Note: Descriptions are shown in the official language in which they were submitted.
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
1
METHOD AND DEVICE FOR DATA COMMUNICATION
Technical Field
The present invention relates to a method and a sys-
tem for data communication between a central unit or
host, such as a central computer in a bank, and a user
unit comprising an IC card that the user carries and uses
when he intends to carry out transactions involving
communications with the host, and a terminal capable of
communicating with the IC card and the host and acting as
an interconnection link between them.
Background
It is presently known to use data transfer systems
comprising IC card-controlled terminals and a host. It is
likewise known to use, in these systems some kind of
secret information to cryptographically protect
transferred data.
Two principal disadvantages are found in the data
transfer systems in use today. The first one relates to
the fact that the terminals contain secret information
which, on account of the physical availability of these
terminals to the public, may be exposed to violation in
the sense that an unauthorised person may try to read the
secret information from the terminal. The second disad-
vantage is that since present standards on the
configuration of IC cards, with the exception of such
basic features as signal levels and the like, allow
considerable degrees of freedom regarding for instance
the memory addresses to which the data are to be allocat-
ed, the terminals normally are able to handle one type of
card only.
CA 02241834 2005-O1-13
2
Object of the Invention
The object of the present invention is to provide a
method and a system solving or to a considerable extent
eliminating the problems outlined above, thus providing
increased flexibility with respect to the cards that may
be used in the system and increased safety in the
managing of the secret information.
Summary of the Invention
The purpose of the present invention is achieved by
1o a method and a system as defined in the appended claims.
A basic concept of the invention is that at least
sensitive data transfers between the user unit and the
host are carried out in a separate safe system mode and
that program-controlled realisation of the safe system
mode is carried out by using card-specific program infor-
mation contained in the card. The safe system mode means
that data transfers are carried out in such a manner that
unauthorised persons cannot distort or manipulate trans-
fered data without such interference being discovered.
2o For this purpose, secret information in the user unit and
in the host is made use of. The initiation of communica-
tion between the card and the terminal is carried out in
so-called normal system mode.
Cards used in accordance with the invention contain
card-specific program information transferred to and used
by the terminal in connection with the establishment of a
safe mode.
In accordance with the present invention the "resi-
dent" information contents in the terminal is no more
3o extensive than is absolutely necessary. Each card carries
program information which is specific to the individual
card and which is transferred to the terminal. Since the
card-specific program information is transferred to the
terminal the latter need not contain "resident" program
CA 02241834 2005-O1-13
3
information that is specific to each individual card or
card type.
This makes it possible to use in the system, cards
that are configured in different ways without it being
necessary for the terminal to contain considerable soft-
ware, and for example several card issuers may use the
same set of terminals without it being necessary that the
terminal contains, or that the other card issuers have
knowledge of, the software that a specific card issuer
1o uses in order that a safe system mode be adopted.
The system in accordance with the invention allows
the terminal to be made both inexpensive and "flexible"
in the sense that without difficulties it is possible to
adapt the unity card/terminal to include cards that are
i5 configured differently without the terminal having to be
changed or be provided with new "resident" program infor-
mation.
Transfer of card-specific program information from
the card to the terminal is effected, in accordance with
2o a preferred embodiment, under the control of the host the
actions of which are based on card-identifying informati-
on or a code transferred from the user unit. However, it
is obviously possible that this may be effected by the
terminal and the card without involving the host.
25 Cards used in accordance with the invention likewise
contain card-specific secret information which is used to
produce cryptographical protection of data transfers and
which is stored in such a way that it cannot be read out
from the card.
3o In accordance with a preferred embodiment the card-
specific secret information is used to encrypt (in the
widest sensey, by means of an algorithm, preferably the
so-called DES algorithm, a generated session key,
preferably in the form of a random number which is then
35 transferred to the host in encrypted form. This session
key is then used to cryptographically protect data
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
4
transferred between the user unit and the host in a safe
system mode.
The above-mentioned session key is erased in the
user unit at the latest the next time contact is
established between an IC card and the terminal, although
it is possible to effect such erasure, for instance in
response to a specific command while contact is still
being maintained, because it is desired to begin a new
session, or when the contact between the card in question
and the terminal is interrupted.
Obviously it is likewise possible to use card-speci-
fic secret information as such in order to
cryptographically protect data transferred between the
host and the user unit in a safe system mode, i.e. that
the secret information is used as a cryptographic key,
either in an encryption algorithm or in an authentication
algorithm.
In accordance with a preferred embodiment, the ter-
minal comprises a keyboard which may be used only in a
safe system mode.
In order to protect data transferred on an open line
or in another medium accessible to unauthorised persons
various different cryptographical techniques are used.
A common method is to first encrypt data which are then
transferred and finally decrypted. The reverse order is
also possible, i.e. to first decrypt data, then transfer
them and finally encrypt the transferred data which are
then retrieved in cleartext. Both these techniques
obviously may be used in connection with the invention.
In the case of for instance a random number which is
adopted to create an encryption key for an encryption
algorithm it .is possible to instead transfer the random
number in cleartext and to then encrypt/decrypt it and
later use the result as an encryption key. Also this ,
technique may be used in connection with the invention,
which thus is not limited to use in connection with the
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
cryptographic technique described herein in detail.
Symmetrical as well as asymmetrical encryption systems
may be used.
Brief Description of the Drawings
' 5 Fig. 1 is a schematic block diagram relating to one
embodiment of a system in accordance with the
present invention.
Fig. 2 illustrates a flow chart of measures to be taken
in accordance with a preferred embodiment before
initiation of data transfers between the user
unit and a host in a safe system mode.
Fig. 3 illustrates the manner in which an encryption key
is generated and encrypted in accordance with one
embodiment of the present invention before the
encryption key is transferred to the host.
Fig. 4 illustrates the authentication of messages (data)
in accordance with a preferred embodiment of the
present invention.
Fig. 5 contains a list of the different varieties of
generation of code keys and transfer thereof to
the host.
Figs 6a-6h are flow charts illustrating the varieties
listed in Fig. 5.
Detailed Description of Embodiments of the Present
Invention
In the following a system will be described with
reference to Fig. 1 which system is designed for safe
data transfers and which comprises a user unit,
comprising an IC card 1, a terminal 2, and a central unit
(host) 3.
The IC card 1 comprises card communication means 4
that are placed in contact with terminal communication
means 5 to establish a connection for data transfers
between the IC card 1 and the terminal 2.
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
6
In addition, the IC card 1 comprises first card
memory means 9 for storing card-specific program
information to be transferred to the terminal 2; second
card memory means 10 for storage of card-specific secret
information in such a way that it cannot be read out from
the card; a memory means 16 for storage of a card- ,
identifying code; and a processor 15 containing required
program information to allow execution of the required
cryptographic processing, in this case encryption, and
generation of a session key before the latter is
transferred to the host 3, as will be described further
on.
The terminal 2 comprises a terminal communication
unit 6 in communication with the central communication
unit 7 associated with the host 3, in order to allow data
transfers between the host 3 and the user unit, and a key
generating means 13, in the form of a random number or
pseudo random number generator for generation of a ses-
sion key to be transferred to the host in an encrypted
state and to be used for authentication of messages to be
transferred between the user unit and the host 3, as will
also be described later on. The terminal 2 comprises
storage means 14 to store the session key.
In accordance with another preferred embodiment no
key generating means is used in the terminal but the
generation of the key instead takes place in the proces-
sor 15 in the card.
The terminal 2 and the host 3 in addition comprise
control means 8, 18 to control the transfer of the system
to the safe system mode which in accordance with the
preferred embodiment is considered to have been adopted
once the session key has been transferred to the host. In
this mode data transfers between the terminal 2 and the
host 3 take place in such a manner that data that are
being transfered are protected (cryptographic
authentication) by means of the session key that has been
transferred to the host. In addition, the terminal 2
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
7
comprises read-out means 11 for read-out of the card-spe-
cific program information in said first card memory means
9, the read-out program information being stored in and
used by program executing means 12 in the terminal 2 in
order to control interaction between the terminal 2 and
the IC card 1.
Fig. 2 illustrates in the form of a flow chart the
manner in which the IC card, the terminal and the host
cooperate in accordance with one embodiment before data
transfer in a safe system mode is initiated, a process to
be described in closer detail in the following with
reference to Fig. 4.
In step 100, the IC card 1 is inserted in the termi
nal 2, whereby contact is established between said termi
nal communication means 5 and said card communication
means 4. In step 101, an ID code stored in said memory
means 16 is transferred via terminal 2 from the user unit
IC card to the host 3. In step 102, on the basis of
verification of the card type, i.e. the card
configuration, the host 3 informs the terminal 2 on how
its read-out means 11 are to proceed to read out the
card-specific program information from said first card
memory means 9. In accordance with a preferred
embodiment, data transferred from the host contains
information on the address where the read-out is to
begin. In step 103, the card-specific program information
is read from card 1 to terminal 2. In step 104, a random
number is generated in said key generating means 13, said
random number to be used as a session key in a sealing
process while using a Message Authentication Algorithm
(MAA). In step 105, the session key in the IC card is
encrypter in said encryption means 15 using the secret
information contained in the second card memory 10 of the
' IC card 1. In step 106, the session key is transferred in
encrypted state to the host 3. Steps 104, 105 and 106 are
- illustrated in closer detail in Fig. 3. In step 107, a
keyboard associated with the terminal 2 is opened for
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
8
use. In step 108, data transfer is begun in the now
adopted safe system mode.
In the following, the description will be made with
reference to Fig. 3. In accordance with the preferred
embodiment a random number is generated in the terminal
to be used as a key in an MAA process to authenticate .
messages (i.e. data) transferred from the user unit to
the host and vice versa. This random number is then
encrypted in the card in a DES encryption algorithm,
10 using the secret information (DES key) in said second
card memory means 10 (Fig. 1) as the encryption key in
order to be transferred in encrypted state (the encrypted
random number is designated by eK) via the terminal to
the host 3, wherein it is decrypted and used as a session
key in an MAA.
In Fig. 4 is exemplified the manner in which data
transfers and authentication of data are carried out in a
safe system mode in accordance with the preferred
embodiment. The encrypted random number eK, having been
20 transferred from the user unit, is decrypted in the host
by means of a key stored in the host, said key depending
on the card that is being used and being identical with
the one in said card. The decrypted random number is then
used as an MAA key together with a message to be
25 transferred to the user unit and a message serial number,
in an MAA in order to generate a cryptographic check sum,
Message Authentication Code (MAC), which is added to and
used to authenticate the message. The MAC will have a
different appearance in successive messages during one
30 and the same session (also when their contents are the
same, since they have received different serial numbers).
Thus, a flow of data is transferred, containing the
message, the serial number, in cleartext, and a MAC. ,
In the user unit an MAA check is carried out to
35 verify the message received while using the MAA key in ,
the terminal, i.e. the random number, or in other words,
a check to verify whether the message has been
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
9
manipulated on its way from the host to the user unit.
The check comprises a corresponding computation of a MAC
and a comparison thereof with the MAC received together
with the message, to determine coincidence.
When the user unit is to transfer a response message
to the host one proceeds in a corresponding manner, i.e.
on the basis of the random number, the response, and the
serial number transferred from the host a new MAC is
computed, which is added 'to the flow of data formed by
the response from the user unit to the host and the
latest serial number transferred from the host. The host
then performs an MAA check of the transfered response in
order to check that the response has not been manipulated
on its way between the user unit and the host. Further
message transfers may then be carried out in the same
way.
Fig. 5 is an account of a number of possible modi-
fications 1-8 of random number generation and protection
of random numbers that may be used in connection with
the present invention. Four cases (1,3,5,6) are shown in
which the random number used as a session key is generat-
ed in the terminal and four cases (2,4,7,8) wherein the
random number is generated in the card. In addition, four
different varieties are shown of the forms in which the
corresponding session key is used for cryptographic
protection respectively is transferred to the host.
Figs 6a-6h show the eight various cases accounted
for in Fig. 5 in more detail. The various steps illu-
strated for each case are indicated by numeral references
placed inside white rectangular boxes. Each Figure
illustrates the situation occurring when a user has
inserted his card in the terminal and the system is about
to accomplish a safe mode. It appears from the Figures
that steps S1-S5 are identical for all eight varieties.
In step S1, the central unit (Host) commands the terminal
(Terminal) to read out the identification number of the
card to verify whether the card is associated with the
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
host in question and, when the verification is positive,
to supply the encryption key which is associated with the
card and which is to be used in the host to encrypt or
decrypt the random number (session key), depending on in
5 which form the key has been transferred to the host. In
step S2, the terminal transfers the read-out card number
to the host. In all eight cases, the host makes sure that
the card has been issued by the user of the host,
whereupon in step S3 it orders the terminal to begin to
10 assume a safe mode. In steps S4 and S5 the terminal
executed the program sequence that is its resident
program information, i.e. to read and fetch the card-
specific program information from a file (SMIB) in the
card. The rest of the steps to be executed in order for a
safe mode to be assumed is governed by the contents of
SMIB, i.e. the card-specific program information. This
shows that a comparatively simple and thus inexpensive
terminal (in principle capable only of reading out a file
from an IC card), when used in a system in accordance
with the present invention, may achieve an astonishing
degree of flexibility with respect to its ability to
interact with cards that are configured in different
ways. The first case illustrated is the one shown in Fig.
3, i.e. the random number to be used as a session key is
generated in the terminal and is encrypted in the card,
in step S6 before being transferred to and stored in the
terminal in step S7, the terminal finally, in step S8,
sending the encrypted random number to the host,
whereupon data transfer in safe system mode may be
started in accordance with Fig. 4.
In accordance with the second case illustrated the
following steps are performed, in addition to steps Sl-S5
already described, viz.: in step S62 the terminal orders ,
(in accordance with the contents of the corresponding
SMIB) the card to generate a random number; the card .
generates and sends a random number to the terminal
wherein it is stored, in step 572; in step S82 the termi-
CA 02241834 2005-O1-13
11
nal orders the card to encrypt the generated random num-
ber; the card encrypts the random number and transmits it
in encrypted state to the terminal: in step 5102, finally,
the terminal transmits the encrypted random number to the
host, whereupon data transfer in safe system mode may
start in accordance with Fig. 4.
In the third case illustrated, the following steps
are executed in addition to steps Sl-S5 already
described, viz.: in step S63 the terminal generates and
1o stores a random number and orders the card to decrypt the
random number: in step S73 the decrypted random number is
transferred to the terminal; and in step S83 the decrypt-
ed random number is transferred to the host. When the
random number (session key) reaches the host it should
not be decrypted before use but be encrypted in order to
provide the key in cleartext, and otherwise data
transfers are commenced in a safe system mode in same
manner as illustrated in Fig. 4.
In the fourth case illustrated the following steps
2o are executed, in addition to steps S1-S5 already describ-
ed, viz.: in step 564 the card is ordered to generate a
random number; in step 74 this random number is transfer-
red to and stored in the terminal; in step S84 the termi-
nal orders the card to decrypt the random number; in step
S94 the card sends the decrypted random number to the
terminal; and in step 5104 the decrypted random number is
sent to Host. When the random number (session key)
reaches the host it should not be decrypted before use
but be encrypted to provide the key in cleartext and
otherwise the data transfer in a safe system mode
commences in the same manner as illustrated in Fig. 4.
In the fifth case illustrated the following steps
are executed, in addition to steps S1-S5 already
described, viz.: the terminal generates a random number
which is transmitted in step S85 to the host in cleartext
and which in step S65 is encrypted by the card: in step
S75 the encrypted random number is transferred to and
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
12
stored in the terminal. Because there is an encrypted
session key in the terminal and because the session key
has been transferred to Host in cleartext it is neces-
sary, in order to establish data transfer in safe system _
mode, to encrypt the session key in Host before it can be
used.
The sixth case illustrated is distinguished from the
fifth case only in the respect that whenever encrypting
is effected in the fifth case decrypting now is to be
performed.
In the seventh case illustrated the following steps
are executed, in addition to steps Sl-S5 already
described, viz.: in step S67 the terminal orders the card
to generate a random number which in step S77 is
15 transferred to the terminal; in step 5107 this random
number is transferred in cleartext to the terminal and in
step S87 the card encrypts the random number; in step
S97, finally, the encrypted random number is transferred
to and stored in the terminal. Because there is an
20 encrypted session key in the terminal and because the
session key has been transferred to Host in clear text it
is necessary, in order to establish data transfer in safe
system mode, to encrypt the session key in Host before it
may be used.
25 The eighth case illustrated a.s distinguished from
the seventh one only in the respect that whenever en-
crypting is effected in the seventh case decrypting now
is to be performed.
One example of a set of the card-specific program
30 information being transferred from the card to the termi-
nal and producing the generation of a session key and
transfer thereof to the host in accordance with variety 1
in Fig. 5 (Fig. 6a) may contain the following sequence of
commands; OPEN (open up the file in the card containing
35 the card-specific secret information, allowing it to be
used as an encryption key in an encryption algorithm),
RANDOM (generate a random number in the key-generating
CA 02241834 1998-08-25
WO 97/16904 PCT/SE96/01396
13
means 13 of the terminal in accordance with the
instructions contained in the command and storage of said
number in the terminal storing means 14), CRYPT (read
- over the random number to the card and encrypt the random
number in the card using a conventional encryption
algorithm defined in and executed by the processor 15,
and the encryption key), READ (read out the encrypted
random number to the terminal) and TRANS (transfer the
encrypted random number to host).
It should be understood that the commands and func-
Lions defined are only of an exemplifying nature and
that they may be implemented in a large number of dif-
ferent ways and in a large number of different program
languages. The methods of implementation of the functions
used in the embodiments in accordance with the present
invention in program code must be considered self-evident
to those skilled in the art when reading the present
invention and therefore they will not be described in
more detail herein.
