Approvers

Recall that with SKA, you can define an authorization policy that defines rules for which approvers need to come together and approve the key usage before the operation is permitted by the HSM.

What is an Approver?

From the view of the HSM, each approver is identified by a public-private key pair. It is called the "Approver Key" or "Approval Key".

The private key is held locally by the human approver and is used to sign approvals. The public key is registered in the SKA policy, and is used by the HSM to verify approvals.

When adding an approver to an SKA policy, you have two options:

• Add a raw public key
• Add an X.509 certificate
  • In normal SKA, the HSM simply extracts the public key from the certificate. All other fields, including the signature are ignored.
  • In SAM mode, the certificate must be signed by one of the CAs allow-listed in the Partition Configuration.

Later, the HSM verifies that an approval is valid by verifying that a specific message is signed by the corresponding private key.

For the purpose of SKA, the HSM does not care how the approver key pair is generated, nor where the private key is stored and how it is access-protected. This decision is up to the approver and their threat model. The available options also vary in user-friendliness.

Managing Approvers

Manually

The simplest—but least secure—method is to use a command-line tool like OpenSSL to generate a key pair and to store the private key on a local device, such as a laptop or smartphone (much like an SSH key).

Similarly, approver keys may be generated and managed with custom software (using the respective programming language's cryptographic library).

However, these approaches often lack a structured workflow for managing approver key pairs. In production environments, this poses a security and availability risk. For example, if you lose too many approver keys, you are no longer able to use your SKA key. To mitigate these risks, appropriate key protection and recovery mechanisms must be implemented.

HSM

The key pair can also be generated and stored in an HSM.

For example, for optimal separation, every user might have its own HSM Partition (so that access control can be separated between users). Then each user's approval client can generate a key pair in their own Partition, and register the public key as the Approver Key. When using the private key, the approval client connects to their Partition. The downside of this is that a lot of Partitions are required.

TSB Approver Management API

The Transaction Security Broker (TSB) provides the Approver Management API. Its idea is the following:

• The HSM generates a key pair and returns it to the TSB.
• The TSB wraps the key using its own wrapping key (for backup purposes) and with a password.
• The TSB stores the wrapped key.
• The approval client retrieves the wrapped key.
• The approval client unwraps the key using the password, and stores it locally.

Using Primus HSM ensures that a true random number generator (TRNG) is used. Only a single HSM Partition is needed (for the TSB). Each approval client needs to have a local mechanism for secure key storage.

For more details, see this page.

warning

This setup is designed for organizations that want to centrally manage approvers and be able to back up approver keys. To avoid the TSB becoming a single point of failure, it is recommended to protect the TSB's wrapping key (defined via hsm.backupKeyName) using SKA and multi-authorization. This SKA key needs to use another method to manage the approver keys.

Securosys Authorization App

info

This is the recommended method for most users.

The Securosys Authorization App is a mobile application designed as a user-friendly approval client. It implements the Approver Management API to obtain a key pair that was generated by an HSM. The app stores the private key in the crypto processor of the respective mobile platform (for example, Secure Enclave on iOS).

For more details, see the Authorization App documentation.

Using Approvers

Every approver needs to have some kind of "approval client". This client:

• Has access to the private approver key.
  • The key storage can be local or remote and can be software- or hardware-backed. How the approver key is managed is up to you, and subject to your threat model.
• Displays pending approvals to the user.
• Received approve/deny actions from the user.
• Upon approval, signs the approvalToBeSigned and returns it to the requester (TSB or a custom backend application).

warning

If the approval signature verification fails, the HSM blocks this approver for 5 minutes. During this time, all other approvals from this approver will be rejected.

If the SKA key has sufficiently many other approvers listed in its SKA policy, the key can still be used. Otherwise, the application needs to wait for the block time to pass and then try again with a new approval signature.

Automated Approval

Recall that from the point of view of the HSM, each approver is simply a public-private key pair. Importantly, an approver does not need to be a human, it can also be an automated process!

This enables building automated approval workflows: you implement custom business logic that checks some rules, and if the rules are satisfied, the approval application signs the task, creating an approval.

On its own, this is no different to where we started without SKA: one application, running on a potentially insecure server, gating access to the HSM keys. However, SKA increases security for automated approval when:

• Combining automated approval with human reviews: Write an SKA policy that requires approval from both a human reviewer and the automated approval code.
• Running the approval logic inside the HSM: With VaultCode, you can run your approval logic inside the HSM. This protects your approval logic from being modified without approval from the HSM Security Officer (SO).