Techniques for secure data exchange

Abstract

Systems and methods for performing secure exchange of cryptographic keys (e.g., public keys) between two devices are disclosed. One or more initialization keys are stored at both devices. In some embodiments, at least one device (e.g., a reader device) stores the initialization key (e.g., a symmetric key, an asymmetric key pair) in local memory as part of the device's manufacturing process. The second device (e.g., a thin client device) is capable of receiving the initialization key from a receiving cloud (e.g., a server computer configured to perform terminal processing). The initialization key is used to perform a secure exchange of the corresponding public keys of the devices. Once these public keys have been exchanged, the devices are able to continue establishing a secure connection, which enables subsequent operations to be performed.

Description

[0001] Cross-references to related applications

[0002] This international application claims priority to U.S. Provisional Patent Application No. 62 / 881,231, filed July 31, 2019, entitled “Techniques for Secure Data Exchanges,” the entire disclosure of which is incorporated herein by reference for all purposes. Background Technology

[0003] Traditionally, to establish a secure channel between two devices, the devices need to exchange public keys. This exchange needs to be secure. A common method for sharing public keys is to utilize certificates authorized by a certification authority. In these systems, the authority's public key and certificate need to be stored on each device. In the case of chained certificates, even more public keys would need to be stored on each device. The process used to establish secure channels can be improved. Summary of the Invention

[0004] One embodiment of the present invention relates to a method comprising: identifying the presence of a reader device by a protocol management computer using a near-field communication channel; obtaining from a remote server computer a first initialization key associated with the reader device and a second initialization key corresponding to the first initialization key, the second initialization key being previously stored at the reader device during the manufacturing process of the reader device; receiving by the protocol management computer via the near-field communication channel the first encrypted data including the first public key associated with the reader device; and transmitting by the protocol management computer via the near-field communication channel the second encrypted data including the second public key associated with the protocol management computer, wherein at least one of the first encrypted data or the second encrypted data is encrypted at least partially based on at least one of the first initialization key or the second initialization key.

[0005] Another embodiment of the invention relates to a protocol management computer (e.g., a thin client device) programmed to perform the methods described above.

[0006] Another embodiment of the invention relates to a reader device programmed to perform operations including: storing a first initialization key during the manufacturing process of the reader device; receiving communication from a protocol management computer via a near-field communication channel; transmitting, in response to receiving the communication, first encrypted data including a first public key associated with the reader device via the near-field communication channel; and receiving, via the near-field communication channel, second encrypted data including a second public key associated with the protocol management computer, from the protocol management computer, wherein at least one of the first encrypted data or the second encrypted data is encrypted at least partially based on the first initialization key or the second initialization key stored at the protocol management computer.

[0007] More detailed information about embodiments of the present invention can be found in the detailed description and accompanying drawings. Attached Figure Description

[0008] Figure 1 A block diagram of a system for exchanging data between devices using different communication protocols is shown according to some implementation schemes.

[0009] Figure 2 A flowchart of a protocol for securely exchanging public keys between thin clients and reader devices, according to some implementation schemes, is shown.

[0010] Figure 3 A flowchart of another protocol for securely exchanging public keys between a thin client device and a reader device, according to some implementation schemes, is shown.

[0011] Figure 4 A flowchart of a protocol for establishing a secure connection between a thin client and a reader device, according to some implementation schemes, is shown.

[0012] Figure 5 A block diagram illustrating a scheme for secure messaging according to some implementation schemes is shown.

[0013] Figure 6 A flowchart illustrating an exemplary method for securely exchanging a public key between two devices according to some implementation schemes is shown.

[0014] Figure 7 A block diagram of a thin client device according to some implementation schemes is depicted.

[0015] Figure 8 A block diagram of a reader device according to some implementation schemes is depicted. Detailed Implementation

