CA2678101C - Authentication device and method - Google Patents
Authentication device and method Download PDFInfo
- Publication number
- CA2678101C CA2678101C CA2678101A CA2678101A CA2678101C CA 2678101 C CA2678101 C CA 2678101C CA 2678101 A CA2678101 A CA 2678101A CA 2678101 A CA2678101 A CA 2678101A CA 2678101 C CA2678101 C CA 2678101C
- Authority
- CA
- Canada
- Prior art keywords
- data
- dynamic password
- cryptographic scheme
- generate
- code
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 52
- 230000008569 process Effects 0.000 claims abstract description 21
- 238000004891 communication Methods 0.000 claims abstract description 5
- 238000010200 validation analysis Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 6
- 238000007906 compression Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 101100234002 Drosophila melanogaster Shal gene Proteins 0.000 description 1
- 235000015076 Shorea robusta Nutrition 0.000 description 1
- 244000166071 Shorea robusta Species 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000013518 transcription Methods 0.000 description 1
- 230000035897 transcription Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
-
- 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
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
-
- 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
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
- G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
Abstract
This invention relates to an authentication device and method, in particular to devices and methods for generating dynamic passwords, and to cards carrying the device and to software implementing the method. An apparatus for generating intermediate cryptogram data corresponding to a dynamic password for a first cryptographic scheme, the intermediate cryptogram data being suitable for display using a device designed for a second, different cryptographic scheme, the apparatus comprising: a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor controlcode to controlthe processor, when running, to: generate a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data corresponding to said dynamic password, the intermediate cryptogram data being suitable for outputting to the said deviceso that, when the said device processes said intermediate cryptogramdata according to the second cryptographic scheme, the said device generates data suitable for displaying said dynamic password.
Description
Authentication device and method This invention relates to an authentication device and method, in particular to devices and methods for generating dynamic passwords, and to cards carrying the device and to software implementing the method.
Authentication of remote users is an essential part of many web- and network-based applications. Traditional usemames and passwords offer an inexpensive but weak solution. Higher security is often obtained by issuing users with a `token'¨a small, portable device __ which generates apparently random passwords that are valid only for a single use: so-called one-time-passwords (OTPs). By presenting an OTP to the system the user demonstrates possession of the token, which when combined with a traditional static password provides strong, two-factor authentication.
A wide variety of tokens exists in the market, based primarily on proprietary, vendor-specific technology. For example, RSA SecureID, VASCO Digipass, Secure Computing and Active Identity. A standardisation effort is currently taking place within the token-vendor community, called the Initiative for Open Authentication (OATH) [http://www.openauthentication.org]. This seeks to promote standards for OTP-generating tokens and the infrastructure necessary for their deployment and use.
At the same time, the need for strong authentication in the financial sector has lead MasterCard to pioneer an alternative standard, based on a variant of the standard 'Chip and PIN' payment card (Figure 1). In this scheme, called the Chip Authentication Program (CAP) [Chip Authentication Program Function Architecture, MasterCard International, September 20041, a hand-held card reader (Figure 2) is used to create OTPs based on the core functions within the card. The card readers are anonymous and interchangeable, and the concept calls for widespread deployment to make them commonplace items in every household or office, thus removing the need for individual users to carry their card reader on their person.
Authentication of remote users is an essential part of many web- and network-based applications. Traditional usemames and passwords offer an inexpensive but weak solution. Higher security is often obtained by issuing users with a `token'¨a small, portable device __ which generates apparently random passwords that are valid only for a single use: so-called one-time-passwords (OTPs). By presenting an OTP to the system the user demonstrates possession of the token, which when combined with a traditional static password provides strong, two-factor authentication.
A wide variety of tokens exists in the market, based primarily on proprietary, vendor-specific technology. For example, RSA SecureID, VASCO Digipass, Secure Computing and Active Identity. A standardisation effort is currently taking place within the token-vendor community, called the Initiative for Open Authentication (OATH) [http://www.openauthentication.org]. This seeks to promote standards for OTP-generating tokens and the infrastructure necessary for their deployment and use.
At the same time, the need for strong authentication in the financial sector has lead MasterCard to pioneer an alternative standard, based on a variant of the standard 'Chip and PIN' payment card (Figure 1). In this scheme, called the Chip Authentication Program (CAP) [Chip Authentication Program Function Architecture, MasterCard International, September 20041, a hand-held card reader (Figure 2) is used to create OTPs based on the core functions within the card. The card readers are anonymous and interchangeable, and the concept calls for widespread deployment to make them commonplace items in every household or office, thus removing the need for individual users to carry their card reader on their person.
2 However, CAP is a closed, proprietary system and is not compatible with other systems.
In the future, CAP-compatible card readers may become widely available, but they will only be useful with CAP-compatible Chip and PIN cards in applications approved by their issuing banks, since only the issuing bank has access to the information needed to verify an OTP generated by the card.
We will describe a means of exploiting standard CAP card readers together with a custom, non-payment card to generate OATH-compatible OTPs. An advantage of this approach is that standard OATH infrastructure can be used for the deployment of the cards and validation of the resulting OTPs, whilst the cost of tokens is reduced to the cost of a chip-card, by exploiting the deployed card reader base. More generally, we will describe algorithm substitution in card and reader based one-time-password devices. Cards may be provided to work with, for example, RSA SecurelD, VASCO
DigiPass, Secure Computing or Actividentity schemes instead of or as well as OATH.
We will describe an integrated circuit for generating a dynamic password for a first cryptographic scheme, the circuit being suitable for use with a device designed for a second, different cryptographic scheme, the circuit comprising: a power supply input for supplying power to the integrated circuit; an interface for transmitting data to and receiving data from the integrated circuit; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to generate a dynamic password according to the first cryptographic scheme and then to produce intermediate cryptogram data suitable for outputting to the said device such that the processing performed by the device according to the second cryptographic scheme results in the device generating the original dynamic password according to the first cryptographic scheme.
We will describe a method of outputting pseudo-cryptogram data corresponding to a dynamic password according to a first cryptographic scheme, the data being suitable for output to a device designed for a second, different cryptographic scheme, the method comprising generating the dynamic password according to the first cryptographic scheme and then generating intermediate cryptogram data by the reverse of the
In the future, CAP-compatible card readers may become widely available, but they will only be useful with CAP-compatible Chip and PIN cards in applications approved by their issuing banks, since only the issuing bank has access to the information needed to verify an OTP generated by the card.
We will describe a means of exploiting standard CAP card readers together with a custom, non-payment card to generate OATH-compatible OTPs. An advantage of this approach is that standard OATH infrastructure can be used for the deployment of the cards and validation of the resulting OTPs, whilst the cost of tokens is reduced to the cost of a chip-card, by exploiting the deployed card reader base. More generally, we will describe algorithm substitution in card and reader based one-time-password devices. Cards may be provided to work with, for example, RSA SecurelD, VASCO
DigiPass, Secure Computing or Actividentity schemes instead of or as well as OATH.
We will describe an integrated circuit for generating a dynamic password for a first cryptographic scheme, the circuit being suitable for use with a device designed for a second, different cryptographic scheme, the circuit comprising: a power supply input for supplying power to the integrated circuit; an interface for transmitting data to and receiving data from the integrated circuit; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to generate a dynamic password according to the first cryptographic scheme and then to produce intermediate cryptogram data suitable for outputting to the said device such that the processing performed by the device according to the second cryptographic scheme results in the device generating the original dynamic password according to the first cryptographic scheme.
We will describe a method of outputting pseudo-cryptogram data corresponding to a dynamic password according to a first cryptographic scheme, the data being suitable for output to a device designed for a second, different cryptographic scheme, the method comprising generating the dynamic password according to the first cryptographic scheme and then generating intermediate cryptogram data by the reverse of the
3 processing performed by the device according to the second cryptographic scheme and outputting said intermediate cryptogram data, such that the device on processing the data generates the original dynamic password according to the first cryptographic scheme.
According to an aspect of the present invention, there is provided an apparatus for generating intermediate cryptogram data corresponding to a password for a first cryptographic scheme, the apparatus being suitable for use with a device designed for a second, different cryptographic scheme, the apparatus comprising: a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a password according to the first cryptographic scheme; and generate intermediate cryptogram data corresponding to said password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme, the said device generates said password.
Preferably the password comprises a dynamic password, or a password which is generated by including bits from a binary counter or clock into the cryptogram calculation, and in the case that a counter is used incrementing the counter each time a password is generated.
On occasion the dynamic password of the first cryptographic scheme may be incompatible with the device of the second cryptographic scheme, and code to generate a dynamic password may comprise code to generate dynamic passwords repeatedly until a dynamic password is found which is compatible with the second cryptographic scheme.
This incompatibility may be caused by leading zeros occurring in certain dynamic passwords of the first cryptographic scheme, which may be incompatible with the device of the second cryptographic scheme.
According to an aspect of the present invention, there is provided an apparatus for generating intermediate cryptogram data corresponding to a password for a first cryptographic scheme, the apparatus being suitable for use with a device designed for a second, different cryptographic scheme, the apparatus comprising: a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a password according to the first cryptographic scheme; and generate intermediate cryptogram data corresponding to said password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme, the said device generates said password.
Preferably the password comprises a dynamic password, or a password which is generated by including bits from a binary counter or clock into the cryptogram calculation, and in the case that a counter is used incrementing the counter each time a password is generated.
On occasion the dynamic password of the first cryptographic scheme may be incompatible with the device of the second cryptographic scheme, and code to generate a dynamic password may comprise code to generate dynamic passwords repeatedly until a dynamic password is found which is compatible with the second cryptographic scheme.
This incompatibility may be caused by leading zeros occurring in certain dynamic passwords of the first cryptographic scheme, which may be incompatible with the device of the second cryptographic scheme.
4 Alternatively the incompatibility may be caused by a check digit automatically generated by said device which is incompatible with certain dynamic passwords of the first cryptographic scheme.
According to another aspect of the present invention, there i.s provided a method of generating intermediate cryptogram data corresponding to a cryptogram according to a first cryptographic scheme, the data being suitable for display on a device designed for a second, different cryptographic scheme, the method comprising: generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data corresponding to said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, when the said device processes said inteimediate cryptogram data according to the second cryptographic scheme, the said device outputs said dynamic password.
The invention further provides processor control code to implement the above-described methods, for example on a general purpose computer system or on a digital signal processor (DSP), or on a dedicated integrated circuit, for example a smart card. The code may be provided on a carrier such as a disk, CD- or DVD-ROM, programmed memory such as read-only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. Code (and/or data) to implement embodiments of the invention may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code. The above described methods may also be implemented, for example, on an FPGA (field programmable gate array) or in an ASIC (application specific integrated circuit). Thus the code may also comprise code for setting up or controlling an ASIC or FPGA, or code for a hardware description language such as Verilog (Trade Mark), VHDL (Very high speed integrated circuit Hardware Description Language), or RTL code or SystemC. Typically dedicated hardware is described using code such as RTL (register transfer level code) or, at a higher level, using a language such as C. As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another.
Features of the above described aspects and embodiments of the invention may be combined in any permutation.
According to an aspect of the present invention there is provided an apparatus for generating intermediate cryptogram data corresponding to a dynamic password for a first cryptographic scheme, the intermediate cryptogram data being suitable for display using a device designed for a second, incompatible cryptographic scheme for generating a password, the apparatus comprising:
a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by the first cryptographic scheme.
According to another aspect of the present invention there is provided an integrated circuit including the apparatus as described herein.
According to a further aspect of the present invention there is provided a card carrying the integrated circuit as described herein.
According to a further aspect of the present invention there is provided a method of generating intermediate cryptogram data corresponding to a cryptogram according to a first cryptographic scheme, the data being suitable for display on a device designed for a second, incompatible cryptographic scheme for generating a password, the method comprising:
generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, 5a when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by said first cryptographic scheme.
According to a further aspect of the present invention there is provided a computer readable medium on which is stored a set of instructions which, when executed by a processor, carry out the method as described herein.
Embodiments of these and other aspects of the invention will now be described in detail with reference to the accompanying drawings, in which:
Figure 3 shows a flowchart of a method according to an embodiment of the invention.
Figure 4 shows a block diagram of a device according to an embodiment of the invention.
We will first describe the MasterCard Chip Authentication Program.
Chip and PIN Cards 'Chip and PIN' cards follow technical standards more formally known as EMV, after Europay, MasterCard and Visa. They are being widely adopted in many countries worldwide, as they offer powerful security features allowing card issuers to control various forms of fraud.
A chip embedded in each EMV card is used to authorise transactions. The authorisation is based on a cryptogram computed using a key unique to the card, together with details of the transaction. The key is embedded into the chip during the issuing process, and a copy retained securely by the issuing bank. The chip also maintains a counter value, known as the Application Transaction Counter (ATC), which is included in the cryptogram computation and incremented with each transaction, as a defence against replay attacks. Finally, the cardholder supplies a PIN, which the chip verifies against a 5b stored reference value, before allowing the cryptogram to be computed.
On receiving a transaction, the issuer is able to re-compute the cryptogram using their copy of the card's key. Since no-one else has the key, a valid cryptogram must originate with the card, and the verification of the PIN by the card demonstrates the card is still in the possession of the original cardholder.
CAP Overview A special class of transactions is known as 'card not present' (CNP) transactions. These include mail order, telephone order and web-based e-commerce transactions. In.
these cases, payment is authorised by the issuing bank based simply on the visible card details such as the card number and expiry date. Since these values are static in nature and easily copied, CNP transactions are an attractive target for fraud.
MasterCard, together with a number of other organisations in the card industry, has developed a standard to allow the security of Chip and PIN cards to be leveraged in CNP scenarios. This scheme is called the Chip Authentication Program (CAP).
CAP requires that each cardholder be issued with a small, hand-held card reader. By inserting their card into their reader, and entering their PIN, the cardholder can generate an OTP based on the key and ATC on the card. The issuer can verify the OTP by re-computing the cryptogram based on the same input data and key.
Note that the card reader is not personal to the cardholder in any way, and does not perform security-critical operations.
EMV CAP OTP Computation Chip and PIN chip-cards were designed for use at point-of-sale payment terminals and ATMs, not specifically for one-time-password generation. CAP readers simulate EMV
payment terminals in their interaction with the card, and the reader is then responsible for taking the payment cryptogram produced by the card and converting it into a one-time-password.
The processing carried out by the CAP reader is specified in detail in [Chip Authentication Program Function Architecture], but in summary it comprises the following stages:
1. Collecting cryptogram input data 2, Extracting OTP data 3. Decimalisation Each step is explained in further detail below.
Collecting Cryptogram Input Data The two principal inputs to the cryptogram computation process are the card key and the ATC. However, with EMV, there are a number of other parameters that are used as inputs into the cryptogram validation. These are specific to card payments, and do not have equivalents in other types of token. In order to reproduce the cryptogram, the validation server must use identical values for these parameters.
In a typical CAP scenario, most of these parameters are either fixed in value when the card is issued, or can be predicted by the validation server. However, a small number of the parameters may change during the card's lifecycle, according to how the card is used. For example, this includes parameters which limit the number or amount of the transactions that the card will authorise off-line. Since the validation server cannot predict these values, they must be transmitted from the card to the server, embedded in the one-time-password itself.
Extracting OTP Data In order to as user-friendly as possible, the one-time-password produced should be as short as possible, whilst maintaining a reasonable level of security. Since the EMV
cryptogram input data, combined with the cryptogram itself, is far too large to be included in the one-time-password in its entirety, it is compressed.
The compression process is defined by a CAP-specific field on the card, known as the Issuer Proprietary Bitmap (IPB), but the process itself is carried out by the card reader.
The IPB defines which bits from the ATC, cryptogram and other EMV input data will be used in the one-time-password¨the other bits are discarded.
Typically, a small number of ATC bits are included, to assist with synchronisation of counter values between server and card, together with at least 16 bits of the cryptogram, and finally those additional cryptogram inputs that cannot be predicted by the server. In some cases, where the card application is used for CAP only and not for payment, it may be that all additional inputs can be predicted by the server and so the OTP is based on the ATC and cryptogram alone.
Decimalisation Finally, the 'binary output from the compression process is decimalised for display to the user on the reader screen. A number of decimalisation schemes are possible, but CAP
defines a single scheme based on simply interpreting the truncation process output as the binary representation of a single integer. Leading zeros are ignored, and so the final length of the OTP can vary.
Next we describe the Open Authentication Standards (OATH).
Overview The Initiative for Open Authentication (OATH) is an industry co-ordinating body seeking to promote the standardisation of the token-based authentication marketplace.
OATH has published a 'reference architecture' describing a vision of a general authentication framework, and is promoting a number of standards for the various interfaces and components within this system.
Most interesting to this application is µHOTP: An HMAC-based one-time-password algorithm', which is being standardised by the IETF as RFC4226 [HOTP: An HMAC-Based One-Time Password Algorithm, httn://www.ietforg/rfc/rfc4226.txt, December 2005].
HOTP Computation As with CAP, the HOTP algorithm is based on an underlying cryptographic primitive, in this case HMAC-SHAL The inputs to this algorithm defined in HOTP are a token key and a counter¨very similar to the basic inputs to an EMV cryptogram computation as used by CAP.
The HOTP computation process is as follows:
1. HIVIAC computation, based on the token key and counter. The counter is then automatically incremented.
2. 'Dynamic Truncation' of the result to give a 31-bit value.
3. Decimalisation of the truncated value, to give the OTP.
Whilst the parallels with the CAP OTP computation are clear, it is important to note that the details of each stage are entirely different. Each step is described and contrasted with its CAP equivalent below, HNIAC Computation The HMAC computation used is as specified in [HMAC: Keyed Hashing for Message Authentication, RFC2104, http://www,ietf org/rfc/rfc2104.txt, February 1997], using SHAl as the underlying hash algorithm [US Secure Hash Algorithm 1 (SHA1), RFC3174, http://www.ietf.org/rfc/rfc3174.txt, September 2001]. The key required by HMAC-SHAl is typically 20 bytes in length, and [HOTP] specifies that an 8-byte counter is used as the only HMAC input data.
The result is a 20-byte binary value, compared to the 8-byte cryptogram used by CAP.
In both cases, a principal objective is that it should not be feasible to recover information about the key from the resulting OTPs. This is the reason why, in both cases, a cryptographic algorithm of some sort is employed.
Dynamic Truncation The truncation process defined by [HOTP] reduces the 20-byte HMAC output to a bit string.
Firstly, the last 4 bits of the last byte of the HMAC output are considered as an integer n in the range 0-15. Then, bytes n, n + 1,..., n + 3 are used as the truncation output (with the leading bit ignored).
The differences with the compression scheme used by CAP are marked:
= The CAP IPB always selects bits from the same position in the EMV
cryptogram for use in the OTP. In OATH, the position of the bits varies, deteimined by the last 4 bits in the HMAC output, hence the term 'dynamic'.
= The cun-ent edition of [HOTPI provides no mechanism for embedding counter synchronisation information in the resulting OTP, whereas the CAP IPB can specify an arbitrary number of ATC bits for inclusion in the OTP.
= The CAP IPB can specify a number of other, EMV-specific data elements for inclusion in the OTP. No such facility is relevant for HOTP.
Decimalisation HOTP decimalisation consists of interpreting the 31-bit output from the dynamic truncation process as the binary representation of an integer, and then reducing that integer modulo 10d, where d is the number of digits desired in the resulting OTP.
In contrast with CAP, if the result has fewer than d digits then leading zeros are inserted to give a total OTP length d.
Note also that this decimalisation process actually performs an additional truncation, in the sense that the output has a smaller information content than the input. In CAP, no information is lost during decimalisation, We will now describe generating OATH OTPs using a CAP Reader. Figure 3 shows an example of a method to achieve this.
We describe a means to generate OATH-compatible OTPs using a standard, unmodified CAP reader, by producing a special OATH chip-card to use within that reader.
This allows an organisation wishing to deploy OATH to deploy low-cost chip-cards instead of higher-cost tokens, exploiting the deployed CAP card-reader infrastructure to use these chip-cards with existing, off-the-shelf OATH validation servers.
Clearly the OATH chip-card reproduces the EMV card interface, or at least those parts of the EMV interface that are used by the CAP reader. Otherwise, the reader would reject the card, The critical card function call is the GENERATE AC call that is used to generate the cryptogram itself. Note that it does not suffice to simply replace the implementation of this function in the card with a function that generates a HOTP hash value, as used in the computation of OATH OTPs. This is because the process of compressing and decimalising the cryptogram to give the OTP is carried out in the reader, and is entirely different between CAP and OATH.
The OATH chip-card therefore implements the following sequence of operations:
1. Generate the HOTP hash value (301), based on the card key and counter, and increment the counter (302).
2. Truncate and decimalise the hash value (303) to produce the OTP itself.
3. Convert the OTP back into a binary format (304), using a process that is the reverse of the decimalisation process employed by a CAP reader.
4. Pad the resulting binary data (305) in a manner that is the reverse of the =
compression process employed by a CAP reader (as defined by the 1PB value on the card).
We call the result an intermediate cryptogram. The OATH chip-card passes this intermediate cryptogram to the CAP reader, as if it were a normal EMV
cryptogram, The CAP reader will then compress and decimalise the data, effectively reversing steps 4 and 3 above, and thus the end result displayed on the reader screen will he the OATH
OTP, as computed by the OATH card at step 2 above. Figure 4 shows a block diagram of an example of a device for an OATH chip-card compatible with CAP readers.
Special Cases A number of special cases arise, which are considered as follows.
Leading Zeros During decimalisation, both CAP and HOT? may result in a decimal result beginning with '0'. CAP specifies that such leading zeros be removed (and so the resulting OTP
may vary in length), whereas HOTP specifies that they be included in the OTP
(which therefore has fixed length).
Note that in CAP, the decimalisation process¨including truncation of leading zeros¨
takes place in the reader. Thus it is not possible to force a CAP reader to display a HOTP OTP that includes leading zeros, regardless of the method used in the chip-card.
We present three possible solutions to this problem:
1. The first possible solution is simple, but unsatisfactory; instruct users to insert additional zeros ahead of the displayed OTP when it is below the expected length.
2. The second possible is to have the authenticating application or validation server insert any missing leading zeros automatically before validating the OTP. This gives a better user experience, but defeats the original objective of implementing OATH using CAP readers without any changes to the validation infrastructure.
3. The third approach is for the OATH chip-card to identify such cases, and when they occur, to automatically discard the OTP (at step 2 above), and generate a new OTP
based on the incremented counter value.
Since the leading digit is effectively random, a long sequence of passwords all beginning with zero is highly unlikely. Moreover, since the validation server in any case accepts a range of counter values in order to avoid synchronisation problems, omitting the occasional password because it begins with a zero does not cause validation to fail, and is unnoticed by the user. Lastly, whilst this technique does reduce the number of possible HOTP outputs by some 10%, a 6-digit minimum length gives at least 1 million possible OTPs and so the overall security offered is still entirely acceptable.
Counter Synchronisation Digits At present HOTP does not specify any means of including counter synchronisation digits in the OTP, whereas CAP offers a flexible scheme, configured using the IPB
embedded in the card, By simply suppressing the CAP synchronisation digits with an appropriate 1PB value, compatibility can be attained.
Consider the possibility that a future version of HOTP may include a means of including counter synchronisation information in the OTP. It is highly likely that the algorithm chosen would not be compatible with that used by CAP, since there is no analogue to the CAP IPB in HOTP. We remark that compatibility can still be obtained, by continuing to suppress the CAP synchronisation information using the IPB
and passing the HOTP synchronisation data from the card to the reader in the intermediate cryptogram, together with the remainder of the OTP.
Now consider the scenario in which the CAP reader includes a mandatory check digit or other synchronisation data, but that HOTP does not. In this case, the reader will receive the cryptogram from the card, and will in addition also receive the ATC value, from which to extract synchronisation data, combining the two to give the displayed OTP. In this case, compatibility can still be maintained, by use of additional card logic. The card should compute the HOTP OTP, and separate it into two parts-----that which the reader will extract from the intermediate cryptogram, and that which the reader will extract from the ATC. The card then provides an intermediate cryptogram and an alternative ATC to the reader, knowing that the reader will combine these to reconstruct the original OTP. The key observation is that the reader has no way of knowing that the value in the alternative ATC is not the same as the counter value used to compute the OTP.
Lastly, note that the scenario in which both HOTP and CAP implement synchronisation schemes, but differently, can be handled by a combination of the above techniques.
Check Digits Check digits are sometimes used to detect errors in data, in particular errors introduced by human transcription. At present, neither CAP nor HOTP includes a check-digit mechanism for the OTPs created, but it is possible that this may change in future.
If a standard CAP reader were required to support a HOTP check digit, this could be achieved by simply embedding the check-digit in the intermediate cryptogram that is passed to the reader, similarly to the technique used to pass synchronisation data discussed above, Alternatively, suppose the CAP reader were to automatically include a check digit in the OTPs, which HOTP did not specify. This would create a more significant problem, since the card would have no means to suppress such a check digit. The only solutions are to modify the application or validation infrastructure to accept HOTP OTPs with CAP check digits appended, or to have the custom card repeatedly generate OTPs until (by luck) an OTP with a correct check digit is found and an appropriate intermediate cryptogram (which does not include the check digit, since it will be added by the reader) computed.
The latter approach would greatly increase the card computation time, since quite a number of OTPs may have to be calculated before a suitable value is found. The card counter would increment far faster than normal, and the tolerance at the validation server may need to be adjusted accordingly. Whilst the increase in card counter required is unpredictable, it is likely that an appropriate balance of system parameters (OTP length, validation server tolerance) can still be found offering acceptable security and reliability as long as the amount of error-checking information inserted by the card reader is not too Large.
Note that this last technique is a repeat of the technique used to handle leading zeros in the HOTP-based OTP. In general: if the HOTP OTP is incompatible with the card reader for whatever reason (in the above examples, because of a leading zero or check digit), it is always possible for the card to simply increment the card counter value until a compatible OTP is found. The applicability of this technique in practice depends on the number and distribution of incompatible OTPs and the validation server parameters.
We have described the specific scenario of a CAP card reader using a special card to achieve OATH compatibility, and alternatives regarding counter synchronisation and check digits. We now list some further possible applications:
Cards may be provided for use with readers designed for any OTP-based system based on a cryptographic engine separate from the user interface, not just CAP.
However, CAP is the most likely system to achieve high volume deployment in the next few years. Cards may be provided for use in any OTP system, not just OATH.
Examples include RSA SecureID, VASCO DigiPass, Secure Computing and ActivIdentity.
Cards may be provided for challenge-response authentication. Cards may be provided for 'short signatures', in which the token produces an OTP based on message data entered by the user (both still including the counter value, and not). Possible applications include where the CAP reader is replaced by a mobile phone (i.e. a mobile phone with a card reader having enough CAP-compatibility to work with the cards). Other applications include where the OATH card is inserted into a card reader which is connected to the user's PC. Further applications include where the OTP is communicated verbally over the telephone, instead of the Internet, or by mail, or by fax, or over an internal network.
No doubt many other effective alternatives will occur to the skilled person.
It will be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the scope of the claims appended hereto.
According to another aspect of the present invention, there i.s provided a method of generating intermediate cryptogram data corresponding to a cryptogram according to a first cryptographic scheme, the data being suitable for display on a device designed for a second, different cryptographic scheme, the method comprising: generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data corresponding to said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, when the said device processes said inteimediate cryptogram data according to the second cryptographic scheme, the said device outputs said dynamic password.
The invention further provides processor control code to implement the above-described methods, for example on a general purpose computer system or on a digital signal processor (DSP), or on a dedicated integrated circuit, for example a smart card. The code may be provided on a carrier such as a disk, CD- or DVD-ROM, programmed memory such as read-only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. Code (and/or data) to implement embodiments of the invention may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code. The above described methods may also be implemented, for example, on an FPGA (field programmable gate array) or in an ASIC (application specific integrated circuit). Thus the code may also comprise code for setting up or controlling an ASIC or FPGA, or code for a hardware description language such as Verilog (Trade Mark), VHDL (Very high speed integrated circuit Hardware Description Language), or RTL code or SystemC. Typically dedicated hardware is described using code such as RTL (register transfer level code) or, at a higher level, using a language such as C. As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another.
Features of the above described aspects and embodiments of the invention may be combined in any permutation.
According to an aspect of the present invention there is provided an apparatus for generating intermediate cryptogram data corresponding to a dynamic password for a first cryptographic scheme, the intermediate cryptogram data being suitable for display using a device designed for a second, incompatible cryptographic scheme for generating a password, the apparatus comprising:
a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by the first cryptographic scheme.
According to another aspect of the present invention there is provided an integrated circuit including the apparatus as described herein.
According to a further aspect of the present invention there is provided a card carrying the integrated circuit as described herein.
According to a further aspect of the present invention there is provided a method of generating intermediate cryptogram data corresponding to a cryptogram according to a first cryptographic scheme, the data being suitable for display on a device designed for a second, incompatible cryptographic scheme for generating a password, the method comprising:
generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, 5a when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by said first cryptographic scheme.
According to a further aspect of the present invention there is provided a computer readable medium on which is stored a set of instructions which, when executed by a processor, carry out the method as described herein.
Embodiments of these and other aspects of the invention will now be described in detail with reference to the accompanying drawings, in which:
Figure 3 shows a flowchart of a method according to an embodiment of the invention.
Figure 4 shows a block diagram of a device according to an embodiment of the invention.
We will first describe the MasterCard Chip Authentication Program.
Chip and PIN Cards 'Chip and PIN' cards follow technical standards more formally known as EMV, after Europay, MasterCard and Visa. They are being widely adopted in many countries worldwide, as they offer powerful security features allowing card issuers to control various forms of fraud.
A chip embedded in each EMV card is used to authorise transactions. The authorisation is based on a cryptogram computed using a key unique to the card, together with details of the transaction. The key is embedded into the chip during the issuing process, and a copy retained securely by the issuing bank. The chip also maintains a counter value, known as the Application Transaction Counter (ATC), which is included in the cryptogram computation and incremented with each transaction, as a defence against replay attacks. Finally, the cardholder supplies a PIN, which the chip verifies against a 5b stored reference value, before allowing the cryptogram to be computed.
On receiving a transaction, the issuer is able to re-compute the cryptogram using their copy of the card's key. Since no-one else has the key, a valid cryptogram must originate with the card, and the verification of the PIN by the card demonstrates the card is still in the possession of the original cardholder.
CAP Overview A special class of transactions is known as 'card not present' (CNP) transactions. These include mail order, telephone order and web-based e-commerce transactions. In.
these cases, payment is authorised by the issuing bank based simply on the visible card details such as the card number and expiry date. Since these values are static in nature and easily copied, CNP transactions are an attractive target for fraud.
MasterCard, together with a number of other organisations in the card industry, has developed a standard to allow the security of Chip and PIN cards to be leveraged in CNP scenarios. This scheme is called the Chip Authentication Program (CAP).
CAP requires that each cardholder be issued with a small, hand-held card reader. By inserting their card into their reader, and entering their PIN, the cardholder can generate an OTP based on the key and ATC on the card. The issuer can verify the OTP by re-computing the cryptogram based on the same input data and key.
Note that the card reader is not personal to the cardholder in any way, and does not perform security-critical operations.
EMV CAP OTP Computation Chip and PIN chip-cards were designed for use at point-of-sale payment terminals and ATMs, not specifically for one-time-password generation. CAP readers simulate EMV
payment terminals in their interaction with the card, and the reader is then responsible for taking the payment cryptogram produced by the card and converting it into a one-time-password.
The processing carried out by the CAP reader is specified in detail in [Chip Authentication Program Function Architecture], but in summary it comprises the following stages:
1. Collecting cryptogram input data 2, Extracting OTP data 3. Decimalisation Each step is explained in further detail below.
Collecting Cryptogram Input Data The two principal inputs to the cryptogram computation process are the card key and the ATC. However, with EMV, there are a number of other parameters that are used as inputs into the cryptogram validation. These are specific to card payments, and do not have equivalents in other types of token. In order to reproduce the cryptogram, the validation server must use identical values for these parameters.
In a typical CAP scenario, most of these parameters are either fixed in value when the card is issued, or can be predicted by the validation server. However, a small number of the parameters may change during the card's lifecycle, according to how the card is used. For example, this includes parameters which limit the number or amount of the transactions that the card will authorise off-line. Since the validation server cannot predict these values, they must be transmitted from the card to the server, embedded in the one-time-password itself.
Extracting OTP Data In order to as user-friendly as possible, the one-time-password produced should be as short as possible, whilst maintaining a reasonable level of security. Since the EMV
cryptogram input data, combined with the cryptogram itself, is far too large to be included in the one-time-password in its entirety, it is compressed.
The compression process is defined by a CAP-specific field on the card, known as the Issuer Proprietary Bitmap (IPB), but the process itself is carried out by the card reader.
The IPB defines which bits from the ATC, cryptogram and other EMV input data will be used in the one-time-password¨the other bits are discarded.
Typically, a small number of ATC bits are included, to assist with synchronisation of counter values between server and card, together with at least 16 bits of the cryptogram, and finally those additional cryptogram inputs that cannot be predicted by the server. In some cases, where the card application is used for CAP only and not for payment, it may be that all additional inputs can be predicted by the server and so the OTP is based on the ATC and cryptogram alone.
Decimalisation Finally, the 'binary output from the compression process is decimalised for display to the user on the reader screen. A number of decimalisation schemes are possible, but CAP
defines a single scheme based on simply interpreting the truncation process output as the binary representation of a single integer. Leading zeros are ignored, and so the final length of the OTP can vary.
Next we describe the Open Authentication Standards (OATH).
Overview The Initiative for Open Authentication (OATH) is an industry co-ordinating body seeking to promote the standardisation of the token-based authentication marketplace.
OATH has published a 'reference architecture' describing a vision of a general authentication framework, and is promoting a number of standards for the various interfaces and components within this system.
Most interesting to this application is µHOTP: An HMAC-based one-time-password algorithm', which is being standardised by the IETF as RFC4226 [HOTP: An HMAC-Based One-Time Password Algorithm, httn://www.ietforg/rfc/rfc4226.txt, December 2005].
HOTP Computation As with CAP, the HOTP algorithm is based on an underlying cryptographic primitive, in this case HMAC-SHAL The inputs to this algorithm defined in HOTP are a token key and a counter¨very similar to the basic inputs to an EMV cryptogram computation as used by CAP.
The HOTP computation process is as follows:
1. HIVIAC computation, based on the token key and counter. The counter is then automatically incremented.
2. 'Dynamic Truncation' of the result to give a 31-bit value.
3. Decimalisation of the truncated value, to give the OTP.
Whilst the parallels with the CAP OTP computation are clear, it is important to note that the details of each stage are entirely different. Each step is described and contrasted with its CAP equivalent below, HNIAC Computation The HMAC computation used is as specified in [HMAC: Keyed Hashing for Message Authentication, RFC2104, http://www,ietf org/rfc/rfc2104.txt, February 1997], using SHAl as the underlying hash algorithm [US Secure Hash Algorithm 1 (SHA1), RFC3174, http://www.ietf.org/rfc/rfc3174.txt, September 2001]. The key required by HMAC-SHAl is typically 20 bytes in length, and [HOTP] specifies that an 8-byte counter is used as the only HMAC input data.
The result is a 20-byte binary value, compared to the 8-byte cryptogram used by CAP.
In both cases, a principal objective is that it should not be feasible to recover information about the key from the resulting OTPs. This is the reason why, in both cases, a cryptographic algorithm of some sort is employed.
Dynamic Truncation The truncation process defined by [HOTP] reduces the 20-byte HMAC output to a bit string.
Firstly, the last 4 bits of the last byte of the HMAC output are considered as an integer n in the range 0-15. Then, bytes n, n + 1,..., n + 3 are used as the truncation output (with the leading bit ignored).
The differences with the compression scheme used by CAP are marked:
= The CAP IPB always selects bits from the same position in the EMV
cryptogram for use in the OTP. In OATH, the position of the bits varies, deteimined by the last 4 bits in the HMAC output, hence the term 'dynamic'.
= The cun-ent edition of [HOTPI provides no mechanism for embedding counter synchronisation information in the resulting OTP, whereas the CAP IPB can specify an arbitrary number of ATC bits for inclusion in the OTP.
= The CAP IPB can specify a number of other, EMV-specific data elements for inclusion in the OTP. No such facility is relevant for HOTP.
Decimalisation HOTP decimalisation consists of interpreting the 31-bit output from the dynamic truncation process as the binary representation of an integer, and then reducing that integer modulo 10d, where d is the number of digits desired in the resulting OTP.
In contrast with CAP, if the result has fewer than d digits then leading zeros are inserted to give a total OTP length d.
Note also that this decimalisation process actually performs an additional truncation, in the sense that the output has a smaller information content than the input. In CAP, no information is lost during decimalisation, We will now describe generating OATH OTPs using a CAP Reader. Figure 3 shows an example of a method to achieve this.
We describe a means to generate OATH-compatible OTPs using a standard, unmodified CAP reader, by producing a special OATH chip-card to use within that reader.
This allows an organisation wishing to deploy OATH to deploy low-cost chip-cards instead of higher-cost tokens, exploiting the deployed CAP card-reader infrastructure to use these chip-cards with existing, off-the-shelf OATH validation servers.
Clearly the OATH chip-card reproduces the EMV card interface, or at least those parts of the EMV interface that are used by the CAP reader. Otherwise, the reader would reject the card, The critical card function call is the GENERATE AC call that is used to generate the cryptogram itself. Note that it does not suffice to simply replace the implementation of this function in the card with a function that generates a HOTP hash value, as used in the computation of OATH OTPs. This is because the process of compressing and decimalising the cryptogram to give the OTP is carried out in the reader, and is entirely different between CAP and OATH.
The OATH chip-card therefore implements the following sequence of operations:
1. Generate the HOTP hash value (301), based on the card key and counter, and increment the counter (302).
2. Truncate and decimalise the hash value (303) to produce the OTP itself.
3. Convert the OTP back into a binary format (304), using a process that is the reverse of the decimalisation process employed by a CAP reader.
4. Pad the resulting binary data (305) in a manner that is the reverse of the =
compression process employed by a CAP reader (as defined by the 1PB value on the card).
We call the result an intermediate cryptogram. The OATH chip-card passes this intermediate cryptogram to the CAP reader, as if it were a normal EMV
cryptogram, The CAP reader will then compress and decimalise the data, effectively reversing steps 4 and 3 above, and thus the end result displayed on the reader screen will he the OATH
OTP, as computed by the OATH card at step 2 above. Figure 4 shows a block diagram of an example of a device for an OATH chip-card compatible with CAP readers.
Special Cases A number of special cases arise, which are considered as follows.
Leading Zeros During decimalisation, both CAP and HOT? may result in a decimal result beginning with '0'. CAP specifies that such leading zeros be removed (and so the resulting OTP
may vary in length), whereas HOTP specifies that they be included in the OTP
(which therefore has fixed length).
Note that in CAP, the decimalisation process¨including truncation of leading zeros¨
takes place in the reader. Thus it is not possible to force a CAP reader to display a HOTP OTP that includes leading zeros, regardless of the method used in the chip-card.
We present three possible solutions to this problem:
1. The first possible solution is simple, but unsatisfactory; instruct users to insert additional zeros ahead of the displayed OTP when it is below the expected length.
2. The second possible is to have the authenticating application or validation server insert any missing leading zeros automatically before validating the OTP. This gives a better user experience, but defeats the original objective of implementing OATH using CAP readers without any changes to the validation infrastructure.
3. The third approach is for the OATH chip-card to identify such cases, and when they occur, to automatically discard the OTP (at step 2 above), and generate a new OTP
based on the incremented counter value.
Since the leading digit is effectively random, a long sequence of passwords all beginning with zero is highly unlikely. Moreover, since the validation server in any case accepts a range of counter values in order to avoid synchronisation problems, omitting the occasional password because it begins with a zero does not cause validation to fail, and is unnoticed by the user. Lastly, whilst this technique does reduce the number of possible HOTP outputs by some 10%, a 6-digit minimum length gives at least 1 million possible OTPs and so the overall security offered is still entirely acceptable.
Counter Synchronisation Digits At present HOTP does not specify any means of including counter synchronisation digits in the OTP, whereas CAP offers a flexible scheme, configured using the IPB
embedded in the card, By simply suppressing the CAP synchronisation digits with an appropriate 1PB value, compatibility can be attained.
Consider the possibility that a future version of HOTP may include a means of including counter synchronisation information in the OTP. It is highly likely that the algorithm chosen would not be compatible with that used by CAP, since there is no analogue to the CAP IPB in HOTP. We remark that compatibility can still be obtained, by continuing to suppress the CAP synchronisation information using the IPB
and passing the HOTP synchronisation data from the card to the reader in the intermediate cryptogram, together with the remainder of the OTP.
Now consider the scenario in which the CAP reader includes a mandatory check digit or other synchronisation data, but that HOTP does not. In this case, the reader will receive the cryptogram from the card, and will in addition also receive the ATC value, from which to extract synchronisation data, combining the two to give the displayed OTP. In this case, compatibility can still be maintained, by use of additional card logic. The card should compute the HOTP OTP, and separate it into two parts-----that which the reader will extract from the intermediate cryptogram, and that which the reader will extract from the ATC. The card then provides an intermediate cryptogram and an alternative ATC to the reader, knowing that the reader will combine these to reconstruct the original OTP. The key observation is that the reader has no way of knowing that the value in the alternative ATC is not the same as the counter value used to compute the OTP.
Lastly, note that the scenario in which both HOTP and CAP implement synchronisation schemes, but differently, can be handled by a combination of the above techniques.
Check Digits Check digits are sometimes used to detect errors in data, in particular errors introduced by human transcription. At present, neither CAP nor HOTP includes a check-digit mechanism for the OTPs created, but it is possible that this may change in future.
If a standard CAP reader were required to support a HOTP check digit, this could be achieved by simply embedding the check-digit in the intermediate cryptogram that is passed to the reader, similarly to the technique used to pass synchronisation data discussed above, Alternatively, suppose the CAP reader were to automatically include a check digit in the OTPs, which HOTP did not specify. This would create a more significant problem, since the card would have no means to suppress such a check digit. The only solutions are to modify the application or validation infrastructure to accept HOTP OTPs with CAP check digits appended, or to have the custom card repeatedly generate OTPs until (by luck) an OTP with a correct check digit is found and an appropriate intermediate cryptogram (which does not include the check digit, since it will be added by the reader) computed.
The latter approach would greatly increase the card computation time, since quite a number of OTPs may have to be calculated before a suitable value is found. The card counter would increment far faster than normal, and the tolerance at the validation server may need to be adjusted accordingly. Whilst the increase in card counter required is unpredictable, it is likely that an appropriate balance of system parameters (OTP length, validation server tolerance) can still be found offering acceptable security and reliability as long as the amount of error-checking information inserted by the card reader is not too Large.
Note that this last technique is a repeat of the technique used to handle leading zeros in the HOTP-based OTP. In general: if the HOTP OTP is incompatible with the card reader for whatever reason (in the above examples, because of a leading zero or check digit), it is always possible for the card to simply increment the card counter value until a compatible OTP is found. The applicability of this technique in practice depends on the number and distribution of incompatible OTPs and the validation server parameters.
We have described the specific scenario of a CAP card reader using a special card to achieve OATH compatibility, and alternatives regarding counter synchronisation and check digits. We now list some further possible applications:
Cards may be provided for use with readers designed for any OTP-based system based on a cryptographic engine separate from the user interface, not just CAP.
However, CAP is the most likely system to achieve high volume deployment in the next few years. Cards may be provided for use in any OTP system, not just OATH.
Examples include RSA SecureID, VASCO DigiPass, Secure Computing and ActivIdentity.
Cards may be provided for challenge-response authentication. Cards may be provided for 'short signatures', in which the token produces an OTP based on message data entered by the user (both still including the counter value, and not). Possible applications include where the CAP reader is replaced by a mobile phone (i.e. a mobile phone with a card reader having enough CAP-compatibility to work with the cards). Other applications include where the OATH card is inserted into a card reader which is connected to the user's PC. Further applications include where the OTP is communicated verbally over the telephone, instead of the Internet, or by mail, or by fax, or over an internal network.
No doubt many other effective alternatives will occur to the skilled person.
It will be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the scope of the claims appended hereto.
Claims (21)
1. An apparatus for generating intermediate cryptogram data corresponding to a dynamic password for a first cryptographic scheme, the intermediate cryptogram data being suitable for display using a device designed for a second, incompatible cryptographic scheme for generating a password, the apparatus comprising:
a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by the first cryptographic scheme.
a communications interface for communicating with a said device; and a processor coupled to a memory, the memory storing processor control code to control the processor, when running, to:
generate a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, the intermediate cryptogram data being suitable for outputting to the said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by the first cryptographic scheme.
2. An apparatus according to claim 1, wherein the dynamic password comprises a one-time password.
3. An apparatus according to claim 1 or 2, wherein the first cryptographic scheme comprises an Open Authentication scheme.
4. An apparatus according to claim 1 or 2, wherein the first cryptographic scheme comprises RSA SecureID.
5. An apparatus according to claim 1 or 2, wherein the first cryptographic scheme comprises Vasco Digipass.TM..
6. An apparatus according to any one of claims 1 to 5, wherein the second cryptographic scheme comprises a Chip Authentication Program (CAP) scheme.
7. An apparatus according to any one of claims 1 to 6, wherein code to control the processor to generate intermediate cryptogram data comprises code to:
generate decimal dynamic password data corresponding to said dynamic password;
generate reverse decimal dynamic password data corresponding to said decimal dynamic password data; and pad said reverse decimal dynamic password data to produce said intermediate cryptogram data.
generate decimal dynamic password data corresponding to said dynamic password;
generate reverse decimal dynamic password data corresponding to said decimal dynamic password data; and pad said reverse decimal dynamic password data to produce said intermediate cryptogram data.
8. An apparatus according to claim 7, wherein code to pad said reverse decimal dynamic password data includes code to insert bits according to a CAP Issuer Proprietary Bitmap.
9. An apparatus according to claim 7 or 8, wherein code to pad said reverse decimal dynamic password data includes code to incorporate check digit data corresponding to one or more check digits.
10. An apparatus according to any one of claims 1 to 9, wherein a portion of possible dynamic passwords in the first cryptographic scheme cannot be displayed using the said device, and wherein code to generate a dynamic password comprises code to generate dynamic passwords repeatedly until a dynamic password is found which can be displayed using the said device.
11. An apparatus according to claim 10, wherein said portion of possible dynamic passwords comprises dynamic passwords having leading zeros.
12. An apparatus according to claim 10, wherein the said device, when running, generates a check digit for display, and wherein code to generate dynamic passwords further comprises code to determine the check digit generated by the said device.
13. An apparatus according to any one of claims 1 to 12, wherein the said device is configured to process synchronisation data in addition to said intermediate cryptogram data, and wherein code to generate intermediate cryptogram data further comprises code to generate synchronisation data for outputting to the said device so that, when the said device processes said synchronisation data and said intermediate cryptogram data according to the second cryptographic scheme, the said device generates data suitable for displaying said dynamic password.
14. An apparatus according to claim 13, wherein said synchronisation data comprises an Application Transaction Counter (ATC).
15. An apparatus according to any one of claims 1 to 14, wherein the device comprises a CAP-compatible reader.
16. An integrated circuit including the apparatus of any one of claims 1 to 15.
17. A card carrying the integrated circuit of claim 16.
18. A method of generating intermediate cryptogram data corresponding to a cryptogram according to a first cryptographic scheme, the data being suitable for display on a device designed for a second, incompatible cryptographic scheme for generating a password, the method comprising:
generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by said first cryptographic scheme.
generating a dynamic password according to the first cryptographic scheme; and generate intermediate cryptogram data from said dynamic password, said intermediate cryptogram data being suitable for outputting to a said device so that, when the said device processes said intermediate cryptogram data according to the second cryptographic scheme to generate a password, the said device outputs said dynamic password generated by said first cryptographic scheme.
19. A method according to claim 18, wherein the device comprises a Chip Authentication Program (CAP)-compatible reader.
20. A method according to claim 18 or 19, wherein generating the dynamic password comprises generating a hash-based message authentication code-secure hash algorithm 1 (HMAC-SHA1) cryptogram.
21. A computer readable medium on which is stored a set of instructions which, when executed by a processor, carry out the method of any one of claims 18 to 20.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0703245A GB2442249B (en) | 2007-02-20 | 2007-02-20 | Authentication device and method |
| GB0703245.1 | 2007-02-20 | ||
| PCT/GB2008/050100 WO2008102169A2 (en) | 2007-02-20 | 2008-02-15 | Authentication device and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2678101A1 CA2678101A1 (en) | 2008-08-28 |
| CA2678101C true CA2678101C (en) | 2016-01-26 |
Family
ID=37908926
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2678101A Active CA2678101C (en) | 2007-02-20 | 2008-02-15 | Authentication device and method |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US7882553B2 (en) |
| EP (1) | EP2122527B1 (en) |
| KR (1) | KR101460627B1 (en) |
| CN (1) | CN101632086B (en) |
| AU (1) | AU2008217416B2 (en) |
| BR (1) | BRPI0807776B1 (en) |
| CA (1) | CA2678101C (en) |
| DK (1) | DK2122527T3 (en) |
| ES (1) | ES2558542T3 (en) |
| GB (1) | GB2442249B (en) |
| MX (1) | MX2009008943A (en) |
| PL (1) | PL2122527T3 (en) |
| WO (1) | WO2008102169A2 (en) |
| ZA (1) | ZA200906272B (en) |
Families Citing this family (127)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0204620D0 (en) * | 2002-02-28 | 2002-04-10 | Europay Internat N V | Chip authentication programme |
| US8909557B2 (en) * | 2002-02-28 | 2014-12-09 | Mastercard International Incorporated | Authentication arrangement and method for use with financial transaction |
| US8794532B2 (en) * | 2008-12-29 | 2014-08-05 | Mastercard International Incorporated | Methods and apparatus for use in association with identification token |
| US9449319B1 (en) * | 2008-06-30 | 2016-09-20 | Amazon Technologies, Inc. | Conducting transactions with dynamic passwords |
| US20110029432A1 (en) * | 2009-07-30 | 2011-02-03 | Hildred Richard N | Computer-implemented methods of processing payments for a merchant selling goods or services to a consumer |
| US8572394B2 (en) | 2009-09-04 | 2013-10-29 | Computer Associates Think, Inc. | OTP generation using a camouflaged key |
| US8843757B2 (en) * | 2009-11-12 | 2014-09-23 | Ca, Inc. | One time PIN generation |
| EP2553863A1 (en) * | 2010-03-29 | 2013-02-06 | Intel Corporation | Methods and apparatuses for administrator-driven profile update |
| EP2617156B1 (en) * | 2010-09-13 | 2019-07-03 | CA, Inc. | Methods, apparatus and systems for securing user-associated passwords used for identity authentication |
| CN102592064A (en) * | 2011-01-07 | 2012-07-18 | 深圳同方电子设备有限公司 | Dynamic crypto chip |
| US20120284187A1 (en) * | 2011-03-15 | 2012-11-08 | Ayman Hammad | System and method for processing payment transactions |
| GB201105765D0 (en) | 2011-04-05 | 2011-05-18 | Visa Europe Ltd | Payment system |
| US20140067678A1 (en) * | 2012-09-02 | 2014-03-06 | Mpayme Ltd. | Dispute code system for secure mobile payment |
| EP3910876A1 (en) * | 2013-03-15 | 2021-11-17 | Assa Abloy Ab | Method, system, and device for generating, storing, using, and validating nfc tags and data |
| EP3019992B1 (en) * | 2013-07-08 | 2020-04-29 | Assa Abloy AB | One-time-password generated on reader device using key read from personal security device |
| US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
| CA2931093A1 (en) * | 2013-12-19 | 2015-06-25 | Visa International Service Association | Cloud-based transactions methods and systems |
| US10846694B2 (en) | 2014-05-21 | 2020-11-24 | Visa International Service Association | Offline authentication |
| US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
| CN104135493A (en) * | 2014-08-22 | 2014-11-05 | 上海众人科技有限公司 | File compression method and system |
| WO2016108189A1 (en) * | 2014-12-29 | 2016-07-07 | Visa International Service Association | Authorizing access to an application library |
| CN104539430B (en) * | 2014-12-30 | 2018-11-30 | 飞天诚信科技股份有限公司 | A kind of dynamic password formation method and equipment based on card |
| CA2977428A1 (en) * | 2015-04-13 | 2016-10-20 | Visa International Service Association | Enhanced authentication based on secondary device interactions |
| CN104933797A (en) * | 2015-06-30 | 2015-09-23 | 武汉天喻信息产业股份有限公司 | Intelligent card access control system and method based on dynamic token |
| CN116471105A (en) | 2016-07-11 | 2023-07-21 | 维萨国际服务协会 | Encryption key exchange procedure using access means |
| EP3340149A1 (en) * | 2016-12-22 | 2018-06-27 | Mastercard International Incorporated | Methods and systems for validating an interaction |
| CN107194692B (en) * | 2017-05-27 | 2020-10-13 | 飞天诚信科技股份有限公司 | Method and terminal for acquiring dynamic two-track information |
| US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
| MX2021003217A (en) | 2018-10-02 | 2021-05-12 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards. |
| WO2020072694A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
| US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
| US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
| CA3110521A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10841091B2 (en) | 2018-10-02 | 2020-11-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| JP2022501861A (en) | 2018-10-02 | 2022-01-06 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーCapital One Services, LLC | Systems and methods for cryptographic authentication of non-contact cards |
| US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| CA3115084A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
| CA3108917A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
| US10680824B2 (en) | 2018-10-02 | 2020-06-09 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
| US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
| SG11202102798TA (en) | 2018-10-02 | 2021-04-29 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards |
| CA3115252A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| JP2022508026A (en) | 2018-10-02 | 2022-01-19 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー | Systems and methods for cryptographic authentication of non-contact cards |
| US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| AU2019355110A1 (en) | 2018-10-02 | 2021-04-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US11361302B2 (en) | 2019-01-11 | 2022-06-14 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
| US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
| US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
| US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
| US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
| US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
| US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
| US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
| US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
| US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
| US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
| US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
| US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
| US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
| US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
| US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
| US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
| US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
| US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
| US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
| US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
| US11182771B2 (en) | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
| US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
| US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
| US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
| US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
| US10541995B1 (en) * | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
| JP2023503795A (en) | 2019-10-02 | 2023-02-01 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー | Client Device Authentication Using Contactless Legacy Magnetic Stripe Data |
| US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
| US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
| US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
| US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
| US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
| US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
| US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
| US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
| US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
| US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
| US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
| US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
| US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
| US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
| US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
| US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
| US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
| US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
| US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
| US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
| US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
| US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
| US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
| US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
| US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
| US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
| US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
| US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
| CN112636910B (en) * | 2020-12-29 | 2021-08-24 | 北京深思数盾科技股份有限公司 | Method, device and system for generating and verifying temporary password |
| US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
| US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
| US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
| US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
| US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
| US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
| US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
| US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
| US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
| US11935035B2 (en) | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
| US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
| US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
Family Cites Families (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100213188B1 (en) * | 1996-10-05 | 1999-08-02 | 윤종용 | Apparatus and method for user authentication |
| US6434700B1 (en) * | 1998-12-22 | 2002-08-13 | Cisco Technology, Inc. | Authentication and authorization mechanisms for Fortezza passwords |
| IL128720A (en) * | 1999-02-25 | 2009-06-15 | Cidway Technologies Ltd | Method for certification of over the phone transactions |
| DE19936226A1 (en) | 1999-08-05 | 2001-02-08 | Alcatel Sa | Methods and devices for controlling the access of a user of a user computer to an access computer |
| GB9929291D0 (en) | 1999-12-11 | 2000-02-02 | Connectotel Limited | Strong authentication method using a telecommunications device |
| US7716484B1 (en) * | 2000-03-10 | 2010-05-11 | Rsa Security Inc. | System and method for increasing the security of encrypted secrets and authentication |
| EP1139200A3 (en) | 2000-03-23 | 2002-10-16 | Tradecard Inc. | Access code generating system including smart card and smart card reader |
| GB0119629D0 (en) * | 2001-08-10 | 2001-10-03 | Cryptomathic As | Data certification method and apparatus |
| KR100420600B1 (en) * | 2001-11-02 | 2004-03-02 | 에스케이 텔레콤주식회사 | METHOD FOR PROCESSING EMV PAYMENT BY USING IrFM |
| GB0204620D0 (en) * | 2002-02-28 | 2002-04-10 | Europay Internat N V | Chip authentication programme |
| AU2003230010A1 (en) | 2002-05-10 | 2003-11-11 | Quizid Technologies Ltd. | An authentication token |
| JP2006527430A (en) * | 2003-06-04 | 2006-11-30 | マスターカード インターナショナル インコーポレーテッド | Customer authentication system and method in commercial transactions |
| US7597250B2 (en) * | 2003-11-17 | 2009-10-06 | Dpd Patent Trust Ltd. | RFID reader with multiple interfaces |
| US20060031174A1 (en) * | 2004-07-20 | 2006-02-09 | Scribocel, Inc. | Method of authentication and indentification for computerized and networked systems |
| CA2577333C (en) * | 2004-08-18 | 2016-05-17 | Mastercard International Incorporated | Method and system for authorizing a transaction using a dynamic authorization code |
| WO2006044717A2 (en) * | 2004-10-15 | 2006-04-27 | Verisign, Inc. | One time password |
| US7210166B2 (en) * | 2004-10-16 | 2007-04-24 | Lenovo (Singapore) Pte. Ltd. | Method and system for secure, one-time password override during password-protected system boot |
| WO2006053191A2 (en) * | 2004-11-10 | 2006-05-18 | Mastercard International Incorporated | Method and system for performing a transaction using a dynamic authorization code |
| US7748636B2 (en) * | 2004-11-16 | 2010-07-06 | Dpd Patent Trust Ltd. | Portable identity card reader system for physical and logical access |
| EP1849119B1 (en) * | 2005-02-18 | 2019-07-10 | EMC Corporation | Derivative seeds |
| US8266441B2 (en) * | 2005-04-22 | 2012-09-11 | Bank Of America Corporation | One-time password credit/debit card |
| WO2006119184A2 (en) * | 2005-05-04 | 2006-11-09 | Tricipher, Inc. | Protecting one-time-passwords against man-in-the-middle attacks |
| US20070022196A1 (en) * | 2005-06-29 | 2007-01-25 | Subodh Agrawal | Single token multifactor authentication system and method |
| US8468361B2 (en) * | 2005-09-21 | 2013-06-18 | Broadcom Corporation | System and method for securely provisioning and generating one-time-passwords in a remote device |
| US20070101152A1 (en) * | 2005-10-17 | 2007-05-03 | Saflink Corporation | Token authentication system |
| US7849323B2 (en) * | 2005-11-09 | 2010-12-07 | Emc Corporation | Password presentation for multimedia devices |
| US7347366B2 (en) * | 2006-03-14 | 2008-03-25 | Verisign, Inc. | Method and apparatus to provide authentication using an authentication card |
| US9258124B2 (en) * | 2006-04-21 | 2016-02-09 | Symantec Corporation | Time and event based one time password |
| WO2008008649A2 (en) * | 2006-06-30 | 2008-01-17 | Vonage Network Inc. | Method and apparatus for providing and using a telephone calling card |
| US20080052524A1 (en) * | 2006-08-24 | 2008-02-28 | Yoram Cedar | Reader for one time password generating device |
| US8006300B2 (en) * | 2006-10-24 | 2011-08-23 | Authernative, Inc. | Two-channel challenge-response authentication method in random partial shared secret recognition system |
| US20080114980A1 (en) * | 2006-11-13 | 2008-05-15 | Thangapandi Sridhar | System, method and apparatus for using standard and extended storage devices in two-factor authentication |
| US9251637B2 (en) * | 2006-11-15 | 2016-02-02 | Bank Of America Corporation | Method and apparatus for using at least a portion of a one-time password as a dynamic card verification value |
| CA2569355C (en) * | 2006-11-29 | 2014-10-14 | Diversinet Corp. | System and method for handling permits for user authentication tokens |
| US7930554B2 (en) * | 2007-05-31 | 2011-04-19 | Vasco Data Security,Inc. | Remote authentication and transaction signatures |
| US7849014B2 (en) * | 2007-08-29 | 2010-12-07 | American Express Travel Related Services Company, Inc. | System and method for facilitating a financial transaction with a dynamically generated identifier |
-
2007
- 2007-02-20 GB GB0703245A patent/GB2442249B/en active Active
- 2007-03-06 US US11/682,773 patent/US7882553B2/en active Active
-
2008
- 2008-02-15 CN CN2008800054396A patent/CN101632086B/en active Active
- 2008-02-15 PL PL08709620T patent/PL2122527T3/en unknown
- 2008-02-15 KR KR1020097019620A patent/KR101460627B1/en active IP Right Grant
- 2008-02-15 DK DK08709620.2T patent/DK2122527T3/en active
- 2008-02-15 ES ES08709620.2T patent/ES2558542T3/en active Active
- 2008-02-15 CA CA2678101A patent/CA2678101C/en active Active
- 2008-02-15 AU AU2008217416A patent/AU2008217416B2/en active Active
- 2008-02-15 MX MX2009008943A patent/MX2009008943A/en active IP Right Grant
- 2008-02-15 BR BRPI0807776-2A patent/BRPI0807776B1/en not_active IP Right Cessation
- 2008-02-15 EP EP08709620.2A patent/EP2122527B1/en active Active
- 2008-02-15 WO PCT/GB2008/050100 patent/WO2008102169A2/en active Application Filing
-
2009
- 2009-09-09 ZA ZA2009/06272A patent/ZA200906272B/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| GB0703245D0 (en) | 2007-03-28 |
| EP2122527B1 (en) | 2015-10-21 |
| US7882553B2 (en) | 2011-02-01 |
| PL2122527T3 (en) | 2016-04-29 |
| ZA200906272B (en) | 2011-02-23 |
| WO2008102169A3 (en) | 2008-10-16 |
| US20080201577A1 (en) | 2008-08-21 |
| MX2009008943A (en) | 2010-01-27 |
| CN101632086A (en) | 2010-01-20 |
| BRPI0807776A2 (en) | 2014-06-24 |
| KR101460627B1 (en) | 2014-11-13 |
| GB2442249B (en) | 2008-09-10 |
| DK2122527T3 (en) | 2016-02-01 |
| EP2122527A2 (en) | 2009-11-25 |
| BRPI0807776B1 (en) | 2019-04-24 |
| CN101632086B (en) | 2012-12-19 |
| GB2442249A (en) | 2008-04-02 |
| AU2008217416B2 (en) | 2012-12-06 |
| WO2008102169A2 (en) | 2008-08-28 |
| CA2678101A1 (en) | 2008-08-28 |
| KR20090127282A (en) | 2009-12-10 |
| ES2558542T3 (en) | 2016-02-05 |
| AU2008217416A1 (en) | 2008-08-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2678101C (en) | Authentication device and method | |
| US10803692B2 (en) | System and method for authorizing financial transactions with online merchants | |
| JP4597529B2 (en) | Authentication mechanisms and methods for use in financial transactions | |
| WO2005109360A1 (en) | Secure pin entry using personal computer | |
| US20150317748A1 (en) | Transaction identification and recognition | |
| EP1791291A1 (en) | Personalization of a bankcard for other applications | |
| US6003764A (en) | Method of securely storing and retrieving monetary data | |
| US10657531B1 (en) | Systems and methods for streamlined checkout | |
| RU2644132C2 (en) | Method, system and device for checking validation of transaction process | |
| US20050080677A1 (en) | Real-time entry and verification of PIN at point-of-sale terminal | |
| WO2020174072A1 (en) | Change of reference pin code value of smart card by a mobile device and a distinct telecommunication device | |
| TWM556889U (en) | Transaction key generation and protection system for cloud mobile payment | |
| WO2010030362A1 (en) | Authentication arrangement and method for use with financial transaction | |
| AU1873397A (en) | Method of securely storing and retrieving monetary data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20130118 |