Conceptio › Archive › Google Patents

Google Patentsopen access

Secure communications providing forward secrecy — Visa International Service Association (US11108565B2)

Visa International Service Association · Google Patents

Google Patents · Patents · License: Open Access

ericlesaint visainternationalserviceassociation

patent, google patents, intellectual property, US11108565B2, Visa International Service Association, Eric Le Saint, en, 2021

ABSTRACT

Abstract

Embodiments of the invention can establish secure communications using a single non-traceable request message from a first computer and a single non-traceable response message from a second computer. Non-traceability may be provided through the use of blinding factors. The request and response messages can also include signatures that provide for non-repudiation. In addition, the encryption of the request and response message is not based on the static keys pairs, which are used for validation of the signatures. As such, perfect forward secrecy is maintained.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a divisional of U.S. application Ser. No. 15/629,689, filed on Jun. 21, 2017 and titled âSECURE COMMUNICATIONS PROVIDING FORWARD SECRECY,â which is incorporated by reference for all purposes in its entirety.

BACKGROUND

Ensuring that data is securely communicated between computers continues to be a concern. For instance, an attacker may intercept communications (e.g., by conducting a man-in-the-middle attack) and infer the identity a client computer or a server computer based on public keys or other data that are exchanged unencrypted. The intercepted data could be used to track the computers or used for illicit purposes. However, preventing the computer's identity from being tracked while still allowing the computer to authenticate itself can be problematic because the authentication can depend on the computer identifying itself. In addition, the encryption keys on the computers performing the communications may later become compromised, enabling an attacker to decrypt previously intercepted communications. Conducting secure, non-traceable, and authenticatable communications while ensuring the security of past communications can pose a challenge.

Embodiments of the present invention address these and other problems individually and collectively.

BRIEF SUMMARY

Embodiments of the invention relate to systems and methods for secure communications. Embodiments of the invention can establish secure communications using a single non-traceable request message from a first computer and a single non-traceable response message from a second computer. Non-traceability may be provided through the use of blinding factors. The request and response messages can also include signatures that provide for non-repudiation. In addition, the encryption of the request and response message is not based on the static keys pairs, which are used for validation of the signatures. As such, perfect forward secrecy is maintained.

Other embodiments are directed to systems, portable consumer devices, and computer readable media associated with methods described herein.

A better understanding of the nature and advantages of embodiments of the present invention may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a simplified message flow diagram illustrating secure communications between a client computer and a server computer, in accordance with some embodiments.

FIG. 2 shows a message flow diagram of a client computer and a server computer establishing secure communications using non-traceable messages, in accordance with some embodiments.

FIG. 3 shows a message flow diagram of a client computer securely obtaining a certificate from a server computer using non-traceable messages, in accordance with some embodiments.

FIG. 4 shows a message flow diagram of a client computer and a server computer establishing secure and non-traceable communications having perfect forward secrecy, in accordance with some embodiments.

FIG. 5 shows a message flow diagram of a client computer and a server computer establishing secure and non-traceable communications having perfect forward secrecy using messages having client and server non-repudiation, in accordance with some embodiments.

FIG. 6 shows a message flow diagram of a client computer and a server computer establishing secure and non-traceable communications using an encrypted signature portion and an unencrypted signature portion to provide non-repudiation, in accordance with some embodiments.

FIG. 7 shows a flowchart of a method for requesting and establishing secure communications, in accordance with some embodiments.

FIG. 8 shows a flowchart of a method for responding to a request to establish secure communications, in accordance with some embodiments.

FIG. 9 shows a table of steps in a computer-implemented method to establish secure and non-traceable communications having perfect forward secrecy, in accordance with some embodiments.

FIG. 10 shows a table of steps in a computer-implemented method to establish secure and non-traceable communications having perfect forward secrecy between a client computer and a sever computer such that the client computer and the server computer cannot repudiate their messages, in accordance with some embodiments.

FIG. 11 shows a table of steps for performing a computer-implemented method to establish secure and non-traceable communications having perfect forward secrecy and using an encrypted signature portion and an unencrypted signature portion, in accordance with some embodiments.

In the drawings, dotted or dashed lines may be used to indicate organizational structure, to indicate that an element is optional, or to indicate that data or information is passed through an element substantially unchanged. Arrows may be used to indicate the flow of data or information between two or more elements. Circles having reference numbers may indicate that certain steps are performed by an adjacent element.

Terms

Prior to discussing embodiments of the invention, description of some terms may be helpful in understanding embodiments.

The term âserver computerâ may include a computer or cluster of computing devices. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

The term âpublic/private key pairâ may include a pair of linked cryptographic keys generated by an entity (e.g., a computer or an electronic device). The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand may 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 body known as a Certification Authority (CA) which stores the public key in a database and distributes it to any other entity which requests it. The private key will typically be kept in a secure storage medium and will usually only be known to the entity. However, the cryptographic systems described herein may feature key recovery mechanisms for recovering lost keys and avoiding data loss. Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC).

A âdigital signatureâ may refer to the result of applying an algorithm based on a public/private key pair, which allows a signing party to manifest, and a verifying party to verify, the authenticity and integrity of a document. The signing party acts by means of the private key and the verifying party acts by means of the public key. This process certifies the authenticity of the sender, the integrity of the signed document and the so-called principle of nonrepudiation, which does not allow disowning what has been signed. A certificate or other data that includes a digital signature by a signing party is said to be âsignedâ by the signing party.

