Note: Descriptions are shown in the official language in which they were submitted.
CA 02299294 2000-02-08
PCT/GB98102868
W O 99164995
SECURE TRANSACTION SYSTEM
Technical Field
The present invention relates to a secure transaction system. particularly for
use
over a public network.
~ Background Art
The most common and well-known public data network is the Internet, which
provides network access to members of the public at low cost. Many types of
commercial
transaction which were previously conducted via telephone. mail or private
network may
now be conducted more easily over the Internet. However, intemet protocols
such as
TCP!IP were not designed for security, and it has therefore been necessary to
provide
additional protocols for secure transactions over the Internet. including
transport-level
protocols such as the Secure Sockets Layer (SSL). and application-level
protocols such as
the Secure Hvpertest Transfer Protocol (SHTTP). Such protocols aim to prevent
interception. decryption and forgery of transactions betty°een a client
and a sewer over the
1 ~ Internet. but they do not verify the identity of the user of the client
terminal. For example.
in a credit card transaction. only the user's name and address. and the card
number and
expiry date need be supplied to order goods or services over the Internet. It
is
comparatively easy to obtain the necessary information to cam' out fraudulent
transacnons
over the Internet. Some verification of the users identity is usually
implemented at the
?0 application level. such as the use of passwords. but these too can be
obtained or Guessed.
Nevertheless. various protocols have been proposed for allowing secure
transactions. and particularly secure payment. over the Internet: one example
is Secure
Electronic Transaction (SET). a protocol for credit card transactions over the
Internet. a
modification of which is described in WO 97/41539. Typically. such
transactions involve
three parties: a client which supplies credit card details. a sen~ice provider
senrer operated
by a supplier of goods or services. and an authorisation server which checks
the credit card
details and informs the service provider server whether payment is authorised
by the
operator of the credit card system.
However. conventional electronic transaction systems do not support non-
30 repudiation: in other words. they do not provide sufficient evidence to
confirm that a
specific transaction was authorised.
CA 02299294 2000-02-08
PCT/GB98/02868
WO 99/64995
vEoreover. conventional electronic transactions do not bind a specific user to
the
use of an authorisation card.
Furthermore. conventional electronic transaction systems are limited in their
application. because the authorising server is designed merely to give an
authorise or
decline message on the basis of the details supplied.
Statement of the Invention
According to one aspect of the present invention. there is provided an
electronic
transaction system in which a terminal combines transaction data which is
unique to a
current transaction with terminal data which is unique to that terminal to
generate bound
terminalltransaction information which is sent to the transaction sen~er. The
transaction
sen~er sends the transaction data to an authorisation sen~er which returns
information
which binds the transaction to the identity of the authorisation sewer. The
transaction
server then has available information which binds together the transaction.
the terminal and
the authorisation server in a form which cannot be fraudulently created by the
transaction
server. and therefore cannot be repudiated.
Accordin; to another aspect of the present invention. there is provided an
electronic
transaction system in which an authorisation token is issued to a user.
Information
confirming the identity of both the authorisation token and the user are
presented to an
authority which confirms the validity of this information and makes it
available to an
authorisation server. The authorisation token is then used in an electronic
transaction with a
transaction server. in which user identification information and authorisation
token
information are supplied to the transaction server and passed to the
authorisation server.
The authorisation server compares the user identification information and
authorisation
token information with information previously made available by the authority
and
indicates to the transaction server the result of the comparison. In this way.
because the
correspondence between the user and the token has been verified before the
transaction, the
use of the token by the user can be conf rmed during the transaction.
According to a further aspect of the present invention. there is provided an
electronic transaction system in which a user terminal transmits to a
transaction server
transaction data and identification data. The transaction data is passed from
the transaction
CA 02299294 2000-02-08
PCT/GB98I02868
WO 99/64995
server to an authorisation sen~er. which compares the identification data with
stored
identification data relating to authorised users of the system. The
authorisation server then
transmits to the transaction server an authorisation message indicating how
the
identification data matches with the stored identification data. The
transaction server
determines whether to accept the transaction data on the basis of the
authorisation message
and the transaction data.
Brief Description of the Drawings ,
Specific embodiments of the present invention will now be described with
reference to the accompanying drawings. in which:
Figure 1 is a diagram of the service functions of an authorisation system W an
embodiment of the present invention;
Figure ? is a diagram of the architecture of the system:
Figure 3 is a diagram of the hardware components of a user terminal:
Figure 4 is a diagram of the hardware components of a smartcard:
Figure 5 is a diagram of the sub-systems within the authorisation sen~er in
the
embodiment:
Figure 6 is a diagram of the certification architecture of the system:
Figure 7 is a diagram illustrating a more specific embodiment in which the
system
is used to authorise an electronic form:
Figure 8 shows the flow of data in the specific embodiment;
Figure 9 shows the cryptographic processes applied by the user terminal:
Figure 10 shows the digital signature validation process applied by the
electronic
form server;
Figure 11 shows the transmission of an authorisation request message to the
authorisation server;
Figure 12 shows the authorisation process performed by the authorisation
server;
and ,
Figure 13 shows the authorisation response message process from the
authorisation
server to the electronic form server.
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
4
Modes for Carrvinn Out the Invention
Authorisation Service
Figure 1 shows the service functions which provide a digital signature
generation
and authentication service in an embodiment of the present invention. A
digital signature
generator 10 generates dinital signatures in the form of data which uniquely
identifies a
specific party and binds the signed data to that party. Digital signatures are
a known
technique for protecting data from modification and for identifying the
siQnin~ party. The
signing party is provided with a private/public key pair. which can be used to
generate and
l0 veriy digital signatures. The 'party' is usually assumed to be the user
operating the
computer which stores the private key and generates the digital si'nature.
However, in the
present embodiment. the private key is stored on a smart card and therefore
the digital
signature binds the signed data to the smart card. Hence. the 'part'' is the
smart card.
As is well-known. data encrypted with a private key can be decrypted with the
15 corresponding public key. and vice versa. Suitable cryptographic algorithms
include the
RSA algorithm, described for e~:ample in US 4.40~,s29. In a typical digital
signature
process, the data to be 'signed' is subjected to a hash algorithm. such as the
Secure Hash
Algorithm (SHA). The result is a type of checksum, known as a 'hash. which
depends
both on the values of the bits making up the data and the positions of those
bits. It is
20 therefore very difficult to modify the data while giving the same hash. The
hash is then
encrypted using the private key, to produce a digital signature.
A digital signature can be verified by performing the same hash algorithm on
the
received data as was used to generate the hash encoded in the digital
signature. The digital
signature is then decrypted using the public key and the decrypted hash is
then compared to
25 the calculated hash. If the hashes match. the signature is valid.
Examples of digital signature algorithms are the RSA digital signature. in
which the
hash is encrypted together with an indication of the type of the hash
algorithm using RSA
encryption. and the digital signature algorithm (DSA), in which the hash
algorithm is the
SHA and the hash is encrypted together with a random number by a variant of
the Diffie-
30 Heiman algorithm.
CA 02299294 2000-02-08
WO 991b4995 PCT/GB98/02868
The digital signature venerator 10 exchanges information IE with a digital
signature
acceptor ?0. and sends 'signed' information SI to the digital signature
acceptor ?0 which
includes a first digital signature generated using a private key and a second
digital
signature using a symmetric key, both keys being held by the digital signature
generator
I 0. On receipt of the signed information, the digital signature acceptor ?0
verifies the first
signature and sends an authorisation request AREQ to a digital signature
authoriser 30. The
authorisation request AREQ includes information derived from the signed
information SI
and the second signature. The digital signature authoriser 30 checks the
information
derived from the signed information SI and the second signature, and sends to
the digital
signature acceptor an authorisation response ARES indicating whether the
si'nature is to
be accepted as genuine. The authorisation response ARES is signed with a
digital signature
generated by a private ke~~ held by the digital signature authoriser 30.
Dependent on the
authorisation response, the digital signature acceptor 20 then accepts or
rejects the signed
information SI.
1 ~ In order to provide evidence of the provision and acceptance or rejection
of the
signed information. the digital signature acceptor 20 may further transmit a
notarisation
request NREQ to a signed message notarises 40. including information derived
from the
signed information SI and from the authorisation response ARES. In response.
the signed
message notarises 40 transmits to the digital signature acceptor 20 a
notarisation
?0 confirmation NCF which includes information derived from the notarisation
request
IvREQ. digitally signed by the signed message notarises 40. The digital
signature acceptor
transmits archive deposit information ARDEP, which may for example comprise
the
signed information SI. the authorisation response ARES and the notarisation
confirmation
NCF. to a long-term archive ~0. This information is later retrieved from the
long-term
archive 50 as archive retrieval information ARRET in the event of repudiation
of the
signed information SI.
Optionally. where an independent time reference is needed, for example to
confirm
the exact time of a transaction such as the sending and receipt of the signed
information SI,
information from a standard time signal source 60 is made available to each of
the
functions described above and is incorporated in each digitally signed
message.
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
6
Svstem Architecture
A high-level system architecture of the di'ital signature authorisation
sen~ice is
shov~~n in Figure 2. Like parts to those of Fi~~ure 1 carry the same reference
numerals.
.4 user 12 wishing to subscribe to the digital signature service must first
apply for a
smart card 18 from which the user's digital signatures are derived. The user
1? has a
computer 14 connectable to the Internet 100 via a modem 16. usinv for example
web
browser software and TCP/IP protocols as is well-known in the art.
The components of the computer 14. which may be an IBM-compatible 'personal
computer' or Apple Macintosh computer. are shown in Figure 3. A CPU 110 is
connected
through a bus 120 to main memory 130. a disc controller I40 connected to a
hard disc 14~,
a user interface controller I ~0 connected to a keyboard I ~2 and other input
devices such as
a mouse 1 ~4, a display controller 160 connected to a visual display 16~. and
an I/O
controller 170. The I/0 controller 170 controls the modem 16 and a card reader
174 into
which a smart card can be docked. Optionally, a biometric device I 80 is
connected to the
1 ~ I/O controller 170 or to the user interface controller 1 ~0. The biometric
device 180 may be
a fin=erprint scanner, an iris scanner. or another device which allows
information derived
uniquely from the user 12 to be input to the computer 14. The fingerprint
scanner may be
integrated with the key board 1 ~?.
The user accesses a customer server 70 through the Internet 100 and requests
subscription to the digital signature service. The request is passed on to a
card bureau 90 by
a suitable form of secure communication. The card bureau 90 sends a smart card
18 to the
user I 2. An example of the components within the smart card 18 is shown in
Fitture 4.
The smart card 18 contains a processor 200 connected to a memory ~ 10 and an
external connector 220. The card 18 may include a power source such as a cell
intesrated
2~ within the card 18. or power may be supplied through the connector 220 by
the card reader
174. At least part of the memory 210 is non-volatile so that a operating
program and data
are stored when the card 18 is removed from the reader 174.
A public/private key pair and a card identity code are recorded in the non-
volatile
memory of the card 18 during manufacture. The private key is protected from
being read
from the card by an operating system running on the processor 200 and
optionally by
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
7
hardware protection measures which prevent the non-volatile memory from bein~~
physically examined to determine its content.
When a request is received from the customer server 70. the name of the user
12 is
printed on the card 18. which is then sent to the user 1?. A status message is
sent to the
authorisation sen~er to indicate that the card 18 is issued but inactive.
The user 1? then takes the card 18 to the public premises 80 of an
organisation
which supports the digital signature service. where the user's identity is
checked against
the identity of the user to whom the card 18 has been issued. Once the user's
identity has
been verified. a status message V is sent from the premises 80 to a card
management server
38 connected to the authorisation server ~0, the message identifying the card
18 and the
user i ~. The user 1? is also issued with the card reader 17.~ and application
software for the
digital si'nature service. ifthe user 1? does not already have these.
A PIN is recorded in the card 18 either before bein; issued to the user, or by
the
user the first time the card 18 is used in a transaction. In the former case.
the user is
1 ~ notified of the PIN afrer the identity verification has taken place.
To use the digital si,nature sen°ice. the user 13 inserts the card 18
into the card
reader 174. Application sofrware running on the computer 14 then prompts the
user 12 for
a PIi~. The user enters a PIN which is compared to that stored on the card 18.
and the
application generates a card validation result (VR) which indicates whether a
PIN has been
requested and w=hether the entered PIN matched that stored on the card 18.
Additionally or alternatively. the computer 14 obtains biometric data from the
biometric device 180 if this is present. The smartcard 18 generates a digital
signature for
the signed information SI transmitted by the computer 14 to the sen~ice
provider 20. as will
be described in a specific example below.
2~ The sen~ice provider ?0 may comprise a general purpose computer running web
server software and connected to the Internet 100. The service provider 20
also runs
authorisation sofrware for communication with the authorisation server 30.
The authorisation sen~er 30 comprises a general purpose computer running
authorisation server software and connected to the Internet 100. As shown in
Figures 2 and
~. the authorisation server 30 is also connected, for example over a local or
private
network. to a public key server 3?. a card authentication server 34 and a
customer
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
8
verification server 36. The public keyf ser,-er 32 and the card authentication
sen~er 34
comprise dedicated hardware modules including encryption /decryption
acceleration
hardware. The customer verification ser<~er 36 stores a database containing
the details of
authorised users of the digital signature service.
6 The authorisation server 30 receives from the sen~ice provider ?0 the
authorisation
request AREQ. which includes a hash H of the signed information SI. a public
key
certificate. identification information relating to the card 18 and the user
12. and card
authentication information. The authorisation server 30 sends the card
authentication
information CCHK to the card authentication server 34. which checks the
authenticity of
the card 18 and returns a response CRES indicating whether the card is
authentic or not.
The authentication server 30 sends the user identification information ID to
the customer
verification sen~er;6. which returns a response IDRES indicating whether. or
to what
extent. the customer identity details are correct.
The authorisation server 30 generates from the responses CRES and IDRES an
1~ authorisation message AM. which is sent to the public key sen~er ~2. The
public key sen~er
32 signs the authorisation message AM to produce a signed authorisation
response ARES
which is transmitted to the service provider ?0.
Public Kev Hierarchy
?~ The digital signatures are generated. verified and authorised using public
key
cryptography, as explained above. The public keys are distributed by means of
public key
certificates. so that users of public keys can trust that the public keys
belong to the parties
with which the users wish to communicate. As is well known. a public key
certificate
consists of a name identifying a party who holds a private key (in this case,
the card I 8),
the corresponding public key. and a digital signature comprising a hash of the
name and the
public key, encrypted using the private key of a certification authority
trusted by the user.
If the user does not have the certification authority's public key. this can
be obtained from
the certification authority's public key certificate. which is signed by a
root certification
authority. Thus. a hierarchy of public key certificates may be used.
ultimately administered
30 by a root certification authority which is always trusted.
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
9
If a public; private key pair is chan'ed. however, the public key certificate
is no
longer valid. The old public key certificate may be revoked by placing a code
identifying
that certificate on a Certificate Revocation List CRL, which is circulated
periodically to
users of the public key. Before a public key certificate is used. it may first
be checked
a;ainst the CRL.
Figure 6 shows the hierarchy of keys in the present embodiment. The smartcard
I 8
performs the digital signature process using a private key SCK stored within
the card 18.
The corresponding public key is contained within a smart card certificate SCC
stored
v~~ithin the card and signed using a card certification private key CCK of a
card certification
authority 1 I0. The corresponding public key is contained within a card
certification
authority certificate CCC which is signed by a root certification authority
private key RCK
of a root certification authority 1?0. The root certification authority
private key RCK is
also used to sign the public key certificate ASC of the authorisation sen~er
30. The
corresponding public key is distributed in a root certification authority
public key
certificate RCC. which is self signed using the correspondin<, private key
RCK. The
authorisation server private key ASK is used to provide a digital signature on
the
authorisation response ARES.
Card .Authentication
?0 In addition to the public key transactions described above. the smart card
18 also
performs a symmetric key card authentication function with the authentication
sen-er 30.
using a separate private key stored on the card 18. The process uses a two-key
triple data
encwption standard (DES. encrypt-decn~pt-encrypt) algorithm in Cipher Block
Chaining
Mode to produce an eight byte message authentication code (MAC).
2~ The symmetric key authentication function is used for secure communications
between the smartcard 18 and the authentication server 30, which the service
provider ?0
passes transparently but is unable to decrypt. For each card authentication
transaction. the
MAC is calculated from a combination of: data stored internally in the card
18. including a
variable application transaction counter value ATC which is incremented for
each
~0 transaction. and a card identity number N which is included in the public
key certificate
SCC: data supplied by the service provider 20. including the time. date and
the identity of
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
the service provider. so as to bind the MAC to the specific transaction: a
hash H of the
sieved information SI. so as to bind the MAC to the data supplied and to the
digital
signature; the validation result VR or information derived from the biometric
data. and the
second unpredictable number UN2.
Electronic Forms Implementation
A more specific embodiment will now be described with reference to Figures 7
to
1 ~. in which the di;ital signature system is used to authenticate a completed
form supplied
electronically by the user 1? to the sewice provider ?0. which is in this case
operated by a
10 ~lovernment department. For convenience. Figures 7 to 13 show the
topological connection
between the computer 14 and the service provider 20. and benween the ser'~ice
provider ?0
and the authorisation sen~er 30. as being through separate nenworks but in
this example the
connections are both through the Internet.
Figure 8 shows the data transmission which takes place during a transaction.
The
computer 14 has already established an Internet connection to the sen~ice
provider ?0. and
is running web browser software. In response to a request initiated by the
user 1?, the
service provider ?0 sends data D comprising HTML pages representing a blank
form (such
as a form for registering a new business). The user 1'? completes the form by
entering data
within the brovvser software and requesting submission of the completed form
to the
?0 sewice provider ?0. The browser software supports the digital signature
sen~ice, for
example by means of a 'plug-in~ which modifies standard browser software. so
that the
user 12 is prompted to enter a PIN when requesting submission of the completed
form. If
the smartcard 18 is not located in the card reader 174. the software prompts
the user I2 to
do this.
At a data processing stage DP. the smartcard 18 venerates a digital signature
from
the form data F of the completed form and the smart card private key SCK. The
signed data
SD is then sent to the service provider ?0. which verifies the signature by
recovering the
card public key from the smart card certificate SCC using the card
certification public key
recovered from the card certification authority certificate CCC. recalculating
the hash
0 function for the form data and comparing the recalculated hash function with
the one
sieved with the smart card key SCK and included in the signed data SD.
Signature
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
verification data SVD derived from the signed data SD is sent by the service
provider ?0 to
the authorisation server 30.
Card authentication data CAD. which comprises the MAC and the input data used
to generate the MAC. and the user identification data ID are transmitted to
the service
provider '_'0 and passed to the authentication server 30. The user
identification data ID
comprises for example Lhe name. address and date of birth of the user. entered
by the user
12 and transmitted by the brow~ser software in a separate field from the
signed data SD.
Optionally, biometric data from the biometric device 180 is included in the
user
identification information. Collectively. the signature verification data SVD.
the card
authentication data CAD and the user identification data ID comprise the
authorisation
request AREQ submitted to the authorisation server 30.
The authorisation server 30 checks the authorisation request .AREQ for
counterfeit
or replayed cryptograms, checks whether the smartcard public key certificate
SCC matches
the card identity and checks the user identification data ID against an entry
in a database of
1 ~ details of known cardholders. The authentication server also verifies the
MAC against the
input data used to generate the MAC, using the appropriate symmetric key. The
results of
these checks are digitally signed using the authorisation server private key
ASIL and sent as
the authorisation response ARES to the service provider ?0.
Some of the above processes will now be explained in greater detail.
User to Sewice Provider
Figure 9 shows how the data sent from the user's computer 14 to the ser,~ice
provider ?0 is generated. The data D sent from the sen~ice provider 20
includes two
random or otherwise unpredictable 3?-bit numbers UN 1 and UIvT?. the date and
time of the
2~ transaction and a sen~er identifier SID. The first unpredictable number is
embedded in the
HTML form as a readable serial number and is returned in the form data F.
The application software calculates a hash of the completed form data F using
a
secure hash algorithm SHA and sends the hash to the card 18. to'ether with the
second
unpredictable number UN?, validation result VR. the date and time and the
sen~er
identifier SID. for use in the DES encryption process to generate the MAC. The
card
generates an application transaction counter value ATC which is also input to
the DES
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
12
process. The hash is also supplied as an input to an RSA public kcy encryption
process.
The card public key certificate SCC is stored.in the card 18 and is retrieved
by the
application software together with the MAC and signature data SD. for
transmission to the
service provider ?0.
Signature Validation
The process performed by the service provider 30 to validate the signature of
the
signed data SD is shown in Figure I 0. The sen~ice provider ?0 receives the
form data F and
checks (S 10) that the serial number UN I matches that of the blank form
previously sent. A
hash is calculated from the form data F using the same SHA as performed by the
card 18.
The card public key is retrieved from the card public key certificate SCC and
is used to
decrypt (S?0) the si'nature data SD to extract the hash calculated by the
users computer
14. The two hashes are compared (S30) and the signature is validated if they
match.
However. this process only establishes that the form was digitally si_ned
using the card 18.
l~ The sen~ice provider 20 must further check that the card 18 is valid and is
being used by
the authorised cardholder. as will be described below.
Authorisation Request
The sen~ice provider ?0 sends the following information to the authorisation
server
?0 30 in the authorisation request message ARES. as illustrated in Figure 1 I:
the user
identification data ID. including any biometric data. the second unpredictable
number
UIv?. the hash H calculated from the received form data F, the card public key
certificate
SCC. the validation result VR. the application transaction counter ATC and the
message
authentication code MAC. The form of the authorisation request message is
shown in detail
25 in Table 1 below:
Table 1 - Authorisation Re~c uest Message
Field Name , Field Description
Version Version of the Authorisation Request
Message
Sewice Provider Message reference supplied by service
Ref. provider
Authorisation Sen~iceAuthorisation service reference supplied
by the
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
13
Ref. sen~ice pro~~ider
Contract Info A URL for a contract govemin, the
use of the
authorisation sen~ice
Request Sent Time The time. as supplied by the sen~ice
provider
system clock. at which the message
was
transmitted
SCC Public key certificate of the card
18
H Hash of the form data F
User Time The time. from the users computer
14. at which
the authorisation request v~~as transmitted
from the
computer 1 ~
Sewice Provider Sewice provider identity used for
Identity generation of
the MAC
UN3 Second unpredictable number
Card Data Data generated by the application
and the card 18
and passed to the authorisation server
User Surname ~ Users surname
User First Name User's first names)
User Title User's title
User DOB User's date of birth
User Address ~ First line of user's address
User Postcode User's postcode
The Card Data described in Table 1 comprises the fields shown below in Table
?:
Table ? - Card Data Structure
Field Name Field Description
Cryptogram Info Data Indicates the type of the
cryptogram
Cryptogram Version Number Version number of the cryptogram
~
Application Transaction CounterA counter value. stored
in the card
I 8, which is updated after
each
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
14
transaction
~
MAC Cryptogram venerated by
the card 18
VR Validation Result
Derivation Key Index Index which identifies the
symmetric
key to the authorisation
sen~er 30
Authorisation Request Process
The authorisation server 30 determines the authorisation response .ARES as
illustrated in Figure 1?. The user identity information ID is sent to the
customer
verification server 36, which checks whether this information matches stored
user identity
information related to the card number, and returns a response IDRES
indicating whether
these details are correct and the status of the card. The card authentication
data CAD are
sent to the card authentication sen~er 34 where the MAC is verified using the
card number
N, extracted from the card public key certificate, the second unpredictable
number LTN2
and the date, time and server identity originally provided by the sen~ice
provider ?0. The
card authentication server 34 also checks the validation result VR. determines
whether the
cryptogram has been replayed or the card counterfeited. and whether the card
public key
certificate SCC is valid and corresponds to the MAC.
1 ~ Optionally. the customer verification server 36 stores a database of
biometric
information for each authorised user, and the response IDRES includes
information on the
confidence level with which biometric data contained within the user identim
information
ID matches the stored profile for that user.
Authorisation Rest~onse
The authorisation server 30 formats the authorisation response message ARES
and
transmits it to the service provider 20 by means of a process illustrated in
Figure 13. First,
an authorisation message AM is generated including the following information:
the hash
value H and the user identification information ID copied from the
authorisation request
?~ AREQ. and a response code indicating the card authentication and user
verification server
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
responses. This message AM is sent to the public key server 3? which generates
a digital
signature for the message usin' the authorisation server private key ASh and
returns this
signature AS together with the authorisation server public kev certificate
ASC. The
authorisation server then sends the authorisation message AM. the signature AS
and the
authorisation server certificate ASC to the service provider 20. together with
a reference
code indicating the agreement under w°hich the authorisation is made to
the service
provider 20.
The data content of the authorisation message is summarised below in Table 3:
Table s - .Authorisation Message Contents '
Field ?dame Field Description
Senice Provider ReferenceMessage reference number supplied
by the
service provider. copied from the
authorisation
request message
Hash Hash of the authorisation request
message
Request Received TimeThe time. from the authorisation
server. at
which the authorisation request
was received
Authorisation ResponseAuthorisation Response Data
Response Sent Time Time. from the authorisation server.
at which
the response was sent
The Authorisation Response Data is coded as individual bits, as shown in Table
4:
Table 4 - .4uthorisation Response Data Bit Meanine
Index Bit Meaning
I~o.
0 0 Card does not exist
1 Card not activated
2 Card expired
3 Card reported lost
4 Card reported stolen
Could not verify
6 Card reeistered as demo
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
16
7 Verification error - see following bytes
1 0 Unspecified address match failure
1 Surname did not match
First name did not match
3 Title did not match
4 Date of birth did not match
First line of address did not match
6 Postcode did not match
(Unused )
0 Unspecified authentication failure
1 Card authentication could not be performed
Cryptogram verification failure
Application Transaction Counter value invalid
PIN verif canon not performed
PIN verification failed
Optionally. the authorisation response data may include an indication of the
confidence level with which the biometric data included in the customer
identification
information matches that stored in the customer verification server 36: for
example.
~ pattern matching algorithms used in iris and fingerprint scans will return a
suitable value
based on the correlation between an input and a reference pattern.
On the basis of the authorisation response ARES. and the result of the
sisnature
verification process. the service provider 20 determines how the form data F
is to be
processed. For example, if the signature is verified and the transaction
authorised by the
authorisation sen~er. the service provider may update a record corresponding
to the user 12
to add the information included in the form data F. If either the signature is
not verified. or
the transaction not authorised. the form data F may be discarded and/or a
message
transmitted to the user's computer indicating that the form has not been
accepted.
Since the authorisation response ARES contains detailed information about the
1 ~ results of the various authorization checks. the sen~ice provider may
allow certain types of
CA 02299294 2000-02-08
WO 99164995 PCT/GB98/02868
17
transaction to proceed even if some of the authorization checks are indicated
as
unsuccessful. For example. if the title did not match. the service provider
judges this as
insignificant. since the user is unambiguously identified by other data, and
the transaction
is processed as acceptable by the sen~ice provider 20.
In the option where the authorisation response ARES includes an indication of
the
confidence level with which the supplied user identification information ID
matches the
stored user identification information. the sewice provider ?0 sets a minimum
confidence
level for the current transaction and allows the transaction to proceed if
this confidence
level is exceeded. Preferably. this minimum confidence level is determined
according to
the monetary value of the transaction. or if the transaction does not have a
specified
monetary value. the consequences of fraud in that transaction.
Preferably. in the case of fraud. the authorisation response ARES is used to
determine the liability between the operator of the service provider 20 and
the operator of
the authorisation sen~er 30. For example. if any of the bits with index 0 are
set. the
1 ~ authorisation sen~er operator will not accept any liability if the service
provider accepts the
transaction, but if only one of the bits with index 1 is set. the
authorisation sen~er operator
will accept liability only to a prearranged limit. and if none of the bits is
set. the
authorisation sewer operator will accept liability to the maximum value
prearranged for the
user 1?.
?0 The present invention is not limited to the use of the Internet but may
also be
applied to transactions over other networks which are not inherently secure.
The network
used to connect the user's computer 14 to the service provider 20 may be
separate from
that used to connect the service provider ?0 to the authorisation sen~er 30.
Although the above embodiment is described with reference to one specific
user. it
is evident that similar procedures are carried out for different users so that
the system can
perform transactions initiated by any one of a large number of users.
The present invention is not limited to any specific type of transaction such
as the
authentication of forms or the authorisation of payment.
In an alternative embodiment. the smart card 18 may sign the form data using
the
30 symmetric encryption key under the DES process and may dispense with the
RSA
encryption process. The service provider ?0 will not then be able to verify
the signature,
CA 02299294 2000-02-08
WO 99/64995 PCT/GB98/02868
is
but instead recalculates the hash and transmits this to the authorisation
sen~er 30 for
verification.
In an alternative embodiment. the smart card l 8 uses the private key SCK both
to
produce the MAC and to sign the form data F and does not use any symmetric
encryption
key. In that case. the sen~ice provider 20 checks the card application data
C.AD using the
public key contained in the smartcard key certificate SCC to ensure that the
MAC was
generated from the input data using the private key SCK. However. the sen~ice
provider 20
is unable to check wfiether card specific data such as the application
transaction counter
ATC and the card number ?~' are correct and correspond to a valid card. so
that this card
specific data is still sent to the authorization server 30. which checks the
consistency of the
card specific data and the validim of the card 18. Likewise, the user
identification data ID
is still sent to the authorization sen~er 30 for comparison with the
cardholder details
accessible by the authorization server.
The above embodiments are described by way of example and are not to be
1 ~ construed as limiting the scope of the invention. Instead. the invention
extends to all
variants which fall within the scope of the following claims.
