Tag: OpenSC

It’s been so long, I had been involved with multiple Smartcard/PKI projects particularly supporting integration of Sun technologies for use with National eID, US Federal (HSPD-12 / PIV cards) and DoD CAC projects. There is no secret sauce,  but unfortunately I did’nt find time to put together a trustworthy documentation addressing the technical aspects of using Smartcard based PKI credentials for Physical and logical access control solution.  Couple of my friends at SIs (too big to name here) involved with large-scale PIV/CAC deployment repeatedly asked me to draft a cheatsheet for them – finally I had some time to put together an unofficial document that illustrates the pre-requisites, architecture scenarios, configuration and deployment of Smartcard based PKI certificate authentication using Sun OpenSSO Enterprise (Formerly referred to as Sun Java System Access Manager). Here is the main feature of the story:

Smartcard/PKI authentication based SSO

OpenSSO supports the use of PKI certificates from Browser or Smartcard/Token based PKI credentials for authentication and enabling Web Single sign-on (SSO) by determining the revocation status of the certificate through the use of the Online Certificate Status Protocol (OCSP), Certificate Revocation Lists (CRLs) and matching the certificate to a pre-existing certificate entry in LDAP.

Tools of the Trade

  1. Sun OpenSSO Enterprise 8 or above
  2. Sun GlassFish Enterprise v2.1 or Sun Web Server 7.0 (or above)
    • Must be configured with an NSS Keystore or FIPS-140 conformant Keystore.
    • PKCS#11/HSM based Keystore (optional)
      • Sun Cryptographic Accelerator (SCA-6000) or another HSM.
  3. Sun Java System Directory Server EE6 or Sun OpenDS (Bundled with OpenSSO )
    • Repository for user accounts and its corresponding PKI certificate entries (optional).
  4. PKI Provider
    • Certificate and Validation Authority
      • Certificate Authority: Cybertrust / Entrust / Microsoft / Verisign
      • OCSP Responders: Tumbleweed / Corestreet OCSP Validator
    • Root CA Certificates and CRLs
      • FBCA SSP CA certificates and CRLs (For PIV/FIPS-201 cards)
      • DoD CA/ECA Root certificates and CRLs (For CAC cards)
      • Govt PKI Root CA certificates and CRLs (For eID cards)
      • OCSP Signing certificate (if required)
  5. Smartcard Reader and drivers
  6. Smartcard client middleware – Browser Plug-in (PKCS#11 or MS-CAPI)
    • ActivIdentity (ActivClient PKI 6.0 / CAC 6.0 or above)
    • GemAlto (GemSAFE)
    • OpenSC PKCS#11 (OpenSC.org) / MUSCLE
  7. Web browser installed with user certificates (Non-Smartcard Scenario)
  8. Smartcards provisioned with PKI certificates
    • PIV, CAC, National eID (PKCS#15/Java Cards)

Architectural Strategies

OCSP based Certificate Validation

In this strategy, OpenSSO determines the revocation status of the certificate by issuing a real-time status request and confirms the status by accepting the response from the OCSP responder. OpenSSO 8 supports OCSP based certificate validation by sending OCSP request validation to an OCSP responder URL (Validation authority or CA) specified in the PKI certificate credential (On the Smartcard) – usually available as an Authority Information Access (AIA) extension attribute (RFC3280). If the AIA attribute is not present, OpenSSO will send the OCSP request to designated OCSP responder URL specified in the OpenSSO Certificate Module configuration.

Logical Architecture - OCSP based Validation Strategy

Logical Architecture - OCSP based Validation Strategy

OpenSSO 8 supports issuing signed OCSP requests by making use of OCSP signing certificates stored in the Web container’s NSS keystore or HSM.

Matching PKI certificates in LDAP/CRLs Repository

In this strategy, OpenSSO determines the validity of the PKI certificate by matching the user’s public-key certificate against the user’s LDAP account  stored in a local or remote LDAP repository. OpenSSO uses the X.509 attributes from the certificate (ex. SubjectDN attributes including uid, emailAddress, serialNumber etc) for searching and retrieving the stored user’s certificate from LDAP.  If the user’s certificate matches the retrieved certificate – the authentication is considered successful.  As a pre-requisite, the cardholder’s public-key certificate from the Smartcard must be obtained out and then stored as an userCertificate;binary attribute entry of the user account in LDAP.

Logical Architecture - Matching to LDAP/CRL entries

Logical Architecture - Matching to LDAP/CRL entries

OpenSSO also supports matching certificates to CRLs in an LDAP repository.  This means OpenSSO uses the Issuer’s DN attribute for searching CRLs in LDAP repository. If the certificate is identified on the CRL; the user authentication is denied. As a pre-requisite, the CRLs must be imported into the LDAP directory. If the user’s certificate includes a CRLDistributionPointsExtension or IssuingDistributionPointExtension   attribute that identifies the location of CRL distribution points where the CRLs are available, OpenSSO certificate module automatically updates it.
In a real-world scenario,  OCSP based certificate validation is overwhelmingly preferred as a best practice over matching certificates using LDAP or CRLs as they require caching them locally, frequency of updates and concerns related to timestamps, authenticity and integrity.

Now, you got the highlights,  if you are ready to dig deeper and test-drive the Configuration and Deployment – Here is the unofficial/unedited cookbook...to make it work. Enjoy and let me know, if you had any suggestions.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Last week, I was test driving a PIV Smartcard based PKI as a keystore (via Java PKCS#11)  to support using the PKI/certificate credentials for performing encryption/decryption and digital signature operations  (PKI based logins to Web applications, Encryption/decryption of documents, Digitally signing email). There is no secret receipe but some of you may find it a bit difficult – if you are doing it for first time.  So, here is my quick cheat sheet for your better understanding :

Since J2SE 5.0,  JCE introduced support for the PKCS#11 standard that allows the following:

  • Using hardware cryptographic accelerators for enhancing performance of cryptographic operations.
  • Using smart cards as key stores for key and trust management.

To use these services, it is necessary to install the PKCS#11 implementation provided by the hardware accelerator and smart card vendors. As part of the J2SE 5.0 bundle (and up), Sun facilitates a SunPKCS#11 provider.

To use a smart card as a keystore or trust store, set the javax.net.ssl.keyStoreType and javax.net.ssl.trustStoreType of the Java runtime system properties  to “pkcs11“, and set the javax.net.ssl.keyStore and javax.net.ssl.trustStore system properties to NONE. To specify the use of a vendor smart-card provider, use the javax.net.ssl.keyStoreProvider and javax.net.ssl.trustStoreProvider
Java runtime system properties to identify them. (For example: “SunPKCS11-smart card”). By setting these properties, you can configure an application to use a smart-card keystore with no changes to the application that previously accessed a file-based keystore.

Configuring a Smart card as a Java Keystore (using OpenSC Framework)

OpenSCThe following example shows how to configure OpenSC supported smart card as a Java keystore and list the certificates using the keytool utility. The OpenSC framework can be downloaded from http://www.opensc.org.

  1. Add the OpenSC PKCS#11 module as the keystore provider in java.security file located at $JAVA_HOME/jre/lib/security/java.security.

    security.provider.1=sun.security.pkcs11.SunPKCS11   /opt/openSC/openscpkcs11-solaris.cfg

  2. Create the OpenSC PKCS#11 configuration file. For example, the openscpkcs11-solaris.cfg looks like as follows:
    name = OpenSC-PKCS11
    description = SunPKCS11 w/ OpenSC Smart card Framework
    library = /usr/lib/pkcs11/opensc-pkcs11.so
  3. With the above settings, it is possible to use the smart card as a keystore and retrieve information about the certificates from your Smartcard. For example,  you may use the keytool utility to list certificate entries from a smart card:

$ keytool -keystore NONE -storetype PKCS11 -providerName SunPKCS11-OpenSC -list -v
Enter keystore password: <SMARTCARD_PIN>
Keystore type: PKCS11
Keystore provider: SunPKCS11-OpenSC
Your keystore contains 4 entries

Alias name: Signature
Entry type: keyEntry
Certificate chain length: 1
Owner: SERIALNUMBER=79797900036, GIVENNAME=Nagappan Expire1779,
SURNAME=R, CN=Nagappan (Signature), C=US
Issuer: CN=Nagappan OpenSSL CA, C=US
Serial number: 1000000000102fdf39941
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 12:20:AC:2F:F2:F5:5E:91:0A:53:7A:4B:8A:F7:39:4F
Alias name: Root
Entry type: trustedCertEntry
Owner: CN=Nagappan OpenSSL Root CA, C=US
Issuer: CN=Nagappan OpenSSL Root CA, C=US

Serial number: 11111111111111111111111111111112
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 5A:0F:FD:DB:4F:FC:37:D4:CD:95:17:D5:04:01:6E:73
Alias name: Authentication
Entry type: keyEntry
Certificate chain length: 1
Owner: SERIALNUMBER=79797900036, GIVENNAME=Nagappan Expire1779,
Issuer: CN=Nagappan OpenSSL CA, C=US
Serial number: 1000000000102fd10d2d9
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 29:7E:8A:5C:91:34:9B:05:52:21:4E:49:5B:45:F8:C4


Using Sun Ray DTU as your Smart card Reader

In our case, the customer chose to use Sun Ray as the Smartcard reader where the inserted card is used for performing session mobility and PKI/Certificate based cryptographic operations. To enable access to Smartcard based PKI credentials on Sun Rays, make sure you install the Sun Ray PC/SC Lite to support accessing smart cards. You may download the PC/SC Lite for Sun Ray Server (SRSS 4.x) from:



Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Belgian eID

Belgian eID

Last 3 weeks, been so hectic…the days were faster than light,  I was pulling my-hair-out on a critical proof-of-concept that requires demonstrating Web Single Sign-on (via Sun Java System Access Manager) using PKI/Digital certificate credentials (from Belgian eID) and then enable Smartcard PKI based Desktop authentication/Session Mobility using Sun Rays. The secret sauce on this architecture is using OpenSC PAM and PKCS#11 framework. Interesting to note, OpenSC is not Microsoft friendly !

I can’t dump more details about this effort at this time…(Ofcourse it works…a great relief). I am a bit cautious, that I don’t want to dump crucial information on the web before my guys present it to those Belgian Govt audience.  With all those caution..here is a tip-of-the-iceberg details of my project.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Important Disclaimer:The information presented in this weblog is provided “AS IS” with no warranties, and confers no rights. It solely represents our opinions. This weblog does not represent the thoughts, intentions, plans or strategies of our employers.