A âcertificateâ or âdigital certificateâ may include an electronic document or data file that uses a digital signature to bind a public key with data associated with an identity. The certificate may include one or more data fields, such as the legal name of the identity, a serial number of the certificate, a valid-from and valid-to date for the certificate, certificate-related permissions, etc. A certificate may contain a âvalid-fromâ date indicating the first date the certificate is valid, and a âvalid-toâ date indicating the last date the certificate is valid. A certificate may also contain a hash of the data in the certificate including the data fields. Unless otherwise noted, each certificate is signed by a certificate authority.

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

In a typical process, the 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 may then store the signed certificate in a database, and issue the signed certificate to the entity.

A âcryptographic nonceâ 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 nonce may be randomly or pseudo-randomly generated. Typically, a cryptographic nonce is of sufficient length as to make insignificant the likelihood of independently generating the same nonce value multiple times.

A âblinded key,â such as a âblinded public keyâ may include a key that has been obfuscated or otherwise modified from its original value by combination with another data element, such as a cryptographic nonce. For example, in elliptic curve cryptography, a public key may be multiplied by the nonce to generate a âblinded public key.â Similarly, a private key may be multiplied by the nonce to generate a âblinded private key.â The nonce may have the same bit-length as the public key and the private key.

An âephemeral key pairâ may include a public key (i.e., an âephemeral public keyâ) and a private key (i.e., an âephemeral private key) generated for use with a single transaction or other communication session. The ephemeral key pair may be of any suitable format, such as ECC or RSA. Typically, an ephemeral key pair may is deleted once the transaction or communication session has concluded.

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â) maintained over a period of time. Typically, though not necessarily, a static private key may be stored securely, such as in a hardware security module (HSM) or secure element (SE). Typically, though not necessarily, a static public key may be bound to an identity through the use of a digital certificate. The static key pair may be of any suitable format, such as ECC or RSA.

A âshared secretâ may include any data value or other information known only to authorized parties in a secure communication. A shared secret can be generated in any suitable manner, from any suitable data. 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. For example, a first computer may generate a first key pair include a first public key and a first private key. A second computer may generate a second key pair including a second public key and a second private key. The first computer may generate a shared secret using the second public key of the second computer and the first private key of the first computer. The second computer may generate the same shared secret using the first public key of the first computer and the second private key of the second computer. The first computer and the second computer may both use the shared secret to generate a session key.

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

The term âauthenticationâ generally refers to a process of establishing confidence in the identity of a user or a computer. Authentication may be performed by confirming the identity of a device using public key cryptography (e.g., encrypted data or digital signatures) for authentication information.

The term âauthentication dataâ or âauthentication informationâ may include any data or information suitable to authenticate a user or device. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), a digital signature, an indication that the device is storing certain information, etc.

An âencryption keyâ may include any data value or other information suitable to cryptographically encrypt data. A âdecryption keyâ may include any data value or other information suitable to decrypt encrypted data. In some cases, the same key used to encrypt data may be operable to decrypt the data. Such a key may be known as a symmetric encryption key.

A âsession keyâ may include any key used to encrypt or decrypt data to be securely communicated. In some cases, a session key may be generated from a shared secret known both to a sending entity and a receiving entity. For example, the session key may be derived using a key derivation function and the shared secret.

âNon-traceabilityâ is a characteristic of secure communications that refers to the ability of a communication message to not disclose information about the identity of the sender such that the message can be traced back to them. For example, in some secure communications, the static public key of a first computer is sent to a second computer in the clear (e.g., not encrypted) during a DiffieHellman key exchange. The first computer's public key may be static because it corresponds to a certificate stored thereon that is signed by a certificate authority. As such, the first computer may be identified and tracked by intercepting its communications based on an unencrypted public key sent during the Diffie Hellman key exchange. In another scenario, a signature may be sent unencrypted and a third party may intercept the signature and attempt to validate the signature using a plurality of different public keys to identify and trace the signer of the signature. To prevent tracking, a computer can generate an ephemeral key pair to be used during a key exchange and then deleted after a shared secret is established. Another way to prevent tracking would be to âblindâ the public key using a cryptographic nonce (e.g., a randomly generated number).

CROSS-REFERENCES TO RELATED APPLICATIONS

BACKGROUND

Embodiments of the present invention address these and other problems individually and collectively.

BRIEF SUMMARY

Other embodiments are directed to systems, portable consumer devices, and computer readable media associated with methods described herein.

A better understanding of the nature and advantages of embodiments of the present invention may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a simplified message flow diagram illustrating secure communications between a client computer and a server computer, in accordance with some embodiments.

FIG. 2 shows a message flow diagram of a client computer and a server computer establishing secure communications using non-traceable messages, in accordance with some embodiments.

FIG. 3 shows a message flow diagram of a client computer securely obtaining a certificate from a server computer using non-traceable messages, in accordance with some embodiments.

FIG. 7 shows a flowchart of a method for requesting and establishing secure communications, in accordance with some embodiments.

FIG. 8 shows a flowchart of a method for responding to a request to establish secure communications, in accordance with some embodiments.

FIG. 9 shows a table of steps in a computer-implemented method to establish secure and non-traceable communications having perfect forward secrecy, in accordance with some embodiments.

Terms

Prior to discussing embodiments of the invention, description of some terms may be helpful in understanding embodiments.

âNon-repudiationâ is a characteristic of secure communications that refers to the ability of a communication message that prevents the sender of the message from denying that they sent that message. A secure communication protocol that provides ânon-repudiationâ may prevent a computer from denying that a message was sent by them using public key cryptography. In addition, ânon-repudiationâ provides for âauthenticationâ of the sender since the receiver can authenticate that only the sender could have sent the message. In one example, an encrypted message may include a signature created using the static private key of a first computer. The static private key may correspond to a static public key which is included in a certificate of the first computer that is signed by a certificate authority. In this example, the private key is only known by the first computer and it would be computationally impractical for another computer to determine this private key due to the characteristics of public key cryptography. Accordingly, the first computer may not repudiate the first message if its public key can validate the signature since no other device may have access to its private key to create the signature. In contrast to a signature, encryption of a message alone may not provide non-repudiation of that message since there may not be a provable method for verifying which device generated that message.

