How do you authorize ledger transactions?

Questions
,
1
  1. Do you use some PKI system?
  2. If yes, how do you handle signing transaction? Do you integrate with some hardware solutions or cloud KMS?
1 Like
2

thanks Ed for the offline convo :slight_smile:

There are two aspects to this question

  1. Access
  2. Authorization

Access
For user / party authentication - detailed can be found Following blogs (leveraging PKI, JWT)
Secure Daml Infrastructure - Part 1 PKI and certificates
Secure DAML Infrastructure - Part 2 - JWT, JWKS and Auth0

Additionally Canton documentation covers Identity Management

For actual signing of blockchain in Domain - depends on underlying ledger implementation

HSMs can be supported but not tested at this time.

For authorization please read Daml Ledger Model

1 Like
3

Expanding on this answer as some of these topics and questions relate to overlapping concerns. In general I think of the following:

  • Authentication (providing some set of credentials to provie you are who you claim)
  • Identity (some system / digital representation, often UUID but can be email address or some other handle)
  • Authorization (set of privileges defining what an identity can do).

For Daml ledgers, there are also several levels under which these are used:

  • User or Application access to the ledger services or APIs
  • Execution of the Daml model to perform actions.

The TechNotes in Vivek comment relate to how a user or application authenticate to the Ledger services. We provide support for TLS mutual authentication for connection authentication and JWT to identify (set of) party(ies) that a user/application can act as on the ledger. I view this as connection and coarse-grained authentication. The fine grained authorization decisions for what the party can do with Daml contracts is modelled and enforced by the Daml model and the Daml runtime components (sitting behind the APIs). How ledger transactions are then authenticated and authorised to the underlying ledger is dependent on the specific persistence solution chosen but many will use certificates for authentication, signing and/or encryption.

The other topics - PKI, HSM and KMS.

Public Key Infrastructure (PKI) is a technical option that manages the issuance and management of digital certificates. This involves the creation of key pairs (public, private) using one of many ciphers (RSA, Elliptic curve). Certificates are then the combination of some metadata (name, org, serial number, issuer, etc) with the public key by a signature. The trust model for PKI is derived from trusting the root Certificate Authorities who sign the certificate. Digital certificates can be used for authentication (i.e. TLS mutual auth, TLS server auth amongst others) and the keys can be used for signing, encryptions and other aspects. Details of use are particular to each blockchain. The above glosses over many details and complexities.

Hardware Security Modules (HSMs) allow the creation and secure storage of keys. Depending on the trust model and security tradeoffs, some deployments will want to use HSMs for the storage of some keys. They can be used at many levels of the authentication flow. HSM often have specific features for ensuring security of the hardware devices, including tamper proofing and detection.

Key Management Systems (KMS) are generally services to store secrets (password credentials, keys, etc) securely. Many KMS will use HSMs as the backing store for the KMS services. They are used to store credentials used by applications and often offer both reversible encryption (i.e. you can get back the actual credential) or non-reversible (credential can only used with device and cannot be retrieved). KMS - for example in AWS or GCP, are frequently used to store secrets, credentials and keys for applications being deployed and the infrastructure being configured. Daml applications and runtime components can use KMS services.

There are lots of subtleties to the above so let me know if there are specific questions.

2 Likes