Google Patentsopen access

Confidential communication management — Visa International Service Association (US10652015B2)

ABSTRACT

Abstract

Systems and methods are provided for confidential communication management. For example, a client computer can determine a client key pair comprising a client private key and a client public key. The client computer can further determine a protected server key identifier, identify a server public key associated with the protected server key identifier, and generating a shared secret using the server public key and the client private key. The client computer can further encrypt message data using the shared secret and sending, to a server computer, a message including the encrypted message data, the protected server key identifier, and the client public key. The protected server key identifier can be associated with the server computer and can be usable by the server computer to identify a server private key to be used in decrypting the encrypted message data.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No. 15/915,614, filed Mar. 8, 2018, which is a continuation application of U.S. application Ser. No. 15/045,052, filed Feb. 16, 2016, which claims the benefit of priority to U.S. Provisional Application 62/116,357, filed on Feb. 13, 2015, the disclosures of which are herein incorporated by reference in their entirety for all purposes.

BACKGROUND

Standard key agreement protocols (e.g., SSL/TLS and IPSec) may reveal information about the identities of parties involved and key agreement protocol type or cipher suite information. Such information may provide intelligence to attackers and help them trace sender and receiver activities, capture metadata and reverse engineer messages, and design time efficient and focused attack methods based on the apparent weaknesses.

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

BRIEF SUMMARY

Embodiments of the invention relate to systems and methods for confidential communication management. Specifically, the embodiments provide an improved key agreement protocol where the specification of keys and protocol data (e.g., cipher suite) remain confidential in the request and response messages, thereby reducing the opportunities for attackers and increasing the cost of attacks.

According to an aspect, methods are provided for confidential key identification. For example, in some embodiments, a server computer can receive a request from a client computer. The request message can include a protected server key identifier and encrypted request data. The server computer can decrypt the protected server key identifier using a server identifier encryption key to obtain a server key identifier. A server private key associated with the server key identifier can be determined. The encrypted data can be decrypted using the server private key to obtain request data.

According to another aspect, methods, systems, and apparatus are provided for protecting protocol data. For example, in some embodiments, a sender computer can encrypt payload data using one or more payload encryption keys to generate encrypted payload data. The sender computer can also encrypt protocol data using one or more protocol encryption keys to generate encrypted protocol data. The protocol data may indicate a cipher suite. The sender computer can transmit a message comprising the encrypted payload data and the encrypted protocol data to a receiver computer.

According to another aspect, methods, systems, and apparatus are provided for data protection. For example, in some embodiments, a sender computer can encrypt payload data using one or more payload encryption keys to generate encrypted payload data. The sender computer can also encrypt protocol data using one or more protocol encryption keys to generate encrypted protocol data. The protocol data may indicate a cipher suite. The sender computer can transmit a message comprising the encrypted payload data and the encrypted protocol data to a receiver computer.

In some embodiments, a computer system is provided. The computer system can be configured to receive a message comprising encrypted protocol data and encrypted payload data. One or more protocol decryption keys can be determined to decrypt the encrypted protocol data. The encrypted protocol data can be decrypted using the one or more protocol decryption keys to obtain protocol data. One or more payload decryption keys to decrypt the payload data can be determined. The encrypted payload data can be decrypted using the protocol data and the one or more payload decryption keys to obtain payload data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates communication between a client computer and a server computer, in accordance with some embodiments of the invention.

FIG. 2 illustrates an example process for generating and sending a request message, in accordance with some embodiments.

FIG. 3 illustrates an example process for receiving and processing a request message, in accordance with some embodiments.

FIG. 4 illustrates an example process for generating and sending a response message, in accordance with some embodiments.

FIG. 5 illustrates an example process for receiving and processing a response message, in accordance with some embodiments.

FIG. 6 illustrates an example of a first request message sent by a client computer to a server computer and the processing of the first request message by the server computer, in accordance with some embodiments.

FIG. 7 illustrates an example of a subsequent request message sent by a client computer to a server computer and the processing of the subsequent request message by the server computer, in accordance with some embodiments.

FIG. 8 shows an example of a response message sent by a server computer to a client computer and the generation of the response message, in accordance with some embodiments.

FIG. 9 illustrates an example request message and an example response message that include a protected client key identifier, in accordance with some embodiments.

FIG. 10 illustrates an example process for encrypting a message, in accordance with some embodiments.

FIG. 11 illustrates another example process for encrypting a message, in accordance with some embodiments.

FIG. 12 illustrates an example process for decrypting a message, in accordance with some embodiments.

FIG. 13 illustrates another example process for decrypting a message, in accordance with some embodiments.

FIG. 14 illustrates another example process for decrypting a message, in accordance with some embodiments.

FIG. 15 illustrates an example process for generating an HTTP request message, in accordance with some embodiments.

FIG. 16 illustrates an example process for processing an HTTP request message, in accordance with some embodiments.

FIG. 17 illustrates an example process for generating an HTTP response message, in accordance with some embodiments.

FIG. 18 illustrates an example process for processing an HTTP response message, in accordance with some embodiments.

FIG. 19 illustrates an example encryption process for encrypting sensitive data, in accordance with some embodiments.

FIG. 20 illustrates an example decryption process for decrypting data, in accordance with some embodiments.

FIG. 21 shows a decision tree for processing a request message to enforce server policies, in accordance with some embodiments.

FIG. 22 is a high level block diagram of a computer system, in accordance with some embodiments.

TERMS

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

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

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

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

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

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

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

A “cryptographic nonce” may include any number, string, bit sequence, or other data value intended to be used in association with a single communication session. In some cases, a cryptographic nonce may be randomly or pseudo-randomly generated. Typically, a cryptographic nonce is of sufficient length as to make insignificant the likelihood of independently generating the same nonce value multiple times.

A “blinded key,” such as a “blinded public key” may include a key that has been obfuscated or otherwise modified from its original value by combination with another data element, such as a cryptographic nonce (e.g., a random or pseudo-random number). For example, a public key may be multiplied by the nonce to generate a “blinded public key.” Similarly, a private key may be multiplied by the nonce to generate a “blinded private key.”

An “encryption key” may include any data value or other information suitable to cryptographically encrypt data. A “decryption key” may include any data value or other information suitable to decrypt encrypted data. In some cases, an encryption key and a decryption key may be the same (i.e., a “symmetric key”).

A “key identifier” can include any data that can be used to identify one or more keys or digital certificates. For example, a key identifier may identify a private key, a public key or a digital certificate thereof, or a private/public key pair. A key identifier may also identify one or more encryption keys, signing keys, or any other suitable keys. A key identifier can be a serial number associated with a digital certificate, wherein the certificate may be retrievable using the serial number. A key identifier can also include a random or pseudo-random number or alphanumeric string that identifies a private or public key. In some embodiments, the mapping between a key identifier and the associated key(s) or certificates can be stored in a table, a file, a database, or any other suitable data storage that supports lookup and/or storage operations.

A “client key identifier” is a key identifier that identifies one or more keys associated with a client computer. A “server key identifier” is a key identifier that identifies one or more keys associated with a server computer.

A “protected key identifier” can include a key identifier and possibly other data that is used to obscure or otherwise protect the confidentiality of the key identifier in some manner. In some embodiments, a protected key identifier merely refers to a one-time value that does not reveal any useful information to an eavesdropper (e.g., a random or pseudo-random value), but that is mapped to one or more keys or certificates. For example, a protected client key identifier can include a one-time random value that is mapped to a client private key or client public key.

