WO1999064995A1 - Systeme de transaction sur - Google Patents

Systeme de transaction sur Download PDF

Info

Publication number
WO1999064995A1
WO1999064995A1 PCT/GB1998/002868 GB9802868W WO9964995A1 WO 1999064995 A1 WO1999064995 A1 WO 1999064995A1 GB 9802868 W GB9802868 W GB 9802868W WO 9964995 A1 WO9964995 A1 WO 9964995A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
transaction
data
authorisation
terminal
Prior art date
Application number
PCT/GB1998/002868
Other languages
English (en)
Inventor
David Alexander Taylor
Mark Jonathan Stirland
Original Assignee
Barclays Bank Plc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Barclays Bank Plc filed Critical Barclays Bank Plc
Priority to JP2000553924A priority Critical patent/JP2002517869A/ja
Priority to CA002299294A priority patent/CA2299294A1/fr
Priority to DE29824106U priority patent/DE29824106U1/de
Priority to AU91757/98A priority patent/AU9175798A/en
Publication of WO1999064995A1 publication Critical patent/WO1999064995A1/fr

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

Definitions

  • the present invention relates to a secure transaction system, particularly for use over a public network.
  • 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.
  • internet 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 Hypertext Transfer Protocol (SHTTP).
  • SSL Secure Sockets Layer
  • SHTTP Secure Hypertext Transfer Protocol
  • Such transactions involve three parties: a client which supplies credit card details, a service provider server 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.
  • 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 terminal/transaction information which is sent to the transaction server.
  • the transaction server sends the transaction data to an authorisation server which returns information which binds the transaction to the identity of the authorisation server.
  • 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.
  • 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 confirmed during the transaction.
  • 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 server, 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.
  • Figure 1 is a diagram of the service functions of an authorisation system in an embodiment of the present invention
  • Figure 2 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 server 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
  • FIG 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 1 1 shows the transmission of an authorisation request message to the authorisation server
  • Figure 12 shows the authorisation process performed by the authorisation server
  • Figure 13 shows the authorisation response message process from the authorisation server to the electronic form server.
  • FIG. 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 digital 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 signing party.
  • the signing party is provided with a private/public key pair, which can be used to generate and verify digital signatures.
  • the ⁇ party' is usually assumed to be the user operating the computer which stores the private key and generates the digital signature.
  • the private key is stored on a smart card and therefore the digital signature binds the signed data to the smart card.
  • the 'party ' is the smart card.
  • 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 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 Diff ⁇ e- Helman algorithm.
  • the digital signature generator 10 exchanges information IE with a digital signature acceptor 20. and sends 'signed' information SI to the digital signature acceptor 20 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 10.
  • the digital signature acceptor 20 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 signature is to be accepted as genuine.
  • the authorisation response ARES is signed with a digital signature generated by a private key held by the digital signature authoriser 30.
  • the digital signature acceptor 20 accepts or rejects the signed information SI.
  • the digital signature acceptor 20 may further transmit a notarisation request NREQ to a signed message notariser 40, including information derived from the signed information SI and from the authorisation response ARES.
  • the signed message notariser 40 transmits to the digital signature acceptor 20 a notarisation confirmation NCF which includes information derived from the notarisation request
  • the digital signature acceptor 20 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 50. 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.
  • archive deposit information ARDEP which may for example comprise the signed information SI, the authorisation response ARES and the notarisation confirmation NCF.
  • FIG. 1 A high-level system architecture of the digital signature authorisation service is shown in Figure 2. Like parts to those of Figure 1 carry the same reference numerals.
  • a 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 12 has a computer 14 connectable to the Internet 100 via a modem 16. using 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 140 connected to a hard disc 145
  • a user interface controller 150 connected to a keyboard 152 and other input devices such as a mouse 154
  • a display controller 160 connected to a visual display 165.
  • an I/O controller 170 controls the modem 16 and a card reader 174 into which a smart card can be docked.
  • a biometric device 180 is connected to the I/O controller 170 or to the user interface controller 150.
  • the biometric device 180 may be a fingerprint 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 keyboard 152.
  • 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 12.
  • An example of the components within the smart card 18 is shown in Figure 4.
  • the smart card 18 contains a processor 200 connected to a memory 210 and an external connector 220.
  • the card 18 may include a power source such as a cell integrated 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 being physically examined to determine its content.
  • the user 12 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 30. the message identifying the card 18 and the user 12. The user 12 is also issued with the card reader 174 and application software for the digital signature service, if the user 12 does not already have these.
  • a PIN is recorded in the card 18 either before being 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 notified of the PIN after the identity verification has taken place.
  • the user 12 inserts the card 18 into the card reader 174.
  • Application software running on the computer 14 then prompts the user 12 for a PIN.
  • 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 whether the entered PIN matched that stored on the card 18.
  • VR card validation result
  • 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 service provider 20.
  • the service provider 20 may comprise a general purpose computer running web server software and connected to the Internet 100.
  • the service provider 20 also runs authorisation software for communication with the authorisation server 30.
  • the authorisation server 30 comprises a general purpose computer running authorisation server software and connected to the Internet 100. As shown in Figures 2 and 5. the authorisation server 30 is also connected, for example over a local or private network, to a public key server 32. a card authentication server 34 and a customer verification server 36.
  • the public key server 32 and the card authentication server 34 comprise dedicated hardware modules including encryption /decryption acceleration hardware.
  • the customer verification server 36 stores a database containing the details of authorised users of the digital signature service.
  • the authorisation server 30 receives from the service provider 20 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 server 36, 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 authorisation message AM. which is sent to the public key server 32.
  • the public key server 32 signs the authorisation message AM to produce a signed authorisation response ARES which is transmitted to the service provider 20.
  • 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.
  • a public key certificate consists of a name identifying a party who holds a private key (in this case, the card 18), 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.
  • a hierarchy of public key certificates may be used, ultimately administered by a root certification authority which is always trusted. If a public/private key pair is changed, 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 against the CRL.
  • FIG. 6 shows the hierarchy of keys in the present embodiment.
  • the smartcard 18 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 within the card and signed using a card certification private key CCK of a card certification authority 110.
  • 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 120.
  • the root certification authority private key RCK is also used to sign the public key certificate ASC of the authorisation server 30.
  • the corresponding public key is distributed in a root certification authority public key certificate RCC. which is self-signed using the corresponding private key RCK.
  • the authorisation server private key ASK is used to provide a digital signature on the authorisation response ARES.
  • the smart card 18 also performs a symmetric key card authentication function with the authentication server 30. using a separate private key stored on the card 18.
  • the process uses a two-key triple data encryption standard (DES. encrypt-decrypt-encrypt) algorithm in Cipher Block Chaining Mode to produce an eight byte message authentication code (MAC).
  • DES encrypt-decrypt-encrypt
  • MAC eight byte message authentication code
  • the symmetric key authentication function is used for secure communications between the smartcard 18 and the authentication server 30, which the service provider 20 passes transparently but is unable to decrypt.
  • the MAC is calculated from a combination of: data stored internally in the card 18.
  • variable application transaction counter value ATC which is incremented for each 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 signed 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.
  • Figures 7 to 13 show the topological connection between the computer 14 and the service provider 20. and between the service provider 20 and the authorisation server 30. as being through separate networks 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 service provider 20. and is running web browser software.
  • the service provider 20 sends data D comprising HTML pages representing a blank form (such as a form for registering a new business).
  • the user 12 completes the form by entering data within the browser software and requesting submission of the completed form to the service provider 20.
  • the browser software supports the digital signature service, 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 12 to do this.
  • the smartcard 18 At a data processing stage DP. the smartcard 18 generates 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 20. 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 function for the form data and comparing the recalculated hash function with the one signed 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 20 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 20 and passed to the authentication server 30.
  • the user identification data ID comprises for example the name, address and date of birth of the user, entered by the user 12 and transmitted by the browser software in a separate field from the signed data SD.
  • biometric data from the biometric device 180 is included in the user identification information.
  • 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 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 ASK and sent as the authorisation response ARES to the service provider 20.
  • Figure 9 shows how the data sent from the user ' s computer 14 to the service provider 20 is generated.
  • the data D sent from the service provider 20 includes two random or otherwise unpredictable 32-bit numbers UNI and UN2. the date and time of the transaction and a server 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. together with the second unpredictable number UN2. validation result VR, the date and time and the server 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 key 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 20.
  • the process performed by the service provider 20 to validate the signature of the signed data SD is shown in Figure 10.
  • the service provider 20 receives the form data F and checks (S10) that the serial number UNI 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 (S20) the signature data SD to extract the hash calculated by the user ' s computer 14.
  • the two hashes are compared (S30) and the signature is validated if they match.
  • this process only establishes that the form was digitally signed using the card 18.
  • the service provider 20 must further check that the card 18 is valid and is being used by the authorised cardholder, as will be described below.
  • the service provider 20 sends the following information to the authorisation server 30 in the authorisation request message ARES, as illustrated in Figure 1 1 : the user identification data ID. including any biometric data, the second unpredictable number UN2. 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 in Table 1 below:
  • the Card Data described in Table 1 comprises the fields shown below in Table 2: Table 2 - Card Data Structure
  • the authorisation server 30 determines the authorisation response ARES as illustrated in Figure 12.
  • 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 server 34 where the MAC is verified using the card number N, extracted from the card public key certificate, the second unpredictable number UN2 and the date, time and server identity originally provided by the service provider 20.
  • 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.
  • 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 identity information ID matches the stored profile for that user.
  • 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.
  • 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 32 which generates a digital signature for the message using the authorisation server private key ASK and returns this signature AS together with the authorisation server public key 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 which the authorisation is made to the service provider 20.
  • the Authorisation Response Data is coded as individual bits, as shown in Table 4: Table 4 - Authorisation Response Data Bit Meaning
  • 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.
  • 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 server, 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.
  • the service 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 service provider 20.
  • the service provider 20 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.
  • the authorisation response ARES is used to determine the liability between the operator of the service provider 20 and the operator of the authorisation server 30. For example, if any of the bits with index 0 are set. the authorisation server 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 server operator will accept liability only to a prearranged limit, and if none of the bits is set. the authorisation server operator will accept liability to the maximum value prearranged for the user 12.
  • 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 20 to the authorisation server 30.
  • the present invention is not limited to any specific type of transaction such as the authentication of forms or the authorisation of payment.
  • the smart card 18 may sign the form data using the symmetric encryption key under the DES process and may dispense with the RSA encryption process.
  • the service provider 20 will not then be able to verify the signature, but instead recalculates the hash and transmits this to the authorisation server 30 for verification.
  • the smart card 18 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.
  • the service provider 20 checks the card application data CAD 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.
  • the service provider 20 is unable to check whether card specific data such as the application transaction counter ATC and the card number N 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 validity of the card 18.
  • the user identification data ID is still sent to the authorization server 30 for comparison with the cardholder details accessible by the authorization server.

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

Dans un système destiné à l'authentification de transactions sur un réseau public (100), un terminal (14) envoie des données de transaction (SD) à signature numérique à un fournisseur (20) de services sur le réseau public (100), ainsi que des données (CAD) d'application de carte produites par une carte à puce (18). Les données (CAD) d'application de carte sont envoyées à un serveur d'autorisation (30) qui vérifie que la carte à puce (18) est valable et que les données (CAD) d'application de carte ont été impérativement produites par la carte à puce (18) dans la transaction en cours. Des informations d'identification (ID) d'utilisateur sont également envoyées du terminal (14) au fournisseur (20) de services et par conséquent au serveur d'autorisation (30) où ces informations sont vérifiées par comparaison aux détails corrects concernant l'utilisateur associés à la carte à puce (18). Les résultats de ces vérifications sont indiqués dans une réponse d'autorisation (ARES) à signature numérique envoyée par le serveur d'autorisation (30) au fournisseur (20) de services qui détermine ensuite la poursuite ou non de la transaction en établissant des critères d'acceptation pour la transaction en cours et en déterminant à partir de la réponse d'autorisation (ARES) si ces critères sont satisfaits.
PCT/GB1998/002868 1998-06-10 1998-09-23 Systeme de transaction sur WO1999064995A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2000553924A JP2002517869A (ja) 1998-06-10 1998-09-23 安全トランザクションシステム
CA002299294A CA2299294A1 (fr) 1998-06-10 1998-09-23 Systeme de transaction sur
DE29824106U DE29824106U1 (de) 1998-06-10 1998-09-23 Sicheres Transaktionssystem
AU91757/98A AU9175798A (en) 1998-06-10 1998-09-23 Secure transaction system

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO1999064995A1 true WO1999064995A1 (fr) 1999-12-16

