# Abstract
Customers trust that their data is kept secure, and encryption serves as the mechanism to maintain this confidentiality. Examples of this data include, but not limited to Personally Identifiable Information (PII), passwords, and proprietary information. Through the use of keys, data is transformed from a readable format “plain text” to a unreadable ciphertext form. Another way to think of this is we use the key to encrypt/lock the data, and only the other party (could be a device or person) with the corresponding key can decrypt/unlock the data. Additional guidance throughout this whitepaper will help you with securing the sensitive data that customers have shared and entrusted you with.
# Data Protection Policy (DPP) requirements
Encryption in Transit: Developers must encrypt all Amazon Information in transit (e.g., when the data traverses a network, or is otherwise sent between hosts). This can be accomplished using HTTP over TLS 1.2 at minimum (HTTPS). Developers must enforce this security control on all applicable external endpoints used by customers as well as internal communication channels (e.g., data propagation channels among storage layer nodes, connections to external dependencies) and operational tooling. Developers must disable communication channels which do not provide encryption in transit even if unused (e.g., removing the related dead code, configuring dependencies only with encrypted channels, and restricting access credentials to use of encrypted channels).
Developers must use data message-level encryption (e.g., using AWS Encryption SDK) where channel encryption (e.g., using TLS) terminates in untrusted multi-tenant hardware (e.g., untrusted proxies).
Encryption at rest: Developers must encrypt all PII at rest (e.g., when the data is persisted) using industry best practice standards (e.g. using either AES-128 bit or larger keys, AES-256 bit is preferred, or RSA with 2048-bit key size (or higher). The cryptographic materials (e.g., encryption/decryption keys) and cryptographic capabilities (e.g., daemons implementing virtual Trusted Platform Modules and providing encryption/decryption APIs) used for encryption of PII at rest must be only accessible to the Developer's processes and services. Developers must not store PII in removable media (e.g., USB) or unsecured public cloud applications (e.g., public links made available through Google Drive).
Developers must securely dispose of any printed documents containing PII.
# Foundation of data encryption
As organizations seek to operate faster and at scale, protecting critical information becomes more important. Securing data through encryption transforms the content in a manner that makes it unreadable without a secret key to decrypt the content back to readable format. Encryption is the encoding of plaintext into another format known as ciphertext. To encrypt a message (data), a key is needed. With data encryption, we use a key, also known as a secret, to encrypt (lock) and decrypt (unlock) a message. Only the person/device with the correct key can decrypt the message and read its contents. Encryption helps keep Amazon Information safe. Even if a malicious user obtains the ciphertext, they won’t be able to read the contents of the message without having the key to decrypt it. In addition, these cryptographic keys must be protected throughout their lifecycle to prevent unauthorized use, access, disclosure, and modification. Keep in mind that there is difference between hash functions and encryption. A hash function is a cryptographic algorithm used to transform large random-size data to small fixed-sized data. Hashing allows for the verification of data. Encryption, on the other hand, is a two- step process that encrypts and decrypts a message. Encryption protects data by rendering it unintelligible to unauthorized access. Data can be encrypted while it is at rest or in transit. Developers who use NIST 800-53 as their framework may refer to System and Communications Protection (SC) for specific guidance on protecting their environments. One of the primary NIST controls is SC-13 Cryptographic Protection (opens new window). SC-13 identifies specific controls, providing additional details to help Developers understand Amazon MWS & SP-API encryption requirements.
Developers must use encryption to protect the Amazon Information and customer PII. In the following section we describe the critical components of data encryption and provide recommendations to help Developers comply with the Amazon MWS & SP-API Data Protection Policy (DPP) encryption requirements.
# Data classification
Data classification provides a way to categorize organizational data based on levels of sensitivity. It includes understanding what data types are available, where the data is stored, access levels, and the security of data. Amazon information can be classified into two categories of data: PII and non-PII. PII data is any data that can be used to identify an Amazon customer. Non-PII data is any other Amazon data, for example product listing information. Developers can protect Amazon Information by carefully managing an appropriate data classification system, level of access, and encryption of data meeting the DPP requirements. Amazon information that can be used to identify Amazon customers must be encrypted, must be stored in a protected manner, and must require authorized access. Amazon recommends a defense-in-depth approach and reduced human access to Amazon customer PII. Developers must have strong authentication mechanisms in their applications. In addition, Developers must ensure that all connections to their applications originate from a trusted network and have the required access.
# Data integrity
It is important for Developers to ensure that the Amazon Information in their systems maintains its integrity as it moves through their systems. Cryptographic hash functions are a reliable way to establish data integrity. A hash function is an irreversible function in which the original data of arbitrary size is mapped to a fixed-size hash value. If a Developer provides Amazon Information via download, there are two main threats to its integrity: accidental data changes caused by network/storage issues, and tampering by an attacker. Developers can mitigate these threats by using hashing functions to verify file integrity. For example, a Developer can hash the contents of a file before making it available for download. When the file is uploaded back into the application, the Developer can run the hash function on the uploaded file and compare the hash output with that of the original file to verify the file's integrity. This provides the best protection against data changes, whether they are accidentally caused by network or storage issues or intentionally caused by an attacker. Developers can increase their confidence in data integrity by verifying a hash with multiple hash functions.
# Encryption-in-transit
As data is transmitted from one system to another, it is susceptible to undesired interference by unauthorized users or third-parties. Data transmission can be limited to a Developer's private or public networks and still be susceptible to malicious attacks.
Developers must protect Amazon Information in-transit, including in communication between other services and end users, by implementing encryption-in-transit. This helps to protect the confidentiality and integrity of data.
Encryption-in-transit protects information by using supported encryption protocols such as TLS 1.2, or HTTPS (HTTP over TLS). This level of encryption must be enforced across all external and internal endpoints. Data propagating through channels, connections to external dependencies, and operational tooling must be protected with encryption-in-transit. As Amazon Information is transmitted, the communication channel used must be encrypted so that no unauthorized interference is possible. Best practice is to encrypt and authenticate all traffic. In NIST 800-53, encryption-in-transit is outlined in control SC-8 Transmission Confidentiality and Integrity (opens new window). Developers leveraging this control should consider adopting the SC-8 control enhancements, as each enhancement can provide additional protections for data in transit.
Developers should consider the following when encrypting data in transit:
- Disable communication channels that cannot support encryption-in-transit.
- Avoid routing traffic through multi-tenant infrastructure nodes.
- Use data message-level encryption if end-to-end TLS is not permissible.
[block:image] { "images": [ { "image": [ "https://files.readme.io/6447d52-https_protocol.png", "https_protocol.png", 1195, 356, "#091313" ] } ] } [/block] Figure 1: HTTPS protocol in use
Table 1 lists some Amazon-compliant security protocols for encrypting data in transit.
| Transfer Type | Insecure Protocols (Non-Compliant) | Secure Protocols (Compliant) |
|---|---|---|
| Web Access | HTTP | HTTPS with TLS 1.2+ |
| E-Mail Servers | POP3, SMTP, IMAP | POP3S, IMAPS, SMTPS |
| File Transfer | FTP, RCP | FTPS, SFTP, SCP, WebDAV over HTTPS |
| Remote Shell | Telnet | SSH-2 |
| Remote Desktop | VNC | r-admin, RDP |
Table 1: Secure vs Insecure protocols to encrypt data in transit
# Encryption-at-rest
Any time a Developer keeps Amazon information in a data store it must be protected. A data store is any storage medium where data can be saved and retained for a specified period of time. Database solutions, block storage, object storage, and archived data blocks are all examples of data stores that must be protected. Developers can secure data in a data store using encryption – this is called encryption-at-rest. Implementing encryption and appropriate access controls reduces the risk of unauthorized access. In NIST, encryption-at-rest is explained in SC-28 Protection of Information at Rest (opens new window). SC-28(1) aims to protect information at rest via cryptography and SC-28(2) aims to protect information via offline storage. Both of these controls are required for Developers who handle Amazon customer PII, as explained in the Amazon MWS & SP-API DPP. Best practice is to encrypt Amazon Information prior to uploading it to a storage destination and protect the storage itself with an approved encryption algorithm. This protects the data at two levels: during transmission from the source to the storage destination and throughout its lifespan at rest in the storage destination.
Developers using Amazon S3 for storage can use the native encryption capabilities of S3 to protect data at rest. You do not “encrypt S3” or “encrypt an S3 bucket”, but rather S3 will encrypt your data at the object level as it writes to disk in AWS data centers. Developers can choose to encrypt in two ways, via the server-side encryption (SSE) example just described, or client-side encryption (CSE).
Developers may choose CSE when they want more control, and assume responsibility to write code on how to encrypt and decrypt the data, decide on the encryption algorithm, where to get the key, and send the data encrypted from. CSE occurs when the object is encrypted prior to uploading to S3 (thus the keys are not managed by AWS). Developers can implement an Amazon S3 bucket policy that prevents uploading unencrypted objects. If Developer does not need to manage the primary key then they can use server-side encryption with S3-managed encryption keys (SSE-S3) or server-side encryption with AWS KMS-managed keys (SSE-KMS). Amazon S3 protects data at rest using envelope encryption. Each object is encrypted with a unique key employing strong multi-factor encryption. As an additional safeguard, AWS encrypts the key with a AWS KMS key. Amazon S3 server-side encryption uses AES-256 to encrypt data. In Figure 2, the encryption solution protects the encryption key as well as the data. Developers storing data in other channels or cloud providers will be able to utilize similar tools native to them (e.g. Azure Key Vault and GCP Default Encryption).
[block:image] { "images": [ { "image": [ "https://files.readme.io/3b6dfff-Encryption_at_rest.png", "Encryption_at_rest.png", 1270, 958, "#743d2f" ] } ] } [/block] Figure 2: Encryption-at-rest in Amazon S3
For more information, refer to: How to prevent uploads of unencrypted objects to Amazon S3. (opens new window)
# Types of encryption
These are the common types of encryption:
- Symmetric encryption. This utilizes the same key for encryption and decryption. Therefore, both the sender and the receiver must have the same key.
- Asymmetric encryption. This requires that the sender and the receiver use different keys -- a public key and a private key. The public key is shared widely but the private key is protected and used only by its owner. The private key is used to encrypt the data and the public key is used to decrypt the data.
- Envelope encryption. This is the practice of encrypting data with an encryption key, and then encrypting the encryption key with another key.
In general, symmetric key algorithms are faster and produce smaller cipher texts than asymmetric algorithms. But asymmetric algorithms provide inherent separation of roles and easier key management. Envelope encryption lets Developer combine the strengths of both symmetric and asymmetric algorithms. When Developers encrypt Amazon information, the encryption key must also be protected. Envelope encryption helps Developers protect the encryption key itself.
Developers using SSE-KMS can encrypt data using one encryption key and encrypt the encryption key using another key. One key remains in plain text so the client is able to decrypt the encryption key and use the decrypted encryption key to decrypt the data.
The top-level plaintext key is known as the AWS KMS key.
[block:image] { "images": [ { "image": [ "https://files.readme.io/dfd53cc-AWS_KMS_Storing.png", "AWS_KMS_Storing.png", 1037, 202, "#a81e20" ] } ] } [/block] Figure 3: AWS KMS storing and managing the AWS KMS key
For more information, refer to AWS Key Management Service (opens new window).
Key size is important in defining the strength of an encryption key. As required by the Amazon DPP, keys must be at least 128 bits in length. Amazon recommends that Developers use keys larger than 128 bits for Amazon customer PII (256 bits preferred). The additional bits exponentially increase the complexity of a brute force attack against the encryption key. A symmetric 256-bit key requires 2128 times more computational power than a 128-bit key. Developers should rotate their cryptographic keys to further protect their systems. Although larger key sizes are harder to break, an exposed key can render the key size irrelevant, as an unauthorized entity can use the exposed key to access Amazon Information. Specific guidance on key rotation can be found in NIST 800-53 control SC- 12 Cryptographic Key Establishment and Management (opens new window). The SC-12 control and its enhancements can help Developers establish, protect, and rotate keys in a manner that is acceptable for their organization, while ensuring that the keys remain available when required.
# Amazon API Applications acceptable encryption standards
The following is an overview of commonly used and recommended encryption standards that Developers should use:
# Advanced Encryption Standard (AES)
The Advanced Encryption Standard (AES), is a symmetric encryption algorithm that uses a block cipher. The block cipher encrypts a fixed text block to an equal length cipher-text block. AES operates on a fixed-length block of 128 bits in length, with a configurable symmetric key length of 128, 192, or 256 bits. Even with a 128-bit key, the task of cracking AES by checking each of 2128 possible key values (a brute force attack) is so computationally intensive that the fastest supercomputer would require, on average, more than 100 trillion years to do it. If Developers choose to use AES keys, the key size must be AES 128-bit or larger (as required by the Amazon DPP). Amazon recommends using AES-256. Amazon also approves the use of AES-GCM/CBC/XTS.
# Rivest-Shamir-Adlemen Encryption Standard (RSA)
The Rivest-Shamir-Adlemen encryption standard (RSA), is an asymmetric algorithm that uses public key cryptography to share data over an insecure network. RSA factors large integers that are the product of two large prime numbers to establish the key size. It generally uses 1024-bit or 2048-bit keys. A larger key size provides greater security but uses more computational power to encrypt and decrypt information. If Developers choose RSA as their encryption standard, they must ensure that their keys are at least 2048-bit, as required by the Amazon DPP.
# Other encryption algorithms
While other encryption standards are available to Developers, the Amazon DPP requires that Developers use AES or RSA. Table 2 lists Amazon-approved encryption algorithms. If Developers are using other industry-standard encryption algorithms that are not listed in the table below, they should contact [email protected] for consultation.
| Encryption algorithm | Amazon-approved type |
|---|---|
| AES | 256-bit (preferred) 128-bit or larger keys |
| AES with GCM mode | 96-bit cryptographically random initialization vector 128-bit tag length |
| AES with CBC mode | 128-bit cryptographically random initialization vector PKCS7 padding |
| AES with XTS mode | Linux: dm-crypt, LUKS Amazon EBS encryption |
| RSA | 2048-bit or larger keys RSA with OAEP |
Table 2: Amazon API Applications approved encryption algorithms
AWS Software Development Kit (SDK (opens new window)) offers a client-side encryption library that simplifies the implementation of encryption. By default, it implements a framework that keeps your data secure with industry cryptography best practices on how to use unique encryption keys and protecting those keys. The SDK is developed on GitHub open source libraries so that you can analyze the code, submit issues, and find information specific to your implementation.
# Standards not to use
These standards have been researched by the industry and proven insecure:
- DES
- RC4
- RSA-PKCSv1.5 with 1024-bit keys
- RSA-OAEP with 1024-bit keys
- Blowfish
- Twofish
# Best practices for encryption
Here are some best practices for encrypting Amazon Information:
Unprotected data, whether in-transit or at-rest, leaves enterprises vulnerable to attack. Developers should ensure that all data is protected through encryption. Developers should follow these best practices for robust protection of in-transit and at-rest data:
Implement robust network security controls to help protect data in transit. For example, Developers can use firewalls and network access control lists to secure their networks against malware attacks or intrusions.
Implement proactive security measures that identify at-risk data and implement effective data protection for data in transit and at rest. Don’t wait for a security incident to implement security measures.
Choose solutions with policies that enable user prompts and blocks, or that automate encryption of PII data in transit. For example, when files with PII data are attached to an email message, large or sensitive data file sets transferred to external file sharing sites, the application must display a warning or block the action.\
Create polices for systematically categorizing and classifying all Amazon Information.
Ensure appropriate data protection measures are applied while data remains at rest, regardless of where the data is stored.
Generate triggers when unauthorized parties access, use, or transfer any data.
Carefully evaluate public, private, or hybrid cloud providers used for storing Amazon Information, based on the security measures that they offer to secure the data.
Data in transit and at rest have slightly different risk profiles, yet the inherent risk hinges primarily on the sensitivity and value of Amazon Information. Bad actors will attempt to gain access to valuable data in transit or at rest. It is important to classify and categorize data and security protocols to effectively protect Amazon Information at every stage. Steps you can follow:
Classify Amazon Information into sensitivity levels and encrypt the critical data. Amazon customer PII must always be encrypted using Amazon-approved encryption mechanisms.
Establish automated policies that prompt or automate encryption for critical data in transit.
Encrypt and decrypt using a publicly available and peer-reviewed algorithm such as AES and a secret key.
Developers using cloud infrastructures must evaluate cloud vendors based on the security measures they offer and the security compliance certifications they hold.
# Conclusion
All data, especially PII, should be secured with encryption both at rest and in transit. By applying encryption to data that customers have entrusted us with, we can ensure there is no unauthorized parties who can access and misuse the data for malicious purposes. You can accomplish this through mechanisms such as the encryption standards shared here, applying policies, access controls, and other best practices documented for further reading.
# Further reading
For additional information, refer to:
- Data Protection Policy (opens new window)
- Acceptable Use Policy (opens new window)
- Best Practices for Security, Identity & Compliance (opens new window)
- Protect Data in Transit (opens new window)
- Protect Data at Rest (opens new window)
- NIST 800-53 Rev.5: Security and Privacy Controls for Information Systems and Organizations (opens new window)
# Document history
| Date | Description |
|---|---|
| July 2022 | Revised for technical accuracy. |
| January 2020 | First publication |
# Notices
Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.
© 2022 Amazon.com Services LLC or its affiliates. All rights reserved.