Key Management - One Perspective

1. Key Management - One Perspective 18 May 2009 “Encryption is easy. Key management is hard. Really hard. The difficulty arises not from the complexity of keys and encryption schemes, approaches to them, or their applications, but from the impacts of encrypted data to operational systems and procedures. One perspective on key management provides insight into implementing encrypted data storage in a typical n-tiered system and identifying the impacted concerns with appropriate implementation strategies for mitigating them.” I’m not paranoid – everybody IS after me!

2. Introduction and Scope OK, let’s call this slide the “Disclaimer…” The information and insights provided here are an attempt at abstracting the lessons learned from an architectural and implementation effort of a PCI DSS-compliant n-tiered system. This information is a single perspective on the very broad topic of key management. The perspective is limited to the concerns of:▪ Symmetric encryption of stored data▪ Producers and Consumers of data in an n-tiered system▪ N-tiered system performance▪ Complete encryption key lifecycle management I’m not paranoid – everybody IS after me!

3. Objective • Why is there a need manage encryption keys • What does managing of encryption keys entail • How does key management impact n-tiered systems • How to mitigate key management impacts to n-tiered systems • Resources Word of the Day: “Re-cryption”: The act of decrypting data with one key and encrypting it with a different key. I’m not paranoid – everybody IS after me!

4. Keys – Why? This is a trivialization but… Encoding is an obfuscation of data whereby anyone who knows the algorithm can “encode” and “decode” data. Encryption is an obfuscation of data whereby everyone knows the algorithm to “encrypt” and “decrypt” data, but only those who know the key used to encrypt the data can actually decrypt it. So… (and without an argument on complexity) If you’re using encoding and your algorithm is compromised, you need to recode your system to re-protect your data. If you’re using encryption and your key is compromised, you only need to change the value of your key to re-protect your data. Therefore … (you’re using encryption – right?) You need a mechanism for changing keys and “re-crypting” data, otherwise you’re no better off than using encoding because changing your key is invasive – Welcome to Key Management I’m not paranoid – everybody IS after me!

5. Key Management – What is it? Assuming that you’ve selected an appropriate, well vetted symmetric encryption technology, managing the keys that will be used to perform encryption and decryption is comprised of: • Creation of keys • Storage of keys • Key lifetime (cryptoperiod) • Access of keys for encryption/decryption • Execution of the key lifecycle • Auditing of key lifecycle • Managing a compromise of a key or set of keys I’m not paranoid – everybody IS after me!

6. Key Management – I Creation of keys: Look for a cryptographic library that provides for generation of keys. That will help you avoid having to manage multiple parties with independent key parts (think of the guys with the two keys to arm the nukes in a submarine). This way the keys can be generated by the system and humans will never know them. Storage of keys: You’ll need at least two keys: • One for encrypting data (called a DEK for Data Encryption Key) • One for encrypting the storage of the DEK (called a KEK for Key Encryption Key) • The DEK and the KEK will need to be stored on separate physical systems so that if one if compromised, the other is not • You might want to think about some kind of encryption or obfuscation of your KEK, but that is not a requirement from a strict PCI standpoint Key lifetime (Cryptoperiod) Keys should have a usage period and lifetime akin to data retention period. I’m not paranoid – everybody IS after me!

7. Key Management – II Access of keys for encryption/decryption: You’ll need to decide on how keys are accessed considering: • Keys will need to be transmitted across components of your system do to the physical separation of DEK and KEK storage • Do you embed the crypto routines in the tier using them or do you provide a crypto service, in which case you’ll need to consider how data is securely exchanged between application code and crypto services Execution of key lifecycle: Keys have the following states at a minimum: • Current (NIST: Active) – used to encrypt and decrypt data • Retired (NIST: Deactivated) – used to only to decrypt data • Expired (NIST: Compromised) – used only to decrypt data of a compromised key • Deleted (NIST: Destroyed) – historical reference to a key that no longer exists You’ll want to automate the key state transitions in accordance with your key lifetime policy. This is especially true if your data retention period is longer that your combined current and retired key lifetimes as you’ll need to be re-crypting. Make sure that key state transition operations are atomic! (Well, at least from the perspective of the caller) I’m not paranoid – everybody IS after me!

