US9270450B2 - Method and device for mutual authentication - Google Patents

Method and device for mutual authentication Download PDF

Info

Publication number
US9270450B2
US9270450B2 US12/520,475 US52047507A US9270450B2 US 9270450 B2 US9270450 B2 US 9270450B2 US 52047507 A US52047507 A US 52047507A US 9270450 B2 US9270450 B2 US 9270450B2
Authority
US
United States
Prior art keywords
merchant
customer
communications
information
digest
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.)
Active, expires
Application number
US12/520,475
Other languages
English (en)
Other versions
US20100115277A1 (en
Inventor
Andrew William Roscoe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oxford University Innovation Ltd
Original Assignee
Oxford University Innovation Ltd
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 Oxford University Innovation Ltd filed Critical Oxford University Innovation Ltd
Assigned to ISIS INNOVATION LIMITED reassignment ISIS INNOVATION LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROSCOE, ANDREW WILLIAM
Publication of US20100115277A1 publication Critical patent/US20100115277A1/en
Application granted granted Critical
Publication of US9270450B2 publication Critical patent/US9270450B2/en
Assigned to OXFORD UNIVERSITY INNOVATION LIMITED reassignment OXFORD UNIVERSITY INNOVATION LIMITED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: ISIS INNOVATION LIMITED
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the invention relates to improvements in communication security and in particular to improvements in communication over computer-based networks to enable greater security and customer confidence in performing financial transactions over such networks.
  • Chip and PIN technology enables an extra level of authentication technology to be applied to verify that the customer and card are valid in “customer present” transactions. It is limited in such circumstances by the need for the customer to have complete trust in the merchant not to use the data it receives improperly, and limited in other means of transaction, for example internet, by the need for there to exist an authenticated secret channel between the card and the merchant. Specifically the customer needs to know that he or she is paying the desired merchant the agreed amount in the intended transaction. While this is obvious in the majority of “customer present” transactions, it is much, more problematic remotely when the communications mediums and equipment used for communication cannot be considered secure.
  • a method of authenticating communication between a first and second party (or node) over an insecure, high bandwidth communications network in which the first party (C) authenticates the second party (M) using a communications protocol comprising a first communications phase through a first communications channel over the insecure, high bandwidth communications network to establish a secure mode of communications between the first and second party, followed by a second communications phase of receiving information from the second party over a second communications channel, such as an empirical channel, and enabling a user to make a human comparison of the information received from the second party with information generated by the first party thereby enabling the user to authenticate the second party in the event of the information from both parties agrees.
  • a communications protocol comprising a first communications phase through a first communications channel over the insecure, high bandwidth communications network to establish a secure mode of communications between the first and second party, followed by a second communications phase of receiving information from the second party over a second communications channel, such as an empirical channel, and enabling a user to make a human comparison of the information received from the second party
  • an aspect of the invention provides a method of authenticating communication by a first node with a second node over an insecure communications network, comprising;
  • an agreement stage comprising agreeing a hash function and communications protocol
  • a first message stage comprising sending a first message from the second node to the first node comprising a longhash element
  • a second communication stage comprising the second node communicating to the first node a first argument operated on by the agreed hash function to provide a longhash element
  • a third message stage comprising sending a second message from the first node to the second node enabling the second node to determine the data committed by the longhash element it received,
  • a fourth message stage comprising sending a second message from the second node to the first node enabling the first node to determine the data committed by the longhash element it received,
  • a digest stage wherein the first and second node generate a digest using at least the two pieces of committed data thereby to enable the user of the first node to authenticate the second node by human comparison of both the digests.
  • Another aspect provides a method of authenticating communication by a first node with a second node over an insecure communications network, comprising; an agreement stage comprising agreeing a hash function and communications protocol; a first message stage comprising sending a first message from the second node to the first node comprising a first longhash element, the first node sending a second message comprising a second longhash element; a second communication stage comprising the second node communicating to the first node a first argument operated on by the agreed hash function to provide the first longhash element, and the first node communicating to the second node a second argument operated on by the agreed hash function to provide the second longhash element; a digest stage wherein the first and second node generate a digest using at least the first and second argument thereby to enable the user of the first node to authenticate the second node by human comparison of both the digests.
  • a security device for enabling authentication of a merchant to a customer over an insecure communications network
  • the security device comprising a processor adapted to perform encrypted communication of data via a data transfer interface to the communications network, and a user interface enabling user input of data and output of data to a user, the security device further being adapted to enable communication of secure information, such as financial data, to a third party, such as a bank, via the data transfer interface over the insecure communications network after the user has authenticated the identity of the merchant using the security device.
  • the security device hereinafter often abbreviated SD, can be a relatively inexpensive electronic device with the following properties:
  • the customer can be confident there is no man-in-the-middle who can steal his or her card details or PIN.
  • FIG. 1 is a schematic view of a communications network comprising a user, or customer, a merchant and a bank;
  • FIG. 2 is a schematic block diagram of a first embodiment of a security device according to the invention.
  • FIG. 3 is a schematic diagram of the communications involved in a run of the SHCBK-SP protocol.
  • FIG. 4 is a schematic block diagram of components of a hardware form of the invention for implementing a digest function based on a Toeplitz model.
  • a communications system 10 comprising a communications network 12 such as the internet, which enables communication between a bank 14 , a merchant 16 and a customer C using customer unit 18 via network interfaces 13 , 17 and 19 respectively.
  • a communications network 12 such as the internet
  • Each of the bank 14 , merchant 16 and customer unit 18 might take the form of computer based units, including mobile phones, personal computers and/or more sophisticated computer systems such as, web servers and/or in the case of merchant 16 , an interactive website hosted by an appropriate web server.
  • the merchant 16 and bank 14 choose to communicate via the network 10 or a separate mechanism 15 , it is assumed that such communication is secured. In many cases this security will be provided by conventional means such as protocols built on top of a PKI:
  • the network 12 is the Internet and merchant 16 provides an interactive trading site on the Internet enabling users to purchase goods and services.
  • the customer unit 18 can be a standard personal computer forming a web client through which a user, or customer, is able to access the website of merchant 16 and to view the available goods and services using a standard Internet browser application.
  • customer unit 18 in FIG. 1 represents a device provided by a merchant at a retail outlet such as a petrol station or shop, in which case the interface 19 between customer unit 18 and network 12 might be secure as might also be network 12 itself for example being provided by a secure and dedicated communications network.
  • a customer security device 20 is provided which interfaces via communications interface 21 with customer unit 18 .
  • connection between the SD 20 and the Merchant 21 may be simplified to a single link. This will frequently occur in “customer present” transactions where the SD makes a direct link with hardware provided by the merchant rather than via the customer unit 18 and network 12 . In any case, whether these intermediaries are present or not, the overall objective will be to enable secure and authenticated communications between security device ( 20 ) and merchant ( 16 ) without relying on security of either the intervening communications links or intermediaries.
  • Interface 21 might comprise a wireless or wired connection.
  • the customer security device might be a portable handheld device comprising a radio frequency, microwave and/or infra-red receiver and transmitter for interfacing with customer unit 18 .
  • the customer security device 20 might also be connectable using a wired connection such as a USB connection. Further variations in the form of system 10 will be discussed later.
  • a customer security device 20 comprising a data transfer interface comprising input/output ports 22 enabling communication via interface 21 with other devices such as customer unit 18 .
  • Security device 20 further comprises a user interface enabling a user to input and receive information from the security device for example by manual data entry and visual/acoustic output.
  • a display 24 is provided such as an LCD display capable of displaying alphanumeric information and security device 20 further comprises user inputs 26 comprising a range of keys in the form of a confirm button 28 , an abort button 29 , and an array of 12 keys for example enabling input of alphanumeric information akin to the keys on a mobile phone keypad.
  • Further input keys 32 are provided to enable user interaction for example in response to information displayed via display unit 24 .
  • Other user inputs include biometric data readers such as a thumb-print reader. This could be treated in the protocol logics below like a PIN.
  • the security device further comprises a card interface enabling the security device 20 to interchange information with the chip on a credit card 36 by insertion of card 36 into the card reader 34 .
  • the security device 20 may contain an input device 40 for inputting information which might be requested for example shown on display screen 24 , such as barcode data or similar hence the data might be entered via an optical character reader or barcode scanner.
  • the input device 40 might be in the form of a wand or other device removable from security device 20 but connectable thereto e.g. via appropriate wiring to enable a user to scan a barcode, alphanumeric characters and/or other image or biometric data, remotely from the security device. This may well be appropriate when the security device 20 takes the form of a desktop device rather than a portable device.
  • the security device 20 may further comprise a printer 38 to enable marking on a substrate such as a piece of paper.
  • Printer 38 might for example be a dot matrix printer enabling printing e.g. of a barcode onto paper fed through the printer 38 for use in postal transactions as detailed below. It is expected that such data is tested by card/SD by reference to identity information held on the card, the success of which is a precondition to the card performing its role in the protocols below.”
  • the normal type of transaction is a customer attempting to pay a merchant, though there may be variants on this such as “blocking” transactions and giving the merchant the right to claim payment up to a certain limit.
  • the essential requirements for such transactions are
  • the merchant is assured that the card is genuine and that all correct identification information required for a transaction such as a PIN have been entered for this transaction. In many cases the merchant will also need clearance from the banking system for the transaction. 2.
  • the customer is assured that he or she is paying the amount of money desired to the intended merchant. In particular, he or she needs to be assured that the information given cannot be abused by a third party who may be listening or who may be interfering with the interaction. 3. It is highly desirable also that the customer's information cannot be abused, intentionally or otherwise (e.g. in a security leak or via a corrupt employee), by the merchant.
  • the authentication problem for the merchant is relatively simple, provided the card system's general security is adequate.
  • the merchant should have separate secure communication with the banking system (via interface 15 or interfaces 17 and 13 via network 12 for example).
  • the banking system via interface 15 or interfaces 17 and 13 via network 12 for example.
  • it is natural to identify a card by its electronic name and that, if the card contained a certificated public key, the merchant is in a good position to check the validity of said key. In other words, if we desire, it is practical to implement a PKI of cards.
  • the authentication problem for the customer is harder. Firstly the customer will not naturally want to identify a merchant by a usable electronic name, and even if this were done it would not be adequate, since customer C needs to know that no intruder can pay the bill of another customer to the same merchant using C's card. In fact, C needs to know that his or her card is paying the amount required for and within the particular transaction intended.
  • HCBK Hash Commitment Before Knowledge.
  • the parties share a high-bandwidth low-security communications medium which allows a potential attacker the vulnerabilities of the standard Dolev-Yao model, plus the ability to carry out combinatorial attacks such as the “birthday attack” on cryptographic values, provided these are computationally feasible.
  • the protocols are designed to allow humans to compare short values without being vulnerable to combinatorial attacks such as the birthday attack that would normally apply to similarly-sized data.
  • the likelihood of any attack by any current computer the probability of a successful attack succeeding will be 2 ⁇ k and any unsuccessful attack with a more than negligible chance of succeeding can be discovered.
  • the protocols allow secure communications to be obtained between devices that encounter each other in a wide range of circumstances, based on nothing further than an insecure means of communication, a mutual understanding of a protocol, and one or two human users making comparisons.
  • the asymmetric versions are identical: except that one participant, in our present invention always the merchant 16 , does not have, the means to satisfy itself that the two digests are equal in the final step.
  • the symmetric versions of the protocols mutually authenticate the merchant's and customer's electronic identities as belonging to the two parties agreeing the digests; and a secret shared session key is established that each knows is with the other party.
  • the asymmetric version authenticates the merchant's electronic identity to the customer, who also knows that the resulting key is a secret shared with the merchant: that is the important direction for reasons discussed earlier.
  • C is the customer's security device 20 and M is the merchant 16 .
  • M is the merchant 16 .
  • the following is its symmetric version and is shown schematically in FIG. 3 .
  • pkM is a public key for M. If the card/SD has sufficient power it can be a strong and possibly certificated public key. If they do not have this power it can be a weak public key generated freshly for this session. It must then be strong enough to resist attack during the period of the transaction, say about 2 minutes and preferably up to about 5 minutes.
  • hkM and hkC are random values
  • longhash( ) is a cryptographic hash function, all of sufficient length that means that it is infeasible for someone knowing the cryptographic hashes longhash(hkM,M) and longhash(hkC,C) to compute any useful approximations to hkM or hkC, and so that it is infeasible to use attacks such as the birthday attack to substitute values in messages 1 to 4 and so that hkM XOR hkC has a sufficient degree of cryptographic entropy so that it can key the cryptographic digest used in messages 5a and 5b.
  • digest(hk,m) is a proposed session key (for an appropriate form of symmetric-key cryptography) chosen randomly by C that e used for secure communication between C and M subsequent to successful completion of the protocol.
  • the length b of the digests is chosen so that a probability of an attack succeeding of 2 ⁇ b is acceptable.
  • Step 5b enables a customer therefore to authenticate the Merchant M by comparison of the digests.
  • the merchant tells the customer the digest (shown to each of M and C at step 5a above) over the phone the customer is able to make a visual comparison with the digest displayed on SD 20 and can for example approve a transaction process by pressing button 28 .
  • the digests do not match then the customer can abort the process, using button 29 shown in FIG. 2 .
  • Other structural arrangements are possible including for example that the Merchant's digest is transmitted to the Customer either because the customer is present and can see, the Merchant's equipment, or via the insecure network, in an appropriately secure way, e.g. using https over the internet enabling display to the user on a PC using the user's internet browser application. The user is able therefore visually or otherwise to compare the digests shown on the PC 18 and SD 20 .
  • an “empirical channel” is a low-bandwidth channel which is not forgeable but which is potentially vulnerable to snooping and blocking.
  • onymous used herein is intended to mean that it is not necessary for a node to reveal its long-term name, public key etc.
  • the component ⁇ k ⁇ _pkM or Message 2 may be replaced by longhash(k) or longhash(pkM,k). This enables Message 2 to be computed significantly faster on a low power SD.
  • the value k used in the Message 5 digest is replaced by this new long hash, and the value ⁇ k ⁇ _pkM is sent from C to M as an additional Message 6. It is thus possible for the SD to perform the asymmetric encryption during the period when the customer is confirming the agreement of the digest values.
  • the value k in Message 5a is replaced by the pair (g ⁇ X, g ⁇ Y), meaning that (since g ⁇ Y can be computed in advance) the SD does not need to perform the expensive exponentiation operation before the digest agreement stage of the protocol, which may be valuable when it is a low power device.
  • HCBK3 in its standard form, establishes a shared key for an arbitrary-sized group.
  • the present application only requires two parties in the group, namely the customer C and merchant M, so the following description is specialised to that case.
  • the customer initiating the protocol, transmits to M its identity C together with other information that it wishes the merchant to know for the purposes of this protocol.
  • the merchant sends its corresponding information, including a means of initiating secret communication to it which we assume below is a public key pkM.
  • This step provides some way of ensuring that C will not send a Message 3 while any other node or agent in G is still waiting for a Message 2.
  • the most obvious way of doing this is to use the empirical channel at this point to inform C that all others are committed. For example, when the merchant has received Message 2 it might display an indication of this that the customer can read.
  • C sends each node the hash key hk under M's public key as contained in INFO M in Message 1, or alternatively sent using any other means of C communicating securely to M that is seemingly contained in Messages 0 and 1.
  • M can check the value of hk by testing to see if it produces the correct value for Message 2 and they only proceed if this is true.
  • Both parties generate a digest value of the values received in Messages 0 and, influenced by the value hk, and display this value together.
  • the parties compare the displayed digests. If this check fails, the run is abandoned. In the asymmetric protocol only the customer performs this check.
  • Each implementation should ensure that the commitment deduced by C in Message 2b does not relate to an earlier run by M. In other words, in Message 4, M should be committed to the same hash key hk that C saw it committed to. This property will naturally hold in many human-mediated symmetric implementations, provided these users follow natural rules. In other implementations it may be necessary or desirable to enforce it via, for example, timing constraints or further empirical communications.
  • the nodes wish to exchange authenticated information akin to the INFO fields described above, they can do so as additions to their first message exchange as in HCBK3. As in that protocol, the INFO fields should be added to the data component of the digest.
  • HCBK Hash Commitment Before Knowledge because nodes are committed to their final digests or hashes before they actually know the values of these things.
  • Protocols may exist or be developed that would achieve the authenticated transfer of information which would be required to authenticate the connection to the merchant for security device 20 based on the agreement of some value generated at both ends of the protocol.
  • the security device 20 can be adapted to encompass the use of any such protocol to achieve the desired effect.
  • the essential quality that a protocol requires is that the customer gains a means of communicating securely with the merchant.
  • the security device 20 requires a means of communicating data to and from the merchant 16 that is both authenticated and secret to them. This would be provided, for example, by them each knowing a symmetric key, that they know is known to nobody else.
  • the security device provides the means of transmitting the non-spoofable value on the internet (eg. via https) and the operation of the method beyond the initial protocol.
  • the main point is flexibility: essentially now the card has same degree of connection with the merchant as one in its own credit-card reader, with the added advantage that there is no need to allow merchant's equipment knowledge of anything that must be kept confidential such as the PIN.
  • Card prompts SD, customer for PIN, which is transmitted to Card along with a representation T of the transaction that the customer has agreed to.
  • cardsign is a signature mechanism for cards: if the card has its own certified public key then the above can be signed by that.
  • T is a suitable representation of the information that the customer has signified agreement to by typing the PIN.
  • the above mechanism can be afforded assurance from the point of view of the merchant by the checks the merchant will carry out on the card as part of the interaction.
  • the second alternative (which would be more effective if any less secure signature mechanism than the above example were used or if more control of PIN guessing is required than is provided by the card itself) is to delegate the decision about whether a PIN is correct to the bank.
  • the card has a long term shared secret with the Bank.
  • SId secret identity
  • it has the entropy of a typical strong cryptographic key or nonce, say 160 bits. It is important that this secret never becomes visible outside the card, even to the SD (or else anyone in temporary possession of the card could obtain it with a corrupt SD).
  • E the entropy itself
  • x the information the card has used to generate it.
  • the card itself could perform analogous calculations using SId itself.
  • the SD can compute a longhash H of the PIN, (E,x), and a record T of the transaction the customer has approved by entering the PIN. This must contain the public identities of Merchant and Customer, the amount and type of transaction, a unique transaction Id and timestamp.
  • the SD then sends the Merchant ⁇ H,x,T ⁇ k , where k is the session key between SD and Merchant.
  • the Merchant checks T and forwards ⁇ H,x,T ⁇ to the Bank, which recomputes the hash using its knowledge of the PIN and SId, and checks it equals H. If so the PIN is verified and presumably the Bank will signal this to the Merchant. 2.
  • the SD computes ⁇ PIN,T ⁇ E under some suitable symmetric key encryption algorithm where the (i) the ability to produce this proves knowledge of E, and (ii) it is not feasible for an agent not knowing E to alter ⁇ X ⁇ E so that it equals ⁇ X′ ⁇ E for any different X′.
  • the SD then sends the merchant ⁇ PIN,T ⁇ E ,x ⁇ k , and the contents of this are forwarded to the bank who can once again check the PIN.
  • Method 1 is not suitable for sending this data to the Bank.
  • Method 2 remains suitable, as would Method 1 if the correctness or otherwise of the data was determined by the card itself so that the data itself does not have to be sent.
  • Chip and PIN methods with all transactions between SD and merchant encrypted under k.
  • a Toeplitz matrix is one whose diagonals (top left to bottom right) each consist of identical items.
  • An n by b matrix can thus be described by a sequence of n+b ⁇ 1 numbers V(1 ⁇ b) . . . V(0), V(1), . . . V(n ⁇ 1) in which the matrix value m(i,j) always equals V(i ⁇ j).
  • Uh(k,x) a perfect Universal Hash function Uh(k,x) can be computed by deriving a Toeplitz matrix of uniformly distributed independent random variables over ⁇ 0,1 ⁇ from the uniformly distributed value k (so V(i) is the value taken by the ith random variable) and multiplying the bit value of x by it.
  • the first is a hardware implementation, as might be implemented as a custom chip or on an FPGA.
  • a programmable device 50 such as an ASIC or FPGA comprising an interface 52 for communication with device 50 including input of key k, as shown schematically.
  • Device 50 also comprises a clock 54 , a PRNG 56 , shift registers 58 and 60 , and an XOR accumulator 62 as well a controller for ensuring suitable functionality.
  • a good candidate for this PRNG 56 is a feedback shift register seeded with k in which some of the parameters are randomly driven by part of k independent of the register's feed, or possibly several such registers.
  • a separate circuit of the type shown in FIG. 4 can be used for each bit-per cycle (bpc) of the PRNG 56 .
  • This contains two shift registers 58 , 60 , one of length b/2+1 containing the pseudo-random bits and one of length b/2 through which a fraction of the digested information M is piped. (M is divided for this purpose into bpc fractions.)
  • Each of these registers is shifted by one bit each cycle in opposite directions as shown in FIG. 4 , and they are initialised with values (possibly 0) functionally dependent on the key k b bits are produced by &-ing each bit of the M-stream with the bit of the PRNG-stream above it and the bit of the PRNG-stream to the right of this place.
  • the resulting b bits are XOR-ed into an accumulator 62 , which is itself initialised with some value functionally dependent on k.
  • the b-bit values produced from each of the bpc fractions of M are XOR-ed together to produce the final digest.
  • An equivalent effect can be produced with a single pair of shift registers of lengths bpc*b/2 and bpc*b/2+1) that are shifted bpc each cycle.
  • the second way of calculating a digest function is software driven.
  • a software implementation i.e. one implemented using the functionality of a microprocessor rather than customised hardware
  • the above relates to a software implementation of digest and is based on the way integer multiplication can provide a sufficiently good analogue of the Toeplitz model.
  • many other ways of using multiplication and other operations structurally similar to a convolution to implement digest functions might be used.
  • the security device 20 preferably comprises a display 24 for the digest, an “OK” or confirm button 28 and an “ABORT” button 29 .
  • display 24 is capable of displaying transaction information (payee, amount . . . ) and a way of inputting a PIN (see below).
  • k can now be used to protect and authenticate the interactions between a chipped card 36 coupled with an SD 20 , and the merchant it is connected to. Of course it is down to the design of these interactions as to whether any information useful to the merchant can be gleaned long term from this: see the discussion above.
  • Security device 20 can comprise an audio transducer arrangement for input and output of audio signals such as a microphone and speaker.
  • Mobile phones might have modes where they act as SDs. However they represent powerful computers in themselves, and may well be open to viruses. So it may be pragmatic that they enter some sort of special mode when their interface (probably literally a plug-in with the card reader) is active. This would be more straightforward in the case that a mobile phone was playing the role of a SD for the Internet (see below), because it would not need to be running its normal telephone function. Of course a mobile phone could provide a communication medium for a separate SD without such precautions.
  • the first part of the solution is to have the SD connected with the merchant via an insecure network.
  • the most likely mode is for it to be connected via the customer's computer (i.e. the device that is hosting the browser over which the transaction is being set up).
  • the manner of this connection does not matter: it could be Bluetooth, some other wireless technology, infra-red, or via a USB cable.
  • the connection between SD and merchant could be by other means such as telephone.
  • the SD/card combination then communicates with the merchant, both in setting up an encrypted session like the protocol above, and in actually transmitting and receiving information using the established session key. This interaction would probably be enabled and directed by the browser or an associated process in the case that the SD were connected via that computer.
  • the solution to the lack of a human at the merchant is that an https connection plays the role of the authenticated channel from merchant to customer.
  • the SD runs one of the protocols above with M, and M displays his view of the digest on the customer's browser using a secure web connection.
  • the secure link is purely between the SD and the merchant (who will presumably also be running the protocol in secure hardware).
  • a telephone augmented by a means of interfacing with the chip could become an SD for the internet provided it had a means of communicating either with the customer's own computer or directly with the merchant's.
  • the comparison of digests can be implemented at least in any of the following three ways, or conceivably a combination of more than one of them:
  • the first is that any technology for generating a one-time time-limited credit card number for the card's account could be integrated into the SD.
  • a secure connection has been made an electronic cheque of a form similar to that set out earlier would be registered at the bank, which would generate a unique identifier for this transaction.
  • the customer would write this number on the order form, which the merchant would verify upon receipt and carry forward the transaction.
  • the SD has a printing device incorporated then, in either of the above options, it would be possible for the SD to output a label or similar that could be affixed to the order form.
  • a traditional credit card transaction gives the merchant full access to the card, meaning that the merchant gains long-term knowledge of the card, and potentially its PIN (e.g. by a fake PIN-input device, video etc).
  • PIN e.g. by a fake PIN-input device, video etc.
  • the use of the customer's SD at the point of sale in conjunction with any of the methods of conducting a transaction as set out above would, depending on which was used, either in whole or part remove any possibility of electronic capture of this information and give the customer more control to prevent PIN-snooping.
  • the technology set out herein is capable of making secure connections over a wide range of applications.
  • the use of an https-based empirical channel will permit users to access wide range of services securely and thereby extend the usability of the HCBK family of protocols and any other protocol that authenticates two or more parties by manual comparison of data displayed on devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
