RU2771928C2 - Secure data exchange ensuring direct secrecy - Google Patents

Abstract

FIELD: communication.

SUBSTANCE: invention relates to the field of communication, namely to data exchange. A client masking coefficient and a client masked public key form a key pair based on an elliptic curve, so that the client masked public key can be used for decryption of data that is encrypted using the client masking coefficient, and the client masked public key can be used for confirmation the authenticity of a signature generated by signing data by means of the client masking coefficient.

EFFECT: increase in the security of data exchange.

21 cl, 11 dwg, 1 tbl

Description

BACKGROUND OF THE INVENTION

[0001] This patent application is U.S. International Application No. 15/629689, filed June 21, 2017, which is incorporated herein by reference in its entirety for all purposes.

[0001] Ensuring the secure exchange of data between computers continues to be a task that requires special attention. For example, an attacker can intercept messages (eg, through a man-in-the-middle attack) and infer the identity of a client computer or a server computer based on public keys or other data that is exchanged openly. The intercepted data may be used to track computers or be used for illegal purposes. However, preventing the computer ID from being tracked while allowing the computer to authenticate can be problematic because authentication can depend on the computer identifying itself. Additionally, the encryption keys on the communicating computers can later be decrypted, giving an attacker the ability to decrypt previously intercepted messages. Conducting secure, untraceable, and authenticated communications while securing past communications can be challenging.

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

SUMMARY OF THE INVENTION

[0003] Embodiments of the present invention relate to systems and methods for securely exchanging data. According to embodiments of the present invention, secure communication can be established using one untraceable request message from a first computer and one untraceable response message from a second computer. Non-tracking can be provided by using masking factors. Request and response messages may also contain signatures that provide non-repudiation. Additionally, the encryption of the request and response message is not based on static key pairs that are used to authenticate signatures. Thus, perfect forward secrecy is maintained.

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

[0005] A better understanding of the essence and advantages of the embodiments of the present invention can be achieved with reference to the following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0007] FIG. 2 is a message flow diagram of a client computer and a server computer setting up secure communications using untraceable messages, in accordance with some embodiments.

[0008] FIG. 3 is a message flow diagram of a client computer securely obtaining a certificate from a server computer using untraceable messages, in accordance with some embodiments.

[0009] FIG. 4 is a message flow diagram of a client computer and a server computer establishing a secure and untraceable communication with perfect forward secrecy, in accordance with some embodiments.

[0010] FIG. 5 is a message flow diagram of a client computer and a server computer establishing a secure and untraceable perfect forward secrecy communication using client and server non-repudiation messages, in accordance with some embodiments.

[0011] FIG. 6 is a message flow diagram of a client computer and a server computer establishing a secure and untraceable communication using an encrypted signature part and an unencrypted signature part for non-repudiation, in accordance with some embodiments.

[0012] FIG. 7 is a flowchart of a method for requesting and establishing secure communications, in accordance with some embodiments.

[0013] FIG. 8 is a flow diagram of a method for responding to a request to establish secure communication, in accordance with some embodiments.

[0014] FIG. 9 is a table of steps in a computer-assisted method for establishing secure and untraceable communications with perfect forward secrecy, in accordance with some embodiments.

[0015] FIG. 10 is a table of steps in a computer-assisted method for establishing secure and untraceable communications with perfect forward secrecy between a client computer and a server computer such that the client computer and server computer cannot relinquish their messages, in accordance with some embodiments.

[0016] FIG. 11 is a table of steps for performing a computer-implemented method for establishing secure and untraceable communication with perfect forward secrecy and using an encrypted signature part and an unencrypted signature part, in accordance with some embodiments.

[0017] On graphics, dotted or dashed lines may be used to indicate an organizational structure, to indicate that an element is optional, or to indicate that data or information is passed through an element substantially unchanged. Arrows can be used to indicate the flow of data or information between two or more elements. Circles containing reference positions may indicate that certain steps are performed by an adjacent element.

TERMS

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

[0019] The term "server computer" may include a computer or a cluster of computing devices. For example, a server computer may be a large mainframe computer, a cluster of minicomputers, or a group of servers that function as one unit. In one example, the server computer may be a database server connected to a web server. The server computer may be connected to the database and may contain any hardware, software, other logic or combination of the previous to serve 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 serve requests from one or more client computers.

[0020] The term "public (public)/private key pair" may include a pair of associated cryptographic keys generated by a subject (eg, computer or electronic device). The public key can be used for public functions, such as encrypting a message to be sent to the subject, or to verify a digital signature that is believed to have been created by the subject. The private key, on the other hand, can be used for private functions such as decrypting a received message or digitally signing it. The public key usually authorizes an authority, known as a Certification Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key is usually stored on a secure storage medium and is usually only known to the subject. However, the cryptographic systems described herein may have key recovery mechanisms to recover lost keys and avoid data loss. The public and private keys may be in any suitable format, including those based on public key cryptographic algorithm (RSA) or elliptic curve cryptography (ECC).

[0021] "Digital signature" may refer to the result of applying an algorithm based on a public/private key pair that allows a signer to claim, and a verifier to verify, the authenticity and integrity of a document. The signer acts with the private key, and the verifier acts with the public key. This process certifies the authenticity of the sender, the integrity of the signed document, and the so-called non-repudiation principle, which does not allow rejection of what has been signed. A certificate or other data that contains the signer's digital signature is said to be "signed" by the signer.

[0022] A "certificate" or "digital certificate" may include an electronic document or data file that uses a digital signature to associate a public key with data associated with an identifier. The certificate may contain one or more data fields, such as the legal name of the subject, the serial number of the certificate, the start and end date of the certificate, associated with the authorization certificate, etc. The certificate may contain a start date indicating the first date on which the certificate is valid , and an expiration date indicating the last date the certificate is valid. The 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 certification authority.

[0023] A "certificate authority" (OS) may have one or more server computers operably linked to issue certificates to subjects. The OS can prove its identity with the OS certificate, which contains the public key of the OS. An OS certificate can be signed with the private key of another OS, or it can be signed with the private key of the same OS. The latter is known as a self-signed certificate. The OS may maintain a database of all certificates issued by the OS, and may also maintain a list of revoked certificates.

[0024] In the normal process, the certification authority accepts an unsigned certificate from a subject whose authenticity is known. An unsigned certificate contains a public key, one or more data fields, and a hash of the data in the certificate. The OS signs the certificate with the private key corresponding to the public key included in the OS certificate. The OS can then store the signed certificate in the database and issue the signed certificate to the subject.

[0025] A "cryptographic nonce" may include any number, string, bit sequence, or other data value intended to be used in conjunction with a single communication session. In some cases, a cryptographic nonce may be generated randomly or pseudo-randomly. Typically, a cryptographic nonce is long enough to make it negligible that the same value of a nonce can be independently generated multiple times.

[0026] A "masked key" such as a "masked public key" may include a key that has been mangled or otherwise altered from its original value by combination with another data element, such as a cryptographic nonce. For example, in elliptic curve cryptography, the public key can be multiplied by a nonce object to generate a "masked public key". Similarly, to generate a "masked private key", the private key can be multiplied by a nonce object. The nonce object can be the same bit length as the public key and private key.

[0027] A "short-lived key pair" may include a public key (i.e., "short-lived public key") and a private key (i.e., "short-lived private key") generated for use with one transaction or another communication session. The short-lived key pair can be in any suitable format, such as ECC or RSA. As a rule, a pair of short-lived keys can be deleted immediately after the completion of a transaction or communication session.

[0028] A "static key pair" may include a public key (ie, "static public key") and a private key (ie, "static private key") stored over a period of time. Typically, although not necessarily, a static private key may be stored in a secure manner, such as in a hardware security module (HSM) or security element (SE). Typically, though not necessarily, a static public key can be associated with an identity using a digital certificate. A static key pair can be in any suitable format such as ECC or RSA.

[0029] A "Shared Secret" may include any data value or other information known only to authorized parties in a secure data exchange. The shared secret may be generated in any suitable manner from any suitable data. For example, a Diffie-Hellman algorithm such as Elliptic Curve Diffie-Hellman (ECDH) can be used to generate a shared secret from a private key and a public key. For example, the first computer may generate a first key pair including 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 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 the session key.

[0030] The term "identity" may include any data or information associated with a user or device. Examples of identification data may include the username associated with the device, the organization associated with the device, billing information such as the Primary Account Number (PAN) associated with the device, the expiration date of the device, the certificate associated with the device, the International Device Identification Number (IMEI) or device serial number, etc.

[0031] The term "authentication" generally refers to the process of verifying the identity of a user or computer. Authentication may be performed by authenticating the device using public key cryptography (eg, encrypted data or digital signatures) for authentication information.

[0032] The term "authentication data" or "authentication information" 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 (such as a private key), a digital signature, an indication that the device stores certain information, etc.

[0033] An "encryption key" may include any data value or other information suitable for cryptographically encrypting data. The "decryption key" may include any data value or other information suitable for decrypting the encrypted data. In some cases, the same key that is used to encrypt the data can be used to decrypt the data. Such a key may be known as a symmetric encryption key.

[0034] A "session key" may include any key used to encrypt or decrypt data for secure exchange. In some cases, the session key may be generated from a shared secret known to both the sending entity and the receiving entity. For example, the session key may be generated using a key derivation function and a shared secret.

[0035] "Untrackable" is a secure communication characteristic that refers to the ability of a communication message not to reveal sender identity information so that the message can be traced back to them. For example, in some secure communication, the static public key of the first computer is sent to the second computer in the clear (eg, unencrypted) during a Diffie-Hellman key exchange. The public key of the first computer can be static because it corresponds to a certificate stored on it that is signed by a certification authority. As such, the first computer can be identified and tracked by intercepting its communications based on the unencrypted public key sent during the Diffie-Hellman key exchange. In another scenario, the signature may be sent unencrypted and a third party may intercept the signature and attempt to authenticate the signature using many different public keys to identify and track the signer of the signature. To prevent snooping, a computer can generate a short-lived key pair for use during a key exchange and then delete it after the shared secret is established. Another way to prevent snooping is to "mask" the public key using a cryptographic nonce (for example, a randomly generated number).

[0036] "Non-repudiation" is a secure communication characteristic that refers to a communication message that prevents a message sender from denying that it has sent the message. A secure communication protocol that provides "non-repudiation" can prevent a computer from denying that a message was sent by it using public key cryptography. Additionally, "non-repudiation" provides "authentication" of the sender, since the recipient can authenticate that only the sender could have sent the message. In one example, the encrypted message may contain a signature generated using the first computer's static private key. The static private key may correspond to the static public key that is included in the first computer's certificate that is signed by the certification authority. In this example, the private key is known only to 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 discard the first message if its public key can authenticate the signature, since no other device can access its private key to create a signature. Unlike a signature, encrypting a message by itself may not provide non-repudiation of the message, as there may be no established way to verify which device generated the message.

[0037] "Forward secrecy" is a characteristic of secure communication that refers to the ability of messages not to be decrypted if the private keys of the sender and/or recipient of the messages are later decrypted. "Ideal forward secrecy" is a characteristic of secure communication that refers to the ability of messages not to be decrypted if the private keys of both the sender and recipient of the messages are later decrypted. In one scenario, the private keys may be obtained by a third party who gains physical access to the computers. In another scenario, a third computer might spend quite a lot of time cracking the private key, which would be impractical, but not impossible. However, secure communications with "perfect forward secrecy" cannot be decrypted even if both the static private keys of the sending and receiving computers are decrypted. One way to achieve "perfect forward secrecy" is to not encrypt messages using static private keys. Accordingly, if static private keys are decrypted, they cannot be used to decrypt messages. In one example, an encryption key pair may be randomly generated for a key exchange and then deleted a little later (eg, set to zero). Accordingly, the private key cannot be obtained if a third party later gains physical access to the computer. Therefore, messages sent in the past retain their secrecy for the future. Also, even if one message is declassified, other messages are not declassified because there is no single key used to encrypt different messages.

IMPLEMENTATION OF THE INVENTION

[0038] Methods and systems for secure communication are described herein. In one embodiment, the first computer and the second computer may communicate over an insecure network (eg, the Internet). To exchange messages over a secure link, the first computer and the second computer may share a secret symmetric key used to encrypt messages. To prevent a third party from obtaining the secret symmetric key, two computers can exchange public keys and then separately generate the same secret symmetric key using their own private key and 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 as a result determine the shared symmetric key.

[0039] Transient key pairs or masked public keys may be used to provide non-traceability. However, since the sender ID is hidden to ensure untraceability, one consequence could be that the sender may deny that they sent the message. To prevent a sender from refusing to send messages, the message may contain a signature that is generated using the sender's static public key. Thus, untraceable keys can be used for encryption, while traceable keys can be used to generate a signature. Additionally, new and different public keys may be used in each key exchange and deleted immediately or shortly after the shared secret is established. Additionally, although traceable signatures may be used, they may be included in the encrypted portion of the message, so they cannot be used to track the sender or recipient of the message. Accordingly, secure communications with "non-traceable", "non-repudiation" and "perfect forward secrecy" can be established. Methods and systems for establishing such communications are described in more detail below.

I. ENSURING THE SECURITY OF DATA EXCHANGE WITH THE USE OF ENCRYPTION KEYS

[0040] The Diffie-Hellman key exchange may allow the first computer and the second computer to establish a secret symmetric key over an insecure network without transmitting the secret symmetric key itself. The Diffie-Hellman key exchange cannot be based on any information previously stored on the first or second computer prior to the key exchange. For example, a Diffie-Hellman-based algorithm such as Elliptic Curve Diffie-Hellman (ECDH) can be used to generate a shared secret from a first computer's private key and a second computer's public key. For example, the first computer may generate a first key pair including 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 to encrypt the communication. As such, the first computer and the second computer can establish secure communication over an insecure network without using any pre-established information.

[0041] FIG. 1 is a simplified message flow diagram 100 illustrating secure communications between client computer 140 and server computer 180, in accordance with some embodiments. The message flow scheme 100 may be used between any first computer and any second computer. The client/server division used in this document is illustrative only and is done to improve understanding. In some embodiments, client computer 140 may perform the operations described as being performed by server computer 180. In some embodiments, server computer 180 may perform operations described as being performed by client computer 140.

[0042] Referring to FIG. 1, client computer 140 may store a client key pair containing a public key and a client private key corresponding to the client's public key. The client key pair can be static. The server computer 180 may store a server key pair containing the server's public key and a server's private key corresponding to the server's public key. The server key pair can be static. Client computer 140 and server computer 180 may communicate over an insecure network 160 (eg, the Internet or a wireless LAN). An insecure network 160 may be "insecure" in the sense that the communication medium itself is not physically secure, or it may be "insecure" in the sense that messages are not transmitted directly between two parties but also pass through other third parties on the network. .

[0043] Client computer 140 and server computer 180 may perform a key exchange to establish secure communications over insecure network 160. For example, client computer 140 and server computer 180 may perform a Diffie-Hellman key exchange as described above to establish a joint a shared secret between client computer 140 and server computer 180. Client computer 140 and server computer 180 can each generate a session key from a shared secret to encrypt and decrypt messages they exchange with each other.

[0044]At the stage 101, the client computer 140 may send a request message to the server computer 180 to initiate the establishment of a secure communication. In some embodiments, the request message may contain identification data. The client computer 140 may encrypt the identity of the response message using the shared secret to obtain the encrypted identity. Client computer 140 may send a challenge message containing encrypted credentials to server computer 180 over insecure network 160.

