CA2299294A1 - Secure transaction system - Google Patents
Secure transaction system Download PDFInfo
- Publication number
- CA2299294A1 CA2299294A1 CA002299294A CA2299294A CA2299294A1 CA 2299294 A1 CA2299294 A1 CA 2299294A1 CA 002299294 A CA002299294 A CA 002299294A CA 2299294 A CA2299294 A CA 2299294A CA 2299294 A1 CA2299294 A1 CA 2299294A1
- Authority
- CA
- Canada
- Prior art keywords
- server
- transaction
- data
- authorisation
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
Abstract
In a system for authentification of transactions over a public network (100), a terminal (14) sends digitally signed transaction data (SD) to a service provider (20) over the public network (100), together with card application data (CAD) generated by a smart card (18). The card application data (CAD) is sent to an authorization server (30) which checks that the smart card (18) is valid and that the card application data (CAD) must have been generated by that smart card (18) in the current transaction. User identification information (ID) is also sent from the terminal (14) to the service provider (20) and thence to the authorisation server (30), where this information (ID) is checked against the correct user details for the smart card (18). The results of these checks are indicated in a digitally signed authorisation response (ARES) from the authorization server (30) to the service provided (20), which then determines whether to proceed with the transaction by setting acceptance criteria for the current transaction and determining from the authorisation response (ARES) whether these criteria are met.
Description
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.
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 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.
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.
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.
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 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 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.
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 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 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 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
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 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 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 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 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 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 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, 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.
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.
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 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.
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.
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.
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 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 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.
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 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 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 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
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 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 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 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 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 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 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, 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.
Claims (27)
1. A method of processing a data transaction between a terminal (14) and a first server (20) over a public network (100) and between the first server (20) and a second server (30), comprising:
transmitting transaction message data (F) and identification data (ID) from said terminal (14) to said first server (20);
transmitting said identification data (ID) from said first server (20) to said second server (30);
comparing said receiv ed identification data (ID) at said second server (30) with previously stored identification data and generating an authorisation message (ARES) indicating the degree of matching between said received identification data (ID) and said previously stored identification data;
transmitting said authorisation message (ARES) from said second server (30) to said first server (20):
and processing said transaction message data (F) at said first server (20) according to the received authorisation message (ARES).
transmitting transaction message data (F) and identification data (ID) from said terminal (14) to said first server (20);
transmitting said identification data (ID) from said first server (20) to said second server (30);
comparing said receiv ed identification data (ID) at said second server (30) with previously stored identification data and generating an authorisation message (ARES) indicating the degree of matching between said received identification data (ID) and said previously stored identification data;
transmitting said authorisation message (ARES) from said second server (30) to said first server (20):
and processing said transaction message data (F) at said first server (20) according to the received authorisation message (ARES).
2. A method as claimed in claim 1, wherein said transaction data (F) is processed at said first server (20) further according to the content of the transaction data (F).
3. A method as claimed in claim 2. wherein the processing step comprises:
determining acceptance criteria from the authorisation message (ARES);
determining one or more acceptance parameters from the transaction message data (F);
and processing the transaction message data (F) as valid if the one or more acceptance parameters meet the acceptance criteria.
determining acceptance criteria from the authorisation message (ARES);
determining one or more acceptance parameters from the transaction message data (F);
and processing the transaction message data (F) as valid if the one or more acceptance parameters meet the acceptance criteria.
4. A method as claimed in any preceding claim. wherein the identification data (ID) is sent to the second server together with transaction identification information (ATC, UN2, H) specific to the current transaction. said authorisation response (ARES) also indicating whether the transaction identification information (ATC. UN2, H) has been verified.
5. A method as claimed in claim 4. wherein said transaction identification information (ATC. UN2, H) is generated by said terminal (14) together with a digital signature (MAC) which is also sent to the second server (30), and the second server (30) verifies the digital signature (MAC) against the transaction identification information { ATC. UN2, H).
6. A method as claimed in any preceding claim, wherein the authorisation message (ARES) is signed by the second server (30), and the signed authorisation message (ARES) is verified by the first server (20), the processing of the transaction message data (F) being dependent on said verification by the first server (20).
7. A method of processing a data transaction between a terminal (14) and a first server (20) over a public network (100) and between the first server (20) and a second server (30), comprising:
generating transaction message data (F) at said terminal (14);
generating at the terminal (14) variable terminal identification information (MAC) which identifies the terminal (14) and varies for each said data transaction;
digitally signing said transaction message data (F);
transmitting said signed transaction message data (SD) and said terminal identification information (MAC) from said terminal (14) to said first server (20) over said public network (100);
verifying said transaction message data (F) at said first server (20);
transmitting said terminal identification information (MAC) from said first server (20) to said second server (30);
verifying said terminal identification information (MAC) at said second server (30) and generating a transaction authorisation message (ARES) dependent on the result:
digitally signing said transaction authorisation message (ARES) at said second server (30);
and transmitting said signed transaction authorisation message (ARES) from said second server {30) to said first server (20).
generating transaction message data (F) at said terminal (14);
generating at the terminal (14) variable terminal identification information (MAC) which identifies the terminal (14) and varies for each said data transaction;
digitally signing said transaction message data (F);
transmitting said signed transaction message data (SD) and said terminal identification information (MAC) from said terminal (14) to said first server (20) over said public network (100);
verifying said transaction message data (F) at said first server (20);
transmitting said terminal identification information (MAC) from said first server (20) to said second server (30);
verifying said terminal identification information (MAC) at said second server (30) and generating a transaction authorisation message (ARES) dependent on the result:
digitally signing said transaction authorisation message (ARES) at said second server (30);
and transmitting said signed transaction authorisation message (ARES) from said second server {30) to said first server (20).
8. A method as claimed in claim 7. wherein said step of verifying said transaction message data (F) includes verifying the consistency of the transaction message data (F).
9. A method as claimed in claim 7 or claim 8. wherein said step of verifying said transaction message data {F) includes verifying the digital signature of the transaction message data at the first server (20).
10. A method as claimed in claim 7 or claim 8, further comprising transmitting said signed transaction message data (SD) to said second server (30) and verifying the digital signature of said transaction message data (F) at said second server (30).
11. A method as claimed in any one of claims 7 to 10. wherein said terminal identification information (MAC) is digitally signed at the terminal (14).
12. A method as claimed in claim 11. further comprising verifying the digital signature of said terminal identification information (MAC) at said second server (30).
13. A method as claimed in claim 11. further comprising verifying the digital signature of said terminal identification information (MAC) at said first server (20).
14. A method as claimed in claim 12 or 13. wherein the terminal identification information (MAC) is signed and verified using a symmetric key pair.
15. A method as claimed in any one of claims 7 to 14, including inputting user identification information (ID) from a user (12) at said terminal (14), wherein the user identification information (ID) is transmitted to said first server (20) and from said first server (20) to said second server (30), the method further comprising:
comparing the received user identification information (ID) at said second server (30) with previously stored user identification information, the content of the authorisation message (ARES) being dependent on said comparison of said user identification information (ID).
comparing the received user identification information (ID) at said second server (30) with previously stored user identification information, the content of the authorisation message (ARES) being dependent on said comparison of said user identification information (ID).
16. A method as claimed in any one of claims 7 to 15, including supplying information (ARDEP) derived from said authorisation message (ARES) and said transaction identification information (SI) from said first server (20) to data storage means (50).
17. A method as claimed in any one of claims 7 to 16, wherein said terminal (14) includes a removable authentication token (18) from which the terminal identification information (MAC) is derived, the terminal identification information (MAC) identifying the removable authentication token (18).
18. A method as claimed in any one of claims 7 to 16, wherein said terminal (14) includes a removable authentication token (18) from which the digital signature of the transaction message data (F) is derived.
19. A method as claimed in claim 17 or claim 18, both when dependent on claim 15, further comprising, prior to said data transaction:
verifying the identity of the user (12) and of the token (18) and transmitting a verification message (V) to the second server (30); and storing status information at said second server (30) in response to said verification message (V);
wherein said authorisation message (ARES) is dependent on said status information.
verifying the identity of the user (12) and of the token (18) and transmitting a verification message (V) to the second server (30); and storing status information at said second server (30) in response to said verification message (V);
wherein said authorisation message (ARES) is dependent on said status information.
20. A method as claimed in any one of claims 7 to 19, further comprising processing said transaction message data (F) at said first server (20) according to the received authorisation message (ARES).
21. A method as claimed in claim 20, wherein the processing step comprises:
determining acceptance criteria from the authorisation message (ARES):
determining one or more acceptance parameters from the transaction message data (F);
and processing the transaction message data (F) as valid if the one or more acceptance parameters meet the acceptance criteria.
determining acceptance criteria from the authorisation message (ARES):
determining one or more acceptance parameters from the transaction message data (F);
and processing the transaction message data (F) as valid if the one or more acceptance parameters meet the acceptance criteria.
22. A method as claimed in any preceding claim, wherein said transmissions between the first server (20) and the second server (30) are performed over said public network (100).
23. A method as claimed in any preceding claim, wherein said public network (100) is a packet-switched network.
24. A method as performed by the first server (20) in a method as claimed in any preceding claim.
25. A method as performed by the second server (30) in a method as claimed in any one of claims 1 to 23.
26. Apparatus arranged to perform the method as claimed in claim 24.
27. Apparatus arranged to perform the method as claimed in claim 25.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9812520.6 | 1998-06-10 | ||
| GB9812520A GB2338381A (en) | 1998-06-10 | 1998-06-10 | Cryptographic authentication for internet using two servers |
| PCT/GB1998/002868 WO1999064995A1 (en) | 1998-06-10 | 1998-09-23 | Secure transaction system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2299294A1 true CA2299294A1 (en) | 1999-12-16 |
Family
ID=10833527
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002299294A Abandoned CA2299294A1 (en) | 1998-06-10 | 1998-09-23 | Secure transaction system |
Country Status (7)
| Country | Link |
|---|---|
| JP (1) | JP2002517869A (en) |
| CN (1) | CN1266520A (en) |
| AU (1) | AU9175798A (en) |
| CA (1) | CA2299294A1 (en) |
| DE (1) | DE29824106U1 (en) |
| GB (1) | GB2338381A (en) |
| WO (1) | WO1999064995A1 (en) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI112286B (en) * | 2000-01-24 | 2003-11-14 | Smarttrust Systems Oy | Payment service apparatus and secure payment procedure |
| AU2005203599B2 (en) * | 2000-02-14 | 2007-03-08 | Yong Kin Ong (Michael) | Electronic funds transfer |
| AUPQ556600A0 (en) | 2000-02-14 | 2000-03-02 | Ong, Yong Kin (Michael) | Electronic funds transfers-zipfund |
| AUPQ564400A0 (en) | 2000-02-16 | 2000-03-09 | Ong, Yong Kin (Michael) | Electronic credit card-ecc |
| US8322606B2 (en) | 2000-02-16 | 2012-12-04 | Ong Yong Kin Michael | Electronic credit card—ECC |
| EP2278538A1 (en) * | 2000-04-24 | 2011-01-26 | Visa International Service Association | Online payer authentication service |
| DE10020565A1 (en) * | 2000-04-27 | 2001-10-31 | Deutsche Post Ag | Process in which a customer retrieves monetary information from a loading point |
| NL1015564C2 (en) * | 2000-05-30 | 2001-12-03 | Beleggings En Exploitatie Mij | Payment system via internet or other telecommunications network has multiple devices to identify and locate user and to prevent fraud |
| AU7001201A (en) * | 2000-06-22 | 2002-01-02 | Mastercard International Inc | An improved method and system for conducting secure payments over a computer network without a pseudo or proxy account number |
| EP1193658A1 (en) * | 2000-09-29 | 2002-04-03 | Siemens Aktiengesellschaft | Method and system for transmitting an amount of electronic money from a credit memory |
| DE10057536A1 (en) * | 2000-10-20 | 2002-04-25 | Klaus Roth | Sale of digital data of any type, such as film, books, music, etc., where the data is encoded using a person specific access code to prevent fraudulent copying |
| US7206936B2 (en) * | 2001-12-19 | 2007-04-17 | Northrop Grumman Corporation | Revocation and updating of tokens in a public key infrastructure system |
| FR2835636A1 (en) * | 2002-02-07 | 2003-08-08 | Carmel Giacopino | Business computer system for transactions includes card reader authentication system and link to network for secure data exchange |
| AU2004225193B2 (en) * | 2003-04-01 | 2009-07-30 | Entropic Technologies Pty Ltd | A system for secure communication |
| WO2004088917A1 (en) * | 2003-04-01 | 2004-10-14 | Entropic Technologies Pty Ltd | A system for secure communication |
| US7694330B2 (en) * | 2003-05-23 | 2010-04-06 | Industrial Technology Research Institute | Personal authentication device and system and method thereof |
| US11063766B2 (en) | 2003-06-13 | 2021-07-13 | Ward Participations B.V. | Method and system for performing a transaction and for performing a verification of legitimate access to, or use of digital data |
| WO2004111751A2 (en) * | 2003-06-13 | 2004-12-23 | Orbid Limited | Method and system for performing a transaction and for performing a verification of legitimate use of digital data |
| CN100388726C (en) * | 2003-11-14 | 2008-05-14 | 国际商业机器公司 | System and method for deferring the delivery of an e-mail |
| CN100388298C (en) * | 2005-01-21 | 2008-05-14 | 高晶 | System and method of implementing online reading of second generation of identity cards by means of shared SAM_V |
| WO2006121322A1 (en) * | 2005-05-10 | 2006-11-16 | Dts Ltd. | Transaction method and verification method |
| JP4857657B2 (en) * | 2005-08-23 | 2012-01-18 | 大日本印刷株式会社 | Access management system and access management method |
| KR20070050712A (en) * | 2005-11-11 | 2007-05-16 | 엘지전자 주식회사 | Method and system for obtaining digital rights of portable memory card |
| US7877784B2 (en) * | 2007-06-07 | 2011-01-25 | Alcatel Lucent | Verifying authenticity of webpages |
| CN102236770B (en) * | 2010-04-20 | 2015-05-20 | 公安部第一研究所 | Novel machine-readable travel document access control method |
| US10051468B2 (en) * | 2013-05-24 | 2018-08-14 | Prashant G. Paima | Process for authenticating an identity of a user |
| CN104156681A (en) * | 2014-07-28 | 2014-11-19 | 上海辰锐信息科技公司 | Identity recognition system |
| US9560030B2 (en) | 2014-11-07 | 2017-01-31 | Kaiser Foundation Hospitals | Nodal random authentication |
| US9560046B2 (en) | 2014-11-07 | 2017-01-31 | Kaiser Foundation Hospitals | Device notarization |
| CN104517086B (en) * | 2014-12-31 | 2018-08-21 | 山东信通电子股份有限公司 | ID card information read method |
| CN104700057A (en) * | 2015-04-02 | 2015-06-10 | 山东信通电子股份有限公司 | Sharable resources type resident identification card reading achievement method and resident identification card reader |
| CN104966035B (en) * | 2015-05-20 | 2018-09-25 | 李明 | ID card information acquisition methods, apparatus and system |
| CN104899533B (en) * | 2015-05-20 | 2018-11-27 | 李明 | ID card information acquisition methods, apparatus and system |
| TW201712591A (en) * | 2015-09-30 | 2017-04-01 | Chunghwa Telecom Co Ltd | Data authorization management and verification method for smart card can respectively perform protection for data items on smart card to restrict the application service end to merely obtain authorized data items |
| CA3029619C (en) * | 2016-07-01 | 2022-12-06 | American Express Travel Related Services Company, Inc. | Systems and methods for validating transmissions over communication channels |
| CN113221797B (en) * | 2021-05-24 | 2024-01-19 | 厦门科路德科技有限公司 | Anti-counterfeiting identification method, device and equipment for printed document |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4405829A (en) | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
| US5280527A (en) * | 1992-04-14 | 1994-01-18 | Kamahira Safe Co., Inc. | Biometric token for authorizing access to a host system |
| US5613012A (en) * | 1994-11-28 | 1997-03-18 | Smarttouch, Llc. | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
| US5615268A (en) * | 1995-01-17 | 1997-03-25 | Document Authentication Systems, Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
| US5826245A (en) * | 1995-03-20 | 1998-10-20 | Sandberg-Diment; Erik | Providing verification information for a transaction |
| US5590197A (en) * | 1995-04-04 | 1996-12-31 | V-One Corporation | Electronic payment system and method |
| US5774552A (en) * | 1995-12-13 | 1998-06-30 | Ncr Corporation | Method and apparatus for retrieving X.509 certificates from an X.500 directory |
| JP3133243B2 (en) * | 1995-12-15 | 2001-02-05 | 株式会社エヌケーインベストメント | Online shopping system |
| US5602918A (en) * | 1995-12-22 | 1997-02-11 | Virtual Open Network Environment Corp. | Application level security system and method |
| US5987140A (en) * | 1996-04-26 | 1999-11-16 | Verifone, Inc. | System, method and article of manufacture for secure network electronic payment and credit collection |
| US5978840A (en) * | 1996-09-26 | 1999-11-02 | Verifone, Inc. | System, method and article of manufacture for a payment gateway system architecture for processing encrypted payment transactions utilizing a multichannel, extensible, flexible architecture |
-
1998
- 1998-06-10 GB GB9812520A patent/GB2338381A/en not_active Withdrawn
- 1998-09-23 JP JP2000553924A patent/JP2002517869A/en active Pending
- 1998-09-23 WO PCT/GB1998/002868 patent/WO1999064995A1/en active Application Filing
- 1998-09-23 AU AU91757/98A patent/AU9175798A/en not_active Abandoned
- 1998-09-23 CN CN98808020.6A patent/CN1266520A/en active Pending
- 1998-09-23 CA CA002299294A patent/CA2299294A1/en not_active Abandoned
- 1998-09-23 DE DE29824106U patent/DE29824106U1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| AU9175798A (en) | 1999-12-30 |
| JP2002517869A (en) | 2002-06-18 |
| GB2338381A (en) | 1999-12-15 |
| CN1266520A (en) | 2000-09-13 |
| WO1999064995A1 (en) | 1999-12-16 |
| GB9812520D0 (en) | 1998-08-05 |
| DE29824106U1 (en) | 2000-07-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2299294A1 (en) | Secure transaction system | |
| US6026166A (en) | Digitally certifying a user identity and a computer system in combination | |
| US6490367B1 (en) | Arrangement and method for a system for administering certificates | |
| US6367013B1 (en) | System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents | |
| US6247129B1 (en) | Secure electronic commerce employing integrated circuit cards | |
| US7627895B2 (en) | Trust tokens | |
| US7552333B2 (en) | Trusted authentication digital signature (tads) system | |
| US6915430B2 (en) | Reliably identifying information of device generating digital signatures | |
| US20030101348A1 (en) | Method and system for determining confidence in a digital transaction | |
| WO1998040982A9 (en) | Secure electronic commerce employing integrated circuit cards | |
| CN111275419B (en) | Block chain wallet signature right confirming method, device and system | |
| WO2000069113A1 (en) | Secure distribution and protection of encryption key information | |
| EP1886204B1 (en) | Transaction method and verification method | |
| US20030221109A1 (en) | Method of and apparatus for digital signatures | |
| US20050086175A1 (en) | Method for storage and transport of an electronic certificate | |
| KR20100006004A (en) | Autentification processing method and system using card, card terminal for authentification processing using card | |
| JP2002519782A (en) | Apparatus and method for end-to-end authentication using biometric data | |
| EP1221145A1 (en) | Method and system for performing a transaction between a client and a server over a network | |
| KR100643501B1 (en) | Key delivery method and the system for IC card issuing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |