Contactless card-based authentication via web-browser

Abstract

A computer-implemented method of implementing short range wireless communications via a web page on a computing device includes receiving, via a web browser executing on the computing device, a first request to execute computer executable instructions from the web page, the computer executable instructions requesting data from an enterprise server. The method further includes triggering the web browser to execute the predetermined computer program in response to a second request from the enterprise server to authenticate the first request. The method further includes scanning the ciphertext from the contactless card by a predetermined computer program to authenticate the ciphertext and cause the enterprise server to send the data. The method further includes, in response to receiving the data sent by the enterprise server, executing the computer executable instructions from the first request via the web browser.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480044305.4 (22) Application Date 2024.06.11 (30) Priority Data 18 / 333,941 2023.06.13 US (85) PCT International Application Entering National Phase Date 2025.12.30 (86) PCT International Application Application Data PCT / US2024 / 033408 2024.06.11 (87) PCT International Application Publication Data WO2024 / 258850 EN 2024.12.19 (71) Applicant: Capital One Services LLC Address: USA (72) Inventors: Jeffrey Carlisle, Vickel, Paul Y. Morton (74) Patent Agency: Beijing Pinyuan Patent Agency Co., Ltd. 11332 Patent Attorneys Tan Yingying and Hu Bin (51) Int.Cl. H04L 9 / 32 (2006.01) G06K 7 / 10 (2006.01) G06F 16 / 95 (2006.01) (54) Invention Title: Authentication Based on a Contactless Card via a Web Browser (57) Abstract: A computer-implemented method for short-range wireless communication via a webpage on a computing device, comprising: receiving a first request from a webpage via a webpage to execute computer-executable instructions, the computer-executable instructions requesting data from an enterprise server. The method further comprises: triggering the webpage to execute a predetermined computer program in response to a second request from the enterprise server to authenticate the first request. The method further comprises: scanning ciphertext from a contactless card via the predetermined computer program to authenticate the ciphertext and cause the enterprise server to send data. The method further comprises: executing the computer-executable instructions from the first request via the webpage in response to receiving data sent by the enterprise server. Claims 2 pages, Description 25 pages, Drawings 14 pages, CN 121420506 A 2026.01.27 CN 1 21 42 05 06 A 1. A computer-implemented method, the method comprising: receiving a first request to execute computer-executable instructions, the computer-executable instructions requesting data from an enterprise server; receiving a second request from the enterprise server to authenticate the first request; scanning for authentication from a contactless card using a short-range wireless communication module of a computing device based on the second request; transmitting a response to the enterprise server in response to determining that the first request is authentic based on authentication data, causing the enterprise server to send the data; and executing the computer-executable instructions from the first request via a web browser in response to receiving the data sent by the enterprise server.2. The computer-implemented method of claim 1, wherein receiving the second request causes the web browser to execute a predetermined computer program from a set of computer programs associated with the web server, the set of computer programs including extensions, plug-ins, components, and add-ons. 3. The computer-implemented method of claim 2, wherein the predetermined computer program is associated with the enterprise server. 4. The computer-implemented method of claim 1, wherein authenticating the first request includes verifying that the first request was initiated by an authorized user. 5. The computer-implemented method of claim 1, wherein determining that the first request is authentic based on authentication information includes: verifying ciphertext through the predetermined computer program, and in response, transmitting a response to the enterprise server through the predetermined computer program, causing the enterprise server to send data for the computer-executable instructions. 6. The computer-implemented method of claim 1, wherein determining that the first request is authentic based on the authentication data includes: transmitting at least ciphertext through the predetermined computer program for the enterprise server to receive, and in response to verification of the ciphertext by the enterprise server, sending data for the computer-executable instructions by the enterprise server. 7. The computer-implemented method of claim 1, wherein the computer-executable instructions are part of a secure transaction being executed on a webpage via the web browser. 8. The computer-implemented method of claim 7, wherein the secure transaction includes at least one of a set of transactions including login transactions, business transactions, and data transfer transactions. 9. The computer-implemented method of claim 1, wherein the enterprise server is at least one of a set of servers including bank servers, authentication servers, and intermediary servers. 10. A computing device, the computing device comprising: a processor; and a memory storing instructions, the instructions which, when executed by the processor, configure the device to: receive a first request to execute computer-executable instructions, the computer-executable instructions requesting data from an enterprise server; receive a second request from the enterprise server to authenticate the first request; scan for authentication from a contactless card using a short-range wireless communication module of the computing device based on the second request; transmit a response to the enterprise server in response to determining that the first request is authentic based on authentication data, causing the enterprise server to send the data; and execute, via a web browser, the computer-executable instructions from the first request (claim 1 / 2 page 2 CN 121420506 A) in response to receiving the data sent by the enterprise server.11. The computing device of claim 10, wherein receiving the second request causes the web browser to execute a predetermined computer program from a set of computer programs associated with the web server, the set of computer programs including extensions, plug-ins, components, and add-ons. 12. The computing device of claim 11, wherein the predetermined computer program is associated with the enterprise server. 13. The computing device of claim 10, wherein authenticating the first request includes verifying that the first request was initiated by an authorized user. 14. The computing device of claim 10, wherein determining that the first request is authentic based on authentication information includes: verifying ciphertext through the predetermined computer program, and, in response, transmitting a response to the enterprise server through the predetermined computer program, causing the enterprise server to send data for the computer-executable instructions. 15. The computing device of claim 10, wherein determining that the first request is authentic based on the authentication data includes: transmitting at least ciphertext through the predetermined computer program for the enterprise server to receive, and, in response to verification of the ciphertext by the enterprise server, sending data for the computer-executable instructions by the enterprise server. 16. The computing device of claim 10, wherein the computer-executable instructions are part of a secure transaction being executed on a webpage via the web browser. 17. The computing device of claim 16, wherein the secure transaction includes at least one of a set of transactions including login transactions, business transactions, and data transfer transactions. 18. The computing device of claim 10, wherein the enterprise server is at least one of a set of servers including bank servers, authentication servers, and intermediate servers. Claims 2 / 2 Page 3 CN 121420506 A Contactless Card-Based Authentication via Web Browser

[0001] Cross-Reference to Related Applications

[0002] This application claims priority to U.S. Patent Application Serial No. 18 / 333,941, filed April 13, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0003] Authentication of users participating in various online functions such as login transactions, payment transactions, and document signing transactions is crucial. Contactless cards are frequently used for such authentication. Contactless cards are based on radio frequency identification (RFID) technology and can be embedded in credit cards, ID cards, and other smart cards. This technology allows users to complete online transactions, such as credit card transactions and identity verification transactions, by performing specific gestures, such as bringing a designated smart card to a specific area within a specific distance (or tapping that specific area) on a device such as a point-of-sale terminal or mobile phone.Such gestures enable the transmission of specific data for the purpose of completing one or more online operations. Before such gesture-based functionality can be adopted, devices, cards, etc., with this capability must be properly activated. However, existing authentication processes are limited to specific applications, restricting access to certain portals and functions.

[0004] One general aspect includes a computer-implemented method for enabling short-range wireless communication via a webpage on a computing device. The computer-implemented method includes: receiving, via a webpage, a first request to execute computer-executable instructions, which requests data from an enterprise server, via a web browser running on the computing device. The method further includes: receiving, from the enterprise server, a second request to authenticate the first request from the webpage. The method further includes: triggering the web browser to execute a predetermined computer program in response to the second request from the enterprise server. The method further includes: scanning ciphertext from a contactless card using a short-range wireless communication module of the computing device via the predetermined computer program. The method further includes: transmitting a response to the enterprise server via the predetermined computer program in response to determining that the first request is authentic based on the ciphertext, causing the enterprise server to send data. The method further includes: executing the computer-executable instructions from the first request via the web browser in response to receiving the data sent by the enterprise server. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each computer program being configured to perform the actions of the method.

[0005] One general aspect includes a computer device comprising a memory and a processor, the memory storing instructions that, when executed by the processor, configure the computing device to: receive a first request from a web page via a web browser executing on the computing device to execute computer-executable instructions that request data from an enterprise server. The device is also configured to receive from the enterprise server a second request to authenticate the first request from the web page. The device is also configured to, in response to the second request from the enterprise server, trigger the web browser to execute a predetermined computer program. The device is also configured to, using a short-range wireless communication module of the computing device, scan ciphertext from a contactless card via the predetermined computer program. The device is also configured to, in response to determining that the first request is authentic based on the ciphertext, transmit a response to the enterprise server via the predetermined computer program, causing the enterprise server to send data. The device is also configured to, in response to receiving data sent by the enterprise server, execute the computer-executable instructions from the first request via a web browser. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each computer program being configured to perform the actions of the method. (See specification page 1 / 25, CN 121420506 A)

[0006] One general aspect includes a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium includes instructions to receive, via a web browser executing on a computing device, a first request to execute computer-executable instructions from a web page, the computer-executable instructions requesting data from an enterprise server. The medium also includes instructions to receive, from the enterprise server, a second request to authenticate the first request from the web page. The medium further includes instructions to trigger the web browser to execute a predetermined computer program in response to the second request from the enterprise server. The medium also includes instructions to scan ciphertext from a contactless card using a short-range wireless communication module of the computing device via the predetermined computer program. The medium further includes instructions to transmit a response to the enterprise server via the predetermined computer program in response to determining that the first request is authentic based on the ciphertext, causing the enterprise server to send data. The medium also includes instructions to execute the computer-executable instructions from the first request via the web browser in response to receiving data sent by the enterprise server. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each computer program configured to perform the actions of the method.

[0007] Non-transitory computer program products (i.e., physically implemented computer program products) are also described, which store instructions that, when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform the operations described herein. Similarly, a computer system is also described, which may include one or more data processors and memory coupled to the one or more data processors. The memory may temporarily or permanently store instructions that cause at least one processor to perform one or more operations described herein. Furthermore, the methods may be implemented by one or more data processors, which may be located within a single computing system or distributed among two or more computing systems. Such computing systems may be connected via one or more connections and may exchange data and / or commands or other instructions, including but not limited to connections via networks (e.g., the Internet, wireless wide area networks, local area networks, wide area networks, wired networks, or similar networks), direct connections between one or more of the multiple computing systems, etc.

