Into To Fabric Deployment

Follow

Into To Fabric Deployment

From Example.org to Product.com

 

Blockdaemon: Building the enterprise blockchain stack 

graph1_fabric.png

Blockddaemon is...

  • The only multi-cloud, multi-geo platform that supports the leading blockchain protocols
  • Blockdaemon enables participation in leading public protocols and also allows fast launch and growth management for private networks
  • BD became a member of the Hyperledger community in May and is working closely with members to simplify the process of deploying nodes and creating scalable enterprise blockchain solutions

 

Blockdaemon: Why Hyperledger?

  • Problem: Transaction throughput vs globally distributed consensus tradeoff.
  • Solution: Use flexible permissioning provided by Hyperledger to provide performance and credible auditability through federated consensus models. Use side-chain snapshotting to public chains when true globally distributed consensus is required.

 

  • Problem: In a sense, current public decentralized blockchains are actually centralized: there is only one single monolithic ledger.
  • Solution: Use flexibily permissioned channels provided by Hyperledger to provide any number of small, independent, single purpose, narrowly focused “kinetic ledgers.”

 

Motivation: 

  • Hyperledger Fabric solution consists of a bundle of PoC demos
    • Cannot be deployed out of the box as a real product

Why?

  • Configuration files are lengthy
    • Have a lot of hard-coded items, such as “example.com
    • Lack many default settings that can be omitted, so they are extremely verbose
  • Generated certificate directory/file structure should not be deployed as is because of:
    • The non-component role-based distribution of credentials
    • The security risk of leaking sensitive credentials
    • The certificate directory structure is confusing, making the solution non-obvious

 

Fabric component and configuration Review

configuation_review.png

 

Configuration files

  • crypto-config.yaml - used by cryptogen
    • Populates crypto-config/ directory
  • configtx.yaml - used by configtxgen
    • A system genesis block; e.g. orderer0.genesis.block
    • A genesis block file for each channel; e.g. channel0.channel.tx
    • An update block; e.g. for anchor peers or modified permissions
    • Creates genesis block files for channels, which describes permissions for that channel
  • docker-compose.yaml - used by docker-compose
    • The files that it can see
    • Environment variables
    • Describes each Fabric component container (ca-server, orderer, peer)
  • config.yaml - client configuration file (in this example, fabric-sdk-go)

 

"White Boxable Elements"

Assuming a fixed configuration (number of orderers, cas, peers, dbs, organization hierarchy etc.) it can be daunting, and no Fabric files provide dynamic (e.g. environment) based customization

  • crypto-config.yaml:
    • 1 top level organization aka DOMAIN
    • 1 suborganization aka ORG
  • configtx.yaml: The above, plus:
    • CONSORTIUM, CHANNEL:
  • docker-compose.yaml: The above, plus:
    • NETWORKID
  • config.yaml:
    • NETWORK, DOMAIN, ORG, CHANNEL

 

Summary:

  • Choose templating engine (e.g. jinja)
    • Change example.com to {{env.DOMAIN}}
    • Convert “sample” config files into template files, for example (in jinja):

 

  • Change org1.example.com to {{env.ORG}}

 

  • Use a deploy methodology that generates desired configuration from templates:
    • Statically defined on deploy (no choice for all static Hyperledger config files)
    • Runtime dependent on launch environment (where possible, e.g. docker-compose or helm)

 

 

 

Untying the Certificate knot

What is a Certificate

  • A certificate is a cryptographically generated document
  • A signed certificate can be confirmed to come from the authoritative source that signed it
  • Purpose of certificates
    • Encryption/Privacy (nobody can read this except for the recipient)
    • Authorization/Identification (I am who I say I am)
    • Authenticity/Signing (this document came from me)
  • In public key cryptography, certificates come in pairs
    • Private keys must be kept secure
    • Public keys can be safely distributed to anyone

 

Public Key Cryptography (PKC)

Public/private key pairs are used in opposite ways for two types of security:

  • Encryption (provides privacy)
    • The public key is used to encrypt a document
    • Only the private key can decrypt that document
    • Anyone intercepting the document cannot read the contents unless they have the private key
  • Authentication (provides identification)
    • The private key is used to sign (encrypt) a document
    • The public key is used to verify (decrypt) the identity of the source of the document
    • Only the entity that has this private key could have generated this document (provides authenticity/provenance)

 

Public Key Infrastructure (PKI)

  • Bootstrapping problem
    • How do we know we are all using the same set of public keys?
    • For encryption, how do we know that the public key we are using to encrypt our document belongs to the intended recipient?
    • For authentication, how do we know that the public key we are using to verify (decrypt) a received document belongs to the proper sender?
  • Commonly agreed upon Central Authority (CA) stamps their approval on all public keys by using the CA’s private key to sign the published key.
  • Can be a hierarchy (chain) of dependent, recursively signed certs, almost like a blockchain!
  • Assures provenance of signed public keys, but only if everyone agrees to use the same public chain of key(s) with the same trusted root CAs

 

