KMS at Okta - Intermediate Level

Jon Todd - @JonToddDotCom

Encryption Key Storagewith AWS KMS at OktaDecember 2015

1 Background

• Okta• Encryption• Why use a key server?

2 KMS Evaluation 3 Implementation

What is Okta?Okta is the foundation for secure

connections between people and technology.

One platform, many use cases

Centralized management of every user, app, device

www.okta.com

IT

Enterprise-grade security built directly into your cloud apps

developer.okta.com

Developers

More than 3000 customersEducation,Non-ProfitFinanceTechnologyCloudHealth Services

Manufacturing, Energy Media Consumer

Used in 185 countries globally

Our Stackstackshare.io/okta/okta

Encryption

Encryption use cases• Fundamental

• Confidentiality• Authenticity

• Practical• Compliance• Least privilege principle

The problem with encryption

Managing these

Alternative approaches to confidentiality• Use cases for hashing instead of encryption

• Authentication• Correlation

• Use cases without needing keys• Homomorphic applications

• Ordering, range query (for example, CryptDB)• Only require encrypt

• Use asymmetric crypto• Trust No One (client encryption scenarios)

• File storage or password vault

Why use a key server?

Example applicationRequirements:1. Data in database is

encrypted at rest and in memory

2. Encryption keys reside only in memory

3. Service has access to the plaintext data

Where do we get the keys from?

• At server startup• Environment variable• File

• At run time• Over JMX + TLS• Over SSH

• Key service

Key service

• Separation of duties• Auditable• Easy rotation of master key• Data key in memory for very short period• Centralized master key never leaves key service

1 Background

• Requirements• How KMS works• KMS threat model

2 KMS Evaluation 3 Implementation

Encryption use cases• Privacy of user data

• Protection of PII, PCI, PHI• Credential storage

• SAML keys• OAuth tokens• Third-party application credentials

Requirements• Strong encryption

256 bit AES GCMStrong random-number generator

• Separation of dutiesBy designQuorum management of servers

• Support auto-scale through secure bootstrappingHypervisor bootstraps IAM keys

• AuditabilityEncryption context + CloudTrail

How KMS works

KMS Operations• randomKey = generateDataKey(keyId, encryptionCtx)• ciphertext = encrypt(plaintext, keyId, encryptionCtx)• plaintext = decrypt(ciphertext, keyId, encryptionCtx)

No plaintext!

Threat model: KMS with EC2

Getting IAM credentials for KMS• Credentials granted via IAM Role• Hypervisor provides a per-instance metadata service• Security considerations

• Metadata service is accessible by all users• Credentials aren’t channel bound• Credentials are short lived

IAM credentials via metadata servicecurl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyApp

{ "Code" : "Success", "LastUpdated" : "2015-08-20T21:17:41Z", "Type" : "AWS-HMAC", "AccessKeyId" : “SOME_ACCESS_ID", "SecretAccessKey" : ”SOME_SECRET_ACCESS_KEY", "Token" : “SOME_SIGNED_TOKEN", "Expiration" : "2015-08-21T03:22:28Z"}

IAM credential rotation• Credentials expire in ~ 6 hours• Credentials are rotated every ~ 1 hour

Threat model: KMS transport

Transport Security• TLS for confidentiality and authentication of server

• “A” rating on Qualys SSL Labs• Disallowed protocols SSL2 & SSL3• Supported protocols TLS 1.0, 1.1, 1.2• Forward secrecy required• Verisign root CA

• IAM Signature V4 for authN and authZ of client

Threat model: KMS

KMS key hierarchy

• CMK – Customer master key• HSA – Hardened security appliance• EKT – Exported key token• HBK – HSA backing key• CDK – Customer data key• CT – Customer token

Source: KMS Cryptographic Details

Threat model – final comparison• AWS CloudHSM

• HSM at cost of managing High Availability (HA)

• Low performance• DIY

• Roll your own credential management and rotation

• Separate operational team• No access to hardware/TPM

1 Background

• Goals• Failure mitigation• Authorization & auditing• Rollout & tuning

2 KMS Evaluation 3 Implementation

Implementation goals• Multiregion support for disaster recovery (DR)• Mitigate total KMS failure• Avoid vendor lock-in• Minimal performance impact• Operational tools for key rotation

Failure mitigation

Multiregion encryption and decryption• Encrypt & store tenant key

encrypted by each region key• Decrypt talks to closest KMS

region• RSA public key used for encrypt

only • Private key provided to service

only in event of KMS outage

September 20th KMS increased error rate

Okta failed-over automaticallyKMS requests by region

https://trust.okta.com

Authorization & auditing

Encryption context• Features:

• Additional authenticated data (AAD) via AES GCM• Logging – Understand why the key was accessed• Authorization – Fine-grained access control to

data keys• Okta’s implementation

• Type: <ServiceName>.<EntityName>• Id: <EntityId>

• A good encryption context identifies or classifies• Think carefully about mutability and storage of context• Encryption context shouldn’t contain sensitive data

Granular decryption policy{ "Effect":"Allow”, "Principal":{"AWS":"arn:...:DirectoryAppRole"}, "Action":"kms:Decrypt", "Condition":{ "StringEquals”:{ "kms:EncryptionContext:type": ”DirectoryService:SensitiveObject” } }}

CloudTrail

Rollout and tuning

Rollout and TTL tuning

TuningGradual rollout

Performance

Region failovers• ~ 0.001% failure rate without tuning HttpClient retries• At retry value of 3, failure rate is negligible

SDK client tuningkmsClientConfig = new ClientConfiguration() .withSocketTimeout(3000) // 3 seconds .withConnectionTimeout(3000) // 3 seconds .withConnectionTTL(60000) // 1 minute .withMaxErrorRetry(3);

client = new AWSKMSClient(kmsClientConfig);

Final thoughts

Implementation recommendations• You may not need encryption or keys

for confidentiality• Put thought into encryption context• Reconcile CloudTrail logs with

application logs• Tune the SDK for timeout and retries• Consider an extended key hierarchy

Reference

• User-Based and Resource-Based Permissions – http://docs.aws.amazon.com/IAM/latest/UserGuide/policies_permissions.html#TypesPermissions

• AWS Key Management Service Cryptographic Details – https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

• KMS Developer Guide – http://docs.aws.amazon.com/kms/latest/developerguide/kms-dg.pdf

Okta for developersUniversal Directory

Single Sign-On

Provisioning

Adaptive Multi-factor Authentication

Social Authentication

Inbound Federation

AD and LDAP Integration

Thank You.

Find me on twitterwww.okta.com@JonToddDotCom

Learn more about Okta