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

Envelope Encryption (or Digital Envelope) with Public Cloud Providers – Part 1, we have covered an overview, Key Management Service Solution, Key Encryption Key (Master Key) Best Practices. In this article we would be covering Data Key Solution, Payload Provider Encryption and Payload Consumer Decryption.

Let’s recall the process, the pattern uses two layers of encryption, where data key encrypt the payload (data), and key encryption key (KEK) encrypts plaintext data key. Once the consumer receives encrypted data key and encrypted payload, it decrypts encrypted data key (there are some variants, we would go through in detail) and use plaintext data key to decrypt the payload.

Data Key Solution

Data Key Solution is key to successful and secure implementation. The solution and recommended approaches would vary by scenarios. It would be hard to iterate all possible scenarios, however, will try to cover most common scenarios.

Quote from the previous article,

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.

AWS KMS supports Data Key Solution out-of-the-box. A quote from AWS KMS article,

AWS KMS supports two kinds of keys — master keys and data keys. Master keys can be used to encrypt and decrypt up to 4 kilobytes of data directly and can also be used to protect data keys. The data keys are then used to encrypt and decrypt customer data.

To compensate the feature on Microsoft Azure, you would like to create a lightweight Microservice (with ACL) to handle the same as above.

The above solution can be built based upon open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object, widely known as JWT.

Data Encryption Algorithm and Performance

The very next question is, what should be data encryption algorithm? Ideally, the symmetric key algorithm would be beneficial. The biggest benefit would be performance over asymmetric keys. The public key algorithms are relatively computationally costly compared with symmetric key algorithms of apparently equivalent security. Therefore, asymmetric key algorithms are widely used in hybrid cryptosystem alongside symmetric key algorithms.

In cryptography, a hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem.

[********* ~]$ openssl speed aes-128-cbc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     139343.68k   152748.27k   155215.70k   155745.61k   157196.29k


[********* ~]$ openssl speed rsa2048
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s    927.6  29996.5

I have already busted some myth around encryption key strength in previous article, worth revisiting. For detail performance analysis visit the whitepaper by Abdel-Karim Al Tamimi.

4096-bit RSA (asymmetric) as KEK with AES-256 (other equivalent symmetric key algorithms) would be an excellent pairing, at given time computational feasibility.

Even with a supercomputer, it would take 1 billion billion years to crack the 128-bit AES key using brute force attack. This is more than the age of the universe (13.75 billion years) – EE|Times

While deciding key strength, you should consider on risk and threat perception, service level agreements, payload sizing, computational power and ground requirement.

Data Key Solution – Embedded or Isolated

An embedding data key component vs. an isolated service, it is an excellent question. Unfortunately, there is no definite answer, the core argument would be trust if each other party trust and system boundary are well within Trusted Subsystem ecosystem than embedding a data key solution could benefit from performance and flexibility.

However, if embedding solution would defeat the purpose or compromise the security than it is always preferable to go with a more secure option. Isolated Solution – as Zero-Knowledge Application would provide security and compliance-friendly implementation. It also reduces Attack Surface Area.

Payload Encryption/Decryption

Definition of Payload is “actual data” in a packet, message or file minus all headers attached for transport and minus all descriptive meta-data – PC Magazine. In one of the previous article, I have listed some risks and countermeasures,

• Spoofing – Protecting Secrete Data i.e. User Information, Personal Information, Access Secretes.
• Information Disclosure – Securing sensitive information available at Rest, including Personally Identifiable Information – PII and any other information classified as Sensitive from Business and Organisational perspective.
• Information Disclosure – employing techniques to obfuscate, encrypt, anonymize information in order limit the scope of information access for shadow IT, pseudo-authorise systems and personals (i.e. DBAs, System Engineers).
• Tempering – generate Hash (MD5 Checksum or similar) to maintain the integrity of data.

Payload Encryption would certainly help an organisation to achieve better compliance and security countermeasures.

Let’s re-call the End-to-End solution,

Data Envelope or Envelope Encryption End-to-End

The above diagram would vary based on considerations those we have discussed in Part-1 and in this article, but more or less the overall flow would remain same.

Payload Encryption (Server or Provider)

1. Generate Plaintext Data Key or (if using isolated data key solution or AWS KMS) request Data Key Solution to generate Plaintext Data Key and Encrypted Data Key (for transmitting).
2. Encrypt Payload using Plaintext Data Key.
3. Encrypt Plaintext Data Key using Key Encryption Key (Not needed if implementing isolated data key solution or AWS KMS).
4. Discard Plaintext Data Key.
5. Transmit Encrypted Payload and Encrypted Data Key.

Payload Decryption (Client or Consumer)

1. Retrieve Encrypted Data Key and Encrypted Payload.
2. Decrypt Encrypted Data Key (either using Data Key Solution or Key Encryption Key).
3. Decrypt Encrypted Payload.
4. Discard Keys.

Summary

Envelope Encryption or Digital Envelope pattern is one of the most trusted application security design patterns. Envelop Encryption benefits from Hybrid Cryptosystem (if combined with Asymmetric and Symmetric Keys) that inherits efficiency, performance and security from used encryption algorithms and key strength.

It reduces limitation of Symmetric Encryption Keys by encrypting using Asymmetric Keys; this would provide a security and compliance countermeasures between non-trusted systems while benefiting from Symmetric Key performance. It is very useful with large size payload encryption.

The pattern can be extended with Hash, Anti-forgery or Tempering validation to ensure data integrity, as well.