[0008] Details of one or more variations of the subject matter described herein are set forth in the drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the specification, drawings, and claims.

[0009] Brief Description of the Drawings: For ease of identification of any particular element or action being discussed, the most significant digit in the reference numerals refers to the drawing number in which the element is first introduced.

[0010] FIG1 illustrates one aspect of the subject matter according to one embodiment.

[0011] FIG2 illustrates one aspect of the subject matter according to one embodiment.

[0012] FIG3 illustrates one aspect of the subject matter according to one embodiment.

[0013] FIG4 illustrates a method 400 according to one embodiment.

[0014] FIG5 illustrates one aspect of the subject matter according to one embodiment.

[0015] FIG6 illustrates one aspect of the subject matter according to one embodiment.

[0016] FIG7 illustrates a contactless card 102 according to one embodiment.

[0017] FIG8 illustrates a transaction card component 800 according to one embodiment.

[0018] FIG9 illustrates a sequence flow 900 according to one embodiment.

[0019] FIG10 illustrates a data structure 1000 according to one embodiment.

[0020] FIG11 is a diagram of a key system according to an exemplary embodiment.

[0021] FIG12 is a flowchart of a method for generating ciphertext according to an exemplary embodiment. Specification 2 / 25 pages 5 CN 121420506 A

[0022] FIG13 illustrates one aspect of the subject matter according to one embodiment.

[0023] FIG14 illustrates one aspect of the subject matter according to one embodiment. Detailed Description

[0024] FIG1 illustrates a data transmission system 100 according to an example embodiment. As discussed further below, system 100 may include a contactless card 102, a client device 104, a network 106, and a server 108. Although FIG1 shows a single instance of the components, system 100 may include any number of components.

[0025] System 100 may include one or more contactless cards 102, which will be further explained below. In some embodiments, the contactless card 102 may wirelessly communicate with the client device 104, for example, using NFC.

[0026] System 100 may include the client device 104, which may be a network-enabled computing device (“computing device” or “computer”). As described herein, a network-enabled computer may include, but is not limited to, computer equipment or communication equipment, including, for example, servers, network appliances, personal computers, workstations, telephones, handheld PCs, personal digital assistants, thin clients, fat clients, internet browsers, or other devices. Client device 104 may also be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad or any other mobile device running Apple's iOS® operating system from Apple®, a device running Microsoft's Windows® mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet or similar wearable mobile device.

[0027] Client device 104 may include a processor and memory, and it should be understood that the processing circuitry may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware. Client device 104 may also include display devices and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any device available and supported by the user device for inputting information into the user device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0028] In some examples, client device 104 of system 100 may execute one or more applications, such as software applications, which, for example, enable network communication with one or more components of system 100 and transmit and / or receive data.

[0029] Client device 104 may communicate with one or more servers 108 via one or more networks 106 and may operate with server 108 as a corresponding front-end / back-end pair. Client device 104 may, for example, transmit one or more requests to server 108 from a mobile application running on client device 104. The one or more requests may be associated with retrieving data from server 108. Server 108 may receive one or more requests from client device 104. Based on one or more requests from client device 104, server 108 may be configured to retrieve the requested data from one or more databases (not shown). Based on the received requested data from one or more databases, server 108 may be configured to transmit the received data to client device 104 in response to one or more requests.

[0030] System 100 may include one or more networks 106. In some examples, network 106 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 104 to server 108.For example, network 106 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing system, code division multiple access system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 1202.11 series networking, Bluetooth, NFC, radio frequency identification (RFID), and / or similar networks.

[0031] Furthermore, network 106 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 802.3, wide area network, wireless personal area network, LAN, or global network such as the Internet. In addition, network 106 may support Internet network, wireless communication network, cellular network, etc., or any combination thereof. Network 106 may also include one network operating independently or cooperating with each other, or any number of networks of the above exemplary types. Network 106 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 106 may convert to or from other protocols to one or more protocols of network devices. Although network 106 is depicted as a single network, it should be understood that, according to one or more examples, network 106 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

[0032] System 100 may include one or more servers 108. In some examples, server 108 may include one or more processors coupled to memory. Server 108 may be configured as a central system, server, or platform for controlling and retrieving various data at different times to perform multiple workflow actions. Server 120 may be configured to connect to one or more databases. Server 108 may be connected to at least one client device 104.

[0033] FIG2 depicts an example client device 104 according to one embodiment. Client device 104 is depicted as a mobile device; however, it should be understood that, in other embodiments, client device 104 may be any other computing device. Client device 104 facilitates the execution of one or more applications (“apps”). Each application includes one or more computer programs, that is, one or more computer-executable instructions executed by the client device 104. For example, in Figure 2, the client device 104 is depicted as having icons for App 204a, App 204b, and App 204c. It should be understood that the client device 104 may include additional, fewer, and / or different applications.Applications such as App 204a, App 204b, and App 204c may include games, banking applications, e-commerce applications, utility applications, entertainment applications, social media applications, web browsers, or any other such applications.

[0034] These applications are built for a specific platform of client device 104, such as iOS® for Apple® iPhone® or Android® for Samsung® or any other manufacturer. Typically, applications are downloaded and installed via an app store and have access to system resources such as the camera, short-range wireless communication module, secure storage, and other hardware and / or software features provided by client device 104. In some cases, when an application (such as App 204a) is first installed or used on client device 104, user 202 is requested to authorize / allow the application to use system resources.

[0035] Contactless card 102 may be associated with one or more applications. For example, consider App 204a as associated with contactless card 102. Here, by virtue of "affiliation," client device 104 facilitates communication between App 204a and contactless card 102, for example, using a short-range wireless communication module such as NFC. As discussed herein, the affiliation between contactless card 102 and App 204a can be established at an early time, such as during the activation of contactless card 102 and / or upon the first use of App 204a. Communication between contactless card 102 and App 204a may include App 204a receiving information from contactless card 102, such as security information, user identification, user authorization, etc. In some examples, App 204a may request specific information from contactless card 102. Contactless card 102 provides specific information and / or a response based on the request from App 204a. In some cases, App 204a may request information from contactless card 102 in response to a request received by App 204a from server 108.

[0036] In some embodiments, the contactless card 102 is a credit card, sometimes referred to as a "smart card," and App 204a is an application provided by the bank that issues / serves the contactless card 102. User 202 can use App 204a on client device 104 to initiate operations such as purchasing or renting products, services, and / or combinations thereof. Alternatively or additionally, as per the User Manual 4 / 25 page 7 CN 121420506 A 202 can use App 204a to initiate operations such as transferring, withdrawing, depositing, etc., or combinations thereof. It should be understood that several other types of operations are also possible, and the examples listed herein should not be considered limiting.This operation may include App 204a communicating with the service / product provider's portal 206, which in turn may communicate with server 108. For example, the service / product provider's portal 206 may communicate with server 108 to receive confirmation, authorization, or other such information to complete the operation initiated by App 204a. In response, server 108 may request authentication that user 202 is an authorized user and holds contactless card 102. Therefore, server 108 may instruct App 204a to confirm the presence of contactless card 102. In some cases, App 204a generates and displays a user interface instructing user 202 to perform a gesture for authenticating user 202. In some embodiments, the gesture may be performed with contactless card 102, such as tapping, double-tapping, swiping, capturing an image, or any other such gesture. Alternatively, the gesture may also include entering an identification code, such as a password, phrase, PIN, etc. Alternatively or additionally, the gesture may include providing biometrics, such as fingerprints, iris scans, voice samples, etc.

[0037] “Tapping” may include user 202 tapping contactless card 102 on client device 104. “Swiping” may include user 202 swiping contactless card 102 relative to client device 104. “Capturing an image” may include capturing an image of a portion of contactless card 102 using client device 104. In some examples, the gesture must be performed relative to a specific part of client device 104, such as the top, side, etc. It should be understood that several other gestures may be used, and combinations of gestures may also be used in some examples.

[0038] This gesture facilitates App 204a receiving information from contactless card 102. Receiving information based on this gesture facilitates confirmation of user 202’s possession of contactless card 102, and thus facilitates user 202’s authentication. App 204a provides the information received from contactless card 102 to server 108. In some cases, App 204a transforms the information before sending it to server 108. For example, App 204a may protect the information, such as by encrypting it before sending it. Alternatively or additionally, App 204a may append additional information, such as the identifier of client device 104 (e.g., IP address, MAC address, etc.), timestamp, or any other such information, before supplying information to server 108.

[0039] Server 108 authenticates user 202 after receiving information from client device 104. In some cases, server 108 also indicates to service / product provider portal 206 that user 202 has been authenticated. In response, service / product provider portal 206 completes the operation initiated by App 204a.In this way, user 202 can use App 204a to complete the operation and resolve the technical challenges of authenticating user 202 and confirming that user 202 holds contactless card 102.

[0040] Some technical challenges for service / product providers to initiate and complete operations include: App 204a, belonging to contactless card 102, cannot access the service / product provider's portal 206 (e.g., website, server, etc.). For example, inaccessibility may be due to incompatibility between App 204a and the underlying computing technology used by the service / product provider's portal 206. In turn, the practical effect of the technical challenge is that user 202 cannot access the products / services provided by the service / product provider.

[0041] In some cases, the solution to this technical challenge of technical incompatibility is for the service / product provider to provide an application, such as App 204b. User 202 initiates the operation via client device 104 using App 204b. Upon receiving the request, App 204b communicates with App 204a to complete the operation. App 204b thus facilitates the completion of the operations described herein. In this way, App 204b acts as the interface between App 204a (belonging to contactless card 102) and the portal 206 of the service / product provider, and solves the problem of technical incompatibility. The technical challenge of this solution using App 204b is that the developer of App 204b must be able to access App 204a and vice versa, but this may not always be the case. Furthermore, the interactive nature of the applications (in this case, App 204a and App 204b) may require that both applications be updated when either one is updated (by their respective developers).