US12/520,475 2006-12-22 2007-12-21 Method and device for mutual authentication Active 2031-10-03 US9270450B2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0625851.1 2006-12-22
GBGB0625851.1A GB0625851D0 (en) 2006-12-22 2006-12-22 Improvements in communications security
PCT/GB2007/004963 WO2008078101A2 (fr) 2006-12-22 2007-12-21 Perfectionnements à une sécurité de communications

Publications (2)

Publication Number Publication Date
US20100115277A1 US20100115277A1 (en) 2010-05-06
US9270450B2 true US9270450B2 (en) 2016-02-23

Family

ID=37759005

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/520,475 Active 2031-10-03 US9270450B2 (en) 2006-12-22 2007-12-21 Method and device for mutual authentication

Country Status (4)

Country Link
US (1) US9270450B2 (fr)
EP (2) EP2127199A2 (fr)
GB (1) GB0625851D0 (fr)
WO (1) WO2008078101A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220166653A1 (en) * 2019-06-07 2022-05-26 Michel Fattouche A Novel Communication System of High Capacity
US11562336B2 (en) 2014-09-03 2023-01-24 Paypal, Inc. Payment authorization system

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100095117A1 (en) * 2008-10-15 2010-04-15 Shebanow Michael C Secure and positive authentication across a network
BRPI0921808A2 (pt) * 2008-11-17 2018-06-05 Thomson Licensing desenho de cabeçalho de quadro de fec para sinais de televisões a cabo.
CN102246450B (zh) * 2008-12-10 2014-05-28 汤姆森特许公司 利用可变首标调制来传送和接收前向纠错帧首标的方法和装置
DE102009042284A1 (de) 2009-09-22 2011-03-31 Giesecke & Devrient Gmbh Verfahren zum Aufbauen eines gesicherten Kommunikationskanals
US9246672B2 (en) * 2010-06-24 2016-01-26 Blackberry Limited Two indices moving in opposite directions for cryptographic bidirectional communications using a shared master key
FR2973909B1 (fr) * 2011-04-08 2013-05-17 Agence Nationale Des Titres Securises Procede d'acces a une ressource protegee d'un dispositif personnel securise
DE102012220774B4 (de) 2012-01-09 2022-02-24 Heinz Giesen Verfahren zur Durchführung von Transaktionen
US10574461B2 (en) 2013-09-30 2020-02-25 Triad National Security, Llc Streaming authentication and multi-level security for communications networks using quantum cryptography
US9450757B2 (en) * 2014-05-07 2016-09-20 Oxcept Limited Method and device for communication security
GB2546340A (en) * 2016-01-18 2017-07-19 Isis Innovation Improving security protocols
GB201809887D0 (en) * 2018-06-15 2018-08-01 Iothic Ltd Decentralised authentication
US11392946B2 (en) 2018-09-04 2022-07-19 Visa International Service Association Identity authentication systems and methods

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998047258A2 (fr) 1997-03-10 1998-10-22 Fielder Guy L Systeme et procede bilateraux d'authentification et de chiffrage
WO2000079367A1 (fr) 1999-06-23 2000-12-28 The Brodia Group Procede et systeme permettant des transactions sures et garanties sur un reseau d'ordinateurs
WO2001018720A1 (fr) 1999-09-07 2001-03-15 Epacific, Inc. Procede et systeme d'autorisation d'achats effectues sur un reseau informatique
WO2001043033A1 (fr) 1999-12-09 2001-06-14 Amazon.Com, Inc. Utilisation d'un intermediaire pour fournir des informations sur les clients de façon securisee a des tiers commerçants sur l'internet
US20020018570A1 (en) 2000-07-07 2002-02-14 International Business Machines Corporation System and method for secure comparison of a common secret of communicating devices
WO2002019211A1 (fr) 2000-08-28 2002-03-07 Microcreditcard.Com, Inc. Procédé et système de facturation à tiers
US20020174075A1 (en) 2001-05-15 2002-11-21 International Business Machines Corporation System & method for on-line payment
US20030126094A1 (en) 2001-07-11 2003-07-03 Fisher Douglas C. Persistent dynamic payment service
US20030206630A1 (en) * 2002-05-03 2003-11-06 Rarick Leonard D. Method and apparatus for generating pseudo-random numbers
US20030220881A1 (en) 2002-01-23 2003-11-27 Nokia Corporation Electronic payments
US6804355B1 (en) * 2000-01-06 2004-10-12 Intel Corporation Block cipher for small selectable block sizes
US20050228983A1 (en) 2004-04-01 2005-10-13 Starbuck Bryan T Network side channel for a message board
US7526088B2 (en) * 2002-03-05 2009-04-28 Cordes Rene-Michael Code generator and device for the synchronous or asynchronous and permanent identification or encoding and decoding of data of any particular length

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998047258A2 (fr) 1997-03-10 1998-10-22 Fielder Guy L Systeme et procede bilateraux d'authentification et de chiffrage
WO2000079367A1 (fr) 1999-06-23 2000-12-28 The Brodia Group Procede et systeme permettant des transactions sures et garanties sur un reseau d'ordinateurs
WO2001018720A1 (fr) 1999-09-07 2001-03-15 Epacific, Inc. Procede et systeme d'autorisation d'achats effectues sur un reseau informatique
WO2001043033A1 (fr) 1999-12-09 2001-06-14 Amazon.Com, Inc. Utilisation d'un intermediaire pour fournir des informations sur les clients de façon securisee a des tiers commerçants sur l'internet
US6804355B1 (en) * 2000-01-06 2004-10-12 Intel Corporation Block cipher for small selectable block sizes
US20020018570A1 (en) 2000-07-07 2002-02-14 International Business Machines Corporation System and method for secure comparison of a common secret of communicating devices
WO2002019211A1 (fr) 2000-08-28 2002-03-07 Microcreditcard.Com, Inc. Procédé et système de facturation à tiers
US20020174075A1 (en) 2001-05-15 2002-11-21 International Business Machines Corporation System & method for on-line payment
US20030126094A1 (en) 2001-07-11 2003-07-03 Fisher Douglas C. Persistent dynamic payment service
US20030220881A1 (en) 2002-01-23 2003-11-27 Nokia Corporation Electronic payments
US7526088B2 (en) * 2002-03-05 2009-04-28 Cordes Rene-Michael Code generator and device for the synchronous or asynchronous and permanent identification or encoding and decoding of data of any particular length
US20030206630A1 (en) * 2002-05-03 2003-11-06 Rarick Leonard D. Method and apparatus for generating pseudo-random numbers
US20050228983A1 (en) 2004-04-01 2005-10-13 Starbuck Bryan T Network side channel for a message board