[0016] Implementations may include methods and systems capable of facilitating secure key exchange between two devices. For example, a thin client (TC) (e.g., an access device) may be positioned between a reader device (e.g., a card reader) and a receiving cloud (e.g., a cloud-based server), which may be configured to perform terminal processing (e.g., point-of-sale terminal processing, credit / debit card terminal processing). The receiving cloud (referred to as the "kernel in the cloud" (KiC)) may utilize a first protocol (e.g., The thin client can also be configured to communicate with a portable device (e.g., a payment device) via a reader device, which can be configured to utilize the same protocol (e.g., first-generation protocol). First-generation protocols) or different protocols (e.g., The reader device can communicate via a communication protocol (e.g., Bluetooth Low Energy). (BLE) communicates with thin clients to exchange transaction data between portable devices and KiC.

[0017] To establish secure communication between the reader and the TC via BLE, an elliptic curve Diffie-Hellman (ECDH) key protocol scheme (0 static, 2 ephemeral ECDH keys with verification keys) can be used (e.g., based on the National Institute of Standards and Technology's Special Publication, SP800-56A, Revision 3) to derive a symmetric shared private key for payload encryption and MAC generation. However, before implementing the key protocol scheme, the public key between the reader and the TC needs to be securely shared.

[0018] Using the techniques disclosed herein, an initialization key is provided to the TC and reader device before the ECDH key protocol scheme is implemented. In some implementations, the initialization key may be stored at the reader device during the manufacturing (or initialization) process before being obtained by the end user. The same initialization key can be provided to the TC upon request (e.g., by the receiving cloud). The TC and reader device can use the initialization key to securely exchange a public key, ensuring that the public key cannot be intercepted and / or obtained by unauthorized parties. The following describes the process in conjunction with... Figure 2 (and similarly in Figure 3The protocols defined in this paper enable TCs and reader devices to encrypt and verify the authenticity and validity of messages using these public keys. These techniques offer advantages over conventional systems that rely on certificates provided by certification authorities, including public keys from other devices. The TC and reader devices in the provided examples do not require storing certification authority certificates or public keys. Therefore, the techniques presented herein reduce the amount of data stored. Furthermore, utilizing the protocols and initialization keys discussed herein eliminates the burden of initially relying on certification authorities to obtain certificates.

[0019] This article discusses several aspects related to providing secure communication between thin clients (TCs) and reader devices. Some of these aspects involve establishing trust between the TC and the reader device, performing mutual authentication, and protecting the communication between the TC and the reader device.

[0020] Before discussing embodiments of the present invention, some terms will be described.

[0021] "Portable device" can include any suitable device that can be operated by a user. Examples of portable devices can include mobile communication devices (e.g., mobile phones), payment devices (e.g., credit cards, debit cards, etc.), user access devices (such as access badges), etc. Portable devices can store sensitive information (such as payment credentials (e.g., master account number, token, expiry date, etc.)) and access credentials. Portable devices can be used to conduct financial transactions (such as providing payment credentials to merchants). Suitable payment devices can be handheld and compact, allowing them to fit into a user's wallet and / or pocket (e.g., pocket-sized). Exemplary payment devices can include smart cards, keychain devices (such as Speedpass, available for purchase from Exxon-Mobil Corp.). TM Other examples of payment devices include payment cards, smart media, transponders, etc. If the payment device is in the form of a debit card, credit card, or smart card, it may also optionally have features such as a magnetic stripe. Such devices can operate in contact or contactless modes.

[0022] A “mobile communication device” can be an example of a “communication device” that can be easily transported. Examples of remote communication capabilities include the use of mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that provides access to networks (such as the Internet or a private network). Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptops, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices (such as smartwatches, fitness trackers, ankle bracelets, rings, earrings, etc.) and automobiles with remote communication capabilities. In some embodiments, a mobile communication device can act as a payment device (e.g., a mobile communication device can store and transmit payment credentials for transactions). Mobile communication devices may also include vehicles (such as automobiles) with remote communication capabilities.

[0023] "Reader device" refers to a data input device that reads data from a card (e.g., a smart card, magnetic stripe card, etc.), a mobile communication device, or any suitable storage medium.

[0024] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used for verification.

[0025] A “payment credential” may include any suitable information associated with an account (e.g., a payment account and / or a payment device associated with the account). Such information may be directly related to the account or may be derived from account-related information. Examples of account information may include a PAN (primary account or “account number”), username, expiry date, and check values ​​such as CVV, dCW, CW2, dCW2, and CVC3 values.

[0026] A "token" can be a substitute value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc. For example, a payment token can include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For instance, the token "4900 0000 0000 0001" can be used in place of the PAN "41470900 0000 1234". In some implementations, the token can be "reserved format" and can have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some implementations, the token can be used in place of the PAN to initiate, authorize, process, or resolve payment transactions, or to represent the original credential in other systems where the original credential would typically be provided. In some implementations, payment tokens can be generated in such a way that it may be impossible to calculably derive the original PAN or other account identifier from the token value. Furthermore, in some implementations, the token format can be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0027] "User" can include an individual. In some implementations, a user can be associated with one or more personal accounts and / or mobile devices. In some implementations, a user may also be referred to as a cardholder, account holder, or consumer.

[0028] "Acceptance Cloud" can be a cloud-based system that performs point-of-sale terminal processing for payment acceptance. The server computer of the Acceptance Cloud can be used to communicate with the merchant's computer, transaction processing computer, authentication computer, or any other suitable system. The server computer (also referred to as "remote server computer") can be located in a remote location relative to the location of the reader device and / or protocol management computer / thin client device.

[0029] The "protocol management computer" can be any suitable device that provides protocol management functionality for the eventual exchange of messages between the cloud and portable devices. The protocol management computer may include a reader device and / or may be communicatively connected to a reader device. The protocol management computer may be a thin client device.

[0030] A "thin client device" can be any suitable device configured to establish a connection with a server-based computing environment (e.g., a cloud server). In some implementations, a thin client can execute software and / or applications that provide a limited set of operations and / or functions.

[0031] A “reader device” can include any suitable means for reading data (e.g., from a portable device). A reader device can use any suitable contact or contactless operating mode to transmit or receive data from or associate with a mobile communication device or portable device. For example, exemplary reader devices can include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and / or a mobile device. In some embodiments, the reader device can be a separate device from the access device and can be configured to communicate via one or more wireless communication protocols (e.g., Bluetooth Low Energy). (BLE) Near Field Communication (NFC) and other technologies communicate with the access device.

[0032] A shared key (also known as a symmetric key) is a piece of data shared between two parties. The shared key can be the symmetric key of a symmetric cryptosystem. It can be a password, passphrase, alphanumeric code, or any suitable token. The shared key can be used to encrypt and decrypt data exchanged between the two parties.

[0033] An "initialization key" is a shared key that can be used to protect (e.g., encrypt) communications used by an initialization program.

[0034] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one example, a server computer can be a database server coupled to a web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combinations thereof for serving requests from one or more client computers. A server computer may include one or more computing devices and may use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0035] "Processor" can refer to any suitable one or more data computing devices. A processor can include one or more microprocessors working together to perform a desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0036] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include a non-transitory computer-readable medium storing instructions that can be executed by a processor to implement a desired method. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0037] Figure 1 A block diagram of a system including users 102 and 104, portable devices 106 and 108, reader device 110, protocol management computer 112 (e.g., an example of an access device), remote server computer 114 (e.g., a server computer remote relative to area 120), and communication network 130 is shown. Users 102 and 104, portable devices 106 and 108, reader device 110, and protocol management computer 112 are depicted as being located within area 120. Portable device 106 and remote server computer 114 can be configured to use a first protocol (e.g., ... The first-generation protocol is used for communication, while the portable device 108 can be configured to use a second communication protocol (e.g., ...). The second-generation protocol is used for communication. In some implementations, the remote server computer 114 can be configured to receive a cloud (e.g., a cloud-based server) that is capable of performing terminal processing for payment transactions.

[0038] Portable devices 106 and 108 exchange communication with reader device 110 (e.g., card reader), which in turn exchanges communication with protocol management computer 112 (e.g., thin client), which in turn exchanges communication with remote server computer 114 (e.g., receiving cloud) via communication network 130 (e.g., via...). (First-generation protocol). Specifically, reader device 110 can be used to communicate with portable devices 106 and 108 and to transfer data between portable devices 106-108 and protocol management computer 112. Protocol management computer 112 (e.g., a thin client) is configured to act as a decoding relay, which enables portable devices (e.g., portable device 106 or portable device 108) to exchange transaction information with remote server computer 114 during transactions.

[0039] Prior to data exchange, reader device 110 and protocol management computer 112 are configured to perform operations to securely exchange a public key. In some embodiments, to achieve secure exchange of the public key, reader device 110 and protocol management computer 112 are configured with a shared key (e.g., initialization key 132). In some embodiments, reader device 110 is configured (e.g., configured by its manufacturer) to store the initialization key 132 during the manufacturing process of reader device 110. The manufacturer (not depicted) may transmit the initialization key 132 at any suitable time (e.g., via a user interface, electronic message, application programming interface, etc.) to an accepting cloud (e.g., remote server computer 114) that stores the initialization key (e.g., as part of a shared key 134) and associates it with an identifier of reader device 110 (e.g., serial number, manufacturer identifier, any suitable alphanumeric code, etc.). Protocol management computer 112 is configured to request the shared key (e.g., initialization key 132) from remote server computer 114. Once both reader device 110 and protocol management computer 112 know the shared key, they can exchange public keys by encrypting their respective public keys with the shared key (e.g., an initialization key). Reference Figure 2 and Figure 3 An exemplary protocol for securely performing public key exchange is discussed in further detail. Secure communication between the TC and the reader device can be established via BLE using an elliptic curve Diffie-Hellman (ECDH) key protocol scheme. (See references.) Figure 4 An exemplary protocol for establishing a secure channel between two devices is described in further detail. Once configured for secure communication, reader device 110 and protocol management computer 112 can be used to enable secure data exchange between portable devices 106-108 and remote server computer 114.

[0040] For example, users 102 and 104 may be customers attempting to purchase items at a physical store (e.g., area 120). Portable device 106 is a newer type of credit card carried by user 102, portable device 108 is an older type of credit card carried by user 104, reader device 110 is a card reader located within the store building, protocol management computer 112 may be a terminal device and / or portable device operated by the store (e.g., the merchant's mobile phone), and remote server computer 114 is a remotely located server computer that provides cloud-based terminal processing for payment transactions via a communication network 130 (e.g., the Internet). In some embodiments, the functionality of protocol management computer 112 is part of an application installed on the merchant's user device (e.g., a user-operated smartphone, laptop, desktop computer, tablet, or any suitable device).

[0041] In one example, user 102 uses portable device 106 to conduct a transaction. In some embodiments, portable device 106 may be inserted, slid over, and / or kept close to (e.g., touched) reader device 110. In some embodiments, reader device 110 may communicate using a first communication protocol. When portable device 106 and protocol management computer 112 initiate a transaction via reader device 110, portable device 106 and remote server computer 114 attempt to exchange transaction information. In some embodiments, remote server computer 114 may seek payment account details from portable device 106, while portable device 106 may seek transaction data (e.g., terminal transaction parameters, language preferences, transaction currency codes, etc.) from remote server computer 114. To exempt remote server computer 114 from having to execute other communication protocols besides the first communication protocol, protocol management computer 112 acts as a communication conversion or abstraction module, wherein protocol management computer 112 intercepts, filters, converts, and / or filters communications between remote server computer 114 and any portable device (e.g., portable device 106) attempting to conduct a transaction with remote server computer 114.

[0042] The communication protocol between the protocol management computer 112 and the portable device 106 (via the reader device 110) may depend on their respective capabilities (e.g., what protocols they share, such as contact, contactless, NFC, Bluetooth, Wi-Fi, QR codes, etc.). The protocol management computer 112 acts as a communication conversion or abstraction module, which exempts the remote server computer 114 from supporting multiple communication protocols, with one conversion / abstraction module for each type of portable device 106-108.

[0043] Specifically, the protocol management computer 112 can communicate using different communication protocols (e.g., both a first communication protocol and a second communication protocol). When receiving communication from the portable device via the reader device 110 under a communication protocol incompatible with the remote server computer 114 (e.g., the second communication protocol), the protocol management computer 112 converts the received communication to be compatible with the remote server computer 114 (e.g., conforming to the first communication protocol) and forwards the converted communication. Similarly, when receiving communication from the remote server computer 114, the protocol management computer 112 converts the communication to a communication protocol incompatible with the remote server computer 114 and then forwards the converted communication to the portable device via the reader device 110.

[0044] In some implementations, user 104 initiates a contact transaction by inserting portable device 108 into reader device 110, enabling communication under a second communication protocol to be exchanged between portable device 106 and protocol management computer 112 via reader device 110. Since communication under the second communication protocol is exchanged between portable device 108 and protocol management computer 112 via reader device 110, protocol management computer 112 converts the communication received from portable device 108 into a first communication protocol and transmits the converted communication to remote server computer 114. Remote server computer 114 can generate responses to the converted communication and send these responses to protocol management computer 112 in the form of communication under the first communication protocol. In response, protocol management computer 112 can convert the communication received from remote server computer 114 into a second communication protocol and transmit the converted communication to portable device 108 via reader device 110.

[0045] At different times, user 102 can initiate contactless transactions by keeping portable device 106 close to reader device 110 (or protocol management computer 112), enabling communication under a first communication protocol to be exchanged between portable device 106 and protocol management computer 112. In some embodiments, reader device 110 communicates via wired or wireless communication channels (e.g., The data received from the portable device 106 is transmitted to the protocol management computer 112. In this example, the protocol management computer 112 determines that the portable device 106 and the remote server computer 114 use compatible communication protocols (e.g., both use the same communication protocol). Therefore, since communication under the first communication protocol is exchanged between the portable device 106 and the protocol management computer 112 (via the reader device 110), the protocol management computer 112 forwards the communication received from the portable device 106 to the remote server computer 114 without performing a conversion. Similarly, when communication is received from the remote server computer 114, the protocol management computer 112 forwards the communication to the portable device 106 via the reader 110 without performing a conversion.

[0046] In some implementations, the first communication protocol discussed above may correspond to the EuroPay Master Visa (EMV) second-generation standard (EMV 2.0), while the second communication protocol may correspond to the EMV first-generation standard (EMV 1.0). Each EMV standard is associated with a number of payment schemes. Each payment scheme in EMV 1.0 defines its own payment processing module, where each module includes functions, logic, or data for processing contact or contactless transactions performed using the associated payment scheme. When processing a transaction, the POS terminal (in this case, the remote server computer 114) will need to identify which payment processing module to use and then allow that module to take over the exchange of commands with the portable device (wherein the commands are sent via the exchanged communication, and the commands include data). EMV 1.0 can be a stateful communication protocol. In other words, the EMV 1.0 payment processing module can be expected to exchange commands in a specific order.

[0047] EMV 2.0 can be a stateless, data-driven communication protocol that can be associated with a single processing module capable of handling different scenarios. However, generally, a POS terminal configured to handle EMV 2.0 transactions may not be able to handle EMV 1.0 transactions. Instead of having a merchant operate a first POS terminal for EMV 1.0 transactions and a second POS terminal for EMV 2.0 transactions, some implementations allow the merchant to operate a single physical card reader (i.e., protocol management computer 112) capable of handling any payment scheme associated with either the EMV 1.0 or EMV 2.0 communication protocol. The card reader may be communicatively coupled to a PA (i.e., remote server computer 114) in the cloud, which handles payment processing via a single communication protocol (e.g., a first communication protocol).

[0048] Therefore, in response to a transaction initiated by a credit / debit card, reader device 110 and / or protocol management computer 112 may be responsible for identifying the communication protocol (e.g., EMV 1.0 or EMV 2.0), payment scheme, and / or payment processing module based on the credit card. If the identified communication protocol, payment scheme, or processing module is incompatible with the communication protocol utilized by remote server computer 114, protocol management computer 112 will convert or transform the communication from the portable device into a format compatible with the communication protocol utilized by remote server computer 114. Meanwhile, remote server computer 114 is responsible for processing the payment based on the converted / transformed communication. In this document, protocol management computer 112 may be referred to as a “thin client” or “thin client device.” The resulting separation of concerns results in multiple modular components of software (e.g., the thin client, and the accepting cloud to which remote server computer 114 is a part), which is generally less complex than the software of a single component (e.g., a single local POS terminal, where the local POS terminal is a complete payment accepting system fully contained within a physical store) configured to process transactions using any communication protocol.

[0049] In some implementations, EMV 2.0 is based on REST or JSON. For example, EMV 2.0 compliant communication is in XML or JSON format and can be transmitted and / or received from a REST interface.

[0050] Generally, updates to payment processing logic are more common than updates to communication protocols. Therefore, relocating payment processing software from the local POS terminal to the accepting cloud (e.g., a remote server computer 114 is part of it) makes it easier to update the payment processing logic, since payment processing network operators no longer need to update the local POS terminal (e.g., perform any updates by physically accessing the card reader).

[0051] Zone 120 is intended to correspond to the physical location of the resource provider (e.g., a physical store), where portable devices 106-108 are placed (e.g., a few inches or feet) close to reader device 110 and / or protocol management computer 112 to execute transactions. However, Figure 1 The setup described herein is not intended to be limiting. In other embodiments, for example, portable devices 106-108 may be remotely located from protocol management computer 112.

[0052] Protocol management computer 112 is intended to depict one or more access devices located at a resource provider's location. For example, protocol management computer 112 may include a reader device (e.g., reader device 110 or different reader devices) for retrieving transaction information from credit or debit cards used by store customers. In some embodiments, protocol management computer 112 is a thin client device connected to remote server computer 114 via a Wi-Fi or Ethernet connection over the Internet (i.e., communications network 130). Generally, protocol management computer 112 provides a unified transaction interface that enables remote server computer 114 to transact with a wider range of portable devices. Compared to a local payment acceptance system, some embodiments may separate payment acceptance functionality between two or three physically decoupled devices: protocol management computer 112 and remote server computer 114 or reader device 110, protocol management computer 112 and remote server computer 114. In particular, protocol management computer 112 may include logic for communicating with portable devices via various communication protocols, managing status and / or processes (e.g., for status communication protocols), and translating communication from one protocol to another. It should be noted that the state or procedure of a stateful communication protocol can affect how the protocol is used to transmit information. Specifically, the state or procedure of a stateful communication protocol can specify the number of commands to be sent, the order of the commands, and which commands carry which data. See below for reference. Figure 7 The protocol management computer 112 is discussed in further detail.

[0053] Remote server computer 114 may correspond to a cloud-based system or one or more server computer systems located remotely in region 120, the remote server computer including logic (e.g., payment processing logic) for transacting with portable devices. In some embodiments, remote server computer 114 hosts a payment processing module referred to as "Payment Acceptance (PA) in the cloud." In particular, the PA in the cloud may be a unified payment processing module capable of processing transactions performed using one or more payment schemes under EMV 2.0.

[0054] Portable devices 106-108 can each be a portable device as defined above, wherein portable device 106 is configured to execute transactions using a first communication protocol, and portable device 108 is configured to execute transactions using a second communication protocol. For example, portable device 106 can be a newer type of credit or debit card compatible with EMV 2.0, while portable device 108 can be an older type of credit or debit card compatible with EMV 1.0.

[0055] Protocol management computer 112 and remote server computer 114 are communicatively coupled to communication network 130. Communication network 130 can be of any type and may include one or more communication networks. Examples of communication network 130 include, but are not limited to, the Internet, wide area network (WAN), local area network (LAN), Ethernet, public or private networks, wired networks, wireless networks, and combinations thereof. Different communication protocols can be used to facilitate communication, including both wired and wireless protocols, such as the IEEE 802.XX protocol suite, TCP / IP, IPX, SAN, AppleTalk, Bluetooth, and other protocols. Generally, communication network 130 may include any communication network or infrastructure that facilitates communication between computing devices.

[0056] Protocol management computer 112 and reader device 110 are communicatively coupled to each other via the same or different networks having area 120, such networks as the Internet, wide area network (WAN), local area network (LAN), Ethernet, public or private network, wired network, wireless network, and combinations thereof. Different communication protocols can be used to facilitate communication, including both wired and wireless protocols, such as the IEEE 802.XX protocol suite, TCP / IP, IPX, SAN, AppleTalk, Bluetooth, and other protocols.

[0057] Figure 2 The following are illustrations of a thin client device 202 according to some embodiments. Figure 1 Example of protocol management computer 112) and reader device 204 Figure 1 The flowchart illustrates a protocol 200 for securely exchanging public keys between reader devices 110 (example). The steps can be performed in any suitable order. In some embodiments, more or fewer steps may be included in the following protocol. The steps can be performed via near-field communication. In some embodiments, the thin client device 202 operates as a contactless payment card (tap payment card) and communicates with the reader device 204 via Application Protocol Data Unit (APDU) communication (e.g., APDU commands and / or responses as defined by ISO / IEC 7816-4).

[0058] In some implementations, the thin client device 202 and the reader device 204 securely store security assets and provide sufficient protection against the release of data at rest. Each device also supports cryptographic algorithms and parameters (e.g., ECC P-256, random number generation, AES-GCM, SHA-256, ECDH, HMAC, ECDSA, etc.). In some implementations, the reader device 204 is registered and initialized as a trusted device to use cloud-based acceptance services by interacting with the KiC, or by the manufacturer of the reader device interacting with the KiC discussed herein (remote server computer 206 being one example). In some implementations, the thin client device 202 and the reader device 204 communicate using a wireless protocol such as Bluetooth Low Energy. (BLE) and / or near-field communication (e.g., communication between two electronic devices within a distance of approximately 4 cm or less using a near-field communication protocol). In some embodiments, the reader device 204 can be manufactured, configured, and initialized in a secure environment. In some embodiments, the thin client device 202 and the reader device 204 are configured with predetermined ECC domain parameters, and both devices can be configured to perform ECC key generation technology.

[0059] At S208, during the manufacturing process, several parameters are securely stored on or generated by the reader device 204 for use in the initialization and key agreement phases. For example, a 128-bit AES-GCM key K_init can be securely stored on the reader device 204. This initialization key can be used to provide confidentiality and integrity when exchanging security assets during initialization procedures performed by both devices. In some cases, the reader device 204 generates a static elliptic curve cryptography (ECC) key pair (SS). R_Auth SP R_Auth This unique identifier, KiC_Reader_ID, can be used during the key negotiation phase of the verification process. It can be generated by the reader. This unique identifier is paired with the generated verification key pair (SS). R_Auth SP R_Auth Related to this. The following table illustrates some data generated, stored, and exchanged between the thin client device 202 and the reader device 204 during the manufacturing process (or at least before the initialization procedure discussed below starting from S220).

[0060]

[0061] At S210, the key K_init (e.g., by the manufacturer of reader device 204) is provided to KiC (e.g., remote server computer 206). K_init may be provided to KiC via any suitable electronic message, communication, user interface (e.g., an interface provided by KiC), or application programming interface (API) (e.g., an API hosted by remote server computer 206).

[0062] At S212, the thin client device 202 detects the reader device 204. For example, the thin client device 202 may be configured to periodically transmit requests for a device identifier. In some embodiments, the reader device 204 periodically and / or transmits its device identifier (e.g., an alphanumeric identifier, serial number, etc.) in response to receiving a request for a device identifier. In some embodiments, the reader device 204 detects the thin client device 202 at least in part based on receiving a message from the thin client device 202 (e.g., a message indicating a request for a device identifier). In some embodiments, the reader device 204 transmits its device identifier to the thin client device 202 in response to receiving a message (e.g., a message indicating a request for a device identifier). In some embodiments, the thin client device 202 detects the reader device 204 at least in part based on receiving a message from the reader device 204 (e.g., a message including the device identifier of the reader device 204).

[0063] At S214, in response to the detection of reader device 204, thin client device 202 transmits a request for a shared key (e.g., a shared key associated with reader device 204, such as the shared key provided to remote server computer 206 at S210). In some embodiments, the request includes the device identifier of reader device 204 obtained during the detection step at S212.

[0064] At step S216, the remote server computer 206 transmits the shared key associated with the reader device 204. Specifically, the shared key does not need to be associated with the reader device 204; instead, in some cases, the shared key may be associated with the manufacturer of the reader device 204. Therefore, in some cases, all reader devices manufactured by a given manufacturer can share the same shared key.

[0065] At S218, upon receiving the shared key or at any appropriate time, the thin client device 202 stores the shared key (K_init) in local memory.

[0066] In some implementations, an initialization procedure can be performed using both the thin client device 202 and the reader device 204. During the initialization procedure, the thin client device 202 and the reader device 204 exchange security assets (e.g., corresponding public keys) encrypted using the keys K_init obtained at S208 and S210, respectively. During the initialization phase, the thin client device 202 can operate in a specific operating mode (e.g., "tap play" mode) and can communicate with the reader device 204 via a communication interface (e.g., using an ISO 7816 interface). An applet (e.g., referred to as a VTRT applet) is initialized on the thin client device 202 and used to exchange Application Protocol Data Unit (APDU) commands and responses with the reader device 204.

[0067] The initialization process can begin at S220, where reader device 204 selects the application identifier (AID) of the VTRT applet and transmits a message (e.g., a SELECT AID command) to thin client device 202 (e.g., via an APDU select command or response). In some embodiments, this selection may be in response to receiving one or more APDU commands and / or responses from thin client device 202 and / or transmitting one or more APDU commands and / or responses to the thin client device.

[0068] In some implementations, the SELECT AID command is used based on the following format:

[0069] CLA INS P1 P2 Lc Command Data Le 0x00 0xA4 0x04 0x00 0x0B VTRT AID 00

[0070] At S222, thin client device 202 generates a unique identifier (e.g., a 16-byte unique identifier called “TC_Reader_Init_ID”), a random number (e.g., a 16-byte random number called “Nonce_TC”), and an initialization vector (e.g., a 12-byte initialization vector (IV) called “IV1”). Nonce_TC and IV1 can be generated by thin client device 202 based on the requirements specified in NIST SP 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, Revision 3 April 2018 (SP800-56Ar3). Thin client device 202 responds to the message received at S220 (e.g., an APDU selection command) using the encrypted value. The encrypted value can be generated using any suitable encryption algorithm (e.g., the Authentication Encryption Standard (AES_GCM) with Galois / Counter mode or any suitable encryption algorithm). In some implementations, the encryption algorithm takes a shared key (e.g., K_init) and a concatenated value including TC_Reader_Init_ID and Nonce_TC as input.

[0071] At S224, the encrypted value is concatenated with IV1, and the concatenated value, along with the data field "status word" set to value 9000, is transmitted to reader device 204 (e.g., in an APDU response such as a SELECT AID command response). Status word 9000 is used to indicate that a message was provided as part of the initialization procedure. Therefore, the APDU response transmitted at S224 may include AES_GCM(K_init,TC_Reader_Init_ID||Nonce_TC)||IV1 and status word 9000.

[0072] In some implementations, the response to the SELECT AID response is utilized based on the following format:

[0073]

[0074]

[0075] The returned tail data can include any suitable value, such as:

[0076] 0x9000: Indicates that the application selected successfully.

[0077] 0x6A81: Indicator command not supported, card blocked.

[0078] 0x6A82: File not found

[0079] 0x6283: Indicates that the application is blocked.

[0080] At S226, reader device 204 receives an APDU message (e.g., a SELECT AID command response) and decrypts it using the IV1 obtained from the message. Reader device 204 generates the encrypted value using AES_GCM or any suitable encryption algorithm. For example, it can be generated by providing K_init(SP) R_Auth The concatenation of KiC_Reader_ID and Nonce_TC) and the Bluetooth identifier associated with the reader device 204 (e.g., BLE name) (referred to as BLE_Name_Reader) are used as inputs to the encryption algorithm (represented as AES_GCM(K_init,SP)). R_Auth The encrypted value is generated using `||KiC_Reader_ID||Nonce_TC,BLE_Name_Reader)`. `BLE_Name_Reader` indicates the name associated with the reader device 204, which can be used for the BLE communication protocol. `BLE_Name_Reader` can be protected for integrity as an Additional Authentication Data (AAD) field in AES_GCM. The encrypted value is concatenated with `BLE_Name_Reader`. The reader device 204 generates another initialization vector (referred to as "IV2") and uses IV2 to encrypt messages containing the encrypted value (e.g., SET DATA commands). In some implementations, IV2 can be generated by providing IV1 as input to a hash algorithm (e.g., SHA-256, SHA 512, etc.) and obtaining the leftmost 12 bytes of the resulting hash value. Therefore, IV2 can be equal to SHA-256(IV1).

[0081] At step S228, reader device 204 transmits a message (e.g., a SET DATA command) to thin client device 202. In some implementations, the SET DATA command is used based on the following format:

[0082]

[0083]

[0084] At S230, thin client device 202 receives an APDU message (SET DATA command) and decrypts it using IV2 (e.g., generated by thin client device 202 via SHA-256 (IV1)). Thin client device 202 verifies the Nonce_TC from the message by comparing the Nonce_TC received at S230 with the Nonce_TC generated at S222. If the Nonce_TCs do not match, thin client device 202 can discard the message, and processing can stop. If the Nonce_TCs match, thin client device 202 can consider the verified message and generate an ECC P-256 key pair (e.g., each referred to as "SS"). TC_Auth "and SP" TC_Auth The thin client device 202 generates a random seed (e.g., a 16-byte random seed referred to as "Seed_TC") and associates one or both keys with any suitable combination of KiC_Reader_ID, BLE_Name_Reader, and / or Seed_TC. In some implementations, the thin client device 202 verifies SP800-56Ar3 based on section 5.6.2.2.3. R_Auth (The public key of reader device 204). Thin client device 202 uses K_init(SP) with any suitable encryption algorithm (e.g., AES_GCM). TC_Auth The encrypted value is generated by combining a concatenation of Seed_TC and a hash value (a concatenation of KiC_Reader_UD and TC_Reader_Init_ID) generated using a hash algorithm (e.g., SHA-256) with state 9000. In some implementations, the encrypted value is generated by AES_GCM(K_init, SP... TC_Auth The thin client device 202 generates another initialization vector (referred to as "IV3") and uses IV3 to encrypt a message (e.g., a SET DATA response) including the encrypted value and status word 9000. In some implementations, IV3 is generated by feeding IV2 as input to a hash algorithm (e.g., SHA-256, SHA 512, etc.) and obtaining the leftmost 12 bytes of the resulting hash value. Therefore, IV3 can be equal to SHA-256(IV2).

[0085] At S232, the thin client device 202 transmits a message (e.g., a SET DATA command response) to the reader device 204. The SET DATA command response can be used in the following format:

[0086]

[0087] Response data may include tail data, such as:

[0088] 0x9000: Indicates that the Set Data command succeeded.

[0089] 0x6980: Indicates an incorrect data length. This error message can be returned when the expected number of bytes is not received.

[0090] 0x6981: Indicates that the TC cannot recognize the reader. This may occur when the TC cannot verify the returned Nonce_TC.

[0091] 0x6982: Indicates that AES-GCM verification failed.

[0092] 0x6983: Indicates that the data could not be decrypted correctly.

[0093] 0x6984: Indicates any appropriate error not listed above.

[0094] At S234, reader device 204 decrypts the received message (e.g., a SET DATA command response) using IV3 (e.g., generated by the reader device via SHA-256 (IV2)). Reader device 204 verifies the message by independently calculating a hash value using a hash algorithm (e.g., SHA-256) and a concatenation of KiC_Reader_ID and TC_Reader_Init_ID (KiC_Reader_ID||TC_Reader_Init_ID) as input. The resulting hash value is compared with the hash of KiC_Reader_ID||TC_Reader_Init_ID obtained from the received message. If the hash values ​​match, the message is considered to have passed verification. Otherwise, reader device 204 may discard the message, and processing stops. If the message has passed verification, reader device 204 stores the public key of thin client device 202 and the Seed_TC obtained from the message. In some implementations, reader device 204 may store the public key (SP) of thin client device 202. TC_Auth The correlation between the Seed_TC obtained from the message using TC_Reader_Init_ID.

[0095] At S234, if the received message is verified at S234, the reader device 204 transmits an APDU message (e.g., a SESSION READY command) indicating that the message transmitted at S232 was successfully received.

[0096] In some implementations, the SESSION READY command is provided in the following format:

[0097]

[0098] During the initialization phase, communication can be aborted in the event of any type of error (such as invalid data, timeout, tearing, operational failure, etc.). Different status words are defined for potential errors. In some implementations, before operation stops, the device identifying the error transmits an APDU message with a status word indicating the specific error to other devices.

[0099] Although not depicted, in some implementations, the thin client device 202 will send a response to the Session Ready command as: 0x9000: indicating successful receipt of the Session Ready command, 0x6985: indicating unexpected response data, or 0x9656: indicating another error.

[0100] If the thin client device 202 does not receive the SESSION READY command, it can abort communication. All generated keys and random values ​​are securely removed from the reader device 204 and the thin client device 202.

[0101] Although not depicted, in some implementations, if the thin client device 202 has a power reset, a RESET command can be sent to the reader device 204 specifying that a new session key needs to be negotiated.

[0102] The Power Reset command can be defined as: (for reader device 204 to thin client device 202) such as using ECDSA and SS R_Auth The signed KiC_Reader_ID||PWRST, or (for thin client device 202 to reader device 204) as if using ECDSA and SS TC_Auth The signature is TC_Reader_Init_ID||PWRST. In some implementations, if the signature is valid within a power reset command, the thin client device 202 and the reader device 204 discard the current session key and securely remove all stored security assets.

[0103] Although not depicted, in some implementations, timers and transaction counters associated with the session key are reset. These timers and transaction counters can be used as parameters specifying the lifespan of the session key. The session key can be renegotiated after an “X” configurable transaction or several seconds. In some implementations, a power reset command takes precedence over any other operation. Therefore, in some cases, a power reset received by the TC or reader can interrupt and discard other operations.

[0104] Pairing reset refers to returning to the initialization procedure (starting from S220), where reader device 204 and thin client device 202 share their verification public key via NFC using a applet. In the event of a secure channel communication error between thin client device 202 and reader device 204 that cannot be resolved by a power reset (such as failure to verify signature, KC_MAC_TAG, Session_MAC_Tag, etc.), thin client device 202 and reader device 204 can request pairing reset by sending a PAIRING RESET command. After pairing reset, thin client device 202 and reader device 204 return to the initialization procedure (starting from S220), where they exchange the verification public key and other parameters via NFC using a applet.

[0105] The PAIRING RESET command can be formatted as follows (for reader device 204 to thin client device 202): such as using ECDSA and SS R_Auth The signed KiC_Reader_ID||PRNGRST, and (for thin client device 202 to reader device 204): using ECDSA and SS TC_Auth The signature is TC_Reader_Init_ID||PRNGRST. In some implementations, if the signature is verified, the thin client device 202 and the reader device 204 securely erase all (or some) of the previously stored security assets.

[0106] In summary, the table below illustrates some of the data generated, stored, and exchanged between the thin client device 202 and the reader device 204 during the initialization process.

[0107]

[0108] In some implementations, multiple reader devices are connected to a single thin client device using a unique BLE name (e.g., BLE_Name_Reader corresponding to each reader device) and a unique reader ID (e.g., KiC_Reader_ID corresponding to each reader device). A unique key pair (SS) associated with BLE_Name_Reader and KiC_Reader_ID is generated for each initialized reader device. TC_Auth SP TC_Auth (A session key negotiation can be independently established for each reader device via BLE using BLE_Name_Reader and unique parameters and authentication keys, as per protocol 400. The following section combines...) Figure 4The following description is provided. Prior to session key negotiation, the thin client device and reader device pair to communicate via BLE. For successful BLE pairing, the reader device can describe its BLE name (BLE_Name_reader) sent to the thin client device during the initialization procedure described above. The thin client device can search for readers initialized using BLE_Name_Reader. The thin client device can refuse connections to readers that have not been successfully initialized and can cause BLE connection failure using appropriate error messages, such as: "No initialized reader found." In some implementations, if the thin client device detects more than one initialized reader, it prompts the user (e.g., via an interface provided by the thin client device) to select a reader (e.g., based on BLE_Name_Reader).

[0109] Figure 3 The following are illustrations of a thin client device 300 according to some embodiments. Figure 2 Example of thin client device 202) and reader device 304 Figure 2 The flowchart below illustrates another protocol 300 for securely exchanging public keys between reader devices 204 (example). The following steps can be performed in any suitable order. In some embodiments, more or fewer steps may be included in the following protocol. The following steps can be performed via near-field communication. In some embodiments, thin client device 302 can function as a contactless payment card (tap payment card) and communicate with reader device 304 via Application Protocol Data Unit (APDU) communication (e.g., APDU commands and / or responses as defined by ISO / IEC 7816-4). Like thin client device 202 and reader device 204, thin client device 302 and reader device 304 can be configured to support cryptographic algorithms and parameters. Reader device 304 can be combined with... Figure 2 The discussion follows a similar approach, registering and initializing the device as a trusted device.

[0110] In some implementations, the thin client device 302 and the reader device 304 securely store security assets and provide sufficient protection against the release of data at rest. Each device also supports cryptographic algorithms and parameters (e.g., ECC P-256, random number generation, AES-GCM, SHA-256, ECDH, HMAC, ECDSA, etc.). In some implementations, the reader device 304 is registered and initialized as a trusted device to use cloud-based acceptance services (e.g., via the manufacturer of the reader device interacting with the KiC discussed herein (remote server computer 306 being one example)). In some implementations, the thin client device 302 and the reader device 304 communicate using a wireless protocol such as Bluetooth Low Energy. (BLE) and / or near-field communication (e.g., communication between two electronic devices within a distance of approximately 4 cm or less using a near-field communication protocol). In some embodiments, the reader device 304 can be manufactured, configured, and initialized in a secure environment. In some embodiments, the thin client device 302 and the reader device 304 are configured with predetermined ECC domain parameters, and both devices can be configured to perform ECC key generation technology.

[0111] At S308, during the manufacturing process, a static elliptic curve cryptography (ECC) key pair (e.g., a private / public key pair, referred to as the initialization key pair, or respectively referred to as SS) can be generated (or obtained, for example, through the manufacturer). R_Init SP R_Init ,) and at least one key (e.g., SS) stored at reader device 304. R_Init In some implementations, the key pair may be static and used for each reader manufactured by the manufacturer. Additionally, the ECC key pair (SS) associated with TC device 302... TC_Init SP TC_Init The public key (SP) TC_Init The initialization key (SS) can be stored at reader device 304. R_Init SP R_Init ,SS TC_Init SP TC_Init This can be used to provide confidentiality and integrity when exchanging secure assets during initialization procedures performed by the reader and thin client devices. In some cases, reader device 304 can generate additional static elliptic curve cryptography (ECC) key pairs (SS). R_Auth SP R_Auth It can be used during the key negotiation phase of verification (see reference). Figure 4(For a more detailed discussion). The unique identifier KiC_Reader_ID can be generated by the reader. This unique identifier is paired with the generated verification key pair (SS). R_Auth SP R_Auth Related to this. The following table illustrates some data generated, stored, and exchanged between the thin client device 302 and the reader device 304 during the manufacturing process (or at least before the initialization procedure discussed below starting from S320).