[0042] Furthermore, in cases where the service / product provider does not have an application (App 204b) that can communicate with App 204a belonging to contactless card 102, the technical challenge of initiating and completing operations with a specific service / product provider remains. In this case, the existing solution for accessing portal 206 is to use an application on client device 104, such as web browser 208. However, a technical challenge in using web browser 208 to access portal 206 to initiate and perform operations is that client device 104 is not as readily accessible to web browser 208 as an application (e.g., App 204a). Specifically, web browser 208 may be prevented from using some of the resources of short-range wireless communication modules similar to those of client device 104. Client device 104 may also prevent web browser 208 from accessing some of its resources for reasons including security.For example, if user 202 might inadvertently access malicious code embedded in webpage 210 accessed by web browser 208. Suppose this malicious code wants to access resources of client device 104, such as a short-range wireless communication module. In this case, the malicious code might access user 202's sensitive and private data. In other embodiments, client device 104 might prevent web browser 208 from accessing additional or other resources. Therefore, without access to some of the resources of client device 104, web browser 208 cannot facilitate authentication of user 202 and / or the possession of contactless card 102 as described herein (using one or more gestures). It should be noted that web browser 208 is another application, but a special type of application identified by client device 104, and therefore associated with restricted access to resources.

[0043] The technical solutions described herein address such technical challenges, including: technical incompatibility between the service / product provider's portal 206 and the application (App 204a) belonging to contactless card 102; and the inability of web browser 208 to access all resources of client device 104. Therefore, the technical solution of this paper is rooted in computing technology, particularly addressing issues related to incompatibility. Furthermore, the technical solution of this paper provides one or more improvements to computing technology by facilitating user 202's access to and completion of operations on portal 206 of a service / product provider that is incompatible with application App 204a belonging to contactless card 102. The technical solution described herein provides practical application for user 202, as he / she can now access portal 206 and continue performing one or more operations that might not be possible via App 204a (and in the absence of App 204b).

[0044] Furthermore, the technical solution described herein provides a practical application whereby the service / product provider does not have to create and distribute applications (e.g., App 204b) for client device 104. Creating, distributing, and maintaining applications (e.g., App 204a) for each type of client device 104 can become impractical for service / client providers. Therefore, the technical solution described herein also provides practical application in this regard by reducing the number of applications that service / product providers must develop, distribute, and maintain.

[0045] Furthermore, the technical solution described herein provides a practical application for user 202, who does not need to install and maintain applications (e.g., App 204b) for every service / product provider he / she may interact with. By reducing the number of applications in this way, the technical solution facilitates user 202 in improving the efficiency of limited memory / storage on client device 104.Furthermore, each application installed on client device 104 presents a security risk, and user 202 may wish to minimize the number of applications installed on client device 104.

[0046] To address the technical challenges and provide the practical application described herein, the technical solutions described herein facilitate user 202 to access and complete one or more operations on portal 206 via web browser 208 on client device 104. Web browser 208 can be any type of browser, such as Safari®, Chrome™, Opera™, etc. Web browser 208 facilitates access to web page 210 provided by portal 206. Web page 210 facilitates user 202 to initiate operations via portal 206. It should be understood that portal 206 can provide other ways to start and perform operations besides web page 210, such as widgets, applets, scripts, or any other such computer programming resources that can be accessed by web browser 208.

[0047] The technical solutions described herein address such technical challenges by using a predetermined computer program accessed by web browser 208 when user 202 initiates an operation. In some cases, web browser 208 accesses a predetermined computer program in response to user 202 initiating a specific type of operation requiring authentication and / or confirmation of holding contactless card 102. Alternatively or additionally, web browser 208 accesses the predetermined computer program in response to user 202 initiating an operation on a specific portal 206, which is included in a list of portals accessible to web browser 208. Alternatively or additionally, web browser 208 accesses the predetermined computer program in response to web browser 208 receiving a request from portal 206 and / or server 108 to authenticate user 202 and / or confirm holding contactless card 102.

[0048] In some embodiments, the predetermined computer program is one of a set of computer programs associated with web browser 208, including extensions, plugins, components, and addons. The pre-defined computer program is depicted as extension 212, but can be any other type of pre-defined computer program accessible to web browser 208. Furthermore, while extension 212 is depicted as residing within web browser 208, in some embodiments, extension 212 may be separate from web browser 208. In some embodiments, extension 212 may be provided by the issuing bank of contactless card 102.

[0049] Extension 212 can customize the web browsing user experience on client device 104.In some embodiments, extension 212 may use the native APIs and frameworks of the operating system of client device 104 (e.g., iOS® and iPadOS®), as well as web technologies such as HTML, CSS, and JavaScript. Extension 212 may facilitate web browser 208 to read and modify the content of web page 210. Extension 212 is built using the native programming language of client device 104 (e.g., Xcode®) and facilitates communication and data sharing with native applications. Therefore, extension 212 facilitates the integration of application content (e.g., from App 204a) into web browser 208, or the sending of web data (from web browser 208) back to the application (e.g., App 204a) to create a unified experience. In some embodiments, extension 212 may facilitate the blocking of specific content types on web page 210 from access by web browser 208. Blocking behavior may include hiding elements, blocking loading, and removing website browsing cache data (cookies) from requests received by web browser 208.

[0050] Figure 3 illustrates extension 212 according to one or more embodiments. Extension 212 includes at least browser code 302 and native code 304. In some embodiments, browser code 302 includes computer-executable instructions, such as JavaScript code and web files, that work in web browser 208. Native code 304 includes computer-executable instructions, such as a function / application programming interface (API) using the operating system of the client device (104). Native code 304 acts as an intermediary between applications (such as App 204a) belonging to contactless card 102 and browser code 302. In some embodiments, the messaging API passes events and event data between browser code 302 and native code 304.

[0051] It should be noted that App 204a, web browser 208, and extension 212 each execute (i.e., operate) independently in their own sandbox environment (i.e., separate containers). Because App 204a and extension 212 run in their respective sandbox environments, they cannot share data in their respective containers. In some embodiments, data may be stored in a shared space that can be accessed and updated by both App 204a and extension 212. For example, in the iOS® operating system, such shared spaces can be enabled by enabling the “app groups” option. It should be understood that in other operating system environments, additional and / or different options may have to be enabled.

[0052] Browser code 302 can facilitate providing a user interface 306 for extension 212. In some embodiments, browser code 302 sends messages from a background script or extension page.User interface 306 may include interactive elements rendered as part of web browser 208 and / or as part of App 204a. Browser code 302 may include specific computer-executable instructions, such as message invocations that send messages to App 204a.

[0053] App 204a includes message processing functions assigned to respond to message invocations. Message invocations are paired with message processing, i.e., using a predetermined protocol to facilitate the transmission of specific data as specific parameters. For example, JSON or other such protocols may be used for such data transmission. For example, a message may be sent from App 204a to extension 212 to notify of an event, such as when user 202 clicks a button, or when the data used by the script in extension 212 changes. Specification 7 / 25 page 10 CN 121420506 A

[0054] Content scripts injected into the web content of webpage 210 cannot send messages to App 204a. However, through messaging, webpage 210 can control features in extension 212 based on events or data, or webpage 210 can request and use data from extension 212. Extension 212 is configured to receive messages from a list of webpages including webpage 210 so that webpage 210 can request and access data. For example, to enable messaging from webpage 210, an identifier of webpage 210 is added to the configuration of extension 212, such as a JSON manifest file of extension 212. In response, when webpage 210 sends a message using a messaging instruction (e.g., browser.runtime.sendMessage) of web browser 208, extension 212 is notified to process the message. In some embodiments, a message from webpage 210 includes an identifier of extension 212, message data, and a closure for processing a response from extension 212. The identifier is a unique identifier associated with each extension 212.

[0055] In some embodiments, if extension 212 needs to process more continuous data from webpage 210, a port connection is established between webpage 210 and extension 212. Extension 212 listens in the background for any such incoming port connection requests from webpage 210. The created port is then used to transfer data between extension 212 and webpage 210 using messages directed to that port. Furthermore, extension 212 includes computer-executable instructions that add functionality to process messages sent from webpage 210 to extension 212 and to respond to webpage 210.

[0056] Thus, extension 212 (i.e., a predefined computer program) facilitates communication between webpage 210 and App 204a belonging to contactless card 102. Using this communication enabled by extension 212, the technical solution described herein facilitates access to portal 206 by user 202.Furthermore, in response to one or more requests from webpage 210 of portal 206, the technical solutions described herein facilitate the use of one or more gestures as described herein to authenticate user 202 and confirm possession of contactless card 102. For example, after receiving a request from webpage 210, extension 212 requests App 204a to perform authentication. Extension 212 then provides the authentication result to webpage 210.

[0057] FIG4 illustrates a method 400 according to one embodiment. Method 400 may be a computer-implemented method, for example, executed by client device 104. In block 402, method 400 includes receiving a first request from webpage 210 via web browser 208 executed on client device 104 to execute computer-executable instructions that request data from server 108. The computer-executable instructions may be part of a secure transaction executed via web browser 208 on webpage 210 of service / product provider portal 206. For example, the secure transaction may be an online operation and includes at least one of login transaction, business transaction, and data transfer transaction. Server 108 may be a bank server, authentication server, intermediary server, or any other server 108 that facilitates the authentication of user 202 and / or provides information about user 202 after authentication.

[0058] For example, user 202 may initiate an operation to a service / product provider's portal 206 via webpage 210. In response, portal 206 may request user 202 to provide additional information to complete the operation. Additional information may include, but is not limited to, authentication information, identification information, bank account information, payment authorization information, or similar information. Portal 206 may request such information from a third-party enterprise server (such as server 108). Thus, computer-executable instructions request data from server 108 to facilitate the provision of such information.