[0045] Server computer 180 may receive a challenge message from client computer 140 over insecure network 160. Server computer 180 may decrypt the encrypted challenge message credentials using the shared secret (e.g., using a session key generated from the shared secret ). Server computer 180 may also verify the identity against data stored on server computer 180. Server computer 180 may then encrypt the payload for client computer 140 using the shared secret to obtain the encrypted payload. In some embodiments, server computer 180 may generate a second shared secret for use in encrypting server computer payloads.

[0046] In step 102, server computer 180 may send a response message containing the encrypted payload to client computer 140. Server computer 180 may send response data to client computer 140 in response to an identity verification received from client computer 140. Client computer 140 may receive the response message and decrypt the encrypted payload using the session key to obtain payload data from server computer 180. Thus, client computer 140 and server computer 180 can establish secure communication over insecure network 160 by performing a key exchange using the method Diffie-Hellman.

[0047] However, the key exchange described above with respect to FIG. 1 may include the first computer (eg, client computer 140) sending its first public key to a second computer (eg, server computer 180) and the second computer sending its second public key to the first computer. Thus, the intercept computer can intercept messages to track the first computer's ID based on the first public key and to track the second computer's ID based on the second public key. In addition, the interception computer may perform a proxy attack or spoof the first computer or the second computer. Some of the embodiments described below overcome these shortcomings.

II. SECURE AND UNTRACKED DATA EXCHANGE

[0048] As discussed above, public key exchange (eg, Diffie-Hellman key exchange) may involve sending static public keys publicly (eg, unencrypted). If there are no other means to securely exchange data between two computers, then the public keys themselves cannot be encrypted. However, a third party computer can intercept the messages (for example, because they are sent over an insecure network such as the Internet) and identify the two computers based on their static public keys. This may allow a third party to track computers.

A. How to establish a secure and untraceable communication

[0049] Message traceability is a problem because it can allow a third party computer to track certain computers, thereby violating the confidentiality of communications and the privacy of the computer and its users. To solve the traceability problem, the client computer can generate a short-lived key pair that is different from its static key pair and use the short-lived public key in the key exchange. The client computer MAY delete this short-lived key pair after the shared secret is established, and generate new short-lived key pairs when subsequent secure communication channels are established. Thus, the open exchange of short-lived public keys does not allow a third party to intercept the client computer, since this particular short-lived public key is used only by the client in this one communication session.

[0050] FIG. 2 is a message flow diagram 200 of a client computer 240 and a server computer 280 setting up secure communications using untraceable messages, in accordance with some embodiments. Before the message flow of FIG. 2, client computer 240 may store client payload 252 and server computer 280 server certificate 288. Client computer 240 may obtain server computer certificate 288 using a message flow such as that described below with respect to FIG. 3.

[0051] The server computer 280 may store a pair of static server keys 286 containing a static private key 282 of the server and a static public key 284 of the server. The server computer 280 may also store the server certificate 288 . The server certificate 288 may contain a static server public key 284 and a certification authority signature to authenticate the server computer 288. The server static private key 282 and the server static public key 284 may be "static" in the sense that they do not change over time, allowing authentication of the server computer 288 using the certificate 288 of the server. Server computer 280 may also store payload data 292 of the server. The server payload 292 can be treated as private data so that it is not transmitted openly without encryption.

[0052] In this message flow, the client computer 240 may initiate the establishment of a secure communication. At block 201, client computer 240 may generate a client's short-lived private key. The client's short-term private key can be randomly generated.

[0053] At step 202, the client computer 240 may determine the client's short-lived public key using the client's short-lived private key. The client's short-term private key and the client's short-term public key may form a key pair for use in public key cryptography.

[0054] At step 203, the client computer 240 may determine the first shared secret using the client's short-lived private key and the server's static public key 284, which may be included in the server's certificate 288. The client computer 240 may determine the first session key using a key derivation function based on the shared secret, the server computer 280 ID, and the communication session ID.

[0055] At 204, client computer 240 may encrypt client payload 252 using a first shared secret (eg, using a first session key) to determine encrypted client data. The client payload 252 may contain private client data and/or a request for certain data or information from the server computer 280. After the client payload 252 is encrypted, the client computer 240 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0056] At step 205, client computer 240 may send a "request message" containing the client's short-lived public key and encrypted client data to server computer 280. The client's short-term public key may be sent in the clear (eg, unencrypted). The request message may indicate that the client computer 240 is requesting the establishment of a secure communication using a shared secret based on the client's masked public key. The request message may be sent over an insecure network. Server computer 280 may receive a request message from client computer 240. Because the client's short-lived public key is only used for this communication session (client's short-lived private key is reset at step 214), it cannot be used to track client computer 240. Thus , the request message sent in step 205 is untraceable.

[0057] At step 206, the server computer 280 may determine the first shared secret using the server's static private key 282 and the client's masked public key. The first shared secret determined by the server computer in step 206 using the server's static private key 282 and the client's masked public key may be the same as the first shared secret generated by the client computer 240 in step 203 using the client's short lived private key and static public key 284 server. The server computer 280 may also determine the same first session key determined by the client computer 240 using a key derivation function based on the shared secret, the server computer 280 ID, and the communication session ID.

[0058] At step 207, the server computer 280 may decrypt the encrypted client data using the first shared secret (eg, using the first session key) to obtain the client payload 252. After the client payload 252 is decrypted, the server computer 280 may nullify (eg, 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 suitable data or information to include in the server payload 292 provided in response to the client computer's request.

[0059] At 208, server computer 280 may generate a server masking factor. The server masking factor may be a randomly generated cryptographic nonce. The server computer 280 may use a server masking factor to prevent third parties from tracking it, as described below. For example, server computer 280 may apply a server masking factor to the server's static public key 284 (eg, using a multiplication) to determine the server's masked public key. Server computer 280 may use only this server mask factor and this masked server public key in this particular communication session with client computer 240, and may generate a different mask factor for subsequent communication sessions. Thus, server computer 280 may not be tracked by third parties based on the server's masked public key.

[0060] At 209, the server computer 280 may determine a second shared secret using the server's masking factor, the server's static private key 282, and the client's short-lived public key. Server computer 280 may also determine a second session key using a key derivation function and a second shared secret.

[0061] At step 210, the server computer 280 may determine the server's masked public key using the server's masking factor and the server's static public key. For example, server computer 280 may apply a server masking factor to the server's static public key 284 (eg, using a multiplication) to determine the server's masked public key.

[0062] In step 211, server computer 280 may encrypt the server masking factor, server certificate 288, and server payload 292 using a second shared secret (eg, using a second session key) to obtain encrypted server data.

[0063] At 212, server computer 280 may send a response message containing the server's masked public key and encrypted server data to client computer 240. The response message may be sent over an insecure network. The server's disguised public key may be sent in the clear (eg, unencrypted). However, the server's masked public key is based on the server's masking factor, which can only be used in that particular communication session. Accordingly, server computer 280 cannot be tracked by a third party intercepting this message and other messages sent by server computer 280. Client computer 240 can receive a response message.

[0064] At 213, the client computer 240 may determine a second shared secret using the client's short-lived private key and the server's masked public key. The second shared secret determined by the client computer 240 at step 213 may be the same as the second shared secret determined by the server computer 280 at step 209 using the client's short-lived public key, the server's masking factor, and the server's static private key 284. The client computer 240 may also determine the same second session key (which is also determined by the server computer 280) using a key derivation function and a second shared secret.

[0065] At step 214, after determining the second shared secret and the second session key, the client computer 240 may reset the client's short-lived private key. That is, the client computer 240 can delete the client's transient private key so that it cannot be recovered later. In addition, even if the client's short-lived private key was decrypted and received by a third party shortly before it was reset to zero, the third party would not be able to decrypt any other communication using the client's short-lived private key, since this client's short-lived private key was only used to decrypt this particular response message.

[0066] At step 215, the client computer 240 may decrypt the encrypted server data using the second shared secret (eg, using the second session key) to obtain the server masking factor, the server certificate 288, and the server payload 292.

[0067] At step 216, the client computer 240 can verify the server's masked public key by regenerating it using the server's masking factor and the server's static public key 284 that is included in the server's certificate 288. The client computer 240 can authenticate that the server computer 280 sent the response message based on the server's verifiable masked public key.

[0068] At 217, client computer 240 and server computer 280 may end the communication session, or they may continue secure communication using the second session key.

[0069] The message flow of FIG. 2 allows the client computer 240 and the server computer 280 to establish a secure communication using untraceable messages, thereby ensuring the confidentiality of the communication and maintaining the privacy of the client computer 240, server computer 280 and their users. However, the message flow of FIG. 2 requires the client computer 240 to store the server computer's server certificate 288, which contains the server's static public key 284 used in generating the first shared secret. Accordingly, the client computer 240 must obtain the server certificate 288 earlier.

B. How to obtain a certificate using untraceable data exchange

[0070] As discussed above, message traceability is a problem because it can allow a third party computer to track certain computers, thereby violating the confidentiality of communications and the privacy of the computer and its users. To solve the traceability problem, the client computer can generate a short-lived key pair that is different from its static key pair. As described above with reference to FIG. 2, the client computer can send the short-lived public key to the server computer without violating confidentiality or privacy. However, if the client computer has not already stored a copy of the server computer's public key (for example, based on the server computer's certificate), then the client computer cannot establish a shared secret with the server computer using public key cryptography. This situation is problematic because the client computer must be able to verify that the certificate received in the response message from the server computer is in fact the server computer's certificate (not another computer's certificate), without the server computer being able to provide its static public key on the client computer is open due to the traceability issue described in this document. Accordingly, the client computer must obtain the server computer's certificate using secure and untraceable messaging to maintain confidentiality and privacy.

[0071] FIG. 3 is a message flow diagram 300 of a client computer 340 securely obtaining a certificate from a server computer 380 using untraceable messages, in accordance with some embodiments. Before the message flow of FIG. 2, the client computer 340 may not store the server computer 380 server certificate 388.

[0072] The server computer 380 may store a static server key pair 386 containing a server static private key 382 and a server static public key 384. The server computer 380 may also store the server certificate 388 . The server certificate 288 may contain a static server public key 384 and a certification authority signature to authenticate the server computer 388. The server static private key 382 and the server static public key 284 may be "static" in the sense that they do not change over time, allowing authentication of the server computer 388 using the certificate 388 of the server. Server computer 380 may also store server payload 392 . The server payload 392 can be treated as private data so that it is not transmitted openly without encryption.

[0073] In this message flow, the client computer 340 may initiate the establishment of a secure communication. At step 301, the client computer 340 can generate a client's short-lived private key. The client's short-term private key can be randomly generated.

[0074] At 302, the client computer 340 may determine the client's short-lived public key using the client's short-lived private key. The client's short-term private key and the client's short-term public key may form a key pair for use in public key cryptography.

[0075] At 303, client computer 340 may send a "request message" containing the client's short-lived public key to server computer 380. The client's short-term public key may be sent in the clear (eg, unencrypted). The request message may indicate that the client computer 340 is requesting the acceptance of a server certificate 388 . The request message may be sent over an insecure network. The server computer 380 may receive a request message from the client computer 340. Because the client's short-lived public key is only used for this communication session (the client's short-lived private key is reset at step 310), it cannot be used to track the client computer 340. Thus , the request message sent in step 303 is untraceable.

[0076] At 304, server computer 380 may generate a server masking factor. The server masking factor may be a randomly generated cryptographic nonce. The server computer 380 may use a server masking factor to prevent third parties from snooping on its communications, as described below. For example, server computer 380 may apply a server masking factor to the server's static public key 384 (eg, using a multiplication) to determine the server's masked public key. Server computer 380 may only use a given server mask factor and a given masked server public key in a given communication session with client computer 340, and may generate a different mask factor for subsequent communication sessions. Thus, the server computer 380 may not be tracked by third parties based on the server's masked public key.

[0077] At step 305, the server computer 380 may determine the first shared secret using the server 382's static private key and the client's short-lived public key. The server computer 380 may determine the first session key using a key derivation function based on the first shared secret. The server computer 380 may use the first session key to encrypt the server certificate 388 and the server payload 392 for transmission to the client computer 340.

[0078] At step 306, the server computer 380 may determine the server's masked public key using the server's masking factor and the server's static public key 384. For example, server computer 380 may apply a server masking factor to the server's static public key 384 (eg, using a multiplication) to determine the server's masked public key.

[0079] At step 307, server computer 380 may encrypt the server masking factor, server certificate 388, and server payload 392 using a first shared secret (eg, using a first session key) to obtain encrypted server data. After encryption, the server computer 380 may reset the first shared secret and the first session key.

[0080] At 308, server computer 380 may send a response message containing the server's masked public key and encrypted server data to client computer 340. The response message may be sent over an insecure network. The server's disguised public key may be sent in the clear (eg, unencrypted). However, the server's masked public key is based on the server's masking factor, which can only be used in that particular communication session. Accordingly, server computer 380 cannot be tracked by a third party intercepting this message and other messages sent by server computer 380. Client computer 340 can receive a response message.

[0081] At 309, the client computer 340 may determine the first shared secret using the client's short-lived private key and the server's masked public key. The first shared secret determined by the client computer 340 at step 309 may be the same as the first shared secret determined by the server computer 380 at step 305 using the client's short-lived public key, the server's masking factor, and the server's static private key 284. The client computer 340 may also determine the same first session key (which is also determined by the server computer 380) using the key derivation function and the first shared secret.

[0082] At 310, after determining the first shared secret and the first session key, the client computer 340 may reset the client's short lived private key. That is, the client computer 340 can delete the client's transient private key so that it cannot be recovered later. In addition, even if the client's short-lived private key was decrypted and received by a third party shortly before it was reset to zero, the third party would not be able to decrypt any other communication using the client's short-lived private key, since this client's short-lived private key was only used to decrypt this particular response message.

[0083] At step 311, the client computer 340 may decrypt the encrypted server data using the first shared secret (eg, using the first session key) to obtain the server masking factor, the server certificate 388, and the server payload 392.

[0084] At step 312, the client computer 340 can verify the server's masked public key by regenerating it using the server's masking factor and the server's static public key 384 that is included in the server's certificate 388. The client computer 340 can authenticate that the server computer 380 sent the response message based on the server's verifiable masked public key.

[0085] At step 313, the client computer 340 may store the server certificate 388 so that the server's static public key 384 may be used to encrypt subsequent communication with the server computer 380, such as that described above with reference to FIG. 2.

[0086] The message flows of FIG. 2 and FIG. 3 allow the client computer and the server computer to establish a secure communication using untraceable messages, even if the client computer has not previously stored the server computer's public key. However, the message flows of FIG. 2 and FIG. 3 do not allow the server computer to authenticate the client computer without sending additional messages or including additional data in the request and response messages. Thus, a failure problem may arise. For example, the client computer might deny sending the request message. Accordingly, it would be useful for messages to have a "non-repudiation" property such that messages cannot be sent by a computer, as opposed to a message storing a specific private key corresponding to a specific public key included in said message. It would also be advantageous if messages from the server computer also had authenticated data, so that the message could not be rejected.

[0087] In addition, the complication of this problem is necessary for messages to maintain "perfect forward secrecy". That is, declassifying a computer's private key or a single message should not then declassify any previous messages that could be intercepted. Additionally, messages must be untraceable. In addition, network and computing resource usage can be reduced by limiting the message flow to establish secure communication for only one request message from the client computer and one response message from the server computer. Methods and systems that solve these problems by using only one request message from the client computer and one response message from the server computer are described in more detail below.

III. SECURE AND NEUTRALIZED DATA EXCHANGE FOR PERFECT FORWARD SECRETY AND NON-REFUSAL