âForward secrecyâ is a characteristic of secure communications that refers to the ability of the messages to not be decrypted if the private keys of the sender and/or the receiver of the messages are later compromised. âPerfect forward secrecyâ is a characteristic of secure communications that refers to the ability of the messages to not be decrypted if the private keys of both the sender and the receiver of the messages are later compromised. In one scenario, the private keys may be obtained by a third party that gains physical access to the computers. In another scenario, a third computer can spend a long enough time to crack the private key, which would be impractical but not impossible. However, secure communications having âperfect forward secrecyâ cannot be decrypted even if the static private keys of the sending and receiving computers are both compromised. One way to achieve âperfect forward secrecyâ is by not encrypting the messages using static private keys. Accordingly, if the static private keys are compromised, they cannot be used to decrypt the messages. In one example, an encryption key pair can be randomly generated for the key exchange and then deleted (e.g., zeroized) shortly thereafter. Accordingly, the private key cannot be obtained if a third party later gains physical access to the computer. Therefore, communications sent in the past maintain their secrecy going forward. Furthermore, even if one message is compromised, the other messages are not compromised because there is no single key used for encryption across different messages.

DETAILED DESCRIPTION

Secure communication methods and systems are described herein. In one embodiment, a first computer and a second computer may communicate over an unsecured network (e.g., the Internet). In order to exchange secure communications, the first computer and the second computer may share a secret symmetric key used to encrypt communications. To prevent a third party from obtaining the secret symmetric key, the two computers can exchange public keys and then separately generate the same secret symmetric key using their own private key and the public key received from the other device. However, if static public keys are sent over the network unencrypted, this may allow a third party to determine the identity of one of the computers or to eventually determine the shared symmetric key.

It is possible to use ephemeral key pairs or blinded public keys to provide non-traceability. However, since the identity of the sender is hidden to provide non-traceability, one consequence may be that the sender can deny having sent the message themselves. In order to prevent the sender from repudiating messages that they sent, the message can include a signature that is created using the static public key of the sender. As such, non-traceable keys may be used for encryption while traceable keys may be used to generate the signature. In addition, new and different public keys may be used in each key exchange and deleted immediately or shortly after establishing a shared secret. In addition, while traceable signatures may be used, they may be included in the encrypted portion of the message such that they cannot be used to trace the sender or the receiver of the message. Accordingly, secure communications having ânon-traceability,â ânon-repudiationâ, and âperfect forward secrecyâ can be established. Methods and systems for establishing such communications are described in further detail below.

I. Securing Communications Using Encryption Keys

A Diffie-Hellman key exchange may enable a first computer and a second computer to establish a secret symmetric key over an unsecured network without transmitting the secret symmetric key itself. The Diffie-Hellman key exchange may not be based on any information previous stored at the first or second computer before the key exchange. 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 of a first computer and a public key of a second computer. For example, the first computer may generate a first key pair include a first public key and a first private key. The second computer may generate a second key pair including a second public key and a second private key. The first computer may send its first public key to the second computer and the second computer may send its second public key to the first computer. The first computer may generate a shared secret using the second public key of the second computer and the first private key of the first computer. The second computer may generate the same shared secret using the first public key of the first computer and the second private key of the second computer. The first computer and the second computer may both use the shared secret to generate a session key for encrypting communications. As such, the first computer and the second computer may establish secure communications over an unsecured network without using any pre-installed information.

FIG. 1 shows a simplified message flow diagram 100 illustrating secure communications between a client computer 140 and a server computer 180 , in accordance with some embodiments. The message flow diagram 100 may be used between any first computer and any second computer. The client/server distinction used herein is merely exemplary and made to improve readability. In some embodiments, the client computer 140 may perform the operations described as being performed by the server computer 180 . In some embodiments, the server computer 180 may perform the operations described as being performed by the client computer 140 .

Referring to FIG. 1 , the client computer 140 may store a client key pair comprising a client public key and a client private key corresponding to the client public key. The client key pair may be static. The server computer 180 may store a server key pair comprising a server public key and a server private key corresponding to the server public key. The server key pair may be static. The client computer 140 and the server computer 180 may communicate over an unsecured network 160 (e.g., the internet or a wireless local area network). The unsecured network 160 may be âunsecuredâ in that the communication medium itself is not physically secured or it may be âunsecuredâ in that communications do not travel directed between two parties but also through other third parties in the network.

The client computer 140 and the server computer 180 may perform a key exchange in order to establish secure communications over the unsecured network 160 . For example, the client computer 140 and the server computer 180 may perform a Diffie-Hellman key exchange as described above to establish a shared secret between the client computer 140 and the server computer 180 . The client computer 140 and the server computer 180 may each derive a session key from the shared secret for encrypting and decrypting communications between each other.

At 101 , the client computer 140 can transmit a request message to the server computer 180 to initiate the establishment of secure communication. In some embodiments, the request message may include identification data. The client computer 140 may encrypt the identification data of the response message using the shared secret to obtain encrypted identification data. The client computer 140 may transmit the request message including the encrypted identification data to the server computer 180 over the unsecured network 160 .

The server computer 180 can receive the request message from the client computer 140 via the unsecured network 160 . The server computer 180 can decrypt the encrypted identification data of the request message using the shared secret (e.g., using the session key derived from the shared secret). The server computer 180 may also verify the identification data based on data stored at the server computer 180 . The server computer 180 may then encrypt payload data for the client computer 140 using the shared secret to obtain encrypted payload data. In some embodiments, the server computer 180 can generate a second shared secret to use for encrypting the server computer's payload data.