[0059] In block 404, method 400 includes receiving a second request from server 108 to authenticate a first request from a webpage. Authenticating the first request includes verifying that an authorized user initiated the first request. Determining that user 202 is an authorized user would require confirming that user 202 holds a contactless card 102. Therefore, server 108 sends a second request to client device 104 to perform authentication and / or confirmation of possession.

[0060] In block 406, method 400 includes, in response to the second request, the execution of a predetermined computer program (i.e., extension 212) triggered by web browser 208. In some embodiments, the second request may be issued by server 108. For example, portal 206 may request authentication information of user 202 from a third-party enterprise server (such as server 108). Therefore, web browser 208 triggers extension 21 to request data from server 108 to facilitate the provision of such information.In other embodiments, the second request may be issued by portal 206, as described on page 8 / 25 of CN 121420506 A. For example, portal 206 may determine that the operation initiated by user 202 is via web browser 208. In response, portal 206 triggers extension 212 of web browser 208 to request authentication via server 108. In other embodiments, the second request may be issued by client device 104 itself. For example, web browser 208 may identify the operation being performed as one of predetermined operations, such as a payment operation, login operation, banking operation, document signing operation, etc., which can benefit from additional security. In response, web browser 208 proactively triggers extension 212, which enables authentication of user 202 using contactless card 102.

[0061] As described herein, upon receiving the second request, extension 212 causes client device 104 to authenticate user 202 and confirm possession of contactless card 102. For example, extension 212 can be configured to use message processing to listen for a second request from server 108. The second request includes an identifier of extension 212 and computer-executable instructions that cause client device 104 to authenticate user 202. The identifier of server 108 can be stored in a list of servers that enable communication with extension 212.

[0062] In block 408, method 400 includes extension 212 scanning authentication information of user 202 from contactless card 102 using a short-range wireless communication module of client device 104. In some embodiments, extension 212 uses App 204a (native application) to facilitate authentication of user 202 and confirmation of possession of contactless card 102. For example, one or more gesture-based techniques described herein can be used for authentication. In some embodiments, App 204a can be launched and executed on client device 104 and generate and display user interface 306 that instructs user 202 to perform one or more gestures relative to client device 104 using contactless card 102. Alternatively, App 204a executes in the background and generates user interface 306 and displays it as part of web browser 208, which includes instructions to perform gestures related to contactless card 102.

[0063] As part of gesture-based authentication, client device 104 receives identification information stored on contactless card 102. In some embodiments, the identification information may be provided in encrypted form. In other embodiments, the identification information or any other information received from contactless card 102 may be any other secure form.

[0064] In block 410, method 400 includes, in response to determining that a first request is genuine based on received authentication information, extending 212 transmits a response to server 108, causing server 108 to send the data requested by portal 206. In some embodiments, determining that the first request is genuine based on ciphertext includes verifying the ciphertext by extending 212. Verification may be performed by extending 212 based on a comparison with stored information. In some embodiments, extending 212 transmits an authentication response to server 108, causing server 108 to send data for computer-executable instructions from the first request. Server 108 may send data only if authentication is successful. If authentication fails, server 108 may send another type of data leading to a user notification and abort the operation.

[0065] In some embodiments, determining that the first request is genuine based on ciphertext includes extending 212 to transmit ciphertext for server 108 to receive. Server 108 verifies the information in the ciphertext, for example, by comparing the information with stored information. In response to server 108 verifying the ciphertext, server 108 sends data for computer-executable instructions.

[0066] In some embodiments, after authentication (by client device 104 or server 108), server 108 may directly send data to portal 206. Alternatively or additionally, server 108 sends data to client device 104, which in turn sends the data to portal 206 via web browser 208.

[0067] In block 412, method 400 includes executing a computer-executable instruction from a first request via web browser 208 in response to receiving data sent by server 108. Thus, client device 104 executes the computer-executable instruction from the first request only after authenticating user 202. In this way, method 400 facilitates the use of web browser 208 by user 202 to perform operations requiring user 202 to authenticate using gestures associated with contactless card 202, which utilize one or more resources of client device 104 specification page 9 / 25 12 CN 121420506 A. In some embodiments, executing computer-executable instructions may include performing the operation by providing payment information, login information, bank information, or any other such information that facilitates the operation.

[0068] Consider an example scenario in which a customer (user 202) is purchasing goods from an online portal (206) using a credit card (contactless card 102) via a web browser (208), mobile phone, or any other computing device (client device 104). User 202 initiates the checkout process (online operation) via the portal. The portal may request additional authentication information from the user and send a request to the web browser.In some examples, a request from the portal may request the triggering of an extension (212) in the web browser. Alternatively, in response to a request from the portal, the web browser determines the extension to be triggered. In other embodiments, in response to a first request from the portal, the web browser sends a request to an enterprise server (server 108) belonging to the credit card to provide authentication information. The enterprise server responds with a second request, and the web browser triggers an extension in response to the second request. Once triggered, the extension facilitates gesture-based authentication by an application belonging to the credit card (App 204a). The authentication result is provided to the enterprise server and / or the portal. Based on the authentication result, the operation is completed (checkout has been processed) or aborted (checkout has been refused).

[0069] It should be understood that the above is only an example scenario of the actual application of the technical solutions described herein, and not a limiting example. The technical solutions described herein can be used in other example scenarios, such as facilitating user 202 to log in to a system with additional authentication. Alternatively, the technical solutions described herein can facilitate users to use gesture-based authentication and additional security measures to transmit digital information. Several other practical applications of the technical solutions described herein are possible.

[0070] Figure 5 illustrates an example routine for initiating and completing an operation or transaction using a web browser on a client device, where the operation requires user authentication based on a physical transaction card. While the example routine depicts a specific sequence of operations, this sequence can be modified without departing from the scope of this disclosure. For example, some of the depicted operations can be performed in parallel or in different sequences without materially affecting the functionality of the routine. In other examples, different components of the example device or system implementing the routine may perform functions substantially simultaneously or in a specific sequence.

[0071] According to some examples, the method includes receiving, at block 502, a computer-executable instruction to initiate a transaction with an online portal 206 via a web browser 208. For example, the transaction may include a login transaction, an online purchase, a banking transaction (e.g., transfer, payment, etc.), a data transfer transaction (e.g., content upload, content download, etc.). It should be noted that the transaction is performed via a web browser 208 (e.g., Safari, Chrome, Firefox, etc.) rather than through an application or other type of computer program. In some embodiments, the transaction may be initiated by a user 202.

[0072] According to some examples, the method includes determining at block 504 the authentication to be performed. In some embodiments, this determination may be made by portal 206. In other embodiments, this determination may be made by server 108 (different from portal 206), wherein server 108 performs one or more operations as part of a transaction. For example, portal 206 may request authentication via server 108, which in turn performs authentication via client device 104.In some other embodiments, web browser 208 determines that authentication is required. Authentication may include authenticating user 202 based on a transaction card (such as contactless card 102). Authentication may also include ensuring that user 202 actually possesses contactless card 102.

[0073] According to some examples, the method includes detecting an extension 212 of web browser 208 at block 506 to perform authentication. Extension 212 may be a predetermined computer program that web browser 208 can access and execute. Extension 212 may be one of several extensions of web browser 208. Portal 206, server 108 may request web browser 208 to determine whether extension 212 is installed on client device 104 that is being used for a transaction. Alternatively, web browser 208 may detect whether extension 212 exists independently without an incoming request. In some embodiments, if extension 212 does not exist, the transaction may not be completed via web browser 208. A notification may be generated and displayed via user interface 306 indicating that the transaction has not been completed, and in some embodiments, alternatives may be suggested to user 202. Instruction manual 10 / 25 pages 13 CN 121420506 A

[0074] According to some examples, where extension 212 is available and detected, the method includes triggering extension 212 at box 508 to perform authentication. After being triggered, extension 212 facilitates the performance of authentication. For example, extension 212 uses an application (App 204a) belonging to contactless card 102 to perform gesture-based authentication.

[0075] According to some examples, the method includes providing the authentication result facilitated by extension 212 at box 510. According to some examples, the method includes further continuing the initiated transaction based on the authentication result at box 512.

[0076] In this way, the technical solutions described herein facilitate the initiation and completion of operations or transactions using web browser 208 of client device 104, wherein the operation requires user authentication based on the physical presence of contactless card 102 in a predetermined vicinity of client device 104.

[0077] FIG6 illustrates a data transmission system according to an example embodiment. System 600 may include, for example, a transmitting or sending device 604 and a receiving or receiving device 608 that communicate with one or more servers 602 via network 606. Transmitting or sending device 604 may be the same as or similar to client device 104 discussed above with reference to FIG1. ​​Receiving or receiving device 608 may be the same as or similar to client device 104 discussed above with reference to FIG1. ​​Network 606 may be similar to network 106 discussed above with reference to FIG1. ​​Server 602 may be similar to server 108 discussed above with reference to FIG1. ​​Although FIG6 shows a single example of the components of system 600, system 600 may include any number of illustrated components.

[0078] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cryptographic message authentication code (CMAC) algorithms, it is important that the key is kept secret between the party that originally processed the data protected using the symmetric algorithm and key and the other party that received and processed the data using the same cryptographic algorithm and the same key.

[0079] It is also important that the same key should not be used too many times. If a key is used or reused too frequently, the key may be leaked. Each time the key is used, it provides an attacker with an additional sample of data that has been processed by the cryptographic algorithm using the same key. The more data that an attacker has processed using the same key, the greater the likelihood that the attacker will discover the value of the key. Frequently used keys may be included in a variety of different attacks.

[0080] Furthermore, each time a symmetric cryptographic algorithm is executed, it may reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data may include tiny power fluctuations that occur when the cryptographic algorithm is executed while the key is being used. It may be possible to measure the side-channel data enough to reveal enough information about the key to allow an attacker to recover the key. Using the same key to exchange data repeatedly exposes data processed by the same key.

