ISI stands for IBM Smartcard Identification. The ISI-protocol is an authentication protocol involving three entities, a chipcard holder wishing to authenticate himself to a server, the chipcard itself as an active member of the protocol, and a server. The server can be reached by the chipcard holder through the Internet.
In a real-life ISI-application the server communicates with the chipcard holder through the Internet. After successful authentication of the chipcardholder by his chipcard, the server grants access to the database so that the secured sensitive data can then be sent through the Internet to the chipcardholder.
A key issue of the ISI-protocol is the authentication of the chipcard holder by his chipcard to the server through the Internet, an unsecured communication channel.
Access is only allowed after successful authentication of the chipcard holder by his chipcard to the server. In the ISI-application the chipcard holder will use his chipcard to authenticate himself on the Internet. This means that the chipcard must act on behalf of the chipcard holder so that a server will authenticate him by authenticating his chipcard.
In the ISI-model there are two authentication steps, independent of each other. First, the chipcard holder should authenticate himself to the chipcard in order to ensure that the chipcard will only act on behalf of a legitimate chipcard holder. After that authentication step, the chipcard then authenticates the chipcard holder to the server by authenticating itself.
At the beginning of the second authentication step the server cannot be sure if the first authentication step has taken place because the first authentication step occurs between the chipcard holder and his chipcard locally on the chipcard holder's system.
Chipcards can have access conditions set that require a Card Holder Verification (CHV). The CHV must be supplied to the chipcard by the card holder. In banking card terms a CHV can be called a Personal Identification Number (PIN).
A CHV is used as a password to permit use of the chipcard or to access an application and is stored in the chipcard. A chipcard can have multiple CHV's for multiple applications. CHV's in chipcards can have a maximum length of 8 bytes in BCD (either a maximum of 16 numerics or a combination of alpha/numeric data).
An important feature of using CHV's is that when an invalid CHV is supplied a limited number of times (internally set in the chipcard), the chipcard blocks its CHV and thereby blocks the whole application secured by that CHV. This should prevent a thief of using a stolen chipcard for an application secured by a CHV, as the probability of supplying a correct CHV in a limited number of retries (for example 5) is very small.
ETSI TE9 chipcards provide us with mechanisms that we can use to authenticate the chipcard itself. A chipcard can be challenged by the external world, the server, by requesting a signature over a token sent to the chipcard.
The signature is a cryptogram calculated using a key stored in the chipcard. The server specifies to the chipcard which key it should use for calculating the cryptogram. The chipcard sends the requested signature back to the server where it will be verified.
As ETSI TE9 chipcards use DES as their cryptographic algorithm, the key used is symmetric which in this context means that the same key is used for encryption and decryption, and hence must be shared between the server and the chipcard.
In the current ISI-protocol authentication keys are not exchanged. Instead, a key already stored in the chipcard will be used in conjunction with the same key stored in the server database.
Verification of the signature is done by the server by calculating the same signature using the same key. The server compares the signature from the chipcard and it's own
signature and, if they are equal, the chipcard has authenticated itself to the server.