Amazon Encryption SDK Concepts: Difference between revisions
| (13 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
By default, the SDK uses AWS KMS as the [[Amazon_KMS_Concepts#Master_Key_Provider|master key provider]] and its [https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html GenerateDataKey] API operation to generate data keys and the [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html Decrypt] API operation to decrypt a data key that was stored alongside cipher text. AWS KMS encrypts and decrypts the data key by using the [[Amazon_KMS_Concepts#Amazon_KMS_Customer_Master_Key|Customer Master Key]] that was specified when configuring the master key provider before the SDK use. | By default, the SDK uses AWS KMS as the [[Amazon_KMS_Concepts#Master_Key_Provider|master key provider]] and its [https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html GenerateDataKey] API operation to generate data keys and the [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html Decrypt] API operation to decrypt a data key that was stored alongside cipher text. AWS KMS encrypts and decrypts the data key by using the [[Amazon_KMS_Concepts#Amazon_KMS_Customer_Master_Key|Customer Master Key]] that was specified when configuring the master key provider before the SDK use. | ||
By default, the AWS Encryption SDK generates a new data key for every encryption operation. | |||
When data is encrypted, the SDK encrypts the data key and stores it along with the encrypted data in an [[#Encrypted_Message|encrypted message]]. When data is decrypted, the AWS Encryption SDK extracts the encrypted data key from the encrypted message, decrypts it, and uses it to decrypt the data. | When data is encrypted, the SDK encrypts the data key and stores it along with the encrypted data in an [[#Encrypted_Message|encrypted message]]. When data is decrypted, the AWS Encryption SDK extracts the encrypted data key from the encrypted message, decrypts it, and uses it to decrypt the data. | ||
| Line 20: | Line 22: | ||
==Data Key Caching== | ==Data Key Caching== | ||
{{External|[https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/data-key-caching.html Amazon Encryption SDK Developer Guide - Data Key Caching]}} | |||
{{External|[https://aws.amazon.com/blogs/security/aws-encryption-sdk-how-to-decide-if-data-key-caching-is-right-for-your-application/ AWS Security Blog - AWS Encryption SDK: How to Decide if Data Key Caching Is Right for Your Application]}} | |||
</ | AWS Encryption SDK generates by default a data key per each encryption request. This is highly secure, as compromising a data key only exposes only one single piece of ciphertext. However, this approach comes with a performance or monetary cost penalty that may be significant, especially when dealing with a large request volume, as each encryption request implies a remote invocation and non-trivial mathematical operations executed by the KMS backend. The factors that may impact performance/cost are the slowness of the master key operations and the cost of master cost operations. | ||
Symmetrically, decrypting data implies first decrypting the unique data key via an invocation into the KMS backend, which imposes the same type of performance penalty. | |||
The overhead of generating a new data key for each operation can be mitigated by caching data keys locally, at the cost of slightly weaker security. Amazon Encryption SDK offers built-in support for caching keys. When a data key is needed to both encrypt or decrypt data, the data key in clear looked for in the cache: if it is found there, it is used, if not, it is generated or decrypted remotely, then placed in the cache. The total capacity of the cache can also be set. Amazon Encryption SDK provides LocalCryptoMaterialsCache, a configurable, in-memory, least recently used (LRU) cache. The cache provides the following configurable security thresholds: | |||
====Maximum Age==== | |||
Represents the maximum life time for entries in the cache, for both encrypt and decrypt operations. This configuration element is required. When the specified amount of time passes after initial creation of the entry, the entry will be considered unusable, and the next operation will incur a cache miss. As result, a new data key will be generated, or an encrypted data key will be sent to the KMS backend for decryption - then placed again in the cache. The lifetime should be set to be long enough to get cache hits, but short enough to limit exposure of plaintext data key in memory. Maximum age can be used as a key rotation policy. | |||
====Message Use Limit==== | |||
Represents the (optional) maximum number of individual messages that can be encrypted under the same a cached data key. This does not affect decrypt operations. Specifying this limit is optional; by default, the limit is set to 2<sup>32</sup>. This is also the maximum accepted value; if you specify a higher limit, the runtime will indicate an error. The AWS Encryption SDK only caches data keys that use an algorithm suite with a key derivation function. This technique avoids the cryptographic limits on the number of bytes encrypted with a single key. However, the more data that a key encrypts, the more data that is exposed if the data key is compromised. | |||
====Byte Use Limit==== | |||
Represents the (optional) maximum number of plaintext bytes that can be encrypted under the same a cached data key. This does not affect decrypt operations. Specifying this limit is optional; by default, the limit is set to 2<sup>63</sup> - 1. While this limit can be set to zero, in this case keys can only be cached if they are used for zero-length messages. | |||
{{External|[https://github.com/ovidiuf/playground/tree/master/amazon/encryption-sdk/02-data-key-caching Playground Amazon Encryption SDK Data Key Caching Example]}} | |||
=Encrypted Message= | =Encrypted Message= | ||
Latest revision as of 17:20, 13 December 2018
Internal
Supported Algorithms
The library uses an AES-GCM encryption algorithm with 256-bit, 192-bit and 128-bit encryption keys. The length of the Initialization Vector is 12 bytes. The length of the authentication tag is 16 bytes. By default, the SDK uses the data key as an input to the HMAC-based extract-and-expand key derivation function (HKDF) to derive the AES-GCM encryption key, and also adds an Elliptic Curve Digital Signature Algorithm (ECDSA) signature.
Data Key Management
By default, the SDK uses AWS KMS as the master key provider and its GenerateDataKey API operation to generate data keys and the Decrypt API operation to decrypt a data key that was stored alongside cipher text. AWS KMS encrypts and decrypts the data key by using the Customer Master Key that was specified when configuring the master key provider before the SDK use.
By default, the AWS Encryption SDK generates a new data key for every encryption operation.
When data is encrypted, the SDK encrypts the data key and stores it along with the encrypted data in an encrypted message. When data is decrypted, the AWS Encryption SDK extracts the encrypted data key from the encrypted message, decrypts it, and uses it to decrypt the data.
Data keys can be encrypted with more than one master key, for redundancy in case one of the master keys is not accessible. TODO https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html#java-example-multiple-providers.
Data Key Caching
AWS Encryption SDK generates by default a data key per each encryption request. This is highly secure, as compromising a data key only exposes only one single piece of ciphertext. However, this approach comes with a performance or monetary cost penalty that may be significant, especially when dealing with a large request volume, as each encryption request implies a remote invocation and non-trivial mathematical operations executed by the KMS backend. The factors that may impact performance/cost are the slowness of the master key operations and the cost of master cost operations.
Symmetrically, decrypting data implies first decrypting the unique data key via an invocation into the KMS backend, which imposes the same type of performance penalty.
The overhead of generating a new data key for each operation can be mitigated by caching data keys locally, at the cost of slightly weaker security. Amazon Encryption SDK offers built-in support for caching keys. When a data key is needed to both encrypt or decrypt data, the data key in clear looked for in the cache: if it is found there, it is used, if not, it is generated or decrypted remotely, then placed in the cache. The total capacity of the cache can also be set. Amazon Encryption SDK provides LocalCryptoMaterialsCache, a configurable, in-memory, least recently used (LRU) cache. The cache provides the following configurable security thresholds:
Maximum Age
Represents the maximum life time for entries in the cache, for both encrypt and decrypt operations. This configuration element is required. When the specified amount of time passes after initial creation of the entry, the entry will be considered unusable, and the next operation will incur a cache miss. As result, a new data key will be generated, or an encrypted data key will be sent to the KMS backend for decryption - then placed again in the cache. The lifetime should be set to be long enough to get cache hits, but short enough to limit exposure of plaintext data key in memory. Maximum age can be used as a key rotation policy.
Message Use Limit
Represents the (optional) maximum number of individual messages that can be encrypted under the same a cached data key. This does not affect decrypt operations. Specifying this limit is optional; by default, the limit is set to 232. This is also the maximum accepted value; if you specify a higher limit, the runtime will indicate an error. The AWS Encryption SDK only caches data keys that use an algorithm suite with a key derivation function. This technique avoids the cryptographic limits on the number of bytes encrypted with a single key. However, the more data that a key encrypts, the more data that is exposed if the data key is compromised.
Byte Use Limit
Represents the (optional) maximum number of plaintext bytes that can be encrypted under the same a cached data key. This does not affect decrypt operations. Specifying this limit is optional; by default, the limit is set to 263 - 1. While this limit can be set to zero, in this case keys can only be cached if they are used for zero-length messages.
Encrypted Message
The encrypted message consists of at least two parts: header and body. In some cases, it also contains a footer. The message header contains the encrypted data key and information about the how the message body is formed. The message body contains ciphertext. The message footer contains a signature that authenticates the message header and the message body.
Overhead Introduced by Amazon Encryption SDK Message Format
Encrypting data with Amazon Encryption SDK introduces a certain amount of space overhead, mainly due to the fact that the data key, after being encrypted with the customer master key, is stored together with the cipher text. The amount of overhead depends on the size of the clear text data, encryption algorithm, whether additional authenticated data (AAD) is provided, and the length of that AAD, the number and type of master key providers, and the frame size. When AWS Encryption SDK is used with its default configuration, with one CMK in AWS KMS as the master key, with no AAD, and encrypt non-framed data, the overhead is approximately 600 bytes. In general, it can be reasonably assumed that Amazon Encryption SDK adds overhead of 1KB or less, not including AAD.