[0088] In other message flows, non-traceability can be achieved by masking public keys that are exchanged openly using masking factors. Such message flows can also achieve mutual authentication of two computers by including masking factors in the encrypted portions of the message, allowing the recipient of the message to authenticate the sending computer by comparing the masked public key received in the open with a matching masked public key determined by applying the masking factor to the static public key, included in the sender's certificate. However, in such message flows, the masking factor is used for both encryption and authentication. Accordingly, if the private keys of both devices are obtained by a third party, the third party can decrypt any new messages as well as any previously intercepted messages. For example, a third party may use the server's static private key together with the client's masked public key (received in the open in the request message) to generate a shared secret that can be used to decrypt the client's masking factor (in the encrypted payload of the intercepted request message). The third party can then decrypt the response message sent from the server using the client's static private key and the client's masking factor (obtained from the request message sent to the server). Thus, a third party can decrypt previously intercepted messages if they can obtain the private keys of both the client and the server. That is, the messages in this exemplary message stream violate "ideal forward secrecy."

[0089] Referring again to FIG. 2, this message flow allows the client computer and the server computer to establish a secure communication using untraceable messages while maintaining the confidentiality of the communication and preserving the privacy of the client computer, server computer, and their users. However, the client computer cannot authenticate the server computer, and the server computer cannot authenticate the client computer separately on a challenge and response basis. That is, the client computer and the server computer cannot authenticate each other without exchanging additional data, either in the request or in the response, or in additional communication messages.

[0090] It would be advantageous to establish a secure exchange of data using only one request message and one response message, while the messages have the property of "non-traceability" while providing "non-repudiation" of messages and maintaining "perfect forward secrecy" .

A. Secure communication for perfect forward secrecy and customer non-repudiation

[0091] FIG. 4 is a diagram 400 of a message flow of a client computer 440 and a server computer 480 establishing secure and untraceable perfect forward secrecy communication, in accordance with some embodiments. This message flow contains a request message transmitted by the client computer 440 at step 406 that cannot be rejected by the client computer 440. The request message at step 406 and the response message from the server computer 480 at step 415 are untraceable because they contain short-term masked public keys instead of static public keys. In addition, the request and response message maintains perfect forward secrecy. The generation and format of the request and response messages are described in more detail below.

[0092] In this message flow, the client computer 440 may initiate the establishment of a secure communication. Prior to message flow, the client computer 440 may store a client static key pair 446 containing a client static private key 442 and a client static public key 444 . The client computer may also store a client certificate 448 that is signed by a certification authority and that contains the client's static public key 444 . The client computer 440 may also store the server certificate 488 . Additionally, client computer 440 may store client payload data 452, which may be private data.

[0093] At 401, client computer 440 may generate a client masking factor. The client masking factor can be randomly generated.

[0094] At 402, the client computer 440 may determine the client's masked public key using the client's masking factor. The client masking factor and the client masked public key can form an elliptic curve key pair, so that the client masked public key can be used to decrypt data that is encrypted using the client masking factor, and the client masked public key can be used to authenticate a signature. generated by signing data with a client masking factor. Thus, the client's masking factor can be used as a private key based on the elliptic curve.

[0095] At step 403, the client computer 440 may determine the first shared secret using the client's masking factor and the server's static public key 484, which may be included in the server's certificate 488. The client computer 440 may determine the first session key using a key derivation function based on the first shared secret.

[0096] At 404, the client computer 440 can determine the client's signature by signing (using the client's static private key 442) the client payload 452, the client's masked public key, and the server's static public key 484. The client computer 440 may determine the client's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA). The client signature may be included in the request message from the client computer 440 to ensure that the client computer 440 cannot be denied. Additionally, the client signature is based on a client masking factor that is used only in a given communication session (e.g., in a single request, single response message) . Thus, the signature is only valid for this particular request message. In addition, the client's signature is based on the static public key 484 of the server. Thus, the other computer may not impersonate the recipient of that particular request message.

[0097] In some embodiments, the client's signature may also be based on a seed indicating the novelty (eg, timeliness) of the request message. The seed may also be included in the encrypted client data so that the recipient of the request message can verify that the message is not old based on the value of the seed. The initial value may be, for example, a trusted time or a counter. The server computer 480 may receive its own trusted time or counter value to verify the seed in the request message.

[0098] At step 405, the client computer 440 may encrypt the client payload 452, the client certificate 448, the client signature, and the client's masked public key using the first shared secret (eg, using the first session key) to determine the encrypted client data. The client computer may perform the encryption, for example, using the Authenticated Associated Data Encryption (AEAD) process. The client payload 452 may contain private client data and/or a request for specific data or information from the server computer 480. After the client payload 452 is encrypted, the client computer 440 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0099] At 406, client computer 440 may send a "request message" containing the client's masked public key and encrypted client data to server computer 480. The client's masked public key may be sent in the clear (eg, unencrypted). The request message may indicate that the client computer 440 is requesting the establishment of a secure communication using a shared secret based on the client's masked public key. The request message may be sent over an insecure network. Server computer 480 may receive a request message from client computer 440.

[0100] Since the client's masked public key is only used for this communication session (the client's masking factor is set to zero at step 417), it cannot be used to track the client computer 440. Thus, the request message sent at step 405 is untraceable.

[0101] Additionally, the challenge message sent at step 405 ensures that the client computer 440 cannot be refused because the client's encrypted data contains the client's signature, which was generated using the client's masking factor.

[0102] Additionally, the request message maintains perfect forward secrecy because there is no data included in the request message that can be used to decrypt any data in other messages sent by client computer 440, past or future. Perfect forward secrecy is maintained because the client masking factor is not provided in the encrypted client data. For example, a client signature is used to authenticate the client computer 440 instead of using a masking factor. However, the client's signature does not contain information that can be used to decrypt messages from the client computer 440, even if the client's static private key 442 and the server's static private key 482 are decrypted.

[0103] At 407, the server computer 480 may determine the first shared secret using the server's static private key 482 and the client's masked public key that was included in the request message. The first shared secret determined by the server computer in step 406 using the server's static private key 482 and the client's masked public key may be the same as the first shared secret generated by the client computer 440 in step 403 using the client's masking factor and the static public key 484 server. The server computer 480 may also determine the same first session key determined by the client computer 440 using a key derivation function based on the first shared secret.

[0104] At 408, the server computer 480 may decrypt the encrypted client data using the first shared secret (eg, using the first session key) to obtain the client payload 452, the client certificate 448, the client signature, and the client's masked public key. The server computer may perform the decryption, for example, using an Authenticated Associated Data Encryption (AEAD) based decryption process. After decrypting the encrypted client data, the server computer 480 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0105] At step 409, the server computer 480 can verify the client's signature using the client's static public key 444, which is included in the client's certificate 448, the client payload 452, the client's masked public key, and the server's static public key 484. The server computer 480 may verify the client's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0106] The server computer 480 may also authenticate the certificate chain associated with the client certificate 448. Additionally, the server computer 480 may process the client payload 452 and generate or identify any suitable data or information to include in the server payload 492 to be provided in response to the client computer's request.

[0107] At 410, server computer 480 may generate a server masking factor. The server masking factor may be a randomly generated cryptographic nonce. Server computer 480 may use a server mask to prevent third parties from tracking it, as described herein. For example, server computer 480 may apply a server masking factor to the server's static public key 484 (eg, using a multiplication) to determine the server's masked public key. The server computer 480 may use only the given server mask factor and the given server masked public key in that particular communication session with the client computer 440 (eg, in the request message at 406 and the response message at 415) and may generate a different mask factor for subsequent communication sessions. Thus, the identity of the server computer 480 may not be tracked based on the server's masked public key.

[0108] At 411, the server computer 480 may determine the second shared secret using the server's masking factor, the server's static private key 482, and the client's masked public key. In some embodiments, the server computer 480 may store multiple static key pairs and it may use a different static key pair to encrypt the response message. Server computer 480 may also determine a second session key using a key derivation function and a second shared secret.

[0109] At 412, the server computer 480 may determine the server's masked public key using the server's mask factor and the server's static public key. For example, server computer 480 may apply a server masking factor to the server's static public key (eg, using a multiplication) to determine the server's masked public key. The server's static public key used to determine the server's masked public key may be part of another static key pair, as discussed above.

[0110] In step 413, the server computer 480 may encrypt the server masking factor, the server certificate (corresponding to the static public key of the static key pair used for encryption), the server payload 492, and the server's masked public key using a second shared secret (e.g., with using the second session key) to obtain encrypted server data. Server computer 480 may perform encryption, for example, using an authenticated data encryption (AEAD) process.

[0111] At 414, server computer 480 may send a response message containing the server's masked public key and encrypted server data to client computer 440. The response message may be sent over an insecure network. The server's disguised public key may be sent in the clear (eg, unencrypted). However, the server's masked public key is based on the server's masking factor, which can only be used in that particular communication session. Accordingly, server computer 480 cannot be tracked by a third party intercepting this message and other messages sent by server computer 480. Client computer 440 can receive a response message.

[0112] At 416, the client computer 440 may determine the second shared secret using the client's masking factor and the server's masked public key that was received in the response message. The second shared secret determined by the client computer 440 at step 416 may be the same as the second shared secret determined by the server computer 480 at step 411 using the client's masked public key, the server's masking factor, and the server's static private key. The client computer 440 may also determine the same second session key (which is also determined by the server computer 480) using the key derivation function and the second shared secret.

[0113] At step 417, after determining the second shared secret and the second session key, the client computer 440 may reset the client masking factor to zero. That is, the client computer 440 may remove the client masking factor so that it cannot be recovered later. In addition, even if the client masking factor was decrypted and received by a third party in a short period of time before it was reset, the third party would not be able to decrypt any other communication using the client masking factor, it was only used to decrypt this particular response message. . Additionally, even if a third party gains access to both of the client computer's static private key and the server computer's static private key, it cannot decrypt the response message without obtaining the client's masking factor, which is set to zero immediately upon receipt of the response message. Thus, perfect forward secrecy is maintained.

[0114] At step 418, the client computer 440 may decrypt the encrypted server data using the second shared secret (e.g., using the second session key) to obtain the server masking factor, the server certificate (corresponding to the static public key of the static key pair used for encryption) , server payload 492, and the server's masked public key. The client computer 440 may perform the decryption, for example, using an Authenticated Encrypted Associated Data (AEAD) decryption process.

[0115] At step 419, the client computer 440 can verify the masked server public key by regenerating it using the server masking factor included in the response message and the server certificate static public key that is also included in the response message. The client computer 440 can authenticate that the server computer 480 sent the response message based on the server's verifiable masked public key. The client computer 440 may also authenticate the server certificate chain included in the response message.

[0116] At 420, the client computer 440 may reset the server's masking factor so that it cannot be recovered later. Thus, a third party will not be able to decrypt the response message, even if it has access to the static private keys of the client computer 440 and server computer 480, because either the server mask factor or the client mask factor are required for decryption, and all of them are set to zero.

[0117] At 421, client computer 440 and server computer 480 may end the communication session, or they may continue secure communication using the second session key.

[0118] The message flow of FIG. 4 allows the client computer 440 and the server computer 480 to establish a secure communication using untraceable messages, thereby ensuring the confidentiality of the communication and maintaining the privacy of the client computer 440, server computer 480 and their users. Additionally, the client computer 480 cannot discard the request message because it contains the client's signature. In addition, request and response messages retain perfect forward secrecy because their encryption depends on the client's mask factor and the server's mask factor, which are set to zero as soon as they are no longer needed for the decryption process. Additionally, network and computing resource usage is reduced because the solution is achieved using only one request message and one response message.

B. Secure communication providing perfect forward secrecy and non-repudiation of client and server

[0119] FIG. 5 is a message flow diagram 500 of a client computer 540 and a server computer 580 establishing a secure and untraceable perfect forward secrecy communication using client and server non-repudiation messages, in accordance with some embodiments. This message flow contains a request message sent by the client computer 540 at block 506, which cannot be refused by the client computer 540, and a response message sent by the server computer 580 at block 516, which cannot be refused by the server computer 580. The request message at step 506 and the response message at step 516 are untraceable because they contain one-time masked public keys instead of static public keys. In addition, the request and response message maintains perfect forward secrecy. The generation and format of the request and response messages are described in more detail below.

[0120] In this message flow, the client computer 540 may initiate the establishment of a secure communication. Prior to message flow, the client computer 540 may store a client static key pair 546 containing the client's static private key 542 and the client's static public key 544. The client computer may also store a client certificate 548 that is signed by a certification authority and that contains the client's static public key 544 . The client computer 540 may also store the server's certificate 588. Additionally, client computer 540 may store client payload 552, which may be private data. Certain steps in the message flow diagram 500 of FIG. 5 may be performed similarly to the steps in the message flow diagram 400 of FIG. 4.

[0121] At block 501, client computer 540 may generate a client masking factor. The client masking factor can be randomly generated.

[0122] At step 502, the client computer 540 may determine the client's masked public key using the client's masking factor. The client masking factor and the client masked public key can form an elliptic curve key pair, so that the client masked public key can be used to decrypt data that is encrypted using the client masking factor, and the client masked public key can be used to authenticate a signature. generated by signing data with a client masking factor.

[0123] At step 503, the client computer 540 may determine the first shared secret using the client's masking factor and the server's static public key 584, which may be included in the server's certificate 588. The client computer 540 may determine the first session key using a key derivation function based on the first shared secret.

[0124] At block 504, the client computer 540 can determine the client's signature by signing the client payload 552, the client's masked public key, and the server's static public key 584. The client computer 540 may determine the client's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA). The client signature may be included in the request message from the client computer 540 to ensure that the client computer 540 cannot be denied. Additionally, the client signature is based on a client masking factor that is used only in a given communication session (e.g., in a single request, single response message) . Thus, the signature is only valid for this particular request message. In addition, the client's signature is based on the static public key 584 of the server. Thus, the other computer may not impersonate the recipient of that particular request message.

[0125] In some embodiments, the client's signature may also be based on a seed indicating the novelty (eg, timeliness) of the request message. The seed may also be included in the encrypted client data so that the recipient of the request message can verify that the message is not old based on the value of the seed. The initial value may be, for example, a trusted time or a counter. The server computer 580 may receive its own trusted time or counter value to verify the seed in the request message.

[0126] At step 505, the client computer 540 may encrypt the client payload 552, the client certificate 548, the client's signature, and the client's masked public key using the first shared secret (eg, using the first session key) to determine the client's encrypted data. The client computer may perform encryption, for example, using the Authenticated Associated Data Encryption (AEAD) process. The client payload 552 may contain private client data and/or a request for certain data or information from the server computer 580. After the client payload 552 is encrypted, the client computer 540 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0127] At 506, client computer 540 may send a "request message" containing the client's masked public key and encrypted client data to server computer 580. The client's masked public key may be sent in the clear (eg, unencrypted). The request message may indicate that the client computer 540 is requesting the establishment of a secure communication using a shared secret based on the client's masked public key. The request message may be sent over an insecure network. The server computer 580 may receive a request message from the client computer 540. Since the client's masked public key is used only for this communication session (the client's masking factor is set to zero in step 517), it cannot be used to track the client computer 540. Thus, the request message sent at step 505 is untraceable. Additionally, the challenge message sent at step 505 ensures that the client computer 540 cannot be denied because the client's encrypted data contains the client's signature, which was generated using the client's masking factor. Additionally, the challenge message maintains perfect forward secrecy because there is no data included in the challenge message that can be used to decrypt any data in other messages sent by the client computer 540, past or future. Perfect forward secrecy is maintained because the masked client factor is not provided in the encrypted client data. For example, a client signature is used to authenticate the client computer 540 instead of using a masking factor. However, the client's signature does not contain information that can be used to decrypt messages from the client computer 540, even if the client's static private key 542 and the server's static private key 582 are decrypted.

