Efficient method for authenticated communication

Abstract

Embodiments of the present invention relate to an efficient method for authenticated communication. In one embodiment, a first computing device is capable of generating a temporary key pair including a temporary public key and a temporary private key. The first computing device is capable of generating a first shared secret using the temporary private key and a static second device public key. The first computing device is capable of encrypting request data using the first shared secret to obtain encrypted request data. The first computing device is capable of sending a request message including the encrypted request data and the temporary public key to a server computer. Upon receiving a response message from the server computer, the first computing device is capable of determining a second shared secret using the temporary private key and a blinded static second device public key. The first computing device is then capable of decrypting encrypted response data from the response message to obtain response data.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2015 / 036524, international application date June 18, 2015, application number 201580032715.8 entering the Chinese national phase, and name “Efficient Method for Authenticated Communications”.

[0002] Cross-reference to related applications

[0003] This application is a formal case of U.S. Provisional Application No. 62 / 014,102 filed on June 18, 2014 (Attorney Docket No.: 79900-911064-1012US01) and U.S. Provisional Application No. 62 / 016,048 filed on June 23, 2014 (Attorney Docket No.: 79900-912144-1012US02), and claims priority to them, the entire contents of which are incorporated herein by reference for all purposes. Background Art

[0004] As the number of user devices such as NFC-enabled mobile phones and contactless cards continues to increase, maintaining the security of payment transactions remains a concern. For example, in order to conduct a payment transaction, it is often necessary to authenticate the user and send information to a server. However, an attacker may attempt to eavesdrop on the transaction (e.g., by performing a man-in-the-middle attack). Therefore, an attacker may attempt to intercept identification data such as a user device identifier or authentication data such as a password sent by the user. If determined, this data may be used for illegal purposes.

[0005] Further complicating the issue is the security of the user device itself. In some cases, the user device may be compromised or otherwise untrustworthy, so storing persistent or static security credentials such as the user's private key on the device is undesirable. Conducting secure authenticated communications in these situations can be challenging.

[0006] Further complicating the problem is the unlikely event that a private key, such as a private key stored on a user device or a private key stored on a server computer, is compromised. In these situations, it is desirable for the security system to exhibit forward secrecy: compromise of a private key should not result in compromise of past secure communications between entities.

[0007] Embodiments of the present invention address these and other problems individually and collectively. Summary of the invention

[0008] Embodiments of the present invention are directed to efficient methods for authenticated communications.

[0009] In one embodiment, the first computing device can generate a temporary key pair including a temporary public key and a temporary private key. The first computing device can generate a first shared secret using the temporary private key and the static second device public key. The first computing device can encrypt the request data using the first shared secret to obtain encrypted request data. The first computing device can send a request message including the encrypted request data and the temporary public key to the second computing device.

[0010] Upon receiving the request message, the second computing device can generate a first shared secret using the temporary public key and the static second device private key. The second computing device can decrypt the encrypted request data using the first shared secret to obtain the request data. The second computing device can then generate a second shared secret using the blinded static second device private key and the temporary public key. The second computing device can encrypt the response data using the second shared secret to determine the encrypted response data. The second computing device can then send a response message including the encrypted response data and the blinded static second device public key to the first computing device.

[0011] Upon receiving the response message, the first computing device can determine the second shared secret using the temporary private key and the blinded static second device public key.The first computing device can then decrypt the encrypted response data from the response message to obtain the response data.

[0012] Other embodiments relate to systems, portable consumer devices, and computer-readable media associated with the methods described herein.

[0013] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A diagram showing an exemplary system that may be used with embodiments of the present invention.

[0015] Figure 2 An example of a computing device in accordance with some embodiments is shown.

[0016] Figure 3 Shown is a flow diagram illustrating communications between a first computing device and a second computing device in accordance with some embodiments.

[0017] Figure 4-5 Methods of securely authenticating a second computing device and obtaining response data from the second computing device are shown in accordance with some embodiments.

[0018] Figure 6-7 A method of securely processing an authentication request message from a first computing device and providing an authentication response message to the first computing device is shown in accordance with some embodiments.

[0019] Figure 8A data flow diagram illustrating operations performed in generating, transmitting, and processing an authentication request message in accordance with some embodiments is shown.

[0020] Fig. 9 A data flow diagram illustrating operations performed in generating, transmitting, and processing an authentication response message in accordance with some embodiments is shown.

[0021] Figure 10-11 A second method of securely authenticating a second computing device and obtaining response data from the second computing device in accordance with some embodiments is shown.

[0022] Figure 12-13 A second method of securely processing an authentication request message from a first computing device and providing an authentication response message to the first computing device is shown in accordance with some embodiments.

[0023] Fig.14 Shown is a data flow diagram illustrating operations performed in a second method of generating, transmitting, and processing an authentication request message in accordance with some embodiments.

[0024] Fig.15 A data flow diagram illustrating operations performed in a second method of generating, transmitting, and processing an authentication response message in accordance with some embodiments is shown.

[0025] Fig.16 An optimized method of securely authenticating a second computing device and obtaining response data from the second computing device in accordance with some embodiments is shown.

[0026] Fig.17 An optimized method for securely processing an authentication request message from a first computing device and providing an authentication response message to the first computing device is shown in accordance with some embodiments.

[0027] Fig.18 A block diagram of an exemplary computer device is shown.

[0028] the term

[0029] Before discussing some embodiments of the present invention, a description of some terms may be helpful for understanding the embodiments.

[0030] The term "server computer" may include a cluster of computers or computing devices. For example, a server computer may be a large mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing for servicing requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0031] The term "public / private key pair" can include a pair of associated encryption keys generated by an entity. The public key can be used for public functions, such as encrypting a message to be sent to an entity, or for verifying a digital signature that should be made by an entity. On the other hand, the private key can be used for private functions, such as decrypting a received message or applying a digital signature. The public key will usually be authorized by a subject known as a certification authority (CA), which stores the public key in a database and distributes it to any other entity requesting it. The private key is generally kept in a secure storage medium and is usually only known to the entity. However, the cryptographic system described herein can be characterized by a key recovery mechanism for recovering lost keys and avoiding data loss. The public key and the private key can be in any suitable format, including a format based on RSA or elliptic curve cryptography (ECC).

[0032] A "digital signature" may refer to the result of applying an algorithm based on a public / private key pair that allows the signing party to display and the verifier to verify the authenticity and integrity of a document. The signing party works with the help of the private key and the verifier works with the help of the public key. This process proves the authenticity of the sender, the integrity of the signed document, and the so-called principle of non-repudiation, which does not allow denial of what has been signed. A certificate or other data that includes the signing party's digital signature is said to be "signed" by the signing party.

[0033] A "certificate" or "digital certificate" may include an electronic or data file that uses a digital signature to bind a public key to data associated with an identity. A certificate may include one or more data fields, such as the legal name of the identity, the serial number of the certificate, the certificate's validity start and end dates, the authorities associated with the certificate, etc. A certificate may include a "valid from" date indicating the first day the certificate is valid, and a "valid to" date indicating the last day the certificate is valid. A certificate may also include a hash of the data in the certificate that includes the data fields. Unless otherwise specified, each certificate is signed by a certificate authority.

[0034] A "certificate authority" (CA) may include one or more server computers operably coupled to issue certificates to entities. A CA may prove its identity using a CA certificate, which includes the CA's public key. A CA certificate may be signed with another CA's private key or with the same CA's private key. The latter is referred to as a self-signed certificate. A CA may maintain a database of all certificates issued by the CA, and may also maintain a list of revoked certificates.

[0035] In a typical process, a certificate authority receives an unsigned certificate from an entity whose identity is known. The unsigned certificate includes a public key, one or more data fields, and a hash of the data in the certificate. The CA signs the certificate with a private key corresponding to the public key included on the CA certificate. The CA can then store the signed certificate in a database and issue the signed certificate to the entity.

[0036] A "cryptographic random number" may include any number, string, bit sequence, or other data value intended to be used in association with a single communication session. In some cases, a cryptographic random number may be generated randomly or pseudo-randomly. Typically, a cryptographic random number has sufficient length to make it unlikely that the same random number value will be generated multiple times independently.

[0037] A "blinded key", such as a "blinded public key", may include a key whose original value has been obfuscated or otherwise modified by combining it with another data element, such as a cryptographic random number. For example, in elliptic curve cryptography, a public key may be multiplied by a random number to generate a "blinded public key". Similarly, a private key may be multiplied by a random number to generate a "blinded private key".

[0038] A "temporary key pair" may include a public key (i.e., a "temporary public key") and a private key (i.e., a "temporary private key") generated for use in a single transaction or other communication session. The temporary key pair may be in any suitable format, such as ECC or RSA. Typically, the temporary key pair may be deleted once the transaction or communication session has ended.

[0039] A "static key pair" may include a public key (i.e., a "static public key") and a private key (i.e., a "static private key") that are maintained for a period of time. Typically, but not necessarily, the static private key may be securely stored in a hardware security module (HSM) or a secure element (SE). Typically, but not necessarily, the static public key may be bound to an identity using a digital certificate. The static key pair may be in any suitable format, such as ECC or RSA.

[0040] A "shared secret" may include any data value or other information known only to an authorized party in a secure communication. A shared secret may be generated from any suitable data in any suitable manner. For example, a Diffie-Hellman-based algorithm, such as Elliptic Curve Diffie-Hellman (ECDH), may be used to generate a shared secret from a private key and a public key. In some cases, a shared secret may be used to generate a session key.

[0041] The term "identification data" may include any data or information associated with a user or a device. Examples of identification data may include the name of a user associated with a device, an organization associated with a device, payment information associated with a device such as a primary account number (PAN), an expiration date of a device, a certificate associated with a device, an IMEI or serial number of a device, and the like.

[0042] The term "authentication data" may include any data or information suitable for authenticating a user or device. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), and the like.

[0043] An "identification factor" may include any data or information determined from identification data and / or authentication data. Typically, but not necessarily, the identification factor may be generated by hashing a combination of the identification data and the authentication data.

[0044] An "encryption key" may include any data value or other information suitable for encrypting data with a cipher. A "decryption key" may include any data value or other information suitable for decrypting encrypted data. In some cases, the same key used to encrypt data may be operable to decrypt data. Such a key may be referred to as a symmetric encryption key.

[0045] The term "session key" may include any key used to encrypt or decrypt data to be securely transmitted. In some cases, a session key may be generated from a shared secret known to both the sender and the receiver. For example, a session key may be derived using a key derivation function and a shared secret. DETAILED DESCRIPTION

[0046] Embodiments of the present invention relate to efficient methods for authenticated communications. For example, a first computing device and a second computing device can mutually authenticate and exchange messages without exposing any sensitive information in plain text.

[0047] In one embodiment, the first computing device can generate a temporary key pair including a temporary public key and a temporary private key. The first computing device can generate a first shared secret using the temporary private key and a static second device public key of the second computing device. The first computing device can encrypt the request data using the first shared secret to obtain encrypted request data. The first computing device can send a request message including the encrypted request data and the temporary public key to the second computing device.

[0048] Upon receiving the request message, the second computing device can generate a first shared secret using the temporary public key and the static second device private key. The second computing device can decrypt the encrypted request data in the request message using the first shared secret to obtain the request data. The second computing device can then generate a second shared secret using the blinded static second device private key and the temporary public key. The second computing device can encrypt the response data using the second shared secret to determine the encrypted response data. The second computing device can then send a response message including the encrypted response data and the blinded static second device public key to the first computing device.

[0049] Upon receiving the response message, the first computing device can determine the second shared secret using the temporary private key and the blinded static second device public key.The first computing device can then decrypt the encrypted response data from the response message to obtain the response data.