At 102 , the server computer 180 can transmit a response message including the encrypted payload data to client computer 140 . The server computer 180 may transmit the response data to the client computer 140 in response to verifying the identification data received from the client computer 140 . The client computer 140 can receive the response message and decrypt the encrypted payload data using the session key to obtain the payload data from the server computer 180 . As such, the client computer 140 and the server computer 180 can establish secure communications over the unsecured network 160 by performing a Diffie-Hellman key exchange.

However, the key exchange described above with respect to FIG. 1 , may involve a first computer (e.g., the client computer 140 ) sending its first public key to a second computer (e.g., the server computer 180 ) and the second computer sending its second public key to the first computer. As such, an eavesdropping computer can intercept the messages to track the identity of the first computer based on the first public key and to track the identity of the second computer based on the second public key. In addition, the eavesdropping computer may conduct a man-in-the-middle attack or imitate the first computer or the second computer. Some of the embodiments described below address these issues.

II. Secure and Non-Traceable Communications

As discussed above, a public key exchange (e.g., a DiffieHellman key exchange) can include sending static public keys in the clear (e.g., unencrypted). If there is no other means for secure communications between two computers, then the public keys cannot be encrypted themselves. However, it is possible for a third party computer to intercept the communications (e.g., because they are sent over an unsecured network such as the Internet) and identify the two computers based on their static public keys. This can enable the third party to trace the computers.

A. Method for Establishing Secure and Non-Traceable Communications

Traceability of messages is a problem because it can enable a third party computer to track certain computers, thereby violating the confidentiality of the communications and the privacy of the computer and its users. To solve the traceability problem, a client computer can generate an ephemeral key pair that is different from its static key pair and use the ephemeral public key in the key exchange. The client computer can delete this ephemeral key pair after a shared secret has been established and generate new ephemeral key pairs in establishing subsequent secure communication channels. As such, exchanging an ephemeral public key in the clear does not enable an intercepting third party to track the client computer since that particular ephemeral public key is only used by the client in that single communication session.

FIG. 2 shows a message flow diagram 200 of a client computer 240 and a server computer 280 establishing secure communications using non-traceable messages, in accordance with some embodiments. Prior to the message flow of FIG. 2 , the client computer 240 can store a client payload 252 and a server certificate 288 of the server computer 280 . The client computer 240 may obtain the server computer's certificate 288 using the message flow described below with respect to FIG. 3 , for example.

The server computer 280 can store a server static key pair 286 including a server static private key 282 and a server static public key 284 . The server computer 280 can also store the server certificate 288 . The server certificate 288 may include the server static public key 284 and a signature of a certificate authority for authentication of the server computer 288 . The server static private key 282 and a server static public key 284 may be âstaticâ in that they do not change over time, enabling the server computer 288 to be authenticated using the server certificate 288 . The server computer 280 can also store server payload data 292 . The server payload data 292 may be treated as sensitive data such that it is not transmitted in the clear without being encrypted.

In this message flow, the client computer 240 can initiate the establishment of secure communications. At 201 , the client computer 240 can generate a client ephemeral private key. The client ephemeral private key may be randomly generated.

At 202 , the client computer 240 can determine a client ephemeral public key using the client ephemeral private key. The client ephemeral private key and the client ephemeral public key can form a key pair for use in public key cryptography.

At 203 , the client computer 240 can determine a first shared secret using the client ephemeral private key and the server static public key 284 , which can be included in the server certificate 288 . The client computer 240 may determine a first session key using a key derivation function based on the shared secret, an identifier of the server computer 280 , and an identifier of the communication session.

At 204 , the client computer 240 can encrypt the client payload 252 using the first shared secret (e.g., using the first session key) to determine client encrypted data. The client payload 252 may include sensitive client data and/or a request for certain data or information from the server computer 280 . After encrypting the client payload 252 , the client computer 240 can zeroize (e.g., completely delete to prevent any recovery) the first shared secret and the first session key.

At 205 , the client computer 240 can transmit a ârequest messageâ including the client ephemeral public key and the client encrypted data to the server computer 280 . The client ephemeral public key can be sent in the clear (e.g., unencrypted). The request message can indicate that the client computer 240 requests to establish secure communications using a shared secret based on the client blinded public key. The request message may be transmitted over an unsecured network. The server computer 280 can receive the request message from the client computer 240 . Since the client ephemeral public key is only used for this communication session (the client ephemeral private key is zeroized at 214 ), then it cannot be used to track the client computer 240 . As such, the request message sent at 205 is non-traceable.

At 206 , the server computer 280 can determine the first shared secret using the server static private key 282 and the client blinded public key. The first shared secret determined by the server computer at 206 using the server static private key 282 and the client blinded public key can be the same as the first shared secret generated by the client computer 240 at 203 using the client ephemeral private key and the server static public key 284 . The server computer 280 may also may determine the same first session key determined by the client computer 240 using a key derivation function based on the shared secret, an identifier of the server computer 280 , and an identifier of the communication session.

At 207 , the server computer 280 can decrypt the client encrypted data using the first shared secret (e.g., using the first session key) to obtain the client payload 252 . After decrypting the client payload 252 , the server computer 280 can zeroize (e.g., completely delete to prevent any recovery) the first shared secret and the first session key. At this point, the server computer 280 may process the client payload 252 and generate or identify any appropriate data or information to include in the server payload 292 to be provided in response to the client computer's request.

