Saturday, 3 February 2018

AWS KMS

Overview
  • Key Management System
  • Alternatives 
    • CloudHSM

Design Goal  ("CIA")
  • Confidentiality - only authorized users can access data
    • Access controls on System and Data should be independent
      • Transparent SSE encryption violates it
        • Acess to data = access to key
    • PARC model:
      • P(rincipal) - user, roles
      • A(ction) - what can user do
      • R(esources)  - on what resource (ARNs)
      • C(onditions) - in what circumstances
    • Encryption
      • Access to data requires access to key
      • It is often easier to reason about access to single key than all the objects protected under that key
  • Integrity - data cannot be changed without detection
    • Authenticated Encryption
  • Availability - data is accessible

Customer Master Key (CMK)
  • AES 256 bit key  (AES-GCM)
  • Default - created for convenience for AWS services on account (e.g. EBS) 
    • cannot be deleted/rotated
    • examples
      • aws/workspaces
      • aws/ses
  • Custom - created manually
    • Alias (friendly name)
    • Optional rotation
    • Can be scheduled for deletion (7-30 days)
    • Max 100 per account (disabled keys also count towards this limit)
    • Can be scheduled for deletion
  • Cannot be exported
  • Can be disabled (prevent any encryption/decryption)
  • Region specific
  • Can encrypt 2^61 objects before hits safety boundaries of AES-GCM
  • Generated in HSA (Hardened Security Appliance) or imported
  • It is not stored in a dedicated host
    • Distributed among various AWS services for Durability/Availability
      • "One of the most durable things in AWS"
    • Stored in encrypted 
      • CMK is encrypted by KMS-managed keys 
      • HSA create their own identity keys (never leave device)
      • When needed CMK is pulled into HSA
        • Decrypts it
        • Flushes it

Data Key
  • Generated by KMS
  • Plain Text and Encrypted version returned
  • Plain Text used to encrypt the data by the client (envelope encryption) and discarded
  • Encrypted is stored along with ciphertext (fate sharing)

Envelope Encryption (Tiered Encryption)
  • Data key generated to encrypt each piece of data - encrypted under master key
  • Bypasses the limit of 4KB for direct encryption

Key Rotation
  • Backing Key - actual secret key
  • CMK is just a logical container for a sequence of backing keys
  • When rotated old backing key is kept for decryption purposes
    • No need to re-encrypt
    • If encryption key is lost -> data is lost

Authenticated Encryption
  • In addition to encrypted ciphertext an authentication tag is returned (MAC)
  • Acts as a signature (nobody tampered with ciphertext)

Encryption Context 
  • Additional Authenticated Data (AAD)
  • Map of Key-Value pairs in plain-text
  • Provided to "Encrypt"/"Decrypt"
    • Must be stored alongside encrypted data
  • Not part of cipher-text but cryptographically bound
  • The signature is calculated over plaint text + AAD
  • Prevents copy&paste ciphertext in different place
  • Visible in CloudTrail so that API call can be attributed properly
    • Do not use sensitive information

Access Control
  • Key Policy 
    • Resource based policy
    • Unlike other AWS services it is mandatory (IAM user policy is not sufficient)
      • KMS will autogenerate one if not specified
    • It is sufficient for access control but may be complemented by IAM policy
    • IAM user can set it when he has "PutKeyPolicy" permission
  • IAM policy (optional)
    • Key policy must give access to AWS account ("/root") to enable IAM policy
      • Additional layer of protection
        • Even IAM "* / *" cannot access key without it
  • Grants (optional)
    • Delegation mechanism (e.g. to AWS Services)
    • Use when you want temporarily allow/deny access
      • Policies are better suited for static assignments
    • Grant token - creation is asynchronous, so token can be passed to enforce grant

How AWS Services uses KMS
  • EC2/EBS model
    • Data keys are stored in hypervisor memory as long as resource in use
    • Permission exists for AWS to re-provision (e.g after power outage)
      • KMS grants visible in CloudTrail
  • S3 model
    • AWS Service may need to make a lot of requests to S3
    • It creates a role in the account that gives it access for longer period of time
      • Restricted as much as possible

AWS Services
  • CloudTrail (S3 model)
    • KMS key must be selected (and its policy must allow CloudTrail usage)
    • Logs delivered to S3 can be encrypted with SSE-KMS (default SSE-S3)
    • GenerateDataKey invoked for every delivery (~every 5 minutes - for each region)
    • Encryption Context
      • CloudTrail ARN
      • S3 Bucket and Path to deliver logs
  • EBS (EC2/EBS model)
    • Volume and Snapshots are encrypted
    • Encryption occurs on EC2 instance (not all instance types support it)
    • Supported on all EBS volume types (standard, gp2, io)
    • Default key created if no custom selected
    • GenerateDataKey created per volume and encrypted version stored on EBS
    • EC2 instance decryptes DataKey and keeps it in memory
    • Encryption Context
      • Volume Id
  • EMR (S3 model)
    • Can be used to encrypt data for EMRFS (S3)
    • SSE-KMS not suported
    • Encryption of HDFS not supported
    • Only client side encryption supported for KMS
    • Encryption Context
      • bucket path
  • Elastic Transcoder
    • SSE-S3, SSE-KMS (default aws/S3 CMK), SSE-KMS (custom CMK)
    • CSE-KMS
    • HLS
      • Each media segment can be encrypted using AES-128 encryption key
      • Player must download the encryption key
  • Redshift
    • 4-tier key architecture
      • data encryption key
        • encrypt blocks in the cluster (1MB)
        • each block assigned random AES-256 key
      • database encryption key (DEK)
        • encrypts data encryption key
        • random AES-256 key stored on disk in a separate network from cluster
      • type
        • KMS
          • cluster encryption key
        • HSM
    • Encryption Context
      • Redshift cluster name
  • RDS (S3 model)
    • Based on EBS encryption
    • Encryption Context
      • RDS database instance
  • SES (S3 model)
    • Encrypts recieved messages (stored in S3)
    • Based on SSE-KMS
    • Must write client to decrypt messages
    • Encryption Context
      • Message Id
  • S3 (S3 model)
  • SQS (S3 model)
  • WorkMail
    • Each message is encrypted using symmetric encryption key
      • generated on the fly (akin to "data key")
    • Internally uses public and private key 
    • Public key is used to encrypt the data key
    • Private key is encrypted with KMS
    • Encrypted symmetric key (with public key), encrypted message and attachments are stored
  • WorkSpaces 
    • Based on EBS encryption
  • Kinesis 

References
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)