AWS - KMS Enum
KMS - Key Management Service
AWS Key Management Service (AWS KMS) is presented as a managed service, simplifying the process for users to create and manage customer master keys (CMKs). These CMKs are integral in the encryption of user data. A notable feature of AWS KMS is that CMKs are predominantly secured by hardware security modules (HSMs), enhancing the protection of the encryption keys.
KMS uses symmetric cryptography. This is used to encrypt information as rest (for example, inside a S3). If you need to encrypt information in transit you need to use something like TLS.
KMS is a region specific service.
Administrators at Amazon do not have access to your keys. They cannot recover your keys and they do not help you with encryption of your keys. AWS simply administers the operating system and the underlying application it's up to us to administer our encryption keys and administer how those keys are used.
Customer Master Keys (CMK): Can encrypt data up to 4KB in size. They are typically used to create, encrypt, and decrypt the DEKs (Data Encryption Keys). Then the DEKs are used to encrypt the data.
A customer master key (CMK) is a logical representation of a master key in AWS KMS. In addition to the master key's identifiers and other metadata, including its creation date, description, and key state, a CMK contains the key material which used to encrypt and decrypt data. When you create a CMK, by default, AWS KMS generates the key material for that CMK. However, you can choose to create a CMK without key material and then import your own key material into that CMK.
There are 2 types of master keys:
AWS managed CMKs: Used by other services to encrypt data. It's used by the service that created it in a region. They are created the first time you implement the encryption in that service. Rotates every 3 years and it's not possible to change it.
Customer manager CMKs: Flexibility, rotation, configurable access and key policy. Enable and disable keys.
Envelope Encryption in the context of Key Management Service (KMS): Two-tier hierarchy system to encrypt data with data key and then encrypt data key with master key.
Key Policies
These defines who can use and access a key in KMS.
By default:
It gives the AWS account that owns the KMS key full access to the KMS key.
Unlike other AWS resource policies, a AWS KMS key policy does not automatically give permission to the account or any of its users. To give permission to account administrators, the key policy must include an explicit statement that provides this permission, like this one.
Without allowing the account(
"AWS": "arn:aws:iam::111122223333:root") IAM permissions won't work.
It allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.
Without this permission, IAM policies that allow access to the key are ineffective, although IAM policies that deny access to the key are still effective.
It reduces the risk of the key becoming unmanageable by giving access control permission to the account administrators, including the account root user, which cannot be deleted.
Default policy example:
If the account is allowed ("arn:aws:iam::111122223333:root") a principal from the account will still need IAM permissions to use the KMS key. However, if the ARN of a role for example is specifically allowed in the Key Policy, that role doesn't need IAM permissions.
Key Administrators
Key administrator by default:
Have access to manage KMS but not to encrypt or decrypt data
Only IAM users and roles can be added to Key Administrators list (not groups)
If external CMK is used, Key Administrators have the permission to import key material
Rotation of CMKs
The longer the same key is left in place, the more data is encrypted with that key, and if that key is breached, then the wider the blast area of data is at risk. In addition to this, the longer the key is active, the probability of it being breached increases.
KMS rotate customer keys every 365 days (or you can perform the process manually whenever you want) and keys managed by AWS every 3 years and this time it cannot be changed.
Older keys are retained to decrypt data that was encrypted prior to the rotation
In a break, rotating the key won't remove the threat as it will be possible to decrypt all the data encrypted with the compromised key. However, the new data will be encrypted with the new key.
If CMK is in state of disabled or pending deletion, KMS will not perform a key rotation until the CMK is re-enabled or deletion is cancelled.
Manual rotation
A new CMK needs to be created, then, a new CMK-ID is created, so you will need to update any application to reference the new CMK-ID.
To do this process easier you can use aliases to refer to a key-id and then just update the key the alias is referring to.
You need to keep old keys to decrypt old files encrypted with it.
You can import keys from your on-premises key infrastructure .
Other relevant KMS information
KMS is priced per number of encryption/decryption requests received from all services per month.
KMS has full audit and compliance integration with CloudTrail; this is where you can audit all changes performed on KMS.
With KMS policy you can do the following:
Limit who can create data keys and which services have access to use these keys
Limit systems access to encrypt only, decrypt only or both
Define to enable systems to access keys across regions (although it is not recommended as a failure in the region hosting KMS will affect availability of systems in other regions).
You cannot synchronize or move/copy keys across regions; you can only define rules to allow access across region.
Enumeration
Privesc
pageAWS - KMS PrivescPost Exploitation
pageAWS - KMS Post ExploitationPersistence
pageAWS - KMS PersistenceReferences
Last updated