[0112]

[0113] At S310, SP R_Init (For example, provided to KiC (e.g., remote server computer 306) by the manufacturer of reader device 304, or by reader device 304, etc.). SP R_Init It can be provided to KiC via any suitable electronic message, communication, user interface (e.g., an interface provided by KiC), or application programming interface (API) (e.g., an API hosted by a remote server computer 306).

[0114] At S312, the thin client device 302 exchanges data with the reader device 304 via a near-field communication channel (or vice versa). In some embodiments, the thin client device 302 requests data from the reader device 304, which transmits its device identifier (e.g., alphanumeric identifier, serial number, etc.), in response to receiving a request.

[0115] At S314, in response to the exchange at S312, the thin client device 302 transmits the initialization key (SP) from the remote server computer 306. R_Init The request includes, in some embodiments, the device identifier of the reader device 304.

[0116] At S316, the remote server computer 306 transmits the initialization key (SP). R_Init Specifically, the initialization key does not need to be associated with reader device 304; instead, in some cases, the initialization key / key pair can be the same across all reader devices. In some cases, all reader devices manufactured by a given manufacturer can share the same initialization key / key pair.

[0117] At S318, upon receiving the initialization key (SP) R_Init At any appropriate time, the thin client device 302 stores the initialization key in local memory.