[0050] In some embodiments, the first computing device can store a static first device private key and a static first device public key, and the temporary key pair can be a temporary first device key pair including the temporary first device public key and the temporary first device private key. In some such embodiments, the request data sent by the first device can include a first device certificate, the first device certificate includes the static first device public key, and the response message received from the second computing device can include the temporary second device public key. Accordingly, the first computing device can generate an auxiliary shared secret using the temporary second device public key and the static first device private key, and decrypt the encrypted response data using the auxiliary shared secret.

[0051] Embodiments of the present invention can protect the identities of computing devices participating in communications. For example, an attacker may attempt to eavesdrop or otherwise monitor data transmitted between a first computing device (e.g., a mobile device) and a second computing device (e.g., a server computer). Because embodiments of the present invention can avoid sending any identifiable information (such as a static first device public key or a static second device public key) in plain text, the identities of the computing devices are protected from attack by unauthorized entities.

[0052] Embodiments can also implement two-way authenticated secure communications using only a single request message and a single response message. This allows for fast authentication with reduced latency, and allows the security properties of embodiments to be integrated into other existing request / response flows without the need to send additional messages. For example, in some embodiments, the content of a request message can be appended to a request message (mutatis mutandis for the response message) that can be sent for a different purpose.

[0053] Some embodiments can also provide the property of forward secrecy: even if the static first device private key or the static second device private key is compromised, the shared secret used to encrypt the request data and the response data cannot be regenerated after the communication session ends. For example, in some embodiments, the first computing device can generate a second session key using a temporary first device private key, a blinded static second device public key, a static first device private key, and a temporary second device public key. In these embodiments, even if the blinded static second device public key and the temporary second device public key are perceived by an eavesdropper during transmission, and the static first device private key is later compromised, the second session key cannot be regenerated by an attacker because the temporary first device private key has been deleted from the first computing device. Without the second session key, data encrypted using the second session key cannot be decrypted. Therefore, these embodiments allow communications to remain secure even in the unlikely event that the first computing device is compromised later.

[0054] In another example, the second computing device can generate a second session key using the temporary first device public key, the blinded static second device private key, the static first device public key, and the temporary second device private key. In these embodiments, even if the static first device public key and the temporary first device public key are perceived by an eavesdropper in transmission, and the static second device private key is later compromised, the second session key cannot be regenerated by the attacker because the temporary second device private key has been deleted from the second computing device. Without the second session key, data encrypted using the second session key cannot be decrypted. Therefore, these embodiments allow communications to remain secure even in the unlikely event of a later compromise of the second computing device.

[0055] Thus, embodiments can allow secure communications even if any endpoint of the communications is compromised.

[0056] Moreover, embodiments can provide faster and more efficient communications in situations where computing devices have communicated before. In some embodiments, a registration at a first computing device can be used to store future shared secrets and future second device session identifiers for one or more second computing devices. A similar registration at a second computing device can be used to store future shared secrets and future blinded static second device public key values ​​for one or more first devices. Therefore, if the first device and the second device communicate multiple times, the stored data can be used. This can avoid certain operations that may be relatively time-consuming and computationally intensive, such as the Elliptic Curve Diffie-Hellman (ECDH) algorithm. This can also provide an improved experience for users of computing devices because embodiments allow for reduced processing, which can improve battery life and reduce communication time. For example, according to some embodiments, secure and private communication between two devices can be performed in less than 50 milliseconds.

[0057] Embodiments can also appear the same as systems that do not use blinding keys to an eavesdropper because an eavesdropper would not know whether a public key transmitted from a first computing device to a second computing device or from a second computing device to a first computing device is a blinded public key or an unblinded public key. Thus, embodiments can provide protection against reverse engineering of the protocol.

[0058] I. System

[0059] A. Payment System

[0060] Figure 1 A system according to an embodiment of the present invention is shown. The system includes a user (not shown), and the user can operate a user device 101. The user can use the user device 101 to communicate with the access device 102 to conduct a payment transaction. As used herein, a "user device" may include a desktop computer, a laptop computer, a mobile phone, a tablet computer, a credit card, a debit card, or any suitable computing device. As used herein, an "access device" may include any computing device suitable for communicating with a user device, such as a point of sale (POS) terminal or a network server. In some embodiments, the access device 102 can communicate directly with the user device 101. In other embodiments, the access device 102 can communicate with the user device 101 via an interface device, such as a smart watch, smart glasses, or any other suitable device. The access device 102 can be connected to a merchant computer 103, and the merchant computer 103 can be connected to an acquirer computer 104. The acquirer computer 104 can be connected to the issuer computer 106 via a payment processing network 105. Any one or all of the devices 101-106 can be implemented using one or more computing devices such as a server computer.

[0061] As used herein, an "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user's financial account and often issues or provides a user device 101 such as a credit or debit card or a mobile device to the user. A "merchant" is generally an entity that participates in a transaction and is able to sell goods or services. An "acquirer" is generally a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities are capable of performing both issuer functions and acquirer functions. Some embodiments may include such a single-entity issuer-acquirer. Each entity may include one or more computer devices (e.g., access device 102, merchant computer 103, acquirer computer 104, payment processing network 105, and issuer computer 106) to enable communication, or to perform one or more functions described herein.

[0062] Payment processing network 105 may include data processing subsystems, networks, and operations to support and deliver certificate authority services, authorization services, exception file services, transaction scoring services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM . Such as VisaNet TM Payment processing networks such as VisaNet can process credit card transactions, debit card transactions and other types of commercial transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services.

[0063] The payment processing network 105 may include one or more server computers. A server computer is typically a powerful computer or cluster of computers. For example, a server computer may be a large mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, the server computer may be a database server coupled to a network server. The payment processing network 105 may use any suitable wired or wireless network, including the Internet.

[0064] In some payment transactions, a user purchases goods or services at a merchant using a user device 101. The user device 101 can interact with an access device 102 at a merchant associated with a merchant computer 103. For example, a user may tap the user device 101 against an NFC reader in the access device 102. Alternatively, such as in an offline or e-commerce transaction, the user may indicate payment details to the merchant over a computer network.

[0065] The authorization request message for the transaction may be generated by the access device 102 or the merchant computer 103 and then forwarded to the acquirer computer 104. Upon receiving the authorization request message, the acquirer computer 104 sends the authorization request message to the payment processing network 105. The payment processing network 105 then forwards the authorization request message to a corresponding issuer computer 106 associated with the issuer with which the user or user device 101 is associated.

[0066] An "authorization request message" may be an electronic message that is sent to a transaction processing network and / or an issuer to request authorization for a transaction. The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier, which may be associated with a payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including but not limited to: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction. The authorization request message may also include other information, such as information identifying the access device that generated the authorization request message, information about the location of the access device, etc.

[0067] After the issuer computer 106 receives the authorization request message, the issuer computer 106 sends an authorization response message back to the payment processing network 105 to indicate whether the current transaction is authorized (or not authorized). The payment processing network 105 then forwards the authorization response message back to the acquirer computer 104. In some embodiments, the payment processing network 105 may deny the transaction even if the issuer computer 106 has authorized the transaction, for example, based on the value of the fraud risk score. The acquirer computer 104 then sends a response message back to the merchant computer 103.

[0068] An "authorization response message" may be an electronic message reply to an authorization request message generated by the issuer computer 106 and / or the payment processing network 105. The authorization response message may include, by way of example only, one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the issuer returns to the merchant computer 103 in response to the authorization request message in an electronic message (either directly or through the payment processing network 105) indicating that the transaction is approved. This code may be used as evidence of authorization. As noted above, in some embodiments, the payment processing network 105 may generate or forward the authorization response message to the merchant, typically through the acquirer computer 104.

[0069] After merchant computer 103 receives the authorization response message, merchant computer 103 may then provide the authorization response message to the user. The response message may be displayed by access device 102, or may be printed on a physical receipt. Alternatively, if the transaction is an online transaction, the merchant may provide a web page or other indication of the authorization response message with a virtual receipt. The receipt may include transaction data for the transaction.

[0070] At the end of the day, regular clearing and settlement processing may be performed by the payment processing network 105. Clearing processing is the process of exchanging financial details between acquirers and issuers to facilitate posting to a customer's payment account and reconciling the user's settlement position.

[0071] B. Computing Devices

[0072] Figure 2 An example of a computing device 200 according to some embodiments is shown. Examples of computing device 200 may include mobile phones, tablet computers, desktop and laptop computers, wearable devices (e.g., smart watches, fitness bands, anklets, rings, earrings, etc.), server computers, or any other computing device suitable for receiving, storing, and transmitting data. Computing device 200 may include a processor 201 communicatively coupled to a network interface 202, a memory 203, and a computer-readable medium 210.

[0073] Processor 201 may include one or more CPUs, each of which may include at least one processor core operable to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors. The CPU interacts with the memory via signals through the conduit to execute stored signal program code according to conventional data processing techniques. In some cases, processor 201 may include multiple CPUs coupled via a network, such as in a distributed or clustered computing system.

[0074] The network interface 202 can be configured to allow the computing device 200 to communicate with other entities such as devices 101-106, other computing devices, etc. using one or more communication networks. The network interface can accept, communicate and / or connect to a communication network. The network interface can use the following connection protocols, which are such as but not limited to: direct connection, Ethernet (thick, thin, twisted pair 10 / 100 / 1000Base T, etc.), token ring network, wireless connection such as IEEE 802.11ax, etc. The communication network can be any one and / or combination of the following: direct interconnection; Internet; local area network (LAN); metropolitan area network (MAN); secure custom connection; wide area network (WAN); wireless network (e.g., using protocols such as but not limited to wireless application protocol (WAP), I-mode, etc.); etc.

[0075] The memory 203 may be used to store data and code. The memory 203 may be coupled to the processor 201 internally or externally (e.g., cloud-based data storage), and may include any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash memory, or any other suitable memory device.

[0076] The computer readable medium 210 may be in the form of a memory (eg, flash memory, ROM, etc.) and may include code executed by the processor 201 for implementing the methods described herein. The computer readable medium 210 may include an authentication module 211, an encryption module 212, and an application module 213.

[0077] Authentication module 211 may include any program, software, or other code suitable for authenticating computing device 200 to another computing device or authenticating another computing device at computing device 200. For example, authentication module 211 may be configured to generate and send authentication request messages to another computing device, receive and process authentication response messages from the other computing device. Similarly, authentication module 211 may be configured to receive and process authentication request messages from another computing device, and generate and send authentication response messages to the other computing device. In various embodiments, authentication module 211 may be configured to perform Figure 4 , 6 , some or all of methods 400 , 600 , 1000 , 1200 , 1600 , or 1700 , 10 , 12 , 16 , and 17 .

[0078] The encryption module 212 may include any program, software, or other code suitable for performing operations related to encryption. For example, the encryption module may be configured to generate a shared secret, such as using a key agreement protocol (such as Diffie-Hellman). The encryption module 212 may also be configured to derive a session key from a shared secret, such as using a key derivation function (KDF). In some embodiments, the encryption module 212 may be configured to store one or more static keys, such as a static first device private key or a static second device private key. In some embodiments, the encryption module 212 may be implemented using any combination of software (such as host card emulation or HCE) and hardware (such as a hardware security module or HSM).

[0079] Application module 213 may include any program, software, or other code suitable for running one or more applications. For example, application module 213 may include a payment application operable to perform a payment transaction. In some embodiments, the payment application may be configured to allow a user to select goods and services to purchase, obtain security credentials (e.g., cryptographic keys) from the issuer of the payment account, and / or initiate or perform a payment transaction (e.g., using security credentials). Application module 313 may include a payment application service operable to serve a payment application at one or more computing devices. In some embodiments, the payment application service may be configured to allow a user to select goods and services to purchase, provide security credentials (e.g., cryptographic keys) to the computing device, and / or initiate or perform a payment transaction.

[0080] II. Authenticated Communication Method

[0081] Embodiments may use the systems and devices described above to perform methods for authenticated communications. Figure 3-7 Some such methods are described.

