Smart Card-Based Identification and Authentication

To provide smart card-based identification and authentication for logical access control, the choice of technology and implementation model is greatly influenced by the environment-specific characteristics and dependencies in terms of client application type (Web-based, rich-client, or desktop login), platform implementation (Java or Microsoft), and host environment (UNIX or Windows). In this section, we discuss the tools of the trade, architectural strategies for enabling smart card-based identification and authentication for controlling access to J2EE-based applications, and Desktop Login for host systems such as UNIX and Windows workstations.

To enable smart card-based identification and authentication for physical access control, it is always recommended to use smart cards with dual interfaces for supporting contact and contactless readers. This allows the card to be inserted or presented for identification or authentication at both traditional smart card readers and contactless card readers (using proximity technologies) commonly used for door access in restricted locations and buildings.

Let's take a look now at the architecture and implementation model for enabling smart card-based authentication for J2EE applications in UNIX and Windows environments.

Architecture and Implementation Model

The basic principles behind the architecture and implementation of smart card authentication for J2EE applications are quite typical to integration of a security provider infrastructure with a J2EE application server. JAAS is the primary representative technology for enabling custom authentication in a J2EE environment. In UNIX and Windows environments, incorporating smart card authentication is done by plugging in PAM and GINA modules, respectively.

Let's take a closer look at the logical architecture and the infrastructure components necessary for building the smart card-enabled authentication in an enterprise IT infrastructure.

Logical Architecture

Figure 15-1 represents a logical architecture showing a smart card authentication-enabled application infrastructure involving J2EE applications, Solaris, Linux, and Windows environments.

Figure 15-1. Smart card authenticationlogical architecture

Let's explore the logical architecture in terms of its infrastructure components and its role in enabling smart card-based authentication.

Smart Cards

Smart cards provided by a card vendor include the Smart Card OS and card management utilities. Most cards have the capability to run multiple applications and store personal and biometrics templates. It is also important that the card be PKCS#15-compliant so that it can support storing certificates and can execute PKI operations on the card. Most smart card vendors provide support for Global Platform, PC/SC, Java Card, and PKCS#11 interface specifications. The card also provides an adequate amount of memory to meet the storage requirements of the application. The card issuer usually pre-installs the card with Card Unique Identifier (CUID), Private Key, and a Certificate (X.509 certificate with public key). The user sets the PIN during enrollment.

Smart Card Readers

Smart card readers (also referred to as Card Acceptance Devices) are usually provided by a card vendor, which also supplies drivers (for example. PC/SC drivers, PKCS#11 Modules) that support host operating systems such as Solaris, Linux, and Windows. The smart card readers interface with a desktop workstation or a notebook computer environment using standard connectors such as Serial, USB, or PCMCIA devices. The card reader device handles all card operations with the inserted card, such as card personalization, loading, and updating card applications and certificates.

Smart Card Enrollment/Personalization System

The smart card enrollment and personalization system is usually provided by a card vendor. The system facilitates enrolling a person to a smart card and registering the person's identification information. The system does this by capturing personal information, CUID, digitized photo, PIN, biometric sample, private key, certificate, and so forth. All enrollment information entries will be stored to a directory infrastructure. After enrollment, the system is responsible for securely loading the selected enrollment and personal information to the card by way of a Hardware Security Module (HSM) using PKCS#11 interfaces. After loading, the system then connects with a card printer to print the required personal information on the face of the card. The enrollment system is also responsible for deleting card applications, updating card information, and terminating or revoking an issued card by disabling the CUID in the directory.

Smart Card Authentication Server

The smart card authentication server provides services for verifying the identity of a person providing a smart card for authentication. It makes use of a challenge-response protocol to authenticate an identity who is trying to gain access to a resource. To verify the caller identity, the server generates a challenge string that is sent to the card to be encrypted using the private key stored in the card. As a response, the encrypted challenge is returned to the server with the CUID, which is used to locate the identity information corresponding to the CUID. The server uses the public key stored for the particular CUID to decrypt the response. If the decryption is successful and the response matches the original challenge, the user is considered as authenticated. The authentication server typically works as a security provider infrastructure for its target resource, which can be a network environment or business applications based on J2EE or Microsoft environments.

Browser Plug-in (for Web Clients)

To support Web browser-based client authentication, it is necessary to use a browser plug-in that allows interacting with a smart card reader and performing card operations. Most card vendors provide plug-ins based on Java, Mozilla, or Microsoft Active-X technologies to support popular Web browsers. The plug-in may implement PKCS#11-compliant interfaces to support cryptographic operations on smart cards such as accessing private keys, login using a PIN, signing e-mail documents, and other logical operations using a Web browser. The browser plug-in helps represent authentication callback and also prompts the user for smart card insertion during the authentication.

JAAS LoginModule (for J2EE and Java Applications)

To support smart card authentication for J2EE and Java applications, most smart card vendors provide JAAS LoginModules. In a J2EE environment, JAAS facilitates a pluggable authentication framework that allows incorporating authentication mechanisms from third-party security providers and custom authentication mechanisms specific to an application environment. JAAS LoginModules can also be built by encapsulating Global Platform or custom Java APIs provided by most smart card vendors. A JAAS LoginModule can be configured in a J2EE environment as a realm for authentication. All deployed applications and their associated user roles can be mapped into the realm. Once a realm is configured with a JAAS LoginModule for smart card authentication, it owns the responsibility of authenticating users within the defined realm and for populating a subject with the necessary principals, such as users and groups.

To understand the steps for implementing and configuring JAAS LoginModules for Java applications, refer to the section entitled "Java Authentication and Authorization Service" in Chapter 4, "Java Extensible Security Architecture and APIs."

J2EE-Compliant Application Server

The J2EE application server, also referred to as the J2EE platform, is a middleware environment capable of delivering multi-tier enterprise applications. It encompasses the architecture and programming model for building and deploying standards-based Java enterprise applications that span from client presentation to business logic and then integration with back-end databases and Enterprise Information Systems (EIS).

To enable smart card-based authentication, the J2EE platform requires an appropriate JAAS LoginModule that incorporates an authentication mechanism provided by a smart card authentication server.

PAM Module (for UNIX Applications and Desktop Login)

To support UNIX applications and desktop login, most smart card vendors provide PAM modules for enabling smart card authentication. PAM provides a set of shared libraries and a generalized API for enabling authentication services in the UNIX environment (for example, Solaris and Linux). PAM-based smart card authentication modules can be configured anytime and, once configured, all PAM-aware applications and the desktop environment (such as CDE, KDE, GNOME, and JDS) can immediately make use of smart card-based authentication services.

Refer to your UNIX provider administration guide for more information about configuring PAM modules.

GINA Module (for Windows Environment)

To support the Windows environment, most smart card vendors provide a GINA module that allows Windows Login using smart cards. GINA is a DLL that handles the default authentication and initiates the Window logon. Replacing the Microsoft default GINA with a smart card authentication-based GINA library allows the use of smart card-based authentication in a Windows environment.

Operational Model

Smart card-based security architecture has a lot in common with many authentication solutions. For a better understanding of the architecture and the relationships between the infrastructure components, we need to understand the different life-cycle operations managed by the architecture, such as card enrollment, authentication, and termination.

Smart Card Enrollment and Termination

To issue a smart card to a user, the card must be enrolled and registered with personal information from the prospective card holder. The entire enrollment process is usually carried out by a designated enrollment officer who is authorized to issue cards. Before enrollment, all required personal information such as digitized photo, biodata, biometric sample, and so forth must be collected and stored in a user directory (such as LDAP or RDBMS) that represents the smart card authentication process. During enrollment, the enrollment system associates the CUID of the card with the user entry stored in the directory. The enrollment system also extracts the public key certificate from the card and stores it to the corresponding user entry. If required, the enrollment system stores selected personal information to the card through a Hardware Security Module (HSM) using PKCS#11. During this process, the user will be asked to set a PIN on the card, which identifies his or her proof of possession. Once complete, the enrollment officer prints the required personal information on the face of the card using a card printer. After printing, the enrollment officer activates the card and the user's access control privileges. Now the card is enrolled to a user and ready for use.

To terminate the card from use, the enrollment officer deactivates the card by disabling the CUID and deleting the public key from the directory so that no further authentication can be done using the card. The card can also be temporarily revoked or blocked using PIN reset if a user enters an incorrect PIN too many times. The card cannot be used until the user resets the PIN, which requires the intervention of the enrollment officer to authorize the PIN reset. This PIN reset process is usually managed by the card OS itself and usually depends on the specific vendor solution.

Smart Card-Based Authentication

Let's consider a working scenario, assuming that a JAAS LoginModule for smart card authentication is installed and configured as the default authentication service for all the applications deployed using a J2EE application server. To support smart card authentication, the smart card authentication server and directory server are also installed as coexisting applications. All users entitled to access the J2EE applications are enrolled and issued a smart card. A user who attempts access to the applications using a Web browser must install a smart card browser plug-in that allows interacting with a smart card reader. During authentication, the client prompts the user to insert the smart card in order to submit credentials to the underlying JAAS LoginModule, which acts as a client to the smart card authentication server. The smart card authentication server authenticates the user based on the credentials and may allow or deny access to the requested application or resource.

The smart card authentication process is typically based on using a Challenge-Response protocol implemented by a smart card authentication server or using certificate validation through Online Certificate Validation Protocol (OCSP).

Smart Card Authentication Using Challenge-Response Protocol

In the Challenge-Response protocol-based authentication process, the server creates a random string (Challenge) requiring the smart card holder to encrypt the challenge using the card holder's private key. The encrypted challenge is sent back to the server as a Response. The server decrypts and verifies the response by means of a previously stored public key certificate. If the decrypted string matches the original string the authentication is considered successful.

Let's take a look at the core details of the Challenge-Response protocol-based authentication process using the sequence diagram shown in Figure 15-2.

Figure 15-2. Sequence diagram for Smart Card authentication process (using Challenge-Response protocol)

The key participants and their activities involved in the authentication process are as follows:

1.	The Client inserts the smart card and attempts to access the J2EE application using a Web browser.
2.	The J2EE application verifies the request using the JAAS LoginModule and then initiates authentication by forwarding the request to the smart card authentication server.
3.	The authentication server creates a random string (Challenge) and then requests the client to encrypt the Challenge using the client's private key.
4.	The client opens the card using the PIN and then asks the card to encrypt the Challenge using the private key.
5.	The encrypted Challenge and CUID of the card is sent back to the authentication server as Response.
6.	The authentication server verifies the response identifying the user's CUID from the directory server and uses the public key for the corresponding CUID to decrypt the encrypted response.
7.	If the decrypted string matches the original Challenge, the authentication is considered successful.
8.	Based on the authentication result, the JAAS LoginModule allows or denies access to the requested application.

In UNIX and Windows environments, the PAM and GINA modules, respectively, play the role of JAAS LoginModule in the authentication process. The desktop login can be done using the smart card and the PIN. In desktop login, the removal of the card from the reader locks the window or logs the user out, depending upon the configuration.

Smart Card Authentication Using OCSP Responder

Using OCSP allows applications to determine the status and validity of smart card-based certificates. During the OCSP-based authentication process, the smart card authentication server (acting as an OCSP client) interacts with an OCSP responder by sending an OCSP request that includes the card holder certificate. The OCSP responder verifies the validity of the card holder certificate and returns the status information with a signed response from the OCSP responder. The OCSP responder returns the following state indicators about a certificate.

• "good": This state indicates that the requested certificate's status is valid and not revoked.

• "revoked": This state indicates that the requested certificate's status has been either permanently or temporarily revoked.

• "unknown": This state indicates that the responder doesn't know about the certificate being requested.

The OCSP responder provides real-time status checking and validation of certificates. The OCSP responder is designated by a Certificate Authority that maintains the status information of all issued certificates. The OCSP responder issues OCSP responses on behalf of that CA. HTTP is used as the preferred protocol to transport the OCSP request and the OCSP response between the smart card authentication client (server) and the OCSP responder.

Using Smart Cards for Physical Access Control

As we discussed earlier in this chapter, using a single credential token for providing unified access control is crucial to the success of any organization in providing both physical access control (building, locations, and so forth) and logical access control (computers, software applications, and so forth). This means that a smart card deployment must provide support for both physical and logical access control in terms of identification and authentication. This is accomplished by smart cards with dual-interfaces that meet the requirements of both physical access control systems using contactless readers (such as a proximity antenna) and logical access control systems using contact-based readers.