Secure hardware tokens David Groep DutchGrid CA

Download Report

Transcript Secure hardware tokens David Groep DutchGrid CA

Secure hardware tokens
David Groep
DutchGrid CA
DutchGrid CA requirements
• Need for automated clients
– from the bioinformatics domain (NBIC BioRange/BioAssist)
– other BIG GRID application domains (e.g. astronomy)
• Supported classes of certificates
(within the Classic X.509 secured profile)
– Users: certificates for natural persons
– Hosts: networked systems, applications or services –
solely to identify network endpoints in communications
– Servers: (internal)
– Robots: agents that perform automated functions
protected in a secure hardware token ~ FIPS140-2 level 2
Token: grid applications
What should the token support
• web interaction (Firefox, IExplorer)
– registration in VOs
– connecting to collaborative Wiki’s, &c
• proxy generation
– some grid proxy init’s have a PKCS#11 i/f
– on all cases,
grid-proxy-init can be mimicked with OpenSSL commands
– ‘mkproxy’ script is available for both soft tokens (files)
and eTokens
(see http://ca.dutchgrid.nl/info/etokens)
Hardware
Several alternatives
• Aladdin eTokens
– price €20 – €65 /pc
– support for latest firmware (CardOS 4.21 a.k.a. 4.2B)
version is mixed
• can get them to work in Win, Linux, MacOS
• but there are some pitfalls with this version still
– not yet FIPS certified (CardOS 4.01 is, 4.2B is not)
• Rainbow iKey 3000
– good OpenSC support
– out of production, since they could not be eaten
– version “4000” OpenSC support unknown
• …
Aladdin eToken
• Comes in several varieties
• eToken PRO USB 32k/64k
– CardOS 4.01:
OpenSC support, FIPS 140-2 lvl 2 (32k)
1024 bit keys only
– CardOS 4.2:
OpenSC supported, 64k version only
2048 bits with firmware upgrade
recently got FIPS certified?
– CardOS 4.21 (4.2B):
NO OpenSC support 
2048 bit keys native
pending certification …
Guide around pitfalls
ca.dutchgrid.nl/info/etokens
Software
• Aladdin PKCS#11 libraries avaialble for
public download off the Aladdin .ru web site
• the rest of the software and a source-RPM-minusetpkcs11.{dll,so}
are available from the DutchGrid CA web site
(full binary available for IGTF members, see web)
• a install-and-forget RPM/DEB really helps for user
adoption
– includes 32bit OpenSSL build for 64 bit platforms
to get the Aladdin etpkcs11.so to link correctly
questions? [email protected]
supported by the Virtual Laboratory for e-Science Scaling and Validation programme
VOMS support
• Recently, a native version of ‘voms-proxyinit’ was ported to cygwin
– with eToken support
– complements the ‘eToken info’ documents
CP/CPS section 2.6.1
Secure hardware tokens, whenever referenced in this
document, are those hardware security cryptographic
devices or hardware security modules that operate
on and hold asymmetric cryptographic key pairs in
such a way that the private part of the key pair
cannot ever be extracted in unencrypted form, can
only be unencrypted inside the device, and the
encrypted form, if available, uses 128 bit symmetric
key encryption or equivalent or stronger, and where
the key pair has been generated inside the
cryptographic device.
Any tampering, any substitution or extraction of
keys, and any unauthorized modification of the
activation data, must leave evidence on the secure
hardware token.
section 2.6.1 (cntd)
Secure hardware tokens and hardware security
modules that comply with the requirements of FIPS
140-1 level 2 or higher, or FIPS 140-2 level 2 or
higher, and where the key pair has been generated
inside the module, are adequate to meet the
requirements set forth above.
If not FIPS certified, implementation of an equivalent
security level and appropriate mechanisms on the
token must be demonstrated: the vendor must have
built the device with the intention of obtaining FIPS
140-2 certification at level 2 or higher, and must
either intend to submit the device for certification, or
have it in process of certification.
Implementation
• Got new CP/CPS approved
– Add appropriate 1SCP OID to the issued certificates
(will do once we issue the frist robot cert)
• Train RAs to help generate keypairs on the tokens
–
–
–
–
initially only the central RA service and the roving RAs
in parallel to the ‘dumb’ RAs at most institutions
targetted at the ‘robot’ use case, i.e. portals
and individuals in grid operations to gain experience
‘limited fieldtest’ for the next few months
• Deployment model: users get the token ‘on loan’
from the CA, so no direct cost to the subscribers