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.

1. © 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

2. 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)

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

8. Used in 185 countries globally

9. Encryption background

10. Encryption use cases
• Fundamental
• Confidentiality
• Authenticity
• Practical
• Compliance
• Least privilege principle

11. The problem with encryption
Managing these 

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

13. Why use a key server?

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

17. Okta case study of AWS KMS

18. Encryption use cases
• Privacy of user data
• Protection of PII, PCI, PHI
• Credential storage
• SAML keys
• OAuth tokens
• Third-party application credentials

19. 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

20. Threat model:
AWS KMS and Amazon EC2

21. +
Client EC2 instance
Master key
Encrypt
KMS
DB
Data key

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

24. 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"
}

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

28. Threat model: KMS
+
Client EC2 instance
Master key
Encrypt
KMS
DB
Data key

29. 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

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

31. Implementing KMS

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

35. Failure mitigation

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

37. September 20th KMS increased error rate

38. Okta failed-over automatically
KMS requests by region
https://trust.okta.com

39. Authorization and auditing

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

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

42. CloudTrail

43. Auditing
Correlate CloudTrail logs with service logs to detect events
not triggered by the service

44. Rollout and tuning

45. Rollout and TTL tuning
TuningGradual rollout

46. Performance

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

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

49. Final thoughts

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

53. 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

54. Remember to complete
your evaluations!

55. Thank you!
Follow me on twitter
www.okta.com@JonToddDotCom
Learn more about Okta