[0128] At step 507, the server computer 580 may determine the first shared secret using the server's static private key 582 and the client's masked public key that was included in the request message. The first shared secret determined by the server computer in step 506 using the server's static private key 582 and the client's masked public key may be the same as the first shared secret generated by the client computer 540 in step 503 using the client's masking factor and the static public key 584 server. The server computer 580 may also determine the same first session key determined by the client computer 540 using a key derivation function based on the first shared secret.

[0129] At 508, the server computer 580 may decrypt the encrypted client data using the first shared secret (eg, using the first session key) to obtain the client payload 552, the client certificate 548, the client signature, and the client's masked public key. The server computer may perform the decryption, for example, using an Authenticated Associated Data Encryption (AEAD) based decryption process. After decrypting the encrypted client data, the server computer 580 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0130] At step 509, the server computer 580 can verify the client's signature using the client's static public key 544, which is included in the client's certificate 548, client payload 552, the client's masked public key, and the server's static public key 584. The server computer 580 may verify the client's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0131] The server computer 580 may also authenticate the certificate chain related to the client certificate 548. Additionally, the server computer 580 may process the client payload 552 and generate or identify any suitable data or information to include in the server payload 592 to be provided in response to the client computer's request.

[0132] At 510, server computer 580 may generate a server masking factor. The server masking factor may be a randomly generated cryptographic nonce. The server computer 580 may use a server mask to prevent third parties from tracking it, as described herein. For example, server computer 580 may apply a server masking factor to the server's static public key 584 (eg, using a multiplication) to determine the server's masked public key. The server computer 580 may use only the given server mask factor and the given server masked public key in that particular communication session with the client computer 540 (eg, in the request message at step 506 and the response message at step 516) and may generate a different mask factor for subsequent communication sessions. Thus, the identity of the server computer 580 may not be tracked based on the server's masked public key.

[0133] At step 511, the server computer 580 may determine the second shared secret using the server masking factor, the server static private key 582, and the client's masked public key. In some embodiments, the server computer 580 may store multiple static key pairs and it may use a different static key pair to encrypt the response message. The server computer 580 may also determine the second session key using the key derivation function and the second shared secret.

[0134] At 512, the server computer 580 may determine the server's masked public key using the server's mask factor and the server's static public key. For example, server computer 580 may apply a server masking factor to the server's static public key (eg, using a multiplication) to determine the server's masked public key. The server's static public key used to determine the server's masked public key may be part of another static key pair, as discussed above.

[0135] At step 513, the server computer 580 can determine the server's signature by signing the server's certificate, the server's payload 592, the server's masked public key, and the client's static public key 544. The server computer 580 may determine the server's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA). The server signature may be included in the response message from the server computer 580 to ensure that the server computer 580 cannot fail. Additionally, the server signature is based on a masked public key of the server that is used only in a given communication session (for example, in a message with one request and one response ). Thus, the signature is only valid for this particular request message. In addition, the server's signature is based on the static public key 544 of the client. Thus, the other computer may not impersonate the recipient of that particular request message.

[0136] In step 514, the server computer 580 may encrypt the server certificate (corresponding to the static public key of the static key pair used for encryption), the server payload 492, the server signature, and the server's masked public key using a second shared secret (e.g., using second session key) to obtain encrypted server data. The server computer 580 may perform encryption, for example, using an authenticated data encryption (AEAD) process.

[0137] At 515, the server computer 580 may reset the server's masking factor so that it cannot be recovered.

[0138] At 516, server computer 580 may send a response message containing the server's masked public key and encrypted server data to client computer 540. The response message may be sent over an insecure network. The server's disguised public key may be sent in the clear (eg, unencrypted). However, the server's masked public key is based on the server's masking factor, which can only be used in that particular communication session. Accordingly, server computer 580 cannot be tracked by a third party intercepting this message and other messages sent by server computer 580. Client computer 540 can receive a response message.

[0139] At 517, the client computer 540 may determine the second shared secret using the client's masking factor and the server's masked public key that was received in the response message. The second shared secret determined by the client computer 540 in step 517 may be the same as the second shared secret determined by the server computer 580 in step 511 using the client's masked public key, the server's masking factor, and the server's static private key. The client computer 540 may also determine the same second session key (which is also determined by the server computer 580) using a key derivation function and a second shared secret.

[0140] At step 518, after determining the second shared secret and the second session key, the client computer 540 may reset the client masking factor to zero. That is, the client computer 540 may remove the client masking factor so that it cannot be recovered later. In addition, even if the client masking factor was decrypted and received by a third party in a short period of time before it was reset, the third party would not be able to decrypt any other communication using the client masking factor, it was only used to decrypt this particular response message. . Additionally, even if a third party gains access to both of the client computer's static private key and the server computer's static private key, it cannot decrypt the response message without obtaining the client's masking factor, which is set to zero immediately upon receipt of the response message. Thus, perfect forward secrecy is maintained.

[0141] At step 519, the client computer 540 may decrypt the encrypted server data using the second shared secret (e.g., using the second session key) to obtain the server masking factor, the server certificate (corresponding to the static public key of the static key pair used for encryption) , the server payload 592, and the server's masked public key. The client computer 540 may perform the decryption, for example, using an Authenticated Associated Data Encryption (AEAD) decryption process.

[0142] At step 519, the client computer 540 can verify the server using the server's static public key, which is included in the server certificate of the response message, the server payload 592, the server's masked public key, and the server's static public key. The client computer 540 may verify the client's signature, for example, using the Elliptic Curve Digital Signature Algorithm (ECDSA). The client computer 540 may also authenticate the server certificate chain included in the response message.

[0143] At 520, client computer 540 and server computer 580 may end the communication session, or they may continue secure communication using the second session key.

[0144] The message flow of FIG. 5 allows the client computer 540 and the server computer 580 to establish a secure communication using untraceable messages, thereby ensuring confidentiality of the communication and maintaining the privacy of the client computer 540, server computer 580 and their users. Additionally, the client computer 540 cannot discard the request message because it contains the client's signature. The server computer 580 may also choose not to discard the response message because it contains the server's signature. In addition, request and response messages retain perfect forward secrecy because their encryption depends on the client's mask factor and the server's mask factor, which are set to zero as soon as they are no longer needed for the decryption process. Additionally, network and computing resource usage is reduced because the solution is achieved using only one request message and one response message.

C. Secure communication providing perfect forward secrecy and non-repudiation of client and server using two-part private signatures

[0145] FIG. 6 is a diagram 600 of a message flow of a client computer 640 and a server computer 680 establishing a secure and untraceable communication using an encrypted signature part and an unencrypted non-repudiation signature part, in accordance with some embodiments. The encrypted portion of the signature may contain identifying information, while the unencrypted portion of the signature does not contain identifying information. Additionally, the unencrypted portion of the signature may be based on encrypted data. Thus, the signature can be based on encrypted data and at the same time be "untraceable".

[0146] This message flow contains a request message transmitted by the client computer 640 at block 607, which cannot be refused by the client computer 640, and a response message transmitted by the server computer 680 at block 618, which cannot be refused by the server computer 680. The request message at step 607 and the response message at step 618 are untraceable because they contain one-time masked public keys instead of static public keys. In addition, the request and response message maintains perfect forward secrecy. The generation and format of the request and response messages are described in more detail below.

[0147] In this message flow, the client computer 640 may initiate the establishment of a secure communication. Prior to the message flow, the client computer 640 may store a client static key pair 646 containing a client static private key 642 and a client static public key 644. The client computer may also store a client certificate 648 that is signed by a certification authority and that contains the client's static public key 644 . The client computer 640 may also store the server's certificate 688. Additionally, client computer 640 may store client payload data 652, which may be private data.

[0148] At 601, client computer 640 may generate a client masking factor. The client masking factor can be randomly generated.

[0149] At 602, the client computer 640 may determine the client's masked public key using the client's masking factor. The client masking factor and the client masked public key can form an elliptic curve key pair, so that the client masked public key can be used to decrypt data that is encrypted using the client masking factor, and the client masked public key can be used to authenticate a signature. generated by signing data with a client masking factor.

[0150] At step 603, the client computer 640 may determine the first shared secret using the client's masking factor and the server's static public key 684, which may be included in the server's certificate 688. The client computer 640 may determine the first session key using a key derivation function based on the first shared secret.

[0151] At step 604, the client computer 640 may determine the L-signature of the client and a random value of the L-signature of the client using the L-signature algorithm. The L-signature algorithm may be, for example, the ECDSA signature algorithm or the Schnorr signature algorithm.

[0152] At step 605, the client computer 640 may encrypt the client L-signature, the client payload 652, the client certificate 648, and the client's masked public key using the first shared secret (eg, using the first session key) to determine the encrypted client data. The client computer may perform the encryption, for example, using the Authenticated Associated Data Encryption (AEAD) process. Client payload 652 may contain private client data and/or a request for specific data or information from server computer 680. After client payload 652 is encrypted, client computer 640 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0153] At block 606, the client computer 640 may determine the client's R-signature using the R-signature algorithm based on the client's static private key 642, the client's L-signature random value, and the client's encrypted data. Thus, the L-signature is based on the unencrypted client payload 652, while the R-signature is based on the encrypted client data. L-signature of the client and R-signature of the client together form the signature of the client. Both the L-signature and the R-signature are required to authenticate the challenge message. Together, the client L-signature and the client R-signature provide non-repudiation of the request message from the client computer 640. Additionally, the client R-signature is based on encrypted client data that contains a masked client public key used only in a given communication session (for example, in a message with one request and one response). Thus, the client's signature is only valid for this particular request message.

[0154] At 607, client computer 640 may send a request message containing the client's masqueraded public key, client's encrypted data, and client's R-signature to server computer 680. The client's masqueraded public key and client's R-signature may be sent in the clear (for example, , unencrypted). Thus, the R-signature of the client, which is based on the encrypted client data, is sent unencrypted, while the L-signature of the client is included in the encrypted client data. The L-signature of the client may contain portions of the client's signature that can be used to identify the client. Therefore, the client signature can be based on encrypted client data while providing untraceability because the R-signature part is based on the encrypted data, while the L-signature part, which can be used to identify and trace the client computer 640, is included in the encrypted client data.

[0155] The request message may also indicate that the client computer 640 is requesting the establishment of a secure communication using a shared secret based on the client's masked public key. The request message may be sent over an insecure network. Server computer 680 may receive a request message from client computer 640. Since the client's masked public key is used only for this communication session (client's masking factor is set to zero at step 620), it cannot be used to track client computer 640. Thus, the request message sent at step 605 is untraceable. Additionally, the challenge message sent at step 605 ensures that the client computer 640 cannot be denied because the client's encrypted data contains the client's signature, which was generated using the client's masking factor. Additionally, the challenge message maintains perfect forward secrecy because there is no data included in the challenge message that can be used to decrypt any data in other messages sent by the client computer 640, past or future. Perfect forward secrecy is maintained because the masked client factor is not provided in the encrypted client data. For example, a client signature is used to authenticate the client computer 640 instead of using a masking factor. However, the client's signature does not contain information that can be used to decrypt messages from the client computer 640, even if the client's static private key 642 and the server's static private key 682 are decrypted.

[0156] At 608, the server computer 680 may determine the first shared secret using the server's static private key 682 and the client's masked public key that was included in the request message. The first shared secret determined by the server computer in step 606 using the server's static private key 682 and the client's masked public key may be the same as the first shared secret determined by the client computer 640 in step 603 using the client's masking factor and the static public key 684 server. The server computer 680 may also determine the same first session key determined by the client computer 640 using a key derivation function based on the first shared secret.

[0157] At step 609, the server computer 680 may decrypt the encrypted client data using the first shared secret (eg, using the first session key) to obtain the client L-signature, client payload 652, and client certificate 648. The server computer may perform the decryption, for example, using an Authenticated Associated Data Encryption (AEAD) based decryption process. After decrypting the encrypted client data, the server computer 680 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0158] At step 610, the server computer 680 can verify the client's signature, which contains both the client's L-signature and the client's R-signature, using the client's static public key 644 (which is included in the client's certificate 648), the client's L-signature, R-signature of the client and encrypted client data.

[0159] The server computer 680 may also authenticate the certificate chain related to the client certificate 648. Additionally, the server computer 680 can process the client payload 652 and generate or identify any suitable data or information to include in the server payload 692 to be provided in response to the client computer's request.

[0160] At 611, server computer 680 may generate a server masking factor. The server masking factor may be a randomly generated cryptographic nonce. Server computer 680 may use a server mask to prevent third parties from tracking it, as described herein. For example, server computer 680 may apply a server masking factor to the server's static public key 684 (eg, using a multiplication) to determine the server's masked public key. Server computer 680 may use only this server mask factor and this masked server public key in a given communication session with client computer 640 (eg, in a request message and a response message) and may generate a different mask factor for subsequent communication sessions. Thus, the identity of the server computer 680 may not be tracked based on the server's masked public key.

[0161] At step 612, the server computer 680 may determine the second shared secret using the server masking factor, the server static private key 682, and the client's masked public key. In some embodiments, the server computer 680 may store multiple static key pairs and it may use a different static key pair to encrypt the response message. The server computer 680 may also determine the second session key using the key derivation function and the second shared secret.

[0162] At step 613, the server computer 680 may determine the L-signature of the server and a random value of the L-signature of the server using the L-signature algorithm. The L-signature algorithm may be, for example, the ECDSA signature algorithm or the Schnorr signature algorithm.

[0163] In step 615, server computer 680 may encrypt the server L-signature, server payload 692, server certificate, and server public key masked using a second shared secret (eg, using a second session key) to determine encrypted server data. The server computer 680 may perform encryption, for example, using an authenticated data encryption (AEAD) process. The server payload 692 may contain private server data and/or certain data or information in response to a request from the client computer 640. After encryption, the client computer 680 may nullify (eg, completely delete to prevent any recovery) the first shared secret and the first session key.

[0164] At 616, the server computer 640 may determine the server's R-signature using the R-signature algorithm based on the server's static private key 682, the server's L-signature random value, and the server's encrypted data. Thus, the L-signature of the server is based on the unencrypted payload 692 of the server, while the R-signature of the server is based on the encrypted data of the server. The L-signature of the server and the R-signature of the server together form the signature of the server. Both the server L-signature and the server R-signature are required to authenticate the response message from the server computer 680. Together, the server L-signature and the server R-signature provide non-repudiation of the response message from the server computer 680. Additionally, the R-signature server is based on encrypted server data that contains a masked server public key that is used only in a given communication session (for example, in a message with one request and one response). Thus, the server's signature is only valid for this particular request message.

[0165] At step 617, the server computer 680 may reset the server's masking factor so that it cannot be recovered.

[0166] At 618, the server computer 680 may send a response message containing the server's R-signature, the server's masked public key, and the server's encrypted data to the client computer 680. The response message may be sent over an insecure network. The server's obfuscated public key and the server's R-signature may be sent in the clear (eg, unencrypted). However, the server's masked public key is based on the server's masking factor, which can only be used in that particular communication session. Additionally, the server R-signature does not contain information identifying the server computer 680. Instead, any information identifying the server computer 680 is included in the server L-signature, which is included in the encrypted server data. Accordingly, server computer 680 cannot be tracked by a third party intercepting this message and other messages sent by server computer 680. Client computer 640 can receive a response message.

[0167] At 619, the client computer 640 may determine the second shared secret using the client's masking factor and the server's masked public key that was received in the response message. The second shared secret determined by the client computer 640 at block 619 may be the same as the second shared secret determined by the server computer 680 at block 612 using the client's masked public key, the server's masking factor, and the server's static private key. The client computer 640 may also determine the same second session key (which is also determined by the server computer 680) using the key derivation function and the second shared secret.

[0168] At step 620, after determining the second shared secret and the second session key, the client computer 640 may reset the client masking factor to zero. That is, the client computer 640 may remove the client masking factor so that it cannot be recovered later. In addition, even if the client masking factor was decrypted and received by a third party in a short period of time before it was reset, the third party would not be able to decrypt any other communication using the client masking factor, it was only used to decrypt this particular response message. . Additionally, even if a third party gains access to both of the client computer's static private key and the server computer's static private key, it cannot decrypt the response message without obtaining the client's masking factor, which is set to zero immediately upon receipt of the response message. Thus, perfect forward secrecy is maintained.

[0169] In step 621, the client computer 540 may decrypt the encrypted server data using the second shared secret (e.g., using the second session key) to obtain the L-signature of the server, the server masking factor, the server certificate (corresponding to the static public key of the static key pair used for encryption) and server payload 592. The client computer 640 may perform the decryption, for example, using an Authenticated Encrypted Associated Data (AEAD) decryption process.

[0170] At step 622, the client computer 640 can verify the server signature, which contains both the server L-signature and the server R-signature, using the server's static public key (which is included in the client's certificate), the server L-signature, R- server signature and encrypted server data. Because the server's signature, which is based on the server's encrypted data, can be authenticated using the server's static public key, the server computer 680 cannot discard the response message.