Family

ID=10833527

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1998/002868 WO1999064995A1 (fr) 1998-06-10 1998-09-23 Systeme de transaction sur

Country Status (7)

Country Link
JP (1) JP2002517869A (fr)
CN (1) CN1266520A (fr)
AU (1) AU9175798A (fr)
CA (1) CA2299294A1 (fr)
DE (1) DE29824106U1 (fr)
GB (1) GB2338381A (fr)
WO (1) WO1999064995A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001055979A1 (fr) * 2000-01-24 2001-08-02 Smarttrust Systems Oy Dispositif de paiement et procede de paiement securise
WO2001082148A1 (fr) * 2000-04-27 2001-11-01 Deutsche Post Ag Procede permettant a un client d'appeler une information sur une valeur monetaire a partir d'un point de chargement
DE10057536A1 (de) * 2000-10-20 2002-04-25 Klaus Roth Vorrichtung und Verfahren zum Vertrieb von Daten zur Wiedergabe in Schrift, Ton und/oder Bild
EP1326368A2 (fr) * 2001-12-19 2003-07-09 Trw Inc. Revocation et mise a jour du jetons dans une infrastructure à clé publique
JP2003536181A (ja) * 2000-06-22 2003-12-02 マスターカード インターナシヨナル インコーポレーテツド 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム
EP2278538A1 (fr) * 2000-04-24 2011-01-26 Visa International Service Association Service d'authentification d'un payeur en ligne
CN104156681A (zh) * 2014-07-28 2014-11-19 上海辰锐信息科技公司 身份识别系统
CN104517086A (zh) * 2014-12-31 2015-04-15 山东信通电子股份有限公司 身份证信息读取方法
CN104700057A (zh) * 2015-04-02 2015-06-10 山东信通电子股份有限公司 可共享资源式居民身份证阅读实现方法及身份证阅读器
CN104899533A (zh) * 2015-05-20 2015-09-09 李明 身份证信息获取方法、装置及系统
CN104966035A (zh) * 2015-05-20 2015-10-07 李明 身份证信息获取方法、装置及系统
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
US20190172064A1 (en) * 2016-07-01 2019-06-06 American Express Travel Related Services Company, Inc. Systems and methods for validating transmissions over communication channels

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AUPQ556600A0 (en) 2000-02-14 2000-03-02 Ong, Yong Kin (Michael) Electronic funds transfers-zipfund
AU2005203599B2 (en) * 2000-02-14 2007-03-08 Yong Kin Ong (Michael) Electronic funds transfer
US8322606B2 (en) 2000-02-16 2012-12-04 Ong Yong Kin Michael Electronic credit card—ECC
AUPQ564400A0 (en) 2000-02-16 2000-03-09 Ong, Yong Kin (Michael) Electronic credit card-ecc
NL1015564C2 (nl) * 2000-05-30 2001-12-03 Beleggings En Exploitatie Mij Werkwijze en inrichting voor het uitvoeren van (trans)acties.
EP1193658A1 (fr) * 2000-09-29 2002-04-03 Siemens Aktiengesellschaft Procédé et dispositif pour la transmission d'une somme d'argent électronique depuis une mémoire de crédit
FR2835636A1 (fr) * 2002-02-07 2003-08-08 Carmel Giacopino Systeme permettant d'effectuer des echanges d'information et des transactions
JP2006522507A (ja) 2003-04-01 2006-09-28 エントロピック・テクノロジーズ・プロプライエタリー・リミテッド セキュア通信システム及びセキュア通信方法
AU2004225193B2 (en) * 2003-04-01 2009-07-30 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 (fr) 2003-06-13 2004-12-23 Orbid Limited Procede et systeme permettant d'effectuer une transaction et une verification portant sur l'utilisation legitime de donnees numeriques
CN100388726C (zh) * 2003-11-14 2008-05-14 国际商业机器公司 延迟传递电子邮件的系统和方法
CN100388298C (zh) * 2005-01-21 2008-05-14 高晶 共享sam_v实现二代身份证联网阅读的系统及方法
WO2006121322A1 (fr) * 2005-05-10 2006-11-16 Dts Ltd. Procede de transaction et procede de verification
JP4857657B2 (ja) * 2005-08-23 2012-01-18 大日本印刷株式会社 アクセス管理システム、および、アクセス管理方法
KR20070050712A (ko) * 2005-11-11 2007-05-16 엘지전자 주식회사 Srm의 디지털 저작권 관리 방법 및 장치
US7877784B2 (en) * 2007-06-07 2011-01-25 Alcatel Lucent Verifying authenticity of webpages
CN102236770B (zh) * 2010-04-20 2015-05-20 公安部第一研究所 一种机读旅行证件访问控制方法
WO2014205461A2 (fr) * 2013-05-24 2014-12-24 Paima Prashant Govind Processus d'authentification d'une identité d'un utilisateur
TW201712591A (zh) * 2015-09-30 2017-04-01 Chunghwa Telecom Co Ltd 用於智慧卡之資料授權管理驗證方法
CN113221797B (zh) * 2021-05-24 2024-01-19 厦门科路德科技有限公司 一种印刷文件的防伪识别方法、装置以及设备