[0081] However, by limiting the number of times a particular key is used, the amount of side-channel data that an attacker can collect is limited, and thus exposure to such and other types of attacks is reduced. As further described herein, the parties involved in the exchange of cryptographic information (e.g., the sender and the receiver) can independently generate keys from an initially shared master symmetric key combined with a counter value, and thus periodically replace the shared symmetric key being used without any form of key exchange to keep the parties synchronized. By periodically changing the shared secret symmetric key used by the sender and the receiver, the aforementioned attacks become impossible.

[0082] Referring to FIG6, system 600 can be configured to implement key diversification. For example, the sender and the receiver may expect to exchange data (e.g., raw sensitive data) via their respective devices 604 and 608. As stated above, while a single instance of the transmitting device 604 and the receiving device 608 may be included, it is understood that one or more transmitting devices 604 and one or more receiving devices 608 may be involved as long as the parties share the same shared secret symmetric key. In some examples, transmitting device 604 and receiving device 608 may be provided with the same master symmetric key. Furthermore, it should be understood that either party or device holding the same secret symmetric key can perform the function of transmitting device 604, and similarly, either party holding the same secret symmetric key can perform the function of receiving device 608.In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties except for the transmitting device 604 and the receiving device 608 involved in exchanging secure data. It is also understood that both the transmitting device 604 and the receiving device 608 may be provided with the same master symmetric key, and further, a portion of the data exchanged between the transmitting device 604 and the receiving device 608 includes at least a portion of data that may be referred to as a counter value. The counter value may include a number that changes each time data is exchanged between the transmitting device 604 and the receiving device 608.

[0083] System 600 may include one or more networks 606. In some examples, network 606 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect one or more transmitting devices 604 and one or more receiving devices 608 to server 602. For example, network 606 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless LAN, Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiplexing-based system, code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 1202.11 series networking, Bluetooth, NFC, RFID, Wi-Fi and / or similar networks.

[0084] Furthermore, network 606 may include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 1302.3, wide area network, wireless personal area network, LAN, or global networks such as the Internet. In addition, network 606 may support Internet networks, wireless communication networks, cellular networks, etc., or any combination thereof. Network 606 may also include a network operating independently or cooperating with each other, or any number of networks of the above exemplary types. Network 606 may utilize one or more protocols of one or more network elements to which it is communicatively coupled. Network 606 can be converted to or from other protocols to one or more protocols of the network device. Although network 606 is depicted as a single network, it should be understood that, according to one or more examples, network 606 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network.

[0085] In some examples, one or more transmitting devices 604 and one or more receiving devices 608 may be configured to communicate with each other and to transmit and receive data without passing through network 606.For example, communication between one or more transmitting devices 604 and one or more receiving devices 608 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and / or similar technologies.

[0086] At block 610, when transmitting device 604 is ready to process sensitive data using symmetric cryptographic operations, the sender may update a counter. Additionally, transmitting device 604 may select an appropriate symmetric cryptographic algorithm, which may include at least one of symmetric encryption algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process diverse values ​​may include any symmetric cryptographic algorithm used to generate diverse symmetric keys of a desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES128; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm fails to generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may produce multiple outputs that can be combined as needed to generate a sufficiently long key.

[0087] At block 612, transmitting device 604 may employ a selected cryptographic algorithm and use a master symmetric key to process the counter value. For example, the sender may select a symmetric encryption algorithm and use a counter that is updated with each conversation between transmitting device 604 and receiving device 608. Transmitting device 604 may then encrypt the counter value using the master symmetric key and the selected symmetric encryption algorithm to create a diversified symmetric key.

[0088] In some examples, the counter value may not be encrypted. In these examples, at block 612, the counter value may be transmitted between transmitting device 604 and receiving device 608 without encryption.

[0089] At block 614, the diversified symmetric key may be used to process sensitive data before transmitting the result to receiving device 608. For example, transmitting device 604 may use a symmetric encryption algorithm to encrypt sensitive data using a diversified symmetric key, as specified in specification page 12 / 25, 15 CN 121420506 A, where the output includes protected encrypted data. The transmitting device 604 can then transmit the protected encrypted data along with the counter value to the receiving device 608 for processing.

[0090] At block 616, the receiving device 608 can first acquire the counter value, and then use the counter value as the input for encryption, and use the master symmetric key as the encryption key to perform the same symmetric encryption. The encrypted output can be the same diversified symmetric key value created by the sender.

[0091] At block 618, receiving device 608 can then acquire the protected encrypted data and decrypt it using a symmetric decryption algorithm along with a diversified symmetric key.

[0092] At block 620, the original sensitive data is revealed as a result of decrypting the protected encrypted data.

[0093] The next time sensitive data needs to be sent from the sender to the receiver via the respective transmitting device 604 and receiving device 608, different counter values ​​can be selected, thereby generating different diversified symmetric keys. By processing the counter values ​​with the master symmetric key and the same symmetric cryptographic algorithm, both transmitting device 604 and receiving device 608 can independently generate the same diversified symmetric key. This diversified symmetric key (rather than the master symmetric key) is used to protect the sensitive data.

[0094] As described above, transmitting device 604 and receiving device 608 initially each possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Because the diversified symmetric key is created independently by transmitting device 604 and receiving device 608, it is never transmitted between the two parties. Therefore, attackers cannot intercept the diversified symmetric key and will never see any data processed with the master symmetric key. Only the counter value is processed using the master symmetric key, not sensitive data. As a result, side-channel data exposure regarding the master symmetric key is reduced. Furthermore, the operation of the transmitting device 604 and the receiving device 608 can be controlled by a symmetric requirement on how often a new diversified value (and thus a new diversified symmetric key) is created. In one embodiment, a new diversified value can be created for each exchange between the transmitting device 604 and the receiving device 608, and thus a new diversified symmetric key can be created.

[0095] In some examples, the key diversification value may include a counter value. Other non-limiting examples of key diversification values ​​include: a random number generated each time a new diversification key is needed, which is sent from transmitting device 604 to receiving device 608; the full value of a counter value sent from transmitting device 604 and receiving device 608; a portion of a counter value sent from transmitting device 604 and receiving device 608; a counter maintained independently by transmitting device 604 and receiving device 608 but not sent between the two devices; a one-time cipher exchanged between transmitting device 604 and receiving device 608; and a cryptographic hash of sensitive data. In some examples, parties may use one or more portions of a key diversification value to create multiple diversification keys. For example, a counter may be used as a key diversification value. Furthermore, combinations of one or more of the exemplary key diversification values ​​described above may be used.

[0096] In another example, a portion of a counter may be used as a key diversification value. If multiple master key values ​​are shared between parties, multiple diversification key values ​​can be obtained through the systems and processes described herein.A new diversification value can be created whenever needed, and thus a new diversification symmetric key can be created. In the most secure case, a new diversification value can be created for each sensitive data exchange between the transmitting device 604 and the receiving device 608. In practice, this can create one-time use keys, such as one-time session keys.

[0097] Figure 7 shows an example configuration of the contactless card 102, which may include a payment card issued by a service provider (as shown by the service provider mark 702 on the front or back of the contactless card 102), such as a credit card, debit card, or gift card. In some examples, the contactless card 102 is not a payment card and may include, but is not limited to, an identity card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 102 may include a substrate 708, which may include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 102 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 102 according to this disclosure may have different characteristics, and this disclosure does not require the transaction card to be implemented as a payment card.

[0098] The contactless card 102 may also include identification information 706 displayed on the front and / or back of the card, and a contact pad 704. The contact pad 704 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop, or tablet computer) via the transaction card. The contact pad can be designed according to one or more standards (such as ISO / IEC 7816) and enable communication according to the EMV protocol. The contactless card 102 may also include processing circuitry, an antenna, and other components, as will be discussed further in Figure 8. These components may be located behind the contact pad 704 or elsewhere on the substrate 708, for example, within different layers of the substrate 708, and may be electrically and physically coupled to the contact pad 704. The contactless card 102 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card (not shown in Figure 7). The contactless card 102 may also include a near-field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. Embodiments are not limited to this approach.

[0099] As shown, the contact pad 704 of the contactless card 102 may include processing circuitry 816 for storing, processing, and conveying information, including a processor 802, a memory 804, and one or more interfaces 806. It should be understood that the processing circuitry 816 may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware.

[0100] The memory 804 may be a read-only memory, a write-once-read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 102 may include one or more of these memories. A read-only memory can be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read multiple times. A write-once / read-many memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. A read / write memory can be programmed and reprogrammed many times after leaving the factory. The read / write memory can also be read multiple times after leaving the factory. In some cases, memory 804 may be an encrypted memory that encrypts data using an encryption algorithm executed by processor 802.

[0101] Memory 804 may be configured to store one or more applets 808, one or more counters 810, customer identifier 814, and one or more accounts 812, which may be virtual accounts. One or more applets 808 may include one or more software applications, such as Java® card applets, configured to run on one or more contactless cards. However, it should be understood that one or more applets 808 are not limited to Java card applets, but may be any software application that can operate on a contactless card or other device with limited memory. One or more counters 810 may include numeric counters sufficient to store integers. Customer identifier 814 may include a unique alphanumeric identifier assigned to a user of contactless card 102, and the identifier may distinguish the user of contactless card from other contactless card users. In some examples, customer identifier 814 may identify both the customer and the account assigned to that customer, and may also identify the contactless card 102 associated with the customer account. As described above, one or more accounts 812 may include thousands of one-time-use virtual accounts associated with the contactless card 102. One or more applets 808 of the contactless card 102 may be configured to manage one or more accounts 812 (e.g., select one or more accounts 812, mark the selected one or more accounts 812 as used, and transfer one or more accounts 812 to a mobile device for autofill via an autofill service).

