Distributed Public Key Infrastructure & REMChain Proof-of-Service Consensus

Distributed Public Key Infrastructure & REMChain Proof-of-Service Consensus

Public Key Infrastructure (PKI) is a system of issuance, storage, and verification for digital certificates and public key management. PKI is a foundation of secure communication over the Internet and is prevalent among both human-to-human interactions and machine-to-machine communication.

PKI is an excellent front-line security deterrent against various forms of hacking including phishing and man-in-the-middle attacks but recent developments such as SIM Swapping — that penetrate 2FA — have led to some severe data breaches. A major contributing factor to the ability of hackers to perform attacks that mimic or circumvent digital certificate issuance is the centralized nature of the traditional PKI structure.

Traditional PKI systems rely on Certificate Authorities (CA) to process the registration and issuance of digital certificates typically via asymmetric (public-key) encryption. However, CA’s are subject to unauthorized certificate replication as seen with Symantec’s — a popular CA — issue with Google authentication certificates, and Google’s subsequent revocation of any Symantec certificates.

Moreover, phishing attacks — aided by black SEO and malvertising — can harvest user 2FA details where reliance on SSL/TSL is susceptible to non-self-signed certificates obtained through services such as LetsEncrypt. Users typically do not notice the subtle differences in whether or not the certificate shown is fully verified. DNS-hijacking can also lead to hackers creating new SSL/TLS certificates for fake sites (via IP address) by using a CA that references a DNS entry to prove ownership.

Attacks based on gaming the PKI infrastructure typically rely on manipulating the centralized nature of CAs. REMME — the enterprise-grade access management platform — is utilizing a public blockchain (REMChain) and X.509 self-signed digital certificates for enhanced authentication and securitization of user access. With the security of cryptocurrency exchanges at a premium, analyzing REMChain and its consensus for secure storage, issuance, and validation of digital certificates provides some excellent insight into leveraging blockchains for improved security and user authentication.

How The Protocol Works

REMME uses a public blockchain as the replacement for the CA within a distributed PKI infrastructure, critically decentralizing the ecosystem that powers digital certificate authentication. REMChain is open-source and based on Hyperledger Sawtooth’s blockchain implementation.

REMME’s distributed PKI (dPKI) is designed to reduce central points of failure, with the role of the CA played by the blockchain and accurately maintained through a proprietary Proof-of-Service consensus performed by Masternodes in the network. The REMChain functions as the distributed storage layer for the certificates state (valid or revoked), hash, public key, and expiration date.

Remchain Consensus

Before diving into the consensus, it is essential to evaluate the overall flow of digital certificate issuance, storage, and authentication.

Certificate Issuance

  1. A digital certificate is generated on a REMChain light node (user device).
  2. The user sends a request to REMChain to store the public key of the digital certificate on the blockchain.
  3. The Masternodes go through the Proof-of-Service consensus process, and the certificate is signed, integrated with the private key of the certificate, and returned to the user device.
  4. The certificate state, hash, public key, and expiration date are stored on-chain.

Certificate Verification

  1. Certificate owner sends public part of the certificate to REMChain Masternodes for a request to access.
  2. Masternodes reference the validity (state) of the digital certificate on the REMChain along with its expiration date.
  3. Server grants certificate access to the user if valid authentication.

Certificate Revocation (i.e., device stolen)

  1. Certificate owner sends public part of the certificate to REMChain Masternodes requesting revocation of the certificate.
  2. User signs transaction with a key corresponding to certificate proving ownership.
  3. Masternodes reference validity of certificate on REMChain
  4. Masternodes changes certificate state to revoked/invalid if successful.

The Masternodes perform the proper authentication and referencing of certificates on the REMChain as part of the consensus layer in the network. Called proof-of-service, REMChain’s consensus is a hybrid of proof-of-stake and reputation incentives among the Masternodes and “committees.”

Masternodes effectively control the verification and revocation of digital certificates on REMChain. Specific incentive and design structures are necessary to ensure that Masternodes come to an agreement on the state of the REMChain without certain Masternodes gaining undue influence in the system.

REMChain approaches this with a pseudorandom algorithm generation of which Masternodes participate in each round of consensus (i.e., when they sign each block). The participants in a round of consensus are a pseudorandomly selected group of Masternodes known as a committee. Each committee consists of 10 Masternodes who have an increased probability of joining a committee for each round (and subsequently gaining a portion of the block reward) through a bet and reputation mechanism.