[0118] In some implementations, an initialization procedure can be performed using a thin client device 302 and a reader device 304. During the initialization procedure, the thin client device 302 and the reader device 304 exchange security assets (e.g., different from SPs). Init (The corresponding public key). During the initialization phase, the thin client device 302 can operate in a specific operating mode (e.g., "tap play" mode) and can communicate with the reader device 304 via a communication interface (e.g., using an ISO 7816 interface). An applet (e.g., referred to as a VTRT applet) is initialized on the thin client device 302 and is used to exchange Application Protocol Data Unit (APDU) commands and responses with the reader device 304.

[0119] The initialization process can begin in S320, where reader device 304 selects the application identifier (AID) of the VTRT applet and transmits a message (e.g., a SELECT AID command) to thin client device 302 (e.g., via an APDU select command or response). In some embodiments, this selection may be in response to receiving one or more APDU commands and / or responses from thin client device 302 and / or transmitting one or more APDU commands and / or responses to that thin client device.

[0120] In some implementations, the SELECT AID command is used based on the following format:

[0121] CLA INS P1 P2 Lc Command Data Le 0x00 0xA4 0x04 0x00 0x0B VTRT AID 00

[0122] At S322, the thin client device 302 generates a unique identifier (e.g., a 16-byte unique identifier called "TC_Reader_Init_ID"), a random number (e.g., a 16-byte random number called "Nonce_TC"), and a value derived from the SP. R_InitThe first symmetric key SK1 is Nonce_TC. Nonce_TC and SK1 can be generated by the thin client device 302 based on the requirements specified in NIST SP 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, Revision 3 April 2018 (SP800-56Ar3). The thin client device 302 responds to a message received at S320 (e.g., an APDU selection command) using the encrypted value. The encrypted value can be generated using any suitable encryption algorithm (e.g., the Authentication Encryption Standard (AES_GCM) with Galois / Counter mode or any suitable encryption algorithm). In some implementations, the encryption algorithm takes the first symmetric key SK1 and a concatenated value including TC_Reader_Init_ID and Nonce_TC as input.