[0102] The processor 802 and memory elements of the exemplary embodiments described above are illustrated with reference to contact pad 704, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of contact pad 704, or completely separate from it, or as further elements beyond the processor 802 and memory 804 elements located within contact pad 704 as described on pages 14 / 25 of the specification, CN 121420506 A.

[0103] In some examples, the contactless card 102 may include one or more antennas 818. One or more antennas 818 may be placed within the contactless card 102 and surrounding the processing circuitry 816 of contact pad 704. For example, one or more antennas 818 may be integrated with the processing circuitry 816, and one or more antennas 818 may be used with an external boost coil. As another example, one or more antennas 818 may be external to contact pad 704 and processing circuitry 816.

[0104] In one embodiment, the coil of the contactless card 102 may serve as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 102 by cutting off power or amplitude modulation. The contactless card 101 can infer data transmitted from the terminal by utilizing gaps in the contactless card's power connection, which can be functionally held by one or more capacitors. The contactless card 102 can communicate in reverse by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal by interference. More generally, using one or more antennas 818, processor 802 and / or memory 804, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth and / or Wi-Fi communication.

[0105] As explained above, the contactless card 102 can be built on a software platform operable on smart cards or other memory-limited devices, such as JavaCard, and one or more applications or applets can be securely executed. One or more applets 808 can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. One or more applets 808 may be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader, for example, a mobile device or point-of-sale terminal) and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag.

[0106] An example of an NDEF OTP is an NDEF short record layout (SR=1). In this example, one or more applets 808 may be configured to encode the OTP as a known type of text tag of NDEF type 4. In some examples, the NDEF message may include one or more records.One or more applets 808 can be configured to add one or more static tag records in addition to OTP records.

[0107] In some examples, one or more applets 808 can be configured to simulate RFID tags. RFID tags may include one or more polymorphic tags. In some examples, different password data is presented each time the tag is read, which can indicate the authenticity of the contactless card. Based on one or more applets 808, NFC reading of the tag can be processed, data can be transmitted to a server (such as a server in a banking system), and the data can be verified at the server.

[0108] In some examples, the contactless card 102 and the server may include certain data that allows the card to be correctly identified. The contactless card 102 may include one or more unique identifiers (not depicted). Each time a read operation occurs, one or more counters 810 can be configured to increment. In some examples, each time data is read from the contactless card 102 (e.g., read by a mobile device), one or more counters 810 are transmitted to the server for verification, and it is determined whether one or more counters 810 are equal to (as part of the verification) the server's counter.

[0109] One or more counters 810 can be configured to prevent replay attacks. For example, if ciphertext has been obtained and replayed, the ciphertext will be immediately rejected if one or more counters 810 have been read, used, or otherwise skipped. If one or more counters 810 have not been used, they can be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. Since there is no communication between one or more applets 808 on the contactless card 102, the contactless card 101 cannot determine one or more application transaction counters 810.

[0110] In some examples, one or more counters 810 may lose synchronization. In some examples, in response to accidental readings of transactions (such as reading at an angle) from page 15 / 25 of the specification 18 CN 121420506 A, one or more counters 810 may increment, but the application will not process one or more counters 810. In some examples, NFC may be enabled when the mobile device 10 is woken up, and the client device 104 may be configured to read available tags, but will not take action in response to the reading.

[0111] To keep one or more counters 810 synchronized, an application (such as a background application) can be executed, which will be configured to detect when the client device 104 wakes up and synchronizes with the bank system's server 108, indicating the reads that occur due to the detection, and then move the counter 710 forward. In other examples, a hashed one-time password can be used, making a certain window of asynchrony acceptable.For example, if within a threshold of 10, one or more counters 810 can be configured to move forward. However, if within a different threshold number, such as 10 or 1000, a request to perform resynchronization can be processed, which requests the user to tap, gesture, or otherwise indicate once or multiple times via one or more applications through their device. If one or more counters 810 increment in an appropriate sequence, it can be known that the user has done so.

[0112] The key diversification technique described herein with reference to one or more counters 810, a master key, and a diversification key is an example of an encryption and / or decryption key diversification technique. This example key diversification technique should not be considered as a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0113] During the creation process of the contactless card 102, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which can be used for encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and implemented by hardware in the contactless card 102. By using a key diversification process, one or more keys can be derived from a master key based on unique identifiable information for each entity that requires the key.

[0114] In some examples, to overcome the vulnerability of the 3DES algorithm, which may be susceptible to vulnerabilities, session keys (such as unique keys for each session) can be derived instead of using the master key; unique card-derived keys and counters can be used as diversification data. For example, each time the contactless card 102 is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and to perform encryption. This results in three layers of encryption. Session keys can be generated by one or more applets and derived using one or more algorithms (such as those defined in EMV 4.3, Volume 2, A1.3.1, Common Session Key Derivation) and an application transaction counter.

[0115] Furthermore, the increment for each card can be unique and can be assigned through personalization or algorithmically assigned using some identification information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5. In some examples, the increment can also vary during sequential reading, allowing a card to increment sequentially as 1, 3, 5, 2, 2… The specific sequence or algorithm sequence can be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0116] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format.

[0117] FIG9 is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. Sequence stream 900 may include a contactless card 102 and a client device 104, which may include an application 902 and a processor 904. Application 902 may be any one of App 204a, 204b, App 204c, or any other application executed on client device 104.

[0118] At line 908, application 902 communicates with contactless card 102 (e.g., after being brought near contactless card 102). Communication between application 902 and contactless card 102 involves contactless card 102 being sufficiently close to a card reader (not shown) of client device 104 to enable NFC data transfer between application 902 and contactless card 102.

[0119] At line 906, after communication has been established between the client device 104 and the contactless card 102, the contactless card 102 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when the contactless card 102 is read by application 902. In particular, this can happen when reading (e.g., NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a card reader application (e.g., application 902) can transmit a message (e.g., a mini-program selection message) with a mini-program ID that produces an NDEF. After confirming the selection, a sequence of selected file messages followed by a read file message can be transmitted. For example, this sequence may include "select capability file", "read capability file", and "select NDEF file". At this time, the counter value maintained by the contactless card 102 can be updated or incremented, which may be followed by "read NDEF file". At this point, a message that may include a header and a shared secret can be generated. A session key can then be generated. MAC ciphertext, which may include a header and a shared secret, can be created from the message. The MAC ciphertext can then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) can be encrypted using the session key. Afterward, the ciphertext and header can be concatenated, encoded in ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF File" message).

[0120] In some examples, the MAC ciphertext may be transmitted as an NDEF tag, and in other examples, the MAC ciphertext may be included as a Uniform Resource Indicator (e.g., as a formatted string). In some examples, application 902 may be configured to transmit a request to contactless card 102 that includes instructions to generate MAC ciphertext.

[0121] At line 910, the contactless card 102 sends the MAC ciphertext to the application 902. In some examples, the transmission of the MAC ciphertext occurs via NFC; however, this disclosure is not limited thereto. In other examples, such communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 912, the application 902 transmits the MAC ciphertext to the processor 904.

[0122] At line 914, the processor 904 verifies the MAC ciphertext according to instructions from the application 122. For example, the MAC ciphertext may be verified as explained below. In some examples, the verification of the MAC ciphertext may be performed by a device other than the client device 104, such as a server of a banking system that communicates data with the client device 104. For example, the processor 904 may output the MAC ciphertext for transmission to a server of the banking system, which can verify the MAC ciphertext. In some examples, the MAC ciphertext may serve as a digital signature for verification purposes. Other digital signature algorithms (such as public-key asymmetric algorithms, e.g., digital signature algorithms and RSA algorithms) or zero-knowledge protocols may be used to perform this verification.

[0123] Figure 10 illustrates an NDEF short record layout (SR=1) data structure 1000 according to an example embodiment. One or more applets can be configured to encode OTP as a known type text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: known type, text, encoded English (en); applet ID: D2760000850101; capability: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalized parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a known index for providing actual dynamic authentication data.

[0124] Figure 11 illustrates a schematic diagram of a system 1100 configured to implement one or more embodiments of the present disclosure. As explained below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. Cryptographic keys may include symmetric keys, which can be used for data encryption and decryption. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from the master key based on unique identifiable information for each entity that requires the key.

[0125] Regarding master key management, for each part of a portfolio on which one or more applets are issued, two issuer master keys 1102 and 1126 will be required.For example, the first master key 1102 may include the issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 1126 may include the issuer data encryption key (Iss-Key-DEK). As further explained herein, these two issuer master keys 1102 and 1126 are diversified into card master key 1108 and 1120, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 522 and the Derived Key Index (pDKI) 1124, which are background data, can be used to identify which issuer master key 1102 or 1126 is used in the encryption process used for authentication. The system performing authentication can be configured to retrieve the values ​​of pNPR 1122 and pDKI 1124 of the contactless card during authentication.

[0126] In some examples, to improve the security of the solution, session keys (such as unique keys for each session) can be derived, but as explained above, unique card-derived keys and counters can be used as diversification data instead of using the master key. For example, different keys can be used each time the card is used in an operation to create a Message Authentication Code (MAC) and to perform encryption. Regarding session key generation, the keys used to generate ciphertext and encrypt data in one or more applets can include session keys based on the card's unique keys (Card-Key-Auth 1108 and Card-Key-Dek 1120). Session keys (Auth-Session-Key 1130 and DEK-Session-Key 1110) can be generated by one or more applets and derived using one or more algorithms and the Application Transaction Counter (pATC) 1104. To fit the data into one or more algorithms, only the 2 lower-order bytes of the 4-byte pATC 1104 are used. In some examples, the four-byte session key derivation method may include: F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(four bytes) F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(four bytes) SK:={(ALG(MK)[F1])||ALG(MK[F2]}, where ALG may include 3DES ECB and MK may include the card-uniquely derived master key.

