Let Shannon guide you through this article by watching this video:
In the last decade decentralized ledger technology has come a long way. Blockchain technology in particular has brought many changes to the web, making it decentralized as never before.
Having said that, one of the greatest catch 22’s of blockchain-based decentralized finance revolves around the issue of privacy. On one hand, all transactions being auditable and transparent is one of the greatest strengths of blockchain and decentralized finance, but on the other hand, having data in smart contracts or transitions that could possibly be tied to private data, exposed, and available for all to see is not exactly something that everybody wants in the open.
This was one of the biggest issues that needed to be solved to make the Humanode project not only a reality, but a viable solution. After all, the Humanode’s consensus mechanism is based on the Proof of Human Existence, and utilizes the most private of private data available: feature vectors from biometric data. This data could be a combination of fingerprints, palm prints, facial recognition, iris recognition, eye vein recognition, ear shape, DNA matching, or even neuro-signature or brain activity.
Whatever combination of biometric data is used, it is absolutely essential that this data remains private and kept away from malicious actors in order to protect privacy, and the viability of the Humanode platform. At the same time, this Data needs to be accessible on the Humanode network’s IPFS clusters for human nodes, user registration and authentication.
Until recently, the problem of scalable multi-purpose privacy was unresolved. Then, Secret Network became the first blockchain that allowed privacy-preserving smart contracts. That means applications built on Secret can utilize encrypted data without revealing it to anyone, even the validators of that network. Using privacy technologies (such as trusted execution environments), Secret Network allows developers to build new types of powerful, permissionless, privacy-preserving applications.
Dominant crypto-assets and smart-contract platforms do not provide necessary user privacy, as all transactions, wallet holdings, and smart contract data are publicly available despite being pseudo-anonymous. While major implementations of permissionless blockchains with privacy features are mostly focused on hiding the data of the sender, receiver, or the transaction itself (Z-cash, MimbleWimble) only a few projects have zoned in on bringing privacy to smart contract data and execution. Secret Network is a peer-to-peer network, enabling different parties to jointly store and run computations on data while keeping them completely private. Its computational model is based on a highly optimized version of secure multi-party computation, guaranteed by a verifiable secret-sharing scheme. The secrecy of shares is ensured by mandating that nodes running the network use Intel’s trusted execution environments (TEE), known as enclaves, for computations and data storage. This feature encrypts sensitive data, hiding it from everyone including the node operator (G. Zyskind, et al., 2015).
So, in short, in order to build Humanode, we chose to utilize Secret Network’s private smart contract layer for decentralized private key generation and storage.
The enrollment and subsequent authentications are handled by smart-contract deployed on Secret Network, the contract is able to check whether the submitted probe matches a gallery of FHEd user biometric data. We could have avoided using FHE altogether, since enclaves don’t expose its data to anyone, but storing the biometric data off-chain (on IPFS) allows us to handle 100K+ potential users and even perform 1:N matchings, thus we must protect the data, while keeping all the encryption keys within the enclave, inaccessible to anyone.
A step-by-step guide to Human node enrollment might help to see the processes of interaction much clearer.
Human node enrollment process
Figure 1: Human node enrollment process
Client device
The process starts with the user scanning the biometric modalities required by the network. To facilitate explanation, we will use the modality of facial recognition as an example. The application detects, transforms, and crops the image to pick out a face “chip”. The residual neural network (ResNet) pre-trained model then generates an 128-dimensional vector representation that can be mathematically compared with other vectors to compute the similarity score. The score is simply an Euclidean distance (L2 norm) between two vectors in that 128-dimensional space.
Client-private smart contract communication
Before our protocol could process that data further, we need to encrypt it using FHE. There are several implementations like Microsoft SEAL that allow encoding using the Public Key, however, most of the implementations have a heavy footprint and cannot be used on-chain. To solve this issue, we’ve picked a very lightweight implementation that is written in Rust and compatible with the WASM runtime environment. However, it only uses the Private Key to encrypt and decrypt data, that means in order to protect the biometric data of the user, he’s required to submit that vector to the private smart-contract that has the Private Key. At a later stage of development, we are going to introduce public key encryption for the user to be able to encrypt embedded vectors on his device.
To cover gas fee of that submission, the App generates a temporary Secret private key and the address, and awaits while the client tops-up that address with the required amount of SCRT. In the final version this process will be done automatically with conversion of HMND to SCRT through a DEX, but in the test version the user will be required to cover the cost using the SCRT token manually. Then the app is able to submit a transaction to the private smart contract, resulting in a FHE-encrypted vector, that can be used for public matching.
Client – public cluster communication
The app then submits the received FHEd vectors (gallery) to the IPFS public cluster, basically using the Humanode API. The node processing this request is responsible for storing the content on IPFS and obtaining its CID (Content Identifier, a hash of the contents).
1-n matching of FHEd templates on the IPFS public cluster
As the Humanode cluster maintains the pins of FHEd biometric vectors of previous enrollments, we can now compare them to the FHEd vector gallery of the enrolling human-node. The result of 1:N matching on encrypted data is an array of encrypted scores. Computing the Euclidean distance (L2 norm) can be performed by calculating a simple dot-product of two vectors, if data has been normalized accordingly before FHE processing. The encrypted array of scores is returned to the client in an API response.
Authorization of a new human-node by the Secret Network private smart contract
The client device sends the encrypted array of matching scores to the private smart contract with another transaction. The private smart-contract has a Private Key used for FHE, so it is able to decrypt the scores. If the score is below the threshold, this means a very similar biometric embedded vector already exists among the human nodes, and the attempt of a new human node authorization is denied. If the dissimilarity score is above the threshold, the private smart contract authorizes enrollment: a new HD seed is generated for the user, and the CID and relevant info is stored in the permanent storage. The contract additionally generates a private key for launching a validator node on behalf of the user.
Launch of a replica human node
After the user is authorized to launch a replica human-node server, he may manually or in a provisioned fashion start a server that uses the obtained private key to become a validator in the Humanode network. After two weeks of the evaluation period, if the candidate node passes the requirements, the new human-node validator becomes active in the consensus.
By using the same approach of combining the FHEd vector database on IPFS and the Secret Network private smart contract, we introduce a secure approach to private biometrics for user authentication and a biometric key management solution.
User Enrollment
The User Enrollment scheme mimics that of human-node enrollment. However, it utilizes a biometric database of all FHEd vectors stored on the IPFS public cluster submitted by all users, not only human nodes authorized by protocol, and performs 1-n matching over them.
After the private smart contract receives a matching score above the threshold, meaning there are no similar identities, it generates a new root HD (hierarchical deterministic) seed and stores it in the encrypted domain hiding even from the user. Otherwise, the user is pointed to his previously registered account.
Private biometric key management
Now, as the private contract generated HD seed is tied to a person’s identity, the user can generate as many wallet addresses as he wishes to, using a biometric modality of his choice, cold wallet device, or password. Maximum security is achieved by combining multiple methods through threshold key signatures. For instance, biometric modalities can be set to be insufficient for authentication without a physical device.
User authentication
Figure 2: User authentication scheme in the Humanode network
Client device
In order to repeatedly authorize in the Humanode network or in applications using Humanode private identity protection, the user, again, starts with biometric verification. The user device sends the output embedded vector to the private smart contract through the private channel to obtain its FHEd representation.
At the later stage of development, we are going to introduce public key encryption for the user to be able to encrypt embedded vectors on his device.
Pulling enrollment FHEd vectors
The Humanode cluster, again, provides API capabilities to make the heavy 1:N matching in the cloud. If a user’s device keeps the original CID used during enrollment or other meta-data available (such as moniker name) that can identify its unique CID, then the matching is done simply as an 1:1 match. Otherwise it falls back to 1:N match mode where we have to compute scores for N existing enrollment vectors, that process can be time consuming and cost more gas to submit on-chain.
1-1 matching in a private smart contract
The user submits the FHEd array of scores to the private smart contract. As the contract already stores a Private Key for any FHEd vector, it decrypts the scores provided and can tell the CID that is under desirable similarity threshold. The caveat is that the contract cannot verify that the score has been computed fairly. An external client can always submit an encrypted number that is known to be a “good” score. Therefore, an additional step is required, where a smart contract either requests the original FHEd vectors to perform the 1-1 verification match by itself, or just fetches that from the internal storage DB. We’ve not evaluated yet the gas consequences of storing all enrollment vectors inside the contract’s storage. In any case, the private smart contract always performs only 1-1 matching.
So, if the matching score is below the threshold and has been validated by the smart-contract, that means the identity matches and the user is successfully authorized. In that case, the contract derives a new private key from stored HD seed for that user. This private key is ephemeral, meaning that it can be revoked in the future or replaced with another one. The application on the user’s device would cache that key to avoid going through the process each time the client needs to sign a transaction. The key might be protected by biometrically-enabled authorization on the target OS.
Conclusion
We hope that you were able to grasp the idea behind bilateral interaction between Secret Network and Humanode. Both parties agree that without multi-purpose scalable privacy solutions a truly decentralized internet is nothing more than a fantasy. We wish all the best and good luck to our counterparts and friends from the Secret Network ecosystem and hope that their hard work solves many problems and removes a lot of barriers for evolution of decentralized applications.
About Secret Network:
Secret Network is the first blockchain with privacy-preserving smart contracts. That means applications built on Secret can utilize encrypted data without revealing it to anyone, even the nodes in the network. For the first time, Secret Network allows developers to build powerful, permissionless, privacy-preserving applications – Secret Apps.
Twitter | Telegram | Discord | Youtube
About Humanode:
Humanode is a biometrically encrypted financial network where 1 human = 1 node based on a Merkle-CRDT public cluster on top of IPFS and the private smart contract on Secret Network. Your encrypted biometric identity becomes a stake, every human node shares the fees equally.
