Encryptions/Data Protection

1. Cipher Suite: client sends SSL/TLS version and supported cipher suites, server sends back server cert and public key

2. Authentication: client validates server cert with CA and verifies server has public key

3. Key Exchange: client generates public key encrypted pre-master key and sends data

Using the private key to "sign" a message, then using the public key to verify that it was its corresponding private key that signed it

• Hash function turns your data into a fix length value

• Use case

  • Sending the hash value of the password so that the password is not actually stored on server

  • Check see if data has been altered

• Digital signing a hash to make sure has is not altered

Encrypting the key that is used to encrypt your data; how SSE-S3 works

• Supports automatic rotation through Lambda

• Directly integrate with some AWS products like RDS

  • Which allows you to automatically rotate DB password and because it integrates with RDS directly, updating password is done for you

• Applications can retrieve secrets by calling the Secrets Manager SDK or API

• Since RDS is backed by EBS, RDS supports EBS volume encryption

• Encryption cannot be removed once added

• Oracle supports integration with CloudHSM

• Transparent Data Encryption

• Encryption is handled within the DB engine; data is secured the moment it is written

• Supported on RDS SQL and Oracle DB types

• Generate-db-auth-token: creates a token with 15 min validity which can be used in place of a DB user password

• IAM policies are used to map IAM identities to DB users

• Authorization is handled by the DB engine

• Communication to Dynamo DB Endpoint is HTTPS

  • If data sent from user/CLI/Console/API, plaintext inside https tunnel

  • If data sent from encryption client, cipher text inside tunnel

• Between Endpoint and the Table, not HTTPs. Either plaintext or cipher text depending on above source

• Encryption at rest is mandatory

• Streams, global tables, backups are all encrypted and use the same key as table

• If a table uses CMK but that CMK is disabled or inaccessible for 7 days, that table is baked up and archived. To restore it you have to present the key.

• Requires 8+ free IP addresses per subnet you plan to deploy a LB node in

• Different listeners can have different SSL certs

• Set of ciphers and protocols; when a server and client are setting up the SSL connection, client sends a cipher suite. Security policy tells what a load balancer can use from that cipher suite

• Default ELBSecurityPolicy-2016-08

Key = key metadata + key material

• Accessed through KMS specific APIs, not industry standards

• Regional and Public service

• When you delete a KMS generated key, it is mark for deletion for some time between 7-30 days. It is NOT immediately deleted

• Perform cryptographic operations (encrypt and decrypt) inside KMS so key never leaves KMS

• Provides FIPS 140-2 Level 2

• 50,000 GenerateDataKey API calls per second across us-east-1, us-west-2, eu-west-1

• 10,000 across us-east-2, ap-southeast-1&2, ap-northeast-1, eu-central-1, eu-west-1

• 5500 for all other regions

• Contains Key ID, date, key policy, and state

• Key encryption keys (aka KMS key) can be used for up to 4KB of data

• Data encryption key

• GenerateDataKey - works on > 4KB

• It is generated using one of the keys KMS manages

• Symmetric key

• When DEK is generated, KMS generates plaintext for you to encrypt your data with (you do the encryption yourself)

• KMS also provides a ciphertext version of your key for you to store with the encrypted data

• When time to decrypt, you pass the ciphertext key to KMS and KMS does the decryption of just the key, and you take that and decrypt the rest of the data

• AWS Managed Keys

  • Rotation required (once per year)

  • One per service per region

  • Cannot be used outside of the service of what it is created for

  • Key policy cannot be customized or changed

• Customer Managed Key

  • More control such as key policy

  • Key policy has the ability to distrust an account entirely; meaning even the full admin access users can be denied

  • Supports cross-account access

  • Rotation is default but can be disabled

• Can be deleted immediately but only deletes the key material. The key and metadata is kept to allow you to rotate the key because you can import a new key material but keep the same container

• Manual key rotation

• Use case: regulation, standardization across hybrid env

• No portability: does not allow decryption outside of AWS

• Cannot be restored after deletion period

• Cannot be immediately deleted

• RSA - encrypt/decrypt OR signing and verification

• Elliptic Curve (ECC) - signing and verification

• SM2 (only China region) - encrypt/decrypt OR signing and verification

• Open source client side encryption library; can utilize KMS or not

• Available in C, .NET, CLI, Java, Javascript, Python

• Handles data keys and wrapping keys

• Handles message formatting

• Depending on your application, if you need high rate of generation of DEK, you might hit rate limit

• CMC allows you to cache the DEK so that you don't reach limit of API calls

• Can set max age threshold, max message encrypted, max bytes encrypted

• Grants allow permissions on 1 KMS key

• Ideal for temporary access and least permission access (where as key policies are long term)

• Generally used by AWS services which us KMS

• Only grant permission, no DENY

• Eventual consistency - up to 5 minute propagation delay which can cause AccessDeniedError

if you try to do something a grant does not allow

• You can choose to have a multi-region key upon key creation

• Primary key in a primary region is replicated to other regions

• Primary and Replica keys can be promoted/demoted

• Same key ID

• These are independent keys and merely replicas (i.e., the keys can be independently managed and have different enablement state, descriptions, tags, etc.)

• Benefits

  • Decreases latency

  • DR

  • Active-Active application

  • Digital signing

• Keys can be interacted with KMS API but encryption operations are done on CloudHSM

• No shared HSMs

• Only support symmetric keys, no multi-region, no auto key rotation

• 1 CloudHSM supports one custom key store

• Passing an additional variable (hence, context) when encrypt/decrypt to ensure the integrity of data

• For example, in a table, there is nothing preventing the same field of ciphertext replacing other fields. But if it was done through encryption context, even if the ciphertext was replaced, it would not be able to be decrypted because the corresponding variable would be different

• A single tenant HSM (shared hardware)

• A temper resistant hardware that AWS has no access to, it is customer managed

• Fully FIPS 140-2 Level 3 compliant

• Launched in a specific CloudHSM VPC managed by AWS

• One AZ by default, you can create a cluster and make it multi AZ

• PKCS#11

• Java Cryptography Extensions (JCE)

• Microsoft CryptoNG (CNG) Library

• Customer generate and manages keys

• End user provides both key and objects to S3

• Hash of the key is taken by S3 and attach it to the key after encryption, key is discarded after

• S3 generates and manage a root key (KEK) and specific object encryption key (DEK)

  • Root key and object key are rotated and managed by S3, no visibility to end user

  • Root key is used to encrypt the object keys

• NO control on how often the key is rotated, who has access to specific key (no key policies)

• KMS generates/manages root key and generates data encryption key that it passes to S3 to use as object keys

• Allows specific key policies so even someone with full S3 admin permissions may not be able to decrypt everything

time limited key encryption key that is passed to S3 which is then used to create DEK (essentially offload operation to S3 instead of KMS)