Encryption At Rest: designed to protect against physical threat or tempering
Data is stored in shared hardware in an encrypted form, even if somebody has access to hardware it can not access the data in a readable format
General used when one party is involved
Encryption In Transit: aimed to protect data when transferred between 2 places
Generally used when multiple individual/systems are involved
Encryption Concepts
Plaintext: un-encrypted data, can be text, image, other application, etc.
Algorithm: peace of code which takes plaintext and a key and generates encrypted data. Examples of algorithms: Blowfish, AES, RC4, DES, RC5 and RC6
Key: is a password
Ciphertext: when an algorithm takes the plaintext and the key, the output generated is cyphertext (encrypted data)
Symmetric Encryption
Symmetric Keys: the same key can be used for encryption and for decryption as well
Symmetric encryption algorithms: AES-256
Great for encryption at rest, not recommended for encryption in-transit
Asymmetric Encryption
Makes it much easier to exchange keys
Asymmetric algorithms: RSA, ElGamal
Asymmetric Keys: are formed of 2 parts: public key and private key
A public key can be used to generate cyphertext which can only be encrypted by the private key
Asymmetric encryption is used by PGP, SSL, SSH, etc.
Signing
Process used to prove identity of a message
A message can be signed with a private key and verified using the public key
Steganography
A process to hide encrypted data in plaintext data
KMS - Key Management Service
It is a regional and a public service
Let’s us create, store and manage cryptographic keys
Can handle symmetric and asymmetric keys
Can perform cryptographic operations such as encryption and decryption
Keys never leave KMS! Keys can be created, imported but they are locked inside KMS
KMS also provides a FIPS 140-2 (L2) compliance <– REMEMBER THIS
KMS Keys (Formerly known mainly as CMK - Customer Master Keys)
Main things managed by KMS are KMS keys
They are used by KMS in cryptographic operations
They are logical containing the following things: ID, date, policy, description and state
Every KMS key is backed by physical key material. The physical key material can be generated by KMS or imported by KMS
KMS keys can be used to directly encrypt or decrypt data for up to 4KB of data
DEK - Data Encryption Keys
Data Encryption Keys are generated from KMS keys using GenerateDataKey API
These keys can be used to locally encrypt/decrypt data with size larger than 4KB
DEK generated is linked to a specific KMS keys
KMS does not store the DEK in any way, it is generated and provided to the user and it is discarded afterwards
KMS provides 2 version of the key a plaintext and a ciphertext encrypted with the CMK
It is expected from us to discard the plaintext key as soon as we encrypted the data
The encrypted data and the encrypted data encryption key should be stored side by side
For decryption of the data we pass back to KMS the encrypted DEK to be decrypted and with the decrypted key we decrypt the data itself
Key Concepts
KMS keys are isolated to a region and never leave KMS (by default)
KMS also supports multi-region keys, where keys are replicated to other regions
There are 2 types of keys: AWS owned and customer owned. In case of customer owned keys, we can have AWS managed (created automatically) or customer managed keys (created explicitly by the customer)
Customer managed keys are more configurable. For example, we can edit the key policy to allow cross account access to the key
KMS keys support rotation. Rotation is optional for customer managed keys
A KMS key contains the backing key, the physical key material and all previous backing keys caused by rotation => data encrypted with previous keys can still be decrypted
We can create aliases for KMS keys. Aliases are per region
Key policies and security:
Key Policies (Resource): they are different compared to policies other AWS services have in the way that each KMS keys policy has to explicitly allow access from the owner AWS account