Privacy and security have always been the most important features for all communications between applications on the web. Presently, we use different internet protocols for maintaining data privacy and integrity in order to have secure server authentication and encrypted communications in the network. Some of the internet protocols used are the Transport Layer Security (TLS) and Secure Sockets Layer (SSL). Both are different in the way that they are designed. The former has two layers of operations for establishing a communication link using a handshaking mechanism for authentication and the transfer of the actual message. X.509 certificates are used in both protocols.
The privacy and security features in blockchain include both the public and permissioned types. In public blockchains like cryptocurrencies, the security feature requirement includes the correct transaction validation to avoid double spending, and immutability to make the ledger tamper-proof. However, the permissioned Blockchain which works on a pre-defined consensus and business logic, demands strong identity management, accountability, access control, and authorization.
In this article, we will see how privacy and security are important in the permissioned blockchain, particularly, the Hyperledger fabric which specializes in building the business blockchain applications. For any business application, privacy and security are paramount. So, apart from Identity Management, accountability, and access control, the applications need to be designed in such a way that they are auditable and compatible with the standards. Also, care should be taken in terms of performance, consistency, and scalability with strict adherence to privacy and security features.
In the Hyperledger fabric, Membership Service Provider (MSP) is one of the main components that provides the membership identity to users who are going to transact in the Blockchain network. These users make use of digital certificates to sign the transactions and submit them to the blockchain. The digital certificates are issued by the Certificate Authority (CA) to the user for authentication, access to the system, and to provide a certain level of user-specific privileges for the right access. The main function of the MSP is to identify which Root CAs and Intermediate CAs should be trusted to define the members of an organization. An MSP can also identify specific roles that an actor would play in the organization.
The certificate authority in Hyperledger is pluggable and so, it can either be an internal or an external traditional certificate authority. With these features, the hyperledger fabric is able to provide the membership and access control, endorsement policies, application-level encryption, and trusted chaincode execution with the help of secured containers.
All this while, we were talking about the blockchain privacy, but why do we need it? In the business blockchain applications which involve many organizations operating in different channels while each channel maintains its own chaincode needs transaction data privacy, namely, state data privacy, smart contract privacy, and user privacy.
Until Hyperledger Fabric v1.1, the X.509 certificates were used which are based on the Public Key Infrastructure, a widely accepted international PKI (Public Key Infrastructure). The CA (certificate authority) which issues the X.509 digital certificate, ensures that each of the individuals in the network is issued with a unique certificate. The X.509 certificate contains information such as version, serial number, algorithm information and the validity of the certificate etc.
For more on X.509 refer https://en.wikipedia.org/wiki/X.509
To know more about our Blockchain offerings from our technology experts, call us today or visit our technologies page.
You could also visit our services page on Blockchain Enablement to understand the services that we provide in this area.
The syntax for the X.509 certificates are,
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
-- X.509 signed certificate SignedContent ::= SEQUENCE { certificate CertificateToBeSigned, algorithm Object Identifier, signature BITSTRING } -- X.509 certificate to be signed CertificateToBeSigned ::= SEQUENCE { version [0] CertificateVersion DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name validity Validity, subject Name subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL } |
There are four key elements in the Public Key Infrastructure of the Hyperledger Fabric, namely,
1. Digital Certificates (X.509)
2. Public and Private Keys
3. Certificate Authorities
4. Certificate Revocation Lists
The certificate authorities issue digital certificates. The certificate consists of the public and private keys for a user. Also, the CA maintains the list of certificates issued and their expiry detail. Once the certificate is expired, the certificates are revoked and put in the revocation list.
To know more about digital certificates, contact our experts today.
What is an Identity Mixer?
An Identity mixer is a type of cryptographic protocol that provides privacy and authentication similar to the X.509 but also has rich features like anonymity and unlinkability. In simple words, transactions can be done without revealing the identity.
In a fabric that uses the Identity mixer, there are three actors involved – the user, issuer, and verifier.
1. The Fabric SDK is the API for the Identity mixer user
2. The Fabric CA for the production or development environment is the Identity mixer issuer
3. The verifier MSP in the Fabric is the Identity mixer verifier
In the Identity mixer, the issuer certifies a set of user’s attributes in the form of a digital certificate called credential.
The user now generates the “zero-knowledge proof” of the possession of the credential and also selectively discloses only the attributes the user chooses to reveal.
With the Zero-knowledge the user would not reveal any additional information for the verifier and the issuer.
For more info on Zero-Knowledge proof, please click this link – https://en.wikipedia.org/wiki/Zero-knowledge_proof.
X.509 vs Identity Mixer
Both the X.509 and the Identity mixer have similarities in the credential (Digital Certificate) concept.
The digitally signed signatures cannot be tampered with and the secret key of the digital certificate ( Credential ) is cryptographically bound in both the cases.
The only difference between the X.509 and the Identity mixer is the signature pattern of the certificates.
In the Identity mixer, zero-knowledge proofs are used so that information is not revealed while ensuring that the signature over some attributes is valid. As it uses the Zero-knowledge proofs, the user who is in possession of the corresponding secret key can generate the proofs about the credential and its attributes.
While using X.509 all the attributes have to be revealed to verify the certificate signature and this causes the linkability issue as it is very easy to find out the certificate usage for signing the transactions and to avoid that every time new certificates need to be used. However, the identity mixer helps in avoiding the linkability as the CA ( Certificate Authority ) is not able to link proofs to the original credentials. It is very difficult for the issuer or the verifier to link two proofs were derived from the same digital certificate (credential).
To get your proof of concepts validated by our experts, get in touch with us today.
Though currently, the Identity mixer in the Hyperledger fabric provides authentication and privacy with anonymity and unlinkability, there are some limitations that need to be considered which are delineated below.
Limitations of the Identity Mixer in the Hyperledger Fabric (v 1.4) – Feb 27, 2019
1. A fixed set of attributes are only supported. Custom attributes will be supported in the future release
2. Revocation of an Identity Mixer credential is not yet supported
3. Peers do not user Identity Mixer for endorsements
Thus, the best way to implement Identity mixer in the hyperledger fabric today is to use only one Identity mixer based MSP (Membership service provider) per channel. Once the present limitations are overcome in the future releases, the much-needed anonymity and unlinkability can be achieved
To read other blogs on the Hyperledger fabric from WalkingTree Technologies, click this link.
References – https://hyperledger-fabric.readthedocs.io
