WO2020172977A1 - Dispositifs de réseau et procédés de calcul sécurisé - Google Patents

Dispositifs de réseau et procédés de calcul sécurisé Download PDF

Info

Publication number
WO2020172977A1
WO2020172977A1 PCT/CN2019/083567 CN2019083567W WO2020172977A1 WO 2020172977 A1 WO2020172977 A1 WO 2020172977A1 CN 2019083567 W CN2019083567 W CN 2019083567W WO 2020172977 A1 WO2020172977 A1 WO 2020172977A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
result
secure
secure compute
compute
Prior art date
Application number
PCT/CN2019/083567
Other languages
English (en)
Inventor
Fei Liu
Jun Xu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN201980092430.1A priority Critical patent/CN113454628A/zh
Priority to EP19917406.1A priority patent/EP3850522B1/fr
Publication of WO2020172977A1 publication Critical patent/WO2020172977A1/fr
Priority to US17/359,108 priority patent/US11943359B2/en

Links

Images

Classifications

    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • 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/3218—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • 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
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4517—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using open systems interconnection [OSI] directories, e.g. X.500
    • 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/12—Applying verification of the received information
    • 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/0825—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) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/3218—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the disclosure generally relates to secure compute network devices and methods.
  • Secure compute also known as privacy-preserving compute
  • a zero-knowledge proof is a method by which one party (the prover) can prove to another party (the verifier) that the prover knows a value “x” , without conveying any information apart from the fact that the prover knows the value of “x” .
  • the zero-knowledge proof allows the prover to prove that they know the value of “x” without revealing the value of “x” to the verifier.
  • a network device comprising a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage.
  • the one or more processors execute the instructions to receive and process routing requests in a network.
  • the one or more processors execute the instructions to send an indication into the network that the network device is able to perform a type of secure compute.
  • the one or more processors execute the instructions to perform the type of secure compute based on an input received via the network from an input device.
  • the one or more processors execute the instructions to ensure that a result of the secure compute is trusted as a correct result of the secure compute.
  • the one or more processors execute the instructions to provide the trusted result of the secure compute to a result device connected to the network.
  • the one or more processors execute the instructions to act as a peer to generate the trusted result, by the network device, with other network devices in the network that performed the secure compute.
  • the one or more processors execute the instructions to record the trusted result in a blockchain ledger.
  • the one or more processors execute the instructions to notarize results of the secure compute from a plurality of network devices to produce the trusted result.
  • the one or more processors execute the instructions in a trusted execution environment (TEE) .
  • TEE trusted execution environment
  • the one or more processors execute the instructions to: receive a query, via the network, whether the network device is able to perform the type of secure compute; and respond to the query to indicate that the network device is able to perform the type of secure compute.
  • the one or more processors execute the instructions to add information to a header of a packet when processing the routing requests.
  • the input from the input device comprises a zero-knowledge proof.
  • the one or more processors execute the instructions to verify correctness of the zero-knowledge proof, based on a verification protocol.
  • the one or more processors execute the instructions to: return a result of true to the result device in response to the zero-knowledge proof being correct; and return a result of false to the result device in response to the zero-knowledge proof being incorrect.
  • the one or more processors execute the instructions to route packets in accordance with an Open System Interconnection (OSI) layer 3 protocol.
  • OSI Open System Interconnection
  • the one or more processors execute the instructions to deliver frames in accordance with an Open System Interconnection (OSI) layer 2 protocol.
  • OSI Open System Interconnection
  • the input received via the network from the input device is encrypted.
  • the one or more processors execute the instructions to perform the secure compute without decrypting the input. This allows the input device to keep information private.
  • the network device further comprises a secure compute accelerator configured to perform the secure compute.
  • a computer-implemented method for secure computing comprises receiving and processing, by a network device, routing requests in a network; sending an indication, by the network device, into the network that the network device is able to perform a type of secure compute; performing the type of secure compute, by the network device, based on an input received via the network from an input device; ensuring, by the network device, that a result of the secure compute is trusted as a correct result of the secure compute; and providing the trusted result of the secure compute from the network device to a result device connected to the network.
  • a non-transitory computer-readable medium storing computer instructions for secure computing, that when executed by one or more processors, cause the one or more processors to: receive and process routing requests in a network by a network device; send an indication into the network that the network device is able to perform a type of secure compute; perform the type of secure compute based on an input received via the network from an input device; ensure that a result of the secure compute is trusted as a correct result of the secure compute; and provide the trusted result of the secure compute to a result device connected to the network.
  • FIG. 1 illustrates a communication system in which embodiments may be practiced.
  • FIG. 2 illustrates an embodiment of a network node in accordance with embodiments of the disclosure.
  • FIG. 3 illustrates high level block diagram of a computing system.
  • FIG. 4 illustrates high level block diagram of a computing system that may be used in one embodiment of a network node.
  • FIG. 5 illustrates example user equipment.
  • FIG. 6 is a flowchart of one embodiment of a process of secure computing performed by a network node.
  • FIG. 7 is a flowchart of one embodiment of a process of secure computing.
  • FIG. 8 illustrates an embodiment of a process in which a single network node performs a secure compute.
  • FIG. 9 illustrates an embodiment of a process in which multiple network nodes perform a secure compute.
  • FIG. 10 illustrates an embodiment of a process in which the result of a secure compute is recorded in a blockchain ledger.
  • FIG. 11 depicts an embodiment of a communication system in which a single network node verifies a zero-knowledge proof.
  • FIG. 12 describes a flowchart of one embodiment of a process that may be used in communication system 1100 of FIG. 11.
  • FIG. 13 depicts an embodiment of a communication system in which multiple network nodes verify a zero-knowledge proof, and in which there is a notary node to notarize the results.
  • FIG. 14 depicts a flowchart of one embodiment of a process that may be used in communication system 1300 of FIG. 13.
  • FIG. 15 depicts an embodiment of a communication system in which multiple network nodes, which act as peers in a blockchain network, verify a zero-knowledge proof.
  • FIG. 16 describes a flowchart of one embodiment of a process that may be used in communication system 1500 of FIG. 15.
  • a network device may include, but is not limited to a, router or a switch.
  • Secure compute also known as privacy-preserving compute
  • a network node acts as a “verifier” by verifying whether a zero-knowledge proof that was generated by an input node is correct.
  • a zero-knowledge protocol Three requirements are met by a zero-knowledge protocol: completeness, soundness, and zero-knowledge.
  • completeness means that if the input is true, the zero-knowledge proof always returns “true. ”
  • Soundness means that if the input is false, it is not possible to trick the zero-knowledge proof to return “true. ”
  • Zero knowledge means that if the statement is true, the verifier will have no idea what the statement actually is.
  • MPC secure multi-party computation
  • An MPC protocol allows n “players” to compute a function of their data while maintaining the privacy of their data.
  • a network node computes some function of the data, without the input nodes revealing their data, in one embodiment. For example, two entities that have confidential patient data could perform joint research on the patient data without revealing the confidential patient information. Thus, the network node performs a secure MPC, in one embodiment.
  • Embodiments are not limited to the type of a secure compute being a zero-knowledge proof or a secure multi-party computation. Other types of privacy preserving computes can be implemented.
  • the one or more parties (which are referred to herein as “input nodes” ) encrypt information that is desired to be kept private before sending the encrypted information to one or more network nodes, in one embodiment.
  • the one or more network nodes perform the secure compute without decrypting the encrypted information, in one embodiment. Therefore, the one more network nodes may determine a result of the secure compute while maintaining the privacy of the one or more party’s information.
  • a significant challenge in implementing a secure compute, such as a zero-knowledge proof or an MPC is that it may take a relatively large amount of computer memory and or computation time, which can make it difficult to provide a practical implementation.
  • Embodiments in which the secure compute is performed by a network node move the burden of performing the secure compute from electronic devices that either do not have the computation power and/or for which performing the secure compute would be too burdensome.
  • a secure compute has one correct result, as defined herein.
  • dis-honest entities could attempt to force an incorrect result.
  • the one or more network nodes that perform the secure compute provide some mechanism to ensure that the result of the secure compute can be trusted to be a correct result, in one embodiment.
  • a “trusted result” means that the result of the secure compute can be trusted to be a correct result.
  • Examples of mechanisms to ensure that the result of the secure compute can be trusted to be a correct result include, but are not limited to, multiple network nodes acting as a peer nodes to generate a trusted result, notarizing results of the secure compute from multiple network devices to produce the trusted result, and/or performing the secure compute in a trusted execution environment (TEE) .
  • TEE trusted execution environment
  • routing traffic can be reduced by selection of which network node (s) perform the secure compute.
  • FIG. 1 illustrates a communication system 100 in which embodiments may be practiced.
  • the communication system 100 includes one or more input nodes 102 (also referred to as “input device” ) , one or more result nodes (also referred to as “result device” ) 104, and a number of network nodes (also referred to as “network devices” ) 106.
  • the network nodes 110 reside in one or more networks 110.
  • the network nodes 106 may be routers, switches, etc. At least one of the network nodes 106 is configured to perform a secure compute.
  • a secure compute has one or more inputs and at least one result, in one embodiment.
  • An input node 102 is a node that provides an input to the secure compute.
  • One or more input nodes 102 may provide different inputs to the secure compute, when there are two or more inputs.
  • a result node 104 is a node that receives a result of the secure compute.
  • input node and “result node” refer to the role that the respective nodes play in the secure computes.
  • a node might be an input node with respect to one secure compute and a result node with respect to another secure compute. It is possible for a node to be both an input node and a result node with respect to the same secure compute, when there are more than one input nodes for that secure compute.
  • An input node 102 or a result node 104 could be user equipment (UE) including, but not limited to, wireless transmit/receive unit (UE) , mobile station, fixed or mobile subscriber unit, pager, cellular telephone, personal digital assistant (PDA) , smartphone, laptop, computer, touchpad, wireless sensor, wearable devices or consumer electronics device.
  • UE user equipment
  • PDA personal digital assistant
  • An input node 102 or a result node 104 could be a web server.
  • An input node 102 may also be referred to herein as an input device, which is understood to be an electronic device such as a UE or web server.
  • a result node 104 may also be referred to herein as a result device, which is understood to be an electronic device such as a UE or web server.
  • the network nodes 106 are configured to receive and process routing requests in the network 110.
  • a network node 106 may include, for example, a router or a switch.
  • a network node 106 routes packets between two nodes (e.g., between two input nodes 102, between an input node and a result node 104, between two result nodes 104) in accordance with an Open System Interconnection (OSI) network layer (or layer 3) protocol.
  • OSI Open System Interconnection
  • a network node 106 delivers frames between two nodes in accordance with an Open System Interconnection (OSI) link layer (or layer 2) protocol.
  • OSI Open System Interconnection
  • the network nodes 106 are not limited to these examples for receiving and processing routing requests in the network 110.
  • an MPLS header can be added between the network layer header (i.e., the layer 3 header) and the link layer header (i.e., the layer 2 header) of the Open Systems Interconnection model (OSI model) .
  • OSI model Open Systems Interconnection model
  • At least one of the network nodes 106 is configured to perform a type of secure compute, in one embodiment.
  • the secure compute may also be referred to herein as “privacy-preserving compute. ”
  • One type of a secure compute is a zero-knowledge proof (also referred to as a zero-knowledge protocol) . Zero-knowledge protocols are known to those of ordinary skill in the art. It is not required that all of the network nodes 106 be able to perform the secure compute.
  • an input node 102 or a result node 104 sends a request (or query) into the network 110 to look for one or more network nodes 106 that are capable of performing the type of secure compute.
  • the sender of the query selects one or more of network nodes 106 to perform the secure compute.
  • the sender of the query may look for one or more network nodes 106 that are capable of performing the particular type of zero-knowledge protocol.
  • a zero-knowledge proof may be considered to be a secure two-party computation, where the verifier (e.g., network node 106) verifies the validity of a statement by the prover (e.g., input node 102) .
  • This concept can be extended to secure multiparty computation (MPC) .
  • An MPC protocol allows n “players” to compute a function of their inputs while maintaining the privacy of their inputs.
  • One example of a secure multiparty computation is referred to as a secure sum protocol, which allows multiple parties to compute a function of their individual data without revealing the data to one another.
  • party A has data x1
  • party B has data x2
  • party C has data x2.
  • Each of the parties may be a different input node 102.
  • a network node 106 computes some function of the data, without the inputs nodes 102 revealing their data. For example, two entities that have confidential patient data could perform joint research on the patient data without revealing the confidential patient information. Thus, the network node 106 performs a secure multiparty computation, in one embodiment. Techniques for secure multiparty computation are known to those of ordinary skill in the art.
  • the secure compute may have one or more inputs, from a corresponding one or more input nodes 102.
  • Each of the input nodes that has an input for the secure compute sends its input to each of the selected network nodes 106, in one embodiment.
  • the result of the secure compute is provided to the result node (s) 104.
  • the network nodes 106 are configured to ensure that the result of the secure compute is trusted in one embodiment. In other words, the network nodes 106 are configured to ensure that the result of the secure compute is the correct result. Further details of how the network nodes 106 ensure that the result is trusted are described herein.
  • An input node 102 might be a computer laptop and a result node 104 might be a web server.
  • a user of the computer laptop might be making a purchase on an e-commerce server that includes the web server.
  • One of the network nodes 106 may perform a secure compute related to the purchase.
  • An example of the secure compute is for the network node 106 to verify that the user of the laptop has sufficient monetary funds to make the purchase. This transaction could involve blockchain technology; however, the use of blockchain technology is not required.
  • the network node (s) 106 could perform any type of secure compute.
  • the secure compute allows the input node 102 (or nodes) to keep some input information private, while still allowing the result node 104 to be certain with respect to the input information.
  • the input node 102 could keep private the total amount of money that a user has in an account, while still assuring the result node 104 that the user has sufficient funds to make a purchase.
  • the input nodes 102 keep their information private by encrypting the information before sending it to the network node (s) 106.
  • the network node (s) 106 are able to generate a result for the secure compute without decrypting the information, in one embodiment.
  • the secure compute involves more than one input node 102.
  • An example of this what is sometimes referred to as “the millionaire’s problem. ”
  • the millionaire’s problem two or more people want to determine who has more wealth without revealing their exact wealth to anyone. More generally, this can be viewed as the problem of comparing two numbers to determine which is larger without revealing the actual value of either number.
  • One or more of the network nodes 106 performs a secure compute with respect to these or other problems, which keeps certain inputs from the input nodes 102 private. For example, a network node 106 could determine which of two people has more wealth without either person revealing their wealth to the network node 106.
  • a single network node 106 performs the secure compute.
  • the network node 106 has a trusted execution environment (TEE) , in one embodiment.
  • the secure compute is performed in the TEE, in one embodiment.
  • a TEE is a secure area of a main processor, in one embodiment.
  • a TEE guarantees code and data loaded inside are protected with respect to confidentiality and integrity, in one embodiment. Examples of TEE include, but are not limited to, AMD Platform Security Processor (PSP) , ARM Technology, Intel Trusted Execution Technology, and Security Trusted Execution Environment.
  • PSP Platform Security Processor
  • the network node 106 may send the result to a result node 104.
  • a network node 106 may provide the result to the result node 104.
  • the result node 104 can trust the result to be the correct result due to the use of, for example, the TEE.
  • a security mechanism other than a TEE can be used in conjunction with the network node 106.
  • two or more network nodes 106 perform the same secure compute.
  • Each network node 106 may provide its result of the secure compute to one of the nodes, which may serve as a “notary node” .
  • the notary node may compare the results to determine a final result. For example, if all of the results match, the results may be considered to be the final result, in one embodiment. If the results do not match, the results may be discarded, or majority of the results may be considered to be the final result in one embodiment.
  • the notary node is one of the network nodes 106, in one embodiment.
  • the notary node could be node that is not a network node 106, in which case two or more network nodes 106 send their respective results to the notary node to be notarized, in one embodiment.
  • the notary node could be the result node 104, in which case two or more network nodes 106 send their respective results to the result node 104 to be notarized, in one embodiment.
  • the result node 104 can trust the result to be the correct result due to, for example, the consensus mechanism provided by the notary node.
  • two or more network nodes 106 acts as peer nodes (or more simply “peers” ) to ensure that the result of the secure compute is trusted to be the correct result.
  • Each node may perform the secure compute.
  • the network nodes 106 may act as peers and compare their results.
  • two or more network nodes 106 act as peers in a blockchain network.
  • a blockchain network is comprised of peer nodes, each of which can hold copies of ledger.
  • a network node 106 holds of copy of a blockchain ledger, in one embodiment.
  • the result of the secure compute is recorded in a blockchain ledger, in one embodiment.
  • the result node 104 obtains the result from the blockchain ledger, in one embodiment.
  • one or more network nodes 106 may provide the result to the result node 104.
  • the result node 104 can trust the result to be correct, for example, the consensus mechanism provided by the network nodes 106 acting as peers.
  • FIG. 1 illustrates one example of a communication system
  • the communication system 100 could include any number of input nodes 102, network nodes 106, result nodes 104, or other components in any suitable configuration.
  • FIG. 2 illustrates an embodiment of a network node (e.g., router) in accordance with embodiments of the disclosure.
  • the network node 106 may comprise a plurality of input/output ports 210/230 and/or receivers (Rx) 212 and transmitters (Tx) 232 for receiving and transmitting data from other nodes, a processor 220, including a storage 222, to process data and determine which node to send the data.
  • the processor 220 is not so limited and may comprise multiple processors.
  • the processor 220 may be implemented as one or more central processing unit (CPU) chips, cores (e.g., a multi-core processor) , field-programmable gate arrays (FPGAs) , application specific integrated circuits (ASICs) , and/or digital signal processors (DSPs) , and/or may be part of one or more ASICs.
  • the processor 220 may be configured to implement any of the schemes described herein using any one or combination of steps described in the embodiments.
  • the processor 220 is configured to perform a secure compute.
  • the processor 220 may be implemented using hardware, software, or both.
  • the storage 222 may include cache 224 and long-term storage 226, and may be configured to store routing tables, forwarding tables, or other tables or information disclosed herein. Although illustrated as a single storage, storage 222 may be implemented as a combination of read only memory (ROM) , random access memory (RAM) , or secondary storage (e.g., one or more disk drives or tape drives used for non-volatile storage of data) .
  • the storage 222 contains instructions that may be executed on the processor 220 in order to perform a secure compute, in one embodiment.
  • FIG. 3 illustrates high level block diagram of a computing system 300.
  • the computing system 300 may be used to implement an input node 102, a result node 104, or a network node 106.
  • Specific devices may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device.
  • a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc.
  • the computing system 300 may comprise one or more input/output devices, such as network interfaces, storage interfaces, and the like.
  • the computing system 300 may include a central processing unit (CPU) 310, a memory 320, a mass storage device 330, and an I/O interface 360 connected to a bus 370.
  • the bus may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus or the like.
  • the CPU 310 may comprise any type of electronic data processor.
  • the CPU 310 may be configured to implement any of the schemes described herein, using any one or combination of steps described in the embodiments.
  • the memory 320 may comprise any type of system memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , a combination thereof, or the like.
  • the memory 320 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.
  • the memory 320 is non-transitory.
  • the memory 320 is a non-transitory computer-readable medium storing computer instructions, that when executed by the CPU 310, cause the one or more processors to perform various functionality described herein.
  • the memory 320 comprises software modules that may be executed on the CPU 310.
  • the mass storage device 330 may comprise any type of storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus.
  • the mass storage device 330 may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, or the like.
  • the computing system 300 also includes one or more network interfaces 350, which may comprise wired links, such as an Ethernet cable or the like, and/or wireless links to access nodes or one or more networks 110.
  • the network interface 350 allows the computing system 300 to communicate with remote units via the network 110.
  • the network interface 350 may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas.
  • computing system 300 is coupled to a local-area network or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, remote storage facilities, or the like.
  • the term “network interface” will be understood to include a port.
  • the components depicted in the computing system of Figure 3 are those typically found in computing systems suitable for use with the technology described herein, and are intended to represent a broad category of such computer components that are well known in the art. Many different bus configurations, network platforms, and operating systems can be used.
  • FIG. 4 illustrates high level block diagram of a computing system 400 that may be used in one embodiment of a network node 106.
  • the computing system 400 has some elements in common with computing system 300, which will not be described in detail.
  • the computing system 400 has a CPU 410, mass storage 440, a network interface 450, I/O interface 460 connected to a bus 470.
  • the memory 440 stores various modules.
  • the routing module 440A is configured to receive and process routing requests in a network, such as network 110.
  • the routing module 440A is configured to route packets in accordance with an Open System Interconnection (OSI) layer 3 protocol.
  • the routing module 440A is configured to deliver frames in accordance with an Open System Interconnection (OSI) layer 2 protocol.
  • OSI Open System Interconnection
  • the capability qualifier module 440B is configured to inform other nodes (typically not another network node 106) that the network device 106 is able to perform a particular type (or types) of secure compute.
  • the type of secure compute may indicate a type of zero-knowledge proof, a type of MPC, or some other privacy preserving compute.
  • the capability qualifier module 440B is configured to add information to a packet header that indicates that the network device 106 is able to perform a particular type of secure compute, in one embodiment.
  • the packet header may be for one or more of the packets that are routed by the network device 106.
  • the capability qualifier module 440B is configured to receive a query, via a network, whether the network device 106 is able to perform a particular type of secure compute, in one embodiment.
  • the capability qualifier module 440E is configured to respond to the query to indicate that the network device is able to perform the particular type of secure compute, in one embodiment.
  • the secure compute module 440C is configured to perform a secure compute.
  • a secure compute also known as privacy-preserving compute
  • the secure compute includes a zero-knowledge proof (also referred to as a zero-knowledge protocol) .
  • the secure compute includes a secure MPC.
  • the trust providing module 440D is configured to perform an operation that ensures that the result of the secure compute is the correct result (e.g., is a trusted result) .
  • trust providing module 440D is configured to communicate with other network devices 106 that performed the same secure compute. This may allow, for example, the network device 106 to act as a peer with other network devices in the network that performed the secure compute.
  • the network device 106 is configured to act as a peer node in a blockchain network. By acting as a peer node in a blockchain network when performing the secure compute, the network device 106 helps to ensure that the result of the secure compute is trusted to be correct.
  • the result providing module 440D is configured to provide the result of the secure compute to a result device 104 connected to the network 110.
  • the result is sent from the network device 106 to the result device 104.
  • the network device 106 records the result in a blockchain ledger.
  • the blockchain ledger is stored on the network device 106, in one embodiment.
  • the blockchain ledger could be stored in memory 440 or mass storage 440.
  • the result device 104 obtains the result from the blockchain ledger, in one embodiment.
  • the secure compute may require substantial computation power, in some embodiments.
  • the secure compute accelerator 480 is configured to accelerate the secure compute, in one embodiment.
  • the secure compute accelerator 480 may contain hardware (e.g., a processor and possibly additional memory) .
  • the secure compute accelerator 480 comprises a hardware accelerator, in one embodiment.
  • the hardware accelerator is configured to perform a secure compute, in one embodiment.
  • the secure compute accelerator 480 is specifically designed to perform the secure compute, in one embodiment.
  • the secure compute accelerator 480 is able to perform the secure compute faster than a general purpose processor, in one embodiment.
  • the secure compute accelerator 480 is not required.
  • the secure compute is performed on the CPU 410.
  • FIG. 5 illustrates example user equipment.
  • the user equipment 500 may be used to implement an input node 102 or a result node 104.
  • the user equipment (UE) may for example be a mobile telephone, but may be other devices in further examples such as a desktop computer, laptop computer, tablet, hand-held computing device, automobile computing device and/or other computing devices.
  • the UE 500 includes at least one processor 504.
  • the processor 504 implements various processing operations of the UE 500.
  • the processor 504 may perform signal coding, data processing, power control, input/output processing, or any other functionality enabling the UE 500 to operate in the system 100 (FIG. 1) .
  • the processor 504 may include any suitable processing or computing device configured to perform one or more operations.
  • the processor 504 may include a microprocessor, microcontroller, digital signal processor, field programmable gate array, or application specific integrated circuit.
  • the UE 500 also includes at least one transceiver 502.
  • the transceiver 502 is configured to modulate data or other content for transmission by at least one antenna 510.
  • the transceiver 502 is also configured to demodulate data or other content received by the at least one antenna 510.
  • Each transceiver 502 may include any suitable structure for generating signals for wireless transmission and/or processing signals received wirelessly.
  • Each antenna 510 includes any suitable structure for transmitting and/or receiving wireless signals. It is appreciated that one or multiple transceivers 502 could be used in the UE 500, and one or multiple antennas 510 could be used in the UE 500.
  • a transceiver 502 may also be implemented using at least one transmitter and at least one separate receiver.
  • the UE 500 further includes one or more input/output devices 508.
  • the input/output devices 508 facilitate interaction with a user.
  • Each input/output device 508 includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen.
  • the UE 500 includes at least one memory 506.
  • the memory 506 stores instructions and data used, generated, or collected by the UE 500.
  • the memory 506 could store software or firmware instructions executed by the processor (s) 504 and data used to reduce or eliminate interference in incoming signals.
  • Each memory 506 includes any suitable volatile and/or non-volatile storage and retrieval device (s) . Any suitable type of memory may be used, such as random access memory (RAM) , read only memory (ROM) , hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.
  • RAM random access memory
  • ROM read only memory
  • SIM subscriber identity module
  • SD secure digital
  • FIG. 6 is a flowchart of one embodiment of a process 600 of secure computing.
  • the process 600 is performed by a network node 106, in one embodiment.
  • Step 602 includes receiving and processing routing requests in a network 110.
  • Step 602 includes routing packets in accordance with an Open System Interconnection (OSI) layer 3 protocol, in one embodiment.
  • Step 602 includes delivering frames in accordance with an Open System Interconnection (OSI) layer 2 protocol, in one embodiment.
  • Step 602 includes receiving and processing routing requests in accordance with an MPLS protocol, in one embodiment.
  • OSI Open System Interconnection
  • MPLS protocol MPLS protocol
  • Step 604 includes sending an indication into the network 110 that the network device 106 is able to perform a type of secure compute.
  • step 604 includes the network device 106 adding information to a header of a packet that indicates that the network device 106 is able to perform the type of secure compute.
  • the network device 106 may add information to a header of one or more of the packets.
  • the packet may be a packet that is delivered between the input node 102 and the result node 104; however, this is not required.
  • the network device 106 is one of the network devices 106 that processes a packet transmitted between the input node 102 and result node 104, in one embodiment.
  • the network device 106 responds to a query from, for example, the input node 102 or the result node 104 about the capabilities of the network node 106. For example, the network device 106 may receive a query of whether the network device 106 is able to perform a type of secure compute. This request is received from a node that will be providing input to the secure compute (or an input node 102) , in one embodiment. This request is received from a node that will be receiving the result of the secure compute (or a result node 104) , in one embodiment.
  • Step 606 includes a network node 106 performing the type of secure compute based on an input from the input node (s) 102.
  • the network node 106 may receive an input to the secure compute from each of one or more input nodes 102 prior to step 606, in one embodiment.
  • the network node 106 performs the secure compute based on an input from a single input node 102.
  • the network node 106 performs the secure compute based on a separate input from each of two or more input nodes 102.
  • the network node 106 is one of two or more network nodes 106 that perform the same secure compute.
  • the secure compute includes a zero-knowledge proof.
  • the input node 102 might provide a proof and a verification to the network node 106.
  • the network node 106 may verify the correctness of the zero-knowledge proof, based on the verification key.
  • Step 608 includes the network node 106 ensuring that the result of the secure compute is trusted to be correct.
  • the network node 106 may ensure that the result is trusted to be correct.
  • the network node 106 acts as a peer with other network devices in the network 110 that performed the secure compute to ensure that the result is trusted to be correct.
  • the network node 106 acts as a peer in a blockchain network to ensure that the result is trusted to be correct, in one embodiment.
  • the network node 106 notarizes results of the secure compute from a set of network devices, in one embodiment.
  • the network node 106 performs the secure compute in a TEE to ensure that the result is trusted to be correct, in one embodiment.
  • Step 610 includes the network node 106 providing a result of the secure compute to the result node 104.
  • Step 610 includes providing the result either directly from the network node 106 to the result node 104 or indirectly from the network node 106 to the result node 104.
  • the network node 106 provides the result directly to the result node 104.
  • the network node 106 provides the result directly to a notary node, which provides the final result to the result node 104.
  • the network node 106 adds the result to a blockchain ledger in order to indirectly provide the result to the result node 104. That is, the result node 104 obtains the result from the blockchain ledger in order to indirectly obtain the result from the network node 106.
  • FIG. 7 is a flowchart of one embodiment of a process 700 of secure computing.
  • the process 700 may be performed in communication system 100, but is not limited thereto.
  • there may be one or more input nodes 102, one or more result nodes 104, and one or more network nodes 106 may perform the secure compute.
  • Step 702 includes nodes communicating a desire to perform a secure compute.
  • a result node 104 sends a request to an input node 102 to perform a zero-knowledge proof.
  • This request passes through the network 110, and may be processed by one or more network nodes 106 that are capable of performing secure computes. However, it is possible that none of the network nodes 106 that process the request are capable of performing secure computes.
  • Steps 704 and 705 describe different options for learning which one or more network nodes 106 are capable of performing secure computes. Either or both steps may be performed.
  • Step 704 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 702.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 702.
  • One or more network nodes 106 may respond to the request of step 704, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 705 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 702.
  • a result node 104 or an input node 102 may examine the header of a packet it received from the other node in step 702.
  • the one or more packets are not required to be associated with the communication between the nodes in step 702.
  • Step 706 includes selecting one or more network nodes 106 that is/are capable of performing the secure compute. This selection is based on the network nodes 106 that respond to the request of step 704, in one embodiment. This selection is based on examining the headers of packets in step 705, in one embodiment. In one embodiment, a single network node 106 is selected. In one embodiment, multiple network nodes 106 are selected. The selection is made by a result node 104, in one embodiment. The selection is made by an input node 102, in one embodiment.
  • the selection in step 706 is based on the distance to the network node 106 from the input node 102, in one embodiment.
  • the selection in step 706 is based on the distance to the network node 106 from the result node 104, in one embodiment. For example, in either case a network node 106 having the shortest distance may be selected.
  • the selection in step 706 is based on the route between the input node 102 and the result node 104. For example, the network node 106 can be selected to achieve the shortest route between the input node 102 and the result node 104.
  • the selection in step 706 is based on capabilities of the network node 106, in one embodiment. For example, there may be different algorithms for performing the secure compute. The selection could be made based on which algorithm (s) a network node 106 is able to perform. The selection in step 706 could be based on more than one factor. For example, the selection could be based on both distance (e.g., distance to the network node 106, routing distance between input node 102 and result node 104, etc. ) and capability (e.g., secure compute algorithms which network node 106 is able to perform) . In one embodiment, the network node 106 is selected based on a matrix of factors.
  • Step 708 includes one or more input nodes 102 preparing the input for the secure compute.
  • Step 708 includes each input node 102 encrypting the information that is desired to be kept private, in one embodiment.
  • an input node 102 prepares a zero-knowledge proof. Further details of an input node 102 preparing a zero-knowledge proof are discussed in connection with process 1200 in FIG. 12 (see, for example, step 1208) .
  • the input in step 708 is not limited to being a zero-knowledge proof.
  • Step 708 may include each node of an MPC preparing their respective inputs. For example, process 700 might be used to allow several parties to place a bid without revealing the actual bid by, for example, encrypting the bids.
  • Step 710 includes the one or more input nodes 102 sending their respective input to each of the one or more selected network nodes 106.
  • Step 712 includes each of the one or more selected network nodes 106 performing the secure compute.
  • each network node 106 verifies the zero-knowledge proof.
  • each network node 106 performs an MPC.
  • Step 714 includes ensuring that that the results of the secure compute is trusted to be correct.
  • the trust is ensured by a security mechanism on the network node 106.
  • the network node 106 may perform the secure compute in a TEE.
  • the trust is ensured by multiple network nodes 106 sending the result of the secure compute to a notary node, which notarizes the result.
  • notarizing the result it is meant that the notary compares the results from the multiple network nodes 106 to verify that the result can be trusted to be correct.
  • the result can be trusted if all of the results are the same.
  • the trust is ensured by multiple network nodes 106 acting as peers in a blockchain network, and recording the result into the blockchain ledger.
  • Step 716 includes one or more result nodes 104 obtaining the result.
  • a result node 104 obtains the result directly from a network node 106 that performed the secure compute.
  • a result node 104 obtains the result indirectly from a notary node that notarized the result.
  • a result node 104 obtains the result from a blockchain ledger, into which the result has been recorded.
  • FIGs. 8, 9, and 10 describe three different embodiments of secure compute. These are three different embodiments of process 700.
  • FIG. 8 describes an embodiment in which a single network node 106 performs the secure compute.
  • FIG. 9 describes an embodiment in which multiple network nodes 106 perform the secure compute.
  • FIG. 10 describes an embodiment in which the result of the secure compute is recorded in a blockchain ledger.
  • process 800 may be performed in communication system 100, but is not limited thereto.
  • process 800 there may be one or more input nodes 102, and one or more result nodes 104.
  • Step 802 includes nodes communicating a desire to perform a secure compute.
  • a result node 104 sends a request to an input node 102 to perform a zero-knowledge proof.
  • Step 804 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 802.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 802.
  • One or more network nodes 106 may respond to the request of step 804, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 805 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 802. However, the one or more packets are not required to be associated with the communication between the nodes in step 802.
  • Step 806 includes selecting a network node 106 to perform the secure compute. This selection is based on the network nodes 106 that respond to the request of step 804, in one embodiment. This selection is based on examining the headers of packets in step 805, in one embodiment. For example, a result node 104 or an input node 102 may examine the header of a packet it received from the other node in step 802.
  • Step 808 includes one or more input nodes 102 preparing the input to the secure compute.
  • an input node 102 prepares a zero-knowledge proof.
  • Step 808 may include each node of an MPC preparing their respective inputs.
  • Step 810 includes the one or more input node 102 sending their respective input to the selected network node 106.
  • Step 812 includes the selected network node 106 performing the secure compute.
  • the network node 106 performs the secure compute in a TEE, which is one embodiment of step 714 (ensuring that the result is trusted) .
  • Other trust mechanisms can be used at the network node 106 to ensure that the result is trusted.
  • Step 814 includes the selected network node 106 providing the result to the result node 104.
  • the selected network node 106 sends the result directly to the result node 104.
  • process 900 may be performed in communication system 100, but is not limited thereto.
  • process 900 there may be one or more input nodes 102, and one or more result nodes 104.
  • Step 902 includes nodes communicating a desire to perform a secure compute.
  • a result node 104 sends a request to an input node 102 to perform a zero-knowledge proof.
  • Step 904 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 902.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 902.
  • One or more network nodes 106 may respond to the request of step 904, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 905 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 802.
  • a result node 104 or an input node 102 may examine the header of a packet it received from the other node in step 902.
  • the one or more packets are not required to be associated with the communication between the nodes in step 902.
  • Step 906 includes selecting multiple network nodes 106 that are capable of performing the secure compute. In the event that only one network node 106 responds that it is capable of performing the secure compute, process 800 could be performed.
  • Step 908 includes one or more input nodes 102 preparing the input.
  • an input node 102 prepares a zero-knowledge proof.
  • Step 808 may include each node of an MPC preparing their respective inputs.
  • Step 908 also includes the one or more input node 102 sending their respective input to each of the selected network nodes 106.
  • Step 910 includes each of the selected network nodes 106 performing the secure compute.
  • Step 912 includes the selected network nodes 106 providing their respective results to a notary node. The notary node could be the result node, but that is not required.
  • Step 914 includes the notary node notarizing the results.
  • the result from each of the network nodes 106 should match for the result to be valid. If the result is valid (step 916) , then the notary node sends the valid result to the one of more result nodes 104, in step 918. If the result is not valid, then the notary node drops the result (step 920) . Note that the notary node can optionally be a result node. Steps 914 -920 are one embodiment of step 714 (ensuring that the result is trusted) .
  • the notary node performs a “majority rules” algorithm in which the notary node selects as the final result what result is most prevalent. For example, if each network node provides a TRUE or FALSE result, the notary node determines whether there are more TRUE or FALSE results. In one embodiment, an odd number of network nodes are used to prevent ties. In another embodiment, an even number of network nodes are permitted, with the results being discarded in the event of a tie.
  • process 1000 may be performed in communication system 100, but is not limited thereto.
  • process 1000 there may be one or more input nodes 102, and one or more result nodes 104.
  • Step 1002 includes nodes communicating a desire to perform a secure compute.
  • a result node 104 sends a request to an input node 102 to perform a zero-knowledge proof.
  • Step 1004 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 1002.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 1002.
  • One or more network nodes 106 may respond to the request of step 1004, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 1005 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 802.
  • a result node 104 or an input node 102 may examine the header of a packet it received from the other node in step 1002.
  • the one or more packets are not required to be associated with the communication between the nodes in step 1002.
  • Step 1006 includes selecting multiple network nodes 106 that are capable of performing the secure compute. In the event that only one network node 106 responds that it is capable of performing the secure compute, process 800 could be performed.
  • Step 1008 includes one or more input nodes 102 preparing the input.
  • an input node 102 prepares a zero-knowledge proof.
  • Step 1008 may include each node of an MPC preparing their respective inputs.
  • Step 1008 also includes the one or more input node 102 sending their respective input to each of the selected network nodes 106.
  • Step 1010 includes each of the selected network nodes 106 performing the secure compute.
  • Step 1012 includes the selected network nodes 106 acting as peers in a blockchain network to verify result.
  • Step 1014 includes at least one of the selected network nodes 106 recording the verified result in a blockchain ledger.
  • the blockchain ledger may be stored on one or more of the peers. In one embodiment, all of the blockchain peers store a copy of the blockchain ledger.
  • Steps 1012 and 1014 are one embodiment of step 714 (ensuring that the result is trusted) .
  • Step 1016 includes the result node (s) 104 obtaining the result from the blockchain ledger.
  • the secure compute that is performed by a network node 106 is a zero-knowledge proof.
  • the zero-knowledge proof is a non-interactive zero-knowledge proof, in one embodiment.
  • FIGs. 11 –16 show details of embodiments in which the secure compute that is performed by a network node 106 is a zero-knowledge proof.
  • FIG. 11 depicts an embodiment of a communication system 1100 in which a single network node 106 verifies a zero-knowledge proof.
  • FIG. 12 describes a flowchart of one embodiment of a process 1200 that may be used in communication system 1100.
  • FIG. 13 depicts an embodiment of a communication system 1300 in which multiple network nodes 106 verify a zero-knowledge proof, and in which there is a notary node to notarize the results.
  • FIG. 14 depicts a flowchart of one embodiment of a process 1400 that may be used in communication system 1300.
  • FIG. 15 depicts an embodiment of a communication system 1500 in which multiple network nodes 106, which act as peers in a blockchain network, verify a zero-knowledge proof.
  • FIG. 16 describes a flowchart of one embodiment of a process 1600 that may be used in communication system 1500.
  • the communication system 1100 includes an input node 102, a result node 104, and several network nodes 106 in a network 1110.
  • Six network nodes 106a –106f are explicitly depicted. There may be other network nodes 106 in a portion of the network 1110a, which are not depicted.
  • the depicted network nodes 106a –106f are considered to reside in one or more networks.
  • network node 106e has been selected to verify a zero-knowledge proof.
  • input node 102 performs a zero-knowledge proof (Prf) , and sends the proof to the verifier network node 106e.
  • the verifier network node 106e verifies the proof, and sends a result of the proof to a result node 104.
  • the zero-knowledge proof comprises a mathematical algorithm ( “P” or “proof algorithm” ) , in one embodiment.
  • the proof algorithm inputs a proving key ( “pk” ) , a random input ( “x” ) , and a private statement ( “w” ) , in one embodiment.
  • the private statement is what the prover (e.g., person operating the input node 102) wishes to keep private.
  • the proving key and the random input are publicly available information, in one embodiment.
  • the proof serves to encrypt the private statement ( “w” ) , in one embodiment.
  • the verifier network node 106e performs a verification of the proof. To do so, the verifier network node 106e executes a mathematical algorithm ( “V” or “verification algorithm” ) , in one embodiment.
  • the verification algorithm (V) inputs the random input ( “x” ) , a verifying key ( “vk” ) and the proof (prf) , in one embodiment.
  • the verifying key is publicly available, in one embodiment.
  • the verification algorithm (V) outputs a binary value (e.g., TRUE, FALSE) , in one embodiment.
  • the verifier network node 106e sends the result (e.g., TRUE, FALSE) to the result node 104.
  • the zero-knowledge proof is based on zero-knowledge succinct non-interactive augments of knowledge (zk-SNARKs) .
  • zk-SNARKs are a type of non-interactive zero-knowledge proof. By non-interactive it is meant that the proof itself can used by the verifier without any further interaction from the prover.
  • a zk-SNARK protocol may be based on three algorithms (G, P, V) .
  • the generator (G) algorithm may be used to generate the proving key (pk) and the verifying key (pv) .
  • the input to the generator (G) algorithm is a parameter lambda and a program.
  • the parameter lambda is kept secret.
  • the proving key (pk) and the verifying key (vk) may each be distributed publicly.
  • the network node 106e serves as the generator node to generate the proving key (pk) and the verifying key (pv) .
  • the generator node could be some other node.
  • the generator node is not required to be a network node 106.
  • the zk-SNARK protocol is one example of a protocol for zero-knowledge proofs. Other protocols for zero-knowledge proofs may be used.
  • the network node 106 advertises (see, for example, step 604 of FIG. 6) the type (s) of protocol that the network node 106 is capable of performing for a zero-knowledge proof.
  • Step 1202 includes a result node 104 sending a zero-knowledge proof request to an input node 102.
  • This request refers to a request for the input node 102 to perform the zero-knowledge proof.
  • This request could be initiated in response to a user of the input node 102 wanting to proof some piece of information to an entity controlling the result node 104, without the user revealing the piece of information.
  • Step 1204 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 1202.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 1202.
  • One or more network nodes 106 may respond to the request of step 1204, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 1205 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 1202. However, the one or more packets are not required to be associated with the communication between the nodes in step 1202.
  • Step 1206 includes selecting a verifier network node 106.
  • the selection may be based on the location of network nodes 106. For example, a network node 106 that is close to the input node 102 and/or the result node 104 may be selected.
  • Step 1208 includes the input node 102 generating the zero-knowledge proof.
  • the zero-knowledge proof has as inputs a proving key “pk” and a statement “w” , in one embodiment.
  • the proving key ( “pk” ) is publicly available, in one embodiment.
  • the statement “w” is what an entity (e.g., user) at the input node 102 wants to prove but to keep secret.
  • the zero-knowledge proof has as inputs a proving key “pk” , a random parameter “x” , and a statement “w” , in one embodiment.
  • the random parameter “x” is publicly available, in one embodiment.
  • Step 1210 includes the input node 102 sending the zero-knowledge proof to the selected verifier network node 106e.
  • the input node 102 may also send a verification key “vk” to the selected verifier network node 106e. Since the verification key “vk” may be publicly available, it is not required that the input node 102 send the verification key “vk” to the selected verifier network node 106e.
  • the input node 102 may also send a random parameter “x” to the selected verifier network node 106e. Since the random parameter “x” may be publicly available, it is not required that the input node 102 send the random parameter “x” to the selected verifier network node 106e.
  • Step 1212 includes the selected verifier network node 106e verifying the zero-knowledge proof.
  • the selected verifier network node 106e executes a verifier algorithm that inputs the zero-knowledge proof, the verification key “vk” , and the random parameter “x” .
  • the verifier algorithm outputs a binary value (e.g., TRUE, FALSE) , in one embodiment.
  • Step 1214 includes a decision of whether the zero-knowledge proof is correct. This decision is made on based on whether the verifier algorithm outputs TRUE or FALSE, in one embodiment.
  • step 1216 includes the selected verifier network node 106e sending a result of TRUE to the result node 104.
  • step 1218 includes the selected verifier network node 106e sending a result of FALSE to the result node 104.
  • the communication system 1300 includes an input node 102, a result node 104, and several network nodes 106. Six network nodes 106a –106f are explicitly depicted in network 1310. There may be other network nodes 106 in portion 1310a of the network, which are not depicted.
  • network nodes 106a, 106e, and 106f has been selected to verify a zero-knowledge proof.
  • Input node 102 performs a zero-knowledge proof (Prf) , and sends the proof to each of the selected network nodes 102a, 106e and 106f.
  • Prf zero-knowledge proof
  • Each selected network node 102a, 106e and 106f verifies the proof.
  • the selected network node 102a, 106e and 106f act as peers to verify the result, in one embodiment.
  • one of the network nodes 106 as a notary node to notarize the results.
  • network node 106e may receive Result_a from network node 106a and Result_afrom network node 106f.
  • Network node 106e may send a final result (e.g., Result_final) to the result node 104, after notarizing the results.
  • the zero-knowledge proof comprises a mathematical algorithm that inputs a proving key ( “pk” ) , a random input ( “x” ) , and a private statement ( “w” ) , in one embodiment.
  • the verification algorithm (V) inputs the random input ( “x” ) , a verifying key ( “vk” ) and the proof (prf) , in one embodiment.
  • the zero-knowledge proof is based on zero-knowledge succinct non-interactive augments of knowledge (zk-SNARKs) . Other protocols for zero-knowledge proofs may be used.
  • Step 1402 includes a result node 104 sending a zero-knowledge proof request to an input node 102.
  • This request refers to a request for the input node 102 to perform the zero-knowledge proof.
  • This request could be initiated in response to a user of the input node 102 wanting to proof some piece of information to an entity controlling the result node 104, without the user revealing the piece of information.
  • Step 1404 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 1402.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 1402.
  • One or more network nodes 106 may respond to the request of step 1404, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 1405 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 1402. However, the one or more packets are not required to be associated with the communication between the nodes in step 1402.
  • Step 1406 includes selecting multiple verifier network nodes 106. The selection may be based on the location of network nodes 106. For example, a network node 106 that is close to the input node 102 and/or the result node 104 may be selected. For the sake of discussion, network nodes 102a, 102e, and 102f are selected.
  • Step 1408 includes the input node 102 generating the zero-knowledge proof.
  • the zero-knowledge proof has as inputs a proving key “pk” and a statement “w” , in one embodiment.
  • the zero-knowledge proof has as inputs a proving key “pk” , a random parameter “x” , and a statement “w” , in one embodiment.
  • Step 1410 includes the input node 102 sending the zero-knowledge proof to each of the selected verifier nodes (e.g., network nodes 102a, 102e, and 102f) .
  • the input node 102 may also send a verification key “vk” to the selected verifier nodes. Since the verification key “vk” may be publicly available, it is not required that the input node 102 send the verification key “vk” to the selected verifier nodes.
  • the input node 102 may also send a random parameter “x” to the selected verifier nodes. Since the random parameter “x” may be publicly available, it is not required that the input node 102 send the random parameter “x” to the selected verifier nodes.
  • Step 1412 includes the selected verifier nodes (e.g., network nodes 102a, 102e, and 102f) verifying the zero-knowledge proof.
  • each selected verifier node executes a verifier algorithm that inputs the zero-knowledge proof, the verification key “vk” , and the random parameter “x” .
  • the verifier algorithm outputs a binary value (e.g., TRUE, FALSE) , in one embodiment.
  • TRUE TRUE
  • FALSE FALSE
  • Step 1414 includes verifier network nodes sending their respective results to a notary node.
  • the notary node may be one of the selected network nodes that verified the zero-knowledge proof. However, the notary node is not required to have verified the zero-knowledge proof.
  • the notary node may be a network node, but is not required to be a network node.
  • network node 106e acts as the notary node, in one embodiment.
  • network node 106a sends Result_a to network node 106e
  • network node 106f sends Result_f to network node 106e, in one embodiment.
  • These results are a binary value (e.g., TRUE, FALSE) , in one embodiment.
  • Step 1416 includes the notary node notarizing the results to generate a trusted result.
  • network node 106e compares its result with Result_a and Result_f to verify that all results match (e.g., are all TRUE or all FALSE) . Assuming that the results match, then the notary node sends the notarized result to the result node 104.
  • the notarized result is either “TRUE” or “FALSE” , in one embodiment.
  • the notary node implements a procedure for notarizing failing, in one embodiment. This may include determining whether there is a network node 106 that had an outlier result. For example, it may include determining whether one network node 106 produced a different result from all other network nodes 106. The notary node may also send a message to the result node 104 that the process of notarizing the results failed and that the zero-knowledge proof should be retried, but with a different set of network nodes.
  • the notary node performs a “majority rules” algorithm in which the notary node selects as the final result what result is most prevalent. For example, if each network node provides a TRUE or FALSE result, the notary node determines whether there are more TRUE or FALSE results. In one embodiment, an odd number of network nodes are used to prevent ties. In another embodiment, an even number of network nodes are permitted, with the results being discarded in the event of a tie.
  • the communication system 1500 includes an input node 102, a result node 104, and several network nodes 106. Six network nodes 106a –106f are explicitly depicted in network 1510. There may be other network nodes 106 in portion 1510a of the network, which are not depicted.
  • network nodes 106a, 106e, and 106f has been selected to verify a zero-knowledge proof.
  • Input node 102 performs a zero-knowledge proof (Prf) , and sends the proof to each of the selected network nodes 102a, 106e and 106f.
  • Prf zero-knowledge proof
  • Each selected network node 102a, 106e and 106f is a peer in a blockchain network, in one embodiment. Each selected network node 102a, 106e and 106f verifies the proof. Each selected network node 102a, 106e and 106f stores the result 1504 in a blockchain ledger. For example, network node 102a stores the result in blockchain ledger 1502a; network node 102e stores the result 1504 in blockchain ledger 1502e; and network node 102f stores the result 1504 in blockchain ledger 1502f.
  • the reference number 1502 may be used to refer to the blockchain ledger in general, without reference to a specific copy of the blockchain ledger.
  • a different copy of the blockchain ledger 1502 is stored on each of the selected network node 102a, 106e and 106f, in one embodiment.
  • the result node 104 is able to obtain the result 1504 from the blockchain ledger 1502 that is stored on at least one of the selected network nodes 106.
  • the zero-knowledge proof comprises a mathematical algorithm that inputs a proving key ( “pk” ) , a random input ( “x” ) , and a private statement ( “w” ) , in one embodiment.
  • the verification algorithm (V) inputs the random input ( “x” ) , a verifying key ( “vk” ) and the proof (prf) , in one embodiment.
  • the zero-knowledge proof is based on zero-knowledge succinct non-interactive augments of knowledge (zk-SNARKs) . Other protocols for zero-knowledge proofs may be used.
  • Step 1602 includes a result node 104 sending a zero-knowledge proof request to an input node 102.
  • This request refers to a request for the input node 102 to perform the zero-knowledge proof.
  • This request could be initiated in response to a user of the input node 102 wanting to proof some piece of information to an entity controlling the result node 104, without the user revealing the piece of information.
  • Step 1604 includes either a result node 104 or an input node 102 sending one or more requests into the network 110 to look for a network node 106 that is capable of performing secure computes.
  • the one or more requests are sent to network nodes 106 that processed the request of step 1602.
  • the request (s) may be sent to network nodes 106 that did not process the request of step 1602.
  • One or more network nodes 106 may respond to the request of step 1604, indicating that the respective network node 106 is capable of performing secure computes.
  • Step 1605 includes either a result node 104 or an input node 102 examining a header of one or more received packets to determine which network node (or nodes) 106 is/are capable of performing secure computes.
  • the one or more received packets are associated with the communication between the nodes in step 1602. However, the one or more packets are not required to be associated with the communication between the nodes in step 1602.
  • Step 1606 includes selecting multiple verifier network nodes 106. The selection may be based on the location of network nodes 106. For example, a network node 106 that is close to the input node 102 and/or the result node 104 may be selected. For the sake of discussion, network nodes 102a, 102e, and 102f are selected.
  • Step 1608 includes the input node 102 generating the zero-knowledge proof.
  • the zero-knowledge proof has as inputs a proving key “pk” and a statement “w” , in one embodiment.
  • the zero-knowledge proof has as inputs a proving key “pk” , a random parameter “x” , and a statement “w” , in one embodiment.
  • Step 1610 includes the input node 102 sending the zero-knowledge proof to each of the selected verifier nodes (e.g., network nodes 102a, 102e, and 102f) .
  • the input node 102 may also send a verification key “vk” to the selected verifier nodes. Since the verification key “vk” may be publicly available, it is not required that the input node 102 send the verification key “vk” to the selected verifier nodes.
  • the input node 102 may also send a random parameter “x” to the selected verifier nodes. Since the random parameter “x” may be publicly available, it is not required that the input node 102 send the random parameter “x” to the selected verifier nodes.
  • Step 1612 includes the selected verifier nodes (e.g., network nodes 102a, 102e, and 102f) verifying the zero-knowledge proof.
  • each selected verifier node executes a verifier algorithm that inputs the zero-knowledge proof, the verification key “vk” , and the random parameter “x” .
  • the verifier algorithm outputs a binary value (e.g., TRUE, FALSE) , in one embodiment.
  • TRUE TRUE
  • FALSE FALSE
  • Step 1614 includes verifier network nodes (e.g., network nodes 102a, 102e, and 102f) acting as peer nodes in a blockchain network.
  • the peer nodes may compare the results from the respective verifier network nodes to ensure that the result can be trusted to be correct. For example, the peer nodes may determine whether all of the results match (e.g., all TRUE or all FALSE) . In the event that the results do not all match, then the process may perform a failure process.
  • the peer nodes perform a “majority rules” algorithm in which the peer nodes select as the final result what result is most prevalent. For example, if each peer node provides a TRUE or FALSE result, the peer nodes determine whether there are more TRUE or FALSE results. In one embodiment, an odd number of peer nodes are used to prevent ties. In another embodiment, an even number of peer nodes are permitted, with the results being discarded in the event of a tie.
  • Step 1616 includes at least one of the verifier network nodes 106 recording the result in the blockchain ledger 1502.
  • each of the verifier network nodes 106 that verified the zero-knowledge proof stores the result in a copy of the blockchain ledger stored on the respective network node 106.
  • network node 106a stores the result in blockchain ledger 1502a
  • network node 106e stores the result in blockchain ledger 1502e
  • network node 106f stores the result in blockchain ledger 1502f.
  • Step 1618 includes the result node 104 obtaining the result from the blockchain ledger 1502.
  • the technology described herein can be implemented using hardware, software, or a combination of both hardware and software.
  • the software used is stored on one or more of the processor readable storage devices described above to program one or more of the processors to perform the functions described herein.
  • the processor readable storage devices can include computer readable media such as volatile and non-volatile media, removable and non-removable media.
  • computer readable media may comprise computer readable storage media and communication media.
  • Computer readable storage media may be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer readable storage media is an example of a non-transitory computer-readable medium.
  • Examples of computer readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.
  • a computer readable medium or media does (do) not include propagated, modulated or transitory signals.
  • Communication media typically embodies computer readable instructions, data structures, program modules or other data in a propagated, modulated or transitory data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as RF and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
  • some or all of the software can be replaced by dedicated hardware control circuit components.
  • illustrative types of hardware control circuit components include Field-programmable Gate Arrays (FPGAs) , Application-specific Integrated Circuits (ASICs) , Application-specific Standard Products (ASSPs) , System-on-a-chip systems (SOCs) , Complex Programmable Control Devices (CPLDs) , special purpose computers, etc.
  • FPGAs Field-programmable Gate Arrays
  • ASICs Application-specific Integrated Circuits
  • ASSPs Application-specific Standard Products
  • SOCs System-on-a-chip systems
  • CPLDs Complex Programmable Control Devices
  • special purpose computers etc.
  • software stored on a storage device
  • the one or more processors can be in communication with one or more computer readable media/storage devices, peripherals and/or communication interfaces.
  • each process associated with the disclosed technology may be performed continuously and by one or more computing devices.
  • Each step in a process may be performed by the same or different computing devices as those used in other steps, and each step need not necessarily be performed by a single computing device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne une technologie permettant d'effectuer des calculs sécurisés. Selon un aspect, l'invention comporte un dispositif de réseau comprenant un stockage en mémoire non transitoire comprenant des instructions; et un ou plusieurs processeurs en communication avec le stockage en mémoire non transitoire. Le ou les processeurs exécutent les instructions afin de recevoir et traiter des demandes de routage dans un réseau; envoyer une indication dans le réseau stipulant que le dispositif de réseau est en mesure d'effectuer des calculs sécurisés; effectuer un calcul sécurisé en fonction d'une entrée reçue par l'intermédiaire du réseau en provenance d'un dispositif d'entrée; garantir qu'un résultat du calcul sécurisé est considéré digne de confiance comme constituant un résultat correct du calcul sécurisé; et fournir le résultat de confiance du calcul sécurisé à un dispositif de résultat connecté au réseau.
