Executive Summary
This whitepaper introduces Rich Online Digital Tokens (RODiT), a novel approach to authentication, configuration, and licensing for online services leveraging non-fungible tokens on blockchain. RODiT address several key challenges compared to traditional methods like digital certificates and public key cryptography:
- Simplified configuration, licensing, and authentication processes
- Prevention of rogue credential issuers
- Streamlined issuing and secure delivery of credentials
- Seamless key rotation independent of license expiration
- Robust protection against man-in-the-middle attacks
RODiT embed metadata like configuration settings, license terms, and authentication claims into unique blockchain tokens. This allows seamless integration of these processes when purchasing online services. The paper provides an overview of RODiT, their implementation on the NEAR blockchain protocol, and Cableguard as a real-world use case for RODiT-based VPN services.
Key benefits of RODiT include reduced complexity/cost, enhanced security, scalability, flexibility in licensing models, support for reselling and white-labeling services. RODiT can enable new solutions across sectors like finance, healthcare, government, telecommunications, and industrial IoT applications requiring strict security.
Introduction
The technology explained in this whitepaper builds on existing technologies and a simple idea: Blockchain-based non-fungible tokens are unique and can´t be cloned, therefore they can be used as authentication keys, ensuring that only the key holder can access what is protected.
Please note there is no relation between our use of non-fungible tokens and what is popularly known as NFTs (expensive unique tokens that have a URL pointing to some digital asset), except using the same underlying technology.
Thin and Rich Credentials
Most authentication methods have two parts, an ID and a credential (a password, a token, etc) but don’t carry any associated info, like configuration or licensing options, claims or addresses, they are what we could call Thin Credentials. Adding or associating configuration or licensing, claims or addresses is performed in separate registration, configuration and licensing processes per Service Provider (a cloud service, a website, a system), in order to gather all the necessary information to provide the service. Using an email address as a credential ID is a very frequent practice that makes thin credentials ever so slightly richer.
If we had credentials that could carry all the configuration, licensing, claims or addresses necessary to interact with Service Providers, that we can call Rich Credentials, that would make registration, configuration and licensing processes simpler or even unnecessary. Instead of having all this information permanently stored by the Service Provider, parts of it contained in the Rich Credential could be shared only when necessary.
Among the several techniques used for authentication, the one that most closely resembles a Rich Credential is the Digital Certificate. It can carry for example Subject Alternative Names, like IP addresses or domain names. In practice, there are few implementations if any that carry configuration or licensing options.
In 1988 the International Telecommunication Union (ITU) published the first version of the X.509 standard for Digital Certificates, which defined the format and syntax of digital certificates. Back in the day continuous and ubiquitous access to the Internet was not common, so one of the requirements in the design was to be able to validate the Digital Certificate while offline. While this requirement is still available as originally designed, some modern features of Public Key Infrastructure (the governance framework for Digital Certificates) can only be used online, for example OCSP. Digital Certificates have not been updated significantly since 2008 (or 1999 you may argue), coincidentally the year of the publication of “Bitcoin: A Peer-to-Peer Electronic Cash System”.
Rich Online Digital Tokens
In this paper we introduce the use of Rich Online Digital Tokens (RODiT), custom non-fungible-tokens that can carry configuration, licensing, claims, and addresses information, as a practical and modern alternative to digital certificates that can be used for mutual authentication, configuration of endpoints and licensing of online services, among other use cases.
Audience
This paper will be of interest for anyone who designs online services (Service Providers).
Problem Statement
There are several problems that can be addressed using RODiT:
Configuration, Licensing and Authentication Complexity and Cost. Both Digital Certificates and Thin Credentials in use require separate registration, configuration and licensing processes that can be become costly and complex in scenarios with strict security requirements.
Rogue Issuers: There is no current fail proof mechanism to prevent the unauthorized issuance of certificates by Certificates Authorities. Participants in Certificate Transparency can monitor and detect unauthorized issuance, but can´t prevent it. Generally speaking Service Providers that use Digital Certificates don´t currently have an effective mechanism to declare which Certificate Authorities (Issuers) they trust, opening the door to well known vulnerabilities in the use of digital certificates (See [1], [2] [3] [4] and [5]). RODiT uses a mechanism whereas domains used by Service Providers must declare what Issuers (that are smart contracts) are trusted to issue valid RODiT for them.
Issuing and Delivering Credentials: When implementing mutual authentication with Digital Certificates, the workflow has several steps that require endpoint access and file transfer of a CSR file between the endpoint and the CA, and a Digital Certificate file between the CA and the endpoint. In order to simplify digital certificate generation and distribution, some implementations generate the CSR and Digital Certificate in a central point, instead of generating the key pairs in the endpoints, which make the private keys far more likely to be compromised. Using RODiT there are no file transfers, as the RODiT is sent to a blockchain address. The impact of using RODiT and its simple issuing and delivery workflow becomes highly significant as the number of participant endpoints grows.
Key Rotation: With Digital Certificates, key rotation requires issuing, transferring and installing a new digital certificate when the key is due to be rotated, regardless of the expiration date of the service being secured with the digital certificate. Expiring digital certificates have caused major incidents worldwide (See [6] and [7]). Using RODiT, key rotation is decoupled from license expiration, as it does not require issuing a new RODiT. Besides, key rotation can be performed independently for every endpoint, without any coordination between endpoints, greatly simplifying management of key rotation. Again, the impact of using RODiT and its simple key rotation workflow becomes highly significant as the number of participant endpoints grows.
Man in the middle (MiTM): This type of attack occurs when a malicious third-party intercepts and alters messages between two unsuspecting parties, potentially stealing confidential information or making unauthorized changes. Despite the risks, mutual authentication is not widely used because of the perceived security provided by other methods and the practical difficulties associated with implementation of mutual authentication for large number of endpoints or large user bases. Using RODiT mutual authentication is simple to implement, providing strong protection against MiTM attacks.
Overview of RODiT
Let’s spell R.O.Di.T out.
- RODiT are Rich because they have configuration and licensing information (not meta information) that is immediately useful.
- RODiT are Online, because they are used while connected to the internet, unlike traditional digital certificates that can operate offline.
- RODiT are Digital to remind you that they are similar in functionality to Digital certificates, and finally;
- RODiT are Tokens because they are unique and they can be bought and sold.
RODiT address, among other features, the following problems:
Configuration, Licensing and Authentication Complexity and Cost
RODiT tokens follow a default structure detailed in Appendix I, and can accommodate extra data fields as necessary for each use case. By including configuration and licensing info in the RODiT, when you purchase a subscription to an online service, at the same time you get your authentication mechanism and your configuration. For example, with a VPN service that uses Cableguard (more about this later), you don’t need to do anything to configure your VPN, it configures itself with the RODiT, and you don’t need to register to be able to login, as it authenticates with the RODiT itself. This is an example of an actual RODiT, with configuration items in blue, authentication items in green and licensing items in orange:
: Each Issuer can mint its own collection of RODiT in the NEAR Protocol blockchain using this component. You can find a live instance for the rodit-org.near smart contract at facilitate paying for RODiT or initializing RODiT addresses. You can purchase NEAR in your cryptocurrency exchange.
Cableguard, as a sample full implementation of RODiT, addresses the following problems:
Configuration, Licensing and Authentication Complexity and Cost
Cableguard VPN servers and clients are licensed via RODiT only.
Cableguard VPN servers and clients authenticate via RODiT only.
Cableguard VPN clients are configured entirely via RODiT.
Cableguard VPN servers are configured via a RODiT and found by clients via associated DNS entries:
- One A type DNS entry per VPN server that lists the IP address.
- One TXT type DNS entry per VPN server that lists the port and public key.
Cableguard VPN doesn´t need a user database, so there is no registration process. Upon purchase of a RODiT that is sent to a blockchain address, the endpoint has the configuration and licensing info that can be validated by all participant endpoints. The only backend process necessary is the DNS configuration and listing of available servers. Not having a registration process or a users database greatly simplifies the backend of a Cableguard VPN service in comparison to current similar services.
Rogue Issuers
Cableguard implements RODiT`s triangle of trust as follows:
Service Providers indicate if they trust particular Issuers with a DNS entry following this format:
rodit-org.near.smartcontract.cableguard.net TXT “whatever”
Issuers indicate if they trust Service Providers with a DNS entry following this format:
cableguard-net.near.serviceprovider.rodit.org TXT “whatever”
Service Providers can indicate if they don´t trust user credentials with a DNS entry following this format:
roditID.revoked.cableguard.net TXT “whatever”
Malicious actors can´t create neither Issuers nor RODiT that will pass these checks and the mutual checks described in the section MiTM below.
Issuing and Delivering Credentials
- Service Providers use Cableguard FORGE to mint collections of RODiT, sent to an address which will distribute them later from a Point of Sale.
- Endpoints use Cableguard RODITPVN to generate locally key pairs, and initialize them in the blockchain with funds from a NEAR Protocol wallet.
- Users purchase RODiT in the Point of Sale with their NEAR Protocol wallet, and obtain the RODiT that are sent to the blockchain address (the public key) in exchange for payment.
Endpoint access or file transfers are unnecessary, and the private key is generated locally in the endpoint with the obvious security implications.
Key rotation
- Endpoint uses Cableguard RODITPVN generates a new key pair, and initialize it in the blockchain.
- Endpoint sends the RODiT to the newly generated blockchain address (public key).
- Optionally, the old key pair can be deleted.
Key lifetime is independent of the duration of the licensed for the service, can happen with whatever frequency that is adequate for the use case, and does not need to be synchronized with the key rotation of any other endpoint.
Man in the middle attack (MiTM)
Each side of every communication performs the following checks on the other end:
- Are we presented with a Live or Revoked RODiT
- Is the RODiT Genuine, is the peer`s signed with the same private key our own RODiT was signed with.
- Is the peer endpoint in Possession of the RODiT at this point in time.
- Is the RODiT Issuer Live or Revoked.
- Is the subscription Active or Expired.
- The RODiT can inform about additional use cases like scopes/permissions, authorized networks, locations, transactions per second, bandwidth, etc.
These checks, plus the implementation of the triangle of trust, and mutual cryptographic authentication and Wireguard`s implementation the Noise protocol framework provide a very effective protection against man in the middle attacks.
NEAR Protocol is a blockchain platform designed to simplify the user experience and make blockchain technology more accessible. It aims to achieve this through several key strategies:
- Chain Abstraction: NEAR Protocol simplifies the complex workings of blockchain technology into more understandable layers, making it accessible to developers, users, and stakeholders. These layers include the protocol layer, network layer, data layer, and smart contract layer.
- Sharding: NEAR Protocol uses sharding to process transactions in parallel, enhancing scalability and making the blockchain’s complexity transparent to users. The blockchain is divided into four shards, each capable of processing 1,000 transactions per second.
- Dynamic Resharding: This feature allows for the creation and destruction of shards based on demand, ensuring scalable and efficient network performance.
- Human- Readable Account Names: NEAR Protocol uses easy-to-remember account names instead of complex addresses, simplifying transactions and interactions on the blockchain.
- Access Keys with Permissions: Users can grant specific permissions to DApps, improving security and usability.
NEAR Protocol is the blockchain selected for the RODiT implementation, driven by a combination of technical, economic, and strategic advantages that the protocol offers, among them:
- Developer- Friendly. NEAR provides a robust and user-friendly development environment, which simplifies the process for developers to build, deploy, and maintain applications. This ease of development can accelerate the creation and enhancement of the RODiT platform.
- Affordable Token Creation. The cost of creating tokens on NEAR is significantly lower compared to other blockchains. This makes it economically viable for users to mint and manage tokens without prohibitive fees, encouraging wider adoption and usage.
- Zero Cost of Token Verification. Verifying ownership and control of tokens on NEAR is essentially free, which helps in maintaining transparency and trust without additional costs.
- Reliability and Minimal Downtime. NEAR Protocol is designed for high reliability, ensuring minimal downtime. This means that applications built on NEAR, including RODiT, can offer consistent and dependable service to their users.
- Incentives for Network Health. NEAR incentivizes its participants to maintain the health and functionality of the blockchain. This ensures a robust and active network, supporting the continuous and stable operation of the RODiT platform.
- Scalability and High Performance. NEAR is built to handle a high volume of transactions efficiently, ensuring that the RODiT platform can scale as its user base grows without compromising on performance.
- Decentralization and Resilience. Being a decentralized platform, NEAR operates without a central authority. This ensures that the RODiT implementation cannot be easily shut down or censored, providing resilience and autonomy to its operations.
- Jurisdictional Independence. NEAR’s decentralized nature means it operates beyond specific jurisdictions, reducing the risk of regulatory interference and providing a global reach for the RODiT platform.
- Proof of Stake (PoS) instead of Proof of Work (PoW). NEAR Protocol operates on a Proof of Stake consensus mechanism, which is more energy-efficient compared to Proof of Work. This makes NEAR an environmentally friendly option, reducing the carbon footprint associated with blockchain operations.
- Accessible Token/Cryptocurrency. NEAR’s tokens are easy to purchase and manage, ensuring that users can seamlessly participate in the RODiT ecosystem without facing barriers related to acquiring or using the native cryptocurrency.
By leveraging these advantages, the NEAR Protocol provides a strong foundation for implementing RODiT, ensuring it is cost-effective, reliable, secure, and scalable, while also being environmentally conscious and user-friendly.
Technical Details of Mutual Authentication
- Endpoints determine if they are presented with a Live or Revoked RODiT by checking if there is a match for the RODiT and a DNS entry following this format: roditID.revoked.serviceproviderdomain. If the entry exists, the authentication fails.
- Endpoints determine if the RODiT is Genuine, by checking if the peer`s RODiT signature found in the serviceprovidersignature was signed with the same private key the endpoint`s own RODiT was signed with. If it does not match, the authentication fails.
- Endpoints determine if the peer endpoint is in Possession of the RODiT by checking if the RODiT ID signature provided has been signed with the key pair that owns the peer`s RODiT in the blockchain at this point in time. If it does not match, the authentication fails.
- Endpoints determine if the peer`s RODiT Issuer is Live or Revoked by checking if there is a match for the RODiT and a DNS entry following this format: issuerdomain.near.smartcontract.serviceproviderdomain . If the entry does not exist, the authentication fails.
- Endpoints determine if the subscription Active or Expired by checking if the current time is between the notafter and notbefore fields of the peer`s RODiT, unless the fields are nul, indicated by the value 1/1/1970. If not Active, the authentication fails.
- The RODiT can inform about additional use cases like scopes/permissions, authorized networks, locations, transactions per second, bandwidth, etc.
Key features and benefits
Besides the problems addressed, there are some additional benefits from using RODiT tokens, as token holders can:
- Sell RODiT at any point during the subscription period to other users. Using other licensing methods selling a partially used subscription is not common or straightforward.
- Swap a RODiT with other users for enhanced anonymity.
- Dispose of a RODiT sending it to a disposal address.
- Renew or a subscription obtaining a discount by returning the previous RODiT, or obtain a rebate for returning an subscription before expiration.
RODiT have some security benefits in comparison to other authentication methods as:
- RODiT can`t be shared between users without risk losing them. This leads to less credential sharing among end users of any Service.
- If the RODiT`s blockchain account is compromised it is easy to detect, as the only way to keep exclusive control by the attacker is by moving it to a new blockchain address. If the attacker does not move the RODiT, it risks losing it as the RODiT owner can move it to a new blockchain address at any time.
Using RODiT can lead to new commercialization practices by Service Providers as:
- Service Providers can delegate sales and distribution to third parties and resellers easily, by providing stocks of RODiT tokens.
- Service Providers can let resellers sell the services with their own brand, “white label”.
RODiT metadata is easily extensible and can cater for custom needs around licensing conditions, permissions (scopes), security boundaries like authorized locations or networks, and other business cases that can be complex to implement using separate licensing, authentication and configuration processes.
Reasons to use a Blockchain
The reasons for using a blockchain instead of a database are the following:
- User control and privacy: Individuals can have more control over their RODiT than they would have with traditional credentials. They can buy RODiT, exchange them, sell them, and renew them without ever having to reveal their identity.
- Decentralization: No single central authority controls the authentication process, reducing the risk of a single point of failure. This also means that small providers can enjoy and high availabilty infrastructure without having to create their own.
- Reduced fraud: The fact that RODiT have a cost creates a higher barrier of entry for any potential attackers.
- Interoperability: Using inter domain trust relationships, RODiT can be reused across multiple systems and platforms.
Use Cases and Applications
RODiT can be leveraged for may uses cases, particularly when there is a need to cater for strict anonymity or security requirements with large number of endpoints. To name a few:
- Cableguard VPN
- As a replacement for SSH Certificates
- Financial Services APIs: Banking, Payment Processing, Cryptocurrency exchanges
- Healthcare APIs: Electronic Health Record (EHR), Medical Device, Telehealth
- Government and Legal Services APIs: Identity Verification, Document Management, Tax and Financial Reporting
- Telecommunications: Messaging applications
- E-commerce APIs: Customer Information, Inventory and Order Management
- Cloud Service Provider APIs: Storage, Compute
RODiT are particularly suited for Industrial and Internet of Things (IoT), as there RODiT can be send to endpoints remotely without accessing the endpoints.
Implementing RODiT can have a big impact in the provision of most online services, particularly:
- Environments at risk due to government sponsored espionage and sabotage.
- Environments where anonymity and security are paramount, like investigative journalism, due to the need to protect whistleblowers and other sources.
- Environments where may need strong authentication in peer to peer messaging, as RODiT mutual authentication is suited to peer to peer validation.
Market Analysis
The overall market value for internet and cloud services in the relevant sectors is as follows:
VPN Services: The global VPN market size is expected to reach USD 43.3 billion by 2027, growing at a CAGR of 14.1% from 2022 to 2027.
SSH Certificates: The global SSH market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 12.1% from 2022 to 2027.
Financial Services APIs: Banking, Payment Processing, Cryptocurrency exchanges:
- The global banking APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 15.1% from 2022 to 2027.
- The global payment processing APIs market size is expected to reach USD 2.1 billion by 2027, growing at a CAGR of 14.3% from 2022 to 2027.
- The global cryptocurrency APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.
Healthcare APIs: Electronic Health Record (EHR), Medical Device, Telehealth:
- The global EHR APIs market size is expected to reach USD 1.3 billion by 2027, growing at a CAGR of 14.2% from 2022 to 2027.
- The global medical device APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.4% from 2022 to 2027.
- The global telehealth APIs market size is expected to reach USD 1.5 billion by 2027, growing at a CAGR of 15.6% from 2022 to 2027.
Government and Legal Services APIs: Identity Verification, Document Management, Tax and Financial Reporting:
- The global identity verification APIs market size is expected to reach USD 1.2 billion by 2027, growing at a CAGR of 13.9% from 2022 to 2027.
- The global document management APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.2% from 2022 to 2027.
- The global tax and financial reporting APIs market size is expected to reach USD 1.3 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.
Telecommunications: Messaging applications:
- The global messaging APIs market size is expected to reach USD 2.3 billion by 2027, growing at a CAGR of 14.5% from 2022 to 2027.
E-commerce APIs: Customer Information, Inventory and Order Management:
- The global e-commerce APIs market size is expected to reach USD 2.5 billion by 2027, growing at a CAGR of 15.3% from 2022 to 2027.
- The global customer information APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 14.1% from 2022 to 2027.
- The global inventory and order management APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.4% from 2022 to 2027.
Cloud Service Provider APIs: Storage, Compute; Internet of Things and SCADA systems:
- The global cloud storage APIs market size is expected to reach USD 2.2 billion by 2027, growing at a CAGR of 14.8% from 2022 to 2027.
- The global cloud compute APIs market size is expected to reach USD 2.5 billion by 2027, growing at a CAGR of 15.5% from 2022 to 2027.
- The global IoT APIs market size is expected to reach USD 1.4 billion by 2027, growing at a CAGR of 14.3% from 2022 to 2027.
- The global SCADA APIs market size is expected to reach USD 1.1 billion by 2027, growing at a CAGR of 13.2% from 2022 to 2027.
See references [10], [11], [12], [13] and [14]
Case Studies
The current reference implementation isCableguard VPN. The following table compares Cableguard VPN with equivalent solutions, Wireguard using PKC and OpenVPN using Digital Certificates.
Appendix I — RODiT Data Structure
| Field Name | Description | X.509 Equivalent | Type and Format | Default value and Valid Range |
|---|---|---|---|---|
| token_id | Unique ID of the token, must be randomly generated | Serial Number | String | For Service Provider is a String like SMARTCONTRACTID;id=ULIDOFTHESERVICEPROVIDER, For Node is a String like: id=ULID |
| issuer_name | Your Service Provider Name | Issuer Name | String | No default value / IT CAN BE EMPTY |
| description_rodit | Description of your Service Provider | Not Applicable | String | No default value / IT CAN BE EMPTY |
| not_after | Date of Expiration of Service | Not After | ISO 8601 YYYY/MM/DD | Default value one year from today’s day, must be greater than not_before, and must take the value 1970/1/1 for “any” |
| not_before | Date of Start of Service | Not Before | ISO 8601 YYYY/MM/DD | Default value today’s date, must take the value 1970/1/1 for “any” |
| subjectuniqueidentifier_url | Service Provider URL | Subject Unique Identifier | URL to guarantee it is unique and controlled by a single entity | No default value, IT CAN NOT BE EMPTY |
| serviceprovider_id | Service Provider ID | Not Applicable | String likeid=ULID or SMARTCONTRACTID;id=ULID | For Service Provider is: ULIDOFTHESERVICEPROVIDER, For Node is a String like SMARTCONTRACTID;id=ULIDOFTHESERVICEPROVIDER |
| serviceprovider_signature | Ed25519 digital signature signed with the Private Key in Base58 | Certificate Signature | String of length 64 | No Default, Ed25519 digital signature (SHA384WITHECDSA), signed with the Private Key in Base58 |
Appendix I — Cableguard VPN Data Structure
| Field Name | Default value and Valid Range |
|---|---|
| token_id | id=ULID |
| issuer_name | Service Provider issuer_name |
| description_rodit | Service Provider description_rodit |
| not_after | expiration date |
| not_before | start date |
| subjectuniqueidentifier_url | No default value |
| serviceprovider_id | SMARTCONTRACTID;id=ULIDOFTHESERVICEPROVIDER |
| serviceprovider_signature | SHA384WITHECDSA signature of the token_id with private key of the blockchain address where the Service Provider root RODiT was sent upon creation |
SOCIAL SHARE CARD GENERATOR