Cryptography As A Service Pattern

Cryptography as a Service Security Pattern

In this pattern, the management of cryptographic keys is delegated to the same entity that performs the cryptographic actions. Consequently, the system under design never possesses the used cryptographic keys.

Benefits and Trade-offs

Benefits:

• Limits risk of leaking cryptographic keys
• Reduces risk of incorrectly configuring and/or using a cipher
• System only handles key identifiers, not key material

Trade-offs:

• Requires greater trust in the entity providing cryptographic operations
• Dependency on external service availability

Common Implementations

Core Components

Note: The Cryptography Service inherits the Cryptographer role from the parent Cryptographic Key Management pattern.

Data Elements

• keyConf: Configuration for key generation (e.g., symmetric/asymmetric, key length) - optional
• keyId: Identifier returned by the service to reference the generated key
• input: Plaintext input for cryptographic action
• output: Result of cryptographic action (e.g., ciphertext, signature)
• config: Configuration for the cryptographic operation (e.g., cipher mode) - optional
• masterKey: Credential used to authenticate the System to the Cryptography Service

Actions

• generate_key: Generate new cryptographic key according to configuration
• crypto_action: Perform cryptographic operation using the identified key

Pattern Flow

Key Generation

System → [generate_key(keyConf)] → Cryptography Service
Cryptography Service → [keyId] → System

The System requests key generation with optional configuration. The Cryptography Service generates the key internally and returns only an identifier (not the key material) for future operations.

Cryptographic Action

System → [crypto_action(input, keyId, config)] → Cryptography Service
Cryptography Service → [output] → System

To use a previously generated key, the System provides the keyId received during generation. The key material never leaves the Cryptography Service.

Key Difference from Self-Managed Cryptography

Security Considerations

The Cryptography Service as Uncontrolled Entity

The Cryptography Service should be considered an uncontrolled entity, requiring additional measures to secure interactions.

Cloud-based Services (Google Cloud KMS, Amazon KMS)

When using cloud-based cryptographic services:

• All interactions travel via the public Internet
• Confidentiality and integrity of exchanged messages must be ensured
• Authentication is critical—verify you're interacting with the actual service, not an attacker spoofing it
• Use TLS/HTTPS for all communications
• Implement proper service authentication (API keys, certificates, IAM)

Mobile Platform Services (Android Keystore, iOS KeyChain)

When using platform-provided services:

• Service is a local entity provided by the underlying platform
• Communication channel is typically more controlled
• Still verify platform-specific security guarantees
• Consider device compromise scenarios

Communication Channel Security

As the Cryptography Service is an uncontrolled entity, at least part of the communication channel will also be uncontrolled.

Required protections:

• Confidentiality of requests (especially for encryption/decryption operations)
• Integrity of requests and responses
• Authentication of the service endpoint

Master Key Handling

The master key is used as a credential to authenticate the System to the Cryptography Service.

Critical: The master key should be treated as a credential:

• Store securely (environment variables, secrets manager)
• Never hardcode in source code
• Rotate periodically
• Limit access to minimal required principals

Key Identifier (keyId) Protection

While keyId is not the key material itself:

• Protect against unauthorized tampering during storage
• An attacker who can modify keyId might redirect operations to a different key
• Consider encrypting or signing stored key identifiers

Implementation Checklist

• Selected appropriate Cryptography Service for your use case
• Reviewed service documentation for security guarantees
• Secured communication channel (TLS, certificate validation)
• Master key stored and managed as a credential
• Key identifiers protected from tampering
• Service authentication properly configured
• Considered service availability and failure modes
• Implemented proper error handling for service failures
• Documented which keys are used for which purposes

Service Selection Considerations

Consult Service Documentation

Always consult the documentation of candidate Cryptography Service(s) to assess:

• Security guarantees for interactions between your system and the service
• Key protection mechanisms (hardware backing, encryption at rest)
• Audit and compliance capabilities
• Service Level Agreements (SLAs)
• Key backup and disaster recovery procedures

Related Patterns

• Cryptographic Key Management (parent pattern)
• Self-Managed Cryptography (alternative implementation)
• Cryptographic Action (uses keys managed by this pattern)
• Encryption (specific cryptographic action)
• Digital Signature (specific cryptographic action)

References

• Source: https://securitypatterns.distrinet-research.be/patterns/99_02_002__crypto_as_a_service/
• E. Barker, 'Recommendation for Key Management: Part 1 – General', NIST SP 800-57 Part 1, May 2020
• Google Cloud KMS Documentation: https://cloud.google.com/kms/docs
• AWS KMS Documentation: https://docs.aws.amazon.com/kms/
• Android Keystore System: https://developer.android.com/training/articles/keystore
• iOS Keychain Services: https://developer.apple.com/documentation/security/keychain_services