Skip to main content

Timestamps

Recall that with SKAs, you can define an authorization policy that can includes a "timelock" or a "timeout", to restrict when key usage is permitted by the HSM.

But how does the HSM know that a certain time has passed?

Workflow

If an application wants to sign with an SKA that has a time requirement, the flow looks as follows:

  1. The application sends a request to the TSB with the payload to be signed with an SKA key.
  2. The TSB forwards the request to the HSM.
  3. The HSM signs (time,payload) with its internal integrity key and returns the signature to the TSB. The timestamp in this signature serves as the reference point. The TSB stores this signature for later.
  4. The TSB collects all necessary approval signatures.
  5. When it is a timelock, the TSB waits for the timelock duration to pass.
  6. The TSB sends the payload, the approval signatures, and the signed timestamp to the HSM.
  7. The HSM verifies that the SKA policy is satisfied. For the time requirements, the HSM verifies:
    • that the timestamp is signed with its integrity key,
    • that the payload matches the payload in the timestamp signature, and
    • that the now requested SKA key operation lies within the allowed time window (not too far away from the signed reference time for timeout, and far enough away for timelock).
  8. If the SKA policy is satisfied, the HSM executes the SKA key operation.

Integrity key

The integrity key is an internal key that never leaves the HSM and can only be used by the HSM itself.

The integrity key is not created automatically, but needs to be explicitly created by the application accessing the HSM partition. For example, see the Primus Tools. The TSB takes care of creating the integrity key for you.

Creating the integrity key requires the Root Key Store (RKS) to be initialized on the HSM. For CloudHSM the RKS is already initialized. For on-premise HSMs you need to configure this as described in section 6 "Attestation and Audit" of the Primus HSM User Guide.

info

In the configuration of the TSB the integrity key is called timestampKey (by its functional name).

The name "integrity key" comes from the HSM API, which exposes integrity as a key capability attribute. Note that the HSM API also defines a dedicated "timestamp key" via the timestamp attribute. Currently, the TSB does not use this new, dedicated "timestamp key" but continues to use the "integrity key" as a timestamp key.

Get started withCloudHSM for free.
Other questions?Ask Sales.
Feedback
Need help?