[0127] As described herein, one or more MAC session keys may be derived using the lower two bytes of the pATC 1104 counter.On each tap of the contactless card, pATC 1104 is configured to update, and the card master key Card-Key-AUTH 508 and Card-Key-DEK 1120 are further diversified into session keys Aut-Session-Key 1130 and DEK-Session-KEY 1110. pATC 1104 can be initialized to zero during personalization or applet initialization. In some examples, pATC counter 1104 can be initialized during or before personalization and can be configured to increment by one on each NDEF read.

[0128] Furthermore, the update for each card can be unique and can be assigned through personalization or algorithmically through pUID or other identification information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, the update can also vary during sequential reads, such that a card can increment repeatedly in the sequence 1, 3, 5, 2, 2, ... The specific sequence or algorithm sequence can be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0129] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it can include only authentication data and an 8-byte random number followed by a MAC of the authentication data. In some examples, the random number can precede the ciphertext A and can be a block length. In other examples, there can be no limit to the length of the random number. In further examples, the total data (i.e., the random number ciphertext) can be a multiple of the block size. In these examples, an additional 8-byte block can be added to match the block generated by the MAC algorithm. As another example, if the algorithm used uses a 16-byte block, it can be a multiple of the block size, or the output can be automatically or manually padded to a multiple of the block size.

[0130] The MAC can be performed by the function key (AUT-Session-Key) 1130. The data specified in the ciphertext can be processed using the `javacard.signature` method: `ALG_DES_MAC8_ISO9797_1_M2_ALG3` is related to the EMV ARQC authentication method. The key used for this calculation can include the session key `AUT-Session-Key 1130`, as explained above. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys.As explained below, AUT-Session-Key 1130 can be used to perform MAC operations on data 1106, and the resulting data or ciphertext An 1114 and random number RND can be encrypted using DEK-Session-Key 1110 to create ciphertext B or output 1118 sent in the message specification page 18 / 25 21 CN 121420506 A.

[0131] In some examples, one or more HSM commands can be processed for decryption, such that the last 16 (binary, hexadecimal 32) bytes can include 3DES symmetric encryption in CBC mode using a random number with zero IV followed by MAC authentication data. The key used for this encryption can include a session key DEK-Session-Key 1110 derived from Card-Key-DEK 1120. In this case, the ATC value used for the session key derivation is the least significant byte of counter pATC 1104.

[0132] The following format represents an example embodiment in binary form. In addition, in some examples, the first byte can be set to ASCII "A".

[0133]

[0134]

[0135] Another exemplary format is shown below. In this example, the label can be encoded in hexadecimal format. Specification 19 / 25 pages 22 CN 121420506 A

[0136]

[0137]

[0138] The UID field of the received message can be extracted to derive the card master key (Card-Key-AUTH 925 and Card-Key-DEK 930) for that particular card from the master key Iss-Key-AUTH 905 and Iss-Key-DEK 910. Using the card master key (Card-Key-Auth 508 and Card-Key-DEK 1120), the counter (pATC) field of the received message can be used to derive the session key (AUT-Session-Key 1130 and DEK-Session-Key 1110) for that particular card. The ciphertext B 1118 can be decrypted using the DEK-Session-KEY, yielding the ciphertext An 1114 and RND, which can then be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the message's Ver, UID, and pATC fields, can be processed via a cipher MAC using the recreated Aut-Session-Key to create a MAC output, such as MAC'. If MAC' matches the ciphertext An 1114, this indicates that both message decryption and the MAC check have passed. The pATC can then be read to determine its validity.

[0139] During the authentication session, one or more ciphertexts may be generated by one or more applications. For example, one or more ciphertexts may be generated as a 3DES MAC using method 2, filled with one or more session keys (such as AUT-Session-Key 1130) using ISO 9797-1 algorithm 3, via a specification page 20 / 25, 23 CN 121420506 A. Input data 1106 may take the following forms: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include a length in bytes. In some examples, the shared secret may be generated by one or more random number generators that may be configured to ensure that the random numbers are unpredictable through one or more security processes. In some examples, the shared secret may include a random 4-byte binary number known to the authentication service and injected into the card during personalization. During the authentication session, the shared secret is not provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte to the end of the input data, and 0x'00' bytes may be added to the end of the resulting data up to an 8-byte boundary. The resulting ciphertext may be 8 bytes in length.

[0140] In some examples, one advantage of encrypting the MAC ciphertext with a non-shared random number as the first block is that it acts as an initialization vector when using a CBC (blockchain) mode with a symmetric encryption algorithm. This allows for "scrambling" between blocks without the need to pre-establish a fixed or dynamic IV.

[0141] By including the application transaction counter (pATC) as part of the data included in the MAC ciphertext, the authentication service can be configured to determine whether the value transmitted in the plaintext data has been tampered with. Furthermore, by including the version in one or more ciphertexts, it is difficult for an attacker to deliberately forge application versions to attempt to reduce the strength of the ciphertext solution. In some examples, the pATC may start from zero and be updated to 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message, and authentication will be rejected. In some examples, when the pATC is greater than a previously received value, it can be evaluated to determine if it is within an acceptable range or threshold, and if it exceeds or falls outside the range or threshold, authentication can be considered failed or unreliable. In MAC operation 1112, data 1106 is processed via MAC using AUT-Session-Key 1130 to produce MAC output (ciphertext A) 1114, which is encrypted.

[0142] To provide additional protection against brute-force attacks on the key on the exposure card, it is desirable to encrypt the MAC ciphertext 1114. In some examples, the data or ciphertext An 1114 to be included in the ciphertext may include: a random number (8), and ciphertext (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that may be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include DEK-Session-Key 1110. In encryption operation 1116, the data or ciphertext An 1114 and RND are processed using DEK-Session-Key 510 to produce encrypted data, namely ciphertext B 1118. The data 1114 may be encrypted using 3DES in cipher block chaining mode to ensure that an attacker must perform any attack on all ciphertexts. As a non-limiting example, other algorithms, such as Advanced Encryption Standard (AES), may be used. In some examples, an initialization vector of 0x'00000000000000000' can be used. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used, as correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.

[0143] In order for the authentication service to verify one or more ciphertexts provided by one or more applets, the following data must be transmitted from one or more applets to the mobile device in plaintext during the authentication session: determining the version number of the encryption method used and the message format used to verify the ciphertext, which allows the method to be changed in the future; a pUID used to retrieve the encrypted asset and derive the card key; and a pATC used to derive the session key for the ciphertext.

[0144] Figure 12 illustrates a method 1200 for generating ciphertext. For example, at box 1202, the Network Profile Record ID (pNPR) and the Derivative Key Index (pDKI) can be used to identify which issuer master key is used in the cipher process used for authentication. In some examples, the method may include performing authentication to retrieve the values ​​of the contactless card's pNPR and pDKI during authentication.

[0145] At box 1204, the issuer master key can be diversified by combining the issuer master key with the card's unique ID number (pUID) and the PAN serial number (PSN) of one or more applets (e.g., payment applets).

[0146] At block 1206, Card-Key-Auth and Card-Key-DEK (unique card keys) can be created by diversifying the issuer's master key to generate session keys that can be used to generate MAC ciphertext.

[0147] At block 1208, the keys used to generate ciphertext and encrypt data in one or more applets may include session keys based on the card's unique key (Card-Key-Auth and Card-Key-DEK) of block 1030. In some examples, these session keys may be generated by one or more applets and derived using pATC to obtain session keys Aut-Session-Key and DEK-Session-Key.

[0148] Figure 13 depicts an exemplary process 1300 illustrating key diversification according to one example. Initially, the sender and receiver may be provided with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value, which can be updated at box 1302, and other data (such as the data to be protected), which can be securely shared with the receiver.

[0149] At box 1304, the counter value can be encrypted by the sender using a data encryption master key to generate a data encryption-derived session key, and the counter value can also be encrypted by the sender using a data integrity master key to generate a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value can be used during the two encryptions.

[0150] In some examples, the counter value may not be encrypted. In these examples, the counter can be transmitted between the sender and receiver in plaintext (i.e., without encryption).

[0151] At box 1306, the data to be protected is processed by the sender using a data integrity session key and a cryptographic MAC algorithm with a cryptographic MAC operation. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0152] At block 1308, the data to be protected can be encrypted by the sender using a session key derived from the data encryption in conjunction with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data (e.g., each 8 bytes long) and then encrypted using a second session key (DEK-Session-Key).

[0153] At block 1310, the encrypted MAC is transmitted from the sender to the receiver. The encrypted MAC has sufficient information to identify additional secret information (such as a shared secret, master key, etc.) for verification of the ciphertext.

[0154] At block 1312, the receiver independently derives two derived session keys from the two master keys using the received counter value, as explained above.

[0155] At block 1314, the session key derived from data encryption is used in conjunction with a symmetric decryption operation to decrypt the protected data. The exchanged data is then subjected to additional processing. In some examples, after extracting the MAC, it is expected that the MAC will be reproduced and matched. For example, when verifying ciphertext, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

[0156] At block 1316, the session key derived from data integrity is used in conjunction with a cryptographic MAC operation to verify that the protected data has not been modified.

[0157] Some examples of the methods described herein can advantageously confirm when authentication is determined to be successful when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is correct. Only if decryption is successful and produces the correct MAC value can the MAC be correct. Successful decryption indicates that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key was created using a master key known only to the sender (e.g., transmitting device) and the receiver (e.g., receiving device), it can be assumed that the original contactless card that created and encrypted the MAC is genuine. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform authentication operations.

[0158] Thereafter, both derived session keys can be discarded, and the next iteration of data exchange will update the counter values ​​(returning to box 1302), and a new set of session keys can be created (at box 1310). In some examples, combined random data can be discarded.

[0159] FIG14 illustrates a method 1400 for card activation according to an example embodiment. For example, card activation can be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components previously explained, such as contactless card 102, client device 104, and server 108.

[0160] In block 1402, the card can be configured to dynamically generate data. In some examples, the data may include information such as an account number, card identifier, card verification value, or phone number, which can be transferred from the card to the device. In some examples, one or more portions of the data may be encrypted via the systems and methods disclosed herein.