[0123] At S324, the encrypted value is concatenated with Nonce_TC, and the concatenated value is transmitted along with the data field "status word" set to value 9000 (e.g., as an APDU response, such as a SELECT AID command response). Status word 9000 is used to indicate that a message was provided as part of an initialization procedure. Therefore, the APDU response transmitted at S324 may include AES_GCM(SK1,TC_Reader_Init_ID||Nonce_TC)||Nonce_TC and status word 9000. It should be understood that in some implementations, the format of the specific data transmitted as a message and / or the data in the message provided in the example may differ.

[0124] In some implementations, the response to the SELECT AID response is utilized based on the following format:

[0125]

[0126] The returned tail data can include any suitable value, such as:

[0127] 0x9000: Indicates that the application selected successfully.

[0128] 0x6A81: Indicator command not supported, card blocked.

[0129] 0x6A82: File not found

[0130] 0x6283: Indicates that the application is blocked.

[0131] At S326, reader device 304 receives an APDU message (e.g., a SELECT AID command response) and uses SK1 (when using stored SS) R_Init After independently generating SK1 from the Nonce_TC obtained from the message, it is decrypted. Reader device 304 generates the encrypted value using AES_GCM or any suitable encryption algorithm. For example, it can be obtained by providing SK1(SP). R_Auth The concatenation of KiC_Reader_ID and Nonce_TC, along with the Bluetooth identifier (e.g., BLE name) associated with reader device 304 (referred to as BLE_Name_Reader), serves as input to the encryption algorithm (represented as AES_GCM(SK1,SP)). R_Auth The encrypted value is generated using the formula ||KiC_Reader_ID||Nonce_TC,BLE_Name_Reader). BLE_Name_Reader indicates the name associated with the reader device 304, which can be used for the BLE communication protocol. BLE_Name_Reader can be protected for integrity as an Additional Authentication Data (AAD) field in AES_GCM. The encrypted value is concatenated with BLE_Name_Reader. The reader device 304 uses SK1 to generate a second symmetric key (referred to as "SK2") and uses SK2 to encrypt messages including the encrypted value (e.g., a SET DATA command). In some implementations, SK2 may be a portion of SHA-256 (SK1) (e.g., the leftmost 12 bytes).

[0132] At S328, reader device 304 transmits a message (e.g., a SET DATA command) to thin client device 302. In some embodiments, the SET DATA command is utilized based on the following format. It should be understood that in some embodiments, the format of the specific data transmitted in the message and / or the data in the message provided in the example may differ.

[0133]

[0134] At S330, thin client device 302 receives an APDU message (SET DATA command) and decrypts it using SK2 (e.g., calculated by thin client device 302 via SHA_256 (SK1)). Thin client device 302 verifies the Nonce_TC in the message by comparing the Nonce_TC received at S330 with the Nonce_TC generated at S322. If the Nonce_TCs do not match, thin client device 302 can discard the message, and processing can stop. If the Nonce_TCs match, thin client device 302 can consider the verified message and generate an ECC P-256 key pair (e.g., each referred to as "SS"). TC_Auth "and SP" TC_Auth The thin client device 302 generates a random seed (e.g., a 16-byte random seed referred to as "Seed_TC") and associates one or both keys with any suitable combination of KiC_Reader_ID, BLE_Name_Reader, and / or Seed_TC. In some implementations, the thin client device 302 verifies the SP800-56Ar3 based on section 5.6.2.2.3. R_Auth (Public key of reader device 304). Thin client device 302 uses SK1 (SP) TC_Auth The concatenation of Seed_TC and the hash value generated by a hash algorithm (e.g., SHA-256) and state 9000 are used to generate an encrypted value using any suitable encryption algorithm (e.g., AES_GCM). In some implementations, the encrypted value is generated by AES_GCM (SS... Init SP TC_Auth The thin client device 302 generates another symmetric key (referred to as "SK3") from SK2 and SK3 to encrypt messages including encrypted values ​​and status words 9000 (e.g., a SETDATA response). In some implementations, SK3 can be calculated using SHA-256 (SK2).

[0135] At S332, the thin client device 302 transmits a message (e.g., a SET DATA command response) to the reader device 304. The SET DATA command response can be utilized according to the following format. It should be understood that in some embodiments, the format of the specific data transmitted in the message and / or the data in the message provided in the example may differ.

[0136]

[0137] Response data may include tail data, such as:

[0138] 0x9000: Indicates that the Set Data command succeeded.

[0139] 0x6980: Indicates an incorrect data length. This error message can be returned when the expected number of bytes is not received.

[0140] 0x6981: Indicates that the TC cannot recognize the reader. This may occur when the TC cannot verify the returned Nonce_TC.

[0141] 0x6982: Indicates that AES-GCM verification failed.

[0142] 0x6983: Indicates that the data could not be decrypted correctly.

[0143] 0x6984: Indicates any appropriate error not listed above.

[0144] At S334, reader device 304 decrypts the received message (e.g., a SET DATA command response) using SK3 (e.g., calculated by reader device 304 via SHA-256 (SK2)). Reader device 304 verifies the message at least in part based on independently calculated SK3. If the message fails verification, reader device 304 can discard the message and processing stops. If the message passes verification, reader device 304 stores the public key SP of thin client device 302. TC_Auth And Seed_TC obtained from the message. In some implementations, reader device 204 may store the public key (SP) of thin client device 302. TC_Auth The correlation between the Seed_TC obtained from the message using TC_Reader_Init_ID.

[0145] At S334, if the message received at S334 passes the verification, the reader device 204 transmits an APDU message (e.g., a SESSION READY command) indicating that the message transmitted at S332 was successfully received.

[0146] In some implementations, the SESSION READY command is provided in the following format:

[0147]

[0148] During the initialization phase, communication can be aborted in the event of any type of error (such as invalid data, timeout, tearing, operational failure, etc.). Different status words are defined for potential errors. In some implementations, before operation stops, the device identifying the error transmits an APDU message with a status word indicating the specific error to other devices.

[0149] Although not depicted, in some implementations, the thin client device 302 will send a response to the Session Ready command as: 0x9000: indicating successful receipt of the Session Ready command, 0x6985: indicating unexpected response data, or 0x9656: indicating another error.

[0150] If the thin client device 302 does not receive the SESSION READY command, it can abort communication. All generated keys and random values ​​are securely removed from the reader device 304 and the thin client device 302.

[0151] Although not depicted, in some implementations, if the thin client device 302 has a power reset capability, a RESET command can be sent to the reader device 304 specifying that a new session key needs to be negotiated.

[0152] The Power Reset command can be defined as: (for reader device 304, for thin client device 302) such as using ECDSA and SS R_Auth The signed KiC_Reader_ID||PWRST, or (for thin client device 302 to reader device 304) as if using ECDSA and SS TC_Auth The signature is TC_Reader_Init_ID||PWRST. In some implementations, if the signature is valid within a power reset command, the thin client device 302 and the reader device 304 discard the current session key and securely remove all stored security assets.

[0153] Although not depicted, in some implementations, timers and transaction counters associated with the session key are reset. These timers and transaction counters can be used as parameters specifying the lifespan of the session key. The session key can be renegotiated after an “X” configurable transaction or several seconds. In some implementations, a power reset command takes precedence over any other operation. Therefore, in some cases, a power reset received by the TC or reader can interrupt and discard other operations.

[0154] Pairing reset refers to returning to the initialization procedure (starting from S320), where reader device 304 and thin client device 302 share their verification public key via NFC using a applet. In the event of a secure channel communication error between thin client device 302 and reader device 304 that cannot be resolved by a power reset, such as failure to verify a signature, KC_MAC_TAG, or Session_MAC_Tag, thin client device 302 and reader device 304 can request a pairing reset by sending a PAIRING RESET command. After the pairing reset, thin client device 302 and reader device 304 return to the initialization procedure (starting from S320), where they exchange the verification public key and other parameters via NFC using a applet.

[0155] The PAIRING RESET command can be formatted as follows (for reader device 304 to thin client device 302): such as using ECDSA and SS R_Auth The signed KiC_Reader_ID||PRNGRST, and (for thin client device 302 to reader device 304): using ECDSA and SS TC_Auth The signature is TC_Reader_Init_ID||PRNGRST. In some implementations, if the signature is verified, the thin client device 302 and the reader device 304 securely erase all (or some) of the previously stored security assets.

[0156] In summary, the table below illustrates some of the data generated, stored, and exchanged between the thin client device 302 and the reader device 304 during the initialization process.

[0157]

[0158] In some implementations, multiple reader devices are connected to a single thin client device using a unique BLE name (e.g., BLE_Name_Reader corresponding to each reader device) and a unique reader ID (e.g., KiC_Reader_ID corresponding to each reader device). A unique key pair (SS) associated with BLE_Name_Reader and KiC_Reader_ID is generated for each initialized reader device. TC_Auth SP TC_Auth (A session key negotiation can be independently established for each reader device via BLE using BLE_Name_Reader and unique parameters and authentication keys, as per protocol 400. The following section combines...) Figure 4The following description is provided. Prior to session key negotiation, the thin client device and reader device pair to communicate via BLE. For successful BLE pairing, the reader device can describe its BLE name (BLE_Name_reader) sent to the thin client device during the initialization procedure described above. The thin client device can search for readers initialized using BLE_Name_Reader. The thin client device can refuse connections to readers that have not been successfully initialized and can cause BLE connection failure using appropriate error messages, such as: "No initialized reader found." In some implementations, if the thin client device detects more than one initialized reader, it prompts the user (e.g., via an interface provided by the thin client device) to select a reader (e.g., based on BLE_Name_Reader).

[0159] In some implementations, the remote server computer may maintain the initialization key without transmitting it to the thin client device 302. In some implementations, instead of the thin client device 302 performing message encryption as described above, the thin client device 302 may instead provide any suitable information that allows the remote server computer 306 to generate and encrypt a message to provide the thin client device 302 with an encrypted message that can be sent to the reader device 302. Therefore, in some implementations, the remote server computer 306 may perform any suitable encryption and / or decryption and / or verification operations discussed above on behalf of the thin client device 302.

[0160] Figure 4 A method for use in thin client device 402 is shown. Figure 1 Example of protocol management computer 112) and reader device 404 Figure 1 A block diagram of protocol 400 for establishing a secure connection between a thin client device 402 and a reader device 404 (example of reader device 110). In some embodiments, the secure connection may utilize one or more session keys generated during session key negotiation. Session key negotiation may conform to a specific standard (e.g., SP800-56Ar3). For example, thin client device 402 and reader device 404 may use, for example, two static (for authentication) and two temporary key pairs to generate a shared key Z (e.g., a session key). As a non-limiting example, thin client device 402 and reader device 404 may perform protocol 400 as outlined below. It should be understood that the protocol for establishing a secure connection may include more or fewer steps than those outlined below, and the steps may be performed in any suitable order.