8. Key Management – III Auditing of the key lifecycles: You need to audit state transitions of keys. This is one of the compelling reasons for storing your keys in a database. So, build a data model that lets you store information about keys. Managing a compromise: If you have evidence that a some un-trusted entity has gained access to a key or set of keys, you’ll want an interface to initiate the transition of the suspect-keys to the compromised state and then initiate a re-cryption of data that was using those keys. If the keys that were compromised are all retired keys, the current key can be used to re-crypt. If the current key is compromised, a new current key will need to be created to be used for re-cryption. I’m not paranoid – everybody IS after me!

9. Key Lifecycle Snapshot This is the key lifecycle according to NIST: Source: http://csrc.nist.gov/groups/ST/toolkit/key_management.html As interesting as a “pre-activation” state may be, I think it’s excessive and not needed. “Current” “Retired” “Expired” With proper historical information, the “destroyed” NIST state really is only a state transition and not a real state. Either way, your end state is “deleted”. “Compromised” is different in that you need to keep the “compromised” key around long enough to decrypt any data using it so that it can re-crypted with a new key. “Deleted” I’m not paranoid – everybody IS after me!

10. Key Creation Example This is an example of the steps executed during the creation of a key: I’m not paranoid – everybody IS after me!

11. Key Audit/Management Example This is an example of a user interface exposing the auditing and compromise response initiation capabilities: I’m not paranoid – everybody IS after me!

12. Aspects of N-tiered Systems Besides the typical software architectural tiers, there are three, no make that four aspects of n-tiered systems that need to be considered:▪ Producers and Consumers▪ People that read/write data ▪ External systems that read/write data ▪ Internal processes (think cron jobs)▪ Systems▪ Software/applications that are performing operations on behalf of the producers and consumers▪ Storage▪ Encrypted data ▪ Encryption Keys ▪ Business – yes as much as we’d like to ignore it, we must consider risk… I’m not paranoid – everybody IS after me!

13. Impacts to N-tiered Systems Introducing encrypted data storage adds the following: • Encryption adds overhead to storing data • Decryption adds overhead to retrieving data • Encrypted data is not readily available for ad-hoc operations through non-encryption-aware software like SQL or analytic studios • Backed up encrypted data is not readily restored to systems without access to corresponding keys Introducing key management adds the following: • Keys are not well known so they somehow must be paired with the data that’s been encrypted with them • Re-crypting large datasets can be operationally intensive • Multiple keys need to be backed up and backups need to honor key lifetime policies • Failure to access key storage systems can block critical data storage operations I’m not paranoid – everybody IS after me!

14. Concerns from the N-tiered Context Data producers and consumers: • Certain data storage operations are critical and need to occur regardless of key availability: consider taking a payment, you never want that to fail • Access to encrypted data in whole but more often than not, only in part: consider the “last 4” example of SSNs and PANs • How do the cryptoperiods and data retention policies interact Systems: • How do you manage re-cryption on a large dataset without impacting operational performance • How do you know which key was used • What impacts will addressing the other concerns create Storage: • Backups: “What do you mean that I really need to re-crypt my backups?” Business: • What opportunities exist for reducing risk I’m not paranoid – everybody IS after me!

15. Keeping Track of Key Usage The encryption/decryption aspects of an n-tiered system enabled for key management are going to need to know which key was used to encrypt any given data. This implies: • Have a data model that tracks an integer key identifier for each key: use integers for speed • Store the key identifier with the data that it was used with • In SQL, store the identifier as a column as opposed to something like a serialized object encapsulating the key identifier and data: keeping the identifier easily query-able will greatly speed up searching for key usages during operations like a mass re-crypt The following slides presents an example data model for DEK and KEK storage. I’m not paranoid – everybody IS after me!

16. DEK/KEK Data Model Example I’m not paranoid – everybody IS after me!

