- 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
- KMS also provides a FIPS 140-2 (L2) compliance
- 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
- 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
- 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
- Every KMS keys has a key policy
- KMS keys are very granular