PCT/CN2019/083567 2019-02-26 2019-04-20 Dispositifs de réseau et procédés de calcul sécurisé WO2020172977A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201980092430.1A CN113454628A (zh) 2019-02-26 2019-04-20 安全计算网络设备和方法
EP19917406.1A EP3850522B1 (fr) 2019-02-26 2019-04-20 Dispositifs de réseau et procédés de calcul sécurisés
US17/359,108 US11943359B2 (en) 2019-02-26 2021-06-25 Secure compute network devices and methods

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962810730P 2019-02-26 2019-02-26
US62/810,730 2019-02-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/359,108 Continuation US11943359B2 (en) 2019-02-26 2021-06-25 Secure compute network devices and methods

Publications (1)

Publication Number Publication Date
WO2020172977A1 true WO2020172977A1 (fr) 2020-09-03

Family

ID=72238980

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/083567 WO2020172977A1 (fr) 2019-02-26 2019-04-20 Dispositifs de réseau et procédés de calcul sécurisé

Country Status (4)

Country Link
US (1) US11943359B2 (fr)
EP (1) EP3850522B1 (fr)
CN (1) CN113454628A (fr)
WO (1) WO2020172977A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114270778B (zh) * 2019-08-19 2023-09-12 诺基亚技术有限公司 针对在可信执行环境中执行的可验证性
US11502829B2 (en) * 2020-09-02 2022-11-15 Vmware, Inc. Robust input verification for secure multi-party computation (MPC) with clients
US11928234B2 (en) * 2021-08-06 2024-03-12 International Business Machines Corporation Platform for dynamic collaborative computation with confidentiality and verifiability
US11522758B1 (en) * 2021-09-13 2022-12-06 International Business Machines Corporation Preserving data integrity in cognitive multi-agent systems
CN115242409B (zh) * 2022-09-21 2022-11-25 环球数科集团有限公司 一种基于零知识证明的隐私计算方法与系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140109190A1 (en) 2012-10-16 2014-04-17 Cisco Technology, Inc. Policy-Based Control Layer in a Communication Fabric
CN105960781A (zh) * 2014-02-11 2016-09-21 华为技术有限公司 利用基于公钥的数字签名保护源路由的方法与系统
US20170185804A1 (en) * 2015-12-23 2017-06-29 Intel Corporation Secure routing of trusted software transactions in unsecure fabric
US20170310583A1 (en) * 2016-04-22 2017-10-26 Cisco Technology, Inc. Segment routing for load balancing
US20180324258A1 (en) * 2015-11-04 2018-11-08 Entit Software Llc Direct connection limitation based on a period of time

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130097417A1 (en) * 2011-10-13 2013-04-18 Microsoft Corporation Secure private computation services
EP3639229A4 (fr) * 2017-06-16 2020-06-17 Visa International Service Association Dispositif de commande d'interaction de réseau de chaîne de blocs
US11240001B2 (en) * 2018-11-06 2022-02-01 International Business Machines Corporation Selective access to asset transfer data
SG11202105218PA (en) * 2018-12-17 2021-06-29 Xeniro Multi-access edge computing node with distributed ledger

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140109190A1 (en) 2012-10-16 2014-04-17 Cisco Technology, Inc. Policy-Based Control Layer in a Communication Fabric
CN105960781A (zh) * 2014-02-11 2016-09-21 华为技术有限公司 利用基于公钥的数字签名保护源路由的方法与系统
US20180324258A1 (en) * 2015-11-04 2018-11-08 Entit Software Llc Direct connection limitation based on a period of time
US20170185804A1 (en) * 2015-12-23 2017-06-29 Intel Corporation Secure routing of trusted software transactions in unsecure fabric
US20170310583A1 (en) * 2016-04-22 2017-10-26 Cisco Technology, Inc. Segment routing for load balancing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3850522A4

