In many permissioned blockchain networks like Corda, notaries are dedicated nodes. Built as a decentralized service, they replace the role that miners play in other blockchains like the Bitcoin blockchain. Notaries are also in charge of validating and signing transactions.
In what follows, we will see how HSMs would play a vital role in such notary nodes.
A notary is an “abstract” service that offers canonical transaction ordering, transaction validation and timestamping. Corda has “modular” and “agile” notary services that can be validating or non-validating.
In Corda, the notary service can be run by the participants of the network themselves or by a third party, and eventually ‘real notaries’.
The ordering system is not a validation service. It consists of putting the transactions in a certain order inside blocks, where blocks will be validated (or not). Ordering consists of collecting transactions from clients and ordering them in blocks. An ordering system also checks the permissions of the users (read/write, etc.).
Interesting enough, Corda allows notaries to choose among several consensus algorithms (algorithm agility). For example, they may choose to run RAFT, which is high-speed and high-trust or Byzantine Fault Tolerant (BFT), which is low-speed and low-trust.
Here is an example of some of the consensus algorithms that notaries may use.
|RAFT||RAFT||In RAFT, nodes are following an elected leader. A new leader can be elected at some intervals. RAFT is a voting-based algorithm.|
|Byzantine Fault Tolerant||BFT||BFT is a failure mode system aimed at solving problems where an unknown number of components can have defects (e.g., are malicious in the context of blockchains). With BFT, a minimum of 3n components are needed to make sure that n components do not prevent the system to work correctly. BFT is achieved in Corda by PKI.|
|Istanbul Byzantine Fault Tolerant||IBFT||IBFT works with BFT validating groups but there is a mechanism that allows adding/removing members from the BFT validators.|
|Simplified Byzantine Fault Tolerant||SBFT||SBFT is roughly a BFT algorithm optimized for decentralization|
|Redundant Byzantine Fault Tolerant||RBFT||Improved version of BFT|
|Crash Fault Tolerant||CFT||CFT bears similarities to BFT but handles faulty components (crashed components) rather than malicious components. It can work up to a level of faulty components of 50%.|
There are more BFT-type algorithms though.
A notary service usually provides a unique consensus by attesting that for a specific transaction, this service has not signed a second transaction, consuming some of the candidate transaction’s states.
Both validating and non-validating notaries sign a transaction. However, only the non-validating notary gets the outputs, time windows, and identity of the validating notary while the validating notary can read the code of the smart contract. Typically, a non-validating notary checks that there is no double-spend.
A validating notary will see the contents of transactions. This creates an issue in terms of data protection. A non-validating notary will not see the content but in return, this obviously creates a security risk as the notary could sign the wrong transaction.
In such a case, zero-knowledge-proof (ZNP) is used. Such a protocol allows a notary to validate some data without having direct knowledge of it.
Here we explain how permissioned blockchain notaries can benefit from blockchains.
Notaries perform two distinct cryptographic operations involving PKI: they sign (P2P messaging) and they notarize (e.g., they sign transactions). For this, they need two distinct keys: the identity private keys and the distributed notary private keys.
The distributed notary key can be copied to all the notaries or it can be held into a single HSM. However, usually, in a typical architecture, all notaries use a dedicated HSM that will help protect the copy of the identity private key. The distributed notary key can still be accessed by all the notary workers from a unique, but highly available HSM.
A notary service can automatically perform thousands of validations per second. Therefore, the signing operation must be fast so as to not delay the validation.
Since HSMs hold the identity and distributed notary keys, we can say that the security and protection of keys on HSMs are the backbones of the security architecture. The compromise of these keys may result in the overall compromise of the system, resulting in huge monetary and credibility loss that is the most important factor for banking systems. Hence, top management and system designers should be well aware of the importance of HSMs in their business architectures.
While the incorporation of HSMs is an important parameter, standards/certifications should also be kept in consideration. International certifications help banks gain the trust of users because a globally-certified HSM not only ensures enhanced security for cryptographic operations and throughput. It also provides regulatory/legal compliance.
FIPS 140-2 is the most common and globally-recognized HSM certification, providing maximum security & assurance level of an HSM.
FIPS 140-2 deals with the requirements for certification of HSM cryptographic modules that include both hardware and software components and issues a security compliance rating from one (1: lowest) to four (4: highest) to the HSM. At the minimum, a FIPS 140-2 Level 3 certified HSM should be used in the banking sector..
Notaries are an essential brick of permissioned blockchains like the ones built from the Corda framework. They need HSMs to hold their keys and to quickly sign transactions and P2P messages.