What is an Identity?¶
The different actors in a blockchain network include peers, orderers, client applications, administrators and more. Each of these actors has an identity that is encapsulated in an X.509 digital certificate. These identities really matter because they determine the exact permissions over resources that actors have in a blockchain network. Hyperledger Fabric uses certain properties in an actor’s identity to determine permissions, and it gives them a special name – a principal. Principals are just like userIDs or groupIDs, but a little more flexible because they can include a wide range of an actor’s identity properties. When we talk about principals, we’re thinking about the actors in the system – specifically the actor’s identity properties which determine their permissions. These properties are typically the actor’s organization, organizational unit, role or even the actor’s specific identity.
Most importantly, an identity must be verifiable (a real identity, in other words), and for this reason it must come from an authority trusted by the system. A membership service provider (MSP) is the means to achieve this in Hyperledger Fabric. More specifically, an MSP is a component that represents the membership rules of an organization, and as such, it that defines the rules that govern a valid identity of a member of this organization. The default MSP implementation in Fabric uses X.509 certificates as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model.
A Simple Scenario to Explain The Use of an Identity¶
Imagine that you visit a supermarket to buy some groceries. At the checkout you see a sign that says that only Visa, Mastercard and AMEX cards are accepted. If you try to pay with a different card – let’s call it an “ImagineCard” – it doesn’t matter whether the card is authentic and you have sufficient funds in your account. It will be not be accepted.
Having a valid credit card is not enough – it must also be accepted by the store! PKIs and MSPs work together in the same way – PKI provides a list of identities, and an MSP says which of these are members of a given organization that participates in the network.
PKI certificate authorities and MSPs provide a similar combination of functionalities. A PKI is like a card provider – it dispenses many different types of verifiable identities. An MSP, on the other hand, is like the list of card providers accepted by the store – determining which identities are the trusted members (actors) of the store payment network. MSPs turn verifiable identities into the members of a blockchain network.
Let’s drill into these concepts in a little more detail.
What are PKIs?¶
A public key infrastructure (PKI) is a collection of internet technologies that provides secure communications in a network. It’s PKI that puts the S in HTTPS – and if you’re reading this documentation on a web browser, you’re probably using a PKI to make sure it comes from a verified source.
*The elements of Public Key Infrastructure (PKI). A PKI is comprised of Certificate Authorities who issue digital certificates to parties (e.g., users of a service, service provider), who then use them to authenticate themselves in the messages they exchange with their environment. A CA’s Certificate Revocation List (CRL) constitutes a reference for the certificates that are no longer valid. Revocation of a certificate can happen fora number of reasons. For example, a certificate may be revoked because the cryptographic private material associated to the certificate has been exposed.
Although a blockchain network is more than a communications network, it relies on the PKI standard to ensure secure communication between various network participants, and to ensure that messages posted on the blockchain are properly authenticated. It’s therefore really important to understand the basics of PKI and then why MSPs are so important.
There are four key elements to PKI:
- Digital Certificates
- Public and Private Keys
- Certificate Authorities
- Certificate Revocation Lists
Let’s quickly describe these PKI basics, and if you want to know more details, Wikipedia is a good place to start.
A digital certificate is a document which holds a set of attributes relating to a
party. The most common type of certificate is the one compliant with the X.509 standard,
which allows the encoding of a party’s identifying details in its structure.
For example, Mary Morris of the Manufacturing division of Mitchell Cars in Detroit,
Michigan might have a digital certificate with a
SUBJECT attribute of
C=US, ST=Michigan, L=Detroit, O=Mitchell Cars, OU=Manufacturing, CN=Mary Morris/UID=123456.
Mary’s certificate is similar to her government identity card – it provides
information about Mary which she can use to prove key facts about her. There are
many other attributes in an X.509 certificate, but let’s concentrate on just these
A digital certificate describing a party called Mary Morris. Mary is the
SUBJECT of the
certificate, and the highlighted
SUBJECT text shows key facts about Mary. The
certificate also holds many more pieces of information, as you can see. Most importantly,
Mary’s public key is distributed within her certificate, whereas her private signing key
is not. This signing key must be kept private.
What is important is that all of Mary’s attributes can be recorded using a mathematical technique called cryptography (literally, “secret writing”) so that tampering will invalidate the certificate. Cryptography allows Mary to present her certificate to others to prove her identity so long as the other party trusts the certificate issuer, known as a Certificate Authority (CA). As long as the CA keeps certain cryptographic information securely (meaning, its own private signing key), anyone reading the certificate can be sure that the information about Mary has not been tampered with – it will always have those particular attributes for Mary Morris. Think of Mary’s X.509 certificate as a digital identity card that is impossible to change.
Authentication & Public keys and Private Keys¶
Authentication and message integrity are important concepts of secure communication. Authentication requires that parties who exchange messages can be assured of the identity that created a specific message. Integrity requires that the message was not modified during its transmission. For example, you might want to be sure you’re communicating with the real Mary Morris than an impersonator. Or if Mary has sent you a message, you might want to be sure that it hasn’t been tampered with by anyone else during transmission.
Traditional authentication mechanisms rely on digital signature mechanisms, that as the name suggests, allow a party to digitally sign its messages. Digital signatures also provide guarantees on the integrity of the signed message.
Technically speaking, digital signature mechanisms require require for each party to hold two cryptographically connected keys: a public key that is made widely available, and acts as authentication anchor, and a private key that is used to produce digital signatures on messages. Recipients of digitally signed messages can verify the origin and integrity of a received message by checking that the attached signature is valid under the public key of the expected sender.
The unique relationship between a private key and the respective public key is the cryptographic magic that makes secure communications possible. The unique mathematical relationship between the keys is such that the private key can be used to produce a signature on a message that only the corresponding public key can match, and only on the same message.
In the example above, to authenticate her message Mary uses her private key to produce a signature on the message, which she then attaches to the message. The signature can be verified by anyone who sees the signed message, using Mary’s public key.
Certificate Revocation Lists¶
A Certificate Revocation List (CRL) is easy to understand – it’s just a list of references to certificates that a CA knows to be revoked for one reason or another. If you recall the store scenario, a CRL would be like a list of stolen credit cards.
When a third party wants to verify another party’s identity, it first checks the issuing CA’s CRL to make sure that the certificate has not been revoked. A verifier doesn’t have to check the CRL, but if they don’t they run the risk of accepting a compromised identity.
Using a CRL to check that a certificate is still valid. If an impersonator tries to pass a compromised digital certificate to a validating party, it can be first checked against the issuing CA’s CRL to make sure it’s not listed as no longer valid.
Note that a certificate being revoked is very different from a certificate expiring. Revoked certificates have not expired – they are, by every other measure, a fully valid certificate. This is similar to the difference between an expired driver’s license and a revoked driver’s license. For more in depth information into CRLs, click here.
Now that you’ve seen how a PKI can provide verifiable identities through a chain of trust, the next step is to see how these identities can be used to represent the trusted members of a blockchain network. That’s where a Membership Service Provider (MSP) comes into play – it identifies the parties who are the members of a given organization in the blockchain network.
To learn more about membership, check out the conceptual documentation on MSPs.