1. Database Key Management CSCI 5857: Encoding and Encryption

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

3. 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 Encrypted database Encryption/ decryption Plaintext database Change to single record “I have you now!”

4. 4 Record-based Encryption Different fields in database encrypted with different keys Allows different levels of security for different information NamePhoneCredit Card Fred Flintstone555-123-45671111222233334444 Barney Rubble555-123-98765555666677778888 ……… Low security: No encryption Moderate security: 192-bit 3DES key Changed every month High security: 256-bit AES key Changed every week

5. 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 application

6. 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 Application “I have you now!”

7. 7 Overall Database 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!) Encrypted database application encrypted record field Cryptographic application Key vault record field

8. 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 application encrypted field value + receipt Cryptographic application Key vault new field value encrypted field value + receipt new field value

9. 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 NamePhonePhone Receipt Credit CardCredit Card Receipt Fred Flintstoneskdf0234rnef2p32045/sdfgm29c845 Barney Rubble8h5rqw;ernq3p32Nc9343f3r,38c844 …………

10. 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 application encrypted field value + receipt Cryptographic application Key vault decrypted field value encrypted field value + receipt decrypted field value

11. 11 Key Vault Security Keys encrypted in any non-volatile storage –Even if steal machine, cannot get to keys Key IDEncrypted Key ValueField … p32Up204thf2-05hphone c845Kdfg3[045taqrogn[39-45tsdcreditcard c846Vmp405h82[-35ut1-49uf12creditcard ………… “I can’t read these”

12. 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” K mask –XOR with actual master key K master to create stored key K stored –Keys K mask and K stored stored separately –Combined as K master = K stored  K mask when needed Cryptography application Key vault volatile memory K master  K mask K stored

13. 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…StartDecommissionExpiration p32…3/10/20154/10/20154/24/2015 c845…4/2/20154/9/20154/12/2015 c846…4/7/20154/12/20154/15/2015 ……………

14. 14 Key Migration Only active keys are used for encryption 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 c844 c845 active 4/2 migration 4/94/12 active 4/5 migration 4/124/15

15. 15 Replacing Network 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 E K s2 D E public (K S2, K PU ) P K s2 E D PE symmetric (P, K S ) “We’ll try again with K s2 ” new

16. 16 Replacing Database Keys Database keys must be stored over long time –Lifetime of key(s) = lifetime of database –If lose keys, lose information in database!

17. 17 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 Cryptographic application Key vault backup paper backup electronic backup