1. Database Key Management
CSCI 5857: Encoding and Encryption

2. Outline Applications and secure databases Dedicated encryption server
Record-based encryption and encryption receipts
Key vault security and master keys
Key migration
Key backup

3. Database Keys: Bad Ideas
Encrypting entire database with a key
Accessing single record requires encrypting/decrypting entire database
Far too time consuming for large database
Exposes entire database to potential observation

4. Record-based Encryption
Databases encrypted one record field at a time
Different fields in database encrypted with different keys
Allows different levels of security for different information
Name
Phone
Credit Card
Fred Flintstone
Barney Rubble …
Low security: No encryption
Moderate security: 192-bit 3DES key Changed every month
High security: bit AES key Changed every week

5. Applications and Encrypted Databases
Most secure databases accessed by other applications as part of large-scale information system
Applications must be able to rapidly access plaintext version of information in database
Keys should not be accessible to unauthorized users

6. Database Keys: Bad Ideas
Embedding keys in applications that access database
Easy for adversary to extract key from application or hardware running application
Changing key requires changing all applications that access database

7. Overall Encryption Architecture
All encryption/decryption done by single cryptographic application on dedicated machine
All keys stored securely in “key vault” on that dedicated machine (and never leave that machine!)

8. Database Record Encryption
Bob enters new field value into application
Application submits value + fieldname to cryptosystem
Cryptosystem retrieves appropriate key for that field from key vault and encrypts value
Cryptosystem returns encrypted value + receipt
Application stores encrypted value + receipt in database

9. Encryption Receipts Might have many different keys used for encryption
Receipt contains ID of key used to encrypt that value
Not actual key!
Can also contain other useful data, such as key expiration date
Stored in database with encrypted value
Used to determine which key to use for later decryption
Name
Phone
Phone Receipt
Credit Card
Credit Card Receipt
Fred Flintstone
skdf0234rnef2
p32
045/sdfgm29
c845
Barney Rubble
8h5rqw;ernq3
Nc9343f3r,38
c844 …

10. Database Record Decryption
Bob enters request for field value into application
Application retrieves encrypted value + receipt from database
Cryptosystem retrieves key with matching ID from key vault and decrypts value
Cryptosystem returns decrypted value to application

11. Key Vault Security Keys encrypted in any non-volatile storage
Even if steal machine, cannot get to keys
Key ID
Encrypted Key Value
Field …
p32
Up204thf2-05h
phone
c845
Kdfg3[045taqrogn[39-45tsd
creditcard
c846
Vmp405h82[-35ut1-49uf12
“I can’t read these”

12. Master Keys Used to decrypt keys for use by cryptosystem
Neither master key nor decrypted key values in non-volatile memory
Stored on separate secure system(s)
Often broken into two parts for maximum security
Generate random “mask” Kmask
XOR with actual master key Kmaster to create stored key Kstored
Keys Kmask and Kstored stored separately
Combined as Kmaster = Kstored  Kmask when needed

13. Key Migration Database keys should have limited lifespan
Longer use  more data for known/chosen plaintext attacks
Rapid changes = less damage if key compromised
Usual components:
Start: Date at which key can be used for encryption/decryption
Decommission: Date at which migration from this key begins
Only used for decryption, not for encryption
Expiration: Date at which key no longer used
Key ID …
Start
Decommission
Expiration
p32
3/10/2015
4/10/2015
4/24/2015
c845
4/2/2015
4/9/2015
4/12/2015
c846
4/7/2015
4/15/2015

14. Key Migration Process
Migration: Re-encrypting data encrypted with older keys using newer keys
As records accessed and run through cryptosystem, records decrypted with decommissioned key automatically re-encrypted with a different active key
Can force migration of records not accessed
For all fields with receipt containing expired key
Decrypt/re-encrypt with cryptosystem

15. Backing Up Database Keys
Easy to replace lost key in network transmission
Lose symmetric session key: Just resend with another
Lose private key in public key encryption: Just generate another and post a new certificate
Database keys must be stored over long time
Lifetime of key(s) = lifetime of database
If lose keys, lose information in database!

16. Key Backup Must back up key vault regularly
At a minimum, each time new key is added to vault
Should keep multiple backups, paper and electronic
Backups must only contain encrypted version of keys
Otherwise, keys vulnerable to observation
Must back up master keys separately
Can encrypt backup version with different keys stored separately

17. What’s Next Let me know if you have any questions
Continue on to the next lectures on Applications of Encryption