First, Masternodes may only qualify for joining a committee by being an active Masternode, which requires a deposit of 250K REMChain tokens into their Reputation account. Masternodes also have an Operational account which they may withdraw tokens from and perform atomic swaps with ERC-20 tokens, but 250K tokens need to remain in the Reputation account for the node to be active.

Configuring a Masternode requires the 250K token deposit in the Reputation account along with the generation of a public/private key pair where the public key corresponds to the address for both the Reputation and Operational accounts.

Masternodes that are configured with a higher amount of staked tokens will become more likely to be selected to a committee from the initialization of the Masternode. However, the primary mechanism for determining the pseudorandom committee selection are the bets and reputation of the Masternodes.

The Reputation account consists of the 250K token deposit (from the Operational account), and the reward for consensus operations within REMChain. The Operational account is comprised of the ability to transfer tokens between accounts on REMChain, withdraw tokens from the Reputation account, exchange with ERC-20 tokens via atomic swaps, make bets, and pay network fees.

A new committee is formed after the propagation and validation of each block. The committee selection algorithm includes the following information:

  • The hash-code of the latest block.
  • List of all Masternodes.
  • Reputation in Reputation Account of each Masternode.

For each round of consensus, each Masternode in the committee sends a bet along with its own variant of the upcoming block of batched transactions (including the requests for storing digital certificates/public keys) to the rest of the committee for approval. Each block contains a request’s public key and the bet.

The committee determines the block confirmation corresponding to the proposed blocks, and the selected block’s proposing Masternode is rewarded accordingly. The committee is then changed after the consensus round of block confirmation, and the process starts over again.

The reward for the Masternode whose block was selected by the committee contains payments from clients for maintaining their digital certificate public keys, bets of the other Masternodes in the committee, transaction fees, and obligatory network fees from the other committee nodes.

Masternodes that leave the rewards in their Reputation account will not be able to withdraw them directly but can accumulate tokens in the account, increasing the likelihood of being selected to the committee again in a positive feedback loop. Otherwise, the Masternode can withdraw the tokens to the Operational account and transfer them elsewhere.

The pseudorandom, reputation, and bet methodology within the consensus reduces potential attacks from an entity owning multiple Masternodes as well as mitigating the harm an entity with a large number of tokens can have on the network.

Maintaining a dPKI infrastructure through a public blockchain affords much greater security guarantees than a centralized CA issuer/register.

The primary benefits of a dPKI include:

  • Transparency of who was assigned which digital certificate.
  • Instantly revoked certificates.
  • Certificate extensions logged by the public ledger.
  • Issued certificates can be tracked and verified on the public ledger.

Importantly, the costs on the service provider’s end (i.e., an exchange) are reduced, and users do not experience complex UI/UX additions. Instead, users may log in via a standard interface where the dPKI functions as a back-end security layer on top of the 2FA already present with most exchanges.

Use Cases

A dPKI has multiple applications that can provide exceptional security benefits to several industries. Two of the major applications that REMME explicitly identifies are:

  1. Cryptocurrency Exchanges
  2. IoT Devices

REMME has partnered with Changelly — the popular exchange service — for securing their authentication protocol through dPKI infrastructure. Phishing attacks are prevalent on cryptocurrency exchanges, with warnings directly from exchanges consistently emphasized across the market. REMME also provides an extensive research report identifying trending vulnerabilities within exchange authentication processes.

Concerns over IoT machine-to-machine (M2M) authentication security are well-founded. Instances of hacking cars — especially with the proliferation of IoT-connected self-driving cars — are frighteningly real. REMME identifies one of the root causes of the problem as PKI infrastructure for M2M authentication not being adequate to support more than simple password login models. Eventually, a future of automated identification for car sharing and micropayments for an IoT ecosystem requires a robust dPKI infrastructure to function securely.


Many of the primary advantages of blockchains stem from their distributed, transparent and permanent nature. Centralized models of security authentication via digital certificate issuance and verification are susceptible to a new generation of attacks. REMChain employs a public blockchain in place of the traditional Certificate Authority to minimize the trust within a broader dPKI infrastructure aimed at providing a layer of robust and transparent security.

The post Distributed Public Key Infrastructure & REMChain Proof-of-Service Consensus appeared first on Blockonomi.



Write a comment