Hyperledger Certificate Authority (CA) service

Clients initially authenticate using password (or external authorization, such as LDAP)

Once authenticated, clients can obtain

  • Enrollment Certificates signed by the Enrollment Certificate Authority (ECA)
    • ECs are signed using the CA private key to assert the certificates’ authenticity

Once enrolled, clients use their EC keys to obtain

  • Transaction Certificates signed by the CA private key via the Transaction Certificate Authority (TCA), used for:
    • Chaincode installation/instantiation
    • Chaincode transactions
  • Transport Layer Security (TLS) Certificates signed by the TLSCA private key via the TLSCA, used for:
    • Endpoint security (for mutual TLS encryption)

 

Certificates in Hpyerledger

  • TLS key pairs are used for encryption and decryption (public and private, respectively)
  • Enrollment/transaction key pairs are used for signing and authorization/validation (private and public, respectively)
  • They can be pre-generated with cryptogen, or issued by the CA service
  • x509 “Subject” identifies the holder/signer entity
    • The TLSCA certificate provides the “root” authority for public encryption keys
    • The CA certificate provides the “root” authority for public authorization/validation keys
  • An entity might be a user (e.g. via a Fabric client), or it could be a peer, which uses its certificates to endorse transactions
  • Fabric permissioning is highly flexible. It is based on the identity or organization membership
    • Organizations can be arranged in an arbitrary hierarchy
    • Identities can be members of any subset of organizations (consortiums)

 

Config block(s) determine permissions

Orderer permissions (defined by system genesis block and subsequent config block updates):

  • Which peers can join what channels
  • Who can tell peers to join a channel

Per channel permissions (defined by channel genesis block and subsequent config block updates):

  • Who can install/instantiate chain code
  • What transaction permissions an entity has
    • Invoke transaction that adds to the ledger and/or changes the ledger state (write)
    • Retrieve transaction record, register for transaction events (read)
  • Who can endorse a transaction, and how many endorsements are required

 

transaction_flow.png

 

Certificate  directory structure complexity

  • Certificate generation itself is relatively easy, but the vast number of generated files and directories is overwhelming
  • Specifying 1 orderer org, 1 peer org, 1 admin and 2 users results in
    • 77 directories
    • 70 files, 36 of which are unique. The rest are copies of other files!

structure_complexity.png

 

Entity/User

  • Can be an orderer or peer
  • Can be an Admin or User
  • Key pair for each entity/user is pre-generated by cryptogen, or provided by the CA service
    • Used to encrypt/decrypt sent/received data (TLS)
    • Used to validate/sign login and transaction data (for authentication and endorsements)
  • Each entity/user has its own subdirectory in crypto-config/

 

Per-entity directories generated by cryptogen

  • ca/ - Certificate Authority (CA) certificate (private key not in entity/user directory)
  • tlsca/ - TLS Certificate Authority (TLSCA) certificate (private key not in entity/user directory)
  • tls/ - TLS certificate pair and a copy of the CA public key
    • Ensures endpoints are who they say they are (asserted by the TLSCA above, which signed them)
    • Only used in network/transport layer for communications encryption
  • msp/ - Membership Service Provider
    • Single directory containing everything needed by a user/entity
    • cacerts/, tlscacerts/ - Copies of public CA and TLSCA certs from above
    • admincerts/ - Copy of public Admin cert for authenticating Admins
    • signcerts/, keystore/ - User/entity’s own key paiir

 

Component role based certificate distribution

  • Generated certificate directory/file structure is entity based, not component role based. Typical real-world deployment is done by deploying component role based containers (docker) or pods (k8s)
  • Existing example component layout is based on deploying the entire certificate directory/file structure as is, such that each component potentially can see every single file in the certificate repository if misconfigured
  • Relies solely on the container configuration to prevent the component from seeing private keys it should not have access to
  • Each component should only be able to be configured to access the files it needs, and no others

 

Summary -  What component role should get what?

  • CA service: 2 files
    • Top level CA pair (usually uses same CA for signing TLS certs as well)
  • Orderer: 1 file, 2 directories
    • System genesis block
    • Complete tls/ and msp/ directories specific to that orderer entity
  • Peer: 2 directories
    • Complete tls/ and msp/ directories specific to that peer entity
  • Client: 2 files (minimum)
    • Channel genesis block and config block updates (optional)
    • CA public key (never give out the private key)
    • TLSCA public key (never give out the private key)
    • TLS key pair (optional)
    • Complete user msp/ directory (if not using CA enrollment)

 

 

References/Links

 

This amazingly detailed primer was created by Blockdaemon engineer, Nye Liu

 

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.