Transcript TAGPMA-netHSM

netHSM
Dhiva Muruganantham
DOEGrids CA
ESnet/LBNL
Agenda
• Hardware Security Module Overview
– nShield
– nToken & netHSM
– Security World
• netHSM Transition
HSM: nCipher Security World
How the nCipher Security World Works
From nCipher Security World
whitepaper
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).
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
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
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
Configuration 1
RFS
Client
1
netHSM
Configuration 2
RFS
Client
1
netHSM
Configuration 2 …
Client
2
RFS
Client
1
netHSM
netHSM with multiple clients
Client
“n”
RFS
Client
1
netHSM
Client
2
Multiple netHSM
Client
“n”
RFS 2
Client
2
RFS 1
Client
1
netHSM 1
netHSM 2
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
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