04-06-2012, 12:10 PM
Java Card Biometric API White Paper
java card- a biometric api.doc (Size: 234.5 KB / Downloads: 56)
ABSTRACT
Java Card has benefited from interoperability both at the binary and the Application Programming Interface (API) level. Biometric technologies can build on this foundation by way of a high level and biometric neutral on-card API. The Java Card Forum has addressed this need with a concise internal application programming interface within the Java Card. Specifically, this API supports secure biometric Match-on-Card so that sensitive biometric data never leaves the card, all while consuming a minimal footprint of memory. This paper describes the requirements, rationale and design of a biometric API for Java Card that evolved under the purview of the Java Card Forum Biometric Task Force and the Biometric Consortium Working Group. The API builds on existing Java Card API designs for security and maximal functionality.
INTRODUCTION
As Java Cards grow into today's smallest standardized computing platform, developers wish to ensure the interoperability of many biometric technologies with Java Cards, and
to allow multiple, independent applications on a card to access the biometric functionality of that card. The Java Card Forum (JCF) [4] addresses this need with an card-internal
API within the Java Card (JC). This paper presents this JC biometric API, and offers guidance for the usage of this API.
The API is developed and accepted by the members of the Java Card Forum Biometric Task Force. It has also been presented to and received feedback from the NIST Biometric Consortium Working Group [9].
Java Cards
Access to a Java Card’s data is usually gained via a PIN code, password, or decryption key; biometrics implemented with match-on-card may also be used. Thus modest amounts of very sensitive data (such as passwords, financial records, and medical records) may be stored on a smart card with much greater safety than, for instance, the
hard disk of a desktop system, and may even help avoid the need to transmit this sensitive data over a potentially unreliable network link.
A drawback of Java Card Virtual Machine (JCVM) interpretation of Java programs is that the execution is typically slower than for code compiled directly to the processor's native machine instructions. In some cases, this performance penalty can be circumvented by providing a native code version of the function (linked through the JCVM). Because native code must be trusted code that is specifically written to respect the Java firewalls, it may only be placed on the card prior to card issuance. Native routines cannot be added after card issuance.
Biometrics Verification
To use a biometric for either verification, the enrollment acquires an initial biometric image from the individual in question. This image may be processed to extract characteristic features from the image.
Biometric Match on Card
Because applications usually use biometrics to enhance security, they must also handle
the biometric data in a secure fashion, much as is the case for computer passwords or PIN codes. This need for secure storage is heightened by the fact that a person’s biometric cannot be changed as is done when a password is compromised. Smart cards offer an ideal platform for the handling of biometric data, as their data storage and processing
offer great security. If an application stores enrolled biometric data in a central database then a compromise of security on the database would reveal the biometric data for the entire population of users. If, on the other hand, the biometric data is stored on individual smart cards then that risk is avoided. The application then also avoids the risk of transmitting the biometric data over potentially unsafe or failure-prone networks. Yet the sensitive biometric data might still be threatened if it must be extracted from the card for off-card match comparison. For greater security, the match processing may be performed on the card; with this Match-On-Card (MOC), the enrolled biometric data never leaves
the secure environment of the card. This is especially attractive when used to access sensitive data inside the card, such as medical records or a signature key; in this case, both the protected information and the security that implements the protection are isolated in the trusted environment of the Java Card. Thus we see a type of nested security where the card and the biometry work in concert to secure each other.
A Biometric API for Java Card
Given the many biometric technology vendors and the several vendors of Java Cards, combined with the huge number of potential biometric applications, the prospect of designing special interfaces for each combination of biometric, card, and client application is clearly impractical. A widespread adoption of biometrics on Java Cards
will require product interoperability.
Thus, the Java Card Forum presents an on-card Biometric API that allows an application to function on various Java Cards and use various biometric technologies. This paper describes the motivation behind the JC Biometric API and how it can be used to facilitate the development of biometric-enabled applications.
ARCHITECTURE
In creation of the JC Biometric API, the greatest challenge was to resolve the requirements of a flexible system able to support the large variety of technologies, while at the same time remaining small and simple enough to fit inside the limited resources of a Java Card. The chosen API is designed to support the large majority of technologies with little or no modifications, and it includes only the core functionality for biometrics.
As shown in Figure 3, the API acts as an interface between one or more matching algorithms and the on-card applets that make use of the biometrics. This figure also shows the place of the biometric enabled Java Card within the context of a larger biometric system that includes a biometric sensor and a PC.