Citations (7)

* Cited by examiner, † Cited by third party
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
WO1996029667A1 (fr) * 1995-03-20 1996-09-26 Sandberg Diment Erik Fourniture d'informations de verification relative a une transaction
US5613012A (en) * 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
EP0779587A2 (fr) * 1995-12-15 1997-06-18 Kabushiki Kaisha N.K Kikaku Système d'achat on-line et méthode pour le règlement de la facture
WO1997041539A1 (fr) 1996-04-26 1997-11-06 Verifone, Inc. Systeme et procede de paiement electronique et de recouvrement de credit proteges sur reseau
WO1998013797A2 (fr) * 1996-09-26 1998-04-02 Verifone, Inc. Systeme, procede et article manufacture pour une architecture de systeme de paiement interreseau dans lesquels on utilise une architecture multivoie, extensible et flexible

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615268A (en) * 1995-01-17 1997-03-25 Document Authentication Systems, Inc. System and method for electronic transmission storage and retrieval of authenticated documents
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
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method

Patent Citations (7)

* Cited by examiner, † Cited by third party
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
WO1996029667A1 (fr) * 1995-03-20 1996-09-26 Sandberg Diment Erik Fourniture d'informations de verification relative a une transaction
EP0779587A2 (fr) * 1995-12-15 1997-06-18 Kabushiki Kaisha N.K Kikaku Système d'achat on-line et méthode pour le règlement de la facture
WO1997041539A1 (fr) 1996-04-26 1997-11-06 Verifone, Inc. Systeme et procede de paiement electronique et de recouvrement de credit proteges sur reseau
WO1998013797A2 (fr) * 1996-09-26 1998-04-02 Verifone, Inc. Systeme, procede et article manufacture pour une architecture de systeme de paiement interreseau dans lesquels on utilise une architecture multivoie, extensible et flexible

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001055979A1 (fr) * 2000-01-24 2001-08-02 Smarttrust Systems Oy Dispositif de paiement et procede de paiement securise
EP2278538A1 (fr) * 2000-04-24 2011-01-26 Visa International Service Association Service d'authentification d'un payeur en ligne
WO2001082148A1 (fr) * 2000-04-27 2001-11-01 Deutsche Post Ag Procede permettant a un client d'appeler une information sur une valeur monetaire a partir d'un point de chargement
JP2003536181A (ja) * 2000-06-22 2003-12-02 マスターカード インターナシヨナル インコーポレーテツド 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム
JP4903346B2 (ja) * 2000-06-22 2012-03-28 マスターカード インターナシヨナル インコーポレーテツド 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム
DE10057536A1 (de) * 2000-10-20 2002-04-25 Klaus Roth Vorrichtung und Verfahren zum Vertrieb von Daten zur Wiedergabe in Schrift, Ton und/oder Bild
EP1326368A2 (fr) * 2001-12-19 2003-07-09 Trw Inc. Revocation et mise a jour du jetons dans une infrastructure à clé publique
EP1326368A3 (fr) * 2001-12-19 2003-12-03 Northrop Grumman Corporation Revocation et mise a jour du jetons dans une infrastructure à clé publique
CN104156681A (zh) * 2014-07-28 2014-11-19 上海辰锐信息科技公司 身份识别系统
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
CN104517086A (zh) * 2014-12-31 2015-04-15 山东信通电子股份有限公司 身份证信息读取方法
CN104700057A (zh) * 2015-04-02 2015-06-10 山东信通电子股份有限公司 可共享资源式居民身份证阅读实现方法及身份证阅读器
CN104899533A (zh) * 2015-05-20 2015-09-09 李明 身份证信息获取方法、装置及系统
CN104966035A (zh) * 2015-05-20 2015-10-07 李明 身份证信息获取方法、装置及系统
CN104966035B (zh) * 2015-05-20 2018-09-25 李明 身份证信息获取方法、装置及系统
US20190172064A1 (en) * 2016-07-01 2019-06-06 American Express Travel Related Services Company, Inc. Systems and methods for validating transmissions over communication channels
US11151561B2 (en) * 2016-07-01 2021-10-19 American Express Travel Related Services Company, Inc. Systems and methods for validating transmissions over communication channels

