HSM Integration

AnkaSecure is designed to sit above the customer's Hardware Security Module (HSM) — never replace it. The HSM provides the FIPS-validated cryptographic boundary; AnkaSecure provides the orchestration, policy and lifecycle layer above it.

This page describes the integration architecture, the supported HSMs, and how module-level FIPS 140-2/140-3 coverage is achieved through the deployed HSM.

Why an HSM-Centric Model

Result: customers retain ownership of their key material and the cryptographic boundary, while gaining a uniform orchestration layer across classical and post-quantum algorithms.

Supported HSMs

AnkaSecure integrates with any PKCS#11 v2.40-compliant HSM. The following are validated reference deployments:

For each HSM, the FIPS 140-2 / 140-3 module certificate is published by the vendor on the NIST CMVP website. Auditors should reference the deployed HSM's certificate, not AnkaSecure software.

Integration Architecture

┌─────────────────────────────────────────────────────┐
│           Customer Applications                       │
│         (REST API / SDK / CLI)                        │
└─────────────────────────┬───────────────────────────┘
                          │
                          │ TLS 1.2/1.3 (+ optional ML-KEM transport)
                          ▼
┌─────────────────────────────────────────────────────┐
│        AnkaSecure Control Plane                       │
│                                                       │
│  • Authentication and tenant resolution               │
│  • Policy engine (algorithm availability per tenant)  │
│  • Key lifecycle (create, rotate, revoke, audit)      │
│  • Migration and re-encryption tooling                │
│  • Audit trail (HMAC-signed, tenant-partitioned)      │
│                                                       │
│  ANKASecure© software is NOT a FIPS 140 module        │
└─────────────────────────┬───────────────────────────┘
                          │
                          │ PKCS#11 v2.40
                          ▼
┌─────────────────────────────────────────────────────┐
│      Customer-deployed HSM                            │
│                                                       │
│  • Master KEKs (per tenant)                           │
│  • Wrap / unwrap operations                           │
│  • Validated cryptographic primitives                 │
│  • FIPS 140-2 / 140-3 module boundary                 │
│                                                       │
│  Holds the NIST CMVP certificate that auditors        │
│  reference for module-level compliance.               │
└─────────────────────────────────────────────────────┘

How Operations Flow

Key generation

1. Application calls POST /api/v1/keys with {algorithm, label, tenantId} (tenant inferred from JWT).
2. AnkaSecure validates the algorithm against the active tenant policy.
3. AnkaSecure requests the HSM to generate the key inside the validated boundary.
4. The HSM returns a handle and a public key. The private key never leaves the HSM in plaintext.
5. AnkaSecure persists the public key and HSM handle in its database, and emits an audit event.

Encryption

1. Application calls POST /api/v1/encrypt with {keyId, plaintext}.
2. AnkaSecure looks up the HSM handle for the requested key (tenant-scoped).
3. For asymmetric KEM (e.g., ML-KEM): AnkaSecure derives a Content Encryption Key (CEK) from the HSM, encrypts the payload (AES-GCM), and wraps the CEK using the HSM.
4. The payload is returned to the application as a Compact JWE.

The plaintext private key never leaves the HSM at any point.

Audit

Every operation (generate, encrypt, decrypt, sign, verify, rotate, revoke, policy change) is logged with:

• Tenant ID, user ID, key ID
• Algorithm and operation type
• Outcome (success / failure code)
• Timestamp and correlation ID
• HMAC-SHA256 signature over a 9-field canonical form (tamper-evidence)

Audit events are stored in a separate, tenant-partitioned store (ankadb_audit) and can be replicated to customer SIEMs (Splunk, Elastic, ArcSight, Microsoft Sentinel).

Achieving FIPS Module-Level Coverage

To meet a buyer requirement that mandates a FIPS-validated cryptographic module:

1. Choose a CMVP-validated HSM from the supported list above (or any other PKCS#11 v2.40 HSM with the appropriate FIPS certificate).
2. Deploy the HSM inside your trust zone (on-premise, AWS, Azure, GCP).
3. Configure AnkaSecure to use it via PKCS#11. The setup ships sample configuration for Luna, nShield, AWS CloudHSM, and SoftHSM (dev only).
4. Constrain the algorithm policy to FIPS-approved values via the policy engine. The "FIPS-only" tenant flag rejects requests that would invoke a non-approved primitive.
5. Reference the HSM's NIST CMVP certificate in audit and procurement responses. AnkaSecure's audit reports include the deployed HSM's certificate identifier.

This is the standard architectural pattern for application-layer cryptographic platforms in regulated environments: the validated boundary is the HSM; the orchestration layer composes operations against it.

Sample PKCS#11 Configuration

# application.yml
ankasecure:
  hsm:
    pkcs11:
      library-path: ${PKCS11_LIBRARY_PATH:/usr/lib/softhsm/libsofthsm2.so}
      slot-index: ${PKCS11_SLOT_INDEX:0}
      pin: ${pkcs11_pin}  # From Docker Swarm secret or cloud KMS — never hardcoded
      kek-label-prefix: ankasecure:kek:tenant
      session-pool-size: 10
      session-timeout-seconds: 30

For Thales Luna, AWS CloudHSM, or Entrust nShield, the library-path points to the vendor-provided PKCS#11 library, and the pin is the partition or crypto-officer credential (managed by the customer's HSM operations team).

Operational Considerations

What's Next

• Threat Model — control plane and HSM trust boundaries
• Multi-Tenancy & Isolation — how tenant KEKs and partitions work
• Compliance Overview — how the HSM's FIPS certificate maps to regulatory requirements

For a guided HSM integration, contact [email protected].

Last updated: 2026-04-29