Also Published As

Publication number Publication date
EP3850522A1 (fr) 2021-07-21
US20210328798A1 (en) 2021-10-21
EP3850522B1 (fr) 2023-06-28
US11943359B2 (en) 2024-03-26
EP3850522A4 (fr) 2021-11-10
CN113454628A (zh) 2021-09-28

Similar Documents

Publication Publication Date Title
US11943359B2 (en) Secure compute network devices and methods
US11601407B2 (en) Fast oblivious transfers
RU2736447C1 (ru) Перекрестная торговля активами в сетях блокчейнов
JP7011646B2 (ja) 量子通信及びトラステッドコンピューティングに基づくデータセキュリティのための方法及びシステム
CN112970236B (zh) 协作风险感知认证
CN114586313B (zh) 用于签署一信息的系统及方法
US8572405B2 (en) Collusion-resistant outsourcing of private set intersection
KR20200116013A (ko) 고 가용성의 신뢰 실행 환경을 사용하여 블록체인 네트워크에 대한 액세스 데이터를 리트리빙하는 방법
TW202008272A (zh) 區塊鏈交易方法及裝置、電子設備
Chikouche et al. A privacy-preserving code-based authentication protocol for Internet of Things
US11374910B2 (en) Method and apparatus for effecting a data-based activity
US20180006823A1 (en) Multi-hop secure content routing based on cryptographic partial blind signatures and embedded terms
JP2022546470A (ja) トランスポート層セキュリティおよび他のコンテキストでのデータの検証のための非集中型技術
US20230032099A1 (en) Physical unclonable function based mutual authentication and key exchange
US20210143985A1 (en) Method and protocol for triple-blind identity mapping.
US20220385642A1 (en) Method and apparatus for effecting a data-based activity
EP4096160A1 (fr) Mise en uvre par secret partagé de clés cryptographiques obtenues par procuration
Kang et al. Lightweight user authentication scheme for roaming service in GLOMONET with privacy preserving
Guo et al. A Novel RLWE‐Based Anonymous Mutual Authentication Protocol for Space Information Network
da Costa et al. DLCP: A protocol for securing light client operation in blockchains
Diaz et al. On securing online registration protocols: Formal verification of a new proposal
Karl et al. Cryptonite: A framework for flexible time-series secure aggregation with non-interactive fault recovery
Devarajan et al. An hyper elliptic curve based efficient signcryption scheme for user authentication
Kamkuemah Reasoning about Authentication and Secrecy in the Signal Protocol
US20240064031A1 (en) Method for integrating blockchain node compliance data within blockchain transaction data

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19917406

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019917406

Country of ref document: EP

Effective date: 20210414

NENP Non-entry into the national phase

Ref country code: DE