How to Enhance the Security of Sensitive Customer Data by Using Amazon CloudFront Field-Level Encryption

Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content to end users through a worldwide network of edge locations. CloudFront provides a number of benefits and capabilities that can help you secure your applications and content while meeting compliance requirements. For example, you can configure CloudFront to help enforce secure, end-to-end connections using HTTPS SSL/TLS encryption. You also can take advantage of CloudFront integration with AWS Shield for DDoS protection and with AWS WAF (a web application firewall) for protection against application-layer attacks, such as SQL injection and cross-site scripting.

Now, CloudFront field-level encryption helps secure sensitive data such as a customer phone numbers by adding another security layer to CloudFront HTTPS. Using this functionality, you can help ensure that sensitive information in a POST request is encrypted at CloudFront edge locations. This information remains encrypted as it flows to and beyond your origin servers that terminate HTTPS connections with CloudFront and throughout the application environment. In this blog post, we demonstrate how you can enhance the security of sensitive data by using CloudFront field-level encryption.

Note: This post assumes that you understand concepts and services such as content delivery networks, HTTP forms, public-key cryptography, CloudFront, AWS Lambda, and the AWS CLI. If necessary, you should familiarize yourself with these concepts and review the solution overview in the next section before proceeding with the deployment of this post’s solution.

How field-level encryption works

Many web applications collect and store data from users as those users interact with the applications. For example, a travel-booking website may ask for your passport number and less sensitive data such as your food preferences. This data is transmitted to web servers and also might travel among a number of services to perform tasks. However, this also means that your sensitive information may need to be accessed by only a small subset of these services (most other services do not need to access your data).

User data is often stored in a database for retrieval at a later time. One approach to protecting stored sensitive data is to configure and code each service to protect that sensitive data. For example, you can develop safeguards in logging functionality to ensure sensitive data is masked or removed. However, this can add complexity to your code base and limit performance.

Field-level encryption addresses this problem by ensuring sensitive data is encrypted at CloudFront edge locations. Sensitive data fields in HTTPS form POSTs are automatically encrypted with a user-provided public RSA key. After the data is encrypted, other systems in your architecture see only ciphertext. If this ciphertext unintentionally becomes externally available, the data is cryptographically protected and only designated systems with access to the private RSA key can decrypt the sensitive data.

It is critical to secure private RSA key material to prevent unauthorized access to the protected data. Management of cryptographic key material is a larger topic that is out of scope for this blog post, but should be carefully considered when implementing encryption in your applications. For example, in this blog post we store private key material as a secure string in the AWS Systems Manager Parameter Store. The Parameter Store provides a centralized location for managing your configuration data such as plaintext data (such as database strings) or secrets (such as passwords) that are encrypted using AWS Key Management Service (AWS KMS). You may have an existing key management system in place that you can use, or you can use AWS CloudHSM. CloudHSM is a cloud-based hardware security module (HSM) that enables you to easily generate and use your own encryption keys in the AWS Cloud.

To illustrate field-level encryption, let’s look at a simple form submission where Name and Phone values are sent to a web server using an HTTP POST. A typical form POST would contain data such as the following.

POST / HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length:60

Name=Jane+Doe&Phone=404-555-0150

Instead of taking this typical approach, field-level encryption converts this data similar to the following.

POST / HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1713

Name=Jane+Doe&Phone=AYABeHxZ0ZqWyysqxrB5pEBSYw4AAA...

To further demonstrate field-level encryption in action, this blog post includes a sample serverless application that you can deploy by using a CloudFormation template, which creates an application environment using CloudFront, Amazon API Gateway, and Lambda. The sample application is only intended to demonstrate field-level encryption functionality and is not intended for production use. The following diagram depicts the architecture and data flow of this sample application.

Sample application architecture and data flow

Here is how the sample solution works:

1. An application user submits an HTML form page with sensitive data, generating an HTTPS POST to CloudFront.
2. Field-level encryption intercepts the form POST and encrypts sensitive data with the public RSA key and replaces fields in the form post with encrypted ciphertext. The form POST ciphertext is then sent to origin servers.
3. The serverless application accepts the form post data containing ciphertext where sensitive data would normally be. If a malicious user were able to compromise your application and gain access to your data, such as the contents of a form, that user would see encrypted data.
4. Lambda stores data in a DynamoDB table, leaving sensitive data to remain safely encrypted at rest.
5. An administrator uses the AWS Management Console and a Lambda function to view the sensitive data.
6. During the session, the administrator retrieves ciphertext from the DynamoDB table.
7. The administrator decrypts sensitive data by using private key material stored in the AWS Systems Manager Parameter Store.
8. Decrypted sensitive data is transmitted over SSL/TLS via the AWS Management Console to the administrator for review.

