This document discusses Okta's use of AWS KMS for encryption key management. It provides background on Okta as a company and describes their requirements for encryption. It then details Okta's implementation of AWS KMS for encrypting user data, including how they structure encryption keys and handle failures. The document also addresses authorization, auditing, performance tuning and rollout considerations for using AWS KMS.
3. 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
4. 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
5. What is Okta?
Okta is the foundation for secure connections
between people and technology.
6. 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
7. More than 2000 customers
Education,
Non-ProfitFinanceTechnologyCloudHealth Services
Manufacturing
, Energy Media Consumer
12. 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
14. 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
+
15. Where do we get the keys from?
• At server startup
• Environment variable
• File
• At run time
• Over JMX + TLS
• Over SSH
• Key service
16. 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
Encrypt
Key Service
DB
22. Threat model: Amazon EC2 and IAM metadata service
+
Client EC2 instance
Master key
Encrypt
KMS
DB
Data key
23. 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
25. 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
26. Threat model: KMS transport
+
Client EC2 instance
Master key
Encrypt
KMS
DB
Data key
27. 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
30. 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
32. Implementation goals
• Multiregion support for disaster recovery (DR)
• Mitigate total KMS failure
• Avoid vendor lock-in
• Minimal performance impact
• Operational tools for key rotation
33. 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
34. 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
36. 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
40. 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
50. 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
51. 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
52. 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