Cloud Architecture Pattern: Envelope Encryption (or Digital Envelope) with Public Cloud Providers – Part 1

An Envelope Encryption uses two layers of encryption, first data/encryption key and (strong) master key. Data Key is used for payload encryption, and the master key encrypts data key. Encrypted payload and encrypted data key sent to the consumer where consumer reverse the two-fold encryption.

Envelope Encryption is useful for stronger data privacy and data protection, and the pattern is recommended by PCI-DSS when encryption keys are used to protect card holder data.

Pretty Good Privacy (PGP) was the first greater acknowledged solution in the early ‘90s, as if I pull off my technology historian’s hat. Since then, the pattern has seen number of variation, and it defiantly requires further alteration as we progress towards more and more cloudification. Interestingly, Microsoft Azure and AWS both offer relatively similar Key Management Service as PaaS. Azure KeyVault from Microsoft Azure, and AWS KMS from AWS, they are moreover offering the similar features. Though, on this particular subject, AWS KMS has useful feature that Azure KeyVault is missing at this point of time.

Let’s individually go through sub-patterns (ingredients) to implement Envelop Encryption or Digital Envelope in public cloud; I am deliberately trying to maintain generic template (independent of a cloud service provider) in the article. However, I would come up with (some) separate CSP (cloud service provider) specific articles.

Data Envelope or Envelope Encryption End-to-End

The ingredients for end-to-end pattern are following:

1. Key Management Solution (in Part-1)
2. Key Encryption Key (Master Key) Best Practices (in Part-1)
3. Data Key Solution (Embedded or Independent) (in Part-2)
4. Data/Payload Provider (in Part-2)
5. Data/Payload Consumer (in Part-2)

Key Management Solution

Key Management Platform as a Service (PaaS) or HSM are the ideal solution in the case. However, Windows Certificate Management (or equivalent) can be considered as alternative solutions, too. Secure key management is essential to protecting data in the cloud, with adequate monitoring and auditing key use. AWS KMS and Azure KeyVault uses HSM – Hardware Security Module behind the managed service.

Instead of a deep dive into the (broad) subject, let’s see some important characteristics of the solution.

• ACL, Access Control List would allow restricting services with appropriate authorization and authentication features.
• Key rotation and revocation.
• Advance security features, i.e. vulnerability scanning, instruction detection, instruction prevention, IPS, threat detection, logging and access audit.
• Performance, ideally if powered through Hardware Security Modules.
• High-availability and service redundancy in case of DR.
• Quorum-Signed Commands and ECDHE  key agreement are ideal features for sensitive solutions (especially in BFSI, Defense or Health).

Ideally, the solution should be Zero-Knowledge Application and deployed in complete isolation (including Network Subnet and Firewall).

Key Encryption Key (KEK) aka Master Key

Key Encryption Key (KEK) is a strong key used to protect data keys in our context, the characteristic and considerations are:

• Access to KEK must be restricted to the smallest amount of endpoint.
• Access to KEK should be secured through ACL.
• It is recommended the practice to implement auditing and logging for keys.
• The key must be stored in a location that is secure (ideally Azure KeyVault or AWS KMS or HSM). Key Encryption Keys must not be stored on Web Services, Application Endpoints or Database Servers.

Key Encryption Key Strength

Let’s try to avoid the argument Symmetric Key vs. Asymmetric Key, and focus on strength argument. The Key, The Algorithm and The Strength should be considered through Threat Modelling and Risk Analysis and the primitive would be cryptanalysis.

Just a myth

Asymmetric encryption schemes are more secure because they require both a public and a private key.

From Cryptanalysis perspective,

• AES (symmetric) is more secure than 512-bit RSA (asymmetric).
• 4096-bit RSA (asymmetric) is more secure than 40-bit RC4 (symmetric).

The choice of the key should be based on your Application Architecture. For example, let’s say that you do not trust another party, then Asymmetric Cryptography would be a good fit then Symmetric Cryptography. In this scenario, the next question is to decide the right strength of RSA and tread off attribute would be performance.

Reference to Key Encryption Key, let’s try to understand the basic role.

1. Plaintext Data Key encrypt the payload, complete the purpose.
2. Master Encryption Key aka Key Encryption Key encrypt Plaintext Data Key.
3. Discard Plaintext Data Key and KEK from application memory.