Deployment walkthrough

The high-level steps to deploy this solution are as follows:

1. Stage the required artifacts
   When deployment packages are used with Lambda, the zipped artifacts have to be placed in an S3 bucket in the target AWS Region for deployment. This step is not required if you are deploying in the US East (N. Virginia) Region because the package has already been staged there.
2. Generate an RSA key pair
   Create a public/private key pair that will be used to perform the encrypt/decrypt functionality.
3. Upload the public key to CloudFront and associate it with the field-level encryption configuration
   After you create the key pair, the public key is uploaded to CloudFront so that it can be used by field-level encryption.
4. Launch the CloudFormation stack
   Deploy the sample application for demonstrating field-level encryption by using AWS CloudFormation.
5. Add the field-level encryption configuration to the CloudFront distribution
   After you have provisioned the application, this step associates the field-level encryption configuration with the CloudFront distribution.
6. Store the RSA private key in the Parameter Store
   Store the private key in the Parameter Store as a SecureString data type, which uses AWS KMS to encrypt the parameter value.

Deploy the solution

1. Stage the required artifacts

(If you are deploying in the US East [N. Virginia] Region, skip to Step 2, “Generate an RSA key pair.”)

Stage the Lambda function deployment package in an Amazon S3 bucket located in the AWS Region you are using for this solution. To do this, download the zipped deployment package and upload it to your in-region bucket. For additional information about uploading objects to S3, see Uploading Object into Amazon S3.

2. Generate an RSA key pair

In this section, you will generate an RSA key pair by using OpenSSL:

1. Confirm access to OpenSSL.

   $ openssl version

   You should see version information similar to the following.

   OpenSSL <version> <date>

2. Create a private key using the following command.

   $ openssl genrsa -out private_key.pem 2048

   The command results should look similar to the following.

   Generating RSA private key, 2048 bit long modulus

   ................................................................................+++

   ..........................+++

   e is 65537 (0x10001)

3. Extract the public key from the private key by running the following command.

   $ openssl rsa -pubout -in private_key.pem -out public_key.pem

   You should see output similar to the following.

   writing RSA key

4. Restrict access to the private key.$ chmod 600 private_key.pem Note: You will use the public and private key material in Steps 3 and 6 to configure the sample application.

3. Upload the public key to CloudFront and associate it with the field-level encryption configuration

Now that you have created the RSA key pair, you will use the AWS Management Console to upload the public key to CloudFront for use by field-level encryption. Complete the following steps to upload and configure the public key.

Note: Do not include spaces or special characters when providing the configuration values in this section.

1. From the AWS Management Console, choose Services > CloudFront.
2. In the navigation pane, choose Public Key and choose Add Public Key.
   

Complete the Add Public Key configuration boxes:

• Key Name: Type a name such as DemoPublicKey.
• Encoded Key: Paste the contents of the public_key.pem file you created in Step 2c. Copy and paste the encoded key value for your public key, including the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- lines.
• Comment: Optionally add a comment.

3. Choose Create.
4. After adding at least one public key to CloudFront, the next step is to create a profile to tell CloudFront which fields of input you want to be encrypted. While still on the CloudFront console, choose Field-level encryption in the navigation pane.
5. Under Profiles, choose Create profile.
   

Complete the Create profile configuration boxes:

• Name: Type a name such as FLEDemo.
• Comment: Optionally add a comment.
• Public key: Select the public key you configured in Step 4.b.
• Provider name: Type a provider name such as FLEDemo.
  This information will be used when the form data is encrypted, and must be provided to applications that need to decrypt the data, along with the appropriate private key.
• Pattern to match: Type phone. This configures field-level encryption to match based on the phone.

6. Choose Save profile.
7. Configurations include options for whether to block or forward a query to your origin in scenarios where CloudFront can’t encrypt the data. Under Encryption Configurations, choose Create configuration.
   

Complete the Create configuration boxes:

• Comment: Optionally add a comment.
• Content type: Enter application/x-www-form-urlencoded. This is a common media type for encoding form data.
• Default profile ID: Select the profile you added in Step 3e.

8. Choose Save configuration

4. Launch the CloudFormation stack

Launch the sample application by using a CloudFormation template that automates the provisioning process.

To finish creating the CloudFormation stack:

1. Choose Next on the Select Template page, enter the input parameters and choose Next.
   Note: The Artifacts configuration needs to be updated only if you are deploying outside of us-east-1 (US East [N. Virginia]). See Step 1 for artifact staging instructions.
2. On the Options page, accept the defaults and choose Next.
3. On the Review page, confirm the details, choose the I acknowledge that AWS CloudFormation might create IAM resources check box, and then choose Create. (The stack will be created in approximately 15 minutes.)

5. Add the field-level encryption configuration to the CloudFront distribution

While still on the CloudFront console, choose Distributions in the navigation pane, and then:

1. 1. In the Outputs section of the FLE-Sample-App stack, look for CloudFrontDistribution and click the URL to open the CloudFront console.
   2. Choose Behaviors, choose the Default (*) behavior, and then choose Edit.
   3. For Field-level Encryption Config, choose the configuration you created in Step 3g.
      
   4. Choose Yes, Edit.
   5. While still in the CloudFront distribution configuration, choose the General Choose Edit, scroll down to Distribution State, and change it to Enabled.
   6. Choose Yes, Edit.

6. Store the RSA private key in the Parameter Store

In this step, you store the private key in the AWS Systems Manager Parameter Store as a SecureString data type, which uses AWS KMS to encrypt the parameter value. For more information about AWS KMS, see the AWS Key Management Service Developer Guide. You will need a working installation of the AWS CLI to complete this step.

1. Store the private key in the Parameter Store with the AWS CLI by running the following command. You will find the <KMSKeyID> in the KMSKeyID in the CloudFormation stack Outputs. Substitute it for the placeholder in the following command.

   $ aws ssm put-parameter --type "SecureString" --name /cloudfront/field-encryption-sample/private-key --value file://private_key.pem --key-id "<KMSKeyID>"
   
   ------------------
   |  PutParameter  |
   +----------+-----+
   |  Version |  1  |
   +----------+-----+

2. Verify the parameter. Your private key material should be accessible through the ssm get-parameter in the following command in the Value The key material has been truncated in the following output.

   $ aws ssm get-parameter --name /cloudfront/field-encryption-sample/private-key --with-decryption
   
   -----…
   
   ||  Value  |  -----BEGIN RSA PRIVATE KEY-----
   MIIEowIBAAKCAQEAwGRBGuhacmw+C73kM6Z…….

   Notice we use the —with decryption argument in this command. This returns the private key as cleartext.

   This completes the sample application deployment. Next, we show you how to see field-level encryption in action.

3. Delete the private key from local storage. On Linux for example, using the shred command, securely delete the private key material from your workstation as shown below. You may also wish to store the private key material within an AWS CloudHSM or other protected location suitable for your security requirements. For production implementations, you also should implement key rotation policies.

   $ shred -zvu -n  100 private*.pem
   
   shred: private_encrypted_key.pem: pass 1/101 (random)...
   shred: private_encrypted_key.pem: pass 2/101 (dddddd)...
   shred: private_encrypted_key.pem: pass 3/101 (555555)...
   ….

Test the sample application

Use the following steps to test the sample application with field-level encryption:

1. Open sample application in your web browser by clicking the ApplicationURL link in the CloudFormation stack Outputs. (for example, https:d199xe5izz82ea.cloudfront.net/prod/). Note that it may take several minutes for the CloudFront distribution to reach the Deployed Status from the previous step, during which time you may not be able to access the sample application.
2. Fill out and submit the HTML form on the page:
   1. Complete the three form fields: Full Name, Email Address, and Phone Number.
   2. Choose Submit.
      
      Notice that the application response includes the form values. The phone number returns the following ciphertext encryption using your public key. This ciphertext has been stored in DynamoDB.
      
      
3. Execute the Lambda decryption function to download ciphertext from DynamoDB and decrypt the phone number using the private key:
   1. In the CloudFormation stack Outputs, locate DecryptFunction and click the URL to open the Lambda console.
   2. Configure a test event using the “Hello World” template.
   3. Choose the Test button.
4. View the encrypted and decrypted phone number data.
   

Summary

In this blog post, we showed you how to use CloudFront field-level encryption to encrypt sensitive data at edge locations and help prevent access from unauthorized systems. The source code for this solution is available on GitHub. For additional information about field-level encryption, see the documentation.

If you have comments about this post, submit them in the “Comments” section below. If you have questions about or issues implementing this solution, please start a new thread on the CloudFront forum.

– Alex and Cameron

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.