EP4085411A1 - Systems and methods for performing a reissue of a contactless card - Google Patents
Systems and methods for performing a reissue of a contactless cardInfo
- Publication number
- EP4085411A1 EP4085411A1 EP20825352.6A EP20825352A EP4085411A1 EP 4085411 A1 EP4085411 A1 EP 4085411A1 EP 20825352 A EP20825352 A EP 20825352A EP 4085411 A1 EP4085411 A1 EP 4085411A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- card
- pan
- contactless card
- applet
- logic
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 74
- 238000010079 rubber tapping Methods 0.000 claims abstract description 10
- 238000004891 communication Methods 0.000 claims description 89
- 230000015654 memory Effects 0.000 claims description 49
- 230000008859 change Effects 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 19
- 229920002239 polyacrylonitrile Polymers 0.000 claims description 11
- 201000006292 polyarteritis nodosa Diseases 0.000 claims description 11
- 230000005540 biological transmission Effects 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 8
- 230000001010 compromised effect Effects 0.000 abstract description 4
- 230000001960 triggered effect Effects 0.000 abstract 1
- 230000008569 process Effects 0.000 description 30
- 230000004913 activation Effects 0.000 description 14
- 230000005291 magnetic effect Effects 0.000 description 14
- 238000003860 storage Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 10
- 238000012795 verification Methods 0.000 description 10
- 230000009471 action Effects 0.000 description 9
- 238000013478 data encryption standard Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 7
- 238000009795 derivation Methods 0.000 description 6
- 150000001768 cations Chemical class 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000000670 limiting effect Effects 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 239000000758 substrate Substances 0.000 description 3
- KDLHZDBZIXYQEI-UHFFFAOYSA-N Palladium Chemical compound [Pd] KDLHZDBZIXYQEI-UHFFFAOYSA-N 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 229920000642 polymer Polymers 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- FMFKNGWZEQOWNK-UHFFFAOYSA-N 1-butoxypropan-2-yl 2-(2,4,5-trichlorophenoxy)propanoate Chemical compound CCCCOCC(C)OC(=O)C(C)OC1=CC(Cl)=C(Cl)C=C1Cl FMFKNGWZEQOWNK-UHFFFAOYSA-N 0.000 description 1
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 229920001756 Polyvinyl chloride acetate Polymers 0.000 description 1
- RTAQQCXQSZGOHL-UHFFFAOYSA-N Titanium Chemical compound [Ti] RTAQQCXQSZGOHL-UHFFFAOYSA-N 0.000 description 1
- XECAHXYUAAWDEL-UHFFFAOYSA-N acrylonitrile butadiene styrene Chemical compound C=CC=C.C=CC#N.C=CC1=CC=CC=C1 XECAHXYUAAWDEL-UHFFFAOYSA-N 0.000 description 1
- 229920000122 acrylonitrile butadiene styrene Polymers 0.000 description 1
- 239000004676 acrylonitrile butadiene styrene Substances 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 239000003990 capacitor Substances 0.000 description 1
- 229910052799 carbon Inorganic materials 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000005184 irreversible process Methods 0.000 description 1
- 239000010410 layer Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003340 mental effect Effects 0.000 description 1
- 229910052751 metal Inorganic materials 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 150000002739 metals Chemical class 0.000 description 1
- 230000003278 mimic effect Effects 0.000 description 1
- 229910052763 palladium Inorganic materials 0.000 description 1
- 229920003023 plastic Polymers 0.000 description 1
- 239000004033 plastic Substances 0.000 description 1
- 229920000515 polycarbonate Polymers 0.000 description 1
- 239000004417 polycarbonate Substances 0.000 description 1
- 229920000728 polyester Polymers 0.000 description 1
- 239000004800 polyvinyl chloride Substances 0.000 description 1
- 229920000915 polyvinyl chloride Polymers 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 210000001525 retina Anatomy 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 229910052710 silicon Inorganic materials 0.000 description 1
- 239000010703 silicon Substances 0.000 description 1
- 239000002356 single layer Substances 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 229910052719 titanium Inorganic materials 0.000 description 1
- 239000010936 titanium Substances 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- 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/352—Contactless payments by cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
- G06K19/07749—Constructional details, e.g. mounting of circuits in the carrier the record carrier being capable of non-contact communication, e.g. constructional details of the antenna of a non-contact smart card
-
- 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/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- 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/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
-
- 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/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
- G06Q20/1085—Remote banking, e.g. home banking involving automatic teller machines [ATMs]
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
-
- 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
- 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/351—Virtual cards
-
- 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/354—Card activation or deactivation
-
- 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/357—Cards having a plurality of specified features
- G06Q20/3572—Multiple accounts on card
-
- 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/357—Cards having a plurality of specified features
- G06Q20/3574—Multiple applications on card
-
- 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/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
- G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
- G06K19/07701—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising an interface suitable for human interaction
- G06K19/07703—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising an interface suitable for human interaction the interface being visual
- G06K19/07707—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising an interface suitable for human interaction the interface being visual the visual interface being a display, e.g. LCD or electronic ink
Definitions
- the present disclosure relates to authentication and authorization, and more particularly, to system and methods for reissuing or otherwise altering information stored on contactless cards.
- a credit card issuer might respond to such a breach by reissuing the affected cards. This involves assigning new credit card numbers to a user’ s account, generating a new physical card with the new number embossed on it, writing a new magnetic stripe, and placing the card in the mail.
- the breach is widespread (involving a large number of cards), it can take several weeks or months for users to receive their new cards. In the interim, they may not be able to use their account to make payments, since it is likely that the card number was voided at the time the breach was discovered (in order to prevent unauthorized access to the account). Clearly, this can be problematic for a customer.
- the reissue process can also be expensive from the perspective of the card issuer, which often absorbs the cost of generating and mailing the new cards. Depending on the quality of the card stock, it may cost between $2 and $30 to create a new card. If the cards need to be reissued on an expedited basis, the additional processing costs may run to $10 per card. When several million card numbers have been compromised, the resulting reissue cost can run to tens of millions of dollars.
- FIG. 1 A depicts an environment suitable for use with exemplary embodiments.
- FIG. IB depicts an example of a contactless card having a physical token.
- FIG. 1C depicts the structure of an exemplary physical token.
- FIG. 2A depicts an exemplary interface for a mobile application associated with an owner of a contactless card.
- FIG. 2B depicts an exemplary interface when the physical token is read by a reader on the owner’s mobile device.
- FIG. 2C depicts an example of data exchange between a contactless card and a client device.
- FIG. 2D depicts an exemplary data structure suitable for use with exemplary embodiments.
- FIG. 3 is a flowchart illustrating key operations according to an example embodiment.
- FIG. 4 is a diagram of a key system according to an example embodiment.
- FIG. 5 is a flowchart of a method of generating a cryptogram according to an example embodiment.
- FIG. 6A is a flowchart illustrating a process of key diversification according to an example embodiment.
- FIG. 6B is a data flow diagram showing an exchange of communications in an exemplary embodiment.
- FIG. 6C is a flowchart depicting card-side logic for changing an identifier associated with a contactless card.
- FIG. 7 depicts an exemplary computing system suitable for use with exemplary embodiments.
- FIG. 8 depicts an exemplary network environment suitable for use with exemplary embodiments.
- Exemplary embodiments provide techniques for securely reissuing or otherwise altering the information stored on a contactless card based on a remote command. Accordingly, the number associated with the card can be quickly changed so that the card can continue to be used with the new number. If the card has the number printed or embossed on its face, then the printed number (and/or a number stored on a magnetic stripe) may not match the number stored on the contactless chip; nonetheless, the card can be used for contactless payments until a new card with a new number can be issued.
- the card may include an electronic ink (e-ink) display that displays the number; in this case, the e-ink display may also be updated when the number stored on the card’s contactless chip is updated.
- e-ink electronic ink
- the card’s chip may include one or more applets that are activated under certain circumstances. For example, when making a payment with the card, a payment applet may be activated and may supply the card’s number to a requesting device. In order to use the card with a new number, this payment applet may need to be updated, but for security purposes the payment applet may be restricted from communicating directly with an external source.
- the chip may include a second encryption and authorization applet responsible for communicating card information to and from external sources. The second applet may perform authentication and may ensure that information transmitted from the payment applet is done so in a secure way (e.g., using encryption).
- the second applet may also be responsible for performing validation functions (e.g., validating the counter stored on the card), as described in more detail below. According to exemplary embodiments, this second applet may be made to serve as a bridge between the external source and the payment applet, causing the number on the payment applet to be rewritten based on secure, internal (to the chip) communications.
- validation functions e.g., validating the counter stored on the card
- the second applet may be directly instructed to overwrite the card's number with a new number.
- a mobile device running the Android operating system can issue a near field communications (NFC) write command to the second applet to trigger the second applet to issue a rewrite command to the payment applet.
- NFC near field communications
- some devices may not support such communications (Apple’s iOS is one such example).
- the second applet may also or alternatively be configured to recognize a predefined pattern that will cause the rewrite command to be issued. For example, a user may tap their contactless card to an NFC reader five times in less than a minute. Because tapping the card to the NFC reader triggers the authentication and encryption operations of the second applet, the second applet can be preconfigured to recognize this predefined pattern and issue the rewrite command in response.
- the card may have capabilities for limiting the number of rewrites of the number that may be performed (e.g., over the life of the card, or during a particular period of time). To that end, the card may maintain a counter of the number of rewrites, and may further store a value representing a maximum number of allowable rewrites. If a request to rewrite the number is received and the number of total requests (previous and current) exceeds the stored maximum value, the rewrite may be canceled.
- FIG. 1A illustrates a data transmission environment 100 according to an example embodiment.
- system 100 may include contactless card 130, a client device 104, a network 114, and a server 116 maintained by the provider of the contactless card 130.
- FIG. 1A illustrates a particular configuration of components, one of ordinary skill in the art will understand that other configurations including more or fewer components, or components in another configuration, may be used.
- the environment 100 may include one or more contactless cards 130, which are further explained below with reference to FIG. IB.
- a contactless card 130 may be in wireless communication, for example NFC communication, with the client device 104.
- the contactless card may include a contactless chip (see FIG. 1C).
- the contactless chip may maintain a copy of the primary account number (PAN) associated with the card 130, which may be read by a reader (such as the NFC reader 110).
- PAN primary account number
- the environment 100 may include a client device 104, which may be a network- enabled computer.
- a network-enabled computer may include, but is not limited to: e.g., a computer device, or communications device including, e.g., a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device.
- a network-enabled computer may include, but is not limited to: e.g., a computer device, or communications device including, e.g., a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device.
- PC personal computer
- PDA personal digital assistant
- the client device 104 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple’s iOS operating system, any device running Microsoft’s Windows® Mobile operating system, and/or any other smartphone or like wearable mobile device.
- a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple’s iOS operating system, any device running Microsoft’s Windows® Mobile operating system, and/or any other smartphone or like wearable mobile device.
- the client device 104 and/or the contactless card 130 may be associated with a user 102, which may be the owner of the contactless card.
- the user 102 may define credentials for accessing a mobile application on the client device 104, which may be an application associated with a service provider of the contactless card.
- the client device 104 of the environment 100 may execute one or more applications, such as software applications.
- the software applications may enable network communications with one or more components of the environment 100 and may transmit and/or receive data.
- the client device 104 may include client-side reissue logic 112 (such as the logic depicted in more detail in connection with FIG. 6B).
- the client device 104 may be in communication with one or more servers 116 via one or more networks 114.
- the client device 104 and may operate as a front-end to a card provider server 116, which is responsible for maintaining security for the contactless card 130.
- the card provider server 116 may also authorize transactions conducted via the card 130.
- the client device 104 may transmit, for example from a mobile device application executing on client device 104, one or more requests to the server 116.
- the server 116 can communicate with the client device 104 to cause the client device 104 to begin the card reissue process, such as when a data breach occurs.
- the server 116 may instruct the client device 104 to change the PAN associated with the user 102’s card 130.
- the client device 104 may receive the instruction and inform the user 102 (e.g., via a display such as the one depicted in FIGs. 2A-2B) that the card’s number is being reissued.
- the client device 104 may cause one or more applets stored on the card 130 to be activated, such as by an express command (e.g., an NFC write command) or by requesting that the user 102 tap the card 130 against the NFC reader 110 in a predetermined pattern (e.g., a predetermined number of times, a predetermined rate over a period of time, in a predetermined pattern, etc.).
- an express command e.g., an NFC write command
- a predetermined pattern e.g., a predetermined number of times, a predetermined rate over a period of time, in a predetermined pattern, etc.
- the instruction to change the PAN may be sent from the server 116 on an individualized basis (e.g., when a single user 102’s card 130 is compromised), or a reissue instruction may be broadcast to a group of recipients (as might be done in the event of a large data breach).
- the client 104 may issue a change instruction to the card 130 in coordination with the server 116.
- the server 116 may furnish a new PAN to be used on the card 130, which the client 104 may communicate to the communication logic/applet on the card 130.
- the payment logic/applet on the card 130 may be pre-programmed with multiple PANs, and the server 116 may identify which PANs to use (or, if the PANs are arranged in a list in the memory of the card, the server 116 may instruct the payment logic/applet to skip over a certain number of options and select the // th PAN in the list).
- the payment logic/applet may be capable of deriving a new PAN from the old PAN (or another identifier stored on the card, such as an identifier associated with the user 102 or an account of the user at a financial institution), and the server 116 may provide instructions relating to how to derive the new PAN or may provide seed numbers to be used in the generation of the new PAN.
- the write request may include information received from the server (e.g., the new PAN, the number of PANs in the list to skip, the generation technique for deriving the new PAN, or the seed for the new PAN). If the client device 104 cannot issue such a write request, then the card 130 can still coordinate with the server 116, albeit potentially in a more limited way. For example, if the communication logic/applet on the card 130 is configured to recognize a predetermined tapping pattern as an instruction to change the PAN, as noted above, then different patterns may be associated with different change instructions.
- the user taps the card 130 against the NFC reader 110 five times in less than a minute, then this may be interpreted as an instruction to advance to the next PAN stored in the list.
- this may be interpreted as an instruction to jump ahead two PANs in the list.
- the instruction from the server 116 to the client device 104 may identify the particular pattern to be used, and the client device 104 may display an appropriate instruction on a user interface.
- the device 104 may request that the user confirm the pattern to ensure that the correct pattern is used (e.g., by asking the user to tap in the predefined pattern, waiting momentarily, and then asking that the user confirm the change by tapping in the same predefined pattern again).
- the communication logic/applet on the card 130 may report a success back to the server 116.
- the success may identify the new PAN that has been selected (either directly, by reporting the PAN or an encrypted version of the PAN, or indirectly, such as by transmitting a hash of the PAN or subset of the PAN). If the updated PAN does not match the PAN expected by the server 116, then the PAN may be voided and the process may be repeated. Alternatively, the server 116 can simply accept the PAN as reported by the card 130.
- the server 116 may include one or more processors, which are coupled to memory.
- the server 116 may be configured as a central system, server or platform to control and call various data at different times to execute a plurality of workflow actions.
- FIG. IB illustrates one or more contactless cards 130, which may comprise a payment card, such as a credit card, debit card, or gift card, issued by a service provider 132 displayed on the front or back of the card 130.
- the contactless card 130 is not related to a payment card, and may comprise, without limitation, an identification card.
- the payment card may comprise a dual interface contactless payment card.
- the contactless card 130 may comprise a substrate 134, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials.
- Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials.
- the contactless card 130 may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise be compliant with the ISO/IEC 14443 standard. However, it is understood that the contactless card 130 according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card.
- the contactless card 130 may also include identification information 136 displayed on the front and/or back of the card.
- the identification information 136 may be printed or embossed directly on the card.
- an e-ink display 149 (or another type of rewritable display, employing technology such as a liquid crystal diode) may be provided for displaying some or all of the identification information 136.
- the e- ink display 149 may display the card number associated with the card.
- the e-ink display 149 may be powered by a magnetic field, such as a magnetic field emanating from the client device 104.
- the antennae of the card 130 may collect power from the magnetic field and power the e-ink display 149 when the card 130 is in close proximity to the client device 104. This allows the e-ink display 149 to be changed to match the new number provisioned to the applet on the card 130 by the client device 104, as discussed herein.
- the contactless card 130 may further include a contact pad 138.
- the contact pad 138 may be configured to establish contact with another communication device, such as a user device, smart phone, laptop, desktop, or tablet computer.
- the contactless card 130 may also include processing circuitry, antenna and other components not shown in FIG. 1C. These components may be located behind the contact pad 138 or elsewhere on the substrate 134.
- the contactless card 130 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. IB).
- the contact pad 138 of FIG. IB may include processing circuitry 140 for storing and processing information, including a microprocessor 142 and a memory 144. It is understood that the processing circuitry 140 may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anticollision algorithms, controllers, command decoders, security primitives and tamperproofmg hardware, as necessary to perform the functions described herein.
- the memory 144 may be a read-only memory, write-once read-multiple memory or read/write memory, e.g., RAM, ROM, and EEPROM, and the contactless card 500 may include one or more of these memories.
- a read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once then read many times.
- a write once/read-multiple memory may be programmed at a point in time after the memory chip has left the factory. Once the memory is programmed, it may not be rewritten, but it may be read many times.
- a read/write memory may be programmed and re-programed many times after leaving the factory. It may also be read many times.
- the memory 144 may be configured to store one or more applets 146, one or more counters 108, and a customer identifier 148.
- the one or more applets 146 may comprise one or more software applications configured to execute on one or more contactless cards, such as Java Card applet. However, it is understood that applets 146 are not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory.
- the one or more counters 108 may comprise a numeric counter sufficient to store an integer.
- the customer identifier 148 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 130, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 148 may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer’s account.
- the applets 146 may include a payment applet configured to conduct payment transactions with the card 130.
- the payment applet may be responsible for maintaining, or may make use of, the card’s Primary Account Number (PAN), which may be communicated from the card as part of a transaction.
- PAN Primary Account Number
- the applets 146 may further include an authentication and/or encryption applet that is invoked when an outside source (such as the client device 104, a point of sale terminal, an automatic teller machine, etc.) attempts to establish communication with the card 130 (such as when the contact pad 138 is placed against, or in proximity to, a reader such as the NFC reader 110).
- an outside source such as the client device 104, a point of sale terminal, an automatic teller machine, etc.
- the payment applet may not communicate directly with outside sources (i.e., sources external to the processing circuitry 140), but may be capable of securely communicating with another applet on the processing circuitry 140, such as the authentication and encryption applet. Information may be passed from the payment applet to the authentication and encryption applet for communication off-card.
- the payment applet may come pre-loaded (e.g., at the time the card is issued) with predefined PANs, one of which is designated as the currently active PAN and the remainder of which are held in reserve.
- the applet may select the next PAN in the list and designate it as the active PAN.
- the applet may randomly generate a new PAN in accordance with PAN generation rules, or may generate a new PAN based off of the previous PAN.
- processor and memory elements of the foregoing exemplary embodiments are described with reference to the contact pad, but the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of the pad 138 or entirely separate from it, or as further elements in addition to processor 142 and memory 144 elements located within the contact pad 138.
- the contactless card 130 may comprise one or more antennas 150.
- the one or more antennas 150 may be placed within the contactless card 130 and around the processing circuitry 140 of the contact pad 138.
- the one or more antennas 150 may be integral with the processing circuitry 140 and the one or more antennas 150 may be used with an external booster coil.
- the one or more antennas 150 may be external to the contact pad 138 and the processing circuitry 142.
- the coil of contactless card 130 may act as the secondary of an air core transformer.
- the terminal may communicate with the contactless card 130 by cutting power or amplitude modulation.
- the contactless card 130 may infer the data transmitted from the terminal using the gaps in the contactless card’s power connection, which may be functionally maintained through one or more capacitors.
- the contactless card 130 may communicate back by switching a load on the contactless card’s coil or load modulation. Load modulation may be detected in the terminal’s coil through interference.
- the contactless cards 130 may be built on a software platform operable on smart cards or other devices having limited memory, such as JavaCard, and one or more or more applications or applets may be securely executed. Applets may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets may be configured to respond to one or more requests, such as near field data exchange (NDEF) requests, from a reader, such as a mobile NFC reader, and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag.
- NDEF near field data exchange
- exemplary transactions may validate a transaction requested of an account associated with the contactless card via the logic 112 executing on the client device 104.
- Figures 2A-2B depict exemplary interfaces that may be presented on the client device 104 in response to the logic.
- FIG. 2A depicts an initial interface 200 for an application associated with the card (e.g., an application provided by the card provider), which may be displayed on the client device 104 when the client device 104 receives an instruction from the server 116 to reissue the card or otherwise reprovision or alter the information stored on the card.
- the interface 200 includes a message area 202 that displays information about the reissuance of the card information. This message area 202 may explain, for example, that the user’s card has been reissued, why the reissue has occurred, and the next steps required for the user to change the card’s information.
- the interface 200 may further include an interactable element 204.
- the user may optionally first be required to select the interactable element 204 in order to verify the user’s desire to reissue the card number (so that the user does not accidentally overwrite the card information by placing the card in proximity with the NFC reader).
- the user can rewrite the PAN or other information stored on the card 130 by bringing the contact pad 138 of the card’s chip in proximity to the device 104’s NFC reader, as shown in FIG. 2B.
- a confirmation message 206 may be displayed indicating that the card’s information has been successfully rewritten.
- the user may be prompted (in the interface 200) to tap their card on the client device’s NFC reader in a predetermined pattern.
- the authentication and encryption applet may register the predetermined pattern
- FIGs. 2A-2B depict the card 130 being rewritten when brought into proximity with a mobile client device 104, it is also contemplated that the card could be rewritten by an automated teller machine, point of sale terminal, or any other device having a suitable transmitter (e.g., an NFC transmitter) for communicating with the contact pad 138.
- a suitable transmitter e.g., an NFC transmitter
- the new card number may not match the number printed or embossed on the card, or the information stored on the card’s magnetic stripe.
- the card includes an e-ink display, as noted above, the e-ink display may be updated at the time the PAN is rewritten in order to reflect the new card number. In this case, it may not be necessary to reissue the physical card, especially if the card does not include a magnetic stripe or if the user primarily uses the card to make contactless payments.
- FIG. 2C is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure.
- a system may include a contactless card 130 and a client device 104, which may include an application (which may include the logic 112) and a processor.
- the application communicates with the contactless card 130 (e.g., after being brought near the contactless card 130). Communication between the application and the contactless card 130 may involve the contactless card 130 being sufficiently close to a card reader (not shown) of the client device 104 to enable NFC data transfer between the application and the contactless card 130.
- the contactless card 130 After communication has been established between client device 104 and contactless card 130, the contactless card 130 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 130 is read by an application hosting the logic 112. In particular, this may occur upon a read, such as an NFC read, of a near field data exchange (NDEF) tag, which may be created in accordance with the NFC Data Exchange Format. For example, a reader, such as the logic 112, may transmit a message, such as an applet select message, with the applet ID of an NDEF producing applet. Upon confirmation of the selection, a sequence of select file messages followed by read file messages may be transmitted.
- a message authentication code (MAC) cryptogram In some examples, this may occur when the contactless card 130 is read by an application hosting the logic 112. In particular, this may occur upon a read, such as an NFC read, of a near field data exchange (NDEF) tag, which may be created in accordance with the NFC Data Exchange Format. For
- the sequence may include “Select Capabilities file”, “Read Capabilities file”, and “Select NDEF file”.
- a counter value maintained by the contactless card 130 may be updated or incremented, which may be followed by “Read NDEF file.”
- the message may be generated which may include a header and a shared secret. Session keys may then be generated.
- the MAC cryptogram may be created from the message, which may include the header and the shared secret.
- the MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with the session key. Thereafter, the cryptogram and the header may be concatenated, and encoded as ASCII hex and returned in NDEF message format (responsive to the “Read NDEF file” message).
- the MAC cryptogram may be transmitted as an NDEF tag, and in other examples the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string).
- the logic 112 may be configured to transmit a request to the contactless card 130, the request comprising an instruction to generate a MAC cryptogram.
- the contactless card 130 sends the MAC cryptogram to the logic 112.
- the transmission of the MAC cryptogram occurs via NFC, however, the present disclosure is not limited thereto.
- this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication.
- the logic 112 communicates the MAC cryptogram to the processor.
- the processor verifies the MAC cryptogram pursuant to an instruction from the logic 112. For example, the MAC cryptogram may be verified, as explained below.
- verifying the MAC cryptogram may be performed by a device other than client device 104, such as a server 116 in data communication with the client device 104.
- the processor may output the MAC cryptogram for transmission to the server 116, which may verify the MAC cryptogram.
- the MAC cryptogram may function as a digital signature for purposes of verification.
- Other digital signature algorithms such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero knowledge protocols, may be used to perform this verification.
- FIG. 2D depicts an exemplary technique for generating a protected message 230 in accordance with exemplary embodiments.
- the message 230 may be configured to deliver information or content from a sender to a recipient. This information or content may be represented by message plaintext 234 (although the content may optionally be encrypted).
- the message plaintext 234 may be combined with a shared secret 232.
- the shared secret 232 may be a random number known to both the sender and the recipient. For instance, if the message plaintext 234 relates to an authentication action for a contactless card as described above, the process of setting up or initializing the card may involve sharing a random number between the chip on the card and the transaction validation server. In one embodiment, the random number may be a 32-bit random number.
- a communication session may be set up by the sender and recipient; the process of setting up the communication session may involve sharing a random number between the sender and recipient, and the random number may be used as the shared secret 232.
- the message plaintext 234 and the shared secret 232 may be combined in various ways.
- the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232.
- the resulting product may then be applied to the MAC algorithm.
- the recipient retrieves the combined MAC data
- the recipient may consult its version of the shared secret 232 and may reverse the process used to combine the MAC data with the shared secret (e.g., dividing the combined MAC data and the shared secret 232 to retrieve the original MAC data).
- the MAC algorithm 236 may be any suitable MAC algorithm, such as the data authentication algorithm (DAA), cipher block chaining message authentication codes (CBC-MAC), Galois message authentication code (GMAC), and hashed message authentication code (HMAC), among many others.
- DAA data authentication algorithm
- CBC-MAC cipher block chaining message authentication codes
- GMAC Galois message authentication code
- HMAC hashed message authentication code
- the MAC algorithm 236 may operate using a key.
- this key may be a first diversified key 250 created using a diversification algorithm 248.
- the diversification algorithm may operate on the counter 108 received from the contactless card and a first master key 244 stored on the contactless card (described in more detail below) to generate the first diversified key 250.
- the MAC algorithm 236 may generate MAC output 238.
- the MAC output 238 may optionally be encrypted by an encryption algorithm 240 to generate an encrypted MAC 242.
- the encryption algorithm 240 may be any suitable encryption algorithm, such as data encryption standard (DES), TripleDES (3DES), advanced encryption standard (AES), and RSA, among many others.
- the MAC output 238 may be truncated and/or combined with random data 254. For instance, in one embodiment, the beginning of the MAC output 238 may be discarded, so that (e.g.) only the last 8 bytes are preserved. The remaining portion of the MAC output 238 may be combined with 8 bytes of randomly generated data 254.
- the recipient may decrypt the encrypted MAC 242 and discard the random data. The recipient may calculate its own version of the MAC, as described below, and may compare the last 8 bytes of the recipient-generated MAC to the data remaining from the encrypted MAC 242 received as part of the message 230.
- the encryption algorithm 240 may operate using a key.
- this key may be a second diversified key 252 created using the diversification algorithm 248.
- the diversification algorithm may operate on the counter 108 received from the contactless card and a second master key 246 stored on the contactless card (described in more detail below) to generate the second diversified key 252.
- the encryption algorithm 240 may generate an encrypted MAC 232, which may be included in a header of the message 230.
- the encrypted MAC 232 may be transmitted along with the message plaintext 234.
- the counter value 108 may optionally be transmitted as part of the message plaintext 234, and may be consulted by the recipient (e.g., the server) in authenticating the message.
- the shared secret 232 is not directly sent as part of the message.
- FIG. 3 is a flowchart illustrating key operations 300 according to an example embodiment.
- two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card.
- UDKs unique derived keys
- a bank identifier number may comprise one number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification.
- the UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.
- the counter may be used as the diversification data, since it changes with each use and provides a different session key each time, as opposed to the master key derivation in which one unique set of keys per card is produced.
- two session keys may be created for each transaction from the UDKs, i.e., one session key from AUTKEY and one session key from ENCKEY.
- the MAC key i.e., the session key created from AUTKEY
- the low order of two bytes of the OTP counter may be used for diversification.
- the ENC key i.e., the session key created from ENCKEY
- the full length of the OTP counter may be used for the ENC key.
- the MAC key may be used for preparing the MAC cryptogram, and the ENC key may be used to encrypt the cryptogram.
- the MAC session key may be used to prepare the cryptogram, and the result may be encrypted with the ENC key before it is transmitted to the one or more servers.
- the session keys are independently derived at the one or more servers, resulting in a first session key (the ENC session key) and a second session key (the MAC session key).
- the second derived key i.e., the ENC session key
- the first derived key i.e., the MAC session key
- a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card.
- the key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card.
- these diversified keys may comprise a first key and a second key.
- the first key may include an authentication master key (Card Cryptogram Generation/Authenti cation Key - Card-Key -Auth), and may be further diversified to create a MAC session key used when generating and verifying a MAC cryptogram.
- the second key may comprise an encryption master key (Card Data Encryption Key - Card-Key-DEK), and may be further diversified to create an ENC session key used when encrypting and decrypting enciphered data.
- the first and the second keys may be created by diversifying the issuer master keys by combining them with the card’s unique ID number (pUID) and the PAN sequence number (PSN) of a payment applet.
- the pUID may comprise a 16-digit numerical value. As explained above, pUID may comprise a 16 digit BCD encoded number. In some examples, pUID may comprise a 14-digit numerical value.
- the counter such as the full 32-bit counter may be added to the initialization arrays of the diversification method.
- a number such as an account number or an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification.
- FIG. 4 illustrates a diagram of a system 400 configured to implement one or more embodiments of the present disclosure.
- the cryptographic keys may comprise symmetric keys which may be used in both encryption and decryption of data.
- Triple DES (3DES) algorithm may be used by EMV and it is implemented by hardware in the contactless card.
- EMV encryption and decryption of data
- DES Triple DES
- one or more keys may be derived from a master key based upon uniquely identifiable information for each entity that requires a key.
- two issuer master keys 405, 410 may be required for each part of the portfolio on which the one or more applets is issued.
- the first master key 405 may comprise an Issuer Cryptogram Generation/ Authentication Key (Iss-Key- Auth) and the second master key 410 may comprise an Issuer Data Encryption Key (Iss-Key- DEK).
- issuer master keys 405, 410 are diversified into card master keys 425, 430, which are unique for each card.
- a network profile record ID (pNPR) 415 and derivation key index (pDKI) 420 as back office data, may be used to identify which Issuer Master Keys 405, 410 to use in the cryptographic processes for authentication.
- the system performing the authentication may be configured to retrieve values of pNPR 415 and pDKI 420 for a contactless card at the time of authentication.
- a session key may be derived (such as a unique key per session) but rather than using the master key, the unique card-derived keys and the counter may be used as diversification data, as explained above. For example, each time the card is used in operation, a different key may be used for creating the message authentication code (MAC) and for performing the encryption.
- the keys used to generate the cryptogram and encipher the data in the one or more applets may comprise session keys based on the card unique keys (Card-Key-Auth 425 and Card-Key-Dek 430).
- the session keys may be generated by the one or more applets and derived by using the application transaction counter (pATC) 445 with one or more algorithms. To fit data into the one or more algorithms, only the 2 low order bytes of the 4-byte pATC 445 is used.
- FI : PATC(lower 2 bytes)
- SK : ⁇ (ALG (MK) [FI] ) II ALG (MK) [F2] ⁇ , where ALG may include 3DES ECB and MK may include the card unique derived master key.
- one or more MAC session keys may be derived using the lower two bytes of pATC 445 counter.
- pATC 445 is configured to be updated, and the card master keys Card-Key- AUTH 425 and Card-Key -DEK 430 are further diversified into the session keys Aut-Session-Key 435 and DEK-Session-KEY 440.
- pATC 445 may be initialized to zero at personalization or applet initialization time.
- the pATC counter 445 may be initialized at or before personalization, and may be configured to increment by one at each NDEF read.
- the update for each card may be unique, and assigned either by personalization, or algorithmically assigned by pUID or other identifying information. For example, odd numbered cards may increment or decrement by 2 and even numbered cards may increment or decrement by 5. In some examples, the update may also vary in sequential reads, such that one card may increment in sequence by 1, 3, 5, 2, 2, ... repeating.
- the specific sequence or algorithmic sequence may be defined at personalization time, or from one or more processes derived from unique identifiers. This can make it harder for a replay attacker to generalize from a small number of card instances.
- the authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format.
- the random number may precede cryptogram A and may be one block long. In other examples, there may be no restriction on the length of the random number.
- the total data i.e., the random number plus the cryptogram
- the total data may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block produced by the MAC algorithm. As another example, if the algorithms employed used 16-byte blocks, even multiples of that block size may be used, or the output may be automatically, or manually, padded to a multiple of that block size.
- the MAC may be performed by a function key (AUT-Sessi on-Key) 435.
- the data specified in cryptogram may be processed with javacard. signature method: ALG_DES_MAC8_IS09797_1_M2_ALG3 to correlate to EMV ARQC verification methods.
- the key used for this computation may comprise a session key AUT-Session-Key 435, as explained above.
- the low order two bytes of the counter may be used to diversify for the one or more MAC session keys.
- AUT-Session-Key 435 may be used to MAC data 450, and the resulting data or cryptogram A 455 and random number RND may be encrypted using DEK-Session-Key 440 to create cryptogram B or output 460 sent in the message.
- one or more HSM commands may be processed for decrypting such that the final 16 (binary, 32 hex) bytes may comprise a 3DES symmetric encrypting using CBC mode with a zero IV of the random number followed by MAC authentication data.
- the key used for this encryption may comprise a session key DEK-Session-Key 440 derived from the Card-Key-DEK 430.
- the ATC value for the session key derivation is the least significant byte of the counter pATC 445.
- the format below represents a binary version example embodiment.
- the first byte may be set to ASCII ‘A’.
- the tag may be encoded in hexadecimal format.
- the UID field of the received message may be extracted to derive, from master keys Iss-Key-AUTH 405 and Iss-Key-DEK 410, the card master keys (Card-Key- Auth 425 and Card-Key-DEK 430) for that particular card.
- the counter (pATC) field of the received message may be used to derive the session keys (Aut-Sessi on-Key 435 and DEK-Sessi on-Key 440) for that particular card.
- Cryptogram B 460 may be decrypted using the DEK-Session-KEY, which yields cryptogram A 455 and RND, and RND may be discarded.
- the UID field may be used to look up the shared secret of the contactless card which, along with the Ver, UID, and pATC fields of the message, may be processed through the cryptographic MAC using the re-created Aut- Session-Key to create a MAC output, such as MAC’. If MAC’ is the same as cryptogram A 955, then this indicates that the message decryption and MAC checking have all passed. Then the pATC may be read to determine if it is valid.
- one or more cryptograms may be generated by the one or more applications.
- the one or more cryptograms may be generated as a 3DES MAC using ISO 9797-1 Algorithm 3 with Method 2 padding via one or more session keys, such as Aut-Session-Key 435.
- the input data 450 may take the following form: Version (2), pUID (8), pATC (4), Shared Secret (4).
- the numbers in the brackets may comprise length in bytes.
- the shared secret may be generated by one or more random number generators which may be configured to ensure, through one or more secure processes, that the random number is unpredictable.
- the shared secret may comprise a random 4-byte binary number injected into the card at personalization time that is known by the authentication service. During an authentication session, the shared secret may not be provided from the one or more applets to the mobile application.
- Method 2 padding may include adding a mandatory 0x’80’ byte to the end of input data and Ox’OO’ bytes that may be added to the end of the resulting data up to the 8-byte boundary.
- the resulting cryptogram may comprise 8 bytes in length.
- one benefit of encrypting an unshared random number as the first block with the MAC cryptogram is that it acts as an initialization vector while using CBC (Block chaining) mode of the symmetric encryption algorithm. This allows the “scrambling” from block to block without having to pre-establish either a fixed or dynamic IV.
- CBC Block chaining
- the authentication service may be configured to determine if the value conveyed in the clear data has been tampered with. Moreover, by including the version in the one or more cryptograms, it is difficult for an attacker to purposefully misrepresent the application version in an attempt to downgrade the strength of the cryptographic solution.
- the pATC may start at zero and be updated by 1 each time the one or more applications generates authentication data.
- the authentication service may be configured to track the pATCs used during authentication sessions.
- the authentication data when the authentication data uses a pATC equal to or lower than the previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authenticated may be rejected. In some examples, where the pATC is greater than the previous value received, this may be evaluated to determine if it is within an acceptable range or threshold, and if it exceeds or is outside the range or threshold, verification may be deemed to have failed or be unreliable.
- data 450 is processed through the MAC using Aut-Session-Key 435 to produce MAC output (cryptogram A) 455, which is encrypted.
- data or cryptogram A 455 to be included in the ciphertext may comprise: Random number (8), cryptogram (8).
- the numbers in the brackets may comprise length in bytes.
- the random number may be generated by one or more random number generators which may be configured to ensure, through one or more secure processes, that the random number is unpredictable.
- the key used to encipher this data may comprise a session key.
- the session key may comprise DEK-Session-Key 440.
- data or cryptogram A 455 and RND are processed using DEK-Session-Key 440 to produce encrypted data, cryptogram B 460.
- the data 455 may be enciphered using 3DES in cipher block chaining mode to ensure that an attacker must run any attacks over all of the ciphertext.
- other algorithms such as Advanced Encryption Standard (AES)
- AES Advanced Encryption Standard
- an initialization vector of Ox’ 0000000000000000’ may be used. Any attacker seeking to brute force the key used for enciphering this data will be unable to determine when the correct key has been used, as correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.
- the authentication service In order for the authentication service to validate the one or more cryptograms provided by the one or more applets, the following data must be conveyed from the one or more applets to the mobile device in the clear during an authentication session: version number to determine the cryptographic approach used and message format for validation of the cryptogram, which enables the approach to change in the future; pUID to retrieve cryptographic assets, and derive the card keys; and pATC to derive the session key used for the cryptogram.
- FIG. 5 illustrates a method 500 for generating a cryptogram.
- a network profile record ID (pNPR) and derivation key index (pDKI) may be used to identify which Issuer Master Keys to use in the cryptographic processes for authentication.
- the method may include performing the authentication to retrieve values of pNPR and pDKI for a contactless card at the time of authentication.
- Issuer Master Keys may be diversified by combining them with the card’ s unique ID number (pUID) and the PAN sequence number (PSN) of one or more applets, for example, a payment applet.
- pUID unique ID number
- PAN PAN sequence number
- Card-Key-Auth and Card-Key-DEK unique card keys
- the keys used to generate the cryptogram and encipher the data in the one or more applets may comprise the session keys of block 530 based on the card unique keys (Card-Key-Auth and Card-Key-DEK).
- these session keys may be generated by the one or more applets and derived by using pATC, resulting in session keys Aut-Session- Key and DEK-Session-Key.
- FIG. 6 depicts an exemplary process 600 illustrating key diversification according to one example.
- a sender and the recipient may be provisioned with two different master keys.
- a first master key may comprise the data encryption master key
- a second master key may comprise the data integrity master key.
- the sender has a counter value, which may be updated at block 602, and other data, such as data to be protected, which it may securely share with the recipient.
- the counter value may be encrypted by the sender using the data encryption master key to produce the data encryption derived session key, and the counter value may also be encrypted by the sender using the data integrity master key to produce the data integrity derived session key. In some examples, a whole counter value or a portion of the counter value may be used during both encryptions.
- the counter value may not be encrypted.
- the counter may be transmitted between the sender and the recipient in the clear, i.e., without encryption.
- the data to be protected is processed with a cryptographic MAC operation by the sender using the data integrity session key and a cryptographic MAC algorithm.
- the protected data including plaintext and shared secret, may be used to produce a MAC using one of the session keys (AUT-Session-Key).
- the data to be protected may be encrypted by the sender using the data encryption derived session key in conjunction with a symmetric encryption algorithm.
- the MAC is combined with an equal amount of random data, for example each 8 bytes long, and then encrypted using the second session key (DEK-Session-Key).
- the encrypted MAC is transmitted, from the sender to the recipient, with sufficient information to identify additional secret information (such as shared secret, master keys, etc.), for verification of the cryptogram.
- additional secret information such as shared secret, master keys, etc.
- the recipient uses the received counter value to independently derive the two derived session keys from the two master keys as explained above.
- the data encryption derived session key is used in conjunction with the symmetric decryption operation to decrypt the protected data. Additional processing on the exchanged data will then occur.
- the MAC is extracted, it is desirable to reproduce and match the MAC. For example, when verifying the cryptogram, it may be decrypted using appropriately generated session keys. The protected data may be reconstructed for verification. A MAC operation may be performed using an appropriately generated session key to determine if it matches the decrypted MAC. As the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from source data.
- the data integrity derived session key is used in conjunction with the cryptographic MAC operation to verify that the protected data has not been modified.
- Some examples of the methods described herein may advantageously confirm when a successful authentication is determined when the following conditions are met.
- the ability to verify the MAC shows that the derived session key was proper.
- the MAC may only be correct if the decryption was successful and yielded the proper MAC value.
- the successful decryption may show that the correctly derived encryption key was used to decrypt the encrypted MAC.
- the derived session keys are created using the master keys known only to the sender (e.g., the transmitting device) and recipient (e.g., the receiving device), it may be trusted that the contactless card which originally created the MAC and encrypted the MAC is indeed authentic.
- the counter value used to derive the first and second session keys may be shown to be valid and may be used to perform authentication operations.
- the two derived session keys may be discarded, and the next iteration of data exchange will update the counter value (returning to block 602) and a new set of session keys may be created (at block 604).
- the combined random data may be discarded.
- FIG. 6B depicts a timing diagram showing an exemplary exchange of messages according to an embodiment.
- Figure 6C depicts an exemplary flow chart showing logic 650 performed by the applets, logic, or programs on the card 130, and is discussed in parallel with FIG. 6B.
- the payment/transaction applet may, at block 652, store one or more PANs for the card. The PANs may be written to the card when the card is initially issued. In some embodiments, only one PAN is issued to the card, and the payment/transaction applet maintains the PAN or accesses it in a defined location in memory.
- the payment/transaction applet may be capable of writing or rewriting the PAN, and may do so when a new PAN is called for.
- multiple PANs may be issued to the card, and may be stored in a list.
- One PAN (such as the first PAN in the list) may be designated as the active PAN to be used for payments and transactions.
- the old PAN may be deleted and the next PAN in the list may become the active PAN; alternatively or in addition, a different PAN in the list may be designated as the current PAN.
- the reissue process may begin when the server 116 transmits a reissue message 620 to a client 104.
- the reissue message may be a message indicating that a particular card belonging to an account holder associated with the client device 104 should have its identifier/PAN reissued, altered, or otherwise changed.
- the account holder may be associated to the client device 104 by virtue of installing an application on the client device 104 belonging to the card issuer (which may also maintain the server 116).
- the user may install an application that allows the user to review their outstanding balance, make payments, etc., and the user’s particular cards may be associated with the application based on the account/card number(s) assigned to the user.
- the application may communicate with the server 116 and may register the device 104 with the server.
- the user may log into their account with the card provider through the application and thereby associate their account with the device 104.
- the application may also communicate with the user’s card 130, and thereby establish a communication link from the server 116 to the card 130.
- the server 116 may contact the user’s application on the device 104 to achieve this.
- the user’s old number or identifier may be voided before, during, or after sending the reissue message 620.
- the application on the client 104 may recognize that the PAN must be reissued.
- the application may be programmed with multiple techniques for communicating this information to the communication/authentication applet on the card in a reissue instruction or tap pattern 622.
- One technique may involve issuing an NFC write command (or another suitable command using a different communication protocol) to the communication/authentication applet on the card 130.
- the NFC write command may identify that the card number or identifier is to be changed.
- This technique may be suitable for devices, such as those running the Android operating system, that are capable of issuing an NFC write command directly to the applets on the card.
- the application may be programmed with logic configured to cause a display device to present instructions to the user requesting that the user tap their card 130 to the NFC reader on the device 104 in a predetermined pattern.
- This logic may have a counterpart on the communication/authentication applet, which is configured to recognize the predetermined pattern and interpret this pattern as an instruction to reissue the PAN or identification number.
- the communication/authenti cation applet on the card recognizes the instruction or pattern 622 and initiates a card change process (block 654 of FIG. 6C).
- the communication/authenti cation applet sets up a secure communication channel or secure form of data transmission between the communication/authentication applet and payment/transaction applet at 626 (block 656 of FIG. 6C).
- This communication channel may be built into the chip on the card 130 such that an express setup procedure is not required, or may be an ad hoc communication channel or data transmission form that is set up on an as- needed basis.
- the communication/authentication applet may transmit a reissue command 628 to the payment/transaction applet over the secure communication channel (block 658 in FIG. 6C).
- the payment/transaction applet may, at 630 (block 660 of FIG. 6C), select a new identifier or PAN (e.g., advancing to the next PAN in a list, generating an entirely new PAN from scratch, deriving a new PAN from the old PAN and/or other information stored on the card, etc.).
- the process for selecting the new identifier or PAN may be coordinated with the server 116, as previously discussed.
- the payment/transaction applet may determine if the change in the identifier or PAN was successful (e.g., a new PAN meeting certain predefined requirements has been generated). If there was a problem in the process, or if the new PAN could not be validated according to the requirements, the payment/transaction applet may report a failure to the communication/authenti cation applet (block 652 of FIG 6C).
- the card’s chip may optionally be de-authorized for performing transactions at this point.
- the payment/transaction applet may confirm 632 the success to the communication/authentication applet, which may relay that confirmation back towards the server 116 (block 652 of FIG. 6C).
- the card includes a rewritable display such as an e-ink display
- the communication/authentication applet may cause the display to be rewritten with the new card identifier (see block 654 of FIG. 6C).
- the card may remain in the magnetic field caused by the communication with the device 104 during this process, so that the energy from the communication can be used to update the display.
- Example embodiments of systems and methods described herein may be configured to provide security factor authentication.
- the security factor authentication may comprise a plurality of processes.
- a first process may comprise logging in and validating a user via one or more applications executing on a device.
- the user may, responsive to successful login and validation of the first process via the one or more applications, engage in one or more behaviors associated with one or more contactless cards.
- the security factor authentication may include both securely proving identity of the user and engaging in one or more types of behaviors, including but not limited to one or more tap gestures, associated with the contactless card.
- the one or more tap gestures may comprise a tap of the contactless card by the user to a device.
- the device may comprise a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process a received tap gesture.
- the contactless card may be tapped to a device, such as one or more computer kiosks or terminals, to verify identity so as to receive a transactional item responsive to a purchase, such as a coffee.
- a secure method of proving identity in a loyalty program may be established. Securely proving the identity, for example, to obtain a reward, coupon, offer, or the like or receipt of a benefit is established in a manner that is different than merely scanning a bar card.
- an encrypted transaction may occur between the contactless card and the device, which may configured to process one or more tap gestures.
- the one or more applications may be configured to validate identity of the user and then cause the user to act or respond to it, for example, via one or more tap gestures.
- data for example, bonus points, loyalty points, reward points, healthcare information, etc., may be written back to the contactless card.
- the contactless card may be tapped to a device, such as a mobile device.
- identity of the user may be verified by the one or more applications which would then grant the user a desired benefit based on verification of the identity.
- the contactless card may be activated by tapping to a device, such as a mobile device.
- the contactless card may communicate with an application of the device via a card reader of the device through NFC communication.
- the communication in which a tap of the card proximate the card reader of the device may allow the application of the device to read data associated with the contactless card and activate the card.
- the activation may authorize the card to be used to perform other functions, e.g., purchases, access account or restricted information, or other functions.
- the tap may activate or launch the application of the device and then initiate one or more actions or communications with one or more servers to activate the contactless card.
- a tap of the contactless card proximate the card reader may initiate a download of the application, such as navigation to a download page of the application). Subsequent to installation, a tap of the contactless card may activate or launch the application, and then initiate, for example via the application or other back-end communication), activation of the contactless card. After activation, the contactless card may be used in various activities, including without limitation commercial transactions.
- a dedicated application may be configured to execute on a client device to perform the activation of the contactless card.
- a webportal, a web-based app, an applet, and/or the like may perform the activation.
- Activation may be performed on the client device, or the client device may merely act as a go between for the contactless card and an external device (e.g., account server).
- the application in providing activation, may indicate, to the account server, the type of device performing the activation (e.g., personal computer, smartphone, tablet, or point- of-sale (POS) device).
- the application may output, for transmission, different and/or additional data to the account server depending on the type of device involved.
- data may comprise information associated with a merchant, such as merchant type, merchant ID, and information associated with the device type itself, such as POS data and POS ID.
- the example authentication communication protocol may mimic an offline dynamic data authentication protocol of the EMV standard that is commonly performed between a transaction card and a point-of-sale device, with some modifications.
- the example authentication protocol is not used to complete a payment transaction with a card issuer/payment processor per se, some data values are not needed, and authentication may be performed without involving real-time online connectivity to the card issuer/payment processor.
- point of sale (POS) systems submit transactions including a transaction value to a card issuer. Whether the issuer approves or denies the transaction may be based on if the card issuer recognizes the transaction value.
- POS based transactions may also decline transactions based on the number of transaction attempts (e.g., transaction counter). A number of attempts beyond a buffer value may result in a soft decline; the soft decline requiring further verification before accepting the transaction.
- a buffer value for the transaction counter may be modified to avoid declining legitimate transactions.
- the contactless card can selectively communicate information depending upon the recipient device. Once tapped, the contactless card can recognize the device to which the tap is directed, and based on this recognition the contactless card can provide appropriate data for that device. This advantageously allows the contactless card to transmit only the information required to complete the instant action or transaction, such as a payment or card authentication. By limiting the transmission of data and avoiding the transmission of unnecessary data, both efficiency and data security can be improved.
- the recognition and selective communication of information can be applied to a various scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and step-up fraud reduction.
- the contactless card tap is directed to a device running Apple’s iOS® operating system, e.g., an iPhone, iPod, or iPad
- the contactless card can recognize the iOS® operating system and transmit data appropriate data to communicate with this device.
- the contactless card can provide the encrypted identity information necessary to authenticate the card using NDEF tags via, e.g., NFC.
- the contactless card tap is directed to a device running the Android® operating system, e.g., an Android® smartphone or tablet, the contactless card can recognize the Android® operating system and transmit appropriate and data to communicate with this device (such as the encrypted identity information necessary for authentication by the methods described herein).
- the contactless card tap can be directed to a POS device, including without limitation a kiosk, a checkout register, a payment station, or other terminal.
- a POS device including without limitation a kiosk, a checkout register, a payment station, or other terminal.
- the contactless card can recognize the POS device and transmit only the information necessary for the action or transaction.
- the contactless card can communicate payment information necessary to complete the transaction under the EMV standard.
- the POS devices participating in the transaction can require or specify additional information, e.g., device-specific information, location-specific information, and transaction-specific information, that is to be provided by the contactless card. For example, once the POS device receives a data communication from the contactless card, the POS device can recognize the contactless card and request the additional information necessary to complete an action or transaction.
- additional information e.g., device-specific information, location-specific information, and transaction-specific information
- the POS device can be affiliated with an authorized merchant or other entity familiar with certain contactless cards or accustomed to performing certain contactless card transactions. However, it is understood such an affiliation is not required for the performance of the described methods.
- the contactless card may be tapped to a mobile device without having to open an application, to indicate a desire or intent to utilize one or more of reward points, loyalty points, coupons, offers, or the like to cover one or more purchases.
- an intention behind the purchase is provided.
- the one or more applications may be configured to determine that it was launched via one or more tap gestures of the contactless card, such that a launch occurred at 3 :51 pm, that a transaction was processed or took place at 3 : 56 pm, in order to verify identity of the user.
- the one or more applications may be configured to control one or more actions responsive to the one or more tap gestures.
- the one or more actions may comprise collecting rewards, collecting points, determine the most important purchase, determine the least costly purchase, and/or reconfigure, in real-time, to another action.
- data may be collected on tap behaviors as biometric/gestural authentication.
- a unique identifier that is cryptographically secure and not susceptible to interception may be transmitted to one or more backend services.
- the unique identifier may be configured to look up secondary information about individual.
- the secondary information may comprise personally identifiable information about the user.
- the secondary information may be stored within the contactless card.
- the device may comprise an application that splits bills or check for payment amongst a plurality of individuals.
- each individual may possess a contactless card, and may be customers of the same issuing financial institution, but it is not necessary.
- Each of these individuals may receive a push notification on their device, via the application, to split the purchase. Rather than accepting only one card tap to indicate payment, other contactless cards may be used.
- individuals who have different financial institutions may possess contactless cards to provide information to initiate one or more payment requests from the card-tapping individual.
- a first friend owes a second friend (payee) a sum of money.
- payor wishes to pay via payee’s smartphone (or other device) using a contactless card.
- Payee logs- on to the appropriate application on his smartphone and selects a payment request option.
- the application requests authentication via payee’s contactless card. For example, the application outputs a display requesting that payee tap his contactless card.
- the contactless card is read and verified.
- the application displays a prompt for payor to tap his contactless card to send payment.
- the application reads the card information and transmits, via an associated processor, a request for payment to payor’s card issuer.
- the card issuer processes the transaction and sends a status indicator of the transaction to the smartphone.
- the application then outputs for display the status indicator of the transaction.
- a credit card customer may receive a new credit card (or debit card, other payment card, or any other card requiring activation) in the mail.
- the customer may decide to activate the card via an application on his or her device (e.g., a mobile device such as a smartphone).
- the customer may select the card activation feature from the application’s menu that is displayed on a display of the device.
- the application may prompt the customer to tap his or her credit card against the screen.
- the application may be configured to communicate with a server, such as a card issuer server which activates the customer’s card.
- the application may then display a message indicating successful activation of the card.
- the card activation would then be complete.
- FIG. 7 illustrates an embodiment of an exemplary computing architecture 700 suitable for implementing various embodiments as previously described.
- the computing architecture 700 may comprise or be implemented as part of an electronic device, such as a computer 701. The embodiments are not limited in this context.
- a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer.
- a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer.
- an application running on a server and the server can be a component.
- One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.
- the computing architecture 700 includes various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth.
- processors multi-core processors
- co-processors memory units
- chipsets controllers
- peripherals peripherals
- oscillators oscillators
- timing devices video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth.
- the computing architecture 700 comprises a processing unit 702, a system memory 704 and a system bus 706.
- the processing unit 702 can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing unit 702.
- the system bus 706 provides an interface for system components including, but not limited to, the system memory 704 to the processing unit 702.
- the system bus 706 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures.
- Interface adapters may connect to the system bus 706 via a slot architecture.
- Example slot architectures may include without limitation Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.
- the computing architecture 700 may comprise or implement various articles of manufacture.
- An article of manufacture may comprise a computer-readable storage medium to store logic.
- Examples of a computer-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re writeable memory, and so forth.
- Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.
- Embodiments may also be at least partly implemented as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.
- the system memory 704 may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.
- ROM read-only memory
- RAM random-access memory
- DRAM dynamic RAM
- DDRAM Double-Data-Rate
- the system memory 704 can include non-volatile memory 708 and/or volatile memory 710.
- a basic input/output system (BIOS) can be stored in the non-volatile memory 708.
- the computing architecture 700 may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) 712, a magnetic floppy disk drive (FDD) 714 to read from or write to a removable magnetic disk 716, and an optical disk drive 718 to read from or write to a removable optical disk 720 (e.g., a CD-ROM or DVD).
- HDD hard disk drive
- FDD magnetic floppy disk drive
- an optical disk drive 718 to read from or write to a removable optical disk 720 (e.g., a CD-ROM or DVD).
- the HDD 712, FDD 714 and optical disk drive 720 can be connected to the system bus 706 by an HDD interface 722, an FDD interface 724 and an optical drive interface 726, respectively.
- the HDD interface 722 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 694 interface technologies.
- the drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth.
- a number of program modules can be stored in the drives and memory units 708, 712, including an operating system 728, one or more application programs 730, other program modules 732, and program data 734.
- the one or more application programs 730, other program modules 732, and program data 734 can include, for example, the various applications and/or components of the messaging system 500.
- a user can enter commands and information into the computer 701 through one or more wire/wireless input devices, for example, a keyboard 736 and a pointing device, such as a mouse 738.
- Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like.
- IR infra-red
- RF radio-frequency
- input devices are often connected to the processing unit 702 through an input device interface 740 that is coupled to the system bus 706, but can be connected by other interfaces such as a parallel port, IEEE 694 serial port, a game port, a USB port, an IR interface, and so forth.
- a monitor 742 or other type of display device is also connected to the system bus 706 via an interface, such as a video adaptor 744.
- the monitor 742 may be internal or external to the computer 701.
- a computer typically includes other peripheral output devices, such as speakers, printers, and so forth.
- the computer 701 may operate in a networked environment using logical connections via wire and/or wireless communications to one or more remote computers, such as a remote computer 744.
- the remote computer 744 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 701, although, for purposes of brevity, only a memory/storage device 746 is illustrated.
- the logical connections depicted include wire/wireless connectivity to a local area network (LAN) 748 and/or larger networks, for example, a wide area network (WAN) 750.
- LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, for example, the Internet.
- the computer 701 When used in a LAN networking environment, the computer 701 is connected to the LAN 748 through a wire and/or wireless communication network interface or adaptor 752.
- the adaptor 752 can facilitate wire and/or wireless communications to the LAN 748, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adaptor 752.
- the computer 701 can include a modem 754, or is connected to a communications server on the WAN 750, or has other means for establishing communications over the WAN 750, such as by way of the Internet.
- the modem 754 which can be internal or external and a wire and/or wireless device, connects to the system bus 706 via the input device interface 740.
- program modules depicted relative to the computer 701, or portions thereof can be stored in the remote memory/storage device 746. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
- the computer 701 is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.13 over-the-air modulation techniques).
- wireless communication e.g., IEEE 802.13 over-the-air modulation techniques.
- the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.
- Wi-Fi networks use radio technologies called IEEE 802.13x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity.
- a Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE 802.3-related media and functions).
- FIG. 8 is a block diagram depicting an exemplary communications architecture 800 suitable for implementing various embodiments as previously described.
- the communications architecture 800 includes various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, power supplies, and so forth.
- the embodiments, however, are not limited to implementation by the communications architecture 800.
- the communications architecture 800 includes one or more clients 802 and servers 804.
- the clients 802 may implement the client device 510.
- the servers 804 may implement the server device 526.
- the clients 802 and the servers 804 are operatively connected to one or more respective client data stores 806 and server data stores 808 that can be employed to store information local to the respective clients 802 and servers 804, such as cookies and/or associated contextual information.
- the clients 802 and the servers 804 may communicate information between each other using a communication framework 810.
- the communications framework 810 may implement any well-known communications techniques and protocols.
- the communications framework 810 may be implemented as a packet-switched network (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), a circuit-switched network (e.g., the public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with suitable gateways and translators).
- the communications framework 810 may implement various network interfaces arranged to accept, communicate, and connect to a communications network.
- a network interface may be regarded as a specialized form of an input output interface.
- Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair 10/100/1000 Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE 802.8a-x network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, and the like.
- multiple network interfaces may be used to engage with various communications network types. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and unicast networks.
- a communications network may be any one and the combination of wired and/or wireless networks including without limitation a direct interconnection, a secured custom connection, a private network (e.g., an enterprise intranet), a public network (e.g., the Internet), a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), an Operating Missions as Nodes on the Internet (OMNI), a Wide Area Network (WAN), a wireless network, a cellular network, and other communications networks.
- a private network e.g., an enterprise intranet
- a public network e.g., the Internet
- PAN Personal Area Network
- LAN Local Area Network
- MAN Metropolitan Area Network
- OMNI Operating Missions as Nodes on the Internet
- WAN Wide Area Network
- wireless network a cellular network, and other communications networks.
- the components and features of the devices described above may be implemented using any combination of discrete circuitry, application specific integrated circuits (ASICs), logic gates and/or single chip architectures. Further, the features of the devices may be implemented using microcontrollers, programmable logic arrays and/or microprocessors or any combination of the foregoing where suitably appropriate. It is noted that hardware, firmware and/or software elements may be collectively or individually referred to herein as “logic” or “circuit.”
- At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.
- a procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.
- the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein, which form part of one or more embodiments. Rather, the operations are machine operations. Useful machines for performing operations of various embodiments include general purpose digital computers or similar devices.
- Coupled and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
- Various embodiments also relate to apparatus or systems for performing these operations.
- This apparatus may be specially constructed for the required purpose or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer.
- the procedures presented herein are not inherently related to a particular computer or other apparatus.
- Various general purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Toxicology (AREA)
- Economics (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Bioethics (AREA)
- Electromagnetism (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Storage Device Security (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/731,178 US10909527B2 (en) | 2018-10-02 | 2019-12-31 | Systems and methods for performing a reissue of a contactless card |
PCT/US2020/061865 WO2021137969A1 (en) | 2019-12-31 | 2020-11-23 | Systems and methods for performing a reissue of a contactless card |
Publications (1)
Publication Number | Publication Date |
---|---|
EP4085411A1 true EP4085411A1 (en) | 2022-11-09 |
Family
ID=76653963
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP20825352.6A Pending EP4085411A1 (en) | 2019-12-31 | 2020-11-23 | Systems and methods for performing a reissue of a contactless card |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP4085411A1 (en) |
JP (2) | JP7334254B2 (en) |
KR (1) | KR20210153592A (en) |
AU (1) | AU2023258357A1 (en) |
CA (1) | CA3116476A1 (en) |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006190175A (en) | 2005-01-07 | 2006-07-20 | Tamura Seisakusho Co Ltd | Rfid-use type authentication control system, authentication control method and authentication control program |
US7793851B2 (en) | 2005-05-09 | 2010-09-14 | Dynamics Inc. | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US9299072B2 (en) | 2014-05-29 | 2016-03-29 | Apple Inc. | Apparatuses and methods for operating a portable electronic device to conduct mobile payment transactions |
US10482453B2 (en) | 2015-04-14 | 2019-11-19 | Capital One Services, Llc | Dynamic transaction card protected by gesture and voice recognition |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
-
2020
- 2020-11-23 JP JP2021542218A patent/JP7334254B2/en active Active
- 2020-11-23 CA CA3116476A patent/CA3116476A1/en active Pending
- 2020-11-23 KR KR1020217007666A patent/KR20210153592A/en not_active Application Discontinuation
- 2020-11-23 EP EP20825352.6A patent/EP4085411A1/en active Pending
-
2023
- 2023-08-16 JP JP2023132465A patent/JP2023156439A/en active Pending
- 2023-10-31 AU AU2023258357A patent/AU2023258357A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
JP2022536435A (en) | 2022-08-17 |
CA3116476A1 (en) | 2021-06-30 |
AU2023258357A1 (en) | 2023-11-30 |
KR20210153592A (en) | 2021-12-17 |
JP7334254B2 (en) | 2023-08-28 |
JP2023156439A (en) | 2023-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11461764B2 (en) | Systems and methods for performing a reissue of a contactless card | |
EP3861501A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
WO2020072575A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
US11210664B2 (en) | Systems and methods for amplifying the strength of cryptographic algorithms | |
WO2020072694A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
WO2020072342A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
US20200106609A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
US20200106614A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
AU2019352586A1 (en) | Systems and methods for signaling a potential attack on contactless cards | |
AU2020343996B2 (en) | Systems and methods for performing a reissue of a contactless card | |
WO2020072552A1 (en) | Systems and methods for cryptographic authentication of contactless cards | |
JP7334254B2 (en) | System and method for performing contactless card reissue |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20210721 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20240610 |