[0171] The client computer 640 and server computer 680 may then end the communication session, or they may continue to communicate securely using the second session key.

[0172] The message flow of FIG. 6 allows the client computer 640 and the server computer 680 to establish a secure communication using untraceable messages, thereby ensuring confidentiality of the communication and maintaining the privacy of the client computer 640, server computer 680 and their users. Additionally, the client computer 640 cannot discard the request message because it contains the client's signature. The server computer 680 may also choose not to discard the response message because it contains the server's signature. Additionally, the client's signature and the server's signature are based on their respective encrypted data, not just plaintext, which provides improved security. In addition, the client and server signatures do not contain recognizable information because the L-signature part is encrypted. Thus, the combined L-signature and R-signature constitute a private and anonymous signature. In addition, request and response messages retain perfect forward secrecy because their encryption depends on the client's mask factor and the server's mask factor, which are set to zero as soon as they are no longer needed for the decryption process. Additionally, network and computing resource usage is reduced because the solution is achieved using only one request message and one response message.

VI. METHODS FOR SECURE DATA EXCHANGE

[0173] Methods for establishing secure communication are described below with reference to FIG. 7 and FIG. 8. The message flow patterns described herein may include these methods or part of them.

A. How to Request and Establish Secure Communication

[0174] FIG. 7 is a flowchart 700 of a method performed by a first computer for requesting and establishing secure communications, in accordance with some embodiments. The method may be performed, for example, by client computer 440, client computer 540, or client computer 640 discussed above. Before starting the method, the first computer may store the first static private key of the first computer, the first static public key of the first computer corresponding to the first static private key, and the second static public key of the second computer.

[0175] At 701, the first computer may generate a first masking factor. The first masking coefficient may be generated using a pseudo-random number generator. The first masking factor can be used as a private key based on the elliptic curve.

[0176] At 702, the first computer may determine the first masked public key using the first masking factor. The first masked public key and the first masking factor may form an elliptic curve key pair.

[0177] At 703, the first computer may generate a signature of the first computer by signing the first masked public key using the first static private key. The first computer may also sign the client's private data and the second computer's authentication public key using the first static private key. The first computer may generate a signature using a digital signature algorithm (eg, ECDSA).

[0178] At 704, the first computer may determine the first shared secret using the first masking factor and the second static public key of the second computer. The first shared secret can be used to encrypt the client's private data. The first computer may also determine the session key using the first shared secret.

[0179] At block 705, the first computer may encrypt data of the first computer using the first shared secret. The first computer data may contain the first static public key and the signature of the first computer to obtain encrypted first computer data.

[0180] At block 706, the first computer may send a first message to the second computer containing the first masked public key and encrypted data of the first computer. The second computer generates the first shared secret and then verifies the first computer's signature.

[0181] Using the method of FIG. 7, the first computer may send a message to the second computer, such that the second computer may authenticate the first computer's signature while confirming that the first computer generated the message.

B. How to provide a response to a request to establish a secure communication

[0182] FIG. 8 is a flowchart 800 of a method for providing a response to a request to establish a secure communication, in accordance with some embodiments. The method may be performed, for example, by server computer 480, server computer 580, or server computer 680 discussed above. Before starting the method, the second computer may store the second static private key of the second computer and the second static public key of the second computer corresponding to the second static private key.

[0183] At step 801, the second computer may receive from the first computer a first message containing the first masked public key of the first computer and encrypted data of the first computer. The first message may be generated by the first computer using the method described above with respect to FIG. 7.

[0184] At 802, the second computer may determine the first shared secret using the first masked public key and the second static private key. The second computer may determine the same first shared secret that was determined by the first computer.

[0185] At 803, the second computer may decrypt, using the first shared secret, the encrypted data of the first computer to obtain the first computer data, the first computer data containing the first static public key and the signature of the first computer. The signature of the first computer may be generated by the first computer signing the first masked public key using the first static private key of the first computer. The first static private key may correspond to the first static public key.

[0186] At 804, the second computer may authenticate the signature of the first computer using the first static public key of the first computer and the first masked public key. The second computer may authenticate the first computer's signature using a digital signature algorithm (eg, ECDSA).

[0187] At 805, the second computer may send a second message containing the second computer's second masked public key and the second computer's encrypted data. The second computer data of the second message may be provided in response to the first message.

[0188] Using the method of FIG. 8, the second computer can authenticate the first computer by authenticating the signature of the first computer.

V. DETAILED METHODS FOR SAFE DATA EXCHANGE

[0189] The first computer and the second computer can establish secure communications using untraceable messages that provide non-repudiation and perfect forward secrecy as described herein. Such secure communication may be established by the first and second computers executing the methods by implementing a set of instructions as described below with respect to FIG. 9, 10 and 11. Table 1 below contains some definitions of terms and functions used in FIG. 9, 10, and 11. A portion of all instructions, terms, and functions described with reference to FIG. 9, 10, and 11 may be implemented in the message flows described herein as needed. The instructions, terms, and functions described with reference to FIG. 9, 10 and 11 are illustrative but not exhaustive.

AEAD, AEAD-1 (sk, data, associated data) Algorithm for authenticated encryption by means of associated data (session key SK AES, data (data) to encrypt or decrypt associated data). Linked data may remain as is, but may be checked for integrity. Sign(sk, data), verify(vk, sig, data) Algorithms for signing (sign) and verifying (verify) using a digital signature scheme (signature) (for example, ECDSA). sk is the signing key. vk is the verification key. The signature scheme may also include hashing and hash verification. PrivSign(sk, data) = [sign_L(), sign_R(sk, random, data) ]
PrivVerify(vk, sig_L, Sig_R, data) Algorithms for creating and authenticating "closed" signatures. The signing algorithm consists of two different algorithms: sign_L() and sing_R(). Sign_L() outputs a random value (random) and sig_L. sign_R() takes into account the signing key sk, the random value generated by sig_L, and the signing data, and generates sig_R.
Both sig_L and sig_R are needed for signature verification. Knowing only Sig_R does not provide information about the identity of the signer. Both an ECDSA signature and a Schnorr signature, for example, can be used in this form and have these properties. enc_c Encrypted data generated on the client (IFD/mobile device) enc_s Encrypted data generated on the server (ICC) C_s Certificate chain that authenticates the server (ICC) C_s_{n} Server Authenticating Certificate Chain (ICC) - nth version C_c Certificate chain that authenticates the client (ICC) d_bc Client masking factor d_bs Server masking factor d_c, Q_c = [d_c]P Client authentication public key matching the corresponding private key: d_c d_ec, Q_ec = [d_ec]P The client's short-term public key, which is the same as the short-term private key: d_ec d_s, Q_s = [d_s]P Server Authentication Public Key (ICC) that matches the corresponding private key: d_s d_s_{n}, Q_s_{n} Server Authentication Public and Private Key (ICC), version n. ICC Mobile phone, integrated circuit chip or server ID_s Server ID IFD Interface device or client IV Initialization vector (belongs to [0..q-1]) KDF AES C_MAC based key derivation function 800-56C. Applied on connected inputs PRNG Pseudo-random number generator PubK (C) Extract public key from Cert C q Curve Order Q_bc Disguised client public key Q_bs Disguised server public key SD_c Private customer data (payload) SD_s Private server data (payload) seed A counter or time, etc., available for checking on the ICC or the server and ensuring the novelty of the masking factor. sID_s The server identifier (ICC) for the session. Based on x-coordinate Q_bs(x_coord(Q_bs)) sID_c Client identifier (IFD or mobile device). Truncated x-coordinate Q_ec sk_1_c, sk_c, sk_1_s, sk_s, sk_2_c AES secure messaging session keys Z, Z_1, Z_2 Intermediate shared secrets (x-coordinate of the joint EC-DH result point) zeroize Reset all inputs - values set to all binary zeros.

Table 1

A. Methods of secure communication providing perfect forward secrecy and non-repudiation of the client

[0190] FIG. 9 is a table 900 of steps for performing a computer-implemented method of establishing secure and untraceable communications with perfect forward secrecy between a client computer and a server computer such that the client computer cannot retract its messages, in accordance with some embodiments. The client computer may be, for example, an interface device (IFD). The server computer may be, for example, an integrated circuit chip (ICC) or a mobile device. Some of all the steps in table 900 may be performed in the message flows described herein, such as the message flow of FIG. 4. Additionally, the steps in table 900 may be performed in a different order.

[0191]At the stage 901 client computer can saven-th version of the server computer's public key ("Q_s_{n}"). The client computer may have previously received this particular version of the server computer's public key from the server computer. The client computer can also saven-th version of the server computer certificate ("C_s_{n}") to authenticate the server computer certificate chain. The client computer may also store private client data ("SD_c"). Private client data can be part of the payload sent in the request message to the server computer. The client computer may also store a server identifier ("ID_s") that identifies the server computer. The client computer may also store a client certificate ("C_c") to authenticate the client computer's certificate chain. The client computer may also store a client authentication private key ("d_c") that matches the corresponding client authentication public key ("Q_c") to form an elliptic curve key pair. The client authentication public key ("Q_c") may be determined using a public key ("P") algorithm based on the client's private authentication key (Q_c = [d_c] P). The client computer may also store the seed ("seed"). The initial value may be a trusted time value or a counter value that may be included in the message to indicate the newness or timeliness of the message.

[0192] The server computer may store the nth version of the server authentication public key ("Q_s_{n}") and the corresponding server authentication private key ("d_s_{n}"), which form an elliptic curve key pair. The server computer may determine the server authentication public key using a public key ("P") algorithm based on the server's private authentication key (Q_s_{n} = [d_s_{n}] P). The server computer may also store the nth version of the server certificate ("C_s_{n}") to authenticate the server computer's certificate chain. The server computer may also store private server data ("SD_s") that may be included in the encrypted payload for the client computer. The server computer may also store the following versions of the server authentication public key ("Q_s_{n+1}"), the server authentication private key ("d_s_{n+1}"), and the corresponding certificate ("C_s_{n+1}"). The next version of the server authentication public key ("Q_s_{n+1}") may be a different public key, but it may be signed using the server authentication private key ("d_s_{n}") corresponding to the server authentication public key ("Q_s_ {n}") to continue the chain of certificates.

[0193]At the stage 902, the client computer may generate a client masking factor ("d_bc") using a pseudo-random number generator ("PRNG()#[0..q-1]").

[0194]At the stage 903, the client computer can determine the client's masked public key ("Q_bc") using a public key algorithm ("P") and a client masking factor ("Q_bc = [d_bc]. P").

[0195]At the stage 904, the client computer may determine the first intermediate shared secret ("Z_1"). The first intermediate shared secret may be based on the x-coordinate of the shared Diffie-Hellman elliptic curve result point based on the client masking factor and the server authentication public key (Z_1 = [d_bc] . Q_s_{n}).

[0196]At the stage 905, the client computer can determine the client identifier ("sID_c") for a given session based on the x-coordinate of the elliptic curve of the client's masked public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0197]At the stage 906, the client computer may determine the first session key ("sk_1_c") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the client identifier ("sID_c" ) (sk_1_c=KDF (Z_1 , ID_s, sID_c)).

[0198]At the stage 907, the client computer can determine the client's signature ("sig_c") by signing the stored seed, the client's private data ("SD_c"), the client's masked public key ("Q_bc"), andn-th version of the server computer's public key authentication ("Q_s_{n}") using a digital signature algorithm (e.g. ECDSA) with the client's private authentication key ("d_c") (sig_c=sign(d_c, seed | SD_c | Q_bc | Q_s_{ n})).

