- 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
- 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 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
- 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.
- Process used to prove identity of a message
- A message can be signed with a private key and verified using the public key
- A process to hide encrypted data in plaintext data
- 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
- Provides FIPS 140-2 (L2) compliance
- Main things managed by KMS are CMKs
- They are used by KMS in cryptographic operations
- They are logical containing the following things: ID, date, policy, description and state
- Every CMK is backed by physical key material. This can be generated by KMS or imported by KMS
- CMKs can be used to encrypt or decrypt data for up to 4KB of data
- Data Encryption Keys are generated from CMKs 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 CMK
- 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
- CMKs are isolated to a region and never leave KMS
- There are 2 types of CMKs: AWS managed (created automatically) and customer managed (much more configurable, can be accessed by other AWS accounts)
- CMKs support rotation. Rotation is optional for customer managed keys
- CMK contains the current backing key and previous backing keys caused by rotation
- We can create aliases for CMKs
- Key policies and security:
- Key Policies (Resource): similar to an S3 bucket policy
- Every CMK has a key policy