KMS
KMS is a regional service although it’s possible to create multi-region keys that act act copies of the original encryption key.
It provides FIPS 140-2 L3.
Components
-
Keys
-
Key material: the string of bits used in a cryptographic algorithm. Secret key material must be kept secret to protect the cryptographic operations that use it. Public key material is designed to be shared. It can have several possible values for
Key material origin:-
AWS_KMS
-
EXTERNAL
-
AWS_CLOUDHSM
-
EXTERNAL_KEY_STORE
-
-
Aliases
Ciphertext contains information about the key that encrypted it, so there’s no need to specify which key to use for decryption.
Keys
Symmetric or Asymmetric. It contains a reference to the key material used to perform cryptographic operations and some metadata, like ID, key spec, key usage, creation date, description, and key state. They NEVER leave the KMS unencrypted. With multi-region keys you can encrypt data in a region and decrypt it in another.
symmetric keys cannot encrypt plaintext over 4096B, a Data key is needed for that.
Keys management
-
Customer managed keys: keys that the customer creates, owns and manages with full control (establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases that refer to the KMS keys, and scheduling the KMS keys for deletion). They have a monthly cost and are counted against the AWS KMS quotas for the account.
-
AWS managed keys: these keys are created, managed, and used on the user’s behalf by an AWS service integrated with AWS KMS. They come at no cost but you might pay for API usage. You can view them and change their policies but cannot change any properties, rotate them, change their key policies, or schedule them for deletion. You cannot use AWS managed keys in cryptographic operations directly; the service that creates them uses them on your behalf.
-
AWS owned keys: a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. Although AWS owned keys are not in your AWS account, an AWS service can use an AWS owned key to protect the resources in your account. No control over. No cost. No quota.
Key types
-
Symmetric: they use AES-GCM 256bit cryptography. Nothing of these keys ever leaves KMS unencrypted.
-
Asymmetric: Only the publick key part may leave KMS unencrypted.
-
HMAC keys: symmetric keys used to generate and veify Hash-Based Message Authentication Codes (HMAC).
-
Data keys: they can encrpyt over 4096B plaintext and are returned to the user after encryption to be used to decrypt the ciphertext. After encryption, they’re returned in both forms, encrypted and unencrypted so that you can use the unencrypted one to decrypt and optionally store the encrypted one along with the encrypted payload, in the same place. When you need to decrypt you can either decrypt the payload using the unencrypted version directly or unencrypt the key first (using KMS) and then use it to unencrypt the payload. Data keys are not stored in AWS and the unencrypted version is discarded immediately after being returned to the user.
-
Data key pairs: same but for asymmetric encryption. The private key comes in both encrypted and unencrypted forms. The public key is always plaintext.
Security
No AWS principal has any permissions to a KMS key unless that permission is provided explicitly and never denied. There are no implicit or automatic permission to use or manage a KMS key. KMS keys belong to the AWS account in which they were created. However, no identity or principal, including the AWS account root user, has permission to use or manage a KMS key unless that permission is explicitly provided and never denied in a key policy, IAM policy or grant. However, identities who have the kms:CreateKey permission can set the initial key policy and give themselves permission to use or manage the key.
Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key. Without permission from the key policy, IAM policies that allow permissions have no effect. (You can use an IAM policy to deny a permission to a KMS key without permission from a key policy).
Key policies
Key policies are resource policies. They’re the primary way to control access to KMS keys.
Each key has exactly one policy.
Unlike IAM policies, which are global, key policies are Regional. A key policy controls access only to a KMS key in the same Region. It has no effect on KMS keys in other Regions.
Default key policy: If you don’t provide one, AWS KMS creates one for you.
-
when you create a KMS key programmatically: one policy statement that gives the
AWS account(root user) that owns the KMS key permission to use IAM policies to allow access to all AWS KMS operations on the KMS key.
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}-
when you create a KMS key with the AWS Management Console: begins with the policy statement that allows access to the AWS account and enables IAM policies. The console then adds a key administrators statement, a key users statement, and (for most key types) a statement that allows principals to use the KMS key with other AWS services.
Connecting to AWS KMS through a VPC endpoint
When you use an interface VPC endpoint, communication between your VPC and AWS KMS is conducted entirely within the AWS network.
The interface VPC endpoint connects your VPC directly to AWS KMS without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. The instances in your VPC do not need public IP addresses to communicate with AWS KMS.
You can use condition keys such as aws:SourceVpc and aws:SourceVpce to filter incoming calls based on the VPC or the VPC endpoint.