Backup HSM Keys (Scott Rea) HEBCA, Dartmouth College November 7, 2008

1. Backup HSM Keys (Scott Rea)HEBCA, Dartmouth CollegeNovember 7, 2008

2. Why Use HSMs to Protect Keys • Protection of CA private keys is paramount to the security and integrity of any PKI • The WHOLE key life-cycle should be considered when instituting protection measures • Generation • Entry • Use • Storage • Destruction 2

3. Key generation By using an HSM for key generation, ensures key only ever exists in clear text within a security context Great for protection & storage aspects Problematic if HSM vendor does not outlive your CA in a meaningful operating state Higher end HSM vendors allow duplication of tokens for back-up or redundancy purposes Still locks you into that vendor Why Use HSMs to Protect Keys

4. Why Use HSMs to Protect Keys • Key entry • HSMs control the way private key material enters the module • Import functions facilitate protection of keys generated outside crypto module • Once imported, they can be deleted but not exported in cleartext (may be exported in encrypted format to facilitate cloning services) • Better to import in encrypted format and only unwrap key into plaintext once inside the module • Also control how keys are activated by managing PIN/Password/Certificate authentication to use key material 4

5. Why Use HSMs to Protect Keys • Key usage • HSMs restrict direct access to keys by applications • Perform only a specific set of operations on keys • Control access to key via authentication mechanisms • Protect key information leakage by obfuscating EMI/EMC etc 5

6. Why Use HSMs to Protect Keys • Key storage • HSMs are great for protecting keys even in hostile environments • Provide evidence of tampering attempts • Respond to tampering attempts e.g. by destroying key material • HSMs should have some way of reliably logging any events pertaining to an attempt to access, use or control a key it protects 6

7. Why Use HSMs to Protect Keys • Key destruction • HSMs have mechanisms for reliably destroying key material once it expires or is no longer needed. • What happens when there is a physical failure of a device or accidental deletion? • Unless you have a back-up, you may prematurely lose access to services and data protected by your keys 7

8. Justifications for HSM back-ups • Vendor goes out of business or it becomes impractical to continue to use their product • Unsupportable in your environment • HSM experiences a physical failure • HSM is stolen or lost • Disaster Recovery • Redundancy of services to meet operational requirements 8

9. HSM Back-up Options • Vendors generally provide a cloning process • This keeps you locked into their services • What if I want to change vendor? • They no longer support my preferred platform OS • They want to charge too much for maintenance • A vulnerability is discovered in their product • Low end devices do not have this capability e.g. Aladdin eToken 9

10. A Higher Education Approach – General Process • Generate keys in a secure “random access memory” environment • Import keys into one or more initial vendor’s devices • Create a number of back-up shares using a m-of-n scheme • Export the shares on individual media • Securely distribute the shares to disparate locations under control of non related entities • Destroy the original environment 10

11. A Higher Education Approach - Details • Start with a laptop that has been prepared from scratch in a secure manner with fresh OS - hardened and patched in accordance with local security policy • USB port & CD/DVD drive required • Wireless card removed – no network cable plugged in • Create a Live-CD or Live-DVD of a secure distribution • We used Knoppix • Prepare a clean USB flash disk to use to ferry the encrypted key shares • Provision 3 new Aladdin eTokens • Under multi-person control, documented through signed manual log for each step, video tape, and independent 3rd party observers, follow a pre-prepared script to create the Root CA and keys. • i.e. complete the steps detailed below 11

12. A Higher Education Approach - Details • Boot the laptop with the Live-CD • Use OpenSSL with secure random process to generate keys, create the self-signed certificate, and a PKCS12 file containing the key and cert • Import the PKCS12 into multiple Aladdin eTokens • We created 3 eTokens – 1 main with 2 backups • The passphrase set on a given eToken was created and entered by an individual not in custody of the token. • The passphrase for each back-up token was documented, placed into a tamper evident container that is stored with the alternative eToken. • The person transporting the main eToken did not know the passphrase (It was communicated directly to the proposed CA Admin) • The back-up tokens were delivered by FedEx and confirmed by delivery service and the recipient (recipient had to quote unique ID sent with token) 12

13. A Higher Education Approach - Details • Create the encrypted raw key shares • Created in memory using an M-of-N scheme – we used 3 of 5. • Encrypted key shares saved to USB flash disk to facilitate later burning to disk by host machine • Necessitated because did not have multiple drives on laptop and could NOT burn CD while using Knoppix host OS in the drive • Copy of application used to create (and reassemble) the shares is also saved on USB flash disk to be burned along with each share that is created • Power down the Knoppix booted machine to destroy active memory • Use host to burn each of 5 shares along with the recovery application • Shares placed in Tamper-evident bags and FedExed to final recipients from separate locations • Verification of shares received from Carrier and recipient 13

14. A Higher Education Approach - Details • USB stick securely destroyed • Contents fully overwritten 1000 times • Secure format • Then physically destroy stick with a hammer (my favorite part) • Host laptop powered down and re-provisioned to remove any possible residue of encrypted shares • Shares are stored in 5 different locations in safes /safety deposit boxes that require multiple user authentication before access is granted • E.g. locked strongbox with a safe – the key to the strong box is held by one local party, the key to the external safe is held by another • Annual verification of contents is required (Audit) 14

15. Summary • Appropriate use of HSMs provides adequate protection of private keys • Often it is important to have a back up or redundancy of keys especially CA keys • There is NOT portability of keys between HSM vendors, so generating keys within an HSM locks you into a particular vendor • This may not be good due to the longevity of CA keys & volatility of HSM vendor market • A proposed process of securely generating keys outside an HSM and then importing them can mitigate risks • A carefully scripted and audited process should be followed with independnt verification • Keys generated in memory can be transferred securely to the intended HSM and multiple back-ups if desired • A back-up of the keys can be encrypted using a simple M-of-N scheme and securely distributed among a divers group of holders for verifiable independent storage • This facilitates future recovery of keys if necessary for import to new HSM vendor • US Higher Education Root (USHER) was created using this process at Dartmouth • Blessing received for process from other PKI communities e.g. FPKI

16. For More Information Dartmouth PKI Outreach: http://www.dartmouth.edu/~deploypki/ Dartmouth PKI Lab: http://www.dartmouth.edu/~pkilab/ Scott Rea - Scott.Rea@dartmouth.edu