[0161] In block 1404, one or more portions of the dynamically generated data may be transmitted to the device's application via NFC or other wireless communications.For example, tapping the card near the device can allow an application on the device to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to assist in card activation, tapping the card can guide the device or prompt the customer to download the associated application from an app store to activate the card. In some examples, the user can be prompted to make a gesture, place or orient the card fully toward a surface of the device, such as at an angle or flat on the surface of the device, close to or near the surface of the device. In response to the full gesture, placement and / or orientation of the card, the device can continue to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0162] In block 1406, one or more portions of the data can be transmitted to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data can be transmitted from the device to the card issuer server for card activation.

[0163] In block 1408, one or more servers can decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, one or more servers can receive encrypted data from the device and can decrypt it to compare the received data with recorded data accessible to one or more servers. If a successful match is found by comparing one or more decrypted portions of the data with the results from one or more servers, the card can be activated. If a failure is found by comparing one or more decrypted portions of the data with the results from one or more servers, one or more processes can occur. For example, in response to a determination of a failure to match, the user can be prompted to tap, swipe, or wave the card again. In this case, there can be a predetermined threshold, including the number of attempts allowed to allow the user to activate the card. Alternatively, the user can receive a notification, such as a message on his or her device indicating that the card verification attempt was unsuccessful, and call, email, or text message to an associated service to assist in activating the card; or receive another notification, such as a phone call on his or her device indicating that the card verification attempt was unsuccessful, and call, email, or text message to an associated service to assist in activating the card; or receive another notification, such as an email indicating that the card verification attempt was unsuccessful, and call, email, or text message to an associated service to assist in activating the card.

[0164] In block 1410, one or more servers can transmit a return message based on the successful activation of the card. For example, the device can be configured to receive output from one or more servers indicating that the card has been successfully activated by one or more servers (see page 23 / 25 of the manual, CN 121420506 A). The device can also be configured to display a message indicating successful card activation. Once activated, the card can be configured to stop dynamically generating data to prevent fraudulent use.In this way, the card may subsequently fail to activate, and one or more servers will be notified that the card has been activated.

[0165] The various elements of the device previously described with reference to the accompanying drawings may include a variety of hardware elements, software elements, or combinations thereof. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, application programming interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware and / or software elements can vary depending on many factors, such as desired computing speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints as desired for a given implementation.

[0166] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, causes the machine to manufacture the logic to perform the techniques described herein. Such representations (referred to as “IP cores”) may be stored on tangible, machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that manufacture the logic or processor. For example, some embodiments may be implemented using a machine-readable medium or article of manufacture that may store instructions or instruction sets that, if executed by a machine, may cause the machine to perform methods and / or operations according to the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor or the like, and may be implemented using any suitable combination of hardware and / or software.Machine-readable media or articles of art may include, for example, any suitable type of memory cell, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage cell, such as memory, removable or non-removable medium, erasable or non-erasable medium, writable or rewritable medium, digital or analog medium, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic medium, magneto-optical medium, removable memory card or disk, various types of digital multifunction disk (DVD), magnetic tape, cassette tape or the like. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0167] The components and features of the above-described devices may be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates and / or single-chip architectures. Furthermore, where appropriate, the features of the device may be implemented using a microcontroller, a programmable logic array and / or a microprocessor or any combination thereof. It should be noted that hardware, firmware and / or software elements may be collectively referred to herein or individually as “logic” or “circuit”.

[0168] It will be appreciated that the exemplary device shown in the block diagrams above may represent one example of a functional description of many potential implementations. Therefore, the division, omission or inclusion of block functions depicted in the figures does not imply that hardware components, circuits, software and / or elements used to implement these functions will necessarily be divided, omitted or included in the embodiments.

[0169] At least one computer-readable storage medium may include instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein. Specification 24 / 25 pages 27 CN 121420506 A

[0170] Some embodiments may be described using the expressions “an embodiment” or “an embodiment” and their derivatives. These terms mean that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. The phrase “in one embodiment” appearing in different places in the specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise stated, the foregoing features are considered to be used together in any combination. Therefore, any feature discussed individually may be used in combination with each other unless it is explicitly stated that these features are incompatible with each other.

[0171] It should be emphasized that the abstract of this disclosure is provided to allow the reader to quickly grasp the essence of the technical disclosure. When submitting this abstract, it should be understood that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features have been grouped together in a single embodiment for the purpose of simplifying this disclosure.The methods disclosed herein should not be construed as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the following claims are incorporated herein by reference, wherein each claim exists independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as concise English equivalents of the respective terms “comprising” and “wherein”. Furthermore, the terms “first,” “second,” “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0172] The above description includes examples of the disclosed architecture. Of course, it is impossible to describe every possible combination of components and / or methods, but those skilled in the art will recognize that many other combinations and permutations are possible. Therefore, this novel architecture is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0173] The foregoing description of the exemplary embodiments is provided for purposes of illustration and description. It is not intended to be exhaustive or to limit this disclosure to the precise form disclosed. Many modifications and variations are possible with respect to this disclosure. It is intended that the scope of this disclosure be limited not by this detailed description, but by the claims appended herein. Future applications filed based on priority to this application may claim the disclosed subject matter in different ways and may generally include any set of one or more limitations disclosed herein or otherwise shown.Instruction manual, page 25 / 25; Figure 1 (CN 121420506 A); Figure 2 (CN 121420506 A); Figure 3 (CN 121420506 A); Figure 4 (CN 121420506 A); Figure 5 (CN 121420506 A); Figure 6 (CN 121420506 A); Figure 7 (CN 121420506 A); Figure 8 (CN 121420506 A); Figure 9 (CN 121420506 A); Figure 10 (CN 121420506 A). Figure 11 of the instruction manual, page 38 of page 10 / 14, CN 121420506 A; Figure 12 of the instruction manual, page 40 of page 12 / 14, CN 121420506 A; Figure 13 of the instruction manual, page 41 of page 13 / 14, CN 121420506 A; Figure 14 of the instruction manual, page 42 of page 14 / 14, CN 121420506 A.

Claims

1. A computer-implemented method, the method comprising: Receive a first request to execute computer-executable instructions, the computer-executable instructions request being data from an enterprise server; Receive a second request from the enterprise server to authenticate the first request; Based on the second request, the short-range wireless communication module of the computing device is used to scan for authentication from the contactless card; In response to determining that the first request is genuine based on authentication data, a response is transmitted to the enterprise server, causing the enterprise server to send the data; as well as In response to receiving data sent by the enterprise server, the computer-executable instructions from the first request are executed via a web browser.

2. The computer-implemented method according to claim 1, wherein, Receiving the second request causes the web browser to execute a predetermined computer program from a set of computer programs associated with the web server, the set of computer programs including extensions, plug-ins, components, and add-ons.

3. The computer-implemented method according to claim 2, wherein, The predetermined computer program is associated with the enterprise server.

4. The computer-implemented method according to claim 1, wherein, Authenticating the first request includes verifying that the first request was initiated by an authorized user.

5. The computer-implemented method according to claim 1, wherein, Determining that the first request is genuine based on authentication information includes: verifying the ciphertext through the predetermined computer program, and in response, transmitting a response to the enterprise server through the predetermined computer program, causing the enterprise server to send data for the computer-executable instructions.

6. The computer-implemented method according to claim 1, wherein, Determining that the first request is genuine based on the authentication data includes: transmitting at least ciphertext via a predetermined computer program for the enterprise server to receive, and in response to the enterprise server verifying the ciphertext, the enterprise server sending data for the computer-executable instructions.

7. The computer-implemented method according to claim 1, wherein, The computer-executable instructions are part of a secure transaction being executed on a webpage via the web browser.

8. The computer-implemented method according to claim 7, wherein, The secure transaction includes at least one of a set of transactions, including login transactions, business transactions, and data transfer transactions.

9. The computer-implemented method according to claim 1, wherein, The enterprise server is at least one of a group of servers, including a bank server, an authentication server, and an intermediate server.

10. A computing device, the computing device comprising: processor; and The memory stores instructions that, when executed by the processor, configure the device to: Receive a first request to execute computer-executable instructions, the computer-executable instructions request being data from an enterprise server; Receive a second request from the enterprise server to authenticate the first request; Based on the second request, the short-range wireless communication module of the computing device is used to scan for authentication from the contactless card; In response to determining that the first request is genuine based on authentication data, a response is transmitted to the enterprise server, causing the enterprise server to send the data; as well as In response to receiving data sent by the enterprise server, the computer-executable instructions from the first request are executed via a web browser.

11. The computing device according to claim 10, wherein, Receiving the second request causes the web browser to execute a predetermined computer program from a set of computer programs associated with the web server, the set of computer programs including extensions, plug-ins, components, and add-ons.

12. The computing device according to claim 11, wherein, The predetermined computer program is associated with the enterprise server.

13. The computing device according to claim 10, wherein, Authenticating the first request includes verifying that the first request was initiated by an authorized user.

14. The computing device according to claim 10, wherein, Determining that the first request is genuine based on authentication information includes: verifying the ciphertext through the predetermined computer program, and in response, transmitting a response to the enterprise server through the predetermined computer program, causing the enterprise server to send data for the computer-executable instructions.

15. The computing device according to claim 10, wherein, Determining that the first request is genuine based on the authentication data includes: transmitting at least ciphertext via a predetermined computer program for the enterprise server to receive, and in response to the enterprise server verifying the ciphertext, the enterprise server sending data for the computer-executable instructions.

16. The computing device according to claim 10, wherein, The computer-executable instructions are part of a secure transaction being executed on a webpage via the web browser.

17. The computing device according to claim 16, wherein, The secure transaction includes at least one of a set of transactions, including login transactions, business transactions, and data transfer transactions.

18. The computing device according to claim 10, wherein, The enterprise server is at least one of a group of servers, including a bank server, an authentication server, and an intermediate server.

Images