Corda Keys and Certificates heading-link-icon

This section describes the different types of keys and certificates used by Corda 5. It contains the following:

Corda uses the following types of application key:

KeyDescriptionKey Type/Algorithm
Session InitiationUsed 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. Same as a 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 RegistrationEncrypts/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 WrappingDecrypts, 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 WrappingWraps 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
LedgerSigns 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
NotaryEach 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 SessionAuthenticates 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 ConfigDecrypts 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

Corda uses the following types of infrastructure key:

KeyDescriptionKey Type/Algorithm
P2P TLSPart 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 TLSTLS key for REST API/HTTP Gateway connections. For more information, see Install the REST Worker Certificate.256-bit ECDSA private authentication key pair
CPK SigningCode-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 SigningCode-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 PublisherCode-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

Corda supports the following PKI assets:

PKIDescriptionType
Kafka TruststoreKafka truststore for server authentication (TLS).JKS
Session Keys X.509 CertificateSession keys certificate validated during session initialization. For more information, see Session Certificates.X.509 Certificate
E2E Identity Trust RootsTrust root of certificates for session initiation keys.256-bit PEM
Certificate for Corda releasesTrusted certificates for binary Corda release verification.X.509 Certificate

Corda uses the following credentials:

CredentialDescriptionType
SSO Config credentialsSSO credentials used by the HTTP Gateway process. This is an API ID provided by Azure AD.String
Installation credentials creationInstallation 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 workerKafka 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 APIThe 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 chartsThe Cluster Administrator configures the Secrets as overrides in Helm charts. This is an alternative to creating Kubernetes Secrets via API.
HELM Chart executionCorda cluster installation HELM Chart execution targeting a Kubernetes environment.
Cluster Administrator user credentialsCluster Administrator user credentials.256-bit secure salted/hashed password
Sensitive config SALT and PASSPHRASESALT and PASSPHRASE to derive a symmetric AES key to decrypt sensitive values encrypted at rest.High entropy unencrypted string
Cluster database credentialsCluster database credentials.High entropy unencrypted string
Credentials stored in the databaseCredentials 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.