 Hello, everyone. I'm Harika. I'm from Tata Consentancy Services, India. I'm working as a researcher in cybersecurity group in TCS. My research broadly focuses on applying cryptography and blockchain solutions to business scenarios. Today, I'm here to talk about privacy-enabled immunity credential system. So, here is the agenda of my presentation. First, I'll define the problem statement. Then I'll walk you through the solution highlights and then I'll explain you the solution details and conclude the presentation with a demo. Now, let's define the problem. Recently, there has been a lot of buzz on immunity passports due to COVID-19 pandemic. Many international arrivals have already mandated the vaccination certificates for entering into their countries. The burden of verifying these credentials are delegated to airlines similar to the visa verification process. But for airlines, verifying authenticity of these credentials is a challenge. Recently, there has been cases where passengers are presenting fake certificates in order to travel. This is a very serious problem. There have also been concerns on privacy of individual health information. Most of the systems are now centralized. So, health information is under single-party control. So, there is a need for unified platform to verify the authenticity of these credentials. So, here we present a blockchain-based decentralized immunity credential system. This system enables users to authenticate their credentials to necessary parties. The proof recorded on blockchain is immutable and verifiable. So, our solution also facilitates selective disclosure of credentials. This system is a permission system that has verified entities. This also ensures that no single party is in control of the credential information. Our system has two main primitives. One is VLS signature and other one is the blockchain. We chose VLS signature as it produces short signature. It also facilitates selective disclosure and signature aggregation which are important for our system. We use permission blockchain for our system. This enables us to have entities verified before onboarding them as BLS. Blockchain acts as a single source of trust. Also, information stored on blockchain acts as a mutable proof. Our BLS-based scheme has four main functions. One is the key generation function. It takes security parameter as input. It outputs a public and private key pair. Second is the signature function. This function takes a private key and set of inputs and output signatures corresponding to the inputs. This is used to sign a message with a private key. So, third is the proof generation function which is run by some prover. This function takes some challenges from the verifier and outputs a proof. This proof is computed using signatures from previous step and also from the information that user has. Next is the verify proof function. This function verifies the proof sent by the prover using public key. So, our system has three main entities. They are credential issuer, credential holder and credential verifier. The credential issuer has authority to perform immunity tests. They also issue certificates to the users. Examples are healthcare providers or diagnostic centers. Cred holders are individuals who wish to authenticate themselves to travel or work. Examples are employees of a company or passengers who wish to travel. Cred verifiers are parties who authenticate the credentials of the cred holders. Examples are employer or airlines. So, coming to the cred holder registration phase, we have cred holder who wishes to get immunity certificate. We have a cred issuer which is typically a healthcare provider or a diagnostic center. Also, we have a blockchain. In cred holder registration phase, the cred holder approaches a healthcare provider and presents his identity proof. The healthcare provider verifies the identity and performs the play test. So, once the test results are obtained, it creates a set of claims. Here, each claim is a field in the immunity certificate. Example, first name can be a claim. Your unique identification number can be a claim. So, these claims are signed by the healthcare provider's private key. These are sent to the holder and signatures are stored on the blockchain. So, this completes the registration phase. Now, holder has necessary credentials that can be used to prove his or her immunity. Now, coming to the cred holder authenticate claims phase. So, the cred holder approaches a verifier such as airlines to authenticate. The verifier sends challenges to the cred holder. Using these challenges, the cred holder computes a proof and sends it to the verifier. So, now during the verification phase, the verifier performs the verification of the proof against the global proof. Once the verification is performed, status is recorded on the blockchain. So, this status can be reused for authenticating with the same verifier. So, coming to the reuse transaction, the holder queries the previous authentication transaction from the blockchain. Holder gets the transaction details. Using these details, holder forms the reuse transaction by appending the timestamp and signs it with the private key. So, verifier then approves the transaction based on the validity of the reuse transaction. So, we implemented this using Hyperledger Fabric 2.3. So, we created a single channel with two organizations, each having two peer nodes, a certificate authority and an ordering service. Our BLS-based scheme was implemented using pairing-based crypto library. So, each peer runs the PBC service as an additional service. So, we have implemented four smart contracts, one each for registration phase, proof generation, verification and reuse. Here we have some of our results. So, without blockchain, the proof generation is on average taking about 0.025 seconds. Verification is taking about 0.007 seconds. So, with the blockchain, the timings are on average about 0.7 seconds. The signature size which is compressed is around 65 bytes. So, time for generating signature for single claim is 0.011 seconds. Registration transaction is also taking around 0.7 seconds. So, the key takeaways from this talk are, we present a system that facilitates user to authenticate immunity credentials in a verifiable manner. Our system also bypasses repeated proof generation and verification process with the help of reuse transaction. Our system is built on simple and efficient primitives making it practical. Now, we shall move on to the demo part. So, first comes the network setup phase. As I already mentioned, we implemented our system using Hyperledger Fabric 2.3. We created one channel with two organizations, organization one and organization two. Each organization will have two peers, one certificate authority and one ordering service. We used CouchDB as a state database. As you can see, the channel is getting created and peers are added to the organizations. Yes, this completes the network setup phase. So, next is the chain code deployment phase. As we all know, chain code is similar to a smart contract that encapsulates business logic. This logic is agreed by all members of the network. A chain code can be invoked to update or query the ledger. So, in this phase, chain code is being installed on all the peers. So, from each chain code, PBC code is called for performing BLS functions. As I already mentioned, we are implementing BLS-based functions using pairing-based crypto library. So, this PBC-related code is run as an additional service on all the peers. This service is mainly used for signature generation verification and proof generation process. So, we are connecting to the PBC server from the chain code. So, the communication between chain code and PBC service is done via sockets. So, also I would like to emphasize that all the participants of the network are running inside Docker containers in a single machine. But in real-world scenarios, each peer runs in a separate machine. So, in our implementation, we have used chain codes for cred holder registration phase, proof generation and proof verification phases. So, this completes our chain code deployment phase. So, our next is running PBC service. So, we are running PBC service on port 8801. Next, we have the smart contract functionalities. So, first one is the registration transaction. This transaction is used by the cred issuer. So, once this transaction is successfully executed, signatures are stored on the blockchain. These signatures acts as global proof, which will be used while verification. Now, we shall query and see the signatures part. So, these are the signatures stored on blockchain. So, this is the CouchDB UI. You can see the signatures on the CouchDB, they are successfully stored on blockchain. So, next we have the generate proof transaction. This transaction is issued by the cred holder. This transaction takes challenges and claim indices as inputs and computes a proof. This proof and certificate of the cred holder are stored on the blockchain. So, this certificate is used while checking the ownership in reuse transaction. So, next we have the verify proof transaction. This transaction is issued by the verifier. This transaction takes proof and claims as input and verifies the authenticity. So, once this transaction is successful, verification status is stored on the blockchain. So, here we are querying the status. So, this status can be used for authenticating with the same verifier. So, within a validity period. So, as you can see the state database, the verification success has been stored on blockchain. So, this completes our demo part. So, if you have any questions, please feel free to answer. I'll answer them.