Also Published As

Publication number Publication date
AU9175798A (en) 1999-12-30
GB2338381A (en) 1999-12-15
GB9812520D0 (en) 1998-08-05
CN1266520A (zh) 2000-09-13
DE29824106U1 (de) 2000-07-13
CA2299294A1 (fr) 1999-12-16
JP2002517869A (ja) 2002-06-18

Similar Documents

Publication Publication Date Title
WO1999064995A1 (fr) Systeme de transaction sur
US6026166A (en) Digitally certifying a user identity and a computer system in combination
US6367013B1 (en) System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents
US6959381B2 (en) Central key authority (CKA) database for user accounts in ABDS system
US6983368B2 (en) Linking public key of device to information during manufacture
US7552333B2 (en) Trusted authentication digital signature (tads) system
US6247129B1 (en) Secure electronic commerce employing integrated circuit cards
US20030101348A1 (en) Method and system for determining confidence in a digital transaction
US20020165830A1 (en) Process and device for electronic payment
US20040260928A1 (en) Wim manufacturer certificate
WO1998040982A9 (fr) Commerce electronique de securite faisant appel a des cartes a circuit integre
EP1198922A1 (fr) Distribution et protection securisees des informations d'une cle de cryptage
US20030221109A1 (en) Method of and apparatus for digital signatures
KR20040078693A (ko) 전자 인증서의 저장 및 이용 방법
KR20100006004A (ko) 카드를 이용한 인증 처리 방법 및 시스템, 카드를 이용한인증 처리를 위한 카드 단말기
CN1379893A (zh) 证书的分配
JP2002519782A (ja) 生物測定データを用いたエンドツーエンド認証の装置と方法
EP1267516B1 (fr) Procédé de sécurisation de données se rapportant à des utilisateurs d'une infrastructure à clé publique

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 98808020.6

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 91757/98

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2299294

Country of ref document: CA

Ref document number: 2299294

Country of ref document: CA

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 09485666

Country of ref document: US

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase