Note: Descriptions are shown in the official language in which they were submitted.
t CA 02295887 2000-O1-04
so 00 00 0 oe ocoo 0o ae
o a a o n ~i ~ ° ~ ° o ~ n
o ° n n a o ~ ~ ri O L1
o ° . " ~ ? O o ., r nn oOm
o . ° n c
nnn ".. ~~
402286W0
"' Method for verifying the effect of the execution of commands which are
loaded in a security module of a terminal.
The present invention relates to a method for verifying the
effect of the execution of commands which are loaded in a security
module of a terminal. More specifically, the present invention relates
to the controlled loading of data in the security module of a smart
card operated terminal by means of the execution of commands.
Terminals, such as vending machines or public telephones, often
comprise a security module for securely storing usage data. Such
payment data is e.g. the number of times the terminal has been used,
the amount of money spent by consumers at the particular terminal, or
the number of telephone metering pulses the (telephone) terminal has
collected. A security module, which is usually mechanically and/or
electronically protected against abuse, comprises electronic memory
means (such as counters and EEPROM) for registering payment data and
for storing keys. A security module may further comprise processing
means for processing data, such as usage data. Such processing means
normally comprise a microprocessor running programs consisting of
commands stored in the security module. The processing often comprises
the cryptographic protection of the usage data in order to prevent
fraud. An example of a security module and its use is disclosed in US
Patent Specification no. 5,572,004.
It is often necessary to update the data stored in a security
module, e.g. for adding new functions or modifying existing functions.
Data may be added or altered using commands, the execution of which
effects the desired addition or alteration. However, the functioning
of the additions and alterations needs to be verified. This is
especially true since security modules often store monetary data or
their equivalents.
Thus the need arises to be able to load such new data into the
security module and to verify its effects, i.e. the proper functioning
of the modifications brought about by that data. As in practice it
will be necessary to effect changes in security modules in many
different locations, verifying the functioning of those security
modules constitutes a problem. The Prior Art does not offer a solution
for this problem.
US Patent Specification no. 4,972,478 discloses a cryptographic
circuit connected with external programming equipment which may
perform an execution test to verify that the cryptographic circuit
accurately performs its cipher algorithm. How this execution test is
performed, and which results are transferred to the external
programming equipment, is not disclosed. Said patent does not deal
with a smart card operated terminal.
jJ~~
P
~
CA 02295887 2000-O1-04
N o ~0 0
o e~ vn or,."
O :. 1 V
.~w .r~~ ~ ~ Gr.(.~n
o r. r r.
~. .~ r. 1 n o ~ r . ~ ~ ' .~ n
402286W0 2
US Patent Specification no. 5,495,571 discloses a method for
parametric testing of a function programming interface. A testing plan
invokes the function with different parameter values and it is tested
whether the function returns appropriate error codes. Said patent does
not deal with the controlled loading of data and commands. Also, said
patent does not deal with a smart card operated terminal.
US Patent Specification no. 4,777,355 discloses an IC card and
system for checking the functionality thereof.
However, the specific verifying method of the invention for external
terminals has not been disclosed. It is an object of the invention to
overcome the above-mentioned and other disadvantages of the prior art
and to provide a method which allows data to be loaded into the
security module of a terminal and to verify the proper functioning of
the commands using that data. It is a further object of the invention
to provide a method which allows the remote function check of a
security module. It is another object of the present invention to
provide a method which allows the terminal to be transparant with
respect to the commands.
The present invention therefore provides a method for verifying
the effect of the execution of commands which are loaded in a security
module of a terminal when updating data stored in said security module
of said terminal, said method comprising the steps of: transferring
the commands from a station to said security module of the said
terminal via a transfer means between the said station and the said
terminal; executing the said commands by the said security module of
the said terminal;
recording results of the executed commands in the said terminal;
transferring the said results to the said station via the said
transfer means; and
checking the proper functioning of the said security module of the
said terminal.
The station may be a remote terminal management agency. The transfer
means may e.g. be a telephone line or a (special purpose) card which
is inserted into the terminal.
By recording the results of the executed commands, it is
possible to remotely check the proper functioning of the security
module. Preferably, the commands are transferred to the terminal as
part of a script file, the terminal extracting the respective commands
from the script file and passing them to the security module.
Advantageously the script file contains information allowing the
selective recording of results, i.e. allowing the results of some
commands to be registered, while the results of other commands are not
registered. This makes it possible to control the loading of certain
commands into the security module by requiring the proper execution of
5s
~~v
~~O
CA 02295887 2000-O1-04
r , ,
mr~ oP n yn O-...~~ Or. ,.
a D . w ~e o ~ p
n ~ ~
a w . p - r ~ ~,. .
' c r
< ~ nnc. ~ ,. - ,
t
402286W0 3
the previous command, while allowing other commands (e.g. commands of
which the results are unpredictable) to be loaded without imposing a
restriction.
As the terminal substantially only transfers the commands to the
secure module, the terminal is effectively transparant with respect to
the commands. This makes the terminal substantially independent of the
particular security module used.
The invention will now be described in more detail by way of
example by reference to the accompanying drawings, in which:
Fig. 1 schematically shows a terminal in which the method of the
present invention may be used;
Fig. 2 schematically shows an example of the structure of a
script file containing commands to be loaded;
Fig. 3 schematically shows an example of the structure of a log
file containing results of commands; and
Fig. 4 shows a flow diagram representing the processing of
commands in a security module according to the present invention.
Referring now to Fig. 1 a terminal 1, connected via a
telecommunications link 3 with a station (terminal management center)
4 is shown. As will be explained below, the station 4 may serve both
to make script files and to verify the functioning of the terminal 1.
The terminal 1 comprises at least one security module 2 which during
normal use of the terminal 1 communicates with a smart card 5. The
terminal 1 further comprises a processor 6 connected with an
associated memory (RAM and/or ROM) 7, an I/O (,input/output) unit 8,
and the security module 2. The I/O unit is connected with the
telecommunications link 3, which is e.g. a
~O
HO
CA 02295887 2000-O1-04
WO 99/13612 PCT/EP97/04963
4
subscriber line of a public telephone network (PSTN) or a link of a
computer network.
The security module 2 may comprise a processor, a memory, an I/0
unit and an associated card reader/writer (not shown) for interfacing
' with the IC card (smart card) 5. A security module normally is a
physically and/or cryptographically protected unit for securely.v -~w'
storing data relating to the use of the terminal, e.g. transaction
data such as monetary balances. Although in this text a security
module is mentioned throughout, it will be understood that the present
invention is also applicable to terminals in which the security module
is replaced by another unit having processing and storage means.
In order to load commands into the security module 2 and execute
them while having the possibility to check their proper functioning,
as provided by the present invention, a script file is made in the
station 4. The script file, which will further be explained with
reference to Fig. 2, contains the commands to be loaded and executed,
thus effecting a data transfer to and/or from the security module 2.
Preferably, the terminal 1 verifies the origin of the commands, i.e.
the terminal checks whether the commands were produced by or at least
sent by the station 4. This verification, which serves to prevent
fraudulent modifications of the contents of the security module, may
be effected by comparing a received MAC (message authentication code)
with a MAC calculated by the terminal. Such verification procedures
are well known in the art.
As shown in Fig. 2, a script file 10 may contain a header and a
number of records, each record comprising a type field Ti (e.g. T1), a
command field Ci (e. g. C1) and a result field Ri (e. g. R1). The result
field Ri may be empty, as will be explained later. A command may
contain data to be written in the memory of the security module, such
as a key for encrypting usage data. However, a command may also
contain an instruction to be executed by the security module 2. A
suitable format of the commands Ci (i ranges from 1 to 4 in Fig. 2) is
e.g. disclosed in the IS07816-4 standard.
The type field Ti allows different types of commands to be
distinguished. In the method of the present invention, three different
types of commands can be distinguished, resulting in three different
types of command handling by the terminal.
A first type of command has an associated expected result or
CA 02295887 2000-O1-04
WO 99/13612 PCT/EP97/04963
response R. This type of command is preferably loaded one by one in
the security module, the terminal comparing the actual result Ri' with
the expected result Ri and stopping the loading if a discrepancy, i.e.
a mismatch between Ri and Ri' occurs. With this type of command it is
5" -possible to perform a controlled loading of the security module and to-
check the proper functioning of the security module while-loadi:ng:- '
A second type of command is not accompanied by an expected
response (i.e. the response field Ri may be empty). However, the
terminal preferably registers the actual responses. This type of
command allows a test of the security module to be performed,
especially in the case where an unknown type of security module (of
which the responses are not completely known in advance) is used. The
results may be entered in a log file which can be collected later.
Thus an off-line processing of the commands is possible.
A third type of command is loaded into the security module and
executed without taking the result into account. That is, the result
of this type of command is not registered by the terminal.
It will be understood that the above-mentioned results of the
commands may comprise memory contents, a status (e.g. indicating a
failed write operation), and/or a smart card command. The said
commands may thus effect a data transfer to and/or from the security
module.
As explained above, the terminal extracts the commands from the
script file and passes them to the security module. Although the
terminal is passive with respect to the commands, it is active with
respect to the script file in that it extracts the commands from the
file and derives its mode of operation (check result/no check) from
the type fields contained in the script file. The script file thus
comprises information which influences the functioning of the terminal
with respect to the script file and the commands derived from it.
The script file may comprise only a single command. However, the
size of the script file may vary and is limited only by the amount of
memory available in the terminal. It can also be envisaged that the
script file contains commands in a compressed and/or cryptographically
protected form.
In Fig. 3, an example of a so-called log file is shown. The file
20 comprises a file header and a number of data fields. In these data
fields, the actual results of commands are stored during or after the
CA 02295887 2000-O1-04
WO 99/13612 PCT/EP97/04963
6
processing (logging of the results). The data fields shown contain a
first result R1' of a first executed command and a second result R2'
of a second executed command. In the station 4 (as shown in Fig. 1),
or in another device, these actual results Ri' may be compared with
Sw 'expected results Ri or may be processed in another way.
The flow diagram of Fig. 4 represents by way of example an ---
embodiment of the method of the present invention. The diagram
comprises an initialization step 100, denoted "Start", in which a
command or a script file containing commands is transferred from the
station 4 to the security module 2 of the terminal 1 (cf. Fig. 1).
In step 101, the command is loaded into the processor of the
security module 2, e.g. by extracting the command from the script
file. In step 102, the security module re-calculates the message
authentication code of the command, resulting in an actual
(recalculated) code MAC'. In step 103, this actual code MAC' is
compared with the received code MAC. If the codes are equal, the
received code MAC is considered authentic and the procedure continues
with step 104. If the codes are not equal, the procedure exits via an
appropriate exit routine (not shown), which may generate an error
message.
In step 104, the type of the command is determined by reading
the type (Ti) of the command (cf. Fig. 2) and is temporarily stored.
Then, in step 105, the command (Ci) is executed by the security module
and the results (Ri') are temporarily stored.
In steps 106 through 108 the security module determines if and
how the results are going to be processed.
If, in step 106, the type equals I (first type), the procedure
continues with step I12, in which the expected result (Ri) is read
from the script file (cf. Fig. 2) to be compared with the actual
result (Ri') in step 113. If, in step 113, the results are equal, the
procedure continues with step 109, else the procedure exits (incorrect
result). If the type does not equal I, the procedure continues with
step 107.
If, in step 107, the type equals II (second type), the procedure
continues with step 114 in which the actual result (Ri') is
registered, e.g in the log file of Fig. 3. If the type does not equal
II, the procedure continues with step 108.
If, in step 108, the type equals III (third type), the procedure
CA 02295887 2000-O1-04
WO 99/13612 PCT/EP97/04963
7
continues with step 109. If the type does not equal III, the procedure
exits (incorrect type).
In steps 109 and 110 the security module checks whether the end
of the script file has been reached. If the end of the file is
- detected in step 110, the procedure terminates in step 111, e.g. by
closing and transmitting the log file (if appropriate). rf the-en~-of -
the script file has not yet been reached, the procedure continues with
step 101, in which the next command is loaded.
By processing the results of the commands in dependance of the
type of the individual commands, it is possible to selectively process
the commands of a single script file.
It will be understood that the procedure set out above is given
by way of example only. Thus, the checking of the message
authentication code, or of any other data protecting code, could be
carried out by performing an inverse calculation of the code instead
of a re-calculation as set out in steps 102 and 103. The results of
executed commands are preferably registered by storing these in the
memory of the security module. Alternatively, the results may be
stored in the memory (7) of the terminal. A log file may be stored in
the terminal memory (7) before transmitting the file to the station
(4) or transferring the file to a smart card (5). A script file may
also be stored in the terminal memory (7), each command being loaded
into the security module in step 101 of the above procedure.
As described above, the method of the present invention allows
both a flexible loading of data in the security module and a remote
check of the functioning of the security module.
It will be understood by those skilled in the art that the
embodiments described above are given by way of example only and that
many modifications and additions are possible without departing from
the scope of the present invention.
*rB
