Database Key Management CSCI 5857: Encoding and Encryption

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

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

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 555-123-4567 1111222233334444 Barney Rubble 555-123-9876 5555666677778888 … Low security: No encryption Moderate security: 192-bit 3DES key Changed every month High security: 256-bit AES key Changed every week

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

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

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!)

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

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 …

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

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”

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

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

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

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!

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

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