[0082] Figure 3A simplified flow chart illustrating communication between a first computing device 301 and a second computing device 302 according to some embodiments is shown. The computing devices 301 and 302 may, in some embodiments, communicate with each other according to Figure 2 The computing device 200 is implemented as Figure 3 As shown, first computing device 301 can send a request message generated using identification data to second computing device 302. Typically, identification data is encrypted or otherwise protected. In some embodiments, the request message may pass through untrusted network 303. Second computing device 302 can process the request message to obtain and verify the identification data. Second computing device 302 can then encrypt the payload data and transmit the encrypted payload data to first computing device 301 in a response message. First computing device 301 can then process the response message to obtain the payload data.

[0083] The second computing device 302 can store a static second device key pair including a static second device public key and a static second device private key. Similarly, the first computing device 301 can store a static first device key pair including a static first device public key and a static first device private key. In addition, the first computing device 301 and / or the second computing device 302 can generate a temporary key pair (i.e., a temporary first device key pair or a temporary second device key pair, respectively). One or more of these keys can be used to encrypt or decrypt request messages and / or response messages.

[0084] In various embodiments, one of the computing devices 301 and 302 may be part of any of the devices, networks, or computers 101-105. For example, in some embodiments, the first computing device 301 may be the user device 101 and the second computing device 302 may be the access device 102 or a server computer. In these embodiments, when a user conducts a transaction, the first computing device 301 communicates with the second computing device 302. In various embodiments, the communication may be based on Figure 4 , 6 , methods 400, 600, 1000, 1200, 1600 or 1700 of 10, 12, 16 and 17 are performed.

[0085] A. First computing device

[0086] Figure 4-5 A method 400 is shown for securely authenticating a second computing device 302 and obtaining response data from the second computing device 302 according to some embodiments. In some embodiments, the method 400 may be performed by the first computing device 301. However, in other embodiments, some or all steps of the method 400 may be performed by other entities.

[0087] At step 401, a temporary key pair is generated. A "temporary key pair" may include a public key (i.e., a "temporary public key") and a private key (i.e., a "temporary private key") generated for use in a single transaction or other communication session. The temporary key pair may be in any suitable form, such as ECC or RSA. Typically, once the communication session using the temporary key ends, or once one or more shared secrets are generated using the temporary key pair, the temporary key pair may be deleted.

[0088] At step 402, an identification factor is calculated using the identification data and the authentication data. The identification data may include any data or information associated with the user or the first computing device 301. Examples of identification data may include the name of the user associated with the first computing device 301, the organization associated with the first computing device 301, payment information associated with the first computing device 301, such as a primary account number (PAN), an expiration date associated with the first computing device 301, a certificate associated with the first computing device 301, an IMEI or serial number of the first computing device 301, and the like. The authentication data may include any data or information suitable for authenticating the user or the first computing device 301. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), and the like. The authentication factor may include any data or information determined from the identification data and / or the authentication data. For example, in some embodiments, the identification factor may be generated by hashing a combination of the identification data and the authentication data.

[0089] In step 403, the identification factor is combined with the temporary public key and the temporary private key. As a result, a combined temporary public key and a combined temporary private key can be determined. The combined key may include a key whose original value has been obfuscated or otherwise modified by combining with another data element or value. For example, the combined temporary public key may be a combination of the temporary public key and the identification factor. Similarly, the combined temporary private key may be a combination of the temporary private key and the identification factor. In some embodiments, combining the key with the data element may include performing a dot product of the key and the data element.

[0090] At step 404, a first shared secret is generated using the combined temporary private key and the static second device public key. The static second device public key may include a static public key stored by the second computing device 302, such as in a secure element. In some embodiments, the static second device public key may be determined from a digital certificate of the second computing device 302, which may have been previously obtained by the first computing device 301 and signed by a trusted certificate authority.

[0091] The shared secret may be generated by combining the temporary private key and the static second device public key using any suitable method. For example, in an embodiment using elliptic curve cryptography, the shared secret may be determined using the Elliptic Curve Diffie-Hellman protocol (ECDH).

[0092] At step 405, a first session key is generated using the first shared secret and the first supplemental data. The first supplemental data may include any other data used to generate the first session key. Examples of the first supplemental data may include a second device identifier and / or a truncated temporary public key.

[0093] The session key may be in any suitable format (e.g., AES, DES, Blowfish, etc.), of any suitable length, generated using any suitable key derivation function (KDF). For example, in one embodiment, the session key may be generated using a Password-Based Key Derivation Function 2 (PBKDF2) algorithm. In some embodiments, other data, such as a first device identifier, may be used as an additional input to the key derivation function.

[0094] At step 406, the temporary public key, the identification data, and the first device identifier are encrypted using the first session key to generate encrypted request data. "First device identifier" may include any identifier suitable for identifying the first computing device.

[0095] At step 407, an authentication request message including the combined temporary public key and the encrypted request data is sent to second computing device 302. In some embodiments, the authentication request message may pass through one or more intermediaries (eg, untrusted network 303) before reaching second computing device 302.

[0096] At step 408, an authentication response message including the blinded static second device public key and the encrypted response data is received from the second computing device 302. Typically, the blinded static second device public key may be a blinded version of the static second device public key used at step 404 to generate the first shared secret.

[0097] At step 409, a second shared secret is generated using the temporary private key and the blinded static second device public key received from the second computing device 302 in step 408. The second shared secret may be generated from the temporary private key and the blinded static second device public key using any suitable method, such as ECDH.

[0098] At step 410, a second session key is generated using the second shared secret and the second supplemental data. The second supplemental data may include any other data used to generate the second session key. Examples of the second supplemental data may include a second device identifier, a first device identifier, and / or a truncated temporary public key. The second session key may be generated using any appropriate KDF.

[0099] In step 411, the encrypted response data is decrypted using the second session key to obtain a cryptographic random number, a second device certificate chain, and payload data. The second device certificate chain may include one or more signed certificate chains from a root CA certificate to the second device certificate, whereby the certificate chain establishes the authenticity of the second device certificate. The payload data may include any appropriate data. For example, the payload data may include a confirmation of the transaction, a user's account balance, a cryptographic key that can be used to perform future transactions, such as a restricted use key (LUK).

[0100] At step 412, the second device certificate chain is verified. The second device certificate chain may be verified using any suitable online or offline method. For example, for each of the one or more certificates in the chain, the digital signature of the certificate may be verified using a known trusted public key (e.g., a public key of a certificate authority or a public key of an entity appropriately authorized by the CA). For example, in some embodiments, a digital signature algorithm such as an elliptic curve digital signature algorithm (ECDSA) may be used to verify the certificate.

[0101] In step 413, the blinded static second device public key is verified using the second device certificate and the cryptographic random number. Verifying the blinded static second device public key may include ensuring that the blinded static second device public key matches the expected value. For example, in some cases, the second blinded static second device public key may be generated using the static second device public key included on the second device certificate and the cryptographic random number decrypted in step 411. The second blinded static second device public key may then be compared with the blinded static second device public key received in step 408 to ensure that the two keys match. Alternatively, in some cases, the blinded static second device public key may be verified by comparing the blinded static second device public key received in step 408 with the stored blinded static second device public key. If the keys match, the second computing device 302 may be authenticated. Otherwise, authentication may fail.

[0102] It should be noted that this authentication method (i.e., verifying a blinded static public key) can provide the advantage that the static second device public key, which may be considered sensitive (because it may reveal the identity of the second computing device 302), does not need to be sent in the clear. Therefore, authentication of the second computing device 302 can be accomplished while protecting the identity of the second computing device 302 from being attacked by an eavesdropper who captures the authentication request message.

[0103] At step 414, the transaction is performed using the payload data. In some embodiments, the payload data may include payment credentials (e.g., a PAN or a cryptographic key). In these embodiments, the transaction may be performed using the payment credentials. For example, if the payload data includes a cryptographic key, a password for the transaction may be generated using the cryptographic key. The password may then be used when conducting the transaction.

[0104] B. Second computing device

[0105] Figure 6-7 A method 600 is shown for securely processing an authentication request message from a first computing device 301 and providing an authentication response message to the first computing device 301 according to some embodiments. In some embodiments, the method 600 may be performed by the second computing device 302. However, in other embodiments, some or all steps of the method 600 may be performed by other entities.

[0106] Typically, prior to method 600, the second computing device 302 stores a static second device key pair. The static second device key pair may include a public key (i.e., a "static second device public key") and a private key (i.e., a "static second device private key"). The second computing device 302 may also include a "second device certificate" that includes the static second device public key. The second device certificate may be signed by a certificate authority, such as the payment processing network 105 or the issuer computer 106.

[0107] At step 601, an authentication request message including a combined temporary public key and encrypted request data is received from first computing device 301. Typically, the combined temporary public key may be generated by first computing device 301 using the temporary public key and an identification factor (eg, according to step 403 of method 400).

[0108] At step 602, a first shared secret is generated using the combined temporary public key and the static second device private key received at step 601. The shared secret may be generated from the combined temporary public key and the static second device private key using any suitable method, such as ECDH.

[0109] At step 603, a first session key is generated using the first shared secret and the first supplemental data. The first supplemental data may include any other data used to generate the first session key. Typically, at step 603, the same data used to generate the first session key at the first computing device (e.g., according to step 405 of method 400) may be used.

[0110] At step 604, the encrypted request data is decrypted using the first session key to obtain request data including a temporary public key, a first device identifier, and identification data. The temporary public key may correspond to the combined temporary public key received at step 601. The first device identifier may include any data suitable for identifying the first computing device 301. The identification data may include any data or information associated with a user or the first computing device 301. Examples of identification data may include the name of a user associated with the first computing device 301, an organization associated with the first computing device 301, payment information associated with the first computing device 301, such as a primary account number (PAN), an expiration date associated with the first computing device 301, a certificate associated with the first computing device 301, an IMEI or serial number of the first computing device 301, and the like.

[0111] At step 605, the identification data is verified using the first device identifier. For example, in some embodiments, the corresponding identification data can be retrieved from a device database using the first device identifier. The decrypted identification data can then be verified by comparing it with the received identification data.

[0112] At step 606, authentication data and / or identification data associated with the first device identifier is retrieved. Authentication data may include any data or information suitable for authenticating a user or first computing device 301. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), etc. In some embodiments, the authentication data may be retrieved from a device database.

[0113] At step 607, an identification factor is generated using the retrieved authentication data and identification data. The identification factor may include any data or information determined from the identification data and / or authentication data. For example, in some embodiments, the identification factor may be generated by hashing a combination of the identification data and the authentication data. Typically, the generation of the identification factor at step 607 is performed in the same manner as at the first computing device 301 (e.g., according to step 402).

[0114] At step 608, the combined temporary public key is verified using the temporary public key and the identification factor. Verifying the combined temporary public key may include ensuring that the combined temporary public key matches an expected value. For example, in some cases, a second combined temporary public key may be generated using the temporary public key obtained at step 604 and the identification factor determined at step 607. The second combined temporary public key may then be compared to the combined temporary public key received at step 601 to ensure that the keys match. If the keys match, first computing device 301 may be authenticated. Otherwise, authentication may fail.

[0115] It should be noted that this authentication method (i.e., verifying the combined temporary key) provides the advantage that the authentication data, which may be sensitive, need not be transmitted in plain text or even in encrypted form. Thus, even if the static second device private key is later compromised (which is unlikely), the plain text authentication data will not be exposed. Furthermore, since the blinding of the keys is generally irreversible, an attacker, even if he knows the combined temporary public key and the temporary public key, cannot derive the identification factor, let alone the authentication data used to generate the identification factor.

[0116] At step 609, a cryptographic random number is generated. The cryptographic random number may be a random or pseudo-random data value generated using any suitable method.

