Database Key Management

1. Database Key Management CSIS 5857: Encoding and Encryption

2. 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 anotherand post a new certificate “We’ll try again with Ks2” Epublic (KS2, KPU) Ks2 E D Ks2 P Esymmetric (P, KS) P D E new new

3. Replacing Database Keys • Information in database encrypted with one or more keys • Database keys must be stored over long time • Lifetime of key(s) = lifetime of database • If lose keys, lose information in database!

4. Applications and Database Keys • Applications must be able to rapidly access plaintext version of information in database • Keys should not be accessible to unauthorized users application

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

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

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!) • Individual record fields encrypted instead of entire database record field record field Cryptographic application application Key vault Encrypted database

8. Record-based Encryption • Different fields in database encrypted with different keys • Allows different levels of security for different information Low security: No encryption Moderate security: 192-bit 3DES key Changed every month High security: 256-bit AES key Changed every week

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

10. Encryption Receipts • 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

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

12. Key Vault Security • Keys stored on same hardware as cryptosystem • Prevents “listening” for key values • Keys encrypted in any non-volatile storage • Even if steal machine, cannot get to keys “I can’t read these”

13. 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 Kmask Key vault Cryptography application volatile memory Kmaster Kstored 

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

15. 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 4/2 4/9 4/12 c844 active migration 4/5 4/12 4/15 c845 active migration

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 keysseparately • Can encrypt backup version with different keys stored separately paper backup Cryptographic application Key vault electronicbackup backup