one perspective on key management 18 may 2009 i’m not paranoid – everybody is after me! 1 key...

One Perspective on Key Management

18 May 2009 I’m not paranoid – everybody IS after me!

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



2

Introduction and ScopeOK, 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



3

Objective1. Why is there a need manage encryption keys2. What does managing of encryption keys entail3. How does key management impact n-tiered systems4. How to mitigate key management impacts to n-tiered

systems 5. Resources

Word of the Day:“Re-cryption”: The act of decrypting data with one key and

encrypting it with a different key.



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



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



6

Key Management – ICreation 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.



7

Key Management – IIAccess 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)



8

Key Management – IIIAuditing 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.


This is the key lifecycle according to NIST:

Source: http://csrc.nist.gov/groups/ST/toolkit/key_management.html


9

Key Lifecycle Snapshot

“Current”

“Retired” “Expired”

“Deleted”

As interesting as a “pre-activation” state may be, I think it’s excessive and not needed.

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.


This is an example of the steps executed during the creation of a key:


10

Key Creation Example

Symmetric Server

1New Key Request

DEK: Data Encryption KeyKEK: Key Encryption KeyMCK: Microsoft.Net Machine.config Key

KEK Encrypted DEK

Rijndael Keyring

2Decrypted

MCKEncrypted

MCK

3Retire Current KEK

Assumptions:

No PANs are stored beyond 12 months.

Symmetric Keys are retired on a daily basis. There is only one symmetric key (one DEK and one KEK) for current use. After 1 day, the current keys are retired. Retired keys are deleted after 12 months.

Symmetric keys are paired with a sequence number. The sequence number is stored with the corresponding encrypted data so that the decrypt process can use appropriate key (current versus retired).

This daily key retiring strategy allows us to expire keys without re-encryption except in the case where we believe we have a compromised key or set of keys (current and/or retired).

Sequence number zero is reserved for default key signifier. The default key is used to avoid transaction failures in the event the Symmetric Key Server is unresponsive. A scheduled job exists to detect PANs stored with default keys and re-encrypted them (see PAN Scanner tab).

MCK Encrypted KEK

Rijndael Keyring

5Retire

Current DEK

Database Cluster 1

Database Cluster 2

4Create newCurrent KEK

6Create new

Current DEK


This is an example of a user interface exposing the auditing and compromise response initiation capabilities:


11

Key Audit/Management Example



12

Aspects of N-tiered SystemsBesides 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…

Producers and Consumers

Systems

Storage

User and System Interfaces

Users

StoredData

ExternalSystems

InternalProcesses

Keys

Business and Data Tiers

Encryption Services



13

Impacts to N-tiered SystemsIntroducing 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



14

Concerns from the N-tiered ContextData 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



15

Keeping Track of Key UsageThe 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.



16

DEK/KEK Data Model ExampleKey Table Data Model (DEK)

Data Type Notes

Sequence ID Int [IDENTITY] Important Sequence IDs: base key = 100Note that the default key will never be stored in the Key database table. In fact, no key with a Sequence ID under 100 will ever be stored in the database. Those ids are reserved for keys that will exist outside of the database and hence the normal retirement scheme.

Encrypted Key Consists of two columns, Key [varchar(260)] and InitializationVector [varchar(260)]

Encryption Sequence ID

Int References (think “foreign key”) to the KEK that the DEK was encrypted with.

Status Enumeration, see notes.

Key Status EnumerationCurrent ~ only ever one Retired ~ 0 to 364 Expired ~ 0 to 365Deleted ~ unlimited

Create Date Date time This field helps to monitor and audit the lifecycle of each key. It’s value is set when the key is created.

Expire Date Date time This date is updated when the key is expired either by an explicit action on part of a user or through a scheduled background process. In conjunction with the expiration reason, this field helps monitor the lifecycle of each key

Expiration Reason Text Example – “Believed comprised by hacker on ip xx.xx.xx.xx”

Key Table Data Model (KEK)

Data Type Notes

Sequence ID Int [IDENTITY] Important Sequence IDs: base key = 100Note that the default key will never be stored in the Key database table. In fact, no key with a Sequence ID under 100 will ever be stored in the database. Those ids are reserved for keys that will exist outside of the database and hence the normal retirement scheme.

Encrypted Key Consists of two columns, Key [varchar(260)] and InitializationVector [varchar(260)]

Status Enumeration, see notes. Key Status EnumerationCurrent ~ only ever one Retired ~ 0 to 364 Expired ~ 0 to 365 Deleted ~ unlimited