[0117] In step 610, the static second device public key and the static second device private key are blinded using the cryptographic random number and the identification factor. As a result, a blinded static second device public key and a blinded static second device private key can be determined. The blinded key may include a key whose original value has been obfuscated or otherwise modified by combining with one or more other data elements. For example, the combined temporary public key may be a combination of a temporary public key, a cryptographic random number, and an identification factor (e.g., a dot product). Similarly, the combined temporary private key may be a combination of a temporary private key, a cryptographic random number, and an identification factor.

[0118] A second shared secret is generated using the blinded static second device private key and the temporary public key at step 611. The shared secret may be generated by combining the temporary public key and the static second device private key using any suitable method, such as ECDH.

[0119] At step 612, a second session key is generated using the second shared secret and the second supplemental data. The second supplemental data may include any other data used to generate the second session key. Typically, at step 612, the same data used to generate the second session key at the first computing device (e.g., according to step 410 of method 400) may be used.

[0120] In step 613, the cryptographic random number, the second device certificate chain, and the payload data are encrypted using the second session key to generate encrypted response data. The second device certificate chain may include one or more signed certificate chains from the root CA certificate to the second device certificate, whereby the certificate chain establishes the authenticity of the second device certificate. The payload data may include any appropriate data. For example, the payload data may include confirmation of the transaction, the user's account balance, a cryptographic key that can be used to perform future transactions, such as a restricted use key (LUK), and the like.

[0121] At step 614, an authentication response message including the blinded static second device public key and the encrypted response data is sent to first computing device 301. In some embodiments, the authentication response message may pass through one or more intermediaries (eg, untrusted network 303) before reaching first computing device 301.

[0122] III. Authentication Communication Flow

[0123] Figure 8 and Fig. 9 is a data flow diagram illustrating the calculation and transmission of various data elements according to some embodiments of the present invention. Figure 8 and Fig. 9 As shown, rectangular boxes indicate data elements (e.g., identification factors) and circles indicate operations to be performed (e.g., key generation). Each arrow pointing to a circle indicates an operand for a corresponding operator, and each arrow leaving a circle indicates a result of the corresponding operator. However, it should be noted that some embodiments may not use all of the operands shown for an operation, and some embodiments may use additional operands for the operations shown. In addition, embodiments do not necessarily perform all of the operations shown, and / or may perform Figure 8 and Fig. 9 There are no additional operations shown.

[0124] A. Authentication request message

[0125] Figure 8 A data flow diagram illustrating operations performed in generating, transmitting, and processing an authentication request message in accordance with some embodiments is shown.

[0126] like Figure 8As shown in , the first computing device 301 uses a public / private key pair generator (KeyGen) to generate a temporary public key (ePubF) and a temporary private key (ePrivF). The temporary public key (ePubF) is combined with an identification factor (IdFactor) to generate a combined temporary public key (ePubF). Similarly, the temporary private key (ePrivF) is combined with an identification factor (IdFactor) to generate a combined temporary private key (ePrivF*). The first computing device 301 uses the combined temporary private key (ePrivF*) and the static second device public key (PubS) as inputs to an elliptic curve Diffie-Hellman (ECDH) operation to generate a first shared secret (Z1). The first shared secret is used as an input to a key derivation function (KDF) to derive a first session key (SK1). The first computing device 301 uses the first session key (SK1) to encrypt the first device identifier (IdF) and identification data (IdData) with the help of an authenticated encryption (AE) algorithm to generate encrypted request data. The encrypted request data and the combined temporary public key (ePubF*) are sent to the second computing device 302 in a request message.

[0127] Once the second computing device 302 receives the request message, the second computing device 302 generates a first shared secret (Z1) using the received combined temporary public key (ePubF*) and the static second device private key (PrivS). The key derivation function (KDF) uses the first shared secret to derive the first session key (SK1). The second computing device 302 then decrypts the encrypted request data using the first session key (SK1) to determine the identification data (IdData) and the first device identifier (IdF). The first device identifier (IdF) can be used to retrieve (query) previously stored identification data (IdData2) for the first computing device 301. If the retrieved identification data (IdData2) and the decrypted identification data (IdData) match, then the authentication of the first computing device 301 is successful. Otherwise, the authentication fails.

[0128] B. Authentication response message

[0129] Fig. 9 A data flow diagram illustrating operations performed in generating, transmitting, and processing an authentication response message in accordance with some embodiments is shown.

[0130] like Fig. 9As shown in , the second computing device 302 combines (MUL) the static second device private key (PrivS) with the cryptographic random number (NonceS) to generate a blinded static second device private key (PrivS*). Similarly, the static second device public key (PubS) is combined (MUL) with the cryptographic random number (NonceS) and the identification factor (IdFactor) to generate a blinded static second device public key (PubS*).

[0131] The blinded static second device private key (ePrivS*) and the combined temporary first device public key (ePubF*) have been Figure 8 Received in the request message, they are combined using an elliptic curve Diffie-Hellman (ECDH) operation to determine a second shared secret (Z2). The second shared secret (Z2) is used in a key derivation function (KDF) to determine a second session key (SK2). The second computing device 302 encrypts the cryptographic random number (NonceS) and the second device certificate (CertS) to determine the encrypted response data. The second computing device 302 then sends a response message to the first computing device 301 including the encrypted response data and the blinded static second device public key (PubS*).

[0132] Once the first computing device 301 receives the response message, the first computing device 301 uses the received Figure 8 The generated blinded static second device public key (PubS*) and temporary private key (ePrivF) are used to generate a second shared secret (Z2) using an elliptic curve Diffie-Hellman (ECDH) algorithm. A key derivation function (KDF) can be used to generate a second session key (SK2) using the second shared secret (Z2). The second computing device 302 then decrypts the encrypted response data using the second session key (SK2) to determine the second device certificate (CertS), the cryptographic random number (NonceS), and the static second device public key (PubS), which can be extracted from the second device certificate (CertS).

[0133] The second computing device 302 may combine (MUL) the cryptographic random number (NonceS) and the static second device public key (PubS) to generate a second device session identifier (PubS*2). The second device session identifier (PubS*2) is then compared to the blinded static second device public key (PubS*) received from the second computing device 302. Authentication may require that the second device session identifier (PubS*2) and the blinded static second device public key (PubS*) match.

[0134] In addition, the second computing device 302 verifies the second device certificate (CertS) using the Elliptic Curve Digital Signature Algorithm (ECDSA) and the public key of the trusted certificate authority (PubCA). In some embodiments, authentication may require verification of both the blinded static second device public key (PubS*) and the second device certificate (CertS).

[0135] IV. Forward Secrecy Authenticated Communication Method

[0136] In some embodiments of the present invention, first computing device 301 may store a static first device key pair including a public key (i.e., a "static first device public key") and a private key (i.e., a "static first device private key"). Embodiments may use the static first device key pair to generate a second session key used to encrypt and decrypt response data in a response message. This may allow embodiments to provide forward secrecy properties for response messages—a subsequent compromise of device 301 or device 302 will not reveal the encrypted response data. Thus, the embodiments described below may provide additional data transmission security.

[0137] A. First computing device

[0138] Figure 10-11 A second method 1000 is shown for securely authenticating a second computing device 302 and obtaining response data from the second computing device 302 in accordance with some embodiments. In some embodiments, the method 1000 may be performed by the first computing device 301. However, in other embodiments, some or all steps of the method 1000 may be performed by other entities.

[0139] Typically, prior to method 1000, the first computing device 301 may store a “static first device key pair” including a “static first device private key (which may be stored in a secure element) and a “static first device public key”. The static first device public key may be included in a first device certificate signed by a certificate authority recognized by the second computing device 302.

[0140] Similarly, the second computing device 302 may store a “static second device key pair” including a “static second device private key (which may be stored in a hardware security module) and a “static second device public key”. The static second device public key may be included in a second device certificate signed by a certificate authority recognized by the first computing device 301.

[0141] At step 1001, a temporary first device key pair is generated. The "temporary first device public key pair" may include a public key (i.e., a "temporary first device public key") and a private key (i.e., a "temporary first device private key") generated for use in a single transaction or other communication session. The temporary first device key pair may be in any suitable format. Typically, the temporary first device key pair may be deleted once the communication session using the temporary first device key pair ends, or once one or more shared secrets have been generated using the temporary first device key pair.

[0142] At step 1002, an identification factor is calculated using the identification data and the authentication data. In some embodiments, the identification factor may be calculated in a similar manner as described at step 402 of method 400.

[0143] In step 1003, the temporary first device public key and the temporary first device private key are blinded using the identification factor. As a result, a combined temporary first device public key and a combined temporary first device private key can be determined. In some embodiments, the key can be blinded in a similar manner as described in step 403 of method 400.

[0144] At step 1004, a first shared secret is generated using the combined temporary first device private key and the static second device public key. The static second device public key may include a static public key stored by the second computing device 302, such as in a secure element. In some embodiments, the first shared secret may be generated in a similar manner as described at step 404 of method 400.

[0145] At step 1005 , a first session key is generated using the first shared secret and the first supplemental data. In some embodiments, the first session key may be generated in a similar manner as described in step 405 of method 400 .

[0146] At step 1006, the temporary first device public key, the identification data, the first device identifier, and the first device certificate are encrypted using the first session key to generate encrypted request data. The "first device identifier" may include any identifier suitable for identifying the first computing device. The "first device certificate" may include any digital certificate that includes the static first device public key and is signed by a certificate authority recognized by the second computing device 302.

[0147] At step 1007, an authentication request message including the combined temporary first device public key and the encrypted request data is sent to second computing device 302. In some embodiments, the authentication request message may pass through one or more intermediaries (eg, untrusted network 303) before reaching second computing device 302.

[0148] At step 1008, an authentication response message is received from the second computing device 302. The authentication response message includes a blinded static second device public key, a temporary second device public key, and encrypted response data. Typically, the blinded static second device public key can be a blinded version of the static second device public key used to generate the first shared secret at step 1004. The temporary second device public key can be a public key of a temporary key pair generated by the second computing device 302 in response to receiving the authentication request message. For example, in some embodiments, the temporary second device public key can be generated according to step 1213 of method 1200.

[0149] At step 1009 , a second shared secret is generated using the temporary first device private key and the blinded static second device public key. In some embodiments, the second shared secret may be generated in a similar manner as described in step 409 of method 400 .

[0150] At step 1010, an auxiliary shared secret is generated using the temporary second device public key and the static first device private key received at step 1108. The auxiliary shared secret may be generated from the temporary second device public key and the blinded static first device private key using any suitable method, such as ECDH.

[0151] At step 1011, an auxiliary session key is generated using the auxiliary shared secret and the auxiliary supplemental data. The auxiliary supplemental data may include any other data used to generate the auxiliary session key. Examples of the auxiliary supplemental data may include a first device identifier and / or a truncated temporary second device public key.

[0152] At step 1012, a second session key is generated using the second shared secret, the second supplemental data, and the secondary session key. The second supplemental data may include any other data used to generate the second session key. Examples of the second supplemental data may include a second device identifier, a first device identifier, and / or a truncated temporary public key. The second session key may be generated using any appropriate KDF.

[0153] In step 1013, the encrypted response data is decrypted using the second session key to obtain a cryptographic random number, a second device certificate chain, and payload data. The second device certificate chain may include one or more signed certificate chains from a root CA certificate to the second device certificate, whereby the certificate chain establishes the authenticity of the second device certificate. The payload data may include any appropriate data. For example, the payload data may include confirmation of the transaction, a user's account balance, a cryptographic key that can be used to perform future transactions, such as a restricted use key (LUK), and the like.

[0154] At step 1014, the second device certificate chain is verified. The second device certificate chain may be verified using any suitable online or offline method. In some embodiments, the second device certificate chain may be verified in a manner similar to that described in step 412 of method 400.

