Web Security Patterns - Page 5 of 11 - a practitioner's notes on security best practices, pitfalls, sʞɔɐɥ and fixes

Java Card 3.0: Deploying and Running "Web applications" on Smartcard.

Ramesh September 1, 2009 13 Comments

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

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
Java Card 3.0 supports 32-bit processor based Smartcards and handles more memory – upto 128k.
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.
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.
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
Java Card 3.0 based Web applications can be developed, debugged and deployed using Netbeans 6.7.1 and up.
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.
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.
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 :

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

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
Go to Netbeans IDE, Choose Project – “Java Card” and select Projects type “Web Project”.
Assign Project name/location/folder and then select “Manage Platforms” to assign the Java Card 3.0 runtime environment.

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

Choosing Java Card as runtime
Select the location of your “Java Card 3.0 Connected Edition Dev kit” installation.
Define the default device (assuming your Smartcard) attributes and press “Finish”:
As a result, you should see the Netbeans console showing your “Java Card Platform” environment for test-driving your applications.
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.
Compile the application – In the Projects window, right-click the project node and choose Build to build the project.
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 🙂

Are you a victim of Identity theft ?

Ramesh August 14, 2009 No Comments

Just came across this interesting web site – NationalIDWatch.org a consumer protection web site by Liberty Coalition, which provides a registry of personalized data breach reports… that reports whether your personal identity information has been stolen or publicly exposed or not ! If your identity information is compromised, it indicates the size of exposure, sensitivity and how it is distributed and so forth ! The web site does guarantee that the report is not intended to sell anything besides reporting personal data breaches. I am not affiliated with this organization also not sure how accurate the information is and its authenticity…. still you can verify for yourself..to see if you are a victim of an Identity theft or exposure !

http://www.nationalidwatch.org/

Enabling FIPS-140 compliance for Java based SSL/TLS applications

Ramesh August 12, 2009 5 Comments

FIPS-140* compliance has gained overwhelming attention these days and it has become a mandatory requirement for several security sensitive applications (mostly in Government and Security solutions and recently with select finance industry solutions and particularly for achieving compliance with regulatory mandates such as PCI DSS, FISMA, HIPPA, etc ). FIPS-140 also helps defining security requirements for supporting integration with cryptographic hardware and software tokens. Ensuring FIPS compliance to Java based application security has been one of demanding needs of security enthusiasts but unfortunately neither Sun JCE or JSSE is not yet FIPS-140 certified – hopefully soon ! Sun JDK 6 (and above) has also introduced several enhancements including support for enabling FIPS-140 compliance for Sun JSSE using FIPS-140 certified cryptographic providers for supporting SSL/TLS communication and associated cryptographic operations. To accomplish this, Java 6 uses the PKCS#11 support for JSSE to integrate with PKCS#11 based FIPS-140 cryptographic token.

Lately I worked on a security solution using SunJSSE with NSS as a software cryptographic token… and here is my tipsheet for those keen on playing FIPS conformance with SunJSSE.

SunJSSE can be configured to run on FIPS-140 compliant mode as long as it uses a FIPS-140 certified cryptographic hardware or software provider that implements all cryptographic algorithms required by JSSE (ex. Network Security Services – NSS, Sun Cryptographic Accelerator 6000, nCipher, etc).

To enable FIPS mode, edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider and associate the name of the FIPS-140 cryptographic provider (ex. SunPKCS11-NSS). The name of the provider is a string that concatenates the prefix SunPKCS11- with the name of the specified PKCS#11 provider in its configuration file.

security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

In case of using NSS as cryptographic software token (Make use of NSS 3.1.1. or above), assuming the libraries are located under the /opt/nss/lib directory and its key database files (with the suffix .db) are under the /opt/nss/fipsdb directory, the sample configuration for representing NSS will be as follows:

                           # Use NSS as a FIPS-140 compliant cryptographic token
                           # SunPKCS11-NSS
                          name = NSS
                          nssLibraryDirectory = /opt/nss/lib
                          nssSecmodDirectory = /opt/nss/fipsdb
                          nssModule = fips

In FIPS mode, SunJSSE will perform SSL/TLS 1.0 based communication and cryptographic operations including symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.
To refer to the SunJSSE supported Ciphersuites suites refer to the Sun JSSE’s documentation and notes for FIPS guidance.

* FIPS-140 is a US Federal data security standard approved by the National Institute of Standards and Technology (NIST) – The current version is FIPS-140-2. All US government agencies are mandated to use only FIPS-conformant/validated products for deploying security sensitive applications and solutions.

Biometrics based Encryption & Digital Signatures ?

Ramesh August 6, 2009 No Comments

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.

Dilbert on IT Auditing and Compliance reporting :-)

Ramesh July 12, 2009 No Comments

Just got this Dilbert comic strip from a friend of mine… pokes fun to highlight the importance of IT auditing and compliance reporting.

Fortifying Sun Ray Desktops with Biometric Authentication

Ramesh June 1, 2009 1 Comment

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.

Biometric Authentication on a Sun Ray environment

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:

Sun Ray Session Server 4.x or above
Solaris 10 X64 or SPARC
Sun OpenSSO (Biometric SSO for Web applications)
Sun Identity Manager (Provisioning Biometric Samples during enrollment)
Sun Directory Server
Sun Secure Global Desktop (Support accessing Windows, Mac, Linux, Solaris Desktops)
Oracle 11g or MySQL 5.x database
BiObex Authentication Middleware (Advanced Biometric Controls)
Hamster Plus – USB Biometric Scanner (SecuGen) – For supporting Desktop/Web authentication
CrossMatch Verifier E – Biometric Scanner for supporting Biometric enrollment

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 🙂