Create Date Date time This field helps to monitor and audit the lifecycle of each key. It’s value is set when the key is created.

Expire Date Datetime This date is updated when the key is expired either by an explicit action on part of a user or through a scheduled background process. In conjunction with the expiration reason, this field helps monitor the lifecycle of each key

Expiration Reason Text The expiration reason helps:1.offer insight into the reasons that a key might have been automatically expired by a background process, and2.Meet auditing requirements in situations when a personnel explicitly expires a key from a key management user interface.An example for a value in this field might be “Key deleted normally”



17

Critical Data Storage OperationsCertain 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.



18

Default Key Cadence Example

Symmetric KEY Server(see Symmetric Key Server tab)

1Scheduled Job

6Current DEK

Encrypted PANover DB connection

5Rijndael DEK

over SSL

Ops Server

4DEK Request

over SSL

Database Servers


2Databases searched for default key usage

3Default Key


Normal cadence:(run every 30 minutes)1: Where PAN is using default DEK, re-encrypt using current DEK (see diagram below)2: Per scan, if total count of default DEK occurrence exceeds threshold, generate alarm



19

Lifetimes and Access ImplicationsRepeating 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 cryptoperiodIf 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 neededIf 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.



20

Encrypt/Decrypt Sequence Example

Symmetric Key ServerPhysical Server n

Application Code EncryptionWrapper Component DEK Web Service

Decrypt(Data, Key ID)

WS DEK Request over SSL

DEK Response over SSL

Decrypted data

Decrypt Data

Symmetric Key ServerPhysical Server n

Application Code EncryptionWrapper Component DEK Web Service

Encrypt(Data)

WS DEK Request over SSL

DEK Response over SSL

Encrypted data, Key ID

Encrypt Data

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



21

Key Access Example

Symmetric Key Server

7Rijndael DEK

over SSL

Web Heads

KEK Encrypted Rijndael DEK

KEK Encrypted DEK

Rijndael Keyring

1DEK Request

over SSL

MCK Encrypted Rijndael KEK

MCK Encrypted KEK

Rijndael Keyring

2KEK Request

over DB Connection

3MCK encrypted Rijndael KEK

over DB Connection

4Decrypted

MCK

Encrypted

MCK

Database Cluster 1

Database Cluster 2

5DEK Request

over DB Connection

6KEK encrypted Rijndael DEK

over DB Connection




22

Performance and RiskRevisiting 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.



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!



24

Normal Key Lifecycle Cadence Example

1Scheduled Job

4Empty (null) PANs

over DB connectionOps Server

Database Servers


2Databases searched for PANs/orders older than 1 year

3PAN storage objectsover DB connection

Normal cadence:(run daily)1: Where PAN/order is older than 1 year, set PAN to null in PAN storage object (see diagram below)2: Delete retired key where age >= 365 days - annotation: key deleted normally3: Retire current key and Create new current key as atomic operation



25

Compromised Key Cadence Example

Symmetric KEY Server(see Symmetric Key Server tab)

1On-demand Job

6Current DEK


5Rijndael DEK

over SSL

Ops Server

4DEK Request

over SSL

Database Servers


2Databases searched for expired key usage

3Expired Key


Compromised current key cadence:(on demand)1: Expire current key - annotation is submitted through key manangement UI2: Create new key3: Where PAN is using newly expired current key, re-encrypt using newly created current key (see diagram below)4: Delete expired key

Compromised retired key cadence:(on demand)1: Expire compromised retired keys - annotation is submitted through key manangement UI2: Where PAN is using any of the newly expired retired keys, re-encrypt using current key (see diagram below)3: Delete expired keys



26

Backups and Et CeteraBackups/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…



27

ResourcesNIST Key Management Projecthttp://csrc.nist.gov/groups/ST/toolkit/key_management.html

NIST Key Management Workshop June 8-9, 2009http://csrc.nist.gov/groups/ST/key_mgmt/

RFC4107http://www.rfc-editor.org/rfc/rfc4107.txt

IEEE Key Management Summithttp://www.keymanagementsummit.com

StrongKey Open Source Projecthttp://www.strongkey.org

Oasis Enterprise Key Management Infrastructurehttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi

one perspective on key management 18 may 2009 i’m not paranoid – everybody is after me! 1 key...

Documents

key management slide

key management impacts

different key

broad topic of key management

encryption keys

obfuscation of data

decrypt data

consumers of data