Non-Patent Citations (9)

* Cited by examiner, † Cited by third party
Title
Black et al., "UMAC: Fast and Secure Message Authentication", Advances in Cryptology, 1666: 216-233, (1999).
Creese et al., "Exploiting Empirical Engagement in Authentication Protocol Design," Lecture Notes in Computer Science, 3450: 119-133 (2005).
Foreign search report issued in related application No. GB0625851.1 (2007).
Huang et al., "Cryptographic Has Functions and Low-Power Techniques for Embedded Hardware", Proceedings of the IEEE International Symposium on Dubrovnik Croatia, 4:1789-1794, (2005).
International Search Report issued in PCT/GB07/04963 (2008).
Menezes et al., "Handbook of Applied Cryptography, Identification and Entity Authentication", Handbook of Applied Cryptography, 385-424 (1997).
Menezes et al., "Hash Functions and Data Integrity", Handbook of Applied Cryptography, 321-383 (1997).
Nguyen et al., "Efficient group authentication protocols based on human interaction," (internet citation): www.easychair.org/FloC-06/fcs-arspa06.pdf, 1-32 (2006).
Search Report issued in European Application No. 12/180192 (2012).

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11562336B2 (en) 2014-09-03 2023-01-24 Paypal, Inc. Payment authorization system
US20220166653A1 (en) * 2019-06-07 2022-05-26 Michel Fattouche A Novel Communication System of High Capacity
US11451418B2 (en) * 2019-06-07 2022-09-20 Michel Fattouche Communication system of high capacity

