AWS Developer Tools Blog

Updates to the Amazon S3 Encryption Client

The Amazon S3 Encryption Client is a convenient and efficient tool for performing client-side encryption of objects in S3. One of the unique propositions of client-side encryption is that if you are willing and able to do all of your own key management then you, and only you, will have access to the unencrypted or “plaintext” material should all of your other access controls fail. Historically, client-side encryption has allowed customers in security sensitive and regulated sectors to use cloud storage, such as S3, before a storage service was certified by their regulators or security auditors, since the service would only have access to the encrypted content.

While client-side encryption still has an important role in security and data protection, two of its disadvantages are that it depends on clients having a secure source of randomness, which is not always easy, and it is CPU intensive on the client. For more simplicity and efficiency, our services also offer server-side encryption. Amazon S3 supports three options for server-side encryption.

One option is for S3 to fully manage the encryption keys (SSE-S3). This option places the most trust in AWS.  With security initiatives such as the Amazon Nitro security system, Amazon s2n, and our relentless internal security work, we’ve demonstrated to customers and regulators that Amazon S3 is appropriate for use in highly sensitive environments.

Another option is for the customer to provide the key, but have S3 perform the actual encryption and decryption (SSE-C). This gives customers a level of separation between themselves and AWS that is similar to client-side encryption; there’s a small window where the encryption key will be present on AWS secure servers, but our CPUs do the work of encryption and decryption “in-place” where the data resides.

A third option is for customers to use a key that is managed by the Amazon Key Management Service (KMS) (SSE-KMS). This option, built with hardware-based security in AWS KMS, gives customers control and transparency over access to their keys with strong auditing. AWS KMS lets customers grant specific AWS services the ability to decrypt the underlying data to do work on the customer’s behalf.

Going back to client-side encryption, today we’re making updates to the Amazon S3 Encryption Client in the AWS SDKs. The updates add fixes for two issues in the AWS C++ SDK that the AWS Cryptography team discovered, and for three issues that were discovered and reported by Sophie Schmieg, from Google’s ISE team. The issues are interesting finds, and they mirror issues that have been discovered in other cryptographic designs (including SSL!), but they also all require a privileged level of access, such as write access to an S3 bucket and the ability to observe whether a decryption operation has succeeded or not. These issues do not impact S3 server-side encryption, or S3’s SSL/TLS encryption, which also protects these issues from any network threats.

The first update addresses an issue where older versions of the S3 Encryption Client include an unencrypted MD5 hash of the plaintext as part of an encrypted object’s meta-data. For well-known objects, or for extremely small objects that may be subject to a brute-force attack, this hash may allow an attacker to reveal the contents of the encrypted object. Only a user with read-access to the S3 object could have had access to the hash. This issue owes its history to the S3 “ETag,” which is a content fingerprint used by HTTP servers and caches to determine if some content has changed. Maintaining a hash of the plaintext allowed synchronization tools to confirm that the content had not changed as it was encrypted. In addition to removing this capability in the updated S3 Encryption Client, we’ve also removed the custom hashes generated by older versions of the S3 Encryption Client from S3 object read responses.

The second update addresses an issue where older versions of the S3 Encryption Client support “CBC” mode encryption, but without a message authentication code (MAC) that checks the ciphertext prior to decryption. This leads to a padding issue that is similar to issues found in SSL/TLS. To use this issue as part of a security attack, an attacker would need the ability to upload or modify objects, and also to observe whether or not a target has successfully decrypted an object. By observing those attempts, an attacker could gradually learn the value of encrypted content, one byte at a time and at a cost of 128 attempts per byte.

The S3 Encryption Client supports AES-GCM for encryption, which is not impacted by this issue. In older versions, we continued to support AES-CBC for some programming languages and families where AES-GCM was not performant. As AES-GCM is now supported and performant in all modern runtimes and languages, we’re removing AES-CBC as an option for encrypting new objects.

The third update addresses an issue where the encryption format specifies the type of encryption to be used, but does not sign or authenticate that instruction. This issue is very hard to abuse, but it means that an attacker who has write access to an object can theoretically modify it to specify a different content encryption algorithm than was actually used. When a decryption is attempted using the “wrong” algorithm, if the decryption succeeds, that may reveal details of up to 16 bytes of the underlying data, but it also takes some educated guesswork about what the data may be. As with issue two, this issue also requires that an attacker be able to observe whether or not a decryption succeeded. To address this issue, the updated S3 Encryption Client will validate the content encryption algorithm during decryption.

The remaining updates are related to specific issues that the AWS Cryptography team identified in the AWS C++ SDK. We’ve updated the AWS C++ SDK’s implementation of the AES-GCM encryption algorithm to correctly validate the GCM tag. Prior to this update, someone with sufficient access to modify the encrypted data could corrupt or alter the plaintext data, and that the change would survive decryption. This would succeed if the C++ SDK is being used to decrypt data; our other SDKs would detect the alteration. This sort of issue was one of the design considerations behind “SCRAM”, an encryption mode we released earlier this year that cryptographically prevents errors like this. We may use SCRAM in future versions of our encryption formats, but for now we’ve made the backwards-compatible change to have the AWS C++ SDK detect any alterations.

The other update, also for an issue identified by the AWS Cryptography team, is to correct the length checks in the C++ SDK. When using AES-CBC, the C++ SDK had an insufficient check on the length of the Initialization Vector (IV) used. The IV is random data that is provided to make the encryption secure. The check was correct for AES-GCM, but incorrect for AES-CBC. We found similar behavior when attempting to read an object with a content wrapping key smaller than 32 bytes (256-bits). Neither issue affects the security of the encryption or decryption, but it did mean that the C++ SDK could crash if the initialization vector or wrapping key wasn’t long enough.

In addition to updates for these issues, we have added new alerts to identify attempts to use encryption without robust integrity checks. We have also added additional interoperability testing, regression tests, and validation to all updated S3 Encryption Client implementations.

The updated SDKs can decrypt objects encrypted with previous versions, however the previous versions will not be able to decrypt objects encrypted by the new version because of the format change required to address the third issue.

For more detailed migration instructions for each SDK and additional information on S3 Encryption Client please see the migration guides linked below:

As mentioned above, these issues do not impact S3’s server-side encryption, or S3’s TLS/SSL encryption for data in transit.

Whether security researcher or customer, we are always open to feedback on where we can make improvements across AWS services or tooling—security-related concerns can be reported to AWS Security via aws-security@amazon.com. As ever, we’re grateful for security research and want to thank Sophie for reporting these issues she did. Updated versions of the S3 Encryption Client are now available for download.