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
| Type | Examples |
|---|---|
| Cloud-based KMS | Google Cloud KMS, Amazon KMS, Azure Key Vault |
| Mobile Platform | Android Keystore, iOS KeyChain |
| Hardware | Hardware Security Modules (HSM) |
Core Components
| Role | Type | Responsibility |
|---|---|---|
| System | Entity | Wants to perform cryptographic operations |
| Cryptography Service | Entity | Handles cryptographic operations, key storage, and key management |
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
| Aspect | Cryptography as a Service | Self-Managed Cryptography |
|---|---|---|
| Key possession | System holds only key identifiers | System holds actual key material |
| Key storage | Managed by service | Managed by application |
| Key exposure risk | Lower (keys never exposed) | Higher (keys in application memory) |
| Trust requirement | Trust the service provider | Trust your own implementation |
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
| Consideration | Cloud KMS | Platform Keystore | HSM |
|---|---|---|---|
| Network dependency | Required | No | Varies |
| Audit logging | Built-in | Limited | Built-in |
| Regulatory compliance | Varies by provider | Platform-dependent | Often required |
| Key ceremony | Managed | N/A | Often required |
| Multi-cloud support | Provider-specific | Platform-specific | Usually portable |
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