© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Jon Todd – Sr. Software Architect, Okta

October 2015

SEC401

Encryption Key Storage

With AWS KMS at Okta

AWS technologies covered

• AWS Key Management Service (AWS KMS)

• AWS Identity and Access Management (IAM)

• AWS CloudTrail

• AWS SDK for Java

• Amazon Elastic Compute Cloud

(Amazon EC2)

Agenda

• Background

• What’s Okta?

• Encryption use cases

• Why use a key server?

• Okta case study of KMS

• Threat model KMS and Amazon EC2

• Failure mitigation

• Authorization and auditing

• Monitoring and tuning

What is an Okta?

Author: Frasmacon - CC by SA 3.0

A. An 8 legged creature

B. A unit of measure

C. An abbreviation

D. A made-up name for a company

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 2000 customers

Education,

Non-ProfitFinanceTechnologyCloudHealth Services

Manufacturing

, Energy Media Consumer

Used in 185 countries globally

Encryption background

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 application

Requirements:

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

Client Service

+

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

+

Client Service

Master key

EncryptKey Service

DB

Okta case study of AWS KMS

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 GCM

Strong random-number generator

• Separation of duties

By design

Quorum management of servers

• Support auto-scale through secure bootstrapping

Hypervisor bootstraps IAM keys

• Auditability

Encryption context + CloudTrail

Threat model:

AWS KMS and Amazon EC2

+

Client EC2 instance

Master key

EncryptKMS

DB

Data key

Threat model: Amazon EC2 and IAM metadata service

+

Client EC2 instance

Master key

EncryptKMS

DB

Data key

Getting IAM credentials for KMS

• IAM roles for EC2

• Hypervisor provides a per-instance metadata service

• Metadata service is accessible by all users

• Credentials aren’t channel bound

• Credentials are short lived

IAM credentials via metadata service

curl 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

Current Time: 2015-08-20T22:14:52Z

LastUpdated: 2015-08-20T21:17:41Z

Expiration: 2015-08-21T03:22:28Z

Current Time: 2015-08-20T22:29:39Z

LastUpdated: 2015-08-20T22:18:48Z

Expiration: 2015-08-21T04:47:30Z

Threat model: KMS transport

+

Client EC2 instance

Master key

EncryptKMS

DB

Data key

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

+

Client EC2 instance

Master key

EncryptKMS

DB

Data key

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

Low Risk

Low Cost

High Cost

High Risk

DIY

KMS

Cloud HSM

• AWS CloudHSM

• HSM at cost of managing

High Availability (HA)

• DIY

• Roll your own credential

management and rotation

• Separate operational team

• Quorum-based management

• Run high-availability service

• No access to hardware/TPM

Implementing KMS

Implementation goals

• Multiregion support for disaster recovery (DR)

• Mitigate total KMS failure

• Avoid vendor lock-in

• Minimal performance impact

• Operational tools for key rotation

Mapping KMS key hierarchy to Okta key hierarchy

• Region master key

• Provided to service at

run time by operator

• Unique per region

• Encrypts tenant master key

• Tenant master key

• Unique per tenant

• Encrypts tenant data key

• Tenant data key

• Encrypts data

Tradeoffs of an extended key hierarchy

Pros

• Adoptions of KMS is easier and incremental

• KMS data keys are enumerable, allowing rotation

• Local encryption provides more control

• Fewer calls to KMS for encryption

Cons

• Local encryption requires more responsibility

• Sharing ciphertext across services is complex

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

Service

KMS East KMS West

Region master keyRegion master key

Tenant master key

RSA Key

Region master key

DB

September 20th KMS increased error rate

Okta failed-over automatically

KMS requests by region

https://trust.okta.com

Authorization and 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

Auditing

Correlate CloudTrail logs with service logs to detect events

not triggered by the service

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 tuning

kmsClientConfig = new ClientConfiguration()

.withSocketTimeout(3000) // 3 seconds

.withConnectionTimeout(3000) // 3 seconds

.withConnectionTTL(60000) // 1 minute

.withMaxErrorRetry(3);

client = new AWSKMSClient(kmsClientConfig);

Final thoughts

Feature requests for KMS

• Support for multiregion encryption

• Security enhancements

• Transport encryption in addition to TLS

• Tighter access control for IAM credentials in EC2 metadata

service

• Bind IAM credentials to EC2 instance/hypervisor

• PKI features

• KMS storage and rotation for asymmetric keys

• Certificate authority as a service

KMS takeaways

Low Risk

Low Cost

High Cost

High Risk

DIY

KMS

Cloud HSM

• It’s highly available

• It’s simple to get up and running

• Enables separation of duties

• Enables secure scaling

automatically

• Orders of magnitude cheaper

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/polici

es_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

Remember to complete

your evaluations!

Thank you!

Follow me on twitterwww.okta.com@JonToddDotCom

Learn more about Okta