[0161] Protocol 400 can begin with S406, in which the thin client device 402, based on section 5.6.1.2 of SP800-56Ar3, uses an elliptic curve cryptography (ECC) algorithm (e.g., ECC P-256) and field parameters (q,FR,a,b{,SEED},G,n,h) to generate a temporary key pair (ES). TC_Agr ,EP TC_Agr ), where q is the field size (e.g., where q is an odd prime or for some prime number m equals 2). m FR is a field representation parameter used to provide additional information about the method used to represent the elements of the finite field GF(q). FR is set to null if q equals an odd prime number p. Elements of a finite field can be represented by integers from 0 to p–1. When q = 2... m When, GF(2 m The elements of GF(2) can be represented by a bit string of length m, where each bit indicates the GF(2) that is considered as a vector space on GF(2). m The coefficients (0 or 1) of a specific element of a specific basis. If q = 2 m And the representation of the field element corresponds to GF(2). m If q = 2, then FR can be empty. m And since the representation of the field elements corresponds to a polynomial basis, FR can specify the reduced polynomial—a trinomial or a quinomial. Parameters a and b can be elements of GF(q) that define the equation of the elliptic curve. G = (x G ,y G ) can be an affine point on an elliptic curve determined by a and b, used to generate a cyclic subgroup of prime order n. The parameter h can be a cofactor of the cyclic subgroup generated by G. The bit string SEED can be an optional parameter used in the approval process for generating and verifying a, b, and possibly G (depending on the generation method).

[0162] At S408, the thin client device 402 will use the Elliptic Curve Digital Signature Algorithm (ECDSA) with SS. TC_Auth Signed TC_Session and EP TC_Agr Cascading (e.g., TC_Session||EP) TC_Agr The data is transmitted to the reader device 404. TC_Session can be a 16-byte random number generated / initialized by the thin client device 402 and refreshed for each key protocol, based on section 5.2 of SP800-56Ar3.

[0163] At S410, upon receiving the aforementioned message, the reader device 404 uses the thin client device's public key (e.g., SP). TC_Auth Use this to verify the message signature.

[0164] At S412, if the signature verification is successful, then as described above, reader device 404 generates an ECC P-256 temporary key pair (ESP) from the field parameters (q,FR,a,b{,SEED},G,n,h) based on section 5.6.1.2 of SP800-56Ar3. R_Agr ,EP R_Agr ).

[0165] At S414, reader device 404 generates a shared key Z. In some implementations, Z = ECC CDH(ES R_Agr ,EP TC_Agr The reader device 404 can derive the shared session key based on Section 5.2 of SP800-56Ar3. ECC CDH primitives can be defined in Section 5.7.1.2 of SP800-56Ar3. In some implementations, the reader device 404 can generate a key generation acknowledgment tag: KC_MAC_Tag, based on Section 5.3 of SP800-56Ar3.

[0166] At S416, reader device 404 transmits data to thin client device 402 using ECDSA and SS. R_Auth Cascaded values ​​of the signature (e.g., EP) R_Agr ||TC_Session||KC_MAC_Tag).

[0167] At S418, the thin client device 402 uses the public key (SP) of the reader device 404. R_Auth Verify the signature of the received message.

[0168] At S420, after verifying the signature, the thin client device 402 generates a shared key Z = ECC CDH(ES). TC_Agr ,EP R_Agr The ECC CDH primitive is defined in section 5.7.1.2 of SP800-56Ar3. Similar to reader device 404 and following the procedure specified in section 5.2 of SP800-56Ar3, thin client device 402 can derive a shared session key, generate a KC_MAC_Tag, and verify it with the session key received from reader device 404 to ensure that the same session key was derived by reader device 404.

[0169] At S422, to complete the negotiation, the thin client device 402 sends Session_Expiration||Session_MAC_TAG to the reader device. Session_Expiration can be defined as dd.mm.yy-hh:mm, but other suitable formats can be used. Session_MAC_TAG can be generated based on Section 5.3 of SP800-56Ar3. After receiving and confirming the Session_MAC_TAG, the reader device 404 is configured to communicate with the thin client device 402 to conduct payment transactions until the session expires.

[0170] In some implementations (e.g., during Protocol 400, also known as the key negotiation scheme), communication can be aborted if invalid data is detected, signature verification fails, or a period of time has elapsed since the last time the message was exchanged between the two devices.

[0171] In one implementation, three session keys are derived from the shared key Z. In some implementations, these session keys are derived according to a specific standard (e.g., ConcatKDF[SP-800-56Ar2]). The following table provides several parameters for the key derivation method.

[0172]

[0173] In some implementations, a DerivedKeyMaterial of length L = 768 is generated using the method described in Section 4.1 of SP800-56C. Four shared session keys, K_enc, K_mac, K-sec, and K_seed, can be generated. Each key can be 128 bits, 256 bits, 128 bits, and 256 bits respectively derived from the leftmost bits of the DerivedKeyMaterial. In some implementations, the shared session keys can be concatenated to represent the DerivedKeyMaterial. This can be represented using the following notation:

[0174] (K_enc||K_mac||K_sec||K_seed)=DerivedKeyMaterial

[0175] In some implementations, the K_seed key is used to update TC_Seed and TC_Session for the next session key generation. The thin client device 402 and the reader device 404 can update Seed_TC and TC_Session using the following procedure:

[0176] New_Session_Seed=HMAC(SHA-256,K_seed,Seed_TC||TC_Session)

[0177] If the new seed_Seed_TC includes the leftmost 16 bytes of the aforementioned New_Session_Seed, then refresh Seed_TC and TC_Session. TC_Session can include the rightmost 16 bytes of New_Session_Seed.

[0178] To ensure that the thin client device 402 and the reader device 404 obtain the same session key, a KC_MAC_Tag is generated and sent to the reader device 404. The KC_MAC_Tag can be a concatenation of multiple data fields. For example, the KC_MAC_Tag can be expressed as HMAC(SHA-256, K_mac, EP). TC_Agr ||EP R_Agr ||KiC_Reader_ID||TC_Reader_Init_ID||TC_Session).

[0179] If the thin client device 402 generates the same KC_MAC_Tag again, the secure channel establishment can be considered complete. Otherwise, the thin client device 402 sends an associated error message to abandon session key negotiation. In some implementations, to complete key negotiation, the thin client device 402 generates a Session_MAC_TAG (e.g., Session_MAC_TAG = HMAC(SHA-256, k_mac, Seed_TC||TC_Session)).

[0180] Some exemplary applications of session keys are as follows:

[0181]

[0182]

[0183] Figure 5 A block diagram illustrating a scheme for secure messaging according to some implementations is shown. AES-GCM can be used for payload encryption (e.g., to generate an encrypted payload 510 including payload 504 and encrypted sensitive data 502). In some implementations, K_sec (in combination with...) can be used first. Figure 4 The generated K_sec) is used as part of payload 504 to encrypt sensitive data, and then K_enc 506 (e.g., combined with) can be used. Figure 4The generated K_enc is further encrypted to generate the encrypted payload 510. In some implementations, the initialization vector 508 is initialized to TC_Seed (e.g., combined with...). Figure 2 and Figure 3 The leftmost 12 bytes of the TC_Seed (discussed). The initialization vector 508 can be encrypted and refreshed for each payload.

