Core Security Patterns Weblog

Looks like convergence projects are in the limelight… lately I noticed a lot of interests on enabling the use of common credentials for securely accessing physical and logical resources.  Although we find most convergence projects are targeted at the enterprise level but there are serious minds working on using smartcard based PKI credentials for supporting citizen-scale projects (I regret that I cannot discuss the specifics) !  Ofcourse the use of on-card PKI credentials and its on-demand verification with the PKI service provider is in practice for a while now at security sensitive organizations. The DoD CAC, PIV and most smartcard based National ID/eIDs contain PKI certificate credentials and few of them includes Biometric samples of the card holder as well. Using those on-card identity credentials for accessing physical and logical resources becomes critical and also makes sense to  fulfil the ultimate purpose of issuing smartcard based credentials… it cannot be overstated.

Couple of weeks ago, I had a chance to present and demonstrate PIV card credentials based logical access control using Sun IDM, OpenSSO Enterprise, WinXP running on Sun Ray environment. The demo was hosted  one of the Big5 SI.  If you curious to see my preso detailing the pieces of the puzzle…here you go:

Java Card technology has been a passion of mine for so long and I always tried my best to keep updated on Smart card technologies…… not just because of my role at Sun, I did get several opportunities to work closely with citizen-scale Java Card deployments with multiple National ID, eID/ICAO, US DoD/CAC, PIV/FIPS-201 cards and related Identity management projects.  It is always been quite adventurous everytime to experience a card issuance architecture and deployment scenario – right from applicant enrollment, demographic data provisioning, Biometrics/PKI credentialing, adjudication/background checks, post-issuance maintenance including card authentication/verification/usage and final retirement/termination.  In the early 2000′s, I even had an opportunity to write couple of Java Card applets for a big 5 financial organization using Java Card 2.x and it is still exists on production (No kidding! one of them may be in your wallet). With all those experiences, I did have my own stumbling issues with programming Smartcards, where I pulled my hair-out on understanding those evil ”Application Protocol Data Units” (APDU) based commands and responses. In my opinion, APDUs are quite complex to understand when you jump in unless you read the docs in-and-out beforehand and then test-driving APDUs are even more hard unless you have the luxury of having a debugging environment –  seriously, you may not want to experience those pains.  Havingsaid, now we can breathe a sigh of relief – I am bit late to experience the newer features of Java Card 3.0 -  It has introduced “network-centric” and “Java/J2EE developer” friendly features that radically changed the way we originally designed, developed, deployed, and integrated Smartcard applications.  Interestingly, there are very compelling aspects about Java Card 3.0 technology -  As I digged with my little experience… here is my observations.  

Understanding Java Card 3.0  

