Enabling Technologies | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Before we delve into the mechanisms and architectural strategies, it is quite important to understand the enabling technologies that contribute to implementing and incorporating smart card and biometric authentication mechanisms in an IT environment.

Java Card API

The Java Card API framework provides a run-time environment and a set of class libraries for developing and deploying secure Java Card applets in Java Card-compliant smart cards. It includes a subset of cryptography and security packages from the J2SE platform. These cryptography and security packages support the smart card applet development and deployment operations with regard to implementing authentication and secure downloading, installing, and deleting of Java Card applets. To facilitate those operations, the Java Card API framework provides the following algorithms and supporting API mechanisms:

Symmetric encryption and decryption algorithms
Asymmetric encryption and decryption algorithms
Key interfaces
Signature generation and verification
Message digests
Random data generation
PIN management

Most smart card vendors provide support for the Java Card API and the Java Card Virtual Machine. The Java Card API is available as part of the Java Card Runtime Environment (JCRE) from Sun Microsystems. For more information about security in the Java Card runtime environment, refer to Chapter 3, "The Java 2 Platform Security."

Global Platform

The Global Platform delivers standards for portable and interoperable infrastructure smart card solutions. It supports implementation on a wide range of systems, including card reader devices, PDAs, mobile phones, contactless chip technology, and infrared devices. The Global Platform-based Java Card delivers a hardware-neutral OS with compatibility and interoperability among smart cards, smart card readers, applications, devices, card personalization systems, and key management systems. Global Platform enables smart cards to run multiple applications as a multi-application enabled card. This helps a card holder to use his or her card as an authentication token in order to gain access to privileged areas. The smart card can also be used for personal data storage of medical and financial information. For more information about Global Platform, refer to the Web site located at http://www.globalplatform.org/.

The Global Platform Card Specification v2.1.1 is recognized by the ISO to support the ISO IEC* 7816 standard series for smart cardsthe ISO/IEC 7816 part 13 standard, which is for application management in a multi-application environment. The Global Platform contribution was also supported by the U.S. International Committee for Information Technology Standards (INCITS) and the American National Standards Institute (ANSI).

PKCS#11

PKCS#11 is an RSA cryptographic token interface standard that defines an application programming interface (API) for performing cryptographic operations on hardware-based security devices, including smart cards. It defines device independence and resource sharing so that multiple applications can access the cryptographic token. Most operating systems and Web browsers provide support for integrating hardware-based cryptographic operations via PKCS#11 interfaces.

PKCS#15

PKCS#15 is an RSA cryptographic token format standard that defines storage of keys on smart cards, devices, and other conventional hardware tokens/IC cards. Most smart card-based National Ids (such as Belgium's eID, Finland's FINEID, Malaysia's MyKad, and Sweden's SEIS) conform to the PKCS#15 standard.

PC/SC Framework

PC/SC defines the architecture for the integration of smart card readers and the use of smart cards in a PC-based environment. PC/SC ensures interoperability through vendor independence among smart card readers and smart card products, PC applications, and card issuers. PC/SC also defines device-independent APIs and resource management to allow multiple applications to share smart card devices. This has led to a common interface for using smart cards and readers. Most vendors provide PC/SC-compliant drivers to support their smart card infrastructure.

For more information about understanding the PC/SC Framework, refer to the PC/SC Workgroup specifications available at http://www.pcscworkgroup.com/specifications/overview.php.

OpenCard Framework (OCF)

OCF provides standardized Java API mechanisms to facilitate the entire life cycle of smart card application development and deployment. It delivers an open architecture-based interoperable application environment and APIs for developing and deploying smart card applications meeting the needs of a wide range of smart card reader terminals (that is, card acceptance devices), card operating system providers, card issuers, and card holders. Using OCF helps smart card application developers and providers with a vendor-independent platform. This means that the developers follow the OpenCard interfaces for developing smart card applications, and providers adhere to OCF interfaces so that the smart cards and card reader devices can deploy and run OCF-based applications.

OCF plays a vital role in developing smart card authentication solutions and in managing biometric information to use with Match-on-the-Card scenarios that involves storing and matching biometric samples on the card. OCF supports all Java-enabled platforms and ISO 7816-compliant devices, such as Personal Computers (PCs), servers, automatic teller machines (ATMs), point-of-sales terminals, set-top boxes, and handheld devices. The OCF implementations also support existing PC/SC 1.0-supported reader devices. A reference implementation of OCF is publicly available for download at http://www.opencard.org. For more information about OCF, refer to the architecture and developer guide available at http://www.opencard.org/index-docs.shtml.

OpenSC

OpenSC is an open source framework initiative for enabling smart cards to support security operations. It provides a set of API libraries and tools for integrating smart card readers and accessing to smart cards. The OpenSC framework focuses on running cryptographic operations and facilitates smart card use in security applications such as mail encryption, authentication, and digital signature. OpenSC provides implements the PKCS#11 API so that applications supporting this API on operating systems such as Linux, Windows and Solaris and Web browsers/e-mail clients such as Mozilla, Firefox and Thunderbird can use it. OpenSC also implements the PKCS#15 standard.

For more information on using OpenSC framework, refer to the architecture and developer guide available at http://www.opensc.org/docs.php

BioAPI

The BioAPI is a standardized API for developing personal identification applications that interface with biometric verification devices such as fingerprint scanners, facial recognition devices, iris and retina scanners, voice recognition systems, and so forth. It was developed by a consortium consisting of industry vendors that support biometric technologies. The BioAPI Version 1.1 [refer BioAPI] is an approved standard that is compliant with the Common Biometric Exchange File Format (CBEFF). The BioAPI is also accepted by the American National Standards Institute (ANSI). BioAPI facilitates development and deployment of biometrics-based personal verification and authentication in a vendor-neutral way with standardized interfaces, modular access to biometric matching algorithms, and support for running across heterogeneous platforms and operating systems. For more information about BioAPI, refer to the Web site for the BioAPI Consortium located at http://www.bioapi.org/.

To support Biometrics Match-on-the-Card and Match-off-the-Card requirements, The Java Card Forum Biometric Task Force and the NIST Biometric Consortium Working Group have developed a Java Card Biometric API specification that defines API mechanisms to facilitate integration of the Java Card API with biometric authentication. This specification provides all required biometric authentication functions, such as enrollment, verification, and identification processes of a biometric service provider (BSP). For more information about the Java Card Biometric API, refer to the API specification located at http://www.javacardforum.org/Documents/JCFBioAPIV1A.pdf.

Pluggable Authentication Module (PAM)

PAM allows applications and OSs to be independent of authentication mechanisms in a UNIX environment, particularly Solaris and Linux. The PAM framework supports multiple authentication service modules configured as a authentication stack. The authentication service modules are a set of dynamically loadable objects invoked by the PAM API to provide a particular type of user authentication. PAM gives system administrators the flexibility to choose any authentication service available on the system to perform authentication. New authentication service modules can also be plugged in and made available without modifying the applications.

PAM allows implementing login modules for different authentication technologies, such as RSA, Kerberos, smart cards, biometrics, and so forth. PAM-based authentication modules can be plugged into the UNIX environment for system authentication, access control, and other related management tasks such as provider administration and account management. The core components of the PAM framework are the PAM API library (PAM API), PAM authentication module, and PAM Service provider interfaces (SPI). Applications implement PAM APIs to communicate with PAM modules for enabling authentication. Authentication service providers implement PAM modules using SPI. To initiate authentication, the application calls the PAM API that loads the appropriate authentication module defined in a configuration file. Then the request is forwarded to the underlying authentication module, which in turn communicates with the authentication service provider. The authentication module returns a response back to the application from the underlying authentication service provider. PAM allows a system administrator to add newer authentication methods simply by installing new PAM modules and to modify authentication policies by editing associated configuration files. In most UNIX environments, a PAM policy file is defined in a /etc/pam.conf or /etc/pam.d configuration file. This file specifies all the PAM policies for a system, such as terms of service name, facility name, control flag, module name, and module arguments:

login   auth    required    pam_biologin.so  bio_finger

The configuration fields are usually represented in the order of service name, facility name, control flag, module name, and module arguments. Any additional fields are interpreted as additional module arguments.

Smart card and Biometrics vendors provide PAM modules for integration with application and UNIX environments. PAM also facilitates multifactor authentication, which allows combining smart cards and biometricsstoring biometric samples of the person who is the smart card holder. During authentication, PAM acquires the biometric sample from the scanner and matches it with the value stored in the smart card of the sample presented at enrollment in order to allow or deny user access. For more information about PAM modules, refer to the Sun Web site at http://www.sun.com/software/solaris/pam.

Graphical Identification and Authentication (GINA)

GINA is a Windows dynamically linked library (DLL) in the Microsoft Windows environment that handles the default authentication process and initiates user interaction by presenting the Windows logon window. The default GINA library can be replaced with custom authentication mechanisms built using Microsoft authentication functions, interfaces, objects, structures, and other programming elements. This facilitates using a custom GINA library in the Windows environment to represent different authentication technologies, such as RSA, Kerberos, smart cards, biometrics, and so forth. Windows does not allow stacking of authentication modules, and therefore only a single GINA can be active at one time.

By default, Microsoft provides a GINA DLL in all their operating systems. In a typical Windows installation, the GINA DLL file called msgina.dll can be found by searching the Windows libraries (for example, in Windows XP, it is made available at C:\WINDOWS\systems). To load or replace the default GINA DLL with a custom GINA representing an authentication provider, it is necessary to change the appropriate registry key representing msgina.dll. The custom GINA is also responsible for setting itself up to receive secure attention sequence (SAS) events for logging and auditing. In Windows, SAS events define the key sequence for initiating the logging process (for example, CTRL+ALT+DEL SAS event).

The Windows CE environment provides support for smart cards by way of registering smart cards as CSPs (Cryptographic Service Providers). Refer to the Windows CE .NET documentation for using smart card subsystems (http://msdn.microsoft.com).

Java Authentication and Authorization Service (JAAS)

JAAS is a Java-based API framework that allows implementing authentication and authorization mechanisms in Java applications. It implements a Java technology version of the standard PAM framework. JAAS allows J2EE applications to remain independent from underlying authentication technologies. J2EE allows plugging in security providers as JAAS LoginModules for use with J2EE application components without requiring modifications to the application itself. JAAS is commonly used for integrating authentication technologies such as RSA SecurID, Kerberos, smart cards, biometrics, and so forth.

In a J2EE environment, JAAS LoginModules are usually configured as Realms that map applications and their user roles to a specific authentication process. Configuring realms is more vendor-specific; refer to the vendor documentation on how to configure realms using JAAS LoginModules in a J2EE application server.

For more information about using JAAS APIs and implementing JAAS login modules, refer to the section "Java Authentication and Authorization Service" in Chapter 4, "Java Extensible Security Architecture and APIs."