[0155] At step 1015, the blinded static second device public key is verified using the second device certificate and the cryptographic random number. Verifying the blinded second device public key may include ensuring that the blinded second device public key matches an expected value. In some embodiments, the blinded static second device public key may be verified in a manner similar to that described in step 413 of method 400.

[0156] At step 1116, the transaction is performed using the payload data. In some embodiments, the payload data may include payment credentials (e.g., a PAN or a cryptographic key). In these embodiments, the transaction may be performed using the payment credentials. For example, if the payload data includes a cryptographic key, a cryptographic key can be used to generate a cryptogram for the transaction. The cryptogram can then be used when performing the transaction.

[0157] It should be noted that the use of the auxiliary session key to generate the second session key as described above can provide the advantage of forward secrecy for the authentication response message. For example, even if the blinded static second device public key and the temporary second device public key are perceived by an eavesdropper in transmission, and the static first device private key is later compromised, the second session key cannot be regenerated by the attacker because the temporary first device private key (necessary to generate the second session key) has been deleted. Without the second session key, the encrypted response data cannot be decrypted. Therefore, these embodiments allow communications to remain secure even in the unlikely event of a later compromise of the first computing device 301.

[0158] B. Second computing device

[0159] Figure 12-13 A second method 1200 is shown for securely processing an authentication request message from a first computing device 301 and providing an authentication response message to the first computing device 301 according to some embodiments. In some embodiments, the method 1200 may be performed by the second computing device 302. However, in other embodiments, some or all steps of the method 1200 may be performed by other entities.

[0160] Typically, prior to method 1200, the first computing device 301 may store a "static first device key pair" including a "static first device private key" (which may be stored in a secure element) and a "static first device public key". The static first device public key may be included in a first device certificate signed by a certificate authority recognized by the second computing device 302.

[0161] Similarly, the second computing device 302 may store a “static second device key pair” including a “static second device private key” (which may be stored in a hardware security module) and a “static second device public key.” The static second device public key may be included in a second device certificate signed by a certificate authority recognized by the first computing device 301.

[0162] At step 1201, an authentication request message including a combined temporary first device public key and encrypted request data is received from the first computing device 301. Typically, the combined temporary first device public key may be generated by the first computing device 301 using the temporary first device public key and an identification factor (e.g., according to step 1103 of method 1000).

[0163] At step 1202, a first shared secret is generated using the combined temporary first device public key and the static second device public key received at step 1201. In some embodiments, the first shared secret may be generated in a similar manner as described at step 602 of method 600.

[0164] At step 1203, a first session key is generated using the first shared secret and the first supplemental data. The first supplemental data may include any other data used to generate the first session key. Typically, at step 1203, the same supplemental data used to generate the first session key at the first computing device (e.g., according to step 1005 of method 1000) may be used.

[0165] At step 1204, the encrypted request data is decrypted using the first session key to obtain request data including a temporary first device public key, a first device identifier, identification data, and a first device certificate. The temporary first device public key may correspond to the combined temporary public key received at step 1201. The first device identifier may include any data suitable for identifying the first computing device 301. The identification data may include any data or information associated with a user or the first computing device 301. The first device certificate may include any digital certificate that includes a static first device public key.

[0166] At step 1205 , the identification data is verified using the first device identifier. In some embodiments, the identification data may be verified in a similar manner as described at step 605 of method 600 .

[0167] At step 1206 , authentication data and / or identification data associated with the first device identifier is retrieved. In some embodiments, the authentication data may be retrieved in a similar manner as described at step 606 of method 600 .

[0168] At step 1207, an identification factor is generated using the retrieved authentication data and identification data. In some embodiments, the identification factor may be generated in a similar manner as described at step 607 of method 600.

[0169] At step 1208 , the combined temporary first device public key is verified using the temporary first device public key and the identification factor. In some embodiments, the combined temporary first device public key may be verified in a similar manner as described at step 608 of method 600 .

[0170] At step 1209, the first device certificate is verified. For example, in some embodiments, a digital signature algorithm, such as an elliptic curve digital signature algorithm (ECDSA), may be used to verify the device certificate. If the combined temporary first device public key and the device certificate are respectively verified and confirmed to be valid, the first computing device 301 is authenticated. Otherwise, the authentication of the first computing device 301 may fail.

[0171] At step 1210, a cryptographic random number is generated. The cryptographic random number may be a random or pseudo-random data value generated using any suitable method.

[0172] In step 1211, the static second device public key and the static second device private key are blinded using the cryptographic random number and the identification factor. As a result, a blinded static second device public key and a blinded static second device private key can be determined. In some embodiments, the key can be blinded in a similar manner as described in step 610 of method 600.

[0173] At step 1212, a second shared secret is generated using the blinded static second device private key and the temporary first device public key. The second shared secret may be generated from the temporary first device public key and the blinded static second device private key using any suitable method, such as ECDH.

[0174] At step 1213, a temporary second device key pair is generated. The "temporary second device key pair" may include a public key (i.e., a "temporary second device public key") and a private key (i.e., a "temporary second device private key") generated for use in a single transaction or other communication session. The temporary second device key pair may be in any suitable format. Typically, the temporary second device key pair may be deleted once the communication session using the temporary second device key pair ends, or once one or more shared secrets have been generated using the temporary second device key pair.

[0175] At step 1214, an auxiliary shared secret is generated using the temporary second device private key and the static first device public key. The auxiliary shared secret may be generated from the temporary second device private key and the static first device public key using any suitable method, such as ECDH.

[0176] At step 1215, an auxiliary session key is generated using the auxiliary shared secret and the auxiliary supplemental data. The auxiliary supplemental data may include any other data used to generate the auxiliary session key. Typically, at step 1215, the same auxiliary supplemental data may be used as used to generate the auxiliary session key at the first computing device (e.g., according to step 1011 of method 1000).

[0177] At step 1216, a second session key is generated using the second shared secret, the second supplemental data, and the auxiliary session key. Typically, at step 1216, the same supplemental data as used to generate the second session key at the first computing device (e.g., according to step 1012 of method 1000) may be used. The second session key may be generated using any suitable KDF.

[0178] At step 1217, the cryptographic random number, the second device certificate chain, and the payload data are encrypted using the second session key to generate encrypted response data. The second device certificate chain may include one or more signed certificate chains from the root CA certificate to the second device certificate, whereby the certificate chain establishes the authenticity of the second device certificate. The payload data may include any appropriate data. For example, the payload data may include confirmation of the transaction, a balance in a user account, a cryptographic key that can be used to perform future transactions, such as a restricted use key (LUK), and the like.

[0179] At step 1218, an authentication response message including the blinded static second device public key, the temporary second device public key, and the encrypted response data is sent to the first computing device 301. In some embodiments, the authentication response message may pass through one or more intermediaries (e.g., untrusted network 303) before reaching the first computing device 301.

[0180] It should be noted that using the auxiliary session key to generate the second session key as described above can provide the advantage of forward secrecy for the authentication response message. For example, even if the blinded static second device public key and the temporary second device public key are perceived by an eavesdropper during transmission, and the static second device private key is later compromised, the second session key cannot be regenerated by the attacker because the temporary second device private key (necessary to regenerate the second session key) has been deleted. Without the second session key, the encrypted response data cannot be decrypted. Therefore, these embodiments allow the communication to remain secure even in the unlikely event of a subsequent compromise of the second computing device 302.

[0181] V. Forward Secrecy Authenticated Communication Flow

[0182] Fig.14 and 15 is a data flow diagram illustrating the calculation and transmission of various data elements according to some embodiments of the present invention. Figure 8 and9 As shown, rectangular boxes indicate data elements (e.g., identification factors), and circles indicate operations to be performed (e.g., key generation). Each arrow pointing to a circle indicates an operand of a corresponding operator, and each arrow leaving a circle indicates a result of a corresponding operator. However, it should be noted that some embodiments may not use all of the operands shown for an operation, and some embodiments may use additional operands for the operations shown. In addition, embodiments may not necessarily perform all of the operations shown, and / or may perform Fig.14 and 15 There are no additional operations shown.

[0183] A. Authentication request message

[0184] Fig.15 Shown is a data flow diagram illustrating operations performed in a second method of generating, transmitting, and processing an authentication request message in accordance with some embodiments.

[0185] like Fig.15 As shown, the first computing device 301 uses a public / private key pair generator (KeyGen) to generate a temporary first device public key (ePubF) and a temporary first device private key (ePrivF). The temporary first device public key (ePubF) is combined with an identification factor (IdFactor) to generate a combined temporary first device public key (ePubF). Similarly, the temporary first device private key (ePrivF) is combined with an identification factor (IdFactor) to generate a combined temporary first device private key (ePrivF*). The first computing device 301 uses the combined temporary first device private key (ePrivF*) and the static second device public key (PubS) as inputs to an elliptic curve Diffie-Hellman (ECDH) operation to generate a first shared secret (Z1). The first shared secret is used as an input to a key derivation function (KDF) to derive a first session key (SK1). The first computing device 301 uses the first session key (SK1) to encrypt the first device identifier (IdF) and identification data (IdData) with the help of the authenticated encryption (AE) algorithm to generate encrypted request data. The encrypted request data, the combined temporary first device public key (ePubF*) and the first device certificate (CertF) are sent to the second computing device 302 in a request message.

[0186] Once the second computing device 302 receives the request message, the second computing device 302 generates a first shared secret (Z1) using the received combined temporary first device public key (ePubF*) and the static second device private key (PrivS). Using the first shared secret, a key derivation function (KDF) is used to derive a first session key (SK1). The second computing device 302 then decrypts the encrypted request data using the first session key (SK1) to determine the identification data (IdData) and the first device identifier (IdF). The first device identifier (IdF) can be used to retrieve (query) previously stored identification data (IdData2) for the first computing device 301. If the retrieved identification data (IdData2) and the decrypted identification data (IdData) match, then the authentication of the first computing device 301 may be successful. Otherwise, the authentication may fail.

[0187] In addition, the second computing device 302 verifies the first device certificate (CertF) using the digital signature algorithm (ECDSA) and the public key of the trusted certificate authority (PubCA). In some embodiments, successful authentication of the first computing device 301 may require verification of both the identification data (IdData) and the first device certificate (CertF).

[0188] B. Authentication response message

[0189] Fig.16 A data flow diagram illustrating operations performed in a second method of generating, transmitting, and processing an authentication response message in accordance with some embodiments is shown.

[0190] like Fig.16 As shown, the second computing device 302 combines (MUL) the static second device private key (PrivS) with the cryptographic random number (NonceS) to generate a blinded static second device private key (PrivS*). Similarly, the static second device public key (PubS) is combined (MUL) with the cryptographic random number (NonceS) and the identification factor (IdFactor) to generate a blinded static second device public key (PubS*).

[0191] Already based on Fig.15 The blinded static second device private key (ePrivS*) and the combined temporary first device public key (ePubF*) received in the request message are combined using an Elliptic Curve Diffie-Hellman (ECDH) operation to determine a second shared secret (Z2).

[0192] In addition, the second computing device 302 uses the public / private key pair generator (KeyGen) to generate a temporary second device public key (ePubS) and a temporary second device private key (ePrivS). Fig.15The temporary second device private key (ePrivS) extracted from the first device certificate (CertF) and the static first device public key (PubF) are combined using the Elliptic Curve Diffie-Hellman (ECDH) algorithm to determine the auxiliary shared secret.

[0193] The auxiliary shared secret and the second shared secret (Z2) are used in a key derivation function (KDF) to determine a second session key (SK2). The second computing device 302 encrypts the cryptographic random number (NonceS) and the second device certificate (CertS) to determine the encrypted response data. The second computing device 302 then sends a response message including the encrypted response data, the blinded static second device public key (PubS*), and the temporary second device public key to the first computing device 301.

