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 application 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 –but grid-proxy-init can easily be mimicked with OpenSSL command-line tools –an ‘mkproxy’ script is available for both soft tokens (files) and eTokens (see

Hardware Several alternatives Aladdin eTokens –price €20 – €65 /pc –support for latest firmware 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 …

Guide around pitfalls ca.dutchgrid.nl/info/etokens

CP/CPS section 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 (cntd) Secure hardware tokens and hardware security modules that comply with the requirements of FIPS level 2 or higher, or FIPS 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 certification at level 2 or higher, and must either intend to submit the device for certification, or have it in process of certification.

Implementation Get the new CP/CPS approved –Add appropriate 1 SCP OID to the issued certificates 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