1. technology and computing
2. software
3. databases

One Perspective on Key Management
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.”
18 May 2009
I’m not paranoid – everybody IS after me!
1
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
2
One Perspective on Key Management
Objective
1.
2.
3.
4.
5.
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.
18 May 2009
I’m not paranoid – everybody IS after me!
3
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
4
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
5
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
6
One Perspective on Key Management
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
Retired
Expired
Deleted
(NIST: Active) – used to encrypt and decrypt data
(NIST: Deactivated) – used to only to decrypt data
(NIST: Compromised) – used only to decrypt data of a compromised key
(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)
18 May 2009
I’m not paranoid – everybody IS after me!
7
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
8
One Perspective on Key Management
Key Lifecycle Snapshot
This is the key lifecycle according to NIST:
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”
Source: http://csrc.nist.gov/groups/ST/toolkit/key_management.html
18 May 2009
I’m not paranoid – everybody IS after me!
9
One Perspective on Key Management
Key Creation Example
This is an example of the steps executed during the creation of a key:
Symmetric Server
Assumptions:
1
No PANs are stored beyond 12 months.
New Key Request
2
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).
DEK: Data Encryption Key
KEK: Key Encryption Key
MCK: Microsoft.Net Machine.config Key
18 May 2009
Encrypted
Decrypted
MCK
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.
MCK
5
Retire
Current DEK
3
Retire Current KEK
4
6
Create new
Current KEK
Create new
Current DEK
Database Cluster
1
Database Cluster
2
MCK Encrypted KEK
KEK Encrypted DEK
Rijndael Keyring
Rijndael Keyring
I’m not paranoid – everybody IS after me!
10
One Perspective on Key Management
Key Audit/Management Example
This is an example of a user interface exposing the auditing and
compromise response initiation capabilities:
18 May 2009
I’m not paranoid – everybody IS after me!
11
One Perspective on Key Management
Aspects of N-tiered Systems
Producers and Consumers
External
Systems
Users
Internal
Processes
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
Systems
User and System Interfaces
Business and Data Tiers
Encryption
Services
18 May 2009
▪ Systems
▪ Software/applications that are
performing operations on behalf of
the producers and consumers
▪ Storage
▪ Encrypted data
▪ Encryption Keys
Storage
Stored
Data
▪ People that read/write data
▪ External systems that
read/write data
▪ Internal processes (think cron jobs)
Keys
▪ Business – yes as much as we’d like to
ignore it, we must consider risk…
I’m not paranoid – everybody IS after me!
12
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
13
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
14
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
15
One Perspective on Key Management
DEK/KEK Data Model Example
Key Table Data Model
(DEK)
Data Type
Sequence ID
Int [IDENTITY]
Encrypted Key
Notes
Important Sequence IDs:
base key = 100
Note 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.
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 Enumeration
Current ~ 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
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”
18 May 2009
Key Table Data Model
(KEK)
Data Type
Notes
Sequence ID
Int [IDENTITY]
Important Sequence IDs:
base key = 100
Note 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 Enumeration
Current ~ 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, and
2.
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”
I’m not paranoid – everybody IS after me!
16
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
17
One Perspective on Key Management
Default Key Cadence Example
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
2
Databases searched for default key usage
3
Database Servers
Default Key
Encrypted PAN
over DB connection
6
Current DEK
Encrypted PAN
over DB connection
Ops Server
Symmetric KEY Server
1
(see Symmetric Key Server tab)
Scheduled Job
5
Rijndael DEK
over SSL
4
DEK Request
over SSL
18 May 2009
DEK: Data Encryption Key
KEK: Key Encryption Key
MCK: Microsoft.Net Machine.config Key
I’m not paranoid – everybody IS after me!
18
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
19
One Perspective on Key Management
Encrypt/Decrypt Sequence Example
Physical Server n
Symmetric Key Server
Application Code
EncryptionWrapper Component
Consider extending with a
“format spec” so that “safe” data
can be returned.
DEK Web Service
Encrypt(Data)
WS DEK Request over SSL
DEK Response over SSL
Encrypt Data
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
Encrypted data, Key ID
Physical Server n
Symmetric Key Server
Application Code
EncryptionWrapper Component
DEK Web Service
Decrypt(Data, Key ID)
WS DEK Request over SSL
DEK Response over SSL
Decrypt Data
Decrypted data
18 May 2009
I’m not paranoid – everybody IS after me!
20
One Perspective on Key Management
Key Access Example
6
KEK encrypted Rijndael DEK
over DB Connection
Database Cluster
1
Web Heads
5
Symmetric Key Server
DEK Request
over DB Connection
KEK Encrypted Rijndael DEK
7
1
Rijndael DEK
over SSL
DEK Request
over SSL
4
KEK Encrypted DEK
Decrypted
MCK
Rijndael Keyring
Encrypted
MCK
3
MCK encrypted Rijndael KEK
over DB Connection
Database Cluster
2
2
KEK Request
over DB Connection
MCK Encrypted Rijndael KEK
DEK: Data Encryption Key
KEK: Key Encryption Key
MCK: Microsoft.Net Machine.config Key
18 May 2009
MCK Encrypted KEK
Rijndael Keyring
I’m not paranoid – everybody IS after me!
21
One Perspective on Key Management
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.
18 May 2009
I’m not paranoid – everybody IS after me!
22
One Perspective on Key Management
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!
18 May 2009
I’m not paranoid – everybody IS after me!
23
One Perspective on Key Management
Normal Key Lifecycle Cadence Example
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 normally
3: Retire current key and Create new current key as atomic operation
2
Databases searched for PANs/orders older than 1 year
3
Database Servers
PAN storage objects
over DB connection
4
Ops Server
Empty (null) PANs
over DB connection
1
Scheduled Job
DEK: Data Encryption Key
KEK: Key Encryption Key
MCK: Microsoft.Net Machine.config Key
18 May 2009
I’m not paranoid – everybody IS after me!
24
One Perspective on Key Management
Compromised Key Cadence Example
Compromised current key cadence:
(on demand)
1: Expire current key - annotation is submitted through key manangement UI
2: Create new key
3: 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 UI
2: Where PAN is using any of the newly expired retired keys, re-encrypt using current key (see diagram below)
3: Delete expired keys
2
Databases searched for expired key usage
3
Database Servers
Expired Key
Encrypted PAN
over DB connection
6
Current DEK
Encrypted PAN
over DB connection
Ops Server
Symmetric KEY Server
1
(see Symmetric Key Server tab)
On-demand Job
5
Rijndael DEK
over SSL
4
DEK Request
over SSL
18 May 2009
DEK: Data Encryption Key
KEK: Key Encryption Key
MCK: Microsoft.Net Machine.config Key
I’m not paranoid – everybody IS after me!
25
One Perspective on Key Management
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…
18 May 2009
I’m not paranoid – everybody IS after me!
26
One Perspective on Key Management
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
18 May 2009
I’m not paranoid – everybody IS after me!
27