[0194] Once the first computing device 301 receives the response message, the first computing device 301 uses the received Fig.15 The generated blinded static second device public key (PubS*) and temporary private key (ePrivF) are used to generate a second shared secret (Z2) by using an elliptic curve Diffie-Hellman (ECDH) algorithm. In addition, the first computing device 301 uses the received temporary second device public key (ePubS) and the static first device private key (PrivF) that can be stored at the first computing device 301 as inputs to the elliptic curve Diffie-Hellman (ECDH) algorithm to generate an auxiliary shared secret.

[0195] A key derivation function (KDF) may be used to generate a second session key (SK2) using the auxiliary shared secret and the second shared secret (Z2). The second computing device 302 then decrypts the encrypted response data using the second session key (SK2) to determine the second device certificate (CertS), the cryptographic random number (NonceS), and the static second device public key (PubS), which may be extracted from the second device certificate (CertS).

[0196] The second computing device 302 can combine (MUL) the cryptographic random number (NonceS) and the static second device public key (PubS) to generate a second device session identifier (PubS*2). The second device session identifier (PubS*2) is then compared to the blinded static second device public key (PubS*) received from the second computing device 302. Authentication may require that the second device session identifier (PubS*2) and the blinded static second device public key (PubS*) match.

[0197] In addition, the second computing device 302 verifies the second device certificate (CertS) using the Elliptic Curve Digital Signature Algorithm (ECDSA) and the public key of the trusted certificate authority (PubCA). In some embodiments, authentication may require verification of both the blinded static second device public key (PubS*) and the second device certificate (CertS).

[0198] VI. Optimizing the communication method for authentication

[0199] In some embodiments of the present invention, the first computing device 301 and the second computing device 302 can each save a registration of devices with which communication has occurred in the past. Each registered device can be associated with the next shared secret and / or other data used in future communication sessions associated with the registered device. In this way, embodiments can avoid certain operations, such as Diffie-Hellman key negotiation, in any subsequent communication between the two devices. Therefore, embodiments can reduce the amount of time and processing required to establish a communication session. In addition, embodiments can protect the identity of the second computing device 302 while obtaining these benefits, which will be described in more detail below.

[0200] A. First computing device

[0201] Fig.16 An optimized method 1600 is shown for securely authenticating a second computing device 302 and obtaining response data from the second computing device 302 in accordance with some embodiments. In some embodiments, the method 1600 may be performed by the first computing device 301. However, in other embodiments, some or all steps of the method 1600 may be performed by other entities.

[0202] In step 1601, steps 401-408 of method 400 are performed. Specifically, a temporary key pair including a temporary public key and a temporary private key is generated. An identification factor is calculated using identification data and authentication data. The temporary public key and the temporary private key are combined using the identification factor. As a result, a combined temporary public key and a combined temporary private key can be determined. A first shared secret is generated using the combined temporary private key and a static second device public key. A first session key is generated using the first shared secret and first supplementary data. The temporary public key, the identification data, and the first device identifier are encrypted using the first session key to generate encrypted request data. An authentication request message including the combined temporary public key and the encrypted request data is sent to the second computing device 302. Then, an authentication response message including a blinded static second device public key and encrypted response data is received from the second computing device 302. Further description of these steps can be found with reference to the corresponding steps of method 400.

[0203] At step 1602, a second device session identifier is determined. In some embodiments, the second device session identifier may be a subset (eg, the last 4 or 8 digits) of the blinded static second device public key received in the authentication response message.

[0204] At step 1603, it is determined whether the second device session identifier is registered. For example, in some embodiments, a registry may be searched for the second device session identifier. If registered, method 1600 proceeds to step 1604. Otherwise, method 1600 proceeds to step 1605.

[0205] If the second device session identifier is registered, then at step 1604, a shared secret associated with the second device session identifier is obtained. For example, in some embodiments, the shared secret may be retrieved from a record of the registration associated with the second device session identifier. The method 1600 then proceeds to step 1606.

[0206] If the second device session identifier is not registered, then at step 1605, step 409 of method 400 is performed. Specifically, a second shared secret is generated using the temporary private key and the blinded static second device public key received in the authentication response message.

[0207] At step 1606, steps 410-414 of method 400 are performed. Specifically, a second session key is generated using the second shared secret and the second supplemental data. The encrypted response data received in the authentication response message is decrypted using the second session key to obtain a cryptographic random number, a second device certificate chain, and payload data. The second device certificate chain is verified. The transaction is then conducted using the payload data.

[0208] At step 1607, a next shared secret and a next second device session identifier are generated using the shared secret. The next shared secret and the next second device session identifier may be generated from the shared secret in any suitable manner. For example, in some embodiments, the next shared secret and the next second device session identifier may be determined using a key derivation function. For example, the key derivation function used to generate the second session key at step 1606 may also generate the next shared secret.

[0209] At step 1608, the next second device session identifier is registered and associated with the next shared secret. For example, in some embodiments, the next second device session identifier and the next shared secret may be stored in a registry or database.

[0210] B. Second computing device

[0211] Fig.17An optimized method 1700 is shown for securely processing an authentication request message from a first computing device 301 and providing an authentication response message to the first computing device 301 according to some embodiments. In some embodiments, the method 1700 may be performed by the second computing device 302. However, in other embodiments, some or all steps of the method 1700 may be performed by other entities.

[0212] At step 1701, steps 601-608 of method 600 are performed. Specifically, an authentication request message including a combined temporary public key and encrypted request data is received from the first computing device 301. A first shared secret is generated using the combined temporary public key and a static second device private key. A first session key is generated using the first shared secret and the first supplemental data. The encrypted request data is decrypted using the first session key to obtain request data including a temporary public key, a first device identifier, and identification data. The identification data is verified using the first device identifier. Authentication data and / or identification data associated with the first device identifier is retrieved. An identification factor is generated using the retrieved authentication data and identification data. The combined temporary public key is verified using the temporary public key and the identification factor. Further description of these steps can be found with reference to the corresponding steps of method 600.

[0213] At step 1702, it is determined whether the first device identifier is registered. For example, in some embodiments, a registry may be searched for the first device identifier. If registered, the method 1700 proceeds to step 1703. Otherwise, the method 1700 proceeds to step 1704.

[0214] If the first device identifier is registered, then at step 1703, a shared secret and a blinded static second device public key associated with the first device identifier are obtained. For example, in some embodiments, the shared secret and the blinded static second device public key may be retrieved from a record of a registry associated with the first device identifier. The method 1700 then proceeds to step 1705.

[0215] If the first device identifier is not registered, then at step 1704, steps 709-711 of method 600 are performed. Specifically, a cryptographic random number is generated. The static second device public key and the static second device private key are blinded using the cryptographic random number and the identification factor. The blinded static second device private key and the temporary public key are then used to generate a second shared secret.

[0216] At step 1705, steps 712-714 of method 600 are performed. Specifically, a second session key is generated using the second shared secret and the second supplemental data. The cryptographic random number, the second device certificate chain, and the payload data are encrypted using the second session key to generate encrypted response data. An authentication response message including the blinded static second device public key and the encrypted response data is then sent to the first computing device 301.

[0217] In step 1706, a next shared secret and a next blinded second device public key are generated using the shared secret. The next shared secret and the next blinded second device public key may be generated from the shared secret in any suitable manner. For example, in some embodiments, the next shared secret may be determined using a key derivation function. For example, the key derivation function used to generate the second session key in step 1705 may also generate the next shared secret.

[0218] At step 1707, the first device identifier is registered and associated with a next shared secret and a next blinded second device public key. For example, in some embodiments, the next blinded second device public key and the next shared secret may be stored in a registry or database entry corresponding to the first device identifier.

[0219] VII. Pseudocode Listing

[0220] Tables 1 and 2 below show pseudo-code listings of secure methods for implementing authenticated data communications according to some embodiments of the present invention.

[0221] A. First computing device

[0222]

[0223]

[0224]

[0225] Table 1

[0226] Table 1 shows a pseudo code listing of a method for implementing secure authentication and obtaining response data according to some embodiments. Some steps described below may be based on a first computing device 301 communicating with a second computing device 302. However, in embodiments of the present invention, some or all of the steps may be performed by another appropriate entity.

[0227] Prior to the method, the first computing device 301 may optionally store one or more data elements, such as authentication data (AuthData F ), identification data (IdData F ), the second device certificate (C s ), Persistent Binding Registry (PB Registry), Cipher Suite Specification (CipherSpec), Static First Device Private Key (d sF ) and / or first device certificate (CF).

[0228] In addition, in some embodiments, the first computing device 301 may be required to store the first device identifier (ID sF ) and the first device control byte (CB) indicating the protocol data of the communication F).

[0229] In step F1, if the identification data is saved but the second device certificate is not available, the identification data is invalid. In other words, the identification data is not sent in the request message.

[0230] In step F2, a temporary first device key pair is generated. The temporary first device key pair includes a temporary first device private key (d eF ) and the temporary first device public key (Q eF ). In embodiments using elliptic curve keys, the temporary key may be generated on the same curve as the second device certificate (if available).

[0231] At step F3, a check is performed to determine whether identification data or authentication data is available. If either is available, then at step F4, an identification factor (IdFactor) is generated by hashing the combination of the identification data and the authentication data and taking the most significant 4 bytes (T4) of the result. Otherwise, at step F5, the identification factor is assigned 1 (i.e., a multiplication unit).

[0232] In step F6, the combined temporary first device public key (Q) is calculated by determining the dot product of the identification factor and the temporary first device public key. eF *).

[0233] At step F7 , if authentication data is available, the first device control byte is modified to indicate that the authentication data should be used to authenticate the first computing device 301 .

[0234] At step F8, a check is performed to determine whether the second device certificate is available. If the second device certificate is available, steps F9-F13 are performed. Otherwise, the method proceeds to step 14.

[0235] In step F9, the second device certificate is authenticated (eg, its digital signature may be verified). Once authenticated, the static second device public key (Q sS ) and a second device certificate identifier (Cfp S ).

[0236] At step F10, a first shared secret (Z1) is generated using the Elliptic Curve Diffie-Hellman (ECDH) algorithm. The input to the ECDH algorithm is a combined temporary first device private key (generated from the identification factor and the temporary first device private key) and a static second device public key.

[0237] In step F11, a key derivation function (KDF) is used to derive a first session key (SK1). The input to the KDF is the first shared secret, the desired output length (len), and the second device identifier (ID sS) and the most significant 16 bytes of the combined temporary first device public key (T 16 ) combination.

[0238] In step F12, the first session key is used to generate the encrypted request data (EncData) using the authenticated encryption (AE) algorithm. F ). The request data includes a predetermined defined header ("KC_0_V"), a first device identifier, a first device control byte, a cipher suite specification, identification data, and a first device certificate.

[0239] At step F13, a request message (CData) is formed using the predefined value (OPTY), the second device certificate identifier, the combined temporary first device public key and the encrypted data.

[0240] At step F14, if the second device certificate is not available, then at step F15 a request message is formed using the first device identifier, the combined temporary first device public key, the first device control byte and the cipher suite specification.

[0241] In step F16, a request message is sent.

[0242] After step F16, wait until a response message is received. The response message includes the blinded static second device public key (BData S ), temporary second device public key (Q eS ) ) and the encrypted response data (EncData S ).

[0243] In step F17, the blinded static second device public key and the temporary second device public key are checked to ensure that they belong to the appropriate elliptic curve domain.

[0244] In step F18, the second device session identifier (ID sS ).

[0245] At step F19, the persistent binding registry is examined to determine if there is an entry for the second device session identifier. At step F20, a check is performed to determine if the second device session identifier is registered. If registered, the method proceeds to step F21. Otherwise, the method proceeds to step F28.

[0246] In step F21, a check is performed to determine the static first device public key (Q sF ) is available. If available, steps F22 and F23 are performed. Otherwise, the method proceeds to step F24.

