Blockchain based Identity, Records Management and Voting using AWS

The purpose of tutorial article is to understand the architecture and thought process of building a blockchain based decentralised identity, records management and voting solution using AWS for the government of mars.

Goal

The mars government was to build a fast and secure solution which helps the martians to proof their identity and can cast vote or own properties attached to the identity.

We are assuming that there are three authorities who form the government i.e., identity, voting and property authorities. Identity authority is responsible for issuing identities to people born in mars, voting authority is responsible conducting elections and property authority issues properties to martians and let’s them sell to other martians.

User Flow

The solution should be such that the martians can proof their identity seamlessly. The age-old method of proofing identity is using ID card issued by the government and we can use the same mechanism as people are already familiar with this therefore preventing any education overheads for the martians.

The obtain the ID card, the martian has to visit the nearby identity authority centre or apply online. The requirements can be birth certificate and other supporting documents to proof that the person was actually born in mars. Then the identity authority will generate a unique identifier (ID) and private key for the ID card. The private key is embedded in a chip in the ID card whereas the ID is printed on the card.

The solution will be such that the card holders control their data therefore maintaining user data privacy. The user can choose with whom they want to share their data with. The identity authority shouldn’t be able to share anyone’s data without their consent.

Martians can share photocopy of the ID card or share the ID number during the process of electronic or non-electronic KYC to proof their’s identity. One step further, the private key stored in the chip enables digital KYC and digital signature. For an entity to get digital KYC or digital signature done from a martian they would need an authentication device which scans the private keys stored in the chip and then signs message and/or grants user data access to the entity. For example: voting authority would need to install authentication device at voting booths using which users will cast their vote. During casting vote a message is signed using the user’s key which contains details of who they are voting for and this message acts as a proof that the actual person has voted. Similarly during property transfer and share profile data with property authority the user would require use their ID card.

The private key and ID can also be stored in a an app installed in user’s phone or computer through authentication device. This can be useful for authenticating into other apps/websites and digital signature. For example: this will let martians vote online without going to a voting booth.

Architecting the Application

We have to architect the solution in such a way it’s highly secure, scalable and maintains data privacy. The solutions will be architected to use amazon web services so that there is no overheads of managing servers, scales on demand and majority of the processes are automated.

Challenges

The first step to architecting the application is to collect the various problems/stoppers and find solutions for each of them. Here are the various problems we have currently:

Identity authority shouldn’t store the profile data of martians in any such form that will leak the data in case of a security breach. But if identity authority doesn’t store the profile data then how will they verify if ID card is valid or not in case of verification and how will they validate if the digital signature belongs to a particular ID card?
How will user grant access to their data to other entities such as property authority without sharing their private key as sharing private key will comprise security and privacy in case the private key is leaked due to security breach?
How will property and voting authorities store records and votes in such a way that it cannot be tampered or deleted?
How will voting authority conduct voting in such a way that the voter identity is not stored nor revealed and duplicate votes or votes from non-martians are prevented?

Solution

Let’s see what are the different technologies we can use to solve the above problems. We will also see how AWS can help us in implementation.

Storing Identity Metadata and Verifying Digital Signatures

History shows that governments who store user identities information has always been targeted by the hackers. If identity authority stores user data with them then there is always a chance of leakage due to security breach. So they have to store data encrypted without storing the private key in any remote servers.

The above diagram shows how the technical process of generating a ID card would look like. Private key is stored in the ID card which user can only access. The ID, encrypted data and public key are stored in database as plaintext.

Storing the hash, public key and ID in the blockchain helps achieving two things:

In case the encrypted data is tampered with then it can be verified by matching the hash. The hash is immutable as it’s stored in the blockchain. We are not storing the encrypted data itself in the blockchain because there can be multiple authorities in the blockchain network and it’s against GDPR policy to share encrypted data with someone who shouldn’t have access to it. And also this will replicate the encrypted data to other authorities nodes which is unnecessary duplication and creates overhead for others to manage increase in storage.
Other authorities such as voting and identity authorities can join the network and verify the digital signatures using the public key associated with the ID. It enables a much more secure way of sharing data due to immutable and no reconciliation properties of blockchain.

The idea behind having and unique ID in the card which is different from public key is that in case the user losses their card we can issue a new one with a new private key without users losing ownership of assets of the blockchain. The ID is tagged to the assets. Only during transactions the signature validation is required.

Data Access Control

The simplest way using which martians can share access of their data is by sharing their private key. For example: they can share the private key with property authority and then property authority can request for the encrypted data from identity authority and decrypt it. But in this case the property authority has to store the private key to access the data on demand which again creates a loophole for data breach which can exploit user privacy.

