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.
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 :
and then proceed with the following steps for deploying a “Hello World” Web application – creating Java card applications can’t get easier than this :
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
Just read this interesting research paper published by Prof. Bobby Tait and Prof. Basie von Solms of the University of Johannesburg (South Africa), explains how a person’s biometric fingerprints/Iris scans can be used as a protocol to perform private key based encryption and digital signatures. The paper describes a biometric middleware infrastructure (BioVault) which requires users to performs biometric authentication for generating or retrieving a random key from user’s keystore. The selected key is used to perform the required encryption or signature operation. If Alice and Bob exchanges messages using their secret key they are required to authenticate with biometrics. The only advantage of this process is the user don’t need to remember a password or carry a smartcard/PIN to support accessing their keystore – as it uses fingerprint or Iris pattern based authentication prior to initiating the operations.
I am not sure, how accurate the solution will be given the “False Acceptance Rate (FAR)” with Biometrics especially with Fingerprints. With all the highest accuracy, as I noted…. Iris recognition’s FAR is 1 in 1.2 million and with Fingerprints FAR may occur 1 in 100,000. And there is no guidance on …how reliable is the solution in case of a MITM attack that compromises the user’s biometric sample….? Still It is an interesting work – but in my opinion using a conventional PKI based solution has its own security advantages over the several inherent reliability issues with biometric authentication.
Lately I’ve been franctically busy with couple of my ISVs and an SI helping them out on a Citizen-scale National Healthcare Identity Infrastructure solution pilot for one of the populous countries in the Atlantic region – Sorry I cannot disclose the country’s name to abide their privacy laws and to protect my job . The solution aims to deliver an Unified Desktop/Voice Infrastructure via Sun Ray environment and fortified by Biometrics and Smartcard PKI based authentication to access the exposed services. Using Smartcard/PKI and Biometrics for Sun Rays has been deployed in production (at few customers) and in practice for a while now… but in my current project the interesting thing is the complete Sun Ray solution will be hosted as a SaaS environment (~Private Cloud) and other complexities are related to legal/privacy issues with performing citizen’s biometric enrollment and storing the biometric information with a private organization (Especially, when the Country’s privacy laws forbids storing citizen’s biometric samples). Keeping those nail biting legal issues aside, the Govt folks are still very enthusiastic and excited about adopting to Biometric authentication for Sun Ray based desktops to access their SaaS hosted Web-based healthcare applications.
Looks cool, Is’nt it. If you are curious to know the secret sauce of the Sun Ray biometric authentication solution, here is the bill of materials, to put together in place:
Shortly, I will update this blog entry with a detailed architecture and deployment cheatsheet… as soon as I wrap up my current project deliverables. If you are a Sun Ray enthusiast, I know you will be having some burning questions ! Feel free to send them, I will try to answer them quick…. otherwise please stay tuned for my unofficial deployment guide.
This stateless infrastructure could be your next generation client for securely accessing your virtual desktops hosted on the cloud
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 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.
Last night, I had the opportunity to present at an OWASP event @Hartford, CT. James McGovern, a long-time buddy of mine organized this event at one of the Hartford skyscrappers – What a great view ! I had contributed code artifacts to OWASP projects before, but it was the first time I had a chance to attend an OWASP event. Amazing to see..it was an enthusiastic crowd with a lot of focus on the emerging trends in IT security. I took a small piece of the IT puzzle.. to present a topic on “Multi-factor Authentication” and then a demo showing OpenSSO w. PKI/Biometric authentication. It was a well-organized event and I saw a lot of interests around OpenSSO.
As promised, here is my slides for your reading pleasure. Enjoy.
A month ago, I had a chance to meet with John Beveridge (Deputy State Auditor at Office of the State Auditor of Massachusetts) at an ISACA event in Boston. During a casual chat, he briefly mentioned about the upcoming regulation highlighting “Mass 201 CMR 17.00 – Massachusetts Standards for Data Protection of Personal Information” and it’s compelling security requirements ! With all curiousity…I had my first dig at Mass 201 CMR 17.00 last week… it is the toughest data protection law so far (as a Govt initiative for preventing identity theft).. I am quite amazed by the stringent rules imposed by this regulation for protecting the personal identity information of Massachusetts residents. I am not a lawyer or an auditor by profession…so here is a my layman interpretation of the regulation and its dictated requirements for securing personal identity information.
Mass 201 CMR 17 data protection requirements aligns well with Federal Trade Commission’s Red Flag rules on Identity Theft Prevention. Some of the security practices has already been in use at many big companies addressing PCI-DSS, GLBA and HIPAA requirements. At the outset, this is a big business boost to Security architects and consulting companies deal with providing Information Security and identity management infrastructure and solutions. This regulation supposed to be effective on Jan 1, 2009 and now for some reasons the deadline is extended till May 1, 2009 – Not sure it helps everyone – but the deadline for compliance is chasing and not too far !