Also Published As

Publication number Publication date
WO2008078101A2 (fr) 2008-07-03
US20100115277A1 (en) 2010-05-06
EP2127199A2 (fr) 2009-12-02
EP2536062B1 (fr) 2019-07-24
GB0625851D0 (en) 2007-02-07
WO2008078101A3 (fr) 2009-04-23
EP2536062A1 (fr) 2012-12-19

Similar Documents

Publication Publication Date Title
US9270450B2 (en) Method and device for mutual authentication
US6189098B1 (en) Client/server protocol for proving authenticity
US7975139B2 (en) Use and generation of a session key in a secure socket layer connection
US8689290B2 (en) System and method for securing a credential via user and server verification
US9117324B2 (en) System and method for binding a smartcard and a smartcard reader
US20060256961A1 (en) System and method for authentication seed distribution
WO2001084761A1 (fr) Procede de securisation de communications entre un terminal et un autre dispositif utilisateur
KR101051420B1 (ko) 안전 ｏｔｐ 생성 장치 및 방법
CN113364597A (zh) 一种基于区块链的隐私信息证明方法及系统
Kungpisdan et al. A limited-used key generation scheme for internet transactions
CN110866754A (zh) 一种基于动态口令的纯软件dpva身份认证方法
JP2003152716A (ja) 可変認証情報を用いる資格認証方法
Chatterjee et al. A novel multi-server authentication scheme for e-commerce applications using smart card
Ortiz-Yepes Enhancing Authentication in eBanking with NFC-enabled mobile phones
JP3889660B2 (ja) 認証方法及び認証システム
Herath et al. Task based Interdisciplinary E-Commerce Course with UML Sequence Diagrams, Algorithm Transformations and Spatial Circuits to Boost Learning Information Security Concepts
Molla Mobile user authentication system (MUAS) for e-commerce applications.
Krzyzanowski Cryptographic communication and authentication
CN117709958A (zh) 支付方法、装置、非易失性存储介质及计算机设备
AU2002259074B2 (en) Use and generation of a session key in a secure socket layer connection
Chen et al. A server-aided signature scheme for mobile commerce
Kim Cryptanalysis and enhancement of authentication protocols
KADIRIRE Online transactions’ security’
CN117745289A (zh) 支付方法、装置、非易失性存储介质及计算机设备
Janbandhu Novel biometric digital signature system for electronic commerce applications

Legal Events

Date Code Title Description
AS Assignment

Owner name: ISIS INNOVATION LIMITED,UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROSCOE, ANDREW WILLIAM;REEL/FRAME:023625/0196

Effective date: 20090811

Owner name: ISIS INNOVATION LIMITED, UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROSCOE, ANDREW WILLIAM;REEL/FRAME:023625/0196

Effective date: 20090811

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: OXFORD UNIVERSITY INNOVATION LIMITED, GREAT BRITAIN

Free format text: CHANGE OF NAME;ASSIGNOR:ISIS INNOVATION LIMITED;REEL/FRAME:039550/0045

Effective date: 20160616

Owner name: OXFORD UNIVERSITY INNOVATION LIMITED, GREAT BRITAI

Free format text: CHANGE OF NAME;ASSIGNOR:ISIS INNOVATION LIMITED;REEL/FRAME:039550/0045

Effective date: 20160616

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8