Database Key Management CSCI 5857: Encoding and Encryption
Slide 2
Outline Record-based encryption Applications and secure
databases Dedicated encryption server Encryption receipts Key vault
security and master keys Key migration Key backup
Slide 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!
Slide 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
Slide 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
Slide 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!
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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 cant read these
Slide 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
Slide 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 IDStartDecommissionExpiration
p323/10/20154/10/20154/24/2015 c8454/2/20154/9/20154/12/2015
c8464/7/20154/12/20154/15/2015
Slide 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
Slide 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 ) Well try again with K s2 new
Slide 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!
Slide 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