A protected key identifier may also comprise a key identifier (with or without additional data) that has been encrypted using an encryption key (also referred to as a “identifier protection key”). For example, a protected server key identifier can include a server key identifier that is mapped to a client private key or client public key. In some embodiments, the protected key identifier may also include additional data, such as a padding and/or a random value. In some embodiments, the padding can be a constant data element. The presence of the constant data element in a result of the decryption of the protected key identifier can indicate validity or integrity of the key identifier. In some other embodiments, the padding may include a message authentication code (MAC) of the key identifier or otherwise ge

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No. 15/915,614, filed Mar. 8, 2018, which is a continuation application of U.S. application Ser. No. 15/045,052, filed Feb. 16, 2016, which claims the benefit of priority to U.S. Provisional Application 62/116,357, filed on Feb. 13, 2015, the disclosures of which are herein incorporated by reference in their entirety for all purposes.

BACKGROUND

Standard key agreement protocols (e.g., SSL/TLS and IPSec) may reveal information about the identities of parties involved and key agreement protocol type or cipher suite information. Such information may provide intelligence to attackers and help them trace sender and receiver activities, capture metadata and reverse engineer messages, and design time efficient and focused attack methods based on the apparent weaknesses.

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

BRIEF SUMMARY

Embodiments of the invention relate to systems and methods for confidential communication management. Specifically, the embodiments provide an improved key agreement protocol where the specification of keys and protocol data (e.g., cipher suite) remain confidential in the request and response messages, thereby reducing the opportunities for attackers and increasing the cost of attacks.

According to an aspect, methods are provided for confidential key identification. For example, in some embodiments, a server computer can receive a request from a client computer. The request message can include a protected server key identifier and encrypted request data. The server computer can decrypt the protected server key identifier using a server identifier encryption key to obtain a server key identifier. A server private key associated with the server key identifier can be determined. The encrypted data can be decrypted using the server private key to obtain request data.

According to another aspect, methods, systems, and apparatus are provided for protecting protocol data. For example, in some embodiments, a sender computer can encrypt payload data using one or more payload encryption keys to generate encrypted payload data. The sender computer can also encrypt protocol data using one or more protocol encryption keys to generate encrypted protocol data. The protocol data may indicate a cipher suite. The sender computer can transmit a message comprising the encrypted payload data and the encrypted protocol data to a receiver computer.

According to another aspect, methods, systems, and apparatus are provided for data protection. For example, in some embodiments, a sender computer can encrypt payload data using one or more payload encryption keys to generate encrypted payload data. The sender computer can also encrypt protocol data using one or more protocol encryption keys to generate encrypted protocol data. The protocol data may indicate a cipher suite. The sender computer can transmit a message comprising the encrypted payload data and the encrypted protocol data to a receiver computer.

In some embodiments, a computer system is provided. The computer system can be configured to receive a message comprising encrypted protocol data and encrypted payload data. One or more protocol decryption keys can be determined to decrypt the encrypted protocol data. The encrypted protocol data can be decrypted using the one or more protocol decryption keys to obtain protocol data. One or more payload decryption keys to decrypt the payload data can be determined. The encrypted payload data can be decrypted using the protocol data and the one or more payload decryption keys to obtain payload data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates communication between a client computer and a server computer, in accordance with some embodiments of the invention.

FIG. 2 illustrates an example process for generating and sending a request message, in accordance with some embodiments.

FIG. 3 illustrates an example process for receiving and processing a request message, in accordance with some embodiments.

FIG. 4 illustrates an example process for generating and sending a response message, in accordance with some embodiments.

FIG. 5 illustrates an example process for receiving and processing a response message, in accordance with some embodiments.

FIG. 6 illustrates an example of a first request message sent by a client computer to a server computer and the processing of the first request message by the server computer, in accordance with some embodiments.

FIG. 7 illustrates an example of a subsequent request message sent by a client computer to a server computer and the processing of the subsequent request message by the server computer, in accordance with some embodiments.

FIG. 8 shows an example of a response message sent by a server computer to a client computer and the generation of the response message, in accordance with some embodiments.

FIG. 9 illustrates an example request message and an example response message that include a protected client key identifier, in accordance with some embodiments.

FIG. 10 illustrates an example process for encrypting a message, in accordance with some embodiments.

FIG. 11 illustrates another example process for encrypting a message, in accordance with some embodiments.

FIG. 12 illustrates an example process for decrypting a message, in accordance with some embodiments.

FIG. 13 illustrates another example process for decrypting a message, in accordance with some embodiments.

FIG. 14 illustrates another example process for decrypting a message, in accordance with some embodiments.

FIG. 15 illustrates an example process for generating an HTTP request message, in accordance with some embodiments.

FIG. 16 illustrates an example process for processing an HTTP request message, in accordance with some embodiments.

FIG. 17 illustrates an example process for generating an HTTP response message, in accordance with some embodiments.

FIG. 18 illustrates an example process for processing an HTTP response message, in accordance with some embodiments.

FIG. 19 illustrates an example encryption process for encrypting sensitive data, in accordance with some embodiments.

FIG. 20 illustrates an example decryption process for decrypting data, in accordance with some embodiments.

FIG. 21 shows a decision tree for processing a request message to enforce server policies, in accordance with some embodiments.

FIG. 22 is a high level block diagram of a computer system, in accordance with some embodiments.

TERMS

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

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

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

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

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

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

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

A “cryptographic nonce” may include any number, string, bit sequence, or other data value intended to be used in association with a single communication session. In some cases, a cryptographic nonce may be randomly or pseudo-randomly generated. Typically, a cryptographic nonce is of sufficient length as to make insignificant the likelihood of independently generating the same nonce value multiple times.

A “blinded key,” such as a “blinded public key” may include a key that has been obfuscated or otherwise modified from its original value by combination with another data element, such as a cryptographic nonce (e.g., a random or pseudo-random number). For example, a public key may be multiplied by the nonce to generate a “blinded public key.” Similarly, a private key may be multiplied by the nonce to generate a “blinded private key.”

An “encryption key” may include any data value or other information suitable to cryptographically encrypt data. A “decryption key” may include any data value or other information suitable to decrypt encrypted data. In some cases, an encryption key and a decryption key may be the same (i.e., a “symmetric key”).

A “key identifier” can include any data that can be used to identify one or more keys or digital certificates. For example, a key identifier may identify a private key, a public key or a digital certificate thereof, or a private/public key pair. A key identifier may also identify one or more encryption keys, signing keys, or any other suitable keys. A key identifier can be a serial number associated with a digital certificate, wherein the certificate may be retrievable using the serial number. A key identifier can also include a random or pseudo-random number or alphanumeric string that identifies a private or public key. In some embodiments, the mapping between a key identifier and the associated key(s) or certificates can be stored in a table, a file, a database, or any other suitable data storage that supports lookup and/or storage operations.

A “client key identifier” is a key identifier that identifies one or more keys associated with a client computer. A “server key identifier” is a key identifier that identifies one or more keys associated with a server computer.

A “protected key identifier” can include a key identifier and possibly other data that is used to obscure or otherwise protect the confidentiality of the key identifier in some manner. In some embodiments, a protected key identifier merely refers to a one-time value that does not reveal any useful information to an eavesdropper (e.g., a random or pseudo-random value), but that is mapped to one or more keys or certificates. For example, a protected client key identifier can include a one-time random value that is mapped to a client private key or client public key.