[0247] In step F22, the auxiliary shared secret (Z) is determined using the ECDH algorithm. aux). The input of ECDH includes a static first device private key and a temporary second device public key.

[0248] In step F23, the secondary session key (SK) is derived using a key derivation function. aux ). The input to the key derivation function comprises the auxiliary shared secret, the desired key length and a combination of the first device identifier and the first 16 bytes of the temporary second device public key. The method then proceeds to step F26.

[0249] At step F24, if the static first device public key is not available, then at step F25, the auxiliary shared secret is set to a NULL value.

[0250] At step F26 , a second shared secret ( Z2 ) is generated using the temporary first device private key and the blinded static second device public key.

[0251] At step F27, the temporary first device private key is zeroed. Zeroing may include, for example, securely and completely deleting a value. The method then proceeds to step F30.

[0252] At step F28 , if the second device session identifier is registered, a second shared secret is retrieved from the persistent binding registry.

[0253] In step F30, a second session key (SK CFRM ), several other keys (SK MAC SK ENC SK RMAC ), the next shared secret (NextZ) and the next blinding factor (NextBlind). The input to the KDF includes a combination of the second shared secret, the expected key length, the auxiliary session key, and other data, such as the second device identifier, the first device identifier, and the first 16 bytes of the temporary first device public key.

[0254] In step F31 , the second session key and the auxiliary session key are reset to zero.

[0255] In step F32, the second session key is used to decrypt (AE -1 ) encrypted response data. The generated response data includes a predefined header (Header), a second device certificate, a cryptographic random number (N S ), the second device control byte (CB S ), a new second device certificate (NewC S ), new cipher suite specification (NewCipherSpec) to be used in future communications, and payload (Payload).

[0256] In step F33, the predefined header is verified by checking that it matches the expected value.

[0257] The second device control byte is also verified.

[0258] In step F34, the second session key is reset to zero.

[0259] At step F35, a check is performed to determine whether the server control byte indicates that a persistent binding should be reestablished, whether the server control byte indicates that persistent binding is not supported, or whether the second device session identifier is not found in the registry. If any of the above is true, the method proceeds to steps F36-F38. Otherwise, the method proceeds to step F39.

[0260] In step F36, the digital signature of the second device certificate is verified using the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0261] In step F37, the static second device public key (Q sS ).

[0262] At step F38, the blinded static second device public key is verified by recalculating it using the first four digits of the cryptographic random number and the static second device public key.

[0263] In step F39, if the server control byte indicates that persistent binding is to be initialized or otherwise performed, steps F40 and F41 are performed.

[0264] In step F40, the next second device session identifier (NextId) is calculated by taking the first 8 bytes of the dot product of the next blinding factor and the static second device public key. sS ).

[0265] In step F41 , a next second device session identifier is registered and associated with a next shared secret.

[0266] B. Second computing device

[0267]

[0268]

[0269]

[0270]

[0271] Table 2

[0272] Table 2 shows a pseudo code listing for implementing a method for securely processing an authentication request message and providing an authentication response message according to some embodiments. Some of the steps described below may be based on a second computing device 302 in communication with a first computing device 301. However, in embodiments of the present invention, some or all of the steps may be performed by another appropriate entity.

[0273] Prior to the method, the second computing device 302 may optionally store one or more data elements, such as authentication data (AuthData) for the first computing device 301 or an associated user. S ), a persistent binding (PB) registry, and / or a data payload (Payload), which may also be determined in response to the request message.

[0274] In addition, in some embodiments, the second computing device 302 may be required to store or access a static second device public key (Q sS ) and the static second device private key (d sS ) of the static second device key pair, indicating the second device control byte (CB) of the protocol data S ), a list of encryption suite preferences (CSList) and / or a list of certificates that can be used to communicate with the second computing device 302 (CertList).

[0275] In step S1, a request message (CData) is received. The request message may include a predefined value (OPTY) indicating the presence of encrypted data, a second device certificate identifier (Cfp S ), combined with the temporary first device public key (Q eF *) and the encrypted request data (EncData F ). Alternatively, in some cases, the request message may include a first device identifier (ID sF ), combined temporary first device public key, first device control byte (CB F ) and cipher suite specification (CipherSpec).

[0276] In step S2, the first four bytes (T4) of the request message are examined to determine whether they include a predefined value. If so, the method proceeds to step S3. Otherwise, the method proceeds to step S8.

[0277] In step S3, the data elements of the request message are isolated. Specifically, since the request message includes predefined values, the second device certificate identifier, the combined temporary first device public key and the encrypted request data (EncData F ).

[0278] At step S4, the second device certificate identifier and the list of certificates are used to retrieve the second device certificate associated with the request message.In addition, a static second device private key corresponding to the retrieved certificate can be determined.

[0279] At step S5, a first shared secret (Z1) is generated using the Elliptic Curve Diffie-Hellman (ECDH) algorithm. The input to the algorithm comprises the received combined temporary first device public key and the static second device private key.

[0280] In step S6, a key derivation function (KDF) is used to derive the first session key (SK1). The input to the KDF includes the first shared secret, the expected key length (len), and the first 16 bytes of the second device session identifier (IDsS) and the combined temporary first device public key (T 16 ) combination.

[0281] In step S7, the first session key is used to decrypt using the authentication (AE) -1 ) function decrypts the encrypted request data. The generated request data includes: a predefined header string with expected values ​​("KC_0_V"), a first device identifier, a first device control byte, a cryptographic suite specification, identification data (IdData F ), and optionally a first device certificate (C F ). The method then proceeds to step S10.

[0282] At step S8, if the first four bytes of the request message do not include the predefined value, then at step S9, the data elements in the request message are isolated. Specifically, the first device identifier, the combined temporary first device public key, the first device control byte and the cipher suite specification are determined.

[0283] In step S10, if it is determined that the identification data is from the first device and the authentication of the identification data fails, then in step S11, a response message including a control byte indicating the authentication failure is returned.

[0284] In step S12, if the first device control byte indicates that authentication data was used to generate the request message, the first device identifier is used to retrieve the authentication data (AuthData S ). For example, the authentication data may be retrieved from a device database.

[0285] If, at step S13, the authentication data cannot be successfully retrieved (eg, no first device identifier is available, or no authentication data is available for the first device identifier), then at step S14 a response message is returned including a control byte indicating that the authentication failed.

[0286] In step S15, if the cipher suite specification determined from the request message is not supported, then in step S16, a response message including a control byte indicating that the cipher suite is invalid is returned.

[0287] At step S17, if the cipher suite specification is insufficient or not allowed, the method proceeds to steps S18-S20.

[0288] In step S18, the second device control byte is modified to indicate that the cipher suite is to be changed. In step S19, the new cipher suite specification (NewCipherSpec) is set to the list of cipher suite preferences. In step S20, the new second device certificate (NewCipherSpec) is set to the list of cipher suite preferences. S ) is set to the list of certificates that can be used in the communication. The method then proceeds to step S22.

[0289] In step S21, if the cipher suite specification is sufficiently allowed, the new cipher suite specification is identical to the (current) cipher suite specification, and the new second device certificate is identical to the (current) second device certificate.

[0290] The steps following step S21 generally involve forming and sending a response message. These steps may be determined using the cipher suite specification and the previously made server certificate. For example, if at step S20 a new second device certificate is used to form the response message, then the static second device public key (Q sS ) or a static second device private key (d sS ) may reference those corresponding to the new second device certificate, which is different from the key of the second device certificate corresponding to the association request message.

[0291] In step S22, if the first device certificate is determined from the request message, the method proceeds to steps S23 and S24. Otherwise, the method proceeds to step S25.

[0292] In step S23, the static first device public key (Q) is extracted from the first device certificate. sF ). The static first device public key is verified to ensure that it belongs to the correct elliptic curve domain.

[0293] Step S24: Generate a temporary second device key pair. The temporary second device key pair includes a temporary second device private key (d eS ) and the temporary second device public key (Q eS ). The method then proceeds to step S26.

[0294] In step S25, if the first device certificate is not determined from the request message, the temporary second device public key is set to a null value.

[0295] In step S26, a second device control byte is prepared using the first device control byte.

[0296] In step S27, a cryptographic random number (N S ).

[0297] In step S28, it is determined whether (1) the first device identifier is not registered, or (2) the first device control byte indicates that persistent binding is not required. If either of these two conditions is false, the method proceeds to step S29. Otherwise, if both conditions are true, the method proceeds to step S39.

[0298] In step S29, the temporary first device public key is verified to ensure that it belongs to the correct elliptic curve domain.

[0299] In step S30, a check is performed to determine whether identification data or authentication data is available. If either is available, the method proceeds to step S31. Otherwise, the method proceeds to step S33.

[0300] In step S31, an identification factor (IdFactor) is generated by hashing the combination of identification data and authentication data and taking the most significant four bytes (T4) of the result.

[0301] At step S32, the combined temporary first device public key is recalculated using the temporary first device public key and the identification factor. If the recalculated key does not match the received key, a response message including a control byte indicating authentication failure is returned.

[0302] At step S33, if neither identification data nor authentication data is available, the identification factor is set to 1 (ie, multiplication unit).

[0303] In step S34, if a static first device public key is available, the method proceeds to steps S35-S36. Otherwise, the method proceeds to step S37.

[0304] In step S35, the auxiliary shared secret (Z) is calculated using the temporary second device private key and the static first device public key as inputs to the ECDH algorithm. aux In step S36, a KDF is used to derive the auxiliary session key (K) using the auxiliary shared secret, the desired key length, and a combination of the first device identifier and the first 16 bytes of the temporary second device public key as input. aux ). The method then proceeds to step S38.

[0305] In step S37, if the static first device public key is not available, the secondary session key is set to a null value.

[0306] In step S38, the second shared secret (Z2) is calculated using the ECDH algorithm. The first input to the ECDH algorithm includes a combination of the first four bytes of the cryptographic random number and the static second device private key. The second input to the ECDH algorithm includes a combined temporary first device public key.

[0307] In step S39, the blinded static second device public key (BData) is calculated by combining the identification factor, the first four bytes of the cryptographic random number and the static second device public key. S ). The method then proceeds to step S43.

[0308] In step S40, if the first device identifier is registered and the first device control byte indicates that persistent binding is required, the method proceeds to steps S41 and S42. Otherwise, the method proceeds to step S43.

[0309] At step S41, the second shared secret and the blinded static second device public key are read from the persistent binding registry entry corresponding to the first device identifier. At step S42, the second device control byte is modified to indicate that persistent binding is enabled.

[0310] In step S43, the second device session identifier (ID sS ).

[0311] In step S44, a key derivation function (KDF) is used to generate a second session key (SK CFRM ), several other keys (SK MAC SK ENC SK RMAC ), the next shared secret (NextZ) and the next blinding factor (NextBlind). The input to the KDF includes a combination of the second shared secret, the expected key length, the auxiliary session key, and other data, such as the second device session identifier, the first device identifier, and the first 16 bytes of the temporary first device public key.

[0312] In step S45, the second shared secret and the secondary session key are reset to zero.

[0313] In step S46, if both the first computing device 301 and the second computing device 302 support persistent binding, and either the first device identifier is not registered or the first device control byte indicates that persistent binding should be initialized, the method proceeds to steps S47-S48. Otherwise, the method proceeds to step S49.

[0314] In step S47, the next blinded static second device public key (NextBData) is determined by combining the next blinding factor and the static second device public key. S). The first device identifier is then registered and associated with the next shared secret and the next blinded static second device public key. In step S48, the second device control byte is modified to indicate that a persistent binding is to be initialized. The method then proceeds to step S51.

[0315] At step S49, if the condition of step S46 is not true, then at step S50 the second device control byte is modified to indicate that the persistent binding has not been used in the response message.

