Corda Keys and Certificates
This section describes the different types of keys and certificates used by Corda 5. It contains the following:
Application Keys
Corda uses the following types of application key:
| Key | Description | Key Type/Algorithm |
|---|---|---|
| Session Initiation | Used during end-to-end session handshakes between two clusters. This key also signs group parameters. A member Corda identity that has been granted admission to a membership group. Synonym for a virtual node or group member. session initiation key signs the member’s context of the MemberInfo. For more information, see Configure Key Pairs and Certificates for the Member.The MGM Membership Group Manager. May also be referred to as the Network Manager. It is a virtual node and Corda identity that acts as a central registrar for group membership. session initiation key signs the MGM’s context. For more information, see Configure Key Pairs and Certificates for the MGM. The session initiation key is also known as the identity key or session key. | 256-bit ECDSA public/private authentication key pair |
| MGM Registration | Encrypts/decrypts registration requests sent to the MGM by members. The Group policy A JSON file containing network information that is bundled with a CPB to create a CPI. file includes the public MGM key for members to use when making registration requests. The MGM keeps the private key. Registration uses this key for authentication in the P2P protocol. The MGM registration key is also known as the Corda ECDH key. For more information, see Configure Key Pairs and Certificates for the MGM. | 256-bit ECDSA private signature key pair |
| Master Wrapping | Decrypts, through wrapping keys, private keys. This master wrapping key is not available in the database but in higher trust zones (for example, crypto worker and secret managers) that enable decrypting database-encrypted wrapping keys. Encrypted wrapping keys can then decrypt the database-encrypted VNodePrivateKey. The crypto processor configuration specifies a set of master wrapping keys as SALT and passphrase parameters for key derivation. This produces a symmetric key which is used for wrapping (encrypting at rest) all Corda-managed wrapping keys. For more information, see Key Wrapping. | AES-256 symmetric master key |
| Managed Wrapping | Wraps higher level asymmetric private keys. These keys are stored, wrapped by a master wrapping key, in crypto databases in both the cluster and per virtual node. These are symmetric keys used to wrap higher level asymmetric private keys. | AES-256 symmetric wrapping key |
| Ledger | Signs flows and consumes Corda network ledger states. This key is critical for availability. The ledger key is also known as the virtual node private ledger signing key. For more information, see Configure Key Pairs and Certificates for the Member. | 256-bit ECDSA/EDDSA/RSA public/private signature key |
| Notary | Each notary
Corda’s uniqueness consensus service. The notary’s primary role is to prevent double-spends by ensuring each transaction contains only unique unconsumed input states.
virtual node has its own public/private key pair for signing successful notarization requests. A notary service (represented by multiple notary nodes) has a composite public key that is used to validate the signature of any notary node that represents that notary service. The MGM is responsible for maintaining the composite public key for the notary service as a whole, which it broadcasts as part of network information to members. The notary service does not have a public key of its own; instead, the MGM provides a composite public key of all active notary representatives. This allows a virtual node to verify that the approval of a notarization request was valid by ensuring that at least one notary representative of a notary service signed a notarization request. The notary key is also known as the notary signing key. For more information, see Generate a Notary Key Pair. | 256-bit ECDSA private signature key pair |
| Ephemeral Session | Authenticates and encrypts messages sent in one E2E session. Corda creates these secret symmetric keys during the SIGMA key exchange. | 256-bit AES symmetric authentication key |
| Sensitive Config | Decrypts sensitive values encrypted at rest (for example, in the database or Kafka). This key is derived from the Sensitive config SALT and PASSPHRASE credential. | AES-256 symmetric data encryption key |
Infrastructure Keys
Corda uses the following types of infrastructure key:
| Key | Description | Key Type/Algorithm |
|---|---|---|
| P2P TLS | Part of TLS encryption at Corda-cluster gateway level. For more information, see Configure the Cluster TLS Key Pair. | 256-bit ECDSA private authentication key pair |
| REST Gateway TLS | TLS key for REST API/HTTP Gateway connections. For more information, see Install the REST Worker Certificate. | 256-bit ECDSA private authentication key pair |
| CPK Signing | Code-signing key for publishing CPKs. The CorDapp Developer uses this key to sign a CPK Corda Package. A signed ZIP/JAR library of Java code packaged to be portable with all of its dependencies and version information contained within it. before bundling it into a CPB. For more information, see Code Signing. | 256-bit X.509 public signature verification key |
| CPB Signing | Code-signing key for publishing CPIs. The CorDapp publisher uses this key to sign a CPB Corda Package Bundle. A signed ZIP/JAR collection of CPKs that forms a complete application suite and contains all the code that a virtual node must operate, minus the specific network details. before sending it to the Network Operator to import when building a CPI. For more information, see Code Signing. | 256-bit X.509 public signature verification key |
| CPI Publisher | Code-signing key for publishing CPIs. Corda validates that uploaded CPIs Corda Package Installer. A signed ZIP/JAR combination of a CPB and a Group Policy File that defines not only the application code that a virtual node will run, but also the details of the MGM with which to register, and the details of network PKI requirements. are signed with a trusted key. The Network Operator usually imports the signing key to Corda. In some cases, such as the Notary CPI, R3 manages the key. For more information, see Code Signing. | 256-bit X.509 public signature verification key |
PKI Assets
Corda supports the following PKI assets:
| PKI | Description | Type |
|---|---|---|
| Kafka Truststore | Kafka truststore for server authentication (TLS). | JKS |
| Session Keys X.509 Certificate | Session keys certificate validated during session initialization. For more information, see Session Certificates. | X.509 Certificate |
| E2E Identity Trust Roots | Trust root of certificates for session initiation keys. | 256-bit PEM |
| Certificate for Corda releases | Trusted certificates for binary Corda release verification. | X.509 Certificate |
Credentials
Corda uses the following credentials:
| Credential | Description | Type |
|---|---|---|
| SSO Config credentials | SSO credentials used by the HTTP Gateway process. This is an API ID provided by Azure AD. | String |
| Installation credentials creation | Installation credentials with enough entropy created in Kubernetes etcd, Helm Chart, or another vault. These credentials are used for key derivation and cluster database secret encryption. | Passphrase and salt |
| Client Kafka credentials for a specific worker | Kafka credentials (user name and password) created at deployment time and stored by default in Kubernetes etcd as secret configuration. This value is passed to worker pods memory at runtime. | High entropy unencrypted string |
| Kubernetes secrets creation via API | The Cluster Adminstrator creates the secrets in Kubernetes etcd to be used by the Corda Helm charts. This is executed optionally when Helm Chart overrides are not used as an alternative. | |
| Kubernetes Secrets configured in Helm charts | The Cluster Administrator configures the Secrets as overrides in Helm charts. This is an alternative to creating Kubernetes Secrets via API. | |
| HELM Chart execution | Corda cluster installation HELM Chart execution targeting a Kubernetes environment. | |
| Cluster Administrator user credentials | Cluster Administrator user credentials. | 256-bit secure salted/hashed password |
| Sensitive config SALT and PASSPHRASE | SALT and PASSPHRASE to derive a symmetric AES key to decrypt sensitive values encrypted at rest. | High entropy unencrypted string |
| Cluster database credentials | Cluster database credentials. | High entropy unencrypted string |
| Credentials stored in the database | Credentials stored in the cluster database or the trusted SSO provider (authorization server) according to OAuth2 RFC roles. For example, Azure Active Directory credentials or SAML. |
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.