Advances in network smart cards authentication

Abstract

Smart cards have been widely used as simple token hardware in authenticationn processes. Nevertheless, a new trend indicates a shift towards more enhanced cards with networking capabilities. We propose revising the usual focus on smart card authentication protocol designs, as well as highlighting the need to adapt to new trends. Our main objective is to define an authentication model that uses the card as a stand-alone supplicant in a mutual end-to-end authentication schema. We also propose a protocol architecture which allows us to integrate the smart card within the network in the authentication plane. Finally, this new approach to network smart cards authentication processes is applied to a practical electronic payment scenario.

Introduction

The link between network technologies and heterogeneous devices has required the correct integration for their respective schemas of authentication. In order to achieve this, these models have been adjusted accordingly, with the goal of reducing the impact on the system’s global security. More recently, the smart card has aspired to be considered as a common host within the network: the Network Smart Card. Thus it must incorporate a variety of network authentication mechanisms and protocols to participate transparently in this context.

Nevertheless, the authentication protocol design for smart cards has traditionally been oriented to support the functionality of token hardware, as opposed to a design oriented more towards the perspective of a host with network connectivity, i.e., a device capable of implementing standardised protocols with its own capabilities for remote authentication. In our opinion, the design of smart card authentication protocols has been conditioned by its ISO 7816 based communication system. This means that the smart card is overly dependent on the host and this dependency is particularly undesirable when dealing with a public host of questionable trust. Moreover, this design is often oriented more towards the authentication of a cardholder or other device rather than being oriented towards actual card authentication. This, along with other considerations is discussed in this paper.

In the following few paragraphs we summarize current smart card characteristics which determine the design of authentication protocols for these devices.

Credentials storage. Historically, magnetic stripe cards have been used for a multitude of applications as non-secure storage devices for critical information (for example; in the case of banking and financial services).

Memory cards have been widely used in the form of telephone cards as well as in corporate environments (e.g., access control or vending machines), given the advantages for secure storing these could offer. Though the features of modern chip cards have been enhanced, this inertia largely continues. Because of this, the early authentication protocol designs took advantage of their capacity for carrying certain security cardholder credentials (identifier, PIN, passwords, etc.). The user is required to further identify himself in order to access the system. There is little or no communication with the rest of the system in these authentication processes. Card and cardholder engage solely in local communication and the terminal acts as the intermediary in this process.

Server role. Smart cards have typically played the role of a server in relation to the terminal (client). This has conditioned the design of protocol authentication and smart cards as the only way of communicating with the system. Because of its terminal dependency, it has been a device of limited scope. Communication (authentication message transport) is impoverished by the push command from the terminal. With the advent of more modern technology, such as OTA (over-the-air) [1] applicable in mobile telephone environments, it has been possible to incorporate a certain degree of pro-activity between client and smart card.

Time-stamps. Another factor, which has influenced the design of smart card authentication protocols, has been the impossibility of using time-stamps. Time-stamps are often required for refreshed messages and to impede replay attacks (for example; SSL/TLS requires the current UNIX GMT time-stamp). The concept of time-stamp was initially exploited in identity-based cryptosystems [2] and in digital signature algorithms, such as ElGamal [3]. Their use in more recent proposals has been important. Nevertheless, it is not always possible to extend the use of time-stamps to any schema, especially when dealing with smart card authentication processes. As is widely known, these do not have internal clocks, since they lack individual batteries. The smart card receives the tick from the terminal clock. The notion of a universal time value, or similar, would only be possible if the terminal provides this value to the card. This technique is highly unreliable and not recommendable for authentication use with smart cards. It is easy to imagine a scenario in which a user may insert his card in a insecure public terminal. Despite some unfortunate attempts, smart card authentication protocols tend to resort to nonces (sequence numbers or random numbers).

Remote authentication: simple vs. mutual. There are various well-known mutual authentication protocols. Due to implementation costs (computing costs or mass-implementation costs), most real-life smart card transactions are carried out using simple remote authentication processes. More recent technology allows for mutual remote authentication, though terminal dependency is still a major issue, impeding card autonomy.

ISO 7816 protocol stack. This is largely considered as the core of the smart card. Due to its characteristics, authentication protocol design has not always been appropriate for networking environments. The resulting protocols make communication difficult online. Some adaptation techniques or middleware have been proposed in order to attain a certain degree of interoperability. Terminal dependency for the transport of authentication messages requires particular attention. An overly particular design could easily break the robustness of any protocol, considering the speed at which new technologies are developed. This type of development has normally been focused on obtaining a high level of integration and interoperability. As clearer research and development guidelines emerge, they point towards smart cards as network-aware devices alongside the current ISO 7816 model.

All of these factors reflect the fact that previous authentication devices have failed in aiding the trend towards network smart cards. Because of this, a number of adaptation processes must be carried out in this field. We aim to contribute in this direction with our work. To summarise, the main objective of this article is to define a smart card remote authentication schema with the following characteristics:

• Stand-alone supplicant: We propose a new smart card remote authentication model. The smart card adopts the functionality of stand-alone supplicant vs. split supplicant.

• Remote authentication protocol architecture. This article describes an architecture characterised by:

  • Atomic smart card authentication protocol design: the authentication protocol should be designed as an integral part of the smart card. We propose a specific protocol stack for the card.

  • End-to-end mutual authentication schema: the smart card participates as a communication extreme.

  • Layer 2 authentication: This article discusses the advantages for network smart card integration based on a layer 2 authentication schema.

In the rest of this article, we review the background and related work in this field (Section 2). In Section 3, we analyse the usual focus given to smart card authentication protocol design as well as identifying the needed adaptation for using these as online smart cards. In Section 4, we propose a new authentication model and remote authentication protocol architecture. In Section 5, we apply the aforementioned architecture to a real-life electronic payment scenario. And finally, in Section 6, we present the conclusions of our work.