1. A Smartcard can act as a ”Personal Web Application Server”  or an user-centric miniature Java EE application server on a network.  Java Card 3.0 has introduced a Servlet container environment referred to as “Connected Edition” – which allows the smartcard applications can built as Java servlets (Web applications) using Servlet 2.4 APIs and deployed as a “WAR” file to the Web container running on a Java Card 3.0 compliant Smart card. This Servlet based deployment is an addition to existing Java card applet deployment model referred to as Classic Edition (exists with Java card 2.2.x). The Java Card clients access the applications using a Web browser (ex. http://localhost:8019/myJavaCardServlet).   
   

   Java Card Platform - Architecture

2. Java Card 3.0 supports 32-bit processor based Smartcards and handles more memory – upto 128k.
3. Enough with pain of understanding/testing APDUs, now you can readily develop Java Servlet 2.4 API compliant Web applications and deploy them to a Smart card.
4. With Java Card 3.0, we can perform interact with using standards based communication with the card using HTTP/HTTPS and also its supporting XML based protocols such as SOAP, REST etc.
5. Support for Java crypto APIs and additionally you can enable access control with the card similiar to performing container-managed authentication in Java EE – using SSL/TLS mechanisms.     
   

   Java card 3.0 - Communication Protocols

    

    

6. Java Card 3.0 based Web applications can be developed, debugged and deployed using Netbeans 6.7.1 and up.
7. Smart card issuance (for Card holders) and updates using GCF can be done through Web based deployment model (via HTTP, TCP) – using both contact and contactless communication interfaces.
8. Other features include full Java language support (Java 1.6 features) including all data types (except float and double), multi-threading, garbage collection, XML parsing/generation capabilities etc.
9. Allows Java developers to explore Java Card platform easily with strong potential for deploying security applications intended for National ID card schemes, passports and simplifying deployment of  ”Match-to-card Biometrics”, “On-card” credential persistence and secure transaction based applications.

Try it yourself

If you are curious to test drive Java Card 3.0 reference implementation especially using its “Connected Edition” to deploy Java Servlet based application to Smart card - Before you begin, make sure you obtain the list of pre-requistes :

1. Java Card Connected Development Kit 3.0.1
2. Netbeans 6.7.1

and then proceed with the following steps for deploying a “Hello World” Web application – creating Java card applications can’t get easier than this :

1. Install the Java Card 3.0 plugins for Netbeans 6.7.1 – Go to Tools, Plugins and search for card to select plugins for “Java Card Projects” and “Java Card Console”.  

   

   Installing Java Card plugins for Netbeans

    

2.  Go to Netbeans IDE,  Choose Project – “Java Card” and select Projects type “Web Project”. 
   

   Creating a Java Card "Web project"

3.  Assign Project name/location/folder and then select “Manage Platforms” to assign the Java Card 3.0 runtime environment.   

    

    

   

   Assigning Java Card Runtime Info

    

    

4.  To assign the Java Card runtime info, select “Manage Platforms” and choose “Platform type” to Java Card Platform.  
   

   Choosing Java Card as runtime

5.  Select the location of your ”Java Card 3.0 Connected Edition Dev kit” installation. 

     

    

   

   Select "Java Card 3.0" Connected Edition

    

6.  Define the default device (assuming your Smartcard) attributes and press “Finish”: 
   

   Select your "Java Card"

    

7.  As a result, you should see the Netbeans console showing your “Java Card Platform” environment for test-driving your applications.     
8. With above steps complete, now you are ready to develop/debug/deploy your Java Card web applications…. here is my first “Hello World” Java Card Web application excercise.       
9.  Compile the application -  In the Projects window, right-click the project node and choose Build to build the project.     
10. To deploy and run the Web application from your target Smartcard device (in my case the JavaCard RI), In the Projects window, right-click the project node and choose Load/Create Instance or just Run to run the application.  Netbeans will launch the browser, displaying the Hello world application prompting for your name….  and push the button to see – what happens !    

Netbeans does all the magic for you – if something not working, no worries ! Like implementing anyother Web application in IDE,  it is now easy for you to painlessly debug and redeploy the application – I am sure, you’ll find deploying applications on Java Card is nolonger a mystery.

With Billions+ Java Cards already in use and so much demand for the Smartcard technology,  Java Card 3.0 promises beyond citizen IDs and can potentially act as your “Personal Web application server” on your wallet.

Thanks to Anki Nelaturu and Saqib Ahmad who introduced me to Java Card 3 with their JavaOne ’09 sessions. After playing with my first excercise on Java Card 3.0 RI, now I am chasing my friendly Smartcard vendors to loan me couple of Java Card 3.0 cards

Lately, Biometric identification and authentication technologies gaining unprecedented importance in government organizations across the globe as evidenced in the US by introduction of HSPD-12, HSPD-24 and and other countries complying with ICAO requirements for biometric-enhanced machined readable traveller documents (MRTDs) / ePassports providing support for Facial/Fingerprint identification for travelers passing through airports, security-sensitive locations and ensuring protection against identity thefts.

I just came across this interesting prediction and analysis  by Matia Grossi, Frost & Sullivan’s industry analyst, – highlights:

• Biometric technology adoption will triple by 2012 from its 2008 value.
• Biometric technologies are getting increased attention in commercial markets particularly the financial, healthcare, retail and educational sectors.
• Technologies currently gaining momentum include face recognition 2D/3D, Iris scans, Hand geometry, Vascular scans (palm vein scans), and Retina scans. Upcoming physiological technologies will be skinprints, earlobe scans, brain fingerprints, and DNA recognition.
• By 2020, Multimodal biometrics using combination of fingerprint, Face, and Iris will emerge as the standard biometric identification solution for  government, border control and airport security applications.

I did’nt have a chance to read the complete report….all I read was the highlights of the report by Matia Grossi, Frost & Sullivan’s industry analyst…right here. If you are curious about using Biometric technologies for enabling Physical and Logical Access Control…read my earlier posts on Biometric SSO Authentication and Provisioning/De-provisioning Biometrics for Physical and Logical Access Control.

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

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

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.

It’s been a while, I had been hearing a lot of talk about unified biometric credentials and using then for convergence of physical and logical access control systems – Like me, you might’ve heard a lot of high-level marketing or analyst’s stuff … so here is some realities from my hands-on experience ! Frankly, there is no magic silver bullet that allows to support provisioning credentials to and from every Biometric middleware providers on the earth (poor standards..they are all proprietary) and it is another uphill task supporting their biometric data provisioning requirements to physical/logical access control systems (PACS and LACS).  With Sun Identity Manager, we can support selected biometric middleware integration through resource adapters but the complexity grows greater when we require provisioning of biometric data to a growing list of biometric middleware (AuthN providers, AFIS systems), PACS, LACS and Smart card management systems (CMS).  Lately, I had been working on a couple of interesting “Convergence” proof-of-concepts for ISVs aligned with PIV and National eID projects. Although it sounds great, converging the biometric credentials with heterogenous systems is not a trivial job, particularly when provisioning them for  smart card issuance  and further support post-issuance scenarios of enabling on-card/off-card biometric data for identification and authentication of individuals at heterogenous PACS and LACS systems. After thoroughly looking into the bottom of the issue, realizing and test-driving several usecases, with no option it become critical for us to enable biometric data as a managed attribute in Identity Manager – to support provisioning/de-provisioning of biometric data, changes and its associated reconciliation operations with PACS and LACS. This certainly helped us to exercise control on those discrete PACS/LACS resources that required provisioning of biometric credentials (for authentication/identification) and then ensuring no back-door account entry exists with the biometric middleware that circumvents IDM initiated biometric enrollment processes or rogue smart card issuance requests. This mandated us the Identity manager to support managing the complete provisioning/de-provisioning lifecycle of the user enrolled biometric information (i.e FIngerprints in CBEFF/INCITS-378 templates, Iris Image Interchange format/INCITS-379 templates, Facial images etc).

With Sun Identity Manager, we accomplished this through interfacing with biometric enrollment systems and enabled support provisioning/de-provisioning/reconciliation of biometric information by extending the identity attributes and establishing a managed database resource that stores CBEFF data as a CLOB.

Pre-requisites:

1. IDM Resource adapter that supports provisioning/de-provisioning/reconcilliation of user accounts with Biometric enrollment middleware.  Alternatively, you would able integrate through Java BioAPI (JNI Wrapper) if the biometric provider support BioAPI.
2. IDM access to Biometric enrollment repository database as a managed resource – Configured as a database resource. This resource is enabled with read-only access to the CBEFF information of the biometric enrollment system.
3. Extend the user attributes to include a Text/String attribute (bioAttribute) that identifies “Biometric Information”.
4. Ensure all user forms of target resources are updated to include a derivation that identifies the bioAttribute.
   <Field name=’accounts[$(TARGET_BIOMETRIC_RESOURCE_NAME)].bioAttribute’>
   <Display class=’Text’>
   <Property name=’title’ value=’bioAttribute’/>
   </Display>
   <Derivation>
   <ref>accounts[Database Table].pivData</ref>
   </Derivation>
   </Field>
5. Configure the  resource adpaters that requires provisioning of biometric information.  Incase, of provisioning of PIV Smart cards you may choose to use the XML Resource Adapter that captures all the demographic data and it can be combined to use the CBEFF information available from the ‘bioAttribute’ data obtained from the database resource.

We verified this solution with selected Biometric vendors and Smart card management systems (CMS) to support enabling “Convergence of biometric credentials use with Physical access control systems (PACS) and Logical access control systems (Using biometrics for Web SSO, Federation, Desktop authentication etc) . Sorry folks, I intentionally avoided identifying the vendor names to avoid any conflicts with my friendly ISV peers.

A picture is worth a thousand words. This picture is intended for a friend of mine (a doubting Thomas), who did’nt believe my latest work on enabling a multi-factor authentication based “Web SSO” that uses on-card credentials (PIN + PKI + Biometrics) using PIV card. This solution is currently tested to run Sun OpenSSO Enterprise 8 (running on Glassfish v2), ActivClient (from ActivIdentity) and BioSP (from Aware) and PIV Smartcards on a Sun Ray environment. It works. If you are curious to know this special sauce, please bear with me. I will post the documentation including solution ingredients and other configuration details …very soon.

Last week, I was at the 7th Annual Smart Card in Government Conference and had the  opportunity to join a panel on “Personal Identity Verification (PIV) – Technologies” and presented a session entitled “Managing PIV Lifecycle and Converging Physical and Logical Access Control” with emphasis on implementing HSPD-12/FIPS-201 mandates.  I thoroughly enjoyed my participation in the conference, particularly the overwhelming  Smartcard and Biometric interests  from US Federal Govt organization, Law enforcement, Defence agencies and from other countries as well.

It is quite compelling to note,  the conference gave a big boost to FIPS-201 specfications that has become

Source: GSA USAccess

the de-facto standard for Identity credentialing for Govt. Employee ID, First Responder Credentials, Airport/Transportation worker credentials, Electronic Passports (ePassports) and  also sets the standards for acquiring and incorporating Demographic data, PKI/certificates and Biometrics for enabling Physical and Logical access control.

During my presence, I had quite a lot of conversations with participants for Govt agencies,  SIs and ISVs about implementing FIPS-201/PIV solution and how to automate identity credentialing  and pre/post issuance processes and provisioning/de-provisiong credentails to Physical access control systems and Logical access control systems (SSO/Federation) and finally how to respond to managing and auditing those discrete processes.

Managing PIV Life-cycle

If you are curious to have my presentation slides, you may grab it here : Managing PIV Lifecycle and Converging Physical and Logical Access Control.

Enjoy.