Module 2: Identity and Membership in Hyperledger Fabric

2.3 Identity and Membership

Identity and membership are foundational concepts in Hyperledger Fabric. As a permissioned blockchain platform, Fabric requires all participants to have identifiable and verifiable identities, which are then used to determine their permissions and access rights within the network.

PKI Infrastructure

Hyperledger Fabric uses a Public Key Infrastructure (PKI) to provide authentication and encryption services. PKI is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates.

Public Key Cryptography Basics

Public key cryptography (also known as asymmetric cryptography) uses a pair of keys:

  • Private Key: Kept secret by the owner
  • Public Key: Freely shared with others

These keys have a mathematical relationship such that: - Data encrypted with the public key can only be decrypted with the private key - Data signed with the private key can be verified using the public key

PKI Components in Fabric

  1. Certificate Authorities (CAs)
  2. Issue and manage digital certificates
  3. Verify the identity of certificate requestors
  4. Maintain certificate revocation lists

  5. Can be hierarchical (root CAs and intermediate CAs)

  6. Digital Certificates

  7. Bind an identity to a public key
  8. Contain information about the identity and the issuing CA
  9. Signed by the issuing CA to prove authenticity

  10. Follow the X.509 standard in Fabric

  11. Certificate Revocation Lists (CRLs)

  12. Lists of certificates that have been revoked
  13. Used to check if a certificate is still valid
  14. Maintained by CAs

  15. Regularly updated and distributed

  16. Registration Authorities (RAs)

  17. Optional component that handles the registration process
  18. Verifies the identity of certificate requestors
  19. Forwards approved requests to the CA
  20. Reduces the workload on the CA

X.509 Certificates

X.509 certificates are the standard format for digital certificates used in Hyperledger Fabric. They provide a way to verify the identity of network participants and components.

Certificate Structure

An X.509 certificate typically includes:

  • Version: Certificate format version
  • Serial Number: Unique identifier assigned by the CA
  • Signature Algorithm: Algorithm used by the CA to sign the certificate
  • Issuer: Name of the CA that issued the certificate
  • Validity Period: Start and end dates for certificate validity
  • Subject: Identity of the certificate owner
  • Subject Public Key Info: Owner's public key and algorithm
  • Extensions: Additional information like key usage, alternative names
  • Certificate Signature: Digital signature created by the CA

Certificate Types in Fabric

Fabric uses different types of certificates for different purposes:

  1. Enrollment Certificates (ECerts)
  2. Long-term identity certificates
  3. Identify components and users in the network
  4. Used for transaction signing and authentication

  5. Issued by the organization's CA

  6. Transaction Certificates (TCerts)

  7. Optional short-term certificates
  8. Derived from ECerts
  9. Provide an additional layer of privacy

  10. Can include specific attributes for fine-grained access control

  11. TLS Certificates

  12. Used for secure communication between components
  13. Authenticate network endpoints
  14. Encrypt communication channels
  15. Issued by a TLS CA (which can be separate from the enrollment CA)

Certificate Lifecycle

The lifecycle of a certificate in Fabric includes:

  1. Registration: Identity is registered with the CA
  2. Enrollment: Certificate is issued to the identity
  3. Usage: Certificate is used for authentication and authorization
  4. Renewal: Certificate is renewed before expiration
  5. Revocation: Certificate is revoked if compromised or no longer needed

Identity Management

Identity management in Hyperledger Fabric involves the processes and tools used to create, maintain, and terminate identities within the network.

Identity Components

An identity in Fabric consists of:

  • Digital Certificate: X.509 certificate binding the identity to a public key
  • Private Key: Corresponding private key (stored securely)
  • Attributes: Optional information about the identity (role, organization, etc.)
  • Privileges: Permissions associated with the identity

Fabric CA

Hyperledger Fabric provides a built-in CA server (Fabric CA) that can be used to manage identities. Key features include:

  • RESTful API: For certificate management operations
  • Web UI: Optional interface for administration
  • Identity Registration: Register new identities with attributes
  • Certificate Issuance: Issue certificates to registered identities
  • Certificate Renewal: Renew certificates before expiration
  • Certificate Revocation: Revoke compromised certificates
  • Attribute-Based Access Control: Include attributes in certificates for fine-grained access control

External CAs

Organizations can also use external CAs instead of Fabric CA. Requirements for external CAs:

  • Must issue X.509 certificates
  • Must support certificate revocation
  • Must be able to include required attributes in certificates
  • Must be trusted by all network participants

Identity Bootstrapping

The process of bootstrapping identities in a Fabric network involves:

  1. Setting up CAs: Deploy and configure CAs for each organization
  2. Creating Admin Identities: Generate certificates for administrative users
  3. Registering Components: Register peers, orderers, and other components
  4. Enrolling Components: Issue certificates to registered components
  5. Configuring MSPs: Set up MSPs to recognize the CAs and identities

Access Control and Policies

Access control in Hyperledger Fabric is implemented through policies that define who can perform specific actions within the network.

Policy Types

Fabric uses several types of policies:

  1. Signature Policies
  2. Based on digital signatures from specific identities
  3. Can use logical expressions (AND, OR, NOutOf)

  4. Example: "Org1.admin AND Org2.admin" requires signatures from both organizations' admins

  5. ImplicitMeta Policies

  6. Reference other policies within the configuration
  7. Use rules like "MAJORITY of Admins" or "ANY of Readers"

  8. Simplify policy management in multi-organization networks

  9. Channel Policies

  10. Control channel configuration and management
  11. Define who can create or modify channels

  12. Specify who can add organizations to channels

  13. Chaincode Policies

  14. Endorsement Policies: Specify which peers must endorse transactions
  15. Lifecycle Policies: Control chaincode deployment and updates
  16. Instantiation Policies: Define who can instantiate chaincode

Policy Evaluation

When an action is attempted, the relevant policy is evaluated:

  1. The action is accompanied by a set of signatures
  2. The policy specifies which identities must sign
  3. The signatures are verified against the specified identities
  4. If the signatures satisfy the policy, the action is allowed
  5. If not, the action is rejected

Role-Based Access Control

Fabric supports role-based access control through:

  • Organizational Roles: Admin, Member, Client, Peer
  • Custom Roles: Defined using attributes in certificates
  • Organizational Units (OUs): Subdivisions within organizations

Policy Examples

Channel Creation Policy:

OutOf(2, 'Org1.admin', 'Org2.admin', 'Org3.admin')

This requires signatures from at least 2 out of the 3 organization admins.

Chaincode Endorsement Policy:

AND('Org1.peer', 'Org2.peer')

This requires endorsements from peers in both Org1 and Org2.

Channel Modification Policy:

MAJORITY Admins

This requires signatures from a majority of the admin identities across all organizations in the channel.

Understanding identity and membership is crucial for implementing secure and properly governed Hyperledger Fabric networks. These concepts form the foundation for access control, transaction validation, and overall network security.

Back to Course Home