White paper - Initial Draft Montserrat Mane (HP) March 1996 Sylvie Zapata-Brel (HP)
This white paper has two objectives:
A smart card is a credit card sized, tamper-resistant security device that offers functions for secure information storage and information processing. A smart card has a microprocessor and internal memory (RAM, EEPROM or ROM). The ROM contains an operating system and information is protected by a PIN (Personal Identification Number).
Other commonly used security devices have significant differences compared to smart cards. Diskettes do not have an operating system and information is not protected. Token cards are able to generate personal keys but do not offer logical partitions to store information.
A smart card can provide the following logical functions:
A smart card has a life cycle. This life cycle could include all or some of the following steps:
In OSF RFC 86.0, smart cards are discussed, but their integration into the the PAM architecture needs to be defined further. They are described in two different ways in the RFC, as a:
A smart card PAM back-end module implies that the smart card is an authentication sub-system. This is not the case, as the smart card will work in conjunction with a given authentication mechanism to provide advanced security features. For example the authentication mechanism could be traditional Unix authentication or Kerberos.
A password mapping device is a very particular utilisation of a smart card.
The approach we have taken is to consider the smart card as a Personal Security Device (PSD) that can be accessed through a generic API called PSM-API. The PSDs and the PSM API comprise the Personal Security Module (PSM).
In the PAM architecture the PSM sits below the PAM back-ends and provides a common generic access to security functions for all PAM back-ends. These security functions can be provided by other security devices as well as smart cards.
Figure 1 shows the relationship between the PAM-API and the PSM-API. The PSM-API sits below the PAM-API and the PAM back-ends and acts as a bridge between the PAM and the smart card Personal Device.
RFC 86.0 proposes that smart cards should be integrated into PAM with a "use_smart_card" option. Because of this additional layer in the architecture, we propose that the smart card is integrated into PAM using a new option "use_psd".
Authentication functions are performed by various applications and are vital to the security of a system. Different types of authentication are provided by different security mechanisms, these include:
The Personal Security Module is used by any application to provide user authentication services. Examples of applications are the PAM back-ends shown in the figure 1.
The data and security mechanisms required by the different types of authentication are provided by the Personal Security Device (PSD).
In the PAM example, we have defined three applications or PAM back-ends, each of them relying on different authentication technologies:
A given authentication technology operates with a set of other security components such as an authentication server or an authorisation server for applications. Altogether they constitute what we will call a security domain.
Usually, the applications are not crypto-aware but know only their security domain and the information associated with the user.
The PSM will be used for any authentication operation regardless of the authentication technology used (passwords, symetric key or public key) and for the specified user.
The PSM-API offers flexible access to the mechanisms required to execute the security services. It hides the complexity of the cryptographic functions (except if applications want to control them). It conceals the hardware used to store the different pieces of information for a user and to execute the commands.
The following figure shows the relationships between the PSM-API, the PSDs and PAM components:
A personal security device is a generic term for a device which is able to store and execute several cryptographic functions with protection mechanisms for secure information.
The same security device could be used by one user to access different applications or systems. The selection of the appropriate data and functions for the application is done by the PSM.
A personal security device has a single owner. They alone have access to this device via the PIN (Personal Identification Number).
To identify and authenticate a user, an application uses the following information, the:
A personal security device has to be able to store all the information about multiple pairs of "application + user name". This is an advantage within the context of Single-sign on. Each of these pairs can be different depending on the application and the user's names.
Examples of personal security devices are:
The other APIs known in the cryptographic domain are:
These APIs are broad in scope and cover all of the cryptographic functions. None of them focus on authentication problems. An application using any of these three APIs would have to be crypto-aware. These APIs enable each application to select all of the parameters used by the different crypto functions. Such APIs are very well adapted to offer an interface with the crypto devices because such devices are designed to provide the basic crypto functionalities.
One of the roles of the PSM is to hide this complexity from the application and to merge it into this layer. The PSM could offer default parameters for each security domain. Based on the default selection, an application could use the functions of the PSM with a minimum of parameters.
Another API often used in a security domain is the GSS-API. This API is used by applications, first to establish credentials and then to process secure exchanges. It is obvious that the GSS-API and the PSM have a large synergy.
The integration of the GSS-API with the PAM back-ends and the PSM should be investigated further in the future. We believe that GSS-API will use PSM-API to retrieve or establish initial credentials
The PSM has been designed to offer an easy access to the three main authentication technologies (Passwords, symetric keys, public keys). Security devices such as smart cards are very well adapted to provide all the required functionalities even for the coexistence of the three functionalities (secure data storage, encryption, signature). In the case of new techniques for authentication (for example, biometrics) it is very likely that the technology of smart cards will evolve to offer required services. This architecture can evolve as smart card security products evolve and new personal security devices are released.
PAM provides a framework into which through PSM-API, smart cards can be integrated easily. This easy integration has advantages for the applications and for the end users. The list below includes some of the advantages of PSM for the applications:
The list below includes some of the advantages of PSM for the user of the PSD:
Though it is possible to integrate different security devices, the smart card is the device which offers the highest level of security and the highest functionalities. If smart card readers eventually become standard features in PCs, the adoption of smart cards will dramatically increase and the smart card will be the most popular security device.
Hewlett-Packard will publish more detailed information about the integration of the PSDs into PAM in the near future. A RFC describing the PSM-API will also be published by Hewlett-Packard shortly.
The authors wish to acknowledge the support of Stephen Lock who reviewed and corrected this document.
REFERENCES
RFC 86.0: V.Samar (SunSoft) and R.Schemers (SunSoft). "Unified Login With Pluggable Authentication Modules (PAM). October 1995.
AUTHOR'S ADDRESS
Montserrat Mane
Internet email : [email protected]
Telephone : 33-76-62-10-90
HEWLETT-PACKARD France
5, Av Raymond
Chanas Eybens
38053 GRENOBLE CEDEX 09
France
Sylvie Zapata-Brel
Internet email : [email protected]
Telephone : 33-76-62-10-03
HEWLETT-PACKARD France
5, Av Raymond
Chanas Eybens
38053 GRENOBLE CEDEX 09
France