At 208 , the server computer 280 can generate a server blinding factor. The server blinding factor can be a randomly generated cryptographic nonce. The server computer 280 can use the server blinding factor to prevent third parties from tracking it as described below. For example, the server computer 280 can apply the server blinding factor to the server static public key 284 (e.g., using multiplication) to determine a server blinded public key. The server computer 280 may only this server blinding factor and this server blinded public key in this particular communication session with the client computer 240 and may generate a different blinding factor for subsequent communications sessions. As such, the server computer 280 may not be tracked by third parties based on the server blinded public key.

At 209 , the server computer 280 can determine a second shared secret using the server blinding factor, the server static private key 282 , and the client ephemeral public key. The server computer 280 may also determine a second session key using a key derivation function and the second shared secret.

At 210 , the server computer 280 can determine the server blinded public key using the server blinding factor and the server static public key. For example, the server computer 280 can apply the server blinding factor to the server static public key 284 (e.g., using multiplication) to determine the server blinded public key.

At 211 , the server computer 280 can encrypt the server blinding factor, the server certificate 288 , and the server payload data 292 using the second shared secret (e.g., using the second session key) to obtain encrypted server data.

At 212 , the server computer 280 can transmit a response message including the server blinded public key and the server encrypted data to the client computer 240 . The response message may be sent over an unsecured network. The server blinded public key can be sent in the clear (e.g., unencrypted). However, the server blinded public key is based on the server blinding factor which may only be used in this particular communication session. Accordingly, the server computer 280 may not be tracked by a third party intercepting this message and other messages sent by the server computer 280 . The client computer 240 can receive the response message.

At 213 the client computer 240 can determine the second shared secret using the client ephemeral private key and the server blinded public key. The second shared secret determined by the client computer 240 at 213 may be the same as the second shared secret determined by the server computer 280 at 209 using the client ephemeral public key, the server blinding factor, and the server static private key 284 . The client computer 240 may also determine the same second session key (as also determined by the server computer 280 ) using a key derivation function and the second shared secret.

At 214 , after determining the second shared secret and the second session key, the client computer 240 can zeroize the client ephemeral private key. That is, the client computer 240 can delete the client ephemeral private key such that it cannot be recovered later. Furthermore, even if the client ephemeral private key were compromised and obtained by a third party in the short period of time prior to it being zeroized, the third party would not be able to decrypt any other communications using the client ephemeral private key since this client ephemeral private key was only used to decrypt this particular response message.

At 215 , the client computer 240 can decrypt the encrypted server data using the second shared secret (e.g., using the second session key) to obtain the server blinding factor, the server certificate 288 , and the <figure-callout id="292" label="server payload" filenames="U

CLAIMS

Claims ( 20 )

What is claimed is:

1. A computer-implemented method for performing communications between a first computer and a second computer, the method comprising:

storing, by the first computer, a first static private key of the first computer, a first static public key of the first computer corresponding to the first static private key, and a second static public key of the second computer;

generating, by the first computer, a first blinding factor;

determining, by the first computer, a first blinded public key using the first blinding factor;

generating, by the first computer, a first-computer signature by signing the first blinded public key using the first static private key;

determining, by the first computer, a first shared secret using the first blinding factor and the second static public key;

encrypting, by the first computer using the first shared secret, first-computer data including the first static public key and the first-computer signature to obtain encrypted first-computer data; and

sending, by the first computer to the second computer, a first message including the first blinded public key and the encrypted first-computer data.

2. The method of claim 1 , wherein the first blinding factor is generated using a pseudo-random number generator.

3. The method of claim 1 , wherein the first blinded public key is determined from the first blinding factor using an elliptic curve public key algorithm.

4. The method of claim 1 , wherein the first-computer data further includes a first-computer certificate, the first-computer certificate including the first static public key.

5. The method of claim 1 , further comprising:

receiving, by the first computer, a second message from the second computer including a second blinded public key of the second computer and encrypted second-computer data;

determining, by the first computer, a second shared secret using the first blinding factor and the second blinded public key; and

decrypting, by the first computer, the encrypted second-computer data using the second shared secret.

6. The method of claim 5 , wherein the second computer determines the first shared secret using the first blinded public key and a second static private key of the second computer corresponding to the second static public key, decrypts the encrypted first-computer data using the first shared secret, validates the first-computer signature using the first static public key, and sends the second message to the first computer including the second blinded public key of the second computer and the encrypted second-computer data.

7. The method of claim 5 , wherein the encrypted second-computer data includes a second-computer signature, the method further comprising:

validating, by the first computer, the second-computer signature of the second computer using the second static public key.

8. The method of claim 5 , further comprising:

validating the second blinded public key using the second static public key and a second computer blinding factor, wherein the encrypted second-computer data includes the second computer blinding factor.

9. A computer-implemented method for performing communications between a first computer and second computer, the method comprising:

storing, by the second computer, a second static private key of the second computer, and a second static public key of the second computer corresponding to the second static private key;

receiving, from the first computer by the second computer, a first message including a first blinded public key of the first computer and encrypted first-computer data of the first computer;

determining, by the second computer, a first shared secret using the first blinded public key and the second static private key;

decrypting, by the second computer using the first shared secret, the encrypted first-computer data to obtain first-computer data, the first-computer data including a first static public key and a first-computer signature of the first computer, wherein the first-computer signature is generated by the first computer signing the first blinded public key using a first static private key of the first computer, the first static private key corresponding to the first static public key; and

validating, by the second computer, the first-computer signature using the first static public key of the first computer and the first blinded public key.

10. The method of claim 9 , further comprising:

generating, by the second computer, a second blinding factor;

determining, by the second computer, a second blinded public key of the second computer using the second blinding factor and the second static public key;

