System Architecture

This section describes how to design systems that use Smart Key Attributes (SKA), what components exist, and how they interact.

A common architecture looks as follows:

Entities

The following entities are part of most SKA architectures:

• Business Application: Application that makes key usage request (such as signing and decrypting).
• Approval App: An application where human approvers can review and approve (or deny) requests for key usages. This can be the Securosys Authorization App or a custom app.
• Primus HSM:
  • Partition: The logical space on the HSM where the SKA key is stored and used. The HSM enforces that SKA keys can only be used when the SKA policy is satisfied. The policy is satisfied if enough approvers sign the request with their approval key.
  • VaultCode: Runtime for executing automated approval engines inside the tamper-proof HSM. You can implement common approval logic in code, and let VaultCode automatically approve/deny requests.
• Workflow Orchestrator:
  • The Primus HSM expects fully satisfied SKA policies when it receives a key usage request. The purpose of the workflow orchestrator is to collect enough approvals and wait for timeout periods to pass (for timelocks). Eventually, once the SKA policy is fulfilled, the workflow orchestrator forwards the request to the HSM. This is common logic that can be reused across projects.
  • Therefore, it is recommended to use the Securosys Transaction Security Broker (TSB) instead of reinventing the wheel.

Building With Smart Key Attributes

Smart Key Attributes can be used via the TSB/REST API and via the JCE API. It is up to you which API you use, which architectural components you build yourself, and which you reuse (such as the TSB).