[0199]At the stage 908, the client computer may generate encrypted client data ("enc_c") using the first session key ("sk_1_c"). Encryption can be done using Authenticated Encryption Associated Data (AEAD) (enc _c=AEAD (sk_1_c , seed | SD_c | C_c | sig_c | PAD_c, Q_bc). The data encrypted by the client computer may contain the seed value, client private data (" SD_c"), client signature ("sig_c"), and client encryption padding data ("PAD_c"). Client encryption padding data ("PAD_c") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption may also be based on associated data that remains in its original form (for example, it is not encrypted), but is checked for integrity.The associated data may contain a masked public key of the client ("Q_bc").

[0200]At the stage 909, the client computer may reset the first intermediate shared secret ("Z_1") and the first session key ("sk_1_c").

[0201]At the stage 910, the client computer may send a challenge message containing the client's masked public key ("Q_bc") and encrypted client data ("enc_c") to the server computer. Thus, the challenge message is "untraceable" because neither the client's masked public key ("Q_bc") nor the client's encrypted data ("enc_c") can be used to identify or track the client computer. For example, the client authentication public key ("Q_c"), which can be used to identify the client computer (because its certificate chain can be used to authenticate the client computer), is not sent in the clear, but instead in encrypted form. Only the client's masked public key ("Q_bc"), which is based on a randomly generated client masking factor ("d_bc"), is sent in the clear.

[0202]At the stage 911, the server computer can confirm that the client's masked public key ("Q_bc") belongs to the elliptic curve region.

[0203]At the stage 912, the server computer may determine the same first intermediate shared secret ("Z_1") that was determined by the client computer. The server computer can determine the first intermediate shared secret ("Z_1") usingn-th version of the server's private authentication key ("d_s_{n}") and the client's masked public key ("Q_bc") (Z_1 = [d_s_{n}] . Q_bc).

[0204]At the stage 913, the server computer can determine the client identifier ("sID_c") based on the x-coordinate of the elliptic curve of the client's masked public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0205]At the stage 914, the server computer may determine the first session key ("sk_1_s") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the client identifier ("sID_c" ) (sk_1_c=KDF (Z_1 , ID_s, sID_c )).

[0206]At the stage 915, the server computer can decrypt the client's encrypted data ("enc_c") using the first session key ("sk_1_c") and the decryption algorithm (AEAD^-one) to define the seed, client private data ("SD_c"), client signature ("sig_c"), and client encryption padding data ("PAD_c") (seed | SD_c | C_c | sig_c| PAD_c=AEAD-1 ( sk_1_c , enc_c , Q_bc)).

[0207]At the stage 916, the server computer may authenticate the initial value (eg, counter or time) to confirm that the client masking factor is new (eg, the amount of time since the client masking factor was generated does not exceed a certain threshold).

[0208]At the stage 917, the server computer may reset the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1").

[0209]At the stage 918, the server computer can determine the client's authentication public key ("Q_c") by extracting it from the client's certificate ("C_c") (Q_c=PubK(C_c)).

[0210]At the stage 919, the server computer can authenticate the client certificate signature ("C_c") and verify that the client's authentication public key ("Q_c") belongs to the elliptic curve region.

[0211]At the stage 920, the server computer can authenticate the client's signature ("sig_c") with the client's authentication public key ("Q_c") using a digital signature algorithm (e.g., ECDSA), and a seed, the client's private data ("SD_c"), masked client key ("Q_bc"), as well asn-th version of the server computer authentication public key ("Q_s_{n}") (verify(Q_c, sig_c, seed | SD_c |Q_bc | Q_s_{n})). The client signature ("sig_c") provides non-repudiation of the client computer because it can be authenticated using the client's public authentication key ("Q_c"), while providing the computer with access to the client's private authentication key ("d_c") (for example, the client computer and while maintaining security only to the client computer). Additionally, the client's signature ("sig_c") is generated by signing the client's private data ("SD_c"), the client's masked public key ("Q_bc"), andn-th version of the server computer's public key ("Q_s_{n}"). Therefore, the client signature ("sig_c") not only ensures that the client computer cannot fail, but also restricts the signature to that particular session with that server computer. Accordingly, another computer cannot pretend to be the recipient of this message.

[0212]At the stage 921 The server computer can generate a server masking factor ("d_bs") using a pseudo-random number generator (d_bs=PRNG () # [0..q-1]).

[0213]At the stage 922, the server computer may determine a second intermediate shared secret ("Z") using the server's masking factor ("d_bs"), the next version of the server's private authentication key ("d_s_{n+1}"), and the client's masked public key ("Q_bc ”) (Z = [d_bs . d_s_{n+1}] Q_bc).

[0214]At the stage 923, the server computer can determine the server's masked public key ("Q_bs") using the server's masking factor ("d_bs") and the next version (n+1) server computer authentication public key ("Q_s_{n+1}") (Q_bs = [d_bs] . Q_s_{n+1}).

[0215]At the stage 924, the server computer can determine the server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0216]At the stage 925, the server computer can determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session, and the client identifier (" sID_c") for this session (sk_s | sk_c=KDF ( Z, sID_s, sID_c)). Second session keys ("sk_s | sk_c") can be used to encrypt future messages sent between client and server to use different encryption keys in each direction (eg, client to server and server to client).

[0217]At the stage 926, the server computer may generate encrypted server data ("enc_s") using a second session key ("sk_s"). Encryption can be performed using Authenticated Encryption Associated Data (AEAD) (enc_s=AEAD ( sk_s , d_bs | C_s_{n+1} | SD_s | PAD_s, Q_bs)). Data encrypted by the server computer may contain a server masking factor ("d_bs"), the following version (n+1) server certificate ("C_s_{n+1}"), which is associated with the next version (n+1) server computer authentication public key ("Q_s_{n+1}"), server private data ("SD_s") (eg, server payload in response to a client request), and server encryption padding data ("PAD_s"). Server encryption padding data ("PAD_s") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption can also be based on associated data that remains intact (for example, it is not encrypted) but is checked for integrity. The associated data may contain a locked server public key ("Q_bs").

[0218]At the stage 927, the server computer may reset the second session key ("sk_s"), the second intermediate shared secret ("Z"), and the server masking factor ("d_bs"). By zeroing out the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1") in step 917 and then zeroing out the second session key ("sk_s"), the second intermediate shared secret ("Z") and the masking factor server ("d_bs") at step 928, the server computer maintains perfect forward secrecy. Perfect forward secrecy is maintained because any data that could potentially be used to break the encryption of the response message (eg, sk_s, Z, d_bs, sk_1_c, and Z_1) is removed. For example, the data remaining on the server computer, such as the server's static private authentication key (d_s) and the server's static public authentication key (Q_s), were not used in encrypting the server's encrypted data (enc_s).

[0219]At the stage 928, the server computer may send a response message containing the server's masked public key ("Q_bs") and encrypted server data ("enc_s") to the client computer. Thus, the response message is "untraceable" because neither the server's masked public key ("Q_bs") nor the server's encrypted data ("enc_s") can be used to identify or track the server computer. For example, the static server authentication public key ("Q_s"), which can be used to identify the server computer (because its certificate chain can be used to authenticate the server computer), is not sent in the clear, but instead in encrypted form. Only the server's masked public key ("Q_bs"), which is based on a randomly generated server masking factor ("d_bs"), is sent in the clear.

[0220]At the stage 929, the client computer can confirm that the server's masked public key ("Q_bs") belongs to the elliptic curve region.

[0221]At the stage 930, the client computer may determine a second intermediate shared secret ("Z") using the client's masking factor ("d_bc") and the server's masked public key ("Q_bs") (Z = [d_bc]. Q_bs).

[0222]At the stage 931, the client computer can determine the server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0223]At the stage 932, the client computer can determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session, and the client identifier (" sID_c") for this session (sk_s | sk_c=KDF (Z, sID_s, sID_c)).

[0224]At the stage 933, the client computer may reset the second intermediate shared secret ("Z") and the client masking factor ("d_bc") to zero.

[0225]At the stage 934, the client computer can decrypt the server's encrypted data ("enc_s") using the first session key ("sk_s") and the decryption algorithm (AEAD^-one) to determine the server masking factor ("d_bs"), the next version of the server certificate ("C_s_{n+1}"), server private data ("SD_s"), and server encryption padding data ("PAD_s"). The server's masked public key ("Q_bs") can be used as additional data in the decryption algorithm.

[0226]At the stage 935, the client computer can determine the next version of the server's public key ("Q_s_{n+1}") by extracting it from the next version of the server's certificate ("C_s_{n+1}") (Q_s_{n+1} = PubK(C_s_{ n+1}).

[0227]At the stage 936, the client computer may authenticate the server's certificate signature ("C_s_{n+1}") and may verify that the server's public key ("Q_s_{n+1}") belongs to the elliptic curve region.

[0228]At the stage 937, the client computer may authenticate the masqueraded server public key ("Q_bs") received in the response message by determining the masqueraded server public key ("Q_bs") using the server masking factor ("d_bs") and the server public key ("Q_s_ {n+1}"). Authentication of the server's masked public key ("Q_bs") may not, by itself, provide non-repudiation. Non-repudiation can be provided using signatures as discussed above.

[0229]At the stage 938, the client computer can reset the server masking factor ("d_bs") to zero.

[0230] Using the method shown in Table 900, the client computer and the server computer can establish a secure communication using only two untraceable messages, which can make the client computer fail-safe and maintain perfect forward secrecy.

B. A method of secure communication that provides perfect forward secrecy and non-repudiation of the client and server

[0231] FIG. 10 is a table 1000 of the execution steps of a computer-implemented method for establishing secure and untraceable communications with perfect forward secrecy between a client computer and a server computer such that the client computer and server computer cannot relinquish their messages, in accordance with some embodiments. The client computer may be, for example, an interface device (IFD). The server computer may be, for example, an integrated circuit chip (ICC) or a mobile device. Some of all the steps in table 1000 may be performed in the message flows described herein, such as the message flow of FIG. 5. Additionally, the steps in table 1000 may be performed in a different order.

[0232] In step 1001, the client computer may store the nth version of the server computer's authentication public key ("Q_s_{n}"). The client computer may have previously received this particular version of the server computer's public key from the server computer. The client computer may also store the nth version of the server computer's certificate ("C_s_{n}") to authenticate the server computer's certificate chain. The client computer may also store private client data ("SD_c"). Private client data can be part of the payload sent in the request message to the server computer. The client computer may also store a server identifier ("ID_s") that identifies the server computer. The client computer may also store a client certificate ("C_c") to authenticate the client computer's certificate chain. The client computer may also store a client authentication private key ("d_c") that matches the corresponding client authentication public key ("Q_c") to form an elliptic curve key pair. The client authentication public key ("Q_c") may be determined using a public key ("P") algorithm based on the client's private authentication key (Q_c = [d_c] P). The client computer may also store the seed ("seed"). The initial value may be a trusted time value or a counter value that may be included in the message to indicate the newness or timeliness of the message.

[0233] The server computer may store the nth version of the server authentication public key ("Q_s_{n}") and the corresponding server authentication private key ("d_s_{n}"), which form an elliptic curve key pair. The server computer may determine the server authentication public key using a public key ("P") algorithm based on the server's private authentication key (Q_s_{n} = [d_s_{n}] P). The server computer may also store the nth version of the server certificate ("C_s_{n}") to authenticate the server computer's certificate chain. The server computer may also store private server data ("SD_s") that may be included in the encrypted payload for the client computer. The server computer may also store the following versions of the server authentication public key ("Q_s_{n+1}"), the server authentication private key ("d_s_{n+1}"), and the corresponding certificate ("C_s_{n+1}").

[0234] At 1002, the client computer may generate a client masking factor ("d_bc") using a pseudo-random number generator ("PRNG () # [0..q-1]").

[0235] At 1003, the client computer may determine the client's masked public key ("Q_bc") using a public key algorithm ("P") and a client masking factor ("Q_bc = [d_bc]. P").

[0236] At 1004, the client computer may determine a first intermediate shared secret ("Z_1"). The first intermediate shared secret may be based on the x-coordinate of the shared Diffie-Hellman elliptic curve result point based on the client masking factor and the server authentication public key (Z_1 = [d_bc] . Q_s_{n}).

[0237] At 1005, the client computer may determine a client identifier ("sID_c") for a given session based on the x-coordinate of the elliptic curve of the client's masked public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0238] In step 1006, the client computer may determine the first session key ("sk_1_c") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the identifier client ("sID_c") (sk_1_c=KDF (Z_1 , ID_s, sID_c)).

[0239] In step 1007, the client computer may determine the client's signature ("sig_c") by signing the stored seed, the client's private data ("SD_c"), the client's masked public key ("Q_bc"), and the nth version of the server's authentication public key. computer ("Q_s_{n}") using a digital signature algorithm (for example, ECDSA) and through the client's private authentication key ("d_c") (sig_c=sign(d_c, seed | SD_c | Q_bc | Q_s_{n})).

[0240] At 1008, the client computer may generate encrypted client data ("enc_c") using the first session key ("sk_1_c"). Encryption can be performed using Authenticated Encryption Associated Data (AEAD) (enc_c=AEAD(sk_1_c , seed | SD_c | C_c | sig_c | PAD_c, Q_bc)). The data encrypted by the client computer may include a seed, client private data ("SD_c"), client signature ("sig_c"), and client encryption padding data ("PAD_c"). The padding client encryption data ("PAD_c") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption can also be based on associated data that remains intact (for example, it is not encrypted) but is checked for integrity. The associated data may contain a masked public key of the client ("Q_bc").

[0241] At 1009, the client computer may reset the first intermediate shared secret ("Z_1") and the first session key ("sk_1_c").

[0242] At 1010, the client computer may send a challenge message containing the client's masked public key ("Q_bc") and encrypted client data ("enc_c") to the server computer. Thus, the challenge message is "untraceable" because neither the client's masked public key ("Q_bc") nor the client's encrypted data ("enc_c") can be used to identify or track the client computer. For example, the client authentication public key ("Q_c"), which can be used to identify the client computer (because its certificate chain can be used to authenticate it), is not sent in the clear, but instead in encrypted form. Only the client's masked public key ("Q_bc"), which is based on a randomly generated client masking factor ("d_c"), is sent in the clear.

[0243] At 1011, the server computer may confirm that the client's masked public key ("Q_bc") belongs to the elliptic curve region.

[0244] At 1012, the server computer may determine the same first intermediate shared secret ("Z_1") that was determined by the client computer. The server computer can determine the first intermediate shared secret ("Z_1") using the nth version of the server's private authentication key ("d_s_{n}") and the client's masked public key ("Q_bc") (Z_1 = [d_s_{n} ] .Q_bc).

[0245] In step 1013, the server computer may determine the client identifier ("sID_c") based on the x-coordinate of the elliptic curve of the masked client public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0246] In step 1014, the server computer may determine the first session key ("sk_1_s") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the identifier client ("sID_c") (sk_1_c=KDF (Z_1 , ID_s, sID_c )).

[0247] In step 1015, the server computer may decrypt the encrypted client data ("enc_c") using the first session key ("sk_1_c") and the decryption algorithm (AEAD ^-1 ) to determine the initial value, the private client data ("SD_c"), client signature ("sig_c") and client encryption padding data ("PAD_c") (seed | SD_c | C_c | sig_c| PAD_c=AEAD-1 (sk_1_c , enc_c, Q_bc)).

[0248] At 1016, the server computer may authenticate the seed value (e.g., counter or time) to confirm that the client masking factor is new (e.g., the amount of time since the client masking factor was generated does not exceed a certain threshold meaning).

[0249] At 1017, the server computer may reset the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1").

[0250] At 1018, the server computer may determine the client authentication public key ("Q_c") by extracting it from the client certificate ("C_c") (Q_c=PubK(C_c)).

[0251] In step 1019, the server computer may authenticate the client certificate signature ("C_c") and verify that the client authentication public key ("Q_c") belongs to the elliptic curve region.

[0252] At 1020, the server computer may authenticate the client's signature ("sig_c") with the client's public authentication key ("Q_c") using a digital signature algorithm (eg, ECDSA), and an initial value, the client's private data ("SD_c ”), a masked client public key (“Q_bc”), and the nth version of the server computer’s public authentication key (“Q_s_{n}”) (verify(Q_c, sig_c, seed | SD_c |Q_bc | Q_s_{n}) ). The client signature ("sig_c") provides non-repudiation of the client computer because it can be authenticated using the client's public authentication key ("Q_c"), while providing the computer with access to the client's private authentication key ("d_c") (for example, the client computer and while maintaining security only to the client computer). Additionally, the client's signature ("sig_c") is generated by signing the client's private data ("SD_c"), the client's masked public key ("Q_bc"), and the nth version of the server computer's authentication public key ("Q_s_{n}"). Therefore, the client signature ("sig_c") not only ensures that the client computer cannot fail, but also restricts the signature to that particular session with that server computer. Accordingly, another computer cannot pretend to be the recipient of this message.

[0253] In step 1021, the server computer may generate a server masking factor ("d_bs") using a pseudo-random number generator (d_bs=PRNG () # [0..q-1]).

[0254] At 1022, the server computer may determine a second intermediate shared secret ("Z") using a server masking factor ("d_bs"), a next version of the server's private authentication key ("d_s_{n+1}"), and a masked public client key ("Q_bc") (Z = [d_bs . d_s_{n+1}] Q_bc).

[0255] In step 1023, the server computer may determine the server computer's masked public key ("Q_bs") using the server's masking factor ("d_bs") and the next version ( n +1) of the server computer's authentication public key ("Q_s_{n+1} ”) (Q_bs = [d_bs] . Q_s_{n+1}).

[0256] At 1024, the server computer may determine a server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0257] In step 1025, the server computer may determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session and the client identifier ("sID_c") for this session (sk_s | sk_c=KDF ( Z, sID_s, sID_c)).

[0258] In step 1026, the server computer may determine the server's signature ("sig_s") by signing the next version ( n +1) of the server computer's certificate ("C_s_{n+1}"), server private data ("SD_s") (e.g. , payload), a masked server public key ("Q_bs"), and a client authentication public key ("Q_c") using a digital signature algorithm (e.g., ECDSA) via the server's private authentication key ("d_s") (sig_s=sign (d_s , C_s_{n+1} | SD_s | Q_bs | Q_c)).

