S3

S3 [3], one of the oldest services in AWS, is divided into buckets at the top level. A bucket contains folders and objects/files. S3 buckets are also the easiest way to launch a static website in AWS. You drop the files that make up the website into a bucket and then make them available via HTTP(S) with a few clicks. In the past, this occasionally went wrong, because confidential data was accidentally left in the clear on the Internet.

Figure 1 shows the settings for creating a bucket. If encryption is enabled, the user can choose whether the AWS system will use automatically generated data or the data stored in the Key Management Service (KMS) [4]. Encryption applies to the objects in the bucket. By default, public access is also blocked (Figure 2).

Figure 1: Creating an S3 bucket.

Figure 2: Blocking public access in bucket settings.

The admin can also control what kind of encryption applies at the folder level (Figure 3). The last stage is the individual object (a file, for example). The user can set encryption here (if using) along with the encryption method.

Figure 3: The folder encryption options in S3.

Alternatively, you can encrypt the objects locally in S3 before uploading them, so that there is no AWS key capable of decrypting them.

KMS

AWS by default uses keys that are automatically generated on the fly to quickly encrypt data. However, the confidentiality and integrity objectives pertaining to the Amazon admins are still not in place.

If you want more control over the keys, you need to use KMS [4]. In the KMS console, AWS offers a list of implicitly generated keys for encrypting databases. For customer-managed keys that are generated by the admin in the console and then have a policy applied to them, a policy is attached to a key – anyone who uses the key is allowed to do what the policy states.

When you create your own key in KMS using KMS to generate the key, the dialog prompts you to define who can manage the key and who can use it for encryption and decryption. Based on this, the user guide calculates a policy, which it attaches to the key.

Instead of having AWS generate a key, an admin can store an externally generated key. In this case, the console requires the admin to select an algorithm to pack the key before uploading it and a token to unpack the key again (see [5] for an example).

Finally, Amazon offers a CloudHSM cluster [6]. If you choose this option, you are binding several hardware security modules (HSMs) that contain a tamper-proof key; this achieves the highest level of control possible in the cloud.

All requests for encryption are answered by the HSMs; their hardware makes sure that nobody reads the keys. Designed as a cluster, CloudHSM is highly available (the A in CIA) – which is important for people who secure large sections of their infrastructure with HSM.

Due to interchangeable components and API compatibility, taking the big step towards CloudHSM in an architecture does not have to happen at the very beginning of development. In this configuration, the remaining trust topic is that the KMS clients are under the control of AWS (i.e., they store decrypted data in RAM).

VMs with Encrypted Hard Disks

Amazon's EC2 VM service uses S3 for its virtual hard disks, making encryption of the hard disks possible. Linux administrators have been aware of this kind of protection for a long time at the level of encrypted partitions or volumes. This either means that the admin has to enter a password when booting the machine or that the password has to be stored in the bootloader. In the latter case, the data remains unprotected in the event of theft.

The AWS Cloud uses KMS behind the scenes. When an admin creates a new VM, the memory management menu offers the option of encrypting the hard disk (Figure 4). The user keys generated in the selected AWS region appear in the selection list.

Figure 4: Selecting an encryption option in AWS EC2 when creating a VM.

When the VM starts, the hypervisor retrieves the data for decryption. Admins who failed to secure access permissions to the key when it was created are allowed to attach the hard disk to a VM, but are unable to read the data, similar to any other encrypted volume.

Since AWS unfortunately does not provide a console for a Linux VM, the ability to work with Linux on-board tools does not exist for the root volume. If the confidential data resides on a separate partition from the VM, the admin boots the VM in the normal way, manually mounts the volume, and enters the password; this means that the key does not reside in AWS.