1 / 11

Secure hardware tokens

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)

baxter
Download Presentation

Secure hardware tokens

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure hardware tokens David Groep DutchGrid CA

  2. 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 functionsprotected in a secure hardware token ~ FIPS140-2 level 2

  3. 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)

  4. 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 • …

  5. 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 …

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

  7. Software • Aladdin PKCS#11 libraries avaialble for public download off the Aladdin .ru web site • the rest of the software and a source-RPM-minus-etpkcs11.{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 platformsto get the Aladdin etpkcs11.so to link correctly questions? janjust@nikhef.nl supported by the Virtual Laboratory for e-Science Scaling and Validation programme

  8. VOMS support • Recently, a native version of ‘voms-proxy-init’ was ported to cygwin • with eToken support • complements the ‘eToken info’ documents

  9. 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.

  10. 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.

  11. 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

More Related