determining, by the second computer, a second shared secret using the first blinded public key, the second blinding factor, and the second static private key;

encrypting, by the second computer using the second shared secret, second-computer data including the second static public key and the second blinding factor to obtain encrypted second-computer data; and

sending, by the second computer to the first computer, a second message including the second blinded public key and the encrypted second-computer data.

11. The method of claim 9 , further comprising:

generating, by the second computer, a second blinding factor;

determining, by the second computer, a second blinded public key of the second computer using the second blinding factor and the second static public key;

determining, by the second computer, a second shared secret using the first blinded public key, the second blinding factor, and the second static private key;

generating, by the second computer, a second-computer signature by signing the second blinded public key using the second static private key;

encrypting, by the second computer using the second shared secret, second-computer data including the second static public key and the second-computer signature to obtain encrypted second-computer data; and

sending, by the second computer to the first computer, a second message including the second blinded public key and the encrypted second-computer data.

12. The method of claim 11 , wherein the second blinding factor is generated using a pseudo-random number generator.

13. The method of claim 11 , wherein the second blinded public key is determined from the second blinding factor using an elliptic curve public key algorithm.

14. A computer system, comprising:

one or more processor circuits; and

a system memory coupled to the one or more processor circuits and storing computer-readable code that, when executed by the one or more processor circuits, performs operations including:

storing a first static private key, a first static public key corresponding to the first static private key, and a second static public key of a second computer;

generating a first blinding factor;

determining a first blinded public key using the first blinding factor;

generating a first-computer signature by signing the first blinded public key using the first static private key;

determining a first shared secret using the first blinding factor and the second static public key;

encrypting, using the first shared secret, data including the first static public key and the first-computer signature to obtain encrypted data; and

sending, to the second computer, a first message including the first blinded public key and the encrypted data.

15. The computer system of claim 14 , wherein the first blinding factor is generated using a pseudo-random number generator.

16. The computer system of claim 14 , wherein the first blinded public key is determined from the first blinding factor using an elliptic curve public key algorithm.

17. The computer system of claim 14 , wherein the data further includes a certificate, the certificate including the first static public key.

18. The computer system of claim 14 , wherein the operations further include:

receiving a second message from the second computer including a second blinded public key of the second computer and encrypted second-computer data;

determining a second shared secret using the first blinding factor and the second blinded public key; and

decrypting the encrypted second-computer data using the second shared secret.

19. The computer system of claim 18 , wherein the encrypted second-computer data includes a second-computer signature, wherein the operations further include:

validating the second-computer signature of the second computer using the second static public key.

20. The computer system of claim 18 , wherein the operations further include:

US16/385,859

2017-06-21

2019-04-16

Secure communications providing forward secrecy

Active

2038-04-14

US11108565B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US16/385,859

US11108565B2

( en )

2017-06-21

2019-04-16

Secure communications providing forward secrecy

Applications Claiming Priority (2)

Application Number

Priority Date

Filing Date

Title

US15/629,689

US10313133B2

( en )

2017-06-21

Secure communications providing forward secrecy

US16/385,859

US11108565B2

( en )

2017-06-21

2019-04-16

Secure communications providing forward secrecy

Related Parent Applications (1)

Application Number

Title

Priority Date

Filing Date

US15/629,689

Division

US10313133B2

( en )

2017-06-21

Secure communications providing forward secrecy

Publications (2)

Publication Number

Publication Date

US20190245695A1

US20190245695A1 ( en )

2019-08-08

US11108565B2

true

US11108565B2 ( en )

2021-08-31

Family

ID=64692838

Family Applications (2)

Application Number

Title

Priority Date

Filing Date

US15/629,689

Active

2037-08-24

US10313133B2

( en )

2017-06-21

Secure communications providing forward secrecy

US16/385,859

Active

2038-04-14

US11108565B2

( en )

2017-06-21

2019-04-16

Secure communications providing forward secrecy

Family Applications Before (1)

Application Number

Title

Priority Date

Filing Date

US15/629,689

Active

2037-08-24

US10313133B2

( en )

2017-06-21

Secure communications providing forward secrecy

Country Status (4)

Country

Link

( 2 )

US10313133B2

( en )

( 1 )

EP3642997B1

( en )

( 1 )

CN110771089A

( en )

( 1 )

WO2018236908A1

( en )

Cited By (3)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US11349659B2

( en )

2017-08-29

2022-05-31

Amazon Technologies, Inc.

Transmitting an encrypted communication to a user in a second secure communication network

US11368442B2

( en )

2017-08-29

2022-06-21

Amazon Technologies, Inc.

Receiving an encrypted communication from a user in a second secure communication network

US11457018B1

( en )

2017-08-29

2022-09-27

Amazon Technologies, Inc.

Federated messaging

Families Citing this family (43)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US9258117B1

( en )

2014-06-26

2016-02-09

Amazon Technologies, Inc.

Mutual authentication with symmetric secrets and signatures

AU2018295722B2

( en )

2017-07-05

2020-11-19

Ntt, Inc.

Secure computation system, secure computation apparatus, secure computation method, program, and recording medium

US10791196B2

( en )

2017-08-29

2020-09-29

Wickr Inc.

Directory lookup for federated messaging with a user from a different secure communication network

US11146397B2

( en )

2017-10-31

2021-10-12

Micro Focus Llc

Encoding abelian variety-based ciphertext with metadata

US10693892B2

( en )

2017-12-11

2020-06-23

International Business Machines Corporation

Network attack tainting and tracking

US10841080B2

( en )

2018-03-20

2020-11-17

International Business Machines Corporation

Oblivious pseudorandom function in a key management system

US10887088B2

( en )

2018-03-20