[0184] According to FIPS-198, an 8-byte MAC_Tag 514 is generated from the encrypted payload 510 using HMAC, where SHA-256 is used to determine the MAC_Tag 514 based on GP-SCP03 and K_mac 516 (e.g., combined with...). Figure 4 Integrity protection for the generated K_mac. In some implementations, a MAC_Tag 514 is generated from the encrypted payload, and a Chain_Tag 518 (e.g., a 16-byte value) can be initialized to zero. The leftmost 8 bytes of the 32-byte HMAC output 513 are used as MAC_Tag 514 and sent along with the encrypted payload. Bytes 9 through 24 of the HMAC output can be used as a new Chain_Tag (e.g., Chain_Tag 518) for the next MAC_Tag generation. In some cases, bytes 21 through 32 of the HMAC output are used as a new IV (e.g., initialization vector 520) to generate the next encrypted payload.

[0185] Perform the following steps to generate an encrypted payload 522 with MAC_Tag 524:

[0186] 1) Initialization Vector 508 = the leftmost 12 bytes of Seed_TC

[0187] 2) Chain-Tag 512 = 0

[0188] 3) Encrypted_Payload 510 = AES-GCM(K_enc, payload 504). Use the initialization vector 508 from step 1.

[0189] 4)MAC_Tag 514||Chain_Tag 518||Initialization Vector 520=HMAC-SHA256(K_mac,Chain_Tag 512||Encrypted_Payload 510)

[0190] 5) Output: (Encrypted_Payload 522, MAC_Tag 524)

[0191] 6)Initialization vector 508=Initialization vector 520

[0192] 7)Chain_Tag 512=Chain_Tag 518

[0193] 8) Repeat steps 3 through 7 (e.g., until the session ends).

[0194] On the receiver side, similar steps are followed to verify MAC_Tag 524 and decrypt the encrypted payload 522.

[0195] 1) IV = the leftmost 12 bytes of TC_Seed

[0196] 2) Chain-Tag = 0

[0197] 9) Input: (Encrypted_Payload 522, MAC_Tag 524)

[0198] 3) Payload = AES-GCM(K-enc, Encrypted_Payload 522); also verify the integrity of the payload.

[0199] 4)Gen_MAC_Tag||New_Chain_Tag||New_IV=HMAC-SHA256(K_mac,Chain_Tag||Encrypted_Payload 522)

[0200] 5) If (Gen_MAC_Tag = MAC_Tag 524) and the payload integrity was verified in step 3.

[0201] a.IV = New_IV

[0202] b.Chain_Tag = New_Chain_Tag

[0203] 6) Else

[0204] a. Send the relevant error message and discard the received message.

[0205] In some implementations, the same initialization vector can be used to encrypt and decrypt sensitive data using K_sec.

[0206] In some implementations, the session key can be renegotiated (e.g., within 24 hours, for every 100 transactions, first-come-first-served, etc.). In some implementations, the previous session key can be securely deleted from the reader device (e.g., when the session expires). Any suitable intermediate data (including Z, the thin client device's temporary public key and private key (ES)) TC_Agr ,EP TC_Agr ) and / or the temporary public and private keys (ES) of the reader device R_Agr ,EP R_Agr (e.g., random numbers, etc.) can be used by thin client devices (e.g., Figure 4 The thin client device 402) and the reader (e.g., Figure 4 The reader device 404) is discarded at any appropriate time (e.g., after the session key is exported and the random value is refreshed).

[0207] Figure 6 A flowchart illustrating an exemplary method 600 for securely exchanging a public key between two devices according to some implementations is shown. Method 600 can be... Figure 1 Protocol Management Computer 112 ( Figures 2 to 4 (Examples of thin client devices 202-402) are executed. Method 600 may include more or fewer steps and may be executed in any suitable order.

[0208] Method 600 may begin with S602, wherein the protocol management computer identifies the presence of the reader device. For example, the protocol management computer may be used as a contactless portable device. When the protocol management computer and the reader device are within a threshold distance of each other, data can be transferred between the devices (e.g., from the reader device to the protocol management computer, and vice versa). Through this communication, the protocol management computer identifies the presence of the reader device.

[0209] At S604, the protocol management computer obtains the first initialization key associated with the reader device from the remote server computer (e.g., as shown in the image). Figure 2 K_init as described in, or as Figure 3 SP as described in R_Init In some implementations, a second initialization key (e.g., as shown in the first initialization key) corresponds to the first initialization key. Figure 2 K_init as described in, or as Figure 3 SS as described in R_Init Previously (e.g., during the manufacturing process of the reader device) stored at the reader device. In some embodiments, with Figure 2As described herein, the first initialization key and the second initialization key are the same symmetric key (e.g., a shared key). In other embodiments, in conjunction with... Figure 3 As described, the first initialization key includes at least one of the asymmetric key pairs (e.g., such as...). Figure 3 SP as described in R_Init ).

[0210] At S606, the protocol management computer receives first encrypted data via a near-field communication channel, the first encrypted data including, as combined with Figure 2 and Figure 3 The first public key associated with the reader device is described. In some embodiments, the first encrypted data is received via a SET DATA message as described above.

[0211] At S608, the protocol management computer transmits second encrypted data via a near-field communication channel. This second encrypted data includes a second public key associated with the protocol management computer. In some embodiments, at least one of the first or second encrypted data is encrypted based at least in part on at least one of a first or second initialization key (e.g., as shown in the image). Figure 2 and Figure 3 (As described in the text).

[0212] Figure 7 A thin client device 702 according to some implementation schemes is described. Figure 1 Example of protocol management computer 112, Figures 2 to 4 Block diagrams of thin client devices 202, 302, and / or 402, etc. are provided. Thin client device 702 is illustrated as including multiple hardware and software modules (704-714). However, it should be understood that this is provided for illustrative purposes only, and each module and associated functionality may be provided and / or performed by the same or different components. That is, thin client device 702 can be described, for example, by using any suitable combination of software instructions and / or hardware configurations, respectively, with reference to... Figure 1 Protocol Management Computer 112 Figures 2 to 4 The thin client device 202-404 performs some of the related functions and steps described herein.

[0213] Thin client device 702 is shown as including processor 704, system memory 706, and external communication interface 708. Furthermore, one or more modules of 710-716 may be located within one or more components of system memory 706, or may be located externally. Processor 704, system memory 706, and / or external communication interface 708 can be used in conjunction with any of the modules described below to provide desired functionality. Some exemplary modules and associated functionality may be as follows.

[0214] Communication module 710 can be configured or programmed to perform the functions of receiving, sending, and generating electronic messages for transmission at thin client device 702 to reader device (e.g., Figure 1 Some or all of the functionalities associated with the reader device 110. For example, the communication module 710 can be configured to perform combined Figure 2 The thin client device 202 is part of and / or combined with protocol 200. Figure 3 The thin client device 302 is described as part of protocol 300. The communication module 710 can be configured to cause the processor 704 to perform any suitable functionality performed by the thin client device 402, such as in conjunction with... Figure 4 As described. When the thin client device 702 receives an electronic message via the external communication interface 708, it can transmit the electronic message to the communication module 710. The communication module 710 can identify and parse the relevant data based on the specific messaging protocol used by the thin client device 702. The communication module 710 can then (e.g., via the data bus 728) transmit any received information to the appropriate module within the thin client device 702. The communication module 710 can also receive information from one or more modules in the thin client device 702 and generate an electronic message in an appropriate data format conforming to the transmission protocol used in the thin client device 702, such that the electronic message can be sent to one or more entities (e.g., sent to...). Figure 1 (Remote server computer 114). Electronic messages can then be transmitted to external communication interface 708 for transmission.

[0215] The communication module 710 can be configured to cause the processor 704 to perform operations with a reader device, a portable device (e.g., Figure 1 Portable device 106) and / or remote server computer (e.g., Figure 1 The communication module 710 may be responsible for: (1) establishing, maintaining and terminating sessions with one or more reader devices, portable devices and / or remote server computers; (2) allowing the exchange of messages within a given session; and (3) allowing multiple sessions to coexist.

[0216] Protocol conversion module 712 can be configured or programmed to cause processor 704 to perform operations on portable devices (via...) Figure 1 The communication sent between the reader device 110 and the remote server computer (e.g., remote server computer 114) is converted from one communication protocol to another, which is associated with some or all of the functionality. The protocol conversion module 712 may be responsible for determining which communication protocol a particular device is configured to use (e.g., EMV 1.0 or EMV 2.0). Based on this determination, the protocol conversion module 712 may, upon request, handle the conversion of communication for transaction exchange. For example, originating from... Figure 1 The communication of the portable device 108 can be received by the communication module 710 (e.g., from...). Figure 1 (Received by reader device 110). Based on the determination that portable device 108 uses a second communication protocol while remote computer 114 uses a first communication protocol, protocol conversion module 712 can convert communication from the second communication protocol to the first communication protocol before forwarding the converted communication to remote computer 114.

[0217] Specifically, the protocol conversion module 712 can be responsible for: (1) requesting the communication module 710 to establish, maintain and terminate sessions with the portable device and the remote server, and (2) synchronizing message exchanges between the portable device and the remote server computer 114 in order to optimize performance and minimize the amount of communication exchanged with the remote computer.

[0218] For this purpose, the protocol conversion module 712 can be configured or programmed to: (1) create, format, and exchange as many messages as possible necessary within a given session to perform as many data requests as possible from a remote computer, and (2) create, format, and exchange as many messages as possible necessary within a given session to perform as many data requests as possible from a portable device.

[0219] The data conversion module 714 can be configured or programmed to cause the processor 704 to perform some or all of the functionalities associated with converting data to be transmitted between portable devices 106-108 and remote server computer 114 from one data format (e.g., associated with a first communication protocol) to another data format (e.g., associated with a second communication protocol) (and vice versa). The data conversion module 714 may be responsible for determining which communication protocol a particular portable device is configured to use (e.g., EMV 1.0 or EMV 2.0). Based on this determination, the data conversion module 714 may, upon request, handle the conversion of data for transactional exchange. For example, communication originating from portable device 108 may be received by communication module 710 (e.g., via reader device 110). Based on the determination that portable device 108 uses the second communication protocol and remote server computer 114 uses the first communication protocol, the data conversion module may convert the data format associated with the second communication protocol to a format suitable for the first communication protocol, and then forward the converted data to remote server computer 114.

[0220] In some implementations, the thin client device 702 may include a data storage 716. The data storage 716 may be configured for storage-coupled operation. Figures 2 to 4 Any suitable data discussed (e.g., data described as stored at thin client devices 202, 302, 402, etc.).

[0221] Figure 8 A block diagram of a reader device 802 according to some embodiments is depicted (respectively...). Figures 1 to 4 Examples of reader devices 110, 204, 304, and / or 404 are provided. Reader device 802 is illustrated to include a communication module 810. However, it should be understood that this is provided for illustrative purposes only, and the associated functionality of the communication module 810 may be provided and / or performed by the same or different components. That is, reader device 802 may perform some of the related functions and steps described herein with reference to reader devices 110, 204, 304, and / or 404, for example, by using any suitable combination of software instructions and / or hardware configuration.

[0222] The reader 802 is shown as including a processor 804, a system memory 806, and an external communication interface 808. Furthermore, the communication module 810 may be located within one or more components of the system memory 806, or it may be located externally. The processor 804, system memory 806, and / or external communication interface 808 may be used in conjunction with the communication module 810 to provide desired functionality. Some exemplary functionalities are described below.

[0223] Communication module 810 can be configured or programmed to perform the functions of receiving, sending, and generating electronic messages for transmission at reader device 802 to thin client devices (e.g., respectively). Figure 1 Protocol management computer 112, Figures 2 to 4 Examples of thin client devices 202, 302, and / or 402) are associated with some or all of their functionality. For example, communication module 810 can be configured to perform combined... Figure 2 The reader device 204 is part of and / or combined with protocol 200. Figure 3 The functionality of reader device 304 as described as part of protocol 300. Communication module 810 can be configured to cause processor 604 to perform any suitable functionality performed by reader devices 304 and 404, respectively, as in combination. Figure 3 and Figure 4 When the reader device 802 receives an electronic message via the external communication interface 808, it can transmit the electronic message to the communication module 810. The communication module 810 can identify and parse the relevant data based on the specific messaging protocol used by the reader device 802.

[0224] The communication module 810 can be configured to cause the processor 804 to perform communication with a portable device (e.g., Figure 1 Portable devices 106 and / or portable devices 108) and / or thin client devices (e.g., Figure 1 The communication module 810 is associated with some or all of the functionalities of communication with the protocol management computer 112, thin client devices 202, 302, 402, etc. In particular, the communication module 810 may be responsible for: (1) establishing, maintaining and terminating sessions with one or more portable devices and / or thin client devices, (2) allowing the exchange of messages within a given session, and (3) allowing multiple sessions to coexist.

[0225] In some embodiments, the reader device 802 may include a data memory 812. The data memory 812 may be configured to store combined... Figures 2 to 4 Any suitable data discussed (e.g., data described as stored at reader devices 204, 304 and / or 404).

[0226] Technological advantages

[0227] Using the techniques disclosed herein, one or more initialization keys (e.g., such as...) can be initialized before a transaction. Figure 2 The symmetric key described in, or as Figure 3At least one of the asymmetric key pairs described herein is provided to a thin client device (referred to as "TC") and a reader device (referred to as "Reader"). In some embodiments, the one or more initialization keys are stored at the reader device during the reader's manufacturing (or initialization) process, and then the reader is obtained by the end user (e.g., a merchant). The same initialization key is provided to the TC (e.g., from a receiving cloud where a remote server computer 114 is part). The TC and the reader device can use the initialization key to securely exchange a unique public key (e.g., via a near-field communication channel when the TC is used as a contactless portable device), making it impossible for unauthorized parties to intercept and / or obtain the public key. The protocols defined above enable the TC and the reader device to encrypt these public keys and verify the authenticity and validity of the messages they exchange. These techniques offer advantages over conventional systems that utilize certificates provided by certification authorities that include public keys of other devices. The TC and reader device in the provided examples do not need to store certification authority certificates or public keys. Therefore, the techniques provided herein reduce the amount of data stored. Furthermore, by utilizing protocols and initialization keys as discussed in this paper, the burden of obtaining certificates from certification authorities can be released first.

[0228] It should be understood that any embodiment of this disclosure can be implemented using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic, wherein the general-purpose programmable processor is in a modular or integrated form. As used herein, the processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked together. Based on the disclosure and teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing embodiments of this disclosure using hardware and combinations of hardware and software.

[0229] Any software component or function described in this application may be implemented as processor-executable software code using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0230] Such programs can also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of this disclosure can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0231] The foregoing description is illustrative and not restrictive. Many variations of this disclosure will become apparent to those skilled in the art upon reading it. Therefore, the scope of this disclosure should not be determined by reference to the foregoing description, but rather by reference to the pending claims and their full scope or equivalents.

[0232] Without departing from the scope of this disclosure, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0233] Unless explicitly indicated otherwise, the use of “a” or “the” is intended to mean “one or more”.