Another solution could be that the property authority can decrypt and again encrypt using a private key they own. But in this case there will be too much duplication of the same data in different forms therefore not a scalable solution.

This is one more solution which would definitely solve the problem i.e., using proxy re- encryption.

The above diagram shows how proxy re-encryption would solve the problem. Basically proxy re- encryption allows data encrypted using person A’s public key to be decrypted by person B’s private key with person A’s consent. The person A grants permission by generating a re- encryption key and sharing it with the person B. The person A needs it’s private key and person B’s public key to generate the re-encryption key. Person B needs re-encryption key, their private key and encrypted data to decrypted the data. The same re-encryption key cannot be used by person C to decryption the data i.e., a new re-encryption key needs to be generated by person A for every person they want to share data access with.

In our case, the authentication device of property authority will have their’s public key configured. When user scans the chip it will send the private key of the ID card and public key of property authority to identity authority’s server. Where the re-encryption key will be generated. Once success, the property authority will go onto request the re-encryption key and encrypted data. Note that property authority will not store the re-encryption key nor the encrypted data. This way anytime they want they can request to view user’s data securely.

The re-encryption key and encrypted data is with identity authority whereas the private key is with property authority therefore for someone to steal information needs to break into both the authorities servers which is cumbersome.

Secure and Immutable Records and Votes Management

It’s very important to make sure that the votes and property records are immutable. Also a vote cannot be casted or removed without the user’s consent nor a property that’s owned by the user can be transferred without the user’s content.

By writing votes and records to blockchain we can make sure this is tamper proof. The same smart contracts that stores the votes and property records can also verify digital signature while casting vote or transferring properties respectively. To be able to verify digital signature, the smart contracts needs to be on the same blockchain network as the identity contract network.

Till now we have been referring to blockchain generically without mentioning what blockchain protocol to use and whether the blockchain will be private or public. Now it’s time to decide that because we don’t want voting authority to have access to properties, property authority’s to have access to votes and identity authority have access to properties and votes both. First of all it has to be a private public because public blockchains don’t have any privacy features so all records and votes will be public. Also public blockchains are not scalable upto to governments and enterprises requirements. There are several private blockchain protocols such as Hyperledger’s Fabric, Quorum, R3’s Corda and so on. For our use-case, Hyperledger’s fabric is the right choice due to its availability in Amazon Managed Blockchain, high TPS and channels for privacy. Other protocols privacy features will not fit our use-case.

A hyperledger fabric network can have multiple blockchains called as channels. The participants of the channel can vote and decide who can join or to be removed from the channel. We will have separate channels for identity, voting and properties chaincodes. Chaincodes between different channels can communicate with each other.

Private Voting

As we will be storing votes in blockchain therefore the input will contain who the user is voting for therefore keeping a permanent record regarding which user has voted for whom. This conflicts with user privacy we want to achieve. We just want to track the total votes for each party and who has voted. We don’t want to track who a person has voted for.

This can be achieved using transient inputs for transactions. A transient input is not stored in the blockchain. It lives in the endorsers peer nodes till the transaction is not committed. Once committed it will be purged. So the party for whom the user wants to vote for can be passed as a transient field.

Deploying on AWS

Let’s see how to deploy this solution in AWS. Every authority will have a hyperledger fabric instance, REST API server, database and frontend for admin and users. Here is the list of AWS services we will use for deploying our solution:

AWS Managed Blockchain: It allows us to easily create Hyperledger Fabric networks. It takes care of managing the peer, orderer and CA. It allows us to add or remove members to the network with just few clicks. It saves a lot of time which is required to deploy and configure hyperledger fabric network.
Elastic Container Registry: Our REST API server will be build into a docker image. This image needs to hosted in a private repository. ECR allows us to store private images which just few clicks. We don’t need to host and manage our own registry.
Elastic Container Service: After the image is hosted we need to run it as a container. Running directly in a place EC2 is painful as it will require manually container orchestration, pre- requisites installation, managing failures and so on. ECS makes it easy to deploy a container with just few clicks. It also allows us to configure replication factor, volume mounts and so on. It also enables CI/CD which saves tons of time we spend on building and deploying code.
DynamoDB: We will use DynamoDB as the database. Installing, scaling and managing a DB is time consuming and takes a lot of effort. In case DynamoDB, nothing such required, it provides a simple to use UI and SDKs to read/write.
Simple Storage Service: This is where we will host our frontend. It enable serverless way of hosting frontend. It takes care of scalability and requires no management overhead.

In the above diagram you can see how each AWS service is connect to each other to make the app functional. This model take care of everything from deployment to scalability. We just need to think about code.