[0259] At 1027, the server computer may generate encrypted server data ("enc_s") using a second session key ("sk_s"). Encryption can be performed using Authenticated Encryption Associated Data (AEAD) (enc_s=AEAD (sk_s , d_bs | C_s_{n+1} | SD_s | PAD_s, Q_bs)). Data encrypted by the server computer may contain the next version ( n +1) of the server certificate ("C_s_{n+1}"), which is associated with the next version ( n +1) of the server computer's public authentication key ("Q_s_{n+1 }"), server private data ("SD_s") (eg, server payload in response to a client request), server signature ("sig_s"), and server encryption padding data ("PAD_s"). The padding server encryption data ("PAD_s") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption can also be based on associated data that remains intact (for example, it is not encrypted) but is checked for integrity. The associated data may contain a locked server public key ("Q_bs").

[0260] At 1028, the server computer may reset the second session key ("sk_s"), the second intermediate shared secret ("Z"), and the server masking factor ("d_bs"). By zeroing out the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1") in step 1017 and then zeroing out the second session key ("sk_s"), the second intermediate shared secret ("Z") and the masking factor server ("d_bs") at 1028, the server computer maintains perfect forward secrecy. Perfect forward secrecy is maintained because any data that could potentially be used to break the encryption of the response message (eg, sk_s, Z, d_bs, sk_1_c, and Z_1) is removed. For example, the data remaining on the server computer, such as the server's static private authentication key (d_s) and the server's static public authentication key (Q_s), were not used in encrypting the server's encrypted data (enc_s).

[0261] At 1029, the server computer may send a response message containing the server's masked public key ("Q_bs") and encrypted server data ("enc_s") to the client computer. Thus, the response message is "untraceable" because neither the server's masked public key ("Q_bs") nor the server's encrypted data ("enc_s") can be used to identify or track the server computer. For example, the static server authentication public key ("Q_s"), which can be used to identify the server computer (because its certificate chain can be used to authenticate the server computer), is not sent in the clear, but instead in encrypted form. Only the server's masked public key ("Q_bs"), which is based on a randomly generated server masking factor ("d_bs"), is sent in the clear.

[0262] At 1030, the client computer may confirm that the server's masked public key ("Q_bs") belongs to the elliptic curve region.

[0263] At 1031, the client computer may determine a second intermediate shared secret ("Z") using the client's masking factor ("d_bc") and the server's masked public key ("Q_bs") (Z = [d_bc]. Q_bs).

[0264] At 1032, the client computer may determine the server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0265] In step 1033, the client computer may determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session and the client identifier ("sID_c") for this session (sk_s | sk_c=KDF ( Z, sID_s, sID_c)).

[0266] At 1034, the client computer may reset the second intermediate shared secret ("Z") and the client masking factor ("d_bc") to zero.