2021-01-05

International Business Machines Corporation

Virtualizing a key hierarchy using a partially-oblivious pseudorandom function (P-OPRF)

US10887293B2

( en )

2018-03-20

2021-01-05

International Business Machines Corporation

Key identifiers in an obliviousness pseudorandom function (OPRF)-based key management service (KMS)

US11115206B2

( en )

2018-08-23

2021-09-07

International Business Machines Corporation

Assymetric structured key recovering using oblivious pseudorandom function

US10924267B2

( en )

2018-08-24

2021-02-16

International Business Machines Corporation

Validating keys derived from an oblivious pseudorandom function

US10666431B1

( en )

2019-03-11

2020-05-26

Capital One Services, Llc

Systems and methods for enhancing web security

US11632235B2

( en )

2019-04-09

2023-04-18

Samsung Electronics Co., Ltd.

Method and apparatus for handling security procedure in mc communication system

US11336462B1

( en )

2019-09-10

2022-05-17

Wells Fargo Bank, N.A.

Systems and methods for post-quantum cryptography optimization

US11206135B2

( en )

2019-11-11

2021-12-21

International Business Machines Corporation

Forward secrecy in Transport Layer Security (TLS) using ephemeral keys

US11334667B1

( en )

2020-01-17

2022-05-17

Wells Fargo Bank, N.A.

Systems and methods for disparate quantum computing threat detection

WO2021222662A1

( en )

2020-04-30

2021-11-04

Sensata Technologies, Inc.

Secure wireless protocol for wireless sensor networks

DE102020112102B3

( en )

2020-05-05

2021-05-20

Infineon Technologies Ag

Method and apparatus for generating a symmetrical session key for encrypted communication

US12506599B2

( en )

2020-05-21

2025-12-23

Marvell Asia Pte, LTD

Methods and systems for secure network communication

IL275954A

( en )

2020-07-09

2022-02-01

Google Llc

Anonymous event attestation with group signatures

IL275947A

( en )

2020-07-09

2022-02-01

Google Llc

Anonymous event attestation

CN112039848B

( en )

2020-08-05

2022-11-04

åäº¬é¾é£æªæ¥ç§ææéå¬å¸

Web authentication method, system and device based on block chain public key digital signature

CN112753203B

( en )

2020-10-30

2022-07-12

åä¸ºææ¯æéå¬å¸

Secure communication method and device

US11258617B1

( en )

2020-12-04

2022-02-22

Salesforce.Com, Inc.

Device identity using key agreement

CN114760046A

( en )

2020-12-26

2022-07-15

è¥¿å®è¥¿çµæ·éæ çº¿ç½ç»éä¿¡è¡ä»½æéå¬å¸

Identity authentication method and device

CN114696999A

( en )

2020-12-26

2022-07-01

è¥¿å®è¥¿çµæ·éæ çº¿ç½ç»éä¿¡è¡ä»½æéå¬å¸

Identity authentication method and device

CN114760039A

( en )

2020-12-26

2022-07-15

è¥¿å®è¥¿çµæ·éæ çº¿ç½ç»éä¿¡è¡ä»½æéå¬å¸

Identity authentication method and device

US12225130B2

( en )

2022-01-14

2025-02-11

Micron Technology, Inc.

Embedded TLS protocol for lightweight devices

WO2023146857A1

( en )

2022-01-25

2023-08-03

Everything Blockchain Technology Corp.

Enhanced secure cryptographic communication system

US12058251B2

( en )

2022-02-10

2024-08-06

Micron Technology, Inc.

Simulation-based testing of a key management server

US11811752B1

( en )

2022-08-03

2023-11-07

1080 Network, Inc.

Systems, methods, and computing platforms for executing credential-less network-based communication exchanges

US20240113865A1

( en )

2022-09-23

2024-04-04

Assa Abloy Ab

Non-repudiation-free public key authentication protocols

US20240106634A1

( en )

2022-09-23

2024-03-28

Assa Abloy Ab

Privacy-strengthened public key authentication protocols

US12567982B2

( en )

2022-10-14

2026-03-03

Assa Abloy Ab

Remote access via system-level trusted authorities

WO2024114880A1

( en )

2022-11-28

2024-06-06

Assa Abloy Ab

Systems and methods for conducting secure mutual authentication with asymmetric keys

US12500765B2

( en )

2023-02-14

2025-12-16

Lenovo (Singapore) Pte. Ltd

Method of providing a secure electronic device

US12567966B2

( en )

2023-06-30

2026-03-03

Scatr Corp

Endpoint validation security

US12432042B2

( en )

2023-06-30

2025-09-30

Scatr, Corp

Network traffic obfuscation

US12335160B2

( en )

2023-06-30

2025-06-17

Scatr Llc

Secure data routing with dynamic packet spoofing

US12519631B2

( en )

2023-06-30

2026-01-06

Scatr Corp

Out of band key exchange

US12519755B2

( en )

2023-07-28

2026-01-06

Scatr Corp

Secure data routing and randomization in windows

US20250097018A1

( en )

2023-09-19

2025-03-20

Apple Inc.

Secure Key Exchange

US12615284B2

( en )

2024-01-24

2026-04-28

Scatr, Corp

Optimizing network traffic obfuscation based on aggregated network performance

DE102024201665A1

( en )

2024-02-22

2025-08-28

Robert Bosch Gesellschaft mit beschrÃ¤nkter Haftung

Method and apparatus for processing data associated with a communication system

Citations (12)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US6446207B1

( en )

1997-01-31

2002-09-03

Certicom Corporation

Verification protocol

US20110022834A1

( en )

2009-07-21

2011-01-27

Cellco Partnership D/B/A Verizon Wireless