17. Critical Data Storage Operations Certain operations should never fail, even if access to the segregated key storage subsystems fails. To mitigate: • Implementing the encryption worker close to the application • Implementing a “default” key in the encryption worker so that encryption can always succeed This creates a new impact: data encrypted with this default key will need to be re-crypted as soon as possible. This is because the default key will need to be persisted where the encryption worker lives unlike keys accessed from the storage subsystem. The means they will be exposed if that application environment is compromised. To mitigate: • Implementing a scanner for default key usage The following slide presents a cadence of scanner for default key usage. I’m not paranoid – everybody IS after me!

18. Default Key Cadence Example I’m not paranoid – everybody IS after me!

19. Lifetimes and Access Implications Repeating the questions of: • Access to encrypted data in whole but more often than not, only in part: consider the “last 4” example of SSNs and PANs • How do the cryptoperiods and data retention policies interact We need to consider the use cases of the data we are encrypting, the cryptoperiods, and any applicable data retention policies. Consider: • Does the data need to be retained longer than the total cryptoperiod If so, consider using current keys with a cryptoperiod of 1 day so that your daily re-crypt load is limited, once you’ve automated your lifecycle, this is a snap • Do we need to retain complete data or is some masked of it acceptable like first 4, last 4 of PANs • Are there use cases where only a mask of the data is needed If so, there’s a great opportunity for performance optimizations. Consider storing the masked data along with the data at initial save/encrypt time. This way you can present the masked data when the full data isn’t needed with decrypt. This removes the need to decrypt and mask when deleting full data. I’m not paranoid – everybody IS after me!

20. Encrypt/Decrypt Sequence Example Consider extending with a “format spec” so that “safe” data can be returned. With the “format spec”, some “safe” form of the data can be returned and saved unencrypted. E.g., First 4, Last 4 of a PAN I’m not paranoid – everybody IS after me!

21. Key Access Example I’m not paranoid – everybody IS after me!

22. Performance and Risk Revisiting these questions: • How do you manage re-cryption on a large dataset without impacting operational performance • What opportunities exist for reducing risk While coming from separate areas of concern, they can be addressed by the same consideration: • As we’ve already stated, use a very short cryptoperiod for your current key, like one day This way you reduce the set of data used by a single key. Reducing the set of data means that you limit re-cryption as your retired keys are deleted, and in event of a compromise you need to re-crypt less data, and you expose less data for any given key that is compromised. I’m not paranoid – everybody IS after me!

23. The Benefit of Lots of Keys I know I keep harping on this, but here’s another example: If you have lots of keys, you reduce the number of keys that can be leeched or snooped out of a system at any one time and if you partition their storage you further reduce the number that can be exposed through a server or storage compromise. Ultimately this means that less data can be compromised and less data exposed reduces the severity/consequence which means less financial risk! I’m not paranoid – everybody IS after me!

24. Normal Key Lifecycle Cadence Example I’m not paranoid – everybody IS after me!

25. Compromised Key Cadence Example I’m not paranoid – everybody IS after me!

26. Backups and Et Cetera Backups/archives present a set of unique challenges: • Since keys reside in segregated storage, they need to be able to paired back to the data that’s been encrypted with them By keeping a key identifier with the encrypted data that is unique across your business systems, it shouldn’t be too difficult to restore into a domain where the keys are present and decrypt. • In the event of a compromise, data encrypted with the keys being expired will need to be re-crypted This one is trickier… if you can easily restore and re-crypt before deleting the compromised keys, great. If you cannot, one strategy is to make a full backup of your current environment once the compromise re-crypt has completed and then delete previous backups containing data encrypted with the compromised key. Either way, this can be highly problematic with large data sets and data warehouse environments. And then there’s that whole ad-hoc access of data thing… I’m not paranoid – everybody IS after me!

27. Resources NIST Key Management Project http://csrc.nist.gov/groups/ST/toolkit/key_management.html NIST Key Management Workshop June 8-9, 2009 http://csrc.nist.gov/groups/ST/key_mgmt/ RFC4107 http://www.rfc-editor.org/rfc/rfc4107.txt IEEE Key Management Summit http://www.keymanagementsummit.com StrongKey Open Source Project http://www.strongkey.org Oasis Enterprise Key Management Infrastructure http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi I’m not paranoid – everybody IS after me!