[0234] Note that, as used herein, the terms “first,” “second,” etc., are not restrictive but can be used as labels to refer to different devices or objects.

[0235] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method for performing encryption, the method comprising: The protocol management computer uses the near-field communication channel to identify the presence of the reader device; The protocol management computer obtains a first initialization key associated with the reader device from a remote server computer, wherein a second initialization key corresponding to the first initialization key was previously stored at the reader device during the manufacturing process of the reader device, wherein the first initialization key and the second initialization key are static keys; The first initialization key is stored at the protocol management computer; The protocol management computer receives, via the near-field communication channel, first encrypted data including a first public key associated with the reader device, the first encrypted data having been encrypted by the reader device at least in part based on a second initialization key stored at the reader device; The protocol management computer decrypts the first encrypted data, at least in part, based on the first initialization key stored on the protocol management computer, to obtain the first public key associated with the reader device; The protocol management computer encrypts data containing a second public key associated with the protocol management computer, based at least in part on the first initialization key stored on the protocol management computer, to generate second encrypted data; as well as The protocol management computer transmits the second encrypted data via the near-field communication channel for the reader device to decrypt, the decryption being based at least in part on the second initialization key stored on the reader device.

2. The method of claim 1, wherein the first initialization key comprises an asymmetric key of an asymmetric key pair.

3. The method of claim 1, further comprising: The protocol management computer obtains an identifier associated with the reader device, wherein obtaining the first initialization key includes sending a request for the first initialization key, wherein the request for the first initialization key includes the identifier, and wherein the identifier is used to retrieve the first initialization key.

4. The method of claim 1, wherein the remote server computer is configured to perform terminal processing operations.

5. The method of claim 1, wherein the first initialization key and the second initialization key are symmetric keys, and wherein the method further comprises: The protocol management computer transmits a first encrypted message and a first initialization vector, wherein the first encrypted message is encrypted using the symmetric key; The protocol management computer receives a second encrypted message, the second encrypted message including second encrypted data, the second encrypted data including the first public key associated with the reader device, and the second encrypted message being encrypted using a second initialization vector generated from the first initialization vector; The protocol management computer decrypts the second encrypted message using the second initialization vector; The protocol management computer verifies that the second encrypted message has been decrypted; as well as The protocol management computer transmits a third encrypted message, including the second public key associated with the protocol management computer, to the reader device. The third encrypted message is encrypted using a third initialization vector generated from the second initialization vector.

6. The method of claim 5, further comprising: Generate a unique identifier and a random number for the reader device, wherein the first initialization key, the unique identifier, and the random number are included in the first encrypted message.

7. The method of claim 6, wherein the second encrypted message, when decrypted, further includes the symmetric key, one or more unique identifiers for the reader device, and the random number.

8. The method of claim 7, wherein verifying the second encrypted message as decrypted includes: The random number received in the second encrypted message is compared with the random number transmitted in the first encrypted message.

9. The method of claim 5, further comprising: In response to verifying the second encrypted message, a second public key and a second private key associated with the protocol management computer are generated.

10. A protocol-managed computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code that, when executed by the processor, causes the protocol-managing computer to perform operations including: The presence of a reader device is identified by using a near-field communication channel; A first initialization key associated with the reader device is obtained from a remote server computer, wherein a second initialization key corresponding to the first initialization key was previously stored at the reader device during the manufacturing process of the reader device, wherein the first initialization key and the second initialization key are static keys; Store the first initialization key; Receive, via the near-field communication channel, first encrypted data including a first public key associated with the reader device, the first encrypted data having been encrypted by the reader device at least in part based on a second initialization key stored on the reader device; The first encrypted data is decrypted, at least in part, based on the first initialization key stored on the protocol management computer, to obtain the first public key associated with the reader device; Data containing a second public key associated with the protocol management computer is encrypted, at least in part, based on the first initialization key stored on the protocol management computer, to generate second encrypted data; and The second encrypted data is transmitted via the near-field communication channel for decryption by the reader device, the decryption being based at least in part on the second initialization key stored on the reader device.

11. The protocol management computer of claim 10, wherein the operation further includes: The first public key and the second public key are used to negotiate one or more session keys with the reader device.

12. The protocol management computer of claim 11, wherein the one or more session keys are used to establish a secure connection between the protocol management computer and the reader device.

13. The protocol management computer of claim 12, wherein the secure connection conforms to the Bluetooth communication protocol.

14. The protocol management computer of claim 10, wherein the protocol management computer is configured to operate as a contactless card.

15. A reader device, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code that, when executable by the processor, causes the reader device to perform operations including: During the manufacturing process of the reader device, a second initialization key is stored at the reader device, the second initialization key corresponding to a first initialization key stored at the protocol management computer, wherein the first initialization key and the second initialization key are static keys; Receive communication from the protocol management computer via a near-field communication channel; In response to receiving the communication, first encrypted data including a first public key associated with the reader device is transmitted via the near-field communication channel, the first encrypted data having been encrypted by the reader device at least in part based on a second initialization key stored at the reader device; Receive, via the near-field communication channel, second encrypted data including a second public key associated with the protocol management computer from the protocol management computer; and The second encrypted data is decrypted at least in part based on the second initialization key stored at the reader device.

16. The reader device of claim 15, wherein the first initialization key and the second initialization key are symmetric keys, and wherein the operation further comprises: The protocol management computer receives a first encrypted message including a first initialization vector, the first encrypted message being encrypted using the symmetric key; Decrypt the first encrypted message using the first initialization vector; The transmission includes a second encrypted message comprising the first public key associated with the reader device, the second encrypted message being encrypted using a second initialization vector generated from the first initialization vector; as well as Receive a third encrypted message including the second public key associated with the protocol management computer, the third encrypted message being encrypted using a third initialization vector generated by the protocol management computer from the second initialization vector.

17. The reader apparatus of claim 16, wherein the operation further comprises generating a second initialization vector from the first initialization vector, wherein the second initialization vector comprises the twelve leftmost bytes of the first initialization vector.

18. The reader device of claim 16, wherein the first encrypted message, the second encrypted message and the third encrypted message are application protocol data unit messages defined by the ISO / IEC 7816-4 communication standard.

19. The reader device of claim 15, wherein the operation further comprises: Generate the first public key as part of a public-private key pair.

20. The reader device of claim 16, wherein the operation further comprises: The reader device transmits a fourth message to the protocol management computer, the fourth message indicating that the third encrypted message has been successfully received.

Images