[0316] In step S51, the second session key is used to generate encrypted response data (EncData) using the authenticated encryption (AE) function. S ). The response data includes a predefined header ("KC_1_V"), a cryptographic random number, a second device control byte, a second device certificate, a new second device certificate, a new encryption suite specification, and a payload. The payload may include any appropriate data.

[0317] In step S52, the second session key is reset to zero.

[0318] In step S53, a response message (RData) including the blinded static second device public key, the temporary second device public key and the encrypted response data is sent.

[0319] VIII. Computer Equipment

[0320] Fig.18 A block diagram of an exemplary computer device is shown. It is a high-level block diagram of a computer system that can be used to implement any of the entities or components described above. Fig.18 The subsystems shown in FIG. 1800 are interconnected via a system bus 1875. Additional subsystems include a printer 1803, a keyboard 1806, a fixed disk 1807, and a monitor 1809, which is coupled to a display adapter 1804. Peripheral devices and input / output (I / O) devices are coupled to the I / O controller 1800, and the peripheral devices and input / output (I / O) devices can be connected to the computer system by any means known in the art, such as a serial port. For example, a serial port 1805 or an external interface 1808 can be used to connect the computer device to a wide area network (such as the Internet), a mouse input device, or a scanner. The interconnection via the system bus 1875 allows the central processor 1802 to communicate with each subsystem and control the execution of instructions from the system memory 1801 or the fixed disk 1807 and the exchange of information between these subsystems. The system memory 1801 and / or the fixed disk can embody a computer readable medium.

[0321] Storage media and computer-readable media for containing code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented with any method or technology for storing and / or transmitting information (such as computer-readable instructions, data structures, program modules or other data), including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium that can be used to store or transmit the desired information and can be accessed by a computer. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods to implement various embodiments.

[0322] The above description is illustrative and not restrictive. After reading this disclosure, those skilled in the art will understand many variations of the present invention. Therefore, the scope of the present invention may not be determined with reference to the above description, but may be determined with reference to the attached claims together with their full scope or equivalents.

[0323] It should be understood that any embodiment of the present invention can be implemented in a modular or integrated manner using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or using computer software with a general-purpose programmable processor in the form of control logic. 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. Based on the disclosure and teachings provided herein, those skilled in the art can understand and recognize other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0324] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language (for example, Java, C, C++, C#, Objective-C, Swift) or scripting language (such as Perl or Python), using, for example, traditional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable non-transient computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media (such as a hard disk or floppy disk) or optical media (such as a compact disk (CD) or DVD (digital versatile disk)), flash memory, etc. The computer-readable medium can be any combination of these storage or transmission devices.

[0325] These programs can also use carrier signal encoding and transmission, and carrier signal is suitable for transmitting by following the wired, optical and / or wireless network (comprising the Internet) of various protocols.Therefore, the computer-readable medium according to an embodiment of the present invention can use the data signal with these program encodings to create.The computer-readable medium encoded with program code can be encapsulated with compatible devices or provided by other devices individually (for example, downloading through the Internet).Any such computer-readable medium can reside on a single computer product or reside in a single computer product (for example, hard disk, CD or whole computer system), can be located at different computer products in a system or network or on different computer products in a system or network.Computer system can include monitor, printer or other suitable display for providing any result mentioned herein to the user.

[0326] Any method described herein can be performed in whole or in part with a computer system that can be configured to perform steps including one or more processors. Therefore, an embodiment can relate to a computer system that is configured to perform the steps of any method described herein, and may perform individual steps or groups of steps with different components. Although expressed as encoded steps, the steps of the method herein can be performed simultaneously or in different orders. In addition, a part in these steps can be used together with other steps from other methods. Equally, all or part of a step can be optional. In addition, any step of any method can be realized with module, unit, circuit or other means for performing these steps.

[0327] Without departing from the spirit and scope of the embodiments of the invention, the specific details of the specific embodiments may be combined in any suitable manner. However, other embodiments of the invention may be directed to specific embodiments with respect to each individual aspect, or specific combinations of these individual aspects.

[0328] The above description of exemplary embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the above teachings.

[0329] Unless expressly indicated to the contrary, the use of “a,” “an,” or “the” is intended to mean “one or more.” Unless expressly indicated to the contrary, the use of “or” is intended to mean an inclusive or rather than an exclusive or.

[0330] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A computer-implemented method using a first computing device, the method include: Determine a temporary key pair including a temporary public key and a temporary private key; Using the temporary private key and the static second device public key and using the Diffie-Hellman protocol to generate a first shared secret; encrypting the request data using the first shared secret to obtain encrypted request data; sending a request message including the encrypted request data and the temporary public key to a second computing device; receiving a response message from the second computing device including encrypted response data and a blinded static second device public key, wherein the blinded static second device public key is determined by blinding the static second device public key with a blinding factor; determining a second shared secret using the temporary private key and the blinded static second device public key; and The encrypted response data is decrypted using the second shared secret to determine the response data.

2. The computer-implemented method of claim 1, further comprising: include: Obtaining and storing the static second device public key; as well as Upon determining that the first computing device is to communicate with the second computing device, the static second device public key is retrieved.

3. The computer-implemented method of claim 2, wherein storing the static second device public key comprises storing the static second device public key in a secure element; and Wherein retrieving the static second device public key comprises retrieving the static second device public key from the secure element.

4. The computer-implemented method of claim 1, in, The request data includes identification data operable by the second computing device to identify the first computing device or user.

5. The computer-implemented method of claim 1, in, The temporary public key is a combined temporary public key, wherein the temporary private key is a combined temporary private key, and wherein the combined temporary public key and the combined temporary private key are determined using an identification factor generated using identification data and authentication data.

6. The computer-implemented method of claim 1, in, The temporary public key is a temporary first device public key, wherein the temporary private key is a temporary first device private key, wherein the request data includes a first device certificate, the first device certificate includes a static first device public key, wherein the response message also includes a temporary second device public key, and wherein the method further includes: An auxiliary shared secret is generated using the temporary second device public key and a static first device private key corresponding to the static first device public key, wherein decrypting the encrypted response data also uses the auxiliary shared secret.

7. The computer-implemented method of claim 1, in, The method further comprises: generating a next shared secret and a next blinded static second device public key using the second shared secret; and The next blinded static second device public key is associated with the next shared secret, wherein the next shared secret is used to decrypt subsequent encrypted response data received from the second computing device.

8. The computer-implemented method of claim 1, in, The response data comprises a second device certificate, the second device certificate comprising a static second device public key, wherein the response data further comprises a cryptographic random number, wherein the cryptographic random number is the blinding factor and the cryptographic random number is applied to the static second device public key to generate the blinded static second device public key by modifying the static second device public key, and wherein the method further comprises: verifying the second device certificate; generating a second device session identifier using the static second device public key and the cryptographic random number; and The second device session identifier is compared to the blinded static second device public key received from the second computing device, wherein if the second device session identifier matches the blinded static second device public key, the second computing device is authenticated.

9. The computer-implemented method of claim 1, in, The response data includes payment credentials, and wherein the method further comprises: A payment transaction is performed using the payment credentials.

10. A computer-implemented method, include: receiving, by the second computing device, from the first computing device, a request message including the encrypted request data and the temporary public key; generating, by the second computing device, a first shared secret using the temporary public key and a static second device private key; decrypting the encrypted request data using the first shared secret by the second computing device to obtain request data; generating, by the second computing device, a second shared secret using the blinded static second device private key and the temporary public key; encrypting, by the second computing device, the response data using the second shared secret to determine encrypted response data; as well as A response message including the encrypted response data and a blinded static second device public key is sent by the second computing device to the first computing device, wherein the blinded static second device public key is determined by blinding the static second device public key with a blinding factor.

11. The computer-implemented method of claim 10, further comprising: include: generating, by the second computing device, a cryptographic random number, wherein the cryptographic random number is the blinding factor; The blinded static second device public key is determined by the second computing device by: applying the cryptographic random number to the static second device public key, thereby generating the blinded static second device public key by modifying the static second device public key; as well as The blinded static second device private key is determined by the second computing device in the following manner: the cryptographic random number is applied to the static second device private key, thereby generating the blinded static second device private key by modifying the static second device private key.

12. The computer-implemented method of claim 10, in, The temporary public key is a combined temporary public key, wherein the request data includes an original temporary public key used to generate the combined temporary public key, wherein the request data also includes identification data, and wherein the computer-implemented method further includes: retrieving, by the second computing device, second authentication data from a device database using the identification data; generating, by the second computing device, a second identification factor using the second authentication data and the identification data; determining, by the second computing device, a second combined temporary public key using the second identification factor and the original temporary public key; and The combined temporary public key is compared to the second combined temporary public key by the second computing device, wherein if the combined temporary public key and the second combined temporary public key match, the first computing device is authenticated.

13. The computer-implemented method of claim 10, in, The temporary public key is a first device temporary public key, and wherein the computer-implemented method further comprises: determining, by the second computing device from the request data, a first device certificate associated with the first computing device, the first device certificate comprising a static first device public key; determining, by the second computing device, a temporary second device key pair comprising a temporary second device public key and a temporary second device private key; and An auxiliary shared secret is generated by the second computing device using the static first device public key and the temporary second device private key, wherein encrypting the response data also uses the auxiliary shared secret, and wherein the response message also includes the temporary second device public key.

14. The computer-implemented method of claim 10, in, The request data includes a first device identifier, and wherein the computer-implemented method further comprises: generating, by the second computing device, a next shared secret and a next blinded static second device public key using the second shared secret; and The first device identifier is associated with the next blinded static second device public key and the next shared secret by the second computing device, wherein the next shared secret is used to encrypt subsequent encrypted response data sent to the first computing device, and wherein the next blinded static second device public key is included in a subsequent response message sent to the first computing device.

15. The computer-implemented method of claim 10, in, The response data includes payment credentials, wherein the payment credentials are operable by the first computing device to perform a payment transaction.

16. A computer-implemented method using a first computing device, the method include: Determine a temporary key pair including a temporary public key and a temporary private key; generating a first shared secret using the temporary private key and the static second device public key; encrypting the request data using the first shared secret to obtain encrypted request data; sending a request message including the encrypted request data and the temporary public key to a second computing device; receiving a response message from the second computing device including encrypted response data and a blinded static second device public key, wherein the blinded static second device public key is determined by blinding the static second device public key with a blinding factor; retrieving a second shared secret from a registry or database, the second shared secret stored in association with the blinded static second device public key; and The encrypted response data is decrypted using the second shared secret to determine the response data.

17. The computer-implemented method of claim 16, further comprising: include: Before generating the first shared secret, generating the second shared secret and the blinded static second device public key using the previous shared secret; associating the blinded static second device public key with the second shared secret; and The blinded static second device public key is stored in the registry or database together with the second shared secret.

18. The computer-implemented method of claim 16, further comprising: include: generating a next shared secret and a next blinded static second device public key using the second shared secret; as well as The next blinded static second device public key is associated with the next shared secret, wherein the next shared secret is used to decrypt subsequent encrypted response data received from the second computing device.

19. The computer-implemented method of claim 18, further comprising: include: The next blinded static second device public key is stored in the registry or database along with the next shared secret.

20. The computer-implemented method of claim 16, further comprising: include: determining a second device session identifier based on the blinded static second device public key; as well as A determination is made as to whether the second device session identifier is registered, wherein the second device session identifier being registered indicates that the second shared secret is stored in the registry or database.

21. The computer-implemented method of claim 20, in, The second device session identifier is a subset of the blinded static second device public key.

22. The computer-implemented method of claim 20, in, Determining whether the second device session identifier is registered further comprises: The registry or database is searched for the second device session identifier.

23. A computer-readable storage medium comprising instructions stored thereon, which, when executed on one or more processors, perform the method of any one of claims 1-22.

24. A first computing device, configured to perform the method of any one of claims 1-9, 16-22.

25. A second computing device configured to perform the method of any one of claims 10-15.

Images