ASVS 5.0 V13.3.3: Run Crypto Operations Inside an Isolated Module

ASVS 5.0 V13.3.3 requires that all cryptographic operations are performed using an isolated security module, such as a vault or hardware security module, so key material is protected from exposure outside it. It is a Level 3 requirement.

The pattern is simple: send data to the module, receive the result, and never receive the key.

Why it matters

A key loaded into application memory can be read by a memory disclosure bug, a debugger, a core dump or a compromised dependency. A key that lives only inside an HSM or KMS cannot be exported, so a compromised app can misuse it only while the compromise lasts, and the module's audit log shows exactly how.

How to implement it

Call the module for sign, verify, encrypt and decrypt rather than fetching keys. Example with AWS KMS signing in Python:

import boto3
kms = boto3.client("kms")
resp = kms.sign(
    KeyId="alias/jwt-signing",
    Message=payload,
    MessageType="RAW",
    SigningAlgorithm="ECDSA_SHA_256",
)
signature = resp["Signature"]

Create the key as non exportable, restrict the kms:Sign permission to the one service, and for large data use envelope encryption: the module encrypts a small data key, and the data key encrypts the bulk data in memory briefly.

How to test it

Confirm the key policy has no export or get operation for the app role, try to retrieve key bytes (it must be impossible) and check the module logs record each operation with the caller identity.

Common mistakes

• Downloading the private key "for performance" and caching it.
• Granting broad key administration rights to the application role.
• Forgetting that data keys also need short lifetimes in memory.

Quick check

Sources

• OWASP ASVS