1. netHSM Dhiva Muruganantham DOEGrids CA ESnet/LBNL

2. Agenda Hardware Security Module Overview –nShield –nToken & netHSM –Security World netHSM Transition

3. HSM: nCipher Security World How the nCipher Security World Works From nCipher Security World whitepaper

4. Hardware Security Modules: Overview Purpose: Defend CA private keys from theft 2001-2002 evaluation: selected nCipher nCipher Security World concept –Ciphertext keys in file system –Plain text keys only in nCipher FIPS-140-3 nShield hardware –Key activities controlled by nCipher OPERATOR card set (eg enabling CA signing activity) –Key management and Security World manged by Administrative card set (ACS) –Operation: Key material is downloaded from file system to device OCS smart card enables key material – plain text signing key is available for operations in device PKCS#12 library calls cause plaintext key to be use Private key in plaintext form never leaves device (PKCS#12 function disabled) 2 Distinct Security Worlds: –Root CA (private) – own ACS, own OCS –All current online CAs – one ACS set, multiple OCS sets, one set for each CA Key – splitting for cards: m of n configuration (eg 3 cards req’d out of 9 total) All ACS sets are m of n configuration OCS cards are single use – Iplanet/SunONE CMS inflexiblity limits our ability to use this technique. (That is, 1 of n).

5. netHSM A Hardware Security Module attached to a network as a shared resource –Remote Operation possible –Can be offline, when it is not in use netHSM components –netHSM –Remote File System –nToken device

6. netHSM objective Transfer the current DOEGrids CA security world in to “netHSM” architecture. Experiment netHSM offerings:- –Multiple netHSM with load balancing –Multiple Remote File System ( RFS) –CA service using netHSM with nTOKEN device –CA service using netHSM but without nTOKEN device –CA service using netHSM with old nShield device

7. Present and Future Present –nShield per CA –Single security world ( 1 set of ACS) for all the online CAs; Root CA excluded –Multiple Operator Card set ( 1 set per CA) Future with netHSM –Multiple netHSM (at least 2 to with stand failure) –Multiple Remote File Server( at least 2 rfs) –Transfer the current Security world into netHSM –Exercise ‘netHSM’ Remote Operation feature –Clone all the online CAs

8. Configuration 1 RFS Client 1 netHSM

9. Configuration 2 RFS Client 1 netHSM

10. Configuration 2 … RFS Client 1 netHSM Client 2

11. Client 2 netHSM with multiple clients RFS Client 1 netHSM Client “n”

12. Client 2 Multiple netHSM RFS 1 Client 1 netHSM 1 Client “n” netHSM 2 RFS 2

13. Findings 1 RFS per netHSM Security world can exists without having an nToken device; i.e client machine can be configured with or without nToken and still can communicate with netHSM Client machine enrollment (mutual authentication) –ipaddress needs to be notified to netHSM before hand –then the client initiates the enrollment request to netHSM After the initial setup netHSM works with out Remote File System Every Client can also act as RFS? Testing in progress

14. Questions? netHSM – RFS – client : Is it necessary to do file system sync between ‘rfs’ and ‘client’? Looks like Yes. Can the client be configured to have multiple HSMs? Multiple netHSM per RFS Multiple netHSM configuration for a client Multiple RFS configuration for a client