Encryptions/Data Protection

Three stages of SSL/TLS

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

Signing

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

Hashing

* 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

Envelop Encryption

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

**Secrets Manager**

* 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

RDS data protection

* Since RDS is backed by EBS, RDS supports **EBS volume encryption**
* Encryption cannot be removed once added
* Oracle supports integration with CloudHSM

TDE

* 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

\

RDS Authentication

* **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

DynamoDB Encryption

* 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.

Load balancer

* Requires 8+ free IP addresses per subnet you plan to deploy a LB node in
* Different listeners can have different SSL certs

Security policies

* 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 component

Key = key metadata + key material

KMS

* 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==

DEK

* 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 key vs CMK

* **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

Imported key

* 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

Generated key

* Cannot be restored after deletion period
* Cannot be immediately deleted

Asymmetric keys (3 types)

* __**RSA**__ - encrypt/decrypt OR signing and verification
* __**Elliptic Curve (ECC)**__ - signing and verification
* __**SM2**__ (only China region) - encrypt/decrypt OR signing and verification

**Encryption SDK**

* __**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

**Cryptographic Materials Cache**

* 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

* 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**

**ValidationError**

 if you try to do something a grant does not allow

**Multi-region keys**

* 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

**Custom Key Stores**

* 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

**Encryption Context**

* 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

CloudHSM

* 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

CloudHSM APIs (3)

* PKCS#11
* Java Cryptography Extensions (JCE)
* Microsoft CryptoNG (CNG) Library

**SSE-C**

* 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 

SSE-S3 (AES 256)

* **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)

SSE-KMS

* 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

bucket key

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)