[0267] In step 1035, the client computer may decrypt the encrypted server data ("enc_s") using the first session key ("sk_s") and the decryption algorithm (AEAD ^-1 ) to determine the next server certificate version ("C_s_{n+1} ”), server private data (“SD_s”), server signature (“sig_s”), and server encryption padding data (“PAD_s”). The server's masked public key ("Q_bs") can be used as additional data in the decryption algorithm.

[0268] At 1036, the client computer may determine the next version of the server's public key ("Q_s_{n+1}") by extracting it from the next version of the server's certificate ("C_s_{n+1}") (Q_s_{n+1} = PubK(C_s_{n+1}).

[0269] At 1037, the client computer may authenticate the server's certificate signature ("C_s_{n+1}") and may verify that the server's public key ("Q_s_{n+1}") belongs to the elliptic curve region.

[0270] At 1038, the client computer may authenticate the server's signature ("sig_s") with the server's public authentication key ("Q_s") using a digital signature algorithm (eg, ECDSA), and the next version of the server's certificate ("C_s_{n +1}"), server private data ("SD_s"), server public key masked ("Q_bs"), and client public key ("Q_c") (verify(Q_s, sig_s, C_s_{n+1} | SD_s | Q_bs | Q_c)). The server signature ("sig_s") ensures that the server computer cannot be denied because it can be authenticated using the server's public authentication key ("Q_s") while providing the computer with access to the server's private authentication key ("d_s") (for example, the server computer and while maintaining security only to the server computer). Additionally, the server signature ("sig_s") is generated by signing the server's private data ("SD_s"), the server's masked public key ("Q_bs"), and the client's authentication public key ("Q_c"). Therefore, the server signature ("sig_s") not only ensures that the server computer cannot fail, but also restricts the signature to that particular session with that client computer. Accordingly, another computer cannot pretend to be the recipient of this message.

[0271] Using the method shown in Table 1000, the client computer and the server computer can establish a secure communication using only two untraceable messages, which can ensure that the client computer and server computer cannot fail at the same time while maintaining perfect forward secrecy.

C. A method of secure communication that provides perfect forward secrecy and non-repudiation of client and server using two-part private signatures

[0272] FIG. 11 is a table 1100 of steps in a computer-implemented method for establishing a secure and untraceable communication using an encrypted signature portion and an unencrypted signature portion, in accordance with some embodiments. The client computer may be, for example, an interface device (IFD). The server computer may be, for example, an integrated circuit chip (ICC) or a mobile device. Some of all the steps in table 1100 may be performed in the message flows described herein, such as the message flow of FIG. 6. Additionally, the steps in table 1100 may be performed in a different order.

[0273]At the stage 1101 client computer can saven-th version of the server computer's public key ("Q_s_{n}"). The client computer may have previously received this particular version of the server computer's public key from the server computer. The client computer can also saven-th version of the server computer certificate ("C_s_{n}") to authenticate the server computer certificate chain. The client computer may also store private client data ("SD_c"). Private client data can be part of the payload sent in the request message to the server computer. The client computer may also store a server identifier ("ID_s") that identifies the server computer. The client computer may also store a client certificate ("C_c") to authenticate the client computer's certificate chain. The client computer may also store a private client authentication key ("d_c") that matches a corresponding client authentication public key ("Q_c") to form an elliptic curve key pair. The client authentication public key ("Q_c") may be determined using a public key ("P") algorithm based on the client's private authentication key (Q_c = [d_c] P). The client computer may also store the seed ("seed"). The initial value may be a trusted time value or a counter value that may be included in the message to indicate the newness or timeliness of the message.

[0274] The server computer may store the nth version of the server authentication public key ("Q_s_{n}") and the corresponding server authentication private key ("d_s_{n}"), which form an elliptic curve key pair. The server computer may determine the server authentication public key using a public key ("P") algorithm based on the server's private authentication key (Q_s_{n} = [d_s_{n}] P). The server computer may also store the nth version of the server certificate ("C_s_{n}") to authenticate the server computer's certificate chain. The server computer may also store private server data ("SD_s") that may be included in the encrypted payload for the client computer. The server computer may also store the following versions of the server authentication public key ("Q_s_{n+1}"), the server authentication private key ("d_s_{n+1}"), and the corresponding certificate ("C_s_{n+1}").

[0275]At the stage 1102, the client computer may generate a client masking factor ("d_bc") using a pseudo-random number generator ("PRNG()#[0..q-1]").

[0276]At the stage 1103, the client computer may determine the client's masked public key ("Q_bc") using a public key algorithm ("P") and a client masking factor ("Q_bc = [d_bc]. P").

[0277]At the stage 1104, the client computer may determine a first intermediate shared secret ("Z_1"). The first intermediate shared secret may be based on the x-coordinate of the shared Diffie-Hellman elliptic curve result point based on the client masking factor and the server authentication public key ( Z_1 = [d_bc] . Q_s_{n}).

[0278]At the stage 1105, the client computer may determine the client identifier ("sID_c") for a given session based on the x-coordinate of the elliptic curve of the client's masked public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0279]At the stage 1106 the client computer may determine the first session key ("sk_1_c") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the client identifier ("sID_c" ) (sk_1_c=KDF (Z_1 , ID_s, sID_c)).

[0280]The client computer can determine the client's signature using an anonymous signing algorithm that includes an L-signature ("Sign_L()") algorithm and an R-signature ("Sign_R()") algorithm. At the stage 1107, the client computer may determine the L-signature ("sigc_L") and the client's signature random value ("rand_c") using the L-signature algorithm ("Sign_L()").

[0281]At the stage 1108, the client computer may generate encrypted client data ("enc_c") using the first session key ("sk_1_c"). Encryption can be performed using Authenticated Encryption Associated Data (AEAD) (enc _c=AEAD (sk_1_c , seed | SD_c | C_c | sigc_L | PAD_c, Q_bc)). The data encrypted by the client computer may include a seed, client private data ("SD_c"), client certificate ("C_c"), client L-signature ("sigc_L"), and client encryption padding data ("PAD_c"). The padding client encryption data ("PAD_c") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption can also be based on associated data that remains intact (for example, it is not encrypted) but is checked for integrity. The associated data may contain a masked public key of the client ("Q_bc").

[0282]At the stage 1109, the client computer can determine the client's R-signature ("sigc_R") using the R-signature algorithm ("Sign_R()"), as well as the client's private authentication key ("d_c"), the client's signature random value ("rand_c") ( based on the L-signature algorithm) and encrypted client data ("enc_c"). Thus, the R-signature of the client is based on the encrypted client data, while the L-signature of the client is included in the encrypted client data.

[0283]At the stage 1110, the client computer may reset the first intermediate shared secret ("Z_1") and the first session key ("sk_1_c").

[0284]At the stage 1111, the client computer may send a challenge message containing the client's masked public key ("Q_bc"), the client's R-signature ("sigc_r"), and the client's encrypted data ("enc_c") to the server computer. Thus, the challenge message is "untraceable" because neither the client's masked public key ("Q_bc"), nor the client's R-signature, nor the client's encrypted data ("enc_c") can be used to identify or track the client computer. For example, the client authentication public key ("Q_c") and the client's L-signature ("sigc_L"), which can be used to identify the client computer, are not sent in the clear, but instead in encrypted form.

[0285]At the stage 1112, the server computer can confirm that the client's masked public key ("Q_bc") belongs to the elliptic curve region.

[0286]At the stage 1113, the server computer may determine the same first intermediate shared secret ("Z_1") that was determined by the client computer. The server computer can determine the first intermediate shared secret ("Z_1") usingn-th version of the server's private authentication key ("d_s_{n}") and the client's masked public key ("Q_bc") (Z_1 = [d_s_{n}] . Q_bc).

[0287]At the stage 1114, the server computer may determine the client identifier ("sID_c") based on the x-coordinate of the elliptic curve of the client's masked public key (sID_c=x-coord ( Q_bc )). The client identifier ("sID_c") may be a truncated x-coordinate of the client's public encryption key.

[0288]At the stage 1115 The server computer may determine the first session key ("sk_1_c") using a key derivation function ("KDF") based on the first intermediate shared secret ("Z_1"), the server identifier ("ID_s"), and the client identifier ("sID_c" ) (sk_1_c=KDF (Z_1 , ID_s, sID_c )).

[0289]At the stage 1116 The server computer can decrypt encrypted client data ("enc_c") using the first session key ("sk_1_c") and the decryption algorithm (AEAD^-one) to define the seed, client private data ("SD_c"), client signature ("sig_c"), and client encryption padding data ("PAD_c") (seed | SD_c | C_c | sig_c| PAD_c=AEAD-1 ( sk_1_c , enc_c , Q_bc)).

[0290]At the stage 1117, the server computer may authenticate the initial value (eg, counter or time) to confirm that the client masking factor is new (eg, the amount of time since the client masking factor was generated does not exceed a certain threshold).

[0291]At the stage 1118, the server computer may reset the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1").

[0292]At the stage 1119, the server computer can determine the client authentication public key ("Q_c") by extracting it from the client certificate ("C_c") (Q_c=PubK(C_c)).

[0293]At the stage 1120, the server computer can authenticate the client certificate signature ("C_c") and verify that the client's authentication public key ("Q_c") belongs to the elliptic curve region.

[0294]At the stage 1121 The server computer can authenticate a client signature that contains both the L-signature of the client ("sigc_L") and the R-signature of the client ("sigc_R") with the client's public authentication key ("Q_c") using a "private" algorithm digital signature based on encrypted client data ("enc_c"). A "closed" digital signature algorithm can be closed in the sense that this algorithm contains two different algorithms, where one algorithm creates an R-signature based on encrypted data that does not contain identifying information, and the other algorithm creates an L-signature that contains identifying information. , which can be encrypted. The client signature ("sigc_L" and "sigc_R" together) provides non-repudiation of the client computer because it can be authenticated using the client's public authentication key ("Q_c") while still providing the computer with access to the client's private authentication key ("d_c" ) (for example, the client computer, and while maintaining security, only the client computer). Additionally, the R-signature of the client is generated by signing the encrypted client data itself ("enc_c"). Additionally, the R-signature of the client does not contain identifying information. Therefore, the client signature not only ensures that the client computer cannot fail, but is "untraceable", while at the same time this signature is limited to this particular session with this server computer. Accordingly, another computer cannot pretend to be the recipient of this message.

[0295]At the stage 1122, the server computer may generate a server masking factor ("d_bs") using a pseudo-random number generator (d_bs=PRNG () # [0..q-1]).

[0296]At the stage 1123, the server computer may determine a second intermediate shared secret ("Z") using the server's masking factor ("d_bs"), the next version of the server's private authentication key ("d_s_{n+1}"), and the client's masked public key ("Q_bc ”) (Z = [d_bs . d_s_{n+1}] Q_bc).

[0297]At the stage 1124 The server computer can determine the server's masked public key ("Q_bs") using the server's masking factor ("d_bs") and the next version (n+1) server computer authentication public key ("Q_s_{n+1}") (Q_bs = [d_bs] . Q_s_{n+1}).

[0298]At the stage 1125, the server computer can determine the server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0299]At the stage 1126, the server computer may determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session, and the client identifier (" sID_c") for this session (sk_s | sk_c=KDF ( Z, sID_s, sID_c)).

[0300]The server computer can determine the signature of the server using an anonymous signing algorithm that contains an L-signature algorithm ("Sign_L()") and an R-signature algorithm ("Sign_R()"). At the stage 1127, the server computer can determine the L-signature ("sigc_L") and the random value of the server's signature ("rand_s") using the L-signature algorithm ("Sign_L()").

[0301]At the stage 1128, the server computer may generate encrypted server data ("enc_s") using a second session key ("sk_s"). Encryption can be performed using Authenticated Encryption Associated Data (AEAD) (enc_s=AEAD ( sk_s, C_s_{n+1} | SD_s | sigs_L | PAD_s, Q_bs)). Data encrypted by the server computer may include a server certificate ("C_s_{n+1}"), server private data ("SD_s"), server L-signature ("sigs_L"), and server encryption padding data ("PAD_s"). Server encryption padding data ("PAD_s") may add an appropriate length to the encrypted data based on the encryption algorithm used. Encryption can also be based on associated data that remains intact (for example, it is not encrypted) but is checked for integrity. The associated data may contain a locked server public key ("Q_bs").

[0302]At the stage 1129, the server computer can determine the server's R-signature ("sigs_R") using the R-signature algorithm ("Sign_R()"), as well as the server's private authentication key ("d_s"), the server's signature random value ("rand_s") ( based on the L-signature algorithm) and encrypted server data ("enc_s"). Thus, the server's R-signature is based on the server's encrypted data, while the server's L-signature is included in the server's encrypted data.

[0303]At the stage 1130, the server computer may reset the second session key ("sk_s"), the second intermediate shared secret ("Z"), and the server masking factor ("d_bs"). By zeroing out the first session key ("sk_1_c") and the first intermediate shared secret ("Z_1") in step 1017 and then zeroing out the second session key ("sk_s"), the second intermediate shared secret ("Z") and the masking factor server ("d_bs") at step 1028, the server computer maintains perfect forward secrecy. Perfect forward secrecy is maintained because any data that could potentially be used to break the encryption of the response message (eg, sk_s, Z, d_bs, sk_1_c, and Z_1) is removed. For example, the data remaining on the server computer, such as the server's static private authentication key (d_s) and the server's static public authentication key (Q_s), were not used in encrypting the server's encrypted data (enc_s).

[0304]At the stage 1131, the server computer may send a response message containing the server's masked public key ("Q_bs"), the server's R signature ("sigc_R"), and the server's encrypted data ("enc_s") to the client computer. Thus, the response message is "untraceable" because neither the server's masked public key ("Q_bs") nor the server's R-signature ("sigc_R") nor the server's encrypted data ("enc_s") can be used to identify or server computer tracking. For example, a static server authentication public key ("Q_s") that can be used to identify a server computer is not sent in the clear, but instead in encrypted form.

[0305]At the stage 1132, the client computer can confirm that the server's masked public key ("Q_bs") belongs to the elliptic curve region.

[0306]At the stage 1133, the client computer may determine a second intermediate shared secret ("Z") using the client's masking factor ("d_bc") and the server's masked public key ("Q_bs") (Z = [d_bc]. Q_bs).

[0307]At the stage 1134, the client computer can determine the server identifier for a given communication session ("sID_s") using the server's masked public key ("Q_bs"). The server identifier ("sID_s") may be based on the x-coordinate of the elliptic curve of the server's masked public key ("Q_bs") (sID_s=x-coord (Q_bs)).

[0308]At the stage 1135, the client computer can determine the second session key ("sk_s | sk_c") using a key derivation function based on the second intermediate shared secret ("Z"), the server identifier ("sID_s") for the given communication session, and the client identifier (" sID_c") for this session (sk_s | sk_c=KDF ( Z, sID_s, sID_c)).

[0309]At the stage 1136, the client computer may reset the second intermediate shared secret ("Z") and client masking factor ("d_bc") to zero.

[0310]At the stage 1137 The client computer can decrypt the server's encrypted data ("enc_s") using the first session key ("sk_s") and the decryption algorithm (AEAD^-one) to determine the next version of the server certificate ("C_s_{n+1}"), server private data ("SD_s"), server L-signature ("sigs_L"), and server encryption padding data ("PAD_s"). The server's masked public key ("Q_bs") can be used as additional data in the decryption algorithm.

[0311]At the stage 1138 the client computer can determine the next version of the server's public key ("Q_s_{n+1}") by extracting it from the next version of the server's certificate ("C_s_{n+1}") (Q_s_{n+1} = PubK(C_s_{ n+1}).

[0312]At the stage 1139, the client computer may authenticate the server certificate signature ("C_s_{n+1}") and may verify that the server's public key ("Q_s_{n+1}") belongs to the elliptic curve region.

[0313]At the stage 1140, a client computer can authenticate a server signature that contains both a server L-signature ("sigs_L") and a server R-signature ("sigs_R") with a server authentication public key ("Q_s") using a "private" algorithm. digital signature based on encrypted server data ("enc_s"). A "closed" digital signature algorithm can be closed in the sense that this algorithm contains two different algorithms, where one algorithm creates an R-signature based on encrypted data that does not contain identifying information, and the other algorithm creates an L-signature that contains identifying information. , which can be encrypted. The server signature ("sigc_L" and "sigc_R" together) ensures that the server computer cannot fail because it can be authenticated using the server's public authentication key ("Q_s") while providing the computer with access to the server's private authentication key ("d_s" ) (for example, the server computer, and while maintaining security only the server computer). Additionally, the R-signature of the server is generated by signing the encrypted server data itself ("enc_s"). Additionally, the R-signature of the server does not contain identifying information about the server computer. Therefore, the server signature not only ensures that the server computer cannot fail, but is also “untraceable”, while this signature is limited to this particular session with this client computer. Accordingly, another computer cannot pretend to be the recipient of this message.

[0314] Using the method shown in Table 1100, the client computer and the server computer can establish a secure communication using only two untraceable messages, which can ensure that the client computer and the server computer cannot fail at the same time while maintaining perfect forward secrecy.

[0315] The above description is illustrative and is not restrictive. Many variations of the present invention may become apparent to those skilled in the art upon reading this specification. Therefore, the scope of the present invention may not be determined with reference to the foregoing description, but should instead be determined with reference to the contemplated claims, along with their full scope or equivalents.

[0316] It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (for example, an application-specific integrated circuit or a field programmable gate array) and/or using computer software with a conventionally programmable processor in modular or holistic mode. As used herein, a processor includes a processor with a single core, a processor with multiple cores on the same integrated circuit, or a number of processor devices on a single circuit board or network. Based on the disclosure and guidance provided herein, those skilled in the art will recognize and appreciate other ways and/or methods for implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0317] Any of the software components or functions described in this application may be implemented as program code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective -C, Swift, or a scripting language such as Perl or Python using, for example, traditional or object-oriented approaches. The program code may be stored as a series of instructions or instructions on a computer-readable medium for storage and/or transmission. Suitable read only 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 disc (CD) or DVD (digital versatile disk) , flash memory, and the like. The computer-readable medium may be any combination of such storage or transmission devices.

[0318] Storage media and computer-readable media for storing code or portions of code 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 in 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 storage technology, CD-ROM, digital versatile disk (DVD) or other optical media, magnetic 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 to which computer access. Based on the description and guidance provided herein, other ways and/or methods for carrying out various embodiments will be apparent to those skilled in the art.

[0319] Such programs may also be encoded and transmitted using carrier signals designed for transmission over wired, optical, and/or wireless networks according to a variety of protocols, including the Internet. Thus, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such programs. Computer-readable media encoded with program code may be provided with a compatible device or provided separately from other devices (eg, via Internet download). Any such computer-readable medium may reside on or in a single computer product (eg, a hard drive, CD, or an entire computer system) and may be present on or in different computer products on a system or network. The computer system may include a monitor, printer, or other suitable display device to provide the user with any of the results mentioned herein.

[0320] Any of the methods described herein may be wholly or partially performed by a computer system containing one or more processors that can be adapted to perform the steps. Thus, embodiments may relate to computer systems adapted to perform the steps of any of the methods described herein, potentially with different components performing the respective steps or the respective group of steps. Although the steps are presented numbered, the steps of the methods herein may be performed simultaneously or in a different order. In addition, portions of these steps may be used with portions of other steps from other methods. Also, the entire step or parts of it may be optional. In addition, any of the steps of any of the methods may be performed by modules, blocks, circuits, or other means to perform these steps.

[0321] The specific details of specific embodiments may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the present invention. However, other embodiments of the present invention may refer to specific embodiments relating to each individual aspect or specific combinations of these individual aspects.

[0322] 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 present invention to the exact form described, and many modifications and variations are possible in light of the above teachings.

[0323] Singular forms mean "one or more" unless otherwise specified. The use of "or" is intended to mean "inclusive or" and not "exclusive or" unless otherwise noted. The use of the terms "first", "second", "third", "fourth", "fifth", "sixth", "seventh", "eighth", "ninth", "tenth", etc., does not necessarily indicate the order or numbering of the various elements, and these can simply be used for naming purposes to qualify the various elements. The use of a "client" computer and a "server" computer does not necessarily indicate the purpose of the computers, but may simply be used for naming purposes.

[0324] All patents, patent applications, publications and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None of these documents is accepted as a prototype.

Claims (72)

1. A computer-implemented method for performing data exchange between a first computer and a second computer, the method comprising the steps of: storing by the first computer the first static private key of the first computer, the first static public key of the first computer corresponding to the first static private key, and the second static public key of the second computer; generating by means of the first computer a first masking coefficient; determining by the first computer a first masked public key using a first masking factor, wherein the first masking factor is generated using a pseudo-random number generator, the first masked public key being determined based on the first masking factor using an elliptic curve-based public key algorithm; generating by the first computer a signature of the first computer by signing the first masked public key using the first static private key; determining by the first computer a first shared secret using the first masking factor and the second static public key; encrypting, by the first computer, using the first shared secret, the first computer data including the first static public key and the signature of the first computer to obtain encrypted data of the first computer; and sending by means of the first computer to the second computer the first message including the first masked public key and the encrypted data of the first computer. 2. The method of claim 1, wherein the first computer data further includes a first computer certificate, wherein the first computer certificate includes a first static public key. 3. The method according to claim 1, further comprising the steps of: receiving by means of the first computer from the second computer a second message including a second masked public key of the second computer and encrypted data of the second computer; determining by the first computer a second shared secret using the first masking factor and the second masked public key; and decrypting by the first computer the encrypted data of the second computer using the second shared secret. 4. The method of claim 3, further comprising removing the first masking factor after determining the second shared secret. 5. The method of claim 3, wherein the second computer determines the first shared secret using the first masked public key and the second static private key of the second computer corresponding to the second static public key, decrypts the encrypted data of the first computer using the first shared secret, confirms authenticates the signature of the first computer using the first static public key and sends to the first computer a second message including the second masked public key of the second computer and the encrypted data of the second computer. 6. The method of claim 3, wherein the encrypted data of the second computer includes a signature of the second computer, the method further comprising verifying, by means of the first computer, the signature of the second computer using the second static public key. 7. The method of claim 3, further comprising authenticating the second masked public key using the second static public key and the second computer's mask factor, wherein the second computer's encrypted data includes the second computer's mask factor. 8. A computer-implemented method for performing data exchange between a first computer and a second computer, the method comprising the steps of: 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; a first message is received from the first computer via the second computer, including the first masked public key of the first computer and encrypted data of the first computer, wherein the first masked public key is determined based on the first masking coefficient using an elliptic curve-based public key algorithm, the first masking coefficient generated using a pseudo-random number generator; determining by the second computer a first shared secret using the first masked public key and the second static private key; decrypting by the second computer using the first shared secret the encrypted data of the first computer to obtain the data of the first computer, wherein the first computer data includes the first static public key and the signature of the first computer, the signature of the first computer is generated by the first computer signing the first masked public key using the first static private key of the first computer, the first static private key corresponding to the first static public key; and confirming by the second computer the authenticity of the signature of the first computer using the first static public key of the first computer and the first masked public key. 9. The method of claim 8, further comprising the steps of: generating by means of the second computer a second masking coefficient; determining, by means of the second computer, a second masked public key of the second computer using the second masking factor and the second static public key; determining, by means of the second computer, a second shared secret using the first masked public key, the second masking factor, and the second static private key; encrypting by the second computer using the second shared secret the data of the second computer, including the second static public key and the second masking coefficient, to obtain encrypted data of the second computer; and sending by means of the second computer to the first computer a second message, including the second masked public key and the encrypted data of the second computer. 10. The method of claim 8, further comprising the steps of: generating by means of the second computer a second masking factor; determining, by means of the second computer, a second masked public key of the second computer using the second masking factor and the second static public key; determining, by means of the second computer, a second shared secret using the first masked public key, the second masking factor, and the second static private key; generating, by means of the second computer, a signature of the second computer by signing the second masked public key using the second static private key; encrypting by the second computer using the second shared secret the data of the second computer containing the second static public key and the signature of the second computer to obtain encrypted data of the second computer; and sending by means of the second computer to the first computer a second message, including the second masked public key and the encrypted data of the second computer. 11. A computer-implemented method for performing data exchange between a first computer and a second computer, the method comprising the steps of: storing by the first computer the first static private key of the first computer, the first static public key of the first computer corresponding to the first static private key, and the second static public key of the second computer; generating by means of the first computer a first masking factor; determining by the first computer a first masked public key using the first masking factor; determining by the first computer a first shared secret using the first masking factor and the second static public key; generating, by means of the first computer, using the first signature algorithm, a first signature of the first computer and a random signature value of the first computer; encrypting by the first computer, using the first shared secret, the first computer data, including the first static public key and the first signature of the first computer, to obtain encrypted data of the first computer; generating, by means of the first computer, a second signature of the first computer by signing the encrypted data of the first computer and the random value of the signature of the first computer with the first static private key using the second signature algorithm; and sending by means of the first computer to the second computer the first message including the first masked public key, the second signature of the first computer and the encrypted data of the first computer. 12. The method of claim 11, wherein the first masking factor is generated using a pseudo-random number generator, wherein the first masked public key is determined based on the first masking factor using an elliptic curve-based public key algorithm, wherein the first computer data further includes a first computer certificate, wherein the first computer certificate includes a first static public key. 13. The method of claim 11, further comprising the steps of: receiving by means of the first computer from the second computer a second message including a second masked public key of the second computer and encrypted data of the second computer; determining by the first computer a second shared secret using the first masking factor and the second masked public key; and decrypting by the first computer the encrypted data of the second computer using the second shared secret. 14. The method of claim 13, wherein the second computer determines the first shared secret using the first masked public key and the second static private key of the second computer corresponding to the second static public key, decrypts the encrypted data of the first computer using the first shared secret, confirms authenticates the signature of the first computer using the first static public key and sends to the first computer a second message including the second masked public key of the second computer and the encrypted data of the second computer. 15. The method of claim 13, wherein the encrypted data of the second computer includes a signature of the second computer, the method further comprising verifying, by means of the first computer, the signature of the second computer using the second static public key. 16. The method of claim 13, further comprising authenticating the second masked public key using the second static public key and the second computer's mask factor, wherein the second computer's encrypted data includes the second computer's mask factor. 17. A computer-implemented method for performing data exchange between a first computer and a second computer, the method comprising the steps of: 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; a first message is received from the first computer by means of the second computer, containing the first masked public key of the first computer, the second signature of the first computer and the encrypted data of the first computer, wherein the second signature of the first computer is generated by the first computer by signing the encrypted data of the first computer and the random value of the signature of the first computer by a first static private key of the first computer using the second signature algorithm, wherein the first computer's random signature value is generated by the first computer using the first signature algorithm; determining by the second computer a first shared secret using the first masked public key and the second static private key; decrypting by the second computer using the first shared secret the encrypted data of the first computer to obtain the data of the first computer, wherein the data of the first computer includes the first static public key of the first computer corresponding to the first static private key, and the first signature of the first computer, and the first signature the first computer is generated by the first computer using the first signature algorithm; and confirming by the second computer the authenticity of the first signature of the first computer and the second signature of the first computer using the first static public key and the encrypted data of the first computer. 18. The method of claim 17, wherein the first computer generates the first masking factor, determines the first masked public key using the first masking factor, determines the first shared secret using the first masking factor and the second static public key, and encrypts the first computer data using the first shared secret. 19. The method of claim 17, further comprising the steps of: generating by means of the second computer a second masking factor; determining, by means of the second computer, a second masked public key of the second computer using the second masking factor and the second static public key; determining, by means of the second computer, a second shared secret using the first masked public key, the second masking factor, and the second static private key; generating, by means of the second computer, using the first signature algorithm, a first signature of the second computer and a random signature value of the second computer; encrypting by the second computer using the second shared secret the data of the second computer, including the second static public key and the first signature of the second computer, to obtain encrypted data of the second computer; generating, by means of the second computer, a second signature of the second computer by signing the encrypted data of the second computer and the random value of the signature of the first computer with the first static private key using the second signature algorithm; and sending by means of the second computer to the first computer a second message including the second masked public key, the second signature of the second computer and the encrypted data of the second computer. 20. The method of claim 19, wherein the first computer determines the second shared secret using the second masked public key, decrypts the second computer's encrypted data using the second shared secret to obtain the second computer's first signature, and verifies the second computer's second signature and the first signature second computer using a second static public key. 21. A system for performing secure data exchange between a first computer and a second computer, comprising: a computer-readable medium storing a plurality of instructions for performing operations according to any of the above methods; and one or more processors for executing instructions stored on a computer-readable medium.

Images