How To Protect Keys

04/19/23 How To Protect Keys 1

How To Protect Keys

Student: Ying HongCourse: Database Security

Instructor: Dr. Yang


Introduction As public key cryptography has become the

basis of computer security, the weak point in security has shifted from the data itself to the keys which protect them.

Tow approaches: one is from RSA Security one is from nCipher Security World


RSA Approach

Traditional approach is to save the keys and encrypted data within the database together.

RSA approach is to build an Encryption Server to provide centralized encryption services, which separates encryption keys from the encrypted data stored in the database.


Internal Database Encryption


External Database Encryption


Sample Implementation

Login:1. Get user ID andpassword

End User

Server

ProcessLogin:

4. Authenticate user

Users' keysEncryptedpasswords

Traditional Approach: Internal Database Encryption

2. Send them to server

3. Get user's keyand password fromDatabase by usinguser ID

5. Send feedback to user

Login:1. Get user ID andpassword

End User

Server

ProcessLogin:

5. Authenticate userEncryptedpasswords

CryptoServerUser's keysCrypto Service

RSA Approach: External Database Encryption



3. Send user ID andpassword, then getpassword inencrypted form

4. Get user'sencrypted password


Weak Point

Traditional approach vs. RSA approach

You may notice: RSA approach did NOT yet solve the problem of

the exposure of the keys and sensitive data thoroughly. It moves the weak point from the server application (ProcessLogin) to the CryptoServer.


nCipher Approach

nCipher approach is to provide Hardware security modules (HSMs) with software to control key management.

nCipher also developed a new system called Secure Execution Engine (SEE), which can protect application software as it’s executed by allowing the sensitive code being executed inside the HSMs.


Secure Key Storage The keys can only be used inside the HSMs,

so that strong security perimeter is provided.

However, it’s not good idea to store keys inside HSM: HSM is attacked, keys are destroyed the number of keys which can be created, used

and stored is restricted by the capacity of storage built into HSM unit

HSM’s module key is often pre-installed and known to the HSM manufacturer, so the chain of trust is not entirely under the control of the HSM administrator.


Key Backup & Recovery

Key backup and recovery should be implemented in a consistently secure manner.

Basic concepts of protecting stored keys: Strong encryption: triple-DES Fragmentation of keys: ‘k of n’ key fragments ACL: a list of operation associated with each key


Key Backup & Recovery cont.



Steps of creating ‘key blob’: The target key is encrypted using Triple-DES

encryption. Its ACL is also, separately, encrypted. The key and ACL are encrypted together and the

result is signed with a wrapper key (module key), to form blob. A Message Authentication Code (MAC) is stored with the key blob, ensuring that tampering is detectable.

The wrapper key in turn is associated with another ACL, which determines who can access it.



If required, key fragments can each be wrapped with their own access control mechanisms.

Now, encrypted key blob can be exported and stored server storage; also key fragments can be stored separately so that k smart cards out of a total set n are required to access the key.


Access To Key Blob


Access To Key Blob cont.

Access to key blobs is physically controlled: Smart cards must be presented in order to load the

key blob into the HSM and unwrap it for decryption;

Knowing the key blob is not sufficient to recover the original key object by itself, since any key stored on physical tokens is encrypted with the module key and module keys are held securely within the HSM.

Instead of just encrypting keys with the module key, the HSM can combine the module key with a phrase supplied by the user, so that it significantly improves the weak point on the chain of the trust we mentioned earlier.



Standard nCipher Approach: Key blob is decrypted only inside the HSM

Login: 1. Get user ID and password

End User



Server

ProcessLogin: 8. Authenticate user

Key blob

6. Decrypt Key blob

HSM

3. Get user's key blob from database

5. Insert operator (or administrator) card, and enter passphrase

4. Send key blob to HSM 7. Send key back to appl.


Extension nCipher’s SEE technology enable the code to

perform security functions inside the HSMs.



Login: 1. Get user ID and password

End User



nCipher Approach with SEE: Key is used only inside the HSM

Server

ProcessLogin: General process

Key blob

6. Decrypt Key blob 7. Authenticate users (Sensitive code)

HSM

3. Get user's key blob from database

5. Insert operator (or administrator) card, and enter passphrase

4. Send key blob to HSM 8. Send authentication result back to appl.


Benefits Non-hierarchical key management

the administrator card set the operator card set(s)

Initialization key uniqueness the module key is not known outside the HSM and

remains valid until the module is reinitialized

Scalability It’s possible to share module keys across a series

of HSMs


Conclusion RSA approach is a software-only solution, so it’s easier

to use.

nCipher approach may be more secure than the RSA approach, and it takes one more step further to protect the sensitive code, but it’s obviously more complicated.


References http://

www.placewareforum.com/rsasecurity/page.cfm?p=event&eventid=12458&subcatid=11728, Securing Data At Rest: Developing a Database Encryption Strategy

http://active.ncipher.com/whitepapers/nCipher_security_world_wp.pdf, nCipher Security World white paper

http://active.ncipher.com/whitepapers/SEE_white_paper.pdf, Secure Execution Engine white paper

How To Protect Keys

Documents

Transcript of How To Protect Keys