A protected key identifier may also comprise a key identifier (with or without additional data) that has been encrypted using an encryption key (also referred to as a “identifier protection key”). For example, a protected server key identifier can include a server key identifier that is mapped to a client private key or client public key. In some embodiments, the protected key identifier may also include additional data, such as a padding and/or a random value. In some embodiments, the padding can be a constant data element. The presence of the constant data element in a result of the decryption of the protected key identifier can indicate validity or integrity of the key identifier. In some other embodiments, the padding may include a message authentication code (MAC) of the key identifier or otherwise generated based on the key identifier. The MAC can be used to authenticate the key identifier and/or other data included in the protected key identifier. The padding and/or the random value may be used to bring the length of the protected key identifier or the unencrypted data including the key identifier, padding, and random value to a fixed length, so as to obfuscate the key identifier and to make it more difficult for an eavesdropper to distinguish the protected key identifiers from any other fixed-length data. In some embodiments, the server key identifier and/or the additional data may be encrypted using an identifier encryption key or some other suitable encryption key to generate the protected key identifier.

In some embodiments, a protected key identifier can be decrypted, or otherwise processed to reveal the underlying key identifier. The key identifier can then be mapped to one or more underlying keys and/or certificates. In some other embodiments, the protected key identifier is not decrypted but used directly to retrieve the corresponding keys and/or certificate. The mappings can be stored in a table, a file, a database, or any other suitable data storage that supports lookup and/or storage operations.

An “identifier encryption key” or “identifier decryption key” can refer to any encryption key operable to encrypt or decrypt a key identifier. In some embodiments, an identifier encryption key may be the same as the identifier decryption key (e.g., symmetric encryption key). For example, a key identifier (and optionally other data) can be encrypted using the identifier encryption key to derive the protected key identifier discussed above. In some embodiments, the identifier encryption key may be determined using a certain public/private key pair and/or other suitable data. For example, in some embodiments, the identifier encryption key may be the result of a point multiplication of a public key and the corresponding private key. In this case, there is no need to independently manage the identifier encryption key since the identifier encryption key can always be recovered from the existing key pair. As another example, the identifier encryption key may be an encryption key that is separately maintained (e.g., stored in a secure element of a client computer or a server computer).

In various embodiments, one or more identifier encryption keys may be used and/or maintained by a single entity (e.g., a client computer or a server computer) in different situations. For instance, a first identifier encryption key may be used to encrypt/decrypt key identifiers for messages according to a first protocol or messages from a particular sender. A second, a different identifier encryption key may be used to encrypt/decrypt key identifiers for messages according to a second protocol or messages from another sender.

In some embodiments, information contained in the messages can indicate which identifier encryption keys to use and/or how to derive the identifier encryption keys. For instance, a header version in message A may be used to select a first default private/public key pair for generating a first identifier encryption key; whereas a different header version in message B may be used to select a second default private/public key pair for generating a second, different identifier encryption key. In some embodiments, the selection of the default private/public key pair or the identifier encryption key may be based on the identity of the sender of a message, credential information, or any other suitable data.

A “one-time key” refers to a key that is intended to be used only once for protecting a single transaction or other communication session (e.g., a request message or a response message) between two entities (e.g., a client computer and a server computer). For instance, a client computer may use a first client key to encrypt a request message sent to a server computer. The first client key may be used by the client computer to decrypt a response message corresponding to the first request message that is sent by the server computer. However, to encrypt the next request message, the client computer may use a second, different key. Thus, the first client key is a one-time client key that is used only for protecting the first request message from the client. Similarly, a one-time server key can be used to protect a single response message from a server computer.

A one-time key can includes a key that is generated anew for each new transaction or communication session (also referred to as an “ephemeral key”). Alternatively, a plurality of one-time keys can be generated from the same base or static key that stays the same across multiple transactions or communication sessions. Each of the plurality of one-time keys can be modified differently. For example, each of the one-time keys can be blinded using different cryptographic nonce, identification factor, or other blinding factors, or otherwise obfuscated differently.

One-time keys are typically removed at the end of a transaction or communication session. In some embodiments, however, one-time keys may be maintained for a prolonged period of time. For example, during asynchronous communication with a server computer, a client computer may send a request message but may not receive the corresponding response message for a long period of time or may receive the corresponding response message out of sequence (e.g., after receipt of a response message corresponding to a later transmitted request message). In this case, the one-time key associated with the earlier request need to be saved and used to decrypt the corresponding response message. A client computer that is communicating with multiple server computers substantially concurrently may also need to store multiple one-time private keys associated with respective transactions or communication sessions in order to decrypt the corresponding response messages. Similarly, a server computer communicating with multiple client computers also need to store multiple one-time keys associated with the respective transactions or communication sessions.

A “one-time key pair” can include a private key and a corresponding public key, where at least one of the two keys changes for each new transaction or communication session. The key pair can be of any suitable format, such as elliptic curve (EC) based keys or RSA based keys. In an example, both the private key and the corresponding public key may be generated anew for each new transaction. Thus, the one-time key pair comprises an ephemeral private key and an ephemeral public key. In another example, a one-time key pair may comprise a static private key that remains the same for more than one transactions but obfuscated differently each time, and an ephemeral public key. In yet another example, a one-time key pair may comprise a static public key that remains the same for more than one transactions, but obfuscated differently each time, and an ephemeral private key. In some embodiments, both of the private key and the public key of the one-time key pair are static but one or both of the keys may be blinded, obfuscated, or otherwise modified differently for each new communication session.

A “static key pair” may include a public key (i.e., a “static public key”) and a private key (i.e., a “static private key”) maintained over a period of time or for a given number of transactions or communication sessions. Typically, though not necessarily, a static private key may be stored securely, such as in a hardware security module (HSM) or secure element (SE). Typically, though not necessarily, a static public key may be bound to an identity through the use of a digital certificate. The static key pair may be of any suitable format, such as ECC or RSA.

A “shared secret” may include any data value or other information known only to authorized parties in a secure communication. A shared secret can be generated in any suitable manner, from any suitable data. For example, a Diffie-Hellman based algorithm, such as Elliptic-Curve Diffie-Hellman (ECDH) may be used to generate a shared secret from a private key and a public key. A request shared secret can refer to a shared secret that is used to protect the security of a request message. A response shared secret refers to a shared secret that is used to protect the security of a response message.

In some cases, a shared secret can be used to generate one or more keys. For example, a shared secret can be used to generate one or more session keys or protection keys (discussed below) for protecting the entire request or response message. As another example, a shared secret can be used to generate a plurality of keys each used to protection a portion of a message.

A “session key” or “protection key” can refer to a key (e.g., an encryption key or a decryption key) that is used to protect at least a portion of a request or response message in a communication session, or any other type of data. A request session key refers to a session key that is used to protect a request message. A response session key refers to a session key that is used to protect a response message. A session key can be generated based on a shared secret. For instance, a request session key can be generated based on a request shared secret and a response session key can be generated based on a response shared secret.

“Protocol data” refers to any data in a message that indicates how to encrypt, decrypt, or otherwise process payload data of a message, or any other type of data. Protocol data can include cipher suite information, data descriptor information (e.g., data-protocol mapping information), or other suitable data. A cipher suite can refer to a named combination of a key exchange algorithm (e.g., ECDHE_RSA), an encryption algorithm, a message authentication code, an authentication algorithm, and/or other algorithms used to protect the communication between a client computer and a server computer. In some embodiments, protocol data can also include key agreement information such as key agreement algorithms and parameters used to establish shared secrets and/or to generate keys. In some embodiments, the protocol data may not include cipher suite information. Instead, the cipher suite information may be hardcoded, fixed, and/or implicitly agreed by communication parties (e.g., a client computer and a server computer).

