US20220006795A1 - Secure message passing using semi-trusted intermediaries - Google Patents
Secure message passing using semi-trusted intermediaries Download PDFInfo
- Publication number
- US20220006795A1 US20220006795A1 US17/479,291 US202117479291A US2022006795A1 US 20220006795 A1 US20220006795 A1 US 20220006795A1 US 202117479291 A US202117479291 A US 202117479291A US 2022006795 A1 US2022006795 A1 US 2022006795A1
- Authority
- US
- United States
- Prior art keywords
- encrypted
- intermediary
- message
- recipient
- mek
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 141
- 230000008569 process Effects 0.000 claims abstract description 81
- 230000004044 response Effects 0.000 claims description 8
- 238000010586 diagram Methods 0.000 description 14
- 238000004891 communication Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 7
- 238000013475 authorization Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 4
- 238000003491 array Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
- H04L51/046—Interoperability with other network applications or services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0471—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0827—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
Definitions
- Passing messages securely between two or more computing devices is often necessary when the message includes sensitive or confidential information.
- a sender of a message cannot send a message directly to a recipient because the address or location of the recipient is unknown or because the recipient is otherwise unreachable.
- the sender can pass the message to an intermediary, which temporarily holds the message until the recipient retrieves it.
- the sender can indicate the identity of the recipient authorized to receive the message, so that the intermediary can ensure the message is passed to its proper recipient.
- the recipient can request messages from the intermediary. Once the intermediary verifies the identity of the recipient vis-à-vis the identity previously indicated by the sender, the intermediary passes the message to the recipient, and the recipient processes the message.
- the intermediary is trusted with an unencrypted message.
- the sender encrypts the message prior to passing the message to the intermediary.
- the processing executed by the recipient can include decryption of the message to access it contents.
- One example embodiment provides a method including receiving, by a first intermediary computing device, a first encryption key generated by a sender computing device for encrypting a message located at the sender computing device.
- the message is to be passed between the sender computing device and a recipient computing device via a second intermediary device that is separate, independent, and distinct from the first intermediary computing device.
- the method further includes encrypting, by the first intermediary computing device, the first encryption key using a second encryption key located at the first intermediary computing device to produce an encrypted version of the first encryption key.
- the method further includes sending, by the first intermediary computing device, the encrypted version of the first encryption key to the sender computing device for inclusion with the message.
- the method further includes receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient computing device.
- the method further includes decrypting, by the first intermediary computing device, the encrypted version of the first encryption key using the second encryption key located at the first intermediary computing device to produce a decrypted version of the first encryption key.
- the method further includes sending, by the first intermediary computing device, the decrypted version of the first encryption key to the recipient computing device for decrypting the message.
- the method includes digitally signing, by the first intermediary computing device, the encrypted version of the first encryption key.
- the method includes receiving, by the first intermediary computing device, the digitally signed and encrypted version of the first encryption key from the recipient computing device, and verifying that the recipient computing device is authorized to request decryption of the encrypted version of the first encryption key based on a recipient identifier (“RID”) associated with the recipient computing device prior to decrypting the encrypted version of the first encryption key.
- the method includes digitally signing, by the first intermediary computing device, the encrypted version of the first encryption key and the RID.
- the method includes receiving, by the second intermediary computing device and from the sender computing device, the encrypted version of the first encryption key and a message encrypted by the sender computing device using the first encryption key; receiving, by the second intermediary computing device, a request to pass the encrypted message and the encrypted version of the first encryption key to the recipient computing device; and passing, by the second intermediary computing device and to the recipient computing device, the encrypted version of the first encryption key and the message encrypted by the sender computing device using the first encryption key.
- the method includes verifying, by the intermediary computing device, that the sender computing device is authorized to request encryption of the first encryption key in response to receiving the first encryption key from the sender computing device.
- the first encryption key is encrypted using a symmetric encryption process.
- the first encryption key is encrypted using an asymmetric encryption process.
- Another example embodiment provides a method including receiving, by a second intermediary computing device, an encrypted message to be passed between a sender computing device and a recipient computing device.
- the message is encrypted by the sender computing device using a first encryption key.
- the method further includes receiving an encrypted version of the first encryption key encrypted by a first intermediary device that is separate, independent, and distinct from the second intermediary computing device.
- the method further includes receiving, by the second intermediary computing device, a request to pass the encrypted message and the encrypted version of the first encryption key to a recipient computing device.
- the method further includes passing, by the second intermediary computing device, the encrypted message and the encrypted version of the first encryption key to the recipient computing device, the encrypted version of the first encryption key being encrypted by the first intermediary computing device using a second encryption key located at the first intermediary device.
- the method includes verifying, by the second intermediary computing device, that the recipient computing device is authorized to request passing of the encrypted message to the recipient computing device based on a recipient identifier (RID) associated with the recipient computing device prior to sending the encrypted message to the recipient computing device.
- RID recipient identifier
- the method includes receiving, by the first intermediary computing device, the first encryption key used by the sender computing device for encrypting the message; encrypting, by the first intermediary computing device, the first encryption key using the second encryption key located at the first intermediary device to produce the encrypted version of the first encryption key; sending, by the first intermediary computing device, the encrypted version of the first encryption key to the sender computing device for inclusion with the message to be passed to the recipient computing device; receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient computing device subsequent to receipt of the message from the sender computing device; decrypting, by the first intermediary computing device, the encrypted version of the first encryption key using the second encryption key to produce a decrypted version of the first encryption key; and sending, by the intermediary computing device, the decrypted version of the first encryption key to the recipient computing device for decrypting the message.
- the method includes receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient, and verifying that the recipient is authorized to request decryption of the encrypted first encryption key based on a recipient identifier (RID) associated with the recipient computing device prior to decrypting the encrypted MEK.
- RID recipient identifier
- the first encryption key is encrypted using a symmetric encryption process. In some cases, the first encryption key is encrypted using an asymmetric encryption process.
- the system includes a first intermediary including a first memory and at least one first processor coupled to the first memory, where the first intermediary is configured to receive a message encryption key (“MEK”) generated by a sender computing device for encrypting a message located at the sender computing device, the message to be passed between the sender computing device and a recipient computing device; encrypt the MEK using a guard key located at the first intermediary to produce an encrypted version of the MEK; send the encrypted version of the MEK to the sender computing device for inclusion with the message; receive the encrypted version of the MEK from the recipient computing device; decrypt the encrypted MEK using the guard key located at the first intermediary to produce a decrypted version of the MEK; and send the decrypted version of the MEK to the recipient computing device for decrypting the message.
- MEK message encryption key
- the system further includes a second intermediary including a second memory and at least one second processor coupled to the second memory, where the second intermediary is separate, independent, and distinct from the first intermediary and configured to receive, from the sender computing device, the encrypted version of the MEK and the message encrypted by the sender computing device using the MEK; receive a request to transmit the encrypted message and the encrypted version of the MEK to the recipient computing device; and send, to the recipient computing device, the encrypted version of the MEK and the message encrypted by the sender computing device using the MEK.
- first intermediary is further configured to digitally sign the encrypted version of the MEK and a recipient identifier (“RID”) associated with the recipient computing device.
- the first intermediary is further configured to receive the digitally signed and encrypted version of the MEK from the recipient, and to verify that the recipient is authorized to request decryption of the encrypted version of the MEK based on the RID prior to decrypting the encrypted MEK. In some cases, the first intermediary is further configured to verify that the sender computing device is authorized to request encryption of the MEK in response to receiving the MEK from the sender computing device. In some cases, the sender computing device is configured to encrypt a message using the MEK, and the recipient computing device is configured to decrypt the message using the decrypted MEK. In some cases, the MEK is encrypted using a symmetric encryption process.
- FIG. 1 is a schematic diagram of an example message passing process, in accordance with an embodiment of the present disclosure.
- FIG. 2 is a schematic diagram of another example message passing process, in accordance with an embodiment of the present disclosure.
- FIG. 3 is a schematic diagram of yet another example message passing process, in accordance with an embodiment of the present disclosure.
- FIG. 4 is a schematic diagram of an example secure message passing process, in accordance with an embodiment of the present disclosure.
- FIG. 5 is a data flow diagram corresponding to the example secure message passing process of FIG. 4 .
- FIG. 6 is a flow diagram for an example secure message passing process, in accordance with an embodiment of the present disclosure.
- FIG. 7 is a block diagram of a computing platform configured to perform a secure message passing process, in accordance with an example of the present disclosure.
- intermediaries can be used to convey messages from a sender to a recipient where the recipient is unavailable to receive a message directly from the sender.
- techniques that make use of intermediaries can be effective in highly controlled environments, their use is nevertheless vulnerable to attacks that seek to circumvent established security measures and to exploit weaknesses and vulnerabilities in their implementation. These techniques also have a high degree of cost and complexity when implemented at a large scale due to the need to establish the trusted relationships at the intermediaries or to create, maintain, and exchange many encryption/decryption keys among the entities.
- a computing device hosting as a sender process has a clear (non-encrypted) message to pass, send, or otherwise transmit to another computing device hosting a recipient process.
- the sender generates a symmetric message encryption key (MEK) for encrypting the message and sends the MEK to a first intermediary process with a request for the first intermediary to encrypt the MEK.
- MEK symmetric message encryption key
- the sender also includes, in the request, a recipient identifier (RID) uniquely associated with the recipient.
- the RID can, for example, include any unique identifier within an authentication realm used by the system.
- the RID is a Security Identifier (SID).
- SID Security Identifier
- the RID can be a user or a service identifier, or any other values that can be used to uniquely identify the recipient of the message.
- the first intermediary verifies that the sender is authorized to request key encryption.
- the first intermediary has its own key, also referred to as a guard key, which is used to generate an encrypted version of the MEK (that is, to encrypt the original MEK) and an encrypted version of the RID (that is, to encrypt the original RID).
- the combination of the encrypted MEK and encrypted RID can be signed together by the first intermediary for additional security so that the first intermediary can subsequently verify that the encrypted MEK and RID were previously processed by the first intermediary.
- the first intermediary returns the encrypted/signed MEK/RID back to the sender.
- the sender uses the originally generated (non-encrypted) MEK to encrypt the message.
- the sender then sends the encrypted message, the RID, and the encrypted/signed MEK/RID to a second intermediary process (for example, a message repository), which verifies that the sender is authorized to send messages and retains the data for the recipient.
- the second intermediary process uses the RID to identify the intended recipient of the message.
- the second intermediary can notify or otherwise inform the recipient to notify the recipient (and optionally the sender) that the message is available to retrieve.
- the recipient attempts to retrieve the encrypted message and the encrypted/signed MEK/RID from the second intermediary.
- the recipient can use any suitable technique for retrieving the encrypted message.
- the recipient can poll the second intermediary on a periodic or non-periodic basis to request delivery of any messages that the second intermediary is retaining on behalf of the recipient.
- the second intermediary verifies that the recipient identity matches the RID and authorizes the request.
- the recipient receives the encrypted message and the encrypted/signed MEK/RID from the second intermediary and requests decryption of the encrypted MEK from the first intermediary.
- the first intermediary verifies that the combined encrypted MEK/RID was signed by the first intermediary and that the recipient identity matches the RID and then decrypts the MEK and returns it to the recipient. Finally, the recipient decrypts the message using the MEK.
- the first and second intermediaries are considered semi-trusted because neither is trusted to store or process an unencrypted message, but they are trusted to reliably encrypt keys, store encrypted messages, and only allow access to the designated senders and recipients.
- Embodiments of the present disclosure use symmetric encryption and separation of the intermediaries to provide a simple, low cost, and high-performance option that increases security while preserving simplicity, as compared to a fully trusted intermediary, and decreases complexity without sacrificing security, as compared to encrypting messages with asymmetric keys for each recipient.
- Message confidentiality is maintained by encrypting the message at the sender and decrypting the message at the recipient—only the sender and the recipient have access to the clear, unencrypted message.
- at least two semi-trusted intermediaries are used—one for key encryption/decryption, and one for message and key passing. Since there are at least two intermediaries, an attack on one of them by an attacker will not result in a breach.
- the intermediaries are separate, independent, and distinct, an infrastructure owner will be afforded additional time to detect and address an active attack before both intermediaries are compromised.
- the first intermediary is stateless.
- the first intermediary does not store any data that it receives or generates as part of the secure message passing process. Rather, the first intermediary holds a single “guard” key that is used by the first intermediary to encrypt and decrypt a message encryption key that is used by the sender to encrypt the message and by the recipient to decrypt the message.
- the encrypted message encryption key is passed from the sender to the recipient via the second intermediary along with the encrypted message.
- Embodiments of the present disclosure can be implemented on a wide range of platforms, including Microsoft Windows® or other platforms, such as mobile computing platforms and Internet-of-Things (IoT) devices where low power requirements may restrict usage of asymmetric encryption techniques.
- Microsoft Windows® or other platforms, such as mobile computing platforms and Internet-of-Things (IoT) devices where low power requirements may restrict usage of asymmetric encryption techniques.
- IoT Internet-of-Things
- the term “message” refers to any data or information that is sent, passed, or otherwise transmitted from one computing service, device, or computer-implemented process to another by any means of transmission, such as electronically, optically, acoustically, electromagnetically, or using any other suitable type of communications.
- the term “sender” refers to any computer-implemented process with a unique, verifiable identity, such as a sender of a message to one or more recipients.
- the sender can be associated with a user or a computing device used to send and receive messages.
- an encrypted message is a message that is unintelligible, while a decrypted message is intelligible, without additional transformation, to at least one entity.
- the term “recipient” refers to any computer-implemented process with a unique, verifiable identity, such as a recipient of a message passed from another entity (e.g., a sender).
- the recipient can be associated with a user or a computing device used to send and receive messages.
- the term “intermediary” refers to an agent located along the transmission path of a message between the sender and the recipient of the message.
- the intermediary is, in some embodiments, a computer-implemented process that acts as an authorization authority to verify that the sender and the recipient are authorized to access the services provided by the intermediaries.
- one or more of the processes described herein can each implement and expose an application program interface (API) configured to receive and respond to calls from one another.
- API application program interface
- the intermediaries can each implement and expose an API configured to receive and respond to calls from the sender and the recipient.
- APIs enable the processes to interoperate, in some embodiments.
- one or more of the processes described above can each include local storage allocated for the private use of the process.
- a trusted intermediary is an agent located between the sender and the recipient of a message.
- the trusted intermediary conveys a clear-text message between entities.
- the intermediary must itself be secured from attacks that could compromise data stored with the intermediary, such as the clear-text messages, which creates a very valuable target to breach as all such messages will be available for the attacker once the trusted intermediary is breached.
- Encryption provides security but introduces other costs and complexities resulting from the difficulty of distributing and managing the keys used for encrypting and decrypting a message in a large-scale environment.
- one or more secure communication channels exist or can be created between processes exchanging messages, such as from a sender to a recipient, using existing techniques.
- all processes, including the sender, the recipient, and any intermediaries can be configured to reliably authenticate the identity of other processes using existing techniques.
- one or more intermediaries can be used to pass messages from the sender to the recipient when the recipient is unreachable directly from the sender.
- the use of intermediaries for message passing, in accordance with certain embodiments, is useful because neither the sender nor the recipient is directly reachable from one another or not always available.
- the intermediaries provide a “man in the middle” that is reliably available for the sender to send messages to it and to retain the message until the recipient is available and ready to receive the message.
- FIG. 1 is a schematic diagram of an example message passing process 100 , in accordance with an embodiment of the present disclosure.
- a sender process (“sender”) 102 sends a message 104 directly to a recipient process (“recipient”) 106 by passing the message 104 to the recipient 106 .
- the message 104 can include, for example, sensitive or confidential information that is intended only for receipt by the recipient 106 .
- the sender 102 is separate, independent, and distinct from the recipient 106 (i.e., the sender 102 and the recipient 106 are implemented by at least two different threads).
- the sender 102 and the recipient 106 can be implemented on physically different computing devices or servers having different network addresses and separate processing and data storage environments.
- the sender 102 and the recipient 106 can be physically or logically isolated from each other, for example, using a network firewall or other suitable security devices for preventing or limiting the exchange of data between the sender 102 and the recipient 106 .
- the process 100 is not suitable for message passing.
- FIG. 2 is a schematic diagram of another example message passing process 200 , in accordance with an embodiment of the present disclosure.
- an intermediary process (“intermediary”) 202 is located between a sender 102 and a recipient 106 .
- the sender 102 passes the message 104 to the intermediary 202 along with a recipient identifier that is associated with the recipient 106 .
- the intermediary 202 receives the message 104 from the sender 102 and retains the message 104 until the recipient 106 sends a message request 204 to the intermediary 202 .
- the recipient 106 can, for example, send the message request 204 to the intermediary 202 when the recipient 106 expects to receive the message 104 or at any other time when the recipient 106 polls the intermediary 202 for messages (for example, polling at certain time intervals or in response to certain events, such as power-up, authentication to a domain controller, etc.).
- the intermediary 202 replies to the message request 204 by passing the message 104 to the recipient 106 if the identity of the recipient 106 matches the recipient identifier.
- the process 200 addresses some of the limitations of the process 100 .
- the recipient 106 does not need to be reachable from the sender 102 because the intermediary 202 retains the message 104 until the recipient 106 retrieves it.
- FIG. 3 is a schematic diagram of yet another example message passing process 300 , in accordance with an embodiment of the present disclosure.
- at least two intermediaries e.g., a first intermediary 302 and a second intermediary 312 .
- the sender 102 encrypts or otherwise secures the message 104 using a message encryption key 306 to produce an encrypted (locked) message 304 .
- the sender 102 sends the key 306 to the first intermediary 302 , which stores the key 306 .
- the sender 102 separately passes the encrypted message 304 to the second intermediary 312 .
- the second intermediary 312 retains the message 304 until it receives a request 314 for the message 304 from the recipient 106 .
- the second intermediary 312 passes the encrypted message 104 to the recipient 106 .
- the key 306 which is stored at the first intermediary 302 , is passed to the recipient 106 from the first intermediary 302 in response to a key request 316 from the recipient 106 .
- the key 306 is then used by the recipient 106 to decrypt (unlock) the encrypted message 304 .
- the key 306 for encrypting and decrypting the message 104 can, for example, include a random string of bits generated specifically to scramble and/or unscramble data. Such keys can be created using processes designed to ensure that each key is unique and unpredictable. For example, 256-bit Advanced Encryption Standard (AES) keys can be used to encrypt the message 104 . However, it will be understood that any suitable encryption process can be used, including symmetric processes and asymmetric processes. Symmetric, or secret key encryption, uses a single key for both encryption and decryption. Symmetric key encryption is used for encrypting large amounts of data efficiently. 256-bit AES keys are symmetric keys.
- AES Advanced Encryption Standard
- Asymmetric, or public/private encryption uses a pair of keys. Data encrypted with one key are decrypted only with the other key in the public/private key pair. When an asymmetric key pair is generated, the public key is typically used to encrypt, and the private key is typically used to decrypt.
- the first intermediary 302 serves as an agent for exchanging the key 306 between the sender 102 and the recipient 106 in a similar manner as the intermediary 202 serves as an agent for exchanging the message 104 between the sender 102 and the recipient 106 in the process 200 of FIG. 2 .
- the sender 102 instead of receiving the message 104 from the sender 102 , the sender 102 passes the key 306 to the first intermediary 302 without the message 104 .
- the encrypted message 304 is instead passed from the sender 102 to the recipient 106 via the second intermediary 312 (e.g., a message repository organized to store messages and metadata descriptive of the messages), which retains the encrypted message 304 until the recipient 106 requests delivery.
- the unencrypted message 104 is not passed at all. In this manner, the first intermediary 302 does not have access to either the original, unencrypted message 104 or the encrypted message 304 .
- the process 300 solves the security problem, there are additional cost and management complexities associated with storing and transferring separate encryption keys from the sender(s) 102 to the recipient(s) 106 for each message (for many messages, at scale, this can incur high storage and processing costs).
- FIG. 4 is a schematic diagram of an example secure message passing process 400 , in accordance with an embodiment of the present disclosure.
- at least two intermediaries e.g., a first intermediary 402 and a second intermediary 412 .
- the process for encrypting and decrypting the message 104 is different from the process 300 in that the first intermediary 402 does not retain the encryption key generated by the sender 102 for encrypting the message 104 .
- the first intermediary 402 holds a separate “guard” key 408 that is used to encrypt a symmetric message encryption key (MEK) 406 , which is generated by the sender 102 , as will now be described in further detail.
- MEK symmetric message encryption key
- the sender 102 Initially, the sender 102 generates the MEK 406 and passes it to the first intermediary 402 along with a request for the first intermediary 402 to encrypt the MEK 406 .
- Any suitable technique can be used to generate the MEK 406 .
- the MEK 406 can be randomly generated using a random number generator or pseudorandom number generator.
- the MEK 406 can be generated using a passphrase as a hash value and a cryptographic hash function that converts the passphrase into the MEK 406 .
- the sender 102 also includes a recipient identifier (RID) associated with the recipient 106 with the MEK 406 .
- the RID can, for example, include an identifier that is unique to the recipient 106 .
- the first intermediary 402 then verifies that the sender 102 is authorized to request encryption of the MEK 406 .
- the first intermediary 402 can be configured as, or can access, an authorization authority, where the sender 102 is trusted through a separate process.
- the first intermediary 402 encrypts the MEK 406 using the guard key 408 located at the first intermediary 402 .
- the guard key 408 is unique from other keys in that the guard key 408 is held only by the first intermediary 402 and is not shared with any other entity. This is important because only the first intermediary 402 can decrypt the MEK 406 once it has been encrypted.
- the MEK is not usable as a key for decrypting data, such as the message 104 , that has been encrypted using the original (unencrypted) MEK.
- the first intermediary 402 also encrypts the RID.
- the combination of the encrypted MEK and the RID (which is encrypted in certain embodiments and not encrypted in certain other embodiments) are digitally signed together by the first intermediary 402 to generate an encrypted/signed MEK/RID 410 and sent back to the sender 102 .
- the first intermediary 402 does not retain the MEK, the encrypted MEK, the RID, or the encrypted/signed MEK/RID 410 after the encrypted/signed MEK/RID 410 is sent back to the sender 102 .
- the sender 102 then encrypts the message 104 , located at the sender 102 , using the original, non-encrypted MEK 406 to produce an encrypted (locked) message 404 .
- a 256-bit AES process can be used to encrypt the message 104 using the MEK 406 .
- the sender 102 does not share the original, non-encrypted MEK 406 with any entity other than the first intermediary 402 .
- the sender 102 then passes the encrypted message 404 and the encrypted/signed MEK/RID 410 to the second intermediary 412 .
- the second intermediary 412 is separate, independent, and distinct from the first intermediary 402 (i.e., the first intermediary 402 and the second intermediary 412 are implemented by at least two different execution environments).
- the first intermediary 402 and the second intermediary 412 can be implemented on physically different servers having different network addresses and separate processing and data storage environments.
- the first intermediary 402 and the second intermediary 412 can be physically or logically isolated from each other, for example, using a network firewall or other suitable security devices for preventing or limiting the exchange of data between the first intermediary 402 and the second intermediary 412 .
- the second intermediary 412 then verifies that the sender 102 is authorized to pass the encrypted message 404 .
- the second intermediary 412 can be configured as, or can access, an authorization authority, where the sender 102 is trusted through a separate process. If the sender 102 is not authorized to pass the encrypted message 404 , then the second intermediary 412 deletes or otherwise disposes of the encrypted message 404 . Once the second intermediary 412 verifies that the sender 102 is authorized to pass the encrypted message 404 , the second intermediary 412 retains the encrypted message 404 .
- the second intermediary 412 cannot decrypt the encrypted message 404 because the second intermediary 412 does not have access to the unencrypted MEK 406 and cannot gain access to the unencrypted MEK 406 since the identity of the second intermediary 412 does not match the RID of the recipient 106 .
- the first intermediary 402 can be configured to refuse any decryption request from the second intermediary 412 or from any entity other than the one with a matching RID (such as the recipient 106 ) to provide a decryption key, thereby further preventing the second intermediary 412 from decrypting the encrypted message 404 .
- the recipient 106 sends a message request 414 to the second intermediary 412 , thereby requesting the second intermediary 412 to pass the encrypted message 404 and the encrypted/signed MEK/RID 410 to the recipient 106 .
- the recipient 106 can generate and send the request message 414 in response to any of a variety of events. For example, the recipient 106 can poll the second intermediary 412 on a periodic or non-periodic basis to request delivery of any messages that the second intermediary 412 is retaining on behalf of the recipient 106 .
- the second intermediary 412 then verifies, using the RID, that the recipient 106 is authorized to receive the encrypted message 404 .
- the second intermediary 412 can be configured as, of can access, an authorization authority, where the recipient 106 is trusted through a separate process.
- the RID is not necessarily used. However, use of the RID or other identifying information helps ensure that the entity requesting delivery of the message (e.g., the recipient 106 ) is authorized to receive the message.
- the second intermediary 412 verifies that the recipient 106 is authorized to receive the encrypted message 404 , the second intermediary 412 passes the encrypted message 404 and the encrypted/signed MEK/RID 410 to the recipient 106 .
- the encrypted message 404 and the encrypted/signed MEK/RID 410 can be passed together or separately. Note that both the encrypted message 404 and the encrypted/signed MEK/RID 410 are needed; without the encrypted/signed MEK/RID 410 , the encrypted message 404 cannot be decrypted, and without the encrypted message 404 , the encrypted/signed MEK/RID 410 are not useable to obtain the message.
- the recipient 106 sends the encrypted/signed MEK/RID 410 to the first intermediary 402 along with a request for the first intermediary 402 to decrypt the encrypted MEK.
- the recipient 106 also includes the RID in the decryption request to the first intermediary 402 .
- the first intermediary 402 then verifies that the recipient 106 is authorized to request decryption of the encrypted MEK and that the RID matches the RID of the recipient 106 .
- the first intermediary 402 can be configured as, or can access, an authorization authority, where the recipient 106 is trusted through a separate process.
- the first intermediary 402 also verifies that the combination of the encrypted MEK and RID was previously signed by the first intermediary as an anti-tampering measure.
- the first intermediary 402 verifies that the recipient 106 is authorized to request decryption of the encrypted MEK and that the RID matches the RID of the recipient 106 , the first intermediary 402 decrypts the encrypted MEK using the guard key 408 , which as noted above is held only by the first intermediary 402 and is not shared with any other entity.
- the decrypted MEK 406 is then passed to the recipient 106 .
- the recipient 106 then decrypts the encrypted message 404 using the decrypted MEK 406 to produce the decrypted (unlocked) message 104 .
- the MEK 406 and the encrypted/signed MEK/RID 410 can, for example, include a random string of bits generated specifically to scramble and/or unscramble data.
- Such keys can be created using processes designed to ensure that each key is unique and unpredictable.
- 256-bit AES process keys can be used to encrypt the message 104 .
- any suitable encryption process can be used, including symmetric encryption/decryption processes and asymmetric encryption/decryption processes.
- the process 400 can be implemented with any number of senders, recipients, and intermediaries. For example, one sender can use the process 400 to pass messages to multiple recipients. Similarly, multiple senders can use the process 400 to pass messages to a single recipient. Other embodiments and variations will be apparent in light of this disclosure.
- FIG. 5 is a data flow diagram 500 corresponding to the example secure message passing process 400 of FIG. 4 , in accordance with an embodiment of the present disclosure.
- FIG. 5 With reference to FIG. 5 :
- the sender 102 initially the sender 102 generates the symmetric message encryption key (MEK) 406 and sends it to a first intermediary 402 along with a request for the first intermediary 402 to encrypt the MEK 406 .
- the sender 102 also includes a recipient identifier (RID) associated with the recipient in the request to the first intermediary 402 .
- the first intermediary 402 then verifies that the sender 102 is authorized to request encryption of the MEK 406 .
- the first intermediary 402 verifies that the sender 102 is authorized to request encryption of the MEK 406 , the first intermediary encrypts the MEK 406 to generate the encrypted MEK.
- the encrypted combination of the encrypted MEK and the RID are signed by the first intermediary to generate the encrypted/signed MEK/RID and sent back to the sender 102 .
- the sender 102 then encrypts the message 104 using the non-encrypted (original) MEK 406 to produce an encrypted (locked) message 404 .
- the sender 102 then passes the encrypted message 404 and the encrypted/signed MEK/RID 410 to a second intermediary 412 .
- the second intermediary 412 receives the encrypted message 404 and the encrypted/signed MEK/RID 410 , while the first intermediary 402 never receives or otherwise has any access to either the non-encrypted message 104 or the encrypted message 404 . This prevents any attack on the first intermediary 402 from accessing the message in either clear or encrypted form.
- the second intermediary 412 verifies that the sender 102 is authorized to pass the encrypted message 404 . Once the second intermediary 412 verifies that the sender 102 is authorized to pass the encrypted message 404 , the second intermediary 412 retains the encrypted message 404 and the encrypted/signed MEK/RID 410 .
- the recipient 106 requests 414 the encrypted message 404 and the encrypted/signed MEK/RID 410 from the second intermediary 412 .
- the second intermediary 412 then verifies, using the RID, that the recipient 106 is authorized to receive the encrypted message 404 . Once the second intermediary 412 verifies that the recipient 106 is authorized to receive the encrypted message 404 , the second intermediary 412 passes the encrypted message 404 and the encrypted/signed MEK/RID 410 to the recipient 106 .
- the recipient 106 sends the encrypted/signed MEK/RID 410 to the first intermediary 402 along with a request for the first intermediary 402 to decrypt the encrypted MEK.
- the first intermediary 402 then verifies that the recipient 106 is authorized to request decryption of the encrypted MEK, that the RID matches the RID of the recipient 106 , and that the combination of the encrypted MEK and RID was previously signed by the first intermediary 402 .
- the first intermediary 402 verifies that the recipient 106 is authorized to request decryption of the encrypted MEK, that the RID matches the RID of the recipient 106 , and that the combination of the encrypted MEK and RID was previously signed by the first intermediary 402 , the first intermediary 402 decrypts the encrypted MEK. The decrypted MEK 406 is then passed to the recipient 106 .
- the recipient 106 then decrypts the encrypted message 404 using the decrypted MEK 406 to produce the decrypted (unlocked) message 104 .
- FIG. 6 is a flow diagram for an example secure message passing process 600 , in accordance with an embodiment of the present disclosure.
- a computer-implemented process acting as a sender e.g., the sender 102 of FIG. 4
- receives 601 a symmetric message encryption key (MEK) and sends it to another computer-implemented process acting as a guard (e.g., the first intermediary (guard) 402 of FIG. 4 ) along with a request for the guard to encrypt the MEK.
- the method 600 includes receiving 602 , by the guard, the MEK.
- receiving 602 the MEK further includes receiving a recipient identifier (RID) associated with another computer-implemented process identified by the sender as a recipient (the recipient 106 of FIG. 4 ).
- the RID can, for example, include any set of values that can be used to uniquely identify the recipient.
- the guard verifies that the sender is authorized to request encryption of the MEK.
- the method 600 further includes encrypting 604 , by the MEK using a key accessible only to the guard.
- the combination of the encrypted MEK and the RID is signed 604 by the guard using the guard key to generate an encrypted/signed MEK and RID.
- the method 600 further includes sending 606 , by the guard, the encrypted/signed MEK/RID to the sender.
- the method 600 includes encrypting 608 , by the sender, a message using the non-encrypted MEK to produce an encrypted (locked) message.
- the sender then passes the encrypted message and the encrypted/signed MEK/RID to another computer-implemented process acting as a message repository (e.g., the second intermediary (message repository) 412 of FIG. 4 ).
- the method 600 further includes receiving 610 , by the message repository, the encrypted message and the encrypted/signed MEK/RID. Note that the message repository receives and retains the encrypted message and the encrypted/signed MEK/RID, while the guard never receives or otherwise has any access to either the non-encrypted message or the encrypted message.
- the message repository then verifies that the sender is authorized to pass the encrypted message. Once the message repository verifies that the sender is authorized to pass the encrypted message, the message repository retains the encrypted message.
- the recipient requests the encrypted message and the encrypted/signed MEK/RID from the message repository.
- the message repository then verifies, using the RID, that the recipient is authorized to receive the encrypted message. Once the message repository verifies that the recipient is authorized to receive the encrypted message, the method 600 continues with passing 612 , by the message repository, the encrypted message and the encrypted/signed MEK/RID to the recipient.
- the recipient sends 613 the encrypted/signed MEK/RID to the guard along with a request for the guard to decrypt the encrypted MEK.
- the method 600 further includes receiving 614 , by the guard, the encrypted MEK. 402 .
- the guard verifies that the recipient is authorized to request decryption of the encrypted MEK and that the RID matches the RID of the recipient. Once the guard verifies that the recipient is authorized to request decryption of the encrypted MEK, that the RID matches the RID of the recipient, and that the combination of the encrypted MEK and RID was previously signed by the guard, the method 600 continues with decrypting 616 , by the guard, the encrypted MEK.
- the method 600 further includes sending 618 , by the guard, the decrypted MEK to the recipient.
- the method 600 includes decrypting 620 , by the recipient, the encrypted message using the decrypted MEK 406 to produce the decrypted (unlocked) message.
- FIG. 7 is a block diagram of a computing platform 700 configured to perform a secure message passing process, in accordance with an example of the present disclosure.
- the platform 700 may be a workstation, a laptop computer, a tablet, a mobile device, or any suitable computing or communication device.
- the computing platform or device 700 includes one or more processors 710 , volatile memory 720 (e.g., random access memory (RAM)), non-volatile memory 730 , one or more network or communication interfaces 740 , a user interface (UI) 760 , a display screen 770 , and a communications bus 750 .
- volatile memory 720 e.g., random access memory (RAM)
- non-volatile memory 730 e.g., non-volatile memory 730
- network or communication interfaces 740 e.g., a network or communication interfaces 740
- UI user interface
- the computing platform 700 may also be referred to as a computer or a computer system.
- the non-volatile (non-transitory) memory 730 can include: one or more hard disk drives (HDDs) or other magnetic or optical storage media; one or more solid state drives (SSDs), such as a flash drive or other solid-state storage media; one or more hybrid magnetic and solid-state drives; and/or one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof.
- HDDs hard disk drives
- SSDs solid state drives
- virtual storage volumes such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof.
- the user interface 760 can include one or more input/output (I/O) devices (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more biometric scanners, one or more environmental sensors, and one or more accelerometers, etc.).
- I/O input/output
- the display screen 770 can provide a graphical user interface (GUI) and in some cases, may be a touchscreen or any other suitable display device.
- GUI graphical user interface
- the non-volatile memory 730 stores an operating system (“OS”) 725 , one or more applications 734 , and data 736 such that, for example, computer instructions of the operating system 725 and the applications 734 , are executed by processor(s) 710 out of the volatile memory 720 .
- the volatile memory 720 can include one or more types of RAM and/or a cache memory that can offer a faster response time than a main memory.
- Data can be entered through the user interface 760 .
- Various elements of the computer platform 700 can communicate via the communications bus 750 .
- the illustrated computing platform 700 is shown merely as an example computing device and can be implemented by any computing or processing environment with any type of machine or set of machines that can have suitable hardware and/or software capable of operating as described herein.
- the processor(s) 710 can be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system.
- processor describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations can be hard coded into the circuitry or soft coded by way of instructions held in a memory device and executed by the circuitry.
- a processor can perform the function, operation, or sequence of operations using digital values and/or using analog signals.
- the processor can be embodied in one or more application specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multicore processors, or general-purpose computers with associated memory.
- ASICs application specific integrated circuits
- DSPs digital signal processors
- GPUs graphics processing units
- FPGAs field programmable gate arrays
- PDAs programmable logic arrays
- multicore processors or general-purpose computers with associated memory.
- the processor 710 can be analog, digital or mixed.
- the processor 710 can be one or more physical processors, or one or more virtual (e.g., remotely located or cloud) processors.
- a processor including multiple processor cores and/or multiple processors can provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data.
- the network interfaces 740 can include one or more interfaces to enable the computing platform 700 to access a computer network 780 such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless connections, including cellular connections.
- a computer network 780 such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless connections, including cellular connections.
- the network 780 may allow for communication with other computing platforms 790 , to enable distributed computing.
- the network 780 may allow for communication with the one or more of the sender 102 , the recipient 106 , the intermediary 202 or 302 , the first intermediary 402 , and the second intermediary 412 of FIGS. 1-4 .
- references to “or” can be construed as inclusive so that any terms described using “or” can indicate any of a single, more than one, and all of the described terms.
- the term usage in the incorporated references is supplementary to that of this document; for irreconcilable inconsistencies, the term usage in this document controls.
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 16/775,901, entitled “SECURE MESSAGE PASSING USING SEMI-TRUSTED INTERMEDIARIES” and filed on Jan. 29, 2020, which is hereby incorporated herein by reference in its entirety.
- Passing messages securely between two or more computing devices is often necessary when the message includes sensitive or confidential information. In some circumstances, a sender of a message cannot send a message directly to a recipient because the address or location of the recipient is unknown or because the recipient is otherwise unreachable. In such cases, the sender can pass the message to an intermediary, which temporarily holds the message until the recipient retrieves it. When passing the message to the intermediary, the sender can indicate the identity of the recipient authorized to receive the message, so that the intermediary can ensure the message is passed to its proper recipient. Subsequently, the recipient can request messages from the intermediary. Once the intermediary verifies the identity of the recipient vis-à-vis the identity previously indicated by the sender, the intermediary passes the message to the recipient, and the recipient processes the message.
- In some systems, the intermediary is trusted with an unencrypted message. In other systems, the sender encrypts the message prior to passing the message to the intermediary. In systems where the sender encrypts the message, the processing executed by the recipient can include decryption of the message to access it contents.
- One example embodiment provides a method including receiving, by a first intermediary computing device, a first encryption key generated by a sender computing device for encrypting a message located at the sender computing device. The message is to be passed between the sender computing device and a recipient computing device via a second intermediary device that is separate, independent, and distinct from the first intermediary computing device. The method further includes encrypting, by the first intermediary computing device, the first encryption key using a second encryption key located at the first intermediary computing device to produce an encrypted version of the first encryption key. The method further includes sending, by the first intermediary computing device, the encrypted version of the first encryption key to the sender computing device for inclusion with the message. The method further includes receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient computing device. The method further includes decrypting, by the first intermediary computing device, the encrypted version of the first encryption key using the second encryption key located at the first intermediary computing device to produce a decrypted version of the first encryption key. The method further includes sending, by the first intermediary computing device, the decrypted version of the first encryption key to the recipient computing device for decrypting the message. In some cases, the method includes digitally signing, by the first intermediary computing device, the encrypted version of the first encryption key. In some cases, the method includes receiving, by the first intermediary computing device, the digitally signed and encrypted version of the first encryption key from the recipient computing device, and verifying that the recipient computing device is authorized to request decryption of the encrypted version of the first encryption key based on a recipient identifier (“RID”) associated with the recipient computing device prior to decrypting the encrypted version of the first encryption key. In some cases, the method includes digitally signing, by the first intermediary computing device, the encrypted version of the first encryption key and the RID. In some cases, the method includes receiving, by the second intermediary computing device and from the sender computing device, the encrypted version of the first encryption key and a message encrypted by the sender computing device using the first encryption key; receiving, by the second intermediary computing device, a request to pass the encrypted message and the encrypted version of the first encryption key to the recipient computing device; and passing, by the second intermediary computing device and to the recipient computing device, the encrypted version of the first encryption key and the message encrypted by the sender computing device using the first encryption key. In some cases, the method includes verifying, by the intermediary computing device, that the sender computing device is authorized to request encryption of the first encryption key in response to receiving the first encryption key from the sender computing device. In some cases, the first encryption key is encrypted using a symmetric encryption process. In some cases, the first encryption key is encrypted using an asymmetric encryption process.
- Another example embodiment provides a method including receiving, by a second intermediary computing device, an encrypted message to be passed between a sender computing device and a recipient computing device. The message is encrypted by the sender computing device using a first encryption key. The method further includes receiving an encrypted version of the first encryption key encrypted by a first intermediary device that is separate, independent, and distinct from the second intermediary computing device. The method further includes receiving, by the second intermediary computing device, a request to pass the encrypted message and the encrypted version of the first encryption key to a recipient computing device. The method further includes passing, by the second intermediary computing device, the encrypted message and the encrypted version of the first encryption key to the recipient computing device, the encrypted version of the first encryption key being encrypted by the first intermediary computing device using a second encryption key located at the first intermediary device. In some cases, the method includes verifying, by the second intermediary computing device, that the recipient computing device is authorized to request passing of the encrypted message to the recipient computing device based on a recipient identifier (RID) associated with the recipient computing device prior to sending the encrypted message to the recipient computing device. In some cases, the method includes receiving, by the first intermediary computing device, the first encryption key used by the sender computing device for encrypting the message; encrypting, by the first intermediary computing device, the first encryption key using the second encryption key located at the first intermediary device to produce the encrypted version of the first encryption key; sending, by the first intermediary computing device, the encrypted version of the first encryption key to the sender computing device for inclusion with the message to be passed to the recipient computing device; receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient computing device subsequent to receipt of the message from the sender computing device; decrypting, by the first intermediary computing device, the encrypted version of the first encryption key using the second encryption key to produce a decrypted version of the first encryption key; and sending, by the intermediary computing device, the decrypted version of the first encryption key to the recipient computing device for decrypting the message. In some cases, the method includes receiving, by the first intermediary computing device, the encrypted version of the first encryption key from the recipient, and verifying that the recipient is authorized to request decryption of the encrypted first encryption key based on a recipient identifier (RID) associated with the recipient computing device prior to decrypting the encrypted MEK. In some cases, the first encryption key is encrypted using a symmetric encryption process. In some cases, the first encryption key is encrypted using an asymmetric encryption process.
- Yet another example embodiment provides a system for secure message passing. The system includes a first intermediary including a first memory and at least one first processor coupled to the first memory, where the first intermediary is configured to receive a message encryption key (“MEK”) generated by a sender computing device for encrypting a message located at the sender computing device, the message to be passed between the sender computing device and a recipient computing device; encrypt the MEK using a guard key located at the first intermediary to produce an encrypted version of the MEK; send the encrypted version of the MEK to the sender computing device for inclusion with the message; receive the encrypted version of the MEK from the recipient computing device; decrypt the encrypted MEK using the guard key located at the first intermediary to produce a decrypted version of the MEK; and send the decrypted version of the MEK to the recipient computing device for decrypting the message. The system further includes a second intermediary including a second memory and at least one second processor coupled to the second memory, where the second intermediary is separate, independent, and distinct from the first intermediary and configured to receive, from the sender computing device, the encrypted version of the MEK and the message encrypted by the sender computing device using the MEK; receive a request to transmit the encrypted message and the encrypted version of the MEK to the recipient computing device; and send, to the recipient computing device, the encrypted version of the MEK and the message encrypted by the sender computing device using the MEK. In some cases, first intermediary is further configured to digitally sign the encrypted version of the MEK and a recipient identifier (“RID”) associated with the recipient computing device. In some cases, the first intermediary is further configured to receive the digitally signed and encrypted version of the MEK from the recipient, and to verify that the recipient is authorized to request decryption of the encrypted version of the MEK based on the RID prior to decrypting the encrypted MEK. In some cases, the first intermediary is further configured to verify that the sender computing device is authorized to request encryption of the MEK in response to receiving the MEK from the sender computing device. In some cases, the sender computing device is configured to encrypt a message using the MEK, and the recipient computing device is configured to decrypt the message using the decrypted MEK. In some cases, the MEK is encrypted using a symmetric encryption process.
- Other aspects, examples, and advantages of these aspects and examples, are discussed in detail below. It will be understood that the foregoing information and the following detailed description are merely illustrative examples of various aspects and features and are intended to provide an overview or framework for understanding the nature and character of the claimed aspects and examples. Any example or feature disclosed herein can be combined with any other example or feature. References to different examples are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the example can be included in at least one example. Thus, terms like “other” and “another” when referring to the examples described herein are not intended to communicate any sort of exclusivity or grouping of features but rather are included to promote readability.
- Various aspects of at least one example are discussed below with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide an illustration and a further understanding of the various aspects and are incorporated in and constitute a part of this specification but are not intended as a definition of the limits of any particular example. The drawings, together with the remainder of the specification, serve to explain principles and operations of the described and claimed aspects. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure.
-
FIG. 1 is a schematic diagram of an example message passing process, in accordance with an embodiment of the present disclosure. -
FIG. 2 is a schematic diagram of another example message passing process, in accordance with an embodiment of the present disclosure. -
FIG. 3 is a schematic diagram of yet another example message passing process, in accordance with an embodiment of the present disclosure. -
FIG. 4 is a schematic diagram of an example secure message passing process, in accordance with an embodiment of the present disclosure. -
FIG. 5 is a data flow diagram corresponding to the example secure message passing process ofFIG. 4 . -
FIG. 6 is a flow diagram for an example secure message passing process, in accordance with an embodiment of the present disclosure. -
FIG. 7 is a block diagram of a computing platform configured to perform a secure message passing process, in accordance with an example of the present disclosure. - As noted above, intermediaries can be used to convey messages from a sender to a recipient where the recipient is unavailable to receive a message directly from the sender. However, while techniques that make use of intermediaries can be effective in highly controlled environments, their use is nevertheless vulnerable to attacks that seek to circumvent established security measures and to exploit weaknesses and vulnerabilities in their implementation. These techniques also have a high degree of cost and complexity when implemented at a large scale due to the need to establish the trusted relationships at the intermediaries or to create, maintain, and exchange many encryption/decryption keys among the entities.
- To this end, techniques that overcome these vulnerabilities, costs, and complexities are provided for secure message passing using semi-trusted intermediaries. In accordance with an embodiment of the present disclosure, a computing device hosting as a sender process has a clear (non-encrypted) message to pass, send, or otherwise transmit to another computing device hosting a recipient process. The sender generates a symmetric message encryption key (MEK) for encrypting the message and sends the MEK to a first intermediary process with a request for the first intermediary to encrypt the MEK. The sender also includes, in the request, a recipient identifier (RID) uniquely associated with the recipient. The RID can, for example, include any unique identifier within an authentication realm used by the system. For example, in Microsoft Active Directory, the RID is a Security Identifier (SID). In some authentication systems, the RID can be a user or a service identifier, or any other values that can be used to uniquely identify the recipient of the message. The first intermediary verifies that the sender is authorized to request key encryption. The first intermediary has its own key, also referred to as a guard key, which is used to generate an encrypted version of the MEK (that is, to encrypt the original MEK) and an encrypted version of the RID (that is, to encrypt the original RID). The combination of the encrypted MEK and encrypted RID can be signed together by the first intermediary for additional security so that the first intermediary can subsequently verify that the encrypted MEK and RID were previously processed by the first intermediary. The first intermediary returns the encrypted/signed MEK/RID back to the sender. Next, the sender uses the originally generated (non-encrypted) MEK to encrypt the message. The sender then sends the encrypted message, the RID, and the encrypted/signed MEK/RID to a second intermediary process (for example, a message repository), which verifies that the sender is authorized to send messages and retains the data for the recipient. The second intermediary process uses the RID to identify the intended recipient of the message. In some embodiments, the second intermediary can notify or otherwise inform the recipient to notify the recipient (and optionally the sender) that the message is available to retrieve. Next, the recipient attempts to retrieve the encrypted message and the encrypted/signed MEK/RID from the second intermediary. The recipient can use any suitable technique for retrieving the encrypted message. For example, the recipient can poll the second intermediary on a periodic or non-periodic basis to request delivery of any messages that the second intermediary is retaining on behalf of the recipient. When the recipient attempts to retrieve the encrypted message, the second intermediary verifies that the recipient identity matches the RID and authorizes the request. The recipient receives the encrypted message and the encrypted/signed MEK/RID from the second intermediary and requests decryption of the encrypted MEK from the first intermediary. The first intermediary verifies that the combined encrypted MEK/RID was signed by the first intermediary and that the recipient identity matches the RID and then decrypts the MEK and returns it to the recipient. Finally, the recipient decrypts the message using the MEK. The first and second intermediaries are considered semi-trusted because neither is trusted to store or process an unencrypted message, but they are trusted to reliably encrypt keys, store encrypted messages, and only allow access to the designated senders and recipients.
- Embodiments of the present disclosure use symmetric encryption and separation of the intermediaries to provide a simple, low cost, and high-performance option that increases security while preserving simplicity, as compared to a fully trusted intermediary, and decreases complexity without sacrificing security, as compared to encrypting messages with asymmetric keys for each recipient. Message confidentiality is maintained by encrypting the message at the sender and decrypting the message at the recipient—only the sender and the recipient have access to the clear, unencrypted message. In certain embodiments, at least two semi-trusted intermediaries are used—one for key encryption/decryption, and one for message and key passing. Since there are at least two intermediaries, an attack on one of them by an attacker will not result in a breach. Furthermore, because the intermediaries are separate, independent, and distinct, an infrastructure owner will be afforded additional time to detect and address an active attack before both intermediaries are compromised. However, despite having at least two intermediaries, there is no requirement for two persistent data stores because the first intermediary is stateless. In other words, the first intermediary does not store any data that it receives or generates as part of the secure message passing process. Rather, the first intermediary holds a single “guard” key that is used by the first intermediary to encrypt and decrypt a message encryption key that is used by the sender to encrypt the message and by the recipient to decrypt the message. The encrypted message encryption key is passed from the sender to the recipient via the second intermediary along with the encrypted message. This means that deployment cost and complexity are comparable to using a fully trusted intermediary. This reduces the costs and complexities of managing the message encryption key in a large or dynamic environment as compared to a scheme where every sender and recipient is required to have its own public and private encryption key. The disclosed techniques thus avoid such costs and complexities in any size environment.
- Embodiments of the present disclosure can be implemented on a wide range of platforms, including Microsoft Windows® or other platforms, such as mobile computing platforms and Internet-of-Things (IoT) devices where low power requirements may restrict usage of asymmetric encryption techniques.
- Examples of the methods and systems discussed herein are not limited in application to the details of construction and the arrangement of components set forth in the following description or illustrated in the accompanying drawings. The methods and systems are capable of implementation in other examples and of being practiced or of being carried out in various ways. Examples of specific implementations are provided herein for illustrative purposes only and are not intended to be limiting. In particular, acts, components, elements and features discussed in connection with any one or more examples are not intended to be excluded from a similar role in any other examples.
- As used herein, in addition to its plain and ordinary meaning, the term “message” refers to any data or information that is sent, passed, or otherwise transmitted from one computing service, device, or computer-implemented process to another by any means of transmission, such as electronically, optically, acoustically, electromagnetically, or using any other suitable type of communications.
- As used herein, in addition to its plain and ordinary meaning, the term “sender” refers to any computer-implemented process with a unique, verifiable identity, such as a sender of a message to one or more recipients. For example, the sender can be associated with a user or a computing device used to send and receive messages.
- As used herein, in addition to its plain and ordinary meaning, the terms “encryption” and “decryption,” respectively, refer to any process or processes that transform a message or other data into or out of a form that is unintelligible. For example, an encrypted message is a message that is unintelligible, while a decrypted message is intelligible, without additional transformation, to at least one entity.
- As used herein, in addition to its plain and ordinary meaning, the term “recipient” refers to any computer-implemented process with a unique, verifiable identity, such as a recipient of a message passed from another entity (e.g., a sender). The recipient can be associated with a user or a computing device used to send and receive messages.
- As used herein, in addition to its plain and ordinary meaning, the term “intermediary” refers to an agent located along the transmission path of a message between the sender and the recipient of the message. The intermediary is, in some embodiments, a computer-implemented process that acts as an authorization authority to verify that the sender and the recipient are authorized to access the services provided by the intermediaries.
- It should be noted that, in some embodiments, one or more of the processes described herein (e.g., the sender, the recipient, and the intermediaries) can each implement and expose an application program interface (API) configured to receive and respond to calls from one another. For instance, the intermediaries can each implement and expose an API configured to receive and respond to calls from the sender and the recipient. These APIs enable the processes to interoperate, in some embodiments. Further, in some embodiments, one or more of the processes described above can each include local storage allocated for the private use of the process.
- As noted above, there are at least two common techniques of secure message passing between two or more computer-implemented processes that utilize intermediaries. These techniques include using trusted intermediaries to convey the message and encrypting at a message to prevent unauthorized access to the data. While these techniques are effective in controlled environments, they are also vulnerable to attacks by entities seeking to circumvent the security measures and to exploit weaknesses and vulnerabilities in their implementation. For instance, in one example, a trusted intermediary is an agent located between the sender and the recipient of a message. The trusted intermediary conveys a clear-text message between entities. However, securing a large number of clear-text messages at rest (i.e., in storage) and during processing is expensive. Also, the intermediary must itself be secured from attacks that could compromise data stored with the intermediary, such as the clear-text messages, which creates a very valuable target to breach as all such messages will be available for the attacker once the trusted intermediary is breached. Encryption provides security but introduces other costs and complexities resulting from the difficulty of distributing and managing the keys used for encrypting and decrypting a message in a large-scale environment.
- In accordance with various embodiments of the present disclosure, it will be understood that one or more secure communication channels exist or can be created between processes exchanging messages, such as from a sender to a recipient, using existing techniques. Furthermore, it will be understood that all processes, including the sender, the recipient, and any intermediaries, can be configured to reliably authenticate the identity of other processes using existing techniques. As noted above, one or more intermediaries can be used to pass messages from the sender to the recipient when the recipient is unreachable directly from the sender. The use of intermediaries for message passing, in accordance with certain embodiments, is useful because neither the sender nor the recipient is directly reachable from one another or not always available. The intermediaries provide a “man in the middle” that is reliably available for the sender to send messages to it and to retain the message until the recipient is available and ready to receive the message.
-
FIG. 1 is a schematic diagram of an examplemessage passing process 100, in accordance with an embodiment of the present disclosure. A sender process (“sender”) 102 sends amessage 104 directly to a recipient process (“recipient”) 106 by passing themessage 104 to therecipient 106. Themessage 104 can include, for example, sensitive or confidential information that is intended only for receipt by therecipient 106. Thesender 102 is separate, independent, and distinct from the recipient 106 (i.e., thesender 102 and therecipient 106 are implemented by at least two different threads). For example, thesender 102 and therecipient 106 can be implemented on physically different computing devices or servers having different network addresses and separate processing and data storage environments. In some cases, thesender 102 and therecipient 106 can be physically or logically isolated from each other, for example, using a network firewall or other suitable security devices for preventing or limiting the exchange of data between thesender 102 and therecipient 106. - In this configuration, there is no intermediary between the
sender 102 and therecipient 106. Therecipient 106 must be reachable and able to receive themessage 104 directly from thesender 102. However, in some cases therecipient 106 may be offline or otherwise unavailable to receive themessage 102. In such cases theprocess 100 is not suitable for message passing. -
FIG. 2 is a schematic diagram of another examplemessage passing process 200, in accordance with an embodiment of the present disclosure. In this configuration, an intermediary process (“intermediary”) 202 is located between asender 102 and arecipient 106. Thesender 102 passes themessage 104 to the intermediary 202 along with a recipient identifier that is associated with therecipient 106. The intermediary 202 receives themessage 104 from thesender 102 and retains themessage 104 until therecipient 106 sends amessage request 204 to the intermediary 202. Therecipient 106 can, for example, send themessage request 204 to the intermediary 202 when therecipient 106 expects to receive themessage 104 or at any other time when therecipient 106 polls the intermediary 202 for messages (for example, polling at certain time intervals or in response to certain events, such as power-up, authentication to a domain controller, etc.). The intermediary 202 replies to themessage request 204 by passing themessage 104 to therecipient 106 if the identity of therecipient 106 matches the recipient identifier. - The
process 200 addresses some of the limitations of theprocess 100. For example, using theprocess 200, therecipient 106 does not need to be reachable from thesender 102 because the intermediary 202 retains themessage 104 until therecipient 106 retrieves it. -
FIG. 3 is a schematic diagram of yet another examplemessage passing process 300, in accordance with an embodiment of the present disclosure. In this configuration, at least two intermediaries (e.g., afirst intermediary 302 and a second intermediary 312) are located between thesender 102 and therecipient 106. Thesender 102 encrypts or otherwise secures themessage 104 using amessage encryption key 306 to produce an encrypted (locked)message 304. Thesender 102 sends the key 306 to thefirst intermediary 302, which stores the key 306. Thesender 102 separately passes theencrypted message 304 to thesecond intermediary 312. Thesecond intermediary 312 retains themessage 304 until it receives arequest 314 for themessage 304 from therecipient 106. Upon receiving themessage request 314, the second intermediary 312 passes theencrypted message 104 to therecipient 106. The key 306, which is stored at thefirst intermediary 302, is passed to therecipient 106 from thefirst intermediary 302 in response to akey request 316 from therecipient 106. The key 306 is then used by therecipient 106 to decrypt (unlock) theencrypted message 304. - According to some embodiments, the key 306 for encrypting and decrypting the
message 104 can, for example, include a random string of bits generated specifically to scramble and/or unscramble data. Such keys can be created using processes designed to ensure that each key is unique and unpredictable. For example, 256-bit Advanced Encryption Standard (AES) keys can be used to encrypt themessage 104. However, it will be understood that any suitable encryption process can be used, including symmetric processes and asymmetric processes. Symmetric, or secret key encryption, uses a single key for both encryption and decryption. Symmetric key encryption is used for encrypting large amounts of data efficiently. 256-bit AES keys are symmetric keys. Asymmetric, or public/private encryption, uses a pair of keys. Data encrypted with one key are decrypted only with the other key in the public/private key pair. When an asymmetric key pair is generated, the public key is typically used to encrypt, and the private key is typically used to decrypt. - As described above, the
first intermediary 302 serves as an agent for exchanging the key 306 between thesender 102 and therecipient 106 in a similar manner as the intermediary 202 serves as an agent for exchanging themessage 104 between thesender 102 and therecipient 106 in theprocess 200 ofFIG. 2 . However, as noted above, instead of receiving themessage 104 from thesender 102, thesender 102 passes the key 306 to thefirst intermediary 302 without themessage 104. Theencrypted message 304 is instead passed from thesender 102 to therecipient 106 via the second intermediary 312 (e.g., a message repository organized to store messages and metadata descriptive of the messages), which retains theencrypted message 304 until therecipient 106 requests delivery. Theunencrypted message 104 is not passed at all. In this manner, thefirst intermediary 302 does not have access to either the original,unencrypted message 104 or theencrypted message 304. - Note that because the
first intermediary 302 does not possess theencrypted message 304, the key 306 alone is useless for accessing the information in themessage 304. This provides an additional layer of protection against an attack of thefirst intermediary 302. In other respects, while theprocess 300 solves the security problem, there are additional cost and management complexities associated with storing and transferring separate encryption keys from the sender(s) 102 to the recipient(s) 106 for each message (for many messages, at scale, this can incur high storage and processing costs). -
FIG. 4 is a schematic diagram of an example securemessage passing process 400, in accordance with an embodiment of the present disclosure. In this configuration, at least two intermediaries (e.g., afirst intermediary 402 and a second intermediary 412) are located between thesender 102 and therecipient 106. Here, the process for encrypting and decrypting themessage 104 is different from theprocess 300 in that thefirst intermediary 402 does not retain the encryption key generated by thesender 102 for encrypting themessage 104. Rather, thefirst intermediary 402 holds a separate “guard” key 408 that is used to encrypt a symmetric message encryption key (MEK) 406, which is generated by thesender 102, as will now be described in further detail. Initially, thesender 102 generates theMEK 406 and passes it to thefirst intermediary 402 along with a request for thefirst intermediary 402 to encrypt theMEK 406. Any suitable technique can be used to generate theMEK 406. For example, theMEK 406 can be randomly generated using a random number generator or pseudorandom number generator. In another example, theMEK 406 can be generated using a passphrase as a hash value and a cryptographic hash function that converts the passphrase into theMEK 406. Thesender 102 also includes a recipient identifier (RID) associated with therecipient 106 with theMEK 406. The RID can, for example, include an identifier that is unique to therecipient 106. Thefirst intermediary 402 then verifies that thesender 102 is authorized to request encryption of theMEK 406. For example, thefirst intermediary 402 can be configured as, or can access, an authorization authority, where thesender 102 is trusted through a separate process. - Once the
first intermediary 402 verifies that thesender 102 is authorized to request encryption of theMEK 406, thefirst intermediary 402 encrypts theMEK 406 using theguard key 408 located at thefirst intermediary 402. Theguard key 408 is unique from other keys in that theguard key 408 is held only by thefirst intermediary 402 and is not shared with any other entity. This is important because only thefirst intermediary 402 can decrypt theMEK 406 once it has been encrypted. In encrypted form, the MEK is not usable as a key for decrypting data, such as themessage 104, that has been encrypted using the original (unencrypted) MEK. In some embodiments, thefirst intermediary 402 also encrypts the RID. The combination of the encrypted MEK and the RID (which is encrypted in certain embodiments and not encrypted in certain other embodiments) are digitally signed together by thefirst intermediary 402 to generate an encrypted/signed MEK/RID 410 and sent back to thesender 102. Thefirst intermediary 402 does not retain the MEK, the encrypted MEK, the RID, or the encrypted/signed MEK/RID 410 after the encrypted/signed MEK/RID 410 is sent back to thesender 102. Thesender 102 then encrypts themessage 104, located at thesender 102, using the original,non-encrypted MEK 406 to produce an encrypted (locked)message 404. For example, a 256-bit AES process can be used to encrypt themessage 104 using theMEK 406. Note that thesender 102 does not share the original,non-encrypted MEK 406 with any entity other than thefirst intermediary 402. - The
sender 102 then passes theencrypted message 404 and the encrypted/signed MEK/RID 410 to thesecond intermediary 412. Thesecond intermediary 412 is separate, independent, and distinct from the first intermediary 402 (i.e., thefirst intermediary 402 and thesecond intermediary 412 are implemented by at least two different execution environments). For example, thefirst intermediary 402 and thesecond intermediary 412 can be implemented on physically different servers having different network addresses and separate processing and data storage environments. In some cases, thefirst intermediary 402 and thesecond intermediary 412 can be physically or logically isolated from each other, for example, using a network firewall or other suitable security devices for preventing or limiting the exchange of data between thefirst intermediary 402 and thesecond intermediary 412. - The
second intermediary 412 then verifies that thesender 102 is authorized to pass theencrypted message 404. For example, thesecond intermediary 412 can be configured as, or can access, an authorization authority, where thesender 102 is trusted through a separate process. If thesender 102 is not authorized to pass theencrypted message 404, then thesecond intermediary 412 deletes or otherwise disposes of theencrypted message 404. Once thesecond intermediary 412 verifies that thesender 102 is authorized to pass theencrypted message 404, thesecond intermediary 412 retains theencrypted message 404. Thesecond intermediary 412 cannot decrypt theencrypted message 404 because thesecond intermediary 412 does not have access to theunencrypted MEK 406 and cannot gain access to theunencrypted MEK 406 since the identity of thesecond intermediary 412 does not match the RID of therecipient 106. Furthermore, thefirst intermediary 402 can be configured to refuse any decryption request from thesecond intermediary 412 or from any entity other than the one with a matching RID (such as the recipient 106) to provide a decryption key, thereby further preventing the second intermediary 412 from decrypting theencrypted message 404. - Next, the
recipient 106 sends amessage request 414 to thesecond intermediary 412, thereby requesting thesecond intermediary 412 to pass theencrypted message 404 and the encrypted/signed MEK/RID 410 to therecipient 106. Therecipient 106 can generate and send therequest message 414 in response to any of a variety of events. For example, therecipient 106 can poll thesecond intermediary 412 on a periodic or non-periodic basis to request delivery of any messages that thesecond intermediary 412 is retaining on behalf of therecipient 106. Thesecond intermediary 412 then verifies, using the RID, that therecipient 106 is authorized to receive theencrypted message 404. For example, as noted above, thesecond intermediary 412 can be configured as, of can access, an authorization authority, where therecipient 106 is trusted through a separate process. Note that in some embodiments the RID is not necessarily used. However, use of the RID or other identifying information helps ensure that the entity requesting delivery of the message (e.g., the recipient 106) is authorized to receive the message. - Once the
second intermediary 412 verifies that therecipient 106 is authorized to receive theencrypted message 404, the second intermediary 412 passes theencrypted message 404 and the encrypted/signed MEK/RID 410 to therecipient 106. Theencrypted message 404 and the encrypted/signed MEK/RID 410 can be passed together or separately. Note that both theencrypted message 404 and the encrypted/signed MEK/RID 410 are needed; without the encrypted/signed MEK/RID 410, theencrypted message 404 cannot be decrypted, and without theencrypted message 404, the encrypted/signed MEK/RID 410 are not useable to obtain the message. - Next, the
recipient 106 sends the encrypted/signed MEK/RID 410 to thefirst intermediary 402 along with a request for thefirst intermediary 402 to decrypt the encrypted MEK. Therecipient 106 also includes the RID in the decryption request to thefirst intermediary 402. Thefirst intermediary 402 then verifies that therecipient 106 is authorized to request decryption of the encrypted MEK and that the RID matches the RID of therecipient 106. For example, as noted above, thefirst intermediary 402 can be configured as, or can access, an authorization authority, where therecipient 106 is trusted through a separate process. In some embodiments, thefirst intermediary 402 also verifies that the combination of the encrypted MEK and RID was previously signed by the first intermediary as an anti-tampering measure. - Once the
first intermediary 402 verifies that therecipient 106 is authorized to request decryption of the encrypted MEK and that the RID matches the RID of therecipient 106, thefirst intermediary 402 decrypts the encrypted MEK using theguard key 408, which as noted above is held only by thefirst intermediary 402 and is not shared with any other entity. The decryptedMEK 406 is then passed to therecipient 106. Therecipient 106 then decrypts theencrypted message 404 using the decryptedMEK 406 to produce the decrypted (unlocked)message 104. - According to some embodiments, the
MEK 406 and the encrypted/signed MEK/RID 410 can, for example, include a random string of bits generated specifically to scramble and/or unscramble data. Such keys can be created using processes designed to ensure that each key is unique and unpredictable. For example, 256-bit AES process keys can be used to encrypt themessage 104. However, it will be understood that any suitable encryption process can be used, including symmetric encryption/decryption processes and asymmetric encryption/decryption processes. It will also be understood that theprocess 400 can be implemented with any number of senders, recipients, and intermediaries. For example, one sender can use theprocess 400 to pass messages to multiple recipients. Similarly, multiple senders can use theprocess 400 to pass messages to a single recipient. Other embodiments and variations will be apparent in light of this disclosure. -
FIG. 5 is a data flow diagram 500 corresponding to the example securemessage passing process 400 ofFIG. 4 , in accordance with an embodiment of the present disclosure. With reference toFIG. 5 : - (1) As discussed above, initially the
sender 102 generates the symmetric message encryption key (MEK) 406 and sends it to afirst intermediary 402 along with a request for thefirst intermediary 402 to encrypt theMEK 406. Thesender 102 also includes a recipient identifier (RID) associated with the recipient in the request to thefirst intermediary 402. Thefirst intermediary 402 then verifies that thesender 102 is authorized to request encryption of theMEK 406. - (2) Once the
first intermediary 402 verifies that thesender 102 is authorized to request encryption of theMEK 406, the first intermediary encrypts theMEK 406 to generate the encrypted MEK. The encrypted combination of the encrypted MEK and the RID are signed by the first intermediary to generate the encrypted/signed MEK/RID and sent back to thesender 102. Thesender 102 then encrypts themessage 104 using the non-encrypted (original)MEK 406 to produce an encrypted (locked)message 404. - (3) The
sender 102 then passes theencrypted message 404 and the encrypted/signed MEK/RID 410 to asecond intermediary 412. Note that thesecond intermediary 412 receives theencrypted message 404 and the encrypted/signed MEK/RID 410, while thefirst intermediary 402 never receives or otherwise has any access to either thenon-encrypted message 104 or theencrypted message 404. This prevents any attack on the first intermediary 402 from accessing the message in either clear or encrypted form. Next, thesecond intermediary 412 verifies that thesender 102 is authorized to pass theencrypted message 404. Once thesecond intermediary 412 verifies that thesender 102 is authorized to pass theencrypted message 404, thesecond intermediary 412 retains theencrypted message 404 and the encrypted/signed MEK/RID 410. - (4) Next, the
recipient 106requests 414 theencrypted message 404 and the encrypted/signed MEK/RID 410 from thesecond intermediary 412. - (5) The
second intermediary 412 then verifies, using the RID, that therecipient 106 is authorized to receive theencrypted message 404. Once thesecond intermediary 412 verifies that therecipient 106 is authorized to receive theencrypted message 404, the second intermediary 412 passes theencrypted message 404 and the encrypted/signed MEK/RID 410 to therecipient 106. - (6) Next, the
recipient 106 sends the encrypted/signed MEK/RID 410 to thefirst intermediary 402 along with a request for thefirst intermediary 402 to decrypt the encrypted MEK. Thefirst intermediary 402 then verifies that therecipient 106 is authorized to request decryption of the encrypted MEK, that the RID matches the RID of therecipient 106, and that the combination of the encrypted MEK and RID was previously signed by thefirst intermediary 402. - (7) Once the
first intermediary 402 verifies that therecipient 106 is authorized to request decryption of the encrypted MEK, that the RID matches the RID of therecipient 106, and that the combination of the encrypted MEK and RID was previously signed by thefirst intermediary 402, thefirst intermediary 402 decrypts the encrypted MEK. The decryptedMEK 406 is then passed to therecipient 106. - (8) The
recipient 106 then decrypts theencrypted message 404 using the decryptedMEK 406 to produce the decrypted (unlocked)message 104. -
FIG. 6 is a flow diagram for an example securemessage passing process 600, in accordance with an embodiment of the present disclosure. Initially a computer-implemented process acting as a sender (e.g., thesender 102 ofFIG. 4 ) generates 601 a symmetric message encryption key (MEK) and sends it to another computer-implemented process acting as a guard (e.g., the first intermediary (guard) 402 ofFIG. 4 ) along with a request for the guard to encrypt the MEK. Themethod 600 includes receiving 602, by the guard, the MEK. In some embodiments, receiving 602 the MEK further includes receiving a recipient identifier (RID) associated with another computer-implemented process identified by the sender as a recipient (therecipient 106 ofFIG. 4 ). The RID can, for example, include any set of values that can be used to uniquely identify the recipient. The guard verifies that the sender is authorized to request encryption of the MEK. Themethod 600 further includes encrypting 604, by the MEK using a key accessible only to the guard. In some embodiments, the combination of the encrypted MEK and the RID is signed 604 by the guard using the guard key to generate an encrypted/signed MEK and RID. Themethod 600 further includes sending 606, by the guard, the encrypted/signed MEK/RID to the sender. - In some embodiments, the
method 600 includes encrypting 608, by the sender, a message using the non-encrypted MEK to produce an encrypted (locked) message. The sender then passes the encrypted message and the encrypted/signed MEK/RID to another computer-implemented process acting as a message repository (e.g., the second intermediary (message repository) 412 ofFIG. 4 ). Themethod 600 further includes receiving 610, by the message repository, the encrypted message and the encrypted/signed MEK/RID. Note that the message repository receives and retains the encrypted message and the encrypted/signed MEK/RID, while the guard never receives or otherwise has any access to either the non-encrypted message or the encrypted message. This prevents any attack on the guard from accessing the message in either clear or encrypted form. The message repository then verifies that the sender is authorized to pass the encrypted message. Once the message repository verifies that the sender is authorized to pass the encrypted message, the message repository retains the encrypted message. - Next, the recipient requests the encrypted message and the encrypted/signed MEK/RID from the message repository. The message repository then verifies, using the RID, that the recipient is authorized to receive the encrypted message. Once the message repository verifies that the recipient is authorized to receive the encrypted message, the
method 600 continues with passing 612, by the message repository, the encrypted message and the encrypted/signed MEK/RID to the recipient. - Next, the recipient sends 613 the encrypted/signed MEK/RID to the guard along with a request for the guard to decrypt the encrypted MEK. The
method 600 further includes receiving 614, by the guard, the encrypted MEK. 402. In some embodiments, the guard verifies that the recipient is authorized to request decryption of the encrypted MEK and that the RID matches the RID of the recipient. Once the guard verifies that the recipient is authorized to request decryption of the encrypted MEK, that the RID matches the RID of the recipient, and that the combination of the encrypted MEK and RID was previously signed by the guard, themethod 600 continues with decrypting 616, by the guard, the encrypted MEK. Themethod 600 further includes sending 618, by the guard, the decrypted MEK to the recipient. In some embodiments, themethod 600 includes decrypting 620, by the recipient, the encrypted message using the decryptedMEK 406 to produce the decrypted (unlocked) message. -
FIG. 7 is a block diagram of acomputing platform 700 configured to perform a secure message passing process, in accordance with an example of the present disclosure. In some cases, theplatform 700 may be a workstation, a laptop computer, a tablet, a mobile device, or any suitable computing or communication device. - The computing platform or
device 700 includes one ormore processors 710, volatile memory 720 (e.g., random access memory (RAM)),non-volatile memory 730, one or more network orcommunication interfaces 740, a user interface (UI) 760, adisplay screen 770, and acommunications bus 750. Thecomputing platform 700 may also be referred to as a computer or a computer system. - The non-volatile (non-transitory)
memory 730 can include: one or more hard disk drives (HDDs) or other magnetic or optical storage media; one or more solid state drives (SSDs), such as a flash drive or other solid-state storage media; one or more hybrid magnetic and solid-state drives; and/or one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof. - The
user interface 760 can include one or more input/output (I/O) devices (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more biometric scanners, one or more environmental sensors, and one or more accelerometers, etc.). - The
display screen 770 can provide a graphical user interface (GUI) and in some cases, may be a touchscreen or any other suitable display device. - The
non-volatile memory 730 stores an operating system (“OS”) 725, one ormore applications 734, anddata 736 such that, for example, computer instructions of theoperating system 725 and theapplications 734, are executed by processor(s) 710 out of thevolatile memory 720. In some examples, thevolatile memory 720 can include one or more types of RAM and/or a cache memory that can offer a faster response time than a main memory. Data can be entered through theuser interface 760. Various elements of thecomputer platform 700 can communicate via thecommunications bus 750. - The illustrated
computing platform 700 is shown merely as an example computing device and can be implemented by any computing or processing environment with any type of machine or set of machines that can have suitable hardware and/or software capable of operating as described herein. - The processor(s) 710 can be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations can be hard coded into the circuitry or soft coded by way of instructions held in a memory device and executed by the circuitry. A processor can perform the function, operation, or sequence of operations using digital values and/or using analog signals.
- In some examples, the processor can be embodied in one or more application specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multicore processors, or general-purpose computers with associated memory.
- The
processor 710 can be analog, digital or mixed. In some examples, theprocessor 710 can be one or more physical processors, or one or more virtual (e.g., remotely located or cloud) processors. A processor including multiple processor cores and/or multiple processors can provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data. - The network interfaces 740 can include one or more interfaces to enable the
computing platform 700 to access acomputer network 780 such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless connections, including cellular connections. In some examples, thenetwork 780 may allow for communication withother computing platforms 790, to enable distributed computing. In some examples, thenetwork 780 may allow for communication with the one or more of thesender 102, therecipient 106, the intermediary 202 or 302, thefirst intermediary 402, and thesecond intermediary 412 ofFIGS. 1-4 . - The foregoing description and drawings of various embodiments are presented by way of example only. These examples are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Alterations, modifications, and variations will be apparent in light of this disclosure and are intended to be within the scope of the invention as set forth in the claims.
- Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Any references to examples, components, elements or acts of the systems and methods herein referred to in the singular can also embrace examples including a plurality, and any references in plural to any example, component, element or act herein can also embrace examples including only a singularity. References in the singular or plural form are not intended to limit the presently disclosed systems or methods, their components, acts, or elements. The use herein of “including,” “comprising,” “having,” “containing,” “involving,” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. References to “or” can be construed as inclusive so that any terms described using “or” can indicate any of a single, more than one, and all of the described terms. In addition, in the event of inconsistent usages of terms between this document and documents incorporated herein by reference, the term usage in the incorporated references is supplementary to that of this document; for irreconcilable inconsistencies, the term usage in this document controls.
Claims (21)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/479,291 US20220006795A1 (en) | 2020-01-29 | 2021-09-20 | Secure message passing using semi-trusted intermediaries |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/775,901 US11159497B2 (en) | 2020-01-29 | 2020-01-29 | Secure message passing using semi-trusted intermediaries |
US17/479,291 US20220006795A1 (en) | 2020-01-29 | 2021-09-20 | Secure message passing using semi-trusted intermediaries |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/775,901 Continuation US11159497B2 (en) | 2020-01-29 | 2020-01-29 | Secure message passing using semi-trusted intermediaries |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220006795A1 true US20220006795A1 (en) | 2022-01-06 |
Family
ID=73646588
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/775,901 Active 2040-03-08 US11159497B2 (en) | 2020-01-29 | 2020-01-29 | Secure message passing using semi-trusted intermediaries |
US17/479,291 Pending US20220006795A1 (en) | 2020-01-29 | 2021-09-20 | Secure message passing using semi-trusted intermediaries |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/775,901 Active 2040-03-08 US11159497B2 (en) | 2020-01-29 | 2020-01-29 | Secure message passing using semi-trusted intermediaries |
Country Status (6)
Country | Link |
---|---|
US (2) | US11159497B2 (en) |
EP (1) | EP4078915A1 (en) |
JP (1) | JP2022522555A (en) |
CN (1) | CN113475038A (en) |
AU (1) | AU2020286292B2 (en) |
WO (1) | WO2021154368A1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10049218B2 (en) | 2016-12-07 | 2018-08-14 | Google Llc | Rollback resistant security |
Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020169961A1 (en) * | 2001-05-10 | 2002-11-14 | International Business Machines Corporation | Method and apparatus for serving content from a semi-trusted server |
US20030204722A1 (en) * | 2002-04-26 | 2003-10-30 | Isadore Schoen | Instant messaging apparatus and method with instant messaging secure policy certificates |
US20050138353A1 (en) * | 2003-12-22 | 2005-06-23 | Terence Spies | Identity-based-encryption message management system |
US20050220095A1 (en) * | 2004-03-31 | 2005-10-06 | Sankaran Narayanan | Signing and validating Session Initiation Protocol routing headers |
US20060212706A1 (en) * | 2005-03-18 | 2006-09-21 | Microsoft Corporation | Scalable session management |
US20080165972A1 (en) * | 2007-01-08 | 2008-07-10 | I-Fax.Com Inc. | Method and system for encrypted email communication |
US20090307490A1 (en) * | 2006-02-02 | 2009-12-10 | Identum Limited | Electronic data communication system |
US20120284516A1 (en) * | 2006-08-24 | 2012-11-08 | Privacydatasystems, Inc. | Cross-domain collaborative systems and methods |
US20130326218A1 (en) * | 2012-05-31 | 2013-12-05 | Lloyd Leon Burch | Techniques for secure message offloading |
US20140020047A1 (en) * | 2012-07-16 | 2014-01-16 | Nicholas Liebmann | Cloud email message scanning with local policy application in a network environment |
US8726009B1 (en) * | 2010-01-26 | 2014-05-13 | David P. Cook | Secure messaging using a trusted third party |
US9077709B1 (en) * | 2012-01-31 | 2015-07-07 | Teradici Corporation | Method for authenticated communications incorporating intermediary appliances |
US20170264628A1 (en) * | 2015-09-18 | 2017-09-14 | Palo Alto Networks, Inc. | Automated insider threat prevention |
US9832179B2 (en) * | 2015-02-25 | 2017-11-28 | Red Hat Israel, Ltd. | Stateless server-based encryption associated with a distribution list |
US20180205686A1 (en) * | 2015-07-06 | 2018-07-19 | Cryptomill Inc. | System and method for providing privacy control to message based communications |
US20190020633A1 (en) * | 2017-07-12 | 2019-01-17 | Wickr Inc. | Provisioning Ephemeral Key Pools for Sending and Receiving Secure Communications |
US20200084222A1 (en) * | 2018-09-12 | 2020-03-12 | Grid7 Llc D/B/A Taekion | Data Packet Security with Expiring Time-Based Hash Message Authentication Codes (HMACs) |
US20200204357A1 (en) * | 2018-12-20 | 2020-06-25 | Fortanix, Inc. | Obtaining quorum approval to perform an operation with a cryptographic item of a key management system |
Family Cites Families (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6959288B1 (en) * | 1998-08-13 | 2005-10-25 | International Business Machines Corporation | Digital content preparation system |
US6697942B1 (en) * | 1999-02-04 | 2004-02-24 | Earthlink, Inc. | Method for remotely managing a remote device using an electronic mail message |
US7096355B1 (en) * | 1999-04-26 | 2006-08-22 | Omniva Corporation | Dynamic encoding algorithms and inline message decryption |
US6912285B2 (en) * | 2000-02-24 | 2005-06-28 | Tumbleweed Communications Corp. | Mechanism for efficient private bulk messaging |
US8972717B2 (en) * | 2000-06-15 | 2015-03-03 | Zixcorp Systems, Inc. | Automatic delivery selection for electronic content |
AU779440B2 (en) * | 2000-06-21 | 2005-01-27 | Sony Corporation | Information recording/reproducing apparatus and method |
WO2002087146A1 (en) * | 2001-04-18 | 2002-10-31 | Pumpkin House Incorporated | Encryption system and control method thereof |
US20030061481A1 (en) * | 2001-09-26 | 2003-03-27 | David Levine | Secure broadcast system and method |
US7221757B2 (en) * | 2002-08-15 | 2007-05-22 | Opentv, Inc. | Method and system for accelerated data encryption |
JP3984570B2 (en) * | 2003-02-12 | 2007-10-03 | 株式会社パンプキンハウス | Program for controlling key management server and verification device in signature / verification system |
JP3919700B2 (en) * | 2003-06-06 | 2007-05-30 | 株式会社モバイル・テクニカ | Cryptographic system and ciphertext processing method thereof |
KR100549504B1 (en) * | 2003-10-10 | 2006-02-03 | 한국전자통신연구원 | Method for creating and verifying simple object access protocol message on web service security using signature encryption |
ATE398866T1 (en) * | 2004-02-27 | 2008-07-15 | Ibm | SYSTEM FOR ACHIEVEING ANONYMOUS COMMUNICATION OF A MESSAGE USING SECRET KEY CRYPTOGRAPHY |
US7370202B2 (en) * | 2004-11-02 | 2008-05-06 | Voltage Security, Inc. | Security device for cryptographic communications |
US8209751B2 (en) * | 2004-11-18 | 2012-06-26 | Biogy, Inc. | Receiving an access key |
WO2006059390A1 (en) * | 2004-12-03 | 2006-06-08 | Mobile Technika Inc. | Encryption system |
JP2006277517A (en) * | 2005-03-30 | 2006-10-12 | Nomura Research Institute Ltd | File transfer system and file transfer method |
US7949138B2 (en) * | 2005-06-30 | 2011-05-24 | Microsoft Corporation | Secure instant messaging |
US8503681B1 (en) * | 2005-11-04 | 2013-08-06 | Cisco Technology, Inc. | Method and system to securely transport data encryption keys |
US20070269041A1 (en) * | 2005-12-22 | 2007-11-22 | Rajat Bhatnagar | Method and apparatus for secure messaging |
US8082446B1 (en) * | 2006-11-30 | 2011-12-20 | Media Sourcery, Inc. | System and method for non-repudiation within a public key infrastructure |
US20080162527A1 (en) * | 2006-12-29 | 2008-07-03 | Ceelox Inc. | System and method for secure and/or interactive dissemination of information |
CN101715638A (en) * | 2007-03-20 | 2010-05-26 | 迪姆威奇软件有限责任公司 | Secure electronic messaging system requiring key retrieval for deriving decryption key |
JP5361031B2 (en) * | 2008-01-07 | 2013-12-04 | アルパイン株式会社 | Cryptographic authentication processing method and apparatus |
WO2009153974A1 (en) * | 2008-06-20 | 2009-12-23 | コニカミノルタホールディングス株式会社 | Data management system, data management method, and computer program |
US8194858B2 (en) * | 2009-02-19 | 2012-06-05 | Physical Optics Corporation | Chaotic cipher system and method for secure communication |
US20100313016A1 (en) * | 2009-06-04 | 2010-12-09 | Microsoft Corporation | Transport Pipeline Decryption for Content-Scanning Agents |
GB2476045B (en) * | 2009-12-08 | 2015-04-22 | Metaswitch Networks Ltd | Provision of text messaging services |
US8769260B1 (en) * | 2012-04-10 | 2014-07-01 | Trend Micro Incorporated | Messaging system with user-friendly encryption and decryption |
US9960919B2 (en) * | 2013-01-08 | 2018-05-01 | Bar-Ilan University | Method for providing security using secure computation |
EP2955897B1 (en) * | 2013-03-05 | 2018-08-01 | Huawei Technologies Co., Ltd. | Key interaction method and device |
JP6573600B2 (en) * | 2013-04-25 | 2019-09-11 | ツリーボックス・ソリューションズ・ピーティーイー・リミテッド | A method performed by at least one server for processing data packets from a first computing device to a second computing device to allow end-to-end encrypted communication |
US20150180845A1 (en) * | 2013-12-19 | 2015-06-25 | Robert Uomini | Electronic mail system and methods |
US10979393B2 (en) * | 2016-01-11 | 2021-04-13 | Mimecast North America, Inc. | Identity-based messaging security |
FR3057123A1 (en) * | 2016-09-30 | 2018-04-06 | Orange | METHOD AND SYSTEM FOR DETECTING INTRUSIONS ON A NETWORK |
US10298551B1 (en) * | 2016-12-14 | 2019-05-21 | EMC IP Holding Company LLC | Privacy-preserving policy enforcement for messaging |
WO2018208787A1 (en) * | 2017-05-08 | 2018-11-15 | ZeroDB, Inc. | High-performance access management and data protection for distributed messaging applications |
US11095662B2 (en) * | 2017-08-29 | 2021-08-17 | Amazon Technologies, Inc. | Federated messaging |
GB2568966A (en) * | 2017-12-04 | 2019-06-05 | Wellness Tech And Media Group Ltd | An encryption process |
FR3079045B1 (en) * | 2018-03-19 | 2021-12-03 | Psa Automobiles Sa | METHOD OF SENDING DATA FROM A MOTOR VEHICLE AND METHOD OF RECEIVING SUCH DATA BY ANOTHER VEHICLE, THROUGH A RADIO COMMUNICATION CHANNEL. |
-
2020
- 2020-01-29 US US16/775,901 patent/US11159497B2/en active Active
- 2020-11-09 WO PCT/US2020/059670 patent/WO2021154368A1/en unknown
- 2020-11-09 CN CN202080003880.1A patent/CN113475038A/en active Pending
- 2020-11-09 AU AU2020286292A patent/AU2020286292B2/en not_active Expired - Fee Related
- 2020-11-09 JP JP2021502755A patent/JP2022522555A/en active Pending
- 2020-11-09 EP EP20816835.1A patent/EP4078915A1/en not_active Withdrawn
-
2021
- 2021-09-20 US US17/479,291 patent/US20220006795A1/en active Pending
Patent Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020169961A1 (en) * | 2001-05-10 | 2002-11-14 | International Business Machines Corporation | Method and apparatus for serving content from a semi-trusted server |
US20030204722A1 (en) * | 2002-04-26 | 2003-10-30 | Isadore Schoen | Instant messaging apparatus and method with instant messaging secure policy certificates |
US20050138353A1 (en) * | 2003-12-22 | 2005-06-23 | Terence Spies | Identity-based-encryption message management system |
US20050220095A1 (en) * | 2004-03-31 | 2005-10-06 | Sankaran Narayanan | Signing and validating Session Initiation Protocol routing headers |
US20060212706A1 (en) * | 2005-03-18 | 2006-09-21 | Microsoft Corporation | Scalable session management |
US20090307490A1 (en) * | 2006-02-02 | 2009-12-10 | Identum Limited | Electronic data communication system |
US20120284516A1 (en) * | 2006-08-24 | 2012-11-08 | Privacydatasystems, Inc. | Cross-domain collaborative systems and methods |
US20080165972A1 (en) * | 2007-01-08 | 2008-07-10 | I-Fax.Com Inc. | Method and system for encrypted email communication |
US8726009B1 (en) * | 2010-01-26 | 2014-05-13 | David P. Cook | Secure messaging using a trusted third party |
US9077709B1 (en) * | 2012-01-31 | 2015-07-07 | Teradici Corporation | Method for authenticated communications incorporating intermediary appliances |
US20130326218A1 (en) * | 2012-05-31 | 2013-12-05 | Lloyd Leon Burch | Techniques for secure message offloading |
US20140020047A1 (en) * | 2012-07-16 | 2014-01-16 | Nicholas Liebmann | Cloud email message scanning with local policy application in a network environment |
US9832179B2 (en) * | 2015-02-25 | 2017-11-28 | Red Hat Israel, Ltd. | Stateless server-based encryption associated with a distribution list |
US20180205686A1 (en) * | 2015-07-06 | 2018-07-19 | Cryptomill Inc. | System and method for providing privacy control to message based communications |
US20170264628A1 (en) * | 2015-09-18 | 2017-09-14 | Palo Alto Networks, Inc. | Automated insider threat prevention |
US20190020633A1 (en) * | 2017-07-12 | 2019-01-17 | Wickr Inc. | Provisioning Ephemeral Key Pools for Sending and Receiving Secure Communications |
US20200084222A1 (en) * | 2018-09-12 | 2020-03-12 | Grid7 Llc D/B/A Taekion | Data Packet Security with Expiring Time-Based Hash Message Authentication Codes (HMACs) |
US20200204357A1 (en) * | 2018-12-20 | 2020-06-25 | Fortanix, Inc. | Obtaining quorum approval to perform an operation with a cryptographic item of a key management system |
Also Published As
Publication number | Publication date |
---|---|
US11159497B2 (en) | 2021-10-26 |
US20210234845A1 (en) | 2021-07-29 |
AU2020286292A1 (en) | 2021-08-12 |
CN113475038A (en) | 2021-10-01 |
AU2020286292B2 (en) | 2022-12-08 |
JP2022522555A (en) | 2022-04-20 |
EP4078915A1 (en) | 2022-10-26 |
WO2021154368A1 (en) | 2021-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11855767B2 (en) | Methods and systems for distributing encrypted cryptographic data | |
US9805210B2 (en) | Encryption-based data access management | |
US9690954B2 (en) | Securing encrypted virtual hard disks | |
US8489889B1 (en) | Method and apparatus for restricting access to encrypted data | |
JP7160605B2 (en) | Method and system for secure data transfer | |
CN108199838B (en) | Data protection method and device | |
CN104618096A (en) | Method and device for protecting secret key authorized data, and TPM (trusted platform module) secrete key management center | |
JP2022542095A (en) | Hardened secure encryption and decryption system | |
US20220006795A1 (en) | Secure message passing using semi-trusted intermediaries | |
US20230021749A1 (en) | Wrapped Keys with Access Control Predicates | |
CA3104787C (en) | Secure message passing using semi-trusted intermediaries | |
JP6830635B1 (en) | Data management method | |
US11736462B1 (en) | Hybrid content protection architecture for email | |
US11683159B2 (en) | Hybrid content protection architecture |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CITRIX SYSTEMS, INC., FLORIDA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMELOV, ALEXANDR;REEL/FRAME:057531/0576 Effective date: 20200129 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, DELAWARE Free format text: SECURITY INTEREST;ASSIGNOR:CITRIX SYSTEMS, INC.;REEL/FRAME:062079/0001 Effective date: 20220930 |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0470 Effective date: 20220930 Owner name: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT, NEW YORK Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0001 Effective date: 20220930 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062112/0262 Effective date: 20220930 |
|
AS | Assignment |
Owner name: CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.), FLORIDA Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525 Effective date: 20230410 Owner name: CITRIX SYSTEMS, INC., FLORIDA Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525 Effective date: 20230410 Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.);CITRIX SYSTEMS, INC.;REEL/FRAME:063340/0164 Effective date: 20230410 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |