Smart cards and cryptographic modules

Where IT security is concerned, smart cards and cryptographic modules are used to protect cryptographic secrets.

Smart cards were first manufactured in the late 1960s but did not enjoy commercial success until the introduction of telephone cards in 1984 by the

French Postal, Telegraph, and Telephone (PTT) [36]. Viewed in terms of their physical operation characteristics, there are three major classes of smart card:

◗ Contact cards, which require physical contact with a card reader [37–39];

◗ Contactless cards, which do not require physical contact and can be divided into those that operate by capacitive coupling (very short range) [40] and those that operate by inductive coupling [41];

◗ Dual technology cards, which offer both modes of operation.

For more information regarding the details of how such cards operate, see [36]. Although weaknesses have been published in recent years (for example, differential power analysis [42] and optical fault induction attacks [43]), smart cards are generally recognized as a highly secure, client-side storage environment for cryptographic keys and other secret information.

Although the personalization and distribution aspects require considerable investment, the fact that this is not prohibitive from a commercial point of view is born out by the high number of smart card devices already in circu-lation in the form of banking cards. In particular, smart card technology was an important enabler for the realization of the electronic wallet concept [44]. One factor that may encourage widespread adoption of smart card technology in the future is the increasing capacity to offer support for sev-eral applications, although from a security perspective it will be important to check that coexisting applications make sense and do not introduce addi-tional risk.

In using smart cards for secure key storage at the client side, we usually protect access to the card by requiring a PIN to unlock the interface, thereby implementing two-factor authentication to the target system. In this case, users require something they have (the smart card) plus something they know (the PIN) in order to correctly authenticate to the system. A subtle advantage of using smart cards for key storage is that the users do not have access to the key themselves. This prevents a user from performing a trans-action and subsequently denying it by deliberately revealing the key and claiming that it was someone else.

Cryptographic applications tend to use smart cards in one of two ways.

Memory cardsare simply used for key storage, and any cryptographic opera-tions to be carried out are not performed on the card. When using memory cards, the keys are read into the application and the latter performs the operations on the host platform. On the other hand,microprocessor cards, also known as cryptocards in this context, permit secure key storage and also enable the cryptographic calculations to be performed on the card. Applica-tions interact with smart cards via application programming interfaces (APIs). As several different interfaces are defined (example interfaces include PKCS#11, PC/SC, OCF, and CDSA; see [36] for details), the final choice of interface adopted will probably reflect the favored development model of the organization.

3.5 Supporting infrastructure 77

For secure applications, cryptocards are to be preferred, as the keys never leave the secure environment and are therefore not prey to attacks that can exercise control over the operating system (such asremote admini-stration trojans [45]). However, care is required when implementing such solutions—to be coherent, the PIN should not pass through the operating system, and this requires the presence of an external PIN pad. Figure 3.8 illustrates this principle.

Smart cards are a viable choice for securing access to cryptographic at the client side, but they are not usually an appropriate choice for server-side operations (although they are often used to store the keys that administra-tors use to gain access to a secure server—Here, however, the administrator is playing the role of a client). At the server-side, keys tend to be stored in specialized devices, collectively known as hardware storage modules (HSM).

The important standard in this area is the Federal Information Processing Standards (FIPS) 140 standard, Security Requirements For Cryptographic Modules, which covers a total of 11 areas relating to the design and imple-mentation of cryptographic modules. The original FIPS 140-1 standard has been recently updated to FIPS 140-2 [46].

The FIPS 140 standards are used to rate security devices against four lev-els of protection, known as level 1 to level 4. Security level 1 provides the lowest level of security, and level 4 provides the highest. Cryptographic modules are rated using a series of tests called the derived test requirements (DTR) for FIPS PUB 140-2, which are published on the National Institute of Standards and Technology (NIST) site together with a list of all validated cryptographic modules [46].

The possibility of carrying out business on the Internet, where the poten-tial number of clients is almost limitless, has led to new requirements for application scalability, and this has in turn led to new demands on the scalability of cryptographic solutions. Cryptographic accelerators are special-ized modules aimed at providing increased performance for cryptographic applications. In reality, cryptographic accelerator functionality is often pro-vided as a specialized HSM, therefore combining secure key storage with high-performance cryptography. For this reason, specific cryptographic

Application

External reader with pin pad External reader without pin pad

Smart card Smart card reader PIN

Application OS OS

Smart card Smart card reader PIN

PKCS#11 PKCS#11

Sniffing tools work here (e.g., netbus)

Figure 3.8 Using cryptocards with external card readers.

accelerators may offer the ability to run in FPS 140–compliant mode, where the former will be limited to FIPS-approved algorithms.