Systems and methods for shared secret data generation

US20130212391A1

( en )

2012-02-09

2013-08-15

Liqun Chen

Elliptic curve cryptographic signature

US20150200774A1

( en )

2014-01-13

2015-07-16

Eric Le Saint

Efficient methods for protecting identity in authenticated transmissions

US20150350197A1

( en )

2014-05-27

2015-12-03

Panasonic Intellectual Property Management Co., Ltd.

Signature verification system, communication device, verification device, signature generation method, and signature verfication method

US20150372811A1

( en )

2014-06-18

2015-12-24

Eric Le Saint

Efficient methods for authenticated communication

US20160065370A1

( en )

2014-08-29

2016-03-03

Eric Le Saint

Methods for secure cryptogram generation

US20160218875A1

( en )

2015-01-27

2016-07-28

Eric Le Saint

Methods for secure credential provisioning

WO2017004470A1

( en )

2015-06-30

2017-01-05

Visa International Service Association

Mutual authentication of confidential communication

US20170019380A1

( en )

2014-10-06

2017-01-19

Micron Technology, Inc.

Secure shared key sharing systems and methods

WO2017106793A1

( en )

2015-12-16

2017-06-22

Visa International Service Association

Systems and methods for secure multi-party communications using a proxy

US9942034B2

( en )

2015-02-13

2018-04-10

Visa International Service Association

Confidential communication management

2017

2017-06-21

US15/629,689

patent/US10313133B2/en

active

Active

2018

2018-06-19

PCT/US2018/038339

patent/WO2018236908A1/en

not_active

Ceased

2018-06-19

CN201880041699.2A

patent/CN110771089A/en

active

Pending

2018-06-19

EP18821451.4A

patent/EP3642997B1/en

active

Active

2019

2019-04-16

US16/385,859

patent/US11108565B2/en

active

Active

Patent Citations (17)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US6446207B1

( en )

1997-01-31

2002-09-03

Certicom Corporation

Verification protocol

US20110022834A1

( en )

2009-07-21

2011-01-27

Cellco Partnership D/B/A Verizon Wireless

Systems and methods for shared secret data generation

US20130212391A1

( en )

2012-02-09

2013-08-15

Liqun Chen

Elliptic curve cryptographic signature

US20150200774A1

( en )

2014-01-13

2015-07-16

Eric Le Saint

Efficient methods for protecting identity in authenticated transmissions

US9647832B2

( en )

2014-01-13

2017-05-09

Visa International Service Association

Efficient methods for protecting identity in authenticated transmissions

US20150350197A1

( en )

2014-05-27

2015-12-03

Panasonic Intellectual Property Management Co., Ltd.

Signature verification system, communication device, verification device, signature generation method, and signature verfication method

US20150372811A1

( en )

2014-06-18

2015-12-24

Eric Le Saint

Efficient methods for authenticated communication

US20160065370A1

( en )

2014-08-29

2016-03-03

Eric Le Saint

Methods for secure cryptogram generation

US9813245B2

( en )

2014-08-29

2017-11-07

Visa International Service Association

Methods for secure cryptogram generation

US20170019380A1

( en )

2014-10-06

2017-01-19

Micron Technology, Inc.

Secure shared key sharing systems and methods

US20160218875A1

( en )

2015-01-27

2016-07-28

Eric Le Saint

Methods for secure credential provisioning

US20190173672A1

( en )

2015-02-13

2019-06-06

Eric Le Saint

Confidential communication management

US9942034B2

( en )

2015-02-13

2018-04-10

Visa International Service Association

Confidential communication management

US10218502B2

( en )

2015-02-13

2019-02-26

Visa International Service Association

Confidential communication management

WO2017004470A1

( en )

2015-06-30

2017-01-05

Visa International Service Association

Mutual authentication of confidential communication

WO2017004466A1

( en )

2015-06-30

2017-01-05

Visa International Service Association

Confidential authentication and provisioning

WO2017106793A1

( en )

2015-12-16

2017-06-22

Visa International Service Association

Systems and methods for secure multi-party communications using a proxy

Non-Patent Citations (3)

* Cited by examiner, â Cited by third party

Title

European Application No. 18821451.4, European Search Report dated dated Apr. 28, 2020, 9 pages.

Garrett and Ward, " Blinded Diffie_Hellman " Preventing Eavesdroppers from Trackinmg Payments, EMVCo Security Working Group, www.emvco.com, Springer International Publishing Switzerland, Dec. 16, 2014, pp. 79-92 (14 pages).

PCT/US2018/038339 , " International Search Report and Written Opinion ", dated Sep. 28, 2018, 13 pages.

Cited By (3)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US11349659B2

( en )

2017-08-29

2022-05-31

Amazon Technologies, Inc.

Transmitting an encrypted communication to a user in a second secure communication network

US11368442B2

( en )

2017-08-29

2022-06-21

Amazon Technologies, Inc.

Receiving an encrypted communication from a user in a second secure communication network

US11457018B1

( en )

2017-08-29

2022-09-27

Amazon Technologies, Inc.

Federated messaging

Also Published As

Publication number

Publication date

RU2020102008A

( en )

2021-07-21

US20180375663A1

( en )

2018-12-27

EP3642997A4

( en )

2020-05-27

CN110771089A

( en )

2020-02-07

EP3642997B1

( en )

2022-03-23

WO2018236908A1

( en )

2018-12-27

EP3642997A1

( en )

2020-04-29

RU2020102008A3

( en )

2021-10-07

US10313133B2

( en )

2019-06-04

US20190245695A1

( en )

2019-08-08

Secure communications providing forward secrecy — Visa International Service Association (US11108565B2)

Related documents