A cipher suite may define a channel strength (e.g., 128 bits, 192 bits, or 256 bits), a key derivation function (KDF) (e.g., AES-128, AES-394, or AES-256), an elliptic curve cryptography (ECC) key agreement curve or key generation algorithm (e.g., P-256, P-384, or P-521), a block cipher mode of operation (e.g., Offset Codebook Mode (OCB), Key Wrap, Counter with CBC-MAC (CCM), EAX, Encrypt-then-MAC (EtM), or Galois/Counter Mode (GCM)), a digital signature algorithm (e.g., Elliptic Curve Digital Signature Algorithm (ECDSA) or Digital Signature Algorithm (DSA)), a cryptographic hash function (e.g., SHA-256, SHA-384, or SHA-512), a nonce (e.g., 16 bytes, 24 bytes, or 32 bytes), and the like.

A sender and a receiver of a message can agree on a cipher suite used for communications between them. In some cases, a client computer and a server computer can exchange one or more messages to negotiate and agree on the cipher suite to be used for subsequent communication. For example, the client computer may send a list of cipher suites it supports to the server computer in a request message. The cipher suites may be listed in the order of preference of the client computer. For example, the first cipher suite on the cipher suite list may be the most preferred by the client computer, the second cipher suite may be less preferred by the client computer than the first cipher suite, and so on. The request message may not include any payload data. Alternatively, the request message can include payload data that is encrypted or otherwise encoded using the preferred cipher suite. In response, the server computer can select a cipher suite from the list of cipher suites provided by the client computer and include the selected cipher suite in a response message. The response message may not include any payload data. Alternatively, the response message can include payload data that is encrypted or otherwise encoded using the selected cipher suite.

“Payload data” or “application data” refers to the “cargo” or content carried by a message and not merely the header, protocol data, metadata, or other similar data in the message that is used to facilitate the delivery or processing of the message. Examples of payload data can include identification data sent in a provisioning request, credential data in a provisioning response from a server computer, application or transaction data in a transaction message, and the like. In a typical embodiment, payload data includes sensitive data that is preferably protected from unauthorized access.

DETAILED DESCRIPTION

Embodiments of the invention relate to systems and methods for confidential communication management.

Embodiments allow communication messages to include, in a secure manner, non-traceable references to keys (e.g., protected key identifiers) used by either side to determine the keys used to protect (e.g., encrypt or decrypt) request or response messages. For instance, a server computer can include a protected server key identifier in a response message to a client computer. The protected server key identifier can include a server key identifier that identifies a server private key used to encrypt the response message. The client computer can pass the protected server key back in a subsequent request, so that the server computer can identify the proper server private key to use for decrypting the request message.

Similarly, a client computer can include a protected client key identifier in request message to a server computer. The protected client key identifier can identify a client private key used to encrypt the request message. The server computer can pass the protected client key back in a response message, so that the client computer can identify the proper client private key to use for decrypting the response message. The capability to match response messages to the corresponding requests and client private keys is important to when the messages are asynchronous.

Embodiments also protect protocol data used for encrypting/decrypting payload data separately from the payload data. Sensitive payload data can be encrypted using one or more payload encryption keys to generate encrypted payload data. Protocol data including a cipher suite used for encrypting the payload data can also be encrypted using one or more protocol encryption keys. The protocol encryption keys and the payload encryption keys can be established based on a key agreement. The encrypted protocol data and the encrypted payload data can be send in a message.

When the message is received, the protocol data decryption keys and the payload decryption keys can be derived based on the key agreement. The encrypted protocol data can be decrypted using the protocol decryption keys to obtain the protocol data (e.g., cipher suite). The encrypted payload data can be decrypted using the protocol data and the payload decryption keys.

In some cases, the payload data can include a plurality of payload elements, each can be individually encrypted using different encryption keys. In such cases, the encrypted payload elements can be decrypted as needed to improve data security.

I. Systems

FIG. 1 illustrates communication between a client computer 101 and a server computer 102 , in accordance with some embodiments. Both client computer 101 and server computer 102 may be any suitable computing device (e.g., mainframes, desktop or laptop computers, tablets, mobile devices, wearable devices, etc.).

As shown in FIG. 1 , client computer 101 may send a request message to server computer 102 . The request message may be of any suitable form. For example, in various embodiments, the request message may be one or more TCP/IP packets, an HTTP request message, or in any other suitable format. Typically, the request message may include a protected server key identifier that identifies a public key or certificate associated with the server computer. The request message may also include encrypted protocol data and encrypted payload data. The encrypted protocol data may include a protected client key identifier to allow the client computer to match asynchronous requests and responses.

The server computer 102 may process the request message. The server computer 102 may determine the server key identifier from the protected server key identifier in the request message. The corresponding server private key can be selected based on the server key identifier and used to generate one or more session keys. Some of the session keys can be used to decrypt the encrypted protocol data in the request message to obtain protocol data. Some of the other session keys can be used to decrypt the encrypted payload data according to the protocol data.

The server computer 102 may generate response data to send to client computer 101 . The response can include the protected client key identifier. The response can also include a new protected key identifier to be used in a subsequent request. Additionally, the response can include encrypted protocol data and encrypted payload data.

The client computer 101 may determine the client key identifier from the protected client key identifier in the response message and select the corresponding client private key. One or more session keys can be generated using the client private key. Some of the session keys can be used to decrypt the encrypted protocol data in the response message to obtain protocol data. Some of the other session keys can be used to decrypt the encrypted payload data according to the protocol data.

II. Confidential Key Identification

FIGS. 2-9 describe methods for protecting the identification of keys in communication between a client and a server. Specifically, embodiments in accordance with the described methods can allow communication messages to include, in a secure manner, identifiers of keys to be used by the client or the server. The specification of keys in communication messages can increase the amount of information included in each message, thereby reducing the total number of messages that are need to authenticate transactions. For example, embodiments allow authentication between a client computer and a server computer to be established in a single pair of a request message and a response message. Furthermore, security of the communication is improved by including non-traceable references to keys used by either side (e.g., protected key identifiers) in the communication messages, so that only the intended party can determine the keys associated with the protected key identifiers. The key identifiers are protected in the messages in a manner such that the keys associated with the key identifiers remain confidential even if the messages are intercepted. Thus, embodiments improve security of communication without sacrificing efficiency.

A. Request Message Generation Method

FIG. 2 illustrates an example process 200 for generating and sending a request message, in accordance with some embodiments. Typically, process 200 may be performed by a client computer, such as client computer 101 , in order to send a message to a server computer (e.g., server computer 102 ). Some or all aspects of the process 200 (or any other processes described herein, or variations and/or combinations thereof) may be performed under the control of one or more computer/control systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and/or in parallel to implement the processes.

At block 202 , a one-time client key pair is determined. The one-time client key can include an ephemeral private key and an ephemeral public key that are generated, by the client computer, for each new request. Alternatively, the one-time client key can include a static private and/or a static public key that are blinded, obfuscated, or otherwise modified differently to generate different blinded keys for each new request. For instance, point multiplication may be performed on a static client public key with some other data element (e.g., a random number, a cryptographic nonce, identification factor, transaction data, etc.) to modify the value of the client public key for each request.

In some embodiments, a client computer may be configured to communicate with one or more server computers. As such, the client computer may maintain a set of one or more one-time client key pairs for some or all of the one or more server computers. Each client key pair in the set of one or more client key pairs corresponds to a particular request sent to a given server computer. The one-time client key pair can be determined to be associated with a particular request message for a particular server computer. In some embodiments, such as for asynchronous communication, the client computer can store, for a given server computer, a certain number of previously-generated client key pairs for previously-sent request messages, so as to enable decryption of an out-of-sequence response message corresponding to a previously-sent request message. The size of the set of previously generated client key pairs can be limited by a predetermined maximum number (e.g., 10).

At block 204 , it is determined whether a protected server key identifier exists. In an embodiment, the client computer may store protected server key identifiers received from previous responses messages from one or more server computers. Each of the one or more server computers may be associated with a set of one or more protected server key identifiers, some or all of which may be received from previous response messages from the associated server computer. Each of the protected server key identifiers can be associated with a particular server public key and/or private key. The mappings between the server computers and the protected server key identifiers and between the protected server key identifiers and the corresponding server public keys and/or certificates may be stored in a table, a database, or any other suitable data storage associated with the client computer. Such mappings can be used to determine whether any protected server identifier (and hence server public key or certificate) exists for a given server computer to which a request message is to be sent. The existence of such protected server identifiers indicate that the client computer has previously received response messages from the server computer and extracted the protected server identifiers from those response messages. The lack of such protected server identifiers can indicate that the client computer has never previously received response messages from the server computer or has not received response messages from the server computer for a predetermined period of time.

If it is determined, at block 204 , that one or more protected server key identifiers exist for the server computer, then at block 206 , a protected server key identifier is retrieved from the one or more protected server key identifiers. Typically, the protected server key identifier associated with the most recently sent response message from the server computer is selected. In some cases, the most recently sent response message by the server computer is not necessarily the most recently received response message by the client computer when the response messages are received out-of-sequence.

At block 208 , the server public key or certificate associated with the retrieved protected server key identifier can be retrieved. In some embodiments, a protected server key identifier and the corresponding server public key or certificate are received in the same response message. In some other embodiments, the protected server key identifier and the corresponding server public key or certificate are received in the different response message. In some cases, the protected server key identifier and/or the associated server public key or certificate may be received in the same or a different communication channel (e.g., email, text) than the communication channel for the request/response messages.

The most recently sent protected server key identifier and its associated server public key or certificate can indicate the latest key update or key rotation performed by the server computer. By including a new server public key or certificate and the associated new protected server key identifier in a response message, the server computer informs the client computer that a subsequent communication with the server computer should use the new server public key or certificate instead of an old one. In some embodiments, new public key or certificate may be used by the server computer to encrypt the response data in the current response message. As such, the new public key or certificate may be used by the client computer to decrypt the current response message.

If it is determined, at block 204 , that no protected server key identifier exists for the server computer, then a random key identifier (also referred to as a pseudo key identifier) may be generated as the protected server key identifier at block 210 . The random key identifier may not identify any existing server public key or server certificate. The random key identifier can include data generated using any suitable randomization or pseudo-randomization algorithm. In some embodiments, the random key identifier may be formatted such that it is apparent to a receiving server computer that the key identifier is random. In some embodiments, the random key identifier may be indistinguishable to a random value by an eavesdropper to a protected key identifier.

At block 212 , a default or initial server public key or certificate is determined. A default server digital key or certificate may include any server public key or server certificate that is to be used in communication where no other public key or certificate has been previously defined for use between the client computer and the server computer. The default digital certificate may include a public key (i.e., a default public key). In some cases, a default digital certificate may be used during a first request sent from a client computer to a server computer. In some embodiments, the default digital certificate may be pre-loaded onto the client computer, and a private key associated with the default digital certificate (i.e., a default private key) may be loaded onto the server computer. In some embodiments, the default server certificate or public key may be provided to the client computer in the same or a different communication channel (e.g., email, text) than the communication channel for the request/response messages. In some embodiments, the default digital certificate to use may vary depending on the key agreement protocol (e.g., based on a version number of the protocol).

The random protected server key identifier generated at step 210 can be included in the request message to be sent to the server computer to indicate that the default or initial server public key is used by the client computer and that the server computer should do so it too.

At block 214 , a request shared secret is generated using the one-time client private key that is determined at block 202 and the server public key or certificate determined at 208 or 212 . The request shared secret can be used to protect (e.g., encrypt and/or decrypt) the request message as discussed below. In some embodiments, the server public key may be determined from a digital certificate of the server computer, which may have been previously obtained by client device (e.g., from a response message from the server computer or from some other channel).

The request shared secret may be generated using any suitable method. For example, in embodiments using elliptic curve cryptography, the shared secret may be determined using the elliptic-curve Diffie-Hellman protocol (ECDH).

Additionally or alternatively, the request shared secret can be generated using additional data. Such additional data can include an identification factor that is calculated using identification data and authentication data. Identification data may include any data or information associated with a user or a client device. Examples of identification data may include a name of a user associated with client device, an organization associated with client device, payment information such as a primary account number (PAN) or token associated with client device, an expiration date associated with the PAN or token, a certificate associated with client device, an IMEI or serial number of client device, etc. Authentication data may include any data or information suitable to authenticate a user or client device. Examples of authentication data may include a password or passphrase, a secret key (e.g., a private key), etc. An identification factor may include any data or information determined from identification data and/or authentication data. For example, in some embodiments, the identification factor may be generated by hashing a combination of the identification data and the authentication data.

At block 216 , a protected client key identifier is optionally determined. The protected client key identifier corresponds to the private key of the one-time client key pair, the public key of the one-time client key pair, or both. In some cases, determining the protected client key identifier can include generating random or pseudo-random data as the protected client key identifier. In some other cases, determining the protected client key identifier can include encrypting a client key identifier using an encryption key. The client key identifier or the protected client key identifier can be associated with a private key of the one-time client key pair, the public key of the one-time client key pair, or both. The mappings can be maintained in a table, a database, or similar data storage at the client device.

When the server computer receives the protected client identifier in the request message, it can include the protected client identifier in a corresponding response message so that the client computer knows which one-time client private key to use in order to decrypt the response message (as discussed below). Thus, protected client identifier can be used by the client computer to map request and response messages, for example, during asynchronous communication. In some embodiments, block 216 may be optional and the request message may not include any protected client key identifier.

At block 218 , request data is encrypted using the request shared secret. The request data optionally includes the protected client key identifier determined at block 216 .

In some embodiments, a request session key may be generated based on the request shared secret. The request session key may be used to encrypt the request data. The request session key can be generated using the request shared secret and other suitable supplementary data such as key derivation data, if any. The request session key can also be referred to as a message protection key since it is used to protect a message between the client device and the server computer. Examples of such supplementary data may include a server computer identifier and/or a truncated one-time client public key.

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

At block 220 , the request message is sent to a server computer. The request message includes the encrypted request data and the protected server key identifier. The protected server key identifier can be a real protected server key identifier retrieved at block 206 or the random key identifier determined at block 210 . The request message can also include a one-time client public key which may or may not be blinded. The request message can also include information that indicates how to decrypt the protected server key identifier. For instance, the request message can include a protocol version number which can be used by the receiving server computer to select the default server key(s) for decrypting the protected server identifier.

In some embodiments, the request message can also include identification data, a client computer identifier, authentication data, along with any o

CLAIMS

Claims ( 18 )

What is claimed is:

1. A computer-implemented method for confidential communication management, comprising:

receiving, by a server computer from a client computer, a request message including a protected server key identifier and encrypted request data;

decrypting, by the server computer, the protected server key identifier using a server identifier encryption key to obtain a server key identifier, wherein the protected server key identifier is usable by the server computer to validate the server key identifier corresponding to a server private key;

determining, by the server computer, the server private key associated with the server key identifier; and

decrypting, by the server computer, the encrypted request data using the server private key to obtain request data.

2. The computer-implemented method of claim 1 , wherein the server identifier encryption key is determined based on a default key pair comprising a default public key and a default private key.

3. The computer-implemented method of claim 1 , wherein decrypting the encrypted request data comprises:

determining a request shared secret based on the server private key and a client public key;

deriving a request session key based on the request shared secret; and

decrypting the encrypted request data using the request session key.

4. The computer-implemented method of claim 1 , wherein the protected server key identifier is decrypted to obtain the server key identifier and a padding element, and the method further comprises validating the padding element before determining the server private key associated with the server key identifier.

5. The computer-implemented method of claim 1 , further comprising:

for another request message including other encrypted request data, determining that another protected server key identifier does not map to an existing server private key and decrypting the other encrypted request data using a default server private key to obtain other request data.

6. The computer-implemented method of claim 1 , further comprising:

determining a second server key identifier to be used in a next request from the client computer, the second server key identifier being associated with a second server private key;

encrypting the second server key identifier using the server identifier encryption key to determine a second protected server key identifier;

encrypting response data comprising the second protected server key identifier to generate encrypted response data; and

sending a response message including the encrypted response data to the client computer.

7. The computer-implemented method of claim 6 , wherein encrypting the second server key identifier comprises encrypting a combination of the second server key identifier, a padding element, and a random element using the server identifier encryption key, the padding element being a constant value or a message authentication code of the second server key identifier.

8. The computer-implemented method of claim 6 , wherein the response message further comprises an obfuscated server public key corresponding to the second server private key.

9. The computer-implemented method of claim 6 , wherein the request data includes a protected client key identifier and the response message includes the protected client key identifier, wherein the protected client key identifier is used, by the client computer, to determine a client private key for decrypting the response message.

10. A computer system for confidential communication management comprising:

a memory that stores computer-executable instructions; and

one or more hardware processors configured to access the memory and execute the computer-executable instructions to implement a method comprising:

receiving, from a client computer, by the computer system a request message including a protected server key identifier and encrypted request data;

decrypting, by the computer system, the protected server key identifier using a server identifier encryption key to obtain a server key identifier, wherein the protected server key identifier is usable by the computer system to validate the server key identifier corresponding to a server private key;

determining, by the computer system, the server private key associated with the server key identifier; and

decrypting, by the computer system, the encrypted request data using the server private key to obtain request data.

11. The computer system of claim 10 , wherein the server identifier encryption key is determined based on a default key pair comprising a default public key and a default private key.

12. The computer system of claim 10 , wherein decrypting the encrypted request data comprises:

determining a request shared secret based on the server private key and a client public key;

deriving a request session key based on the request shared secret; and

decrypting the encrypted request data using the request session key.

13. The computer system of claim 10 , wherein the protected server key identifier is decrypted to obtain the server key identifier and a padding element, and the method further comprises validating the padding element before determining the server private key associated with the server key identifier.

14. The computer system of claim 10 , wherein the method further comprises:

for another request message including other encrypted request data, determining that another protected server key identifier does not map to an existing server private key and decrypting the other encrypted request data using a default server private key to obtain other request data.

15. The computer system of claim 10 , wherein the method further comprises:

determining a second server key identifier to be used in a next request from the client computer, the second server key identifier being associated with a second server private key;

encrypting the second server key identifier using the server identifier encryption key to determine a second protected server key identifier;

encrypting response data comprising the second protected server key identifier to generate encrypted response data; and

sending a response message including the encrypted response data to the client computer.

16. The computer system of claim 15 , wherein encrypting the second server key identifier comprises encrypting a combination of the second server key identifier, a padding element, and a random element using the server identifier encryption key, the padding element being a constant value or a message authentication code of the second server key identifier.

17. The computer system of claim 15 , wherein the response message further comprises an obfuscated server public key corresponding to the second server private key.

18. The computer system of claim 15 , wherein the request data includes a protected client key identifier and the response message includes the protected client key identifier, wherein the protected client key identifier is used, by the client computer, to determine a client private key for decrypting the response message.

US16/257,882

2015-02-13

2019-01-25

Confidential communication management

Active

US10652015B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US16/257,882

US10652015B2

( en )

2015-02-13

2019-01-25

Confidential communication management

Applications Claiming Priority (4)

Application Number

Priority Date

Filing Date

Title

US201562116357P

2015-02-13

2015-02-13

US15/045,052

US9942034B2

( en )

2015-02-13

2016-02-16

Confidential communication management

US15/915,614

US10218502B2

( en )

2015-02-13

2018-03-08

Confidential communication management

US16/257,882

US10652015B2

( en )

2015-02-13

2019-01-25

Confidential communication management

Related Parent Applications (1)

Application Number

Title

Priority Date

Filing Date

US15/915,614

Continuation

US10218502B2

( en )

2015-02-13

2018-03-08

Confidential communication management

Publications (2)

Publication Number

Publication Date

US20190173672A1

US20190173672A1 ( en )

2019-06-06

US10652015B2

true

US10652015B2 ( en )

2020-05-12

Family

ID=56615761

Family Applications (3)

Application Number

Title

Priority Date

Filing Date

US15/045,052

Active

2036-09-11

US9942034B2

( en )

2015-02-13

2016-02-16

Confidential communication management

US15/915,614

Active

US10218502B2

( en )

2015-02-13

2018-03-08

Confidential communication management

US16/257,882

Active

US10652015B2

( en )

2015-02-13

2019-01-25

Confidential communication management

Family Applications Before (2)

Application Number

Title

Priority Date

Filing Date

US15/045,052

Active

2036-09-11

US9942034B2

( en )

2015-02-13

2016-02-16

Confidential communication management

US15/915,614

Active

US10218502B2

( en )

2015-02-13

2018-03-08

Confidential communication management

Country Status (6)

Country

Link

US

( 3 )

US9942034B2

( en )

EP

( 2 )

EP3869730B1

( en )

CN

( 1 )

CN107251476A

( en )

AU

( 1 )

AU2016218981B2

( en )

RU

( 1 )

RU2718689C2

( en )

WO

( 1 )

WO2016131056A1

( en )

Cited By (4)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US11122021B1

( en )

2020-06-25

2021-09-14

Bank Of America Corporation

Server for handling multi-encrypted messages

US11451389B2

( en )

2020-06-25

2022-09-20

Bank Of America Corporation

Multi-encrypted message response manager

US11757846B2

( en )

2020-06-25

2023-09-12

Bank Of America Corporation

Cognitive multi-encrypted mail platform

US12013970B2

( en )

2022-05-16

2024-06-18

Bank Of America Corporation

System and method for detecting and obfuscating confidential information in task logs

Families Citing this family (160)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US9015281B2

( en )

*

2010-10-08

2015-04-21

Brian Lee Moffat

Private data sharing system

US10033693B2

( en )

2013-10-01

2018-07-24

Nicira, Inc.

Distributed identity-based firewalls

US10298555B2

( en )

*

2014-04-04

2019-05-21

Zettaset, Inc.

Securing files under the semi-trusted user threat model using per-file key encryption

JP2018516030A

( en )

2015-05-05

2018-06-14

ショカード、インコーポレイテッド

ID management service using blockchain

US10033703B1

( en )

*

2015-06-16

2018-07-24

Amazon Technologies, Inc.

Pluggable cipher suite negotiation

US10009324B2

( en )

2015-06-29

2018-06-26

American Express Travel Related Services Company, Inc.

Host card emulation systems and methods

US10110566B2

( en )

*

2015-07-21

2018-10-23

Baffle, Inc.

Systems and processes for executing private programs on untrusted computers

US20170076106A1

( en )

*

2015-09-16

2017-03-16

Qualcomm Incorporated

Apparatus and method to securely control a remote operation

US10206079B1

( en )

*

2015-09-30

2019-02-12

Groupon, Inc.

System and method for notification transmission and confirmation management

US10218698B2

( en )

*

2015-10-29

2019-02-26

Verizon Patent And Licensing Inc.

Using a mobile device number (MDN) service in multifactor authentication

US10324746B2

( en )

2015-11-03

2019-06-18

Nicira, Inc.

Extended context delivery for context-based authorization

WO2017088930A1

( en )

*

2015-11-27

2017-06-01

Hewlett Packard Enterprise Development Lp

Distribution and verification of transaction integrity keys

US11153087B1

( en )

2015-12-29

2021-10-19

Amazon Technologies, Inc.

Hub-based token generation and endpoint selection for secure channel establishment

US10411886B1

( en )

*

2015-12-29

2019-09-10

Amazon Technologies, Inc.

Authenticating secure channel establishment messages based on shared-secret

US10778435B1

( en )

*

2015-12-30

2020-09-15

Jpmorgan Chase Bank, N.A.

Systems and methods for enhanced mobile device authentication

US10007826B2

( en )

*

2016-03-07

2018-06-26

ShoCard, Inc.

Transferring data files using a series of visual codes

US10819418B2

( en )

2016-04-29

2020-10-27

Honeywell International Inc.

Systems and methods for secure communications over broadband datalinks

BR112018072929A2

( en )

2016-05-13

2019-02-19

nChain Holdings Limited

method and system for verifying the integrity of a computer software and computer software program

US20190306094A1

( en )

*

2016-06-02

2019-10-03

Beijing Yi Zhang Yun Feng Technology Co., Ltd.

Dynamic communication of capability using headers

WO2017207057A1

( en )

*

2016-06-02

2017-12-07

Kobil Systems Gmbh

Secure messaging

EP3273635B1

( en )

*

2016-07-20

2019-10-30

Mastercard International Incorporated

Secure channel establishment

US10296757B2

( en )

*

2016-07-29

2019-05-21

Sap Se

Appended key ID for key identification during data encryption

US10938837B2

( en )

2016-08-30

2021-03-02

Nicira, Inc.

Isolated network stack to manage security for virtual machines

DE102016012189B4

( en )

*

2016-10-11

2020-02-06

Giesecke+Devrient Mobile Security Gmbh

Diffie Hellman key derivation, subscription loading, authentication

US10218686B2

( en )

*

2016-10-24

2019-02-26

International Business Machines Corporation

Dynamically managing, from a centralized service, valid cipher suites allowed for secured sessions

CN106533665B

( en )

*

2016-10-31

2018-08-07

北京百度网讯科技有限公司

Mthods, systems and devices for storing website private key plaintext

US11063758B1

( en )

*

2016-11-01

2021-07-13

F5 Networks, Inc.

Methods for facilitating cipher selection and devices thereof

US10715607B2

( en )

2016-12-06

2020-07-14

Nicira, Inc.

Performing context-rich attribute-based services on a host

US11032246B2

( en )

2016-12-22

2021-06-08

Nicira, Inc.

Context based firewall services for data message flows for multiple concurrent users on one machine

US10803173B2

( en )

2016-12-22

2020-10-13

Nicira, Inc.

Performing context-rich attribute-based process control services on a host

US10812451B2

( en )

2016-12-22

2020-10-20

Nicira, Inc.

Performing appID based firewall services on a host

US10802858B2

( en )

2016-12-22

2020-10-13

Nicira, Inc.

Collecting and processing contextual attributes on a host

US10805332B2

( en )

2017-07-25

2020-10-13

Nicira, Inc.

Context engine model

CN108347410B

( en )

*

2017-01-24

2021-08-31

华为技术有限公司

Security implementation method, device and system

US20180218357A1

( en )

*

2017-02-01

2018-08-02

Microsoft Technology Licensing, Llc

Export high value material based on ring 1 evidence of ownership

US10498541B2

( en )

2017-02-06

2019-12-03

ShocCard, Inc.

Electronic identification verification methods and systems

USRE49968E1

( en )

2017-02-06

2024-05-14

Ping Identity Corporation

Electronic identification verification methods and systems with storage of certification records to a side chain

US10735384B2

( en )

*

2017-02-17

2020-08-04

Whatsapp Inc.

Techniques for key ratcheting with multiple step sizes

EP3586241A4

( en )

*

2017-02-24

2021-01-13

Semtech (International) AG

Privacy preserving message blinding

DE102017204184A1

( en )

*

2017-03-14

2018-09-20

Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.

Authenticated confirmation and activation message

CN106972919B

( en )

*

2017-03-29

2020-04-24

北京奇虎科技有限公司

Key negotiation method and device

US10796015B2

( en )

*

2017-03-29

2020-10-06

Mybitchbook, Inc.

Method and system for anonymous user data storage and controlled data access

US10608822B2

( en )

*

2017-04-26

2020-03-31

Nxp B.V.

Efficient calculation of message authentication codes for related data

US10574457B2

( en )

*

2017-05-12

2020-02-25

Nokia Technologies Oy

Indicator for determination of key for processing message in communication system

JP6834771B2

( en )

*

2017-05-19

2021-02-24

富士通株式会社

Communication device and communication method

US10313133B2

( en )

2017-06-21

2019-06-04

Visa International Service Association

Secure communications providing forward secrecy

EP3419211B1

( en )

*

2017-06-23

2022-03-30

Flytxt B.V.

Privacy preserving computation protocol for data analytics

US10924278B2

( en )

*

2017-07-13

2021-02-16

Qwyit, Llc

Method and apparatus for authentication and encryption service employing unbreakable encryption

US11349659B2

( en )

*

2017-08-29

2022-05-31

Amazon Technologies, Inc.

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

US11095662B2

( en )

2017-08-29

2021-08-17

Amazon Technologies, Inc.

Federated messaging

US11368442B2

( en )

*

2017-08-29

2022-06-21

Amazon Technologies, Inc.

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

US11018875B2

( en )

*

2017-08-31

2021-05-25

Onboard Security, Inc.

Method and system for secure connected vehicle communication

US10567165B2

( en )

*

2017-09-21

2020-02-18

Huawei Technologies Co., Ltd.

Secure key transmission protocol without certificates or pre-shared symmetrical keys

US11146397B2

( en )

*

2017-10-31

2021-10-12

Micro Focus Llc

Encoding abelian variety-based ciphertext with metadata

US10778651B2

( en )

*

2017-11-15

2020-09-15

Nicira, Inc.

Performing context-rich attribute-based encryption on a host

EP4120620A1

( en )

2017-12-08

2023-01-18

Ping Identity Corporation

Methods and systems for recovering data using dynamic passwords

US10862773B2

( en )

2018-01-26

2020-12-08

Nicira, Inc.

Performing services on data messages associated with endpoint machines

US10802893B2

( en )

2018-01-26

2020-10-13

Nicira, Inc.

Performing process control services on endpoint machines

CN108306880B

( en )

*

2018-01-31

2019-06-11

北京深思数盾科技股份有限公司

A kind of data distribution, retransmission method and device

US10819689B2

( en )

*

2018-05-03

2020-10-27

Honeywell International Inc.

Systems and methods for encrypted vehicle data service exchanges

US10715511B2

( en )

*

2018-05-03

2020-07-14

Honeywell International Inc.

Systems and methods for a secure subscription based vehicle data service

US11362824B2

( en )

*

2018-05-25

2022-06-14

Intertrust Technologies Corporation

Content management systems and methods using proxy reencryption

US11184157B1

( en )

*

2018-06-13

2021-11-23

Amazon Technologies, Inc.

Cryptographic key generation and deployment

US11398900B2

( en )

*

2018-06-21

2022-07-26

Oracle International Corporation

Cloud based key management

CN110798431A

( en )

*

2018-08-03

2020-02-14

杭州海康威视数字技术股份有限公司

A security parameter interaction method, device, device and system

US10867046B2

( en )

*

2018-08-08

2020-12-15

Quanta Computer Inc.

Methods and apparatus for authenticating a firmware settings input file

US20210326866A1

( en )

*

2018-08-17

2021-10-21

Visa International Service Association

Techniques For Securely Communicating Sensitive Data

CN110855597B

( en )

*

2018-08-20

2022-08-09

京东科技控股股份有限公司

Message transmission method, server and client

GB2577122A

( en )

*

2018-09-17

2020-03-18

Trustonic Ltd

Establishing a protected communication channel

US11210664B2

( en )

*

2018-10-02

2021-12-28

Capital One Services, Llc

Systems and methods for amplifying the strength of cryptographic algorithms

US10592710B1

( en )

*

2018-10-02

2020-03-17

Capital One Services, Llc

Systems and methods for cryptographic authentication of contactless cards

US11551208B2

( en )

*

2018-10-04

2023-01-10

Verifone, Inc.

Systems and methods for point-to-point encryption compliance

US11082221B2

( en )

2018-10-17

2021-08-03

Ping Identity Corporation

Methods and systems for creating and recovering accounts using dynamic passwords

WO2020081074A1

( en )

*

2018-10-17

2020-04-23

Hewlett-Packard Development Company, L.P.

Requesting access to a service

US10979227B2

( en )

2018-10-17

2021-04-13

Ping Identity Corporation

Blockchain ID connect

US11258604B2

( en )

2018-10-19

2022-02-22

Oracle International Corporation

Rewiring cryptographic key management system service instances

WO2020102727A1

( en )

*

2018-11-15

2020-05-22

Trade Examination Technologies, Inc.

Secure and accountable data access

EP4191948B1

( en )

*

2018-11-15

2026-04-15

Huawei Digital Power Technologies Co., Ltd.

Rekeying a security association sa

CN113169866B

( en )

*

2018-11-28

2024-09-06

维萨国际服务协会

Techniques to prevent collusion using simultaneous key distribution

HK1254273A2

( en )

*

2018-12-03

2019-07-12

Foris Limited

Secure distributed key management system

JP7369772B2

( en )

*

2018-12-10

2023-10-26

アルゴランド，インコーポレイテッド

Utilizing virtual blockchain protocols to implement fair electronic exchange

CN113169937B

( en )

*

2018-12-21

2023-04-28

瑞典爱立信有限公司

Method, device, network node and medium for processing user data service

US11343093B2

( en )

*

2019-02-08

2022-05-24

Fisher Controls International Llc

Methods and apparatus to broadcast data packets in a process control environment

US12069174B2

( en )

*

2019-02-08

2024-08-20

Malikie Innovations Limited

Secure communication with an authentication process

US11190496B2

( en )

2019-02-12

2021-11-30

Visa International Service Association

Fast oblivious transfers

US10686592B1

( en )

*

2019-03-14

2020-06-16

Monkey Solution LLC

System and method to provide a secure communication of information

US11387983B2

( en )

*

2019-03-25

2022-07-12

Micron Technology, Inc.

Secure medical apparatus communication

US11632235B2

( en )

*

2019-04-09

2023-04-18

Samsung Electronics Co., Ltd.

Method and apparatus for handling security procedure in mc communication system

FR3095708B1

( en )

*

2019-05-02

2022-03-04

Sagemcom Broadband Sas

Secure data transmission method

US20220321326A1

( en )

*

2019-06-05

2022-10-06

Mastercard International Incorporated

Security model for distributed computing system

US11190514B2

( en )

*

2019-06-17

2021-11-30

Microsoft Technology Licensing, Llc

Client-server security enhancement using information accessed from access tokens

HUP1900254A1

( en )

*

2019-07-15

2021-01-28

Xtendr Zrt

Cryptographic alias mapper method and computer system, as well as computer program and computer readable medium

SG10201906806XA

( en )

*

2019-07-23

2021-02-25

Mastercard International Inc

Methods and computing devices for auto-submission of user authentication credential

US11570155B2

( en )

*

2019-07-25

2023-01-31

Everything Blockchain Technology Corp.

Enhanced secure encryption and decryption system

WO2021025989A1

( en )

*

2019-08-02

2021-02-11

Mastercard International Incorporated

System and method to support payment acceptance capability for merchants

CN110535641B

( en )

*

2019-08-27

2022-06-10

中国神华能源股份有限公司神朔铁路分公司

Key management method and apparatus, computer device, and storage medium

US11303588B1

( en )

*

2019-09-05

2022-04-12

Meta Platforms, Inc.

Automating a response to a message communicated to a business entity via an online messaging application

CN112637109B

( en )

*

2019-09-24

2023-09-05

北京京东尚科信息技术有限公司

Data transmission method, system, electronic device and computer readable medium

US11296870B2

( en )

*

2019-10-01

2022-04-05

Sap Se

Key management configurations

US11070533B2

( en )

*

2019-10-10

2021-07-20

Forcepoint Llc

Encrypted server name indication inspection

CN110705985B

( en )

*

2019-10-21

2020-09-29

北京海益同展信息科技有限公司

Method and apparatus for storing information

DE112020005033T5

( en )

*

2019-11-21

2022-07-21

Murata Manufacturing Co., Ltd.

COMMUNICATION DATA TEXT CONFUSION ENCRYPTION METHOD

US12452078B2

( en )

*

2019-11-27

2025-10-21

Apple Inc.

Multiple-key verification information for mobile device identity document

CN110855439A

( en )

*

2019-12-17

2020-02-28

深圳前海环融联易信息科技服务有限公司

HTTP encryption method, device, computer equipment and storage medium

US11539718B2

( en )

2020-01-10

2022-12-27

Vmware, Inc.

Efficiently performing intrusion detection

US11405766B2

( en )

2020-02-06

2022-08-02

International Business Machines Corporation

Connecting computer processing systems and transmitting data

US11357020B2

( en )

2020-02-06

2022-06-07

International Business Machines Corporation

Connecting computer processing systems and transmitting data

US11290575B2

( en )

*

2020-02-06

2022-03-29

International Business Machines Corporation

Connecting computer processing systems and transmitting data

US11489821B2

( en )

*

2020-02-26

2022-11-01

International Business Machines Corporation

Processing a request to initiate a secure data transfer in a computing environment

US11652616B2

( en )

2020-02-26

2023-05-16

International Business Machines Corporation

Initializing a local key manager for providing secure data transfer in a computing environment

Related documents

• Generating augmented reality experiences utilizing physical objects to … — Meta Platforms Technologies, Llc (US20260037214A1)#653960
• Virtual reality system using multiple force arrays for a solver — DeepMotion, Inc. (US10657696B2)#653961
• Tracking position of device inside-out for virtual reality interactivity — Sony Interactive Entertainment America Llc (US10535153B2)#653962
• Augmented reality system with spatialized audio tied to user manipulated … — Magic Leap, Inc. (US11231770B2)#653963
• Big data-based autonomous flight drone system and autonomous flight method … — Rgblab Co., Ltd. (US20210390867A1)#653964