Complete remote authentication without hardware security assurance

By generating and providing zero-knowledge proofs in the prior art, the problem of relying on dedicated hardware and/or firmware for remote authentication of computing devices is solved, achieving higher reliability and security, while reducing manufacturing costs and the risks brought about by hardware failures.

CN119678428APending Publication Date: 2025-03-21GOOGLE LLC
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202380060974.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-08-25
Filing Date
2023-07-18
Publication Date
2025-03-21

AI Technical Summary

Technical Problem

The prior art relies on dedicated hardware and/or firmware (such as TPM chips) when performing remote authentication of computing devices, increasing the manufacturing cost of computing devices and may permanently prevent the computing device from providing hardware security assurance once the dedicated hardware is damaged.

Method used

The computing device generates and provides zero-knowledge proofs (such as zk-SNARK proofs), and proves the integrity and properties of the computing device without using dedicated hardware and/or firmware, thereby realizing remote authentication of the computing device.

Benefits of technology

Remote authentication of computing devices is achieved without relying on dedicated hardware and/or firmware, which improves the reliability and security of computing devices, reduces manufacturing costs, and reduces the risk of functional blocking due to hardware failures.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119678428A_ABST
    Figure CN119678428A_ABST
Patent Text Reader

Abstract

The computing device may generate a zero-knowledge proof that the computing device has one or more attributes and may send an indication of the zero-knowledge proof to the computing system. The computing system may verify that the zero-knowledge proof computing device has one or more attributes, and may grant the computing device permission to perform an action requiring the computing device to have one or more attributes in response to successfully verifying that the zero-knowledge proof computing device has one or more attributes.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 373,521, filed on August 25, 2022, the entire contents of which are incorporated herein by reference. Background Art

[0002] Remote attestation is a mechanism for verifying and verifying the integrity of a computing device to determine whether the platform is trusted. In some examples, a computing system may perform remote attestation of a computing device via the use of hardware security assurances to determine whether the computing device has been modified or otherwise compromised. Such hardware security assurances may be provided using dedicated hardware and / or firmware in the computing device that can prove the integrity of the computing device to the computing system, such as a Trusted Platform Module (TPM) chip or other physical security mechanism. Summary of the invention

[0003] Generally speaking, the techniques of this disclosure are directed to performing a complete remote authentication of a computing device without using dedicated hardware and / or firmware (such as a Trusted Platform Module (TPM) chip or other physical security mechanism) to prove the integrity of the computing device. Instead, the computing device can provide a zero-knowledge proof (ZKP), such as a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof, that the computing device is in a specific configuration, thereby proving the integrity of the computing device without using dedicated hardware and / or firmware and without revealing the details of the specific configuration of the computing device.

[0004] In some aspects, the technology described herein relates to a method comprising: receiving, by one or more processors of a computing system, from a computing device an indication of a zero-knowledge proof that the computing device has one or more properties; verifying, by the one or more processors, the zero-knowledge proof that the computing device has the one or more properties; and in response to successfully verifying the zero-knowledge proof, granting, by the one or more processors, the computing device permission to perform an action that requires the computing device to have the one or more properties.

[0005] In some aspects, the technology described herein relates to a computing system comprising: a memory that stores instructions; and one or more processors that execute the instructions to: receive an indication from a computing device that the computing device has a zero-knowledge proof of one or more properties; verify that the zero-knowledge proof proves that the computing device has the one or more properties; and in response to successfully verifying the zero-knowledge proof, grant the computing device permission to perform an action that requires the computing device to have the one or more properties.

[0006] In some aspects, the technology described herein relates to an apparatus that includes: means for receiving an indication from a computing device that the computing device has a zero-knowledge proof of one or more properties; means for verifying that the zero-knowledge proof proves that the computing device has the one or more properties; and means for granting the computing device permission to perform an action that requires the computing device to have the one or more properties in response to successfully verifying the zero-knowledge proof.

[0007] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a computing system, cause the one or more processors to: receive from a computing device an indication of a zero-knowledge proof that the computing device has one or more properties; verify that the zero-knowledge proof proves that the computing device has the one or more properties; and in response to successfully verifying the zero-knowledge proof, grant the computing device permission to perform an action that requires the computing device to have the one or more properties.

[0008] In some aspects, the technology described herein relates to a method comprising: generating, by one or more processors of a computing device, a zero-knowledge proof that the computing device has one or more properties; sending, by the one or more processors, an indication of the zero-knowledge proof to a computing system; and receiving, by the one or more processors, an indication that enables the computing device to perform an action that requires the computing device to have the one or more properties in response to the computing system successfully verifying the zero-knowledge proof.

[0009] In some aspects, the technology described herein relates to a computing device, the computing device comprising: a memory storing instructions; and one or more processors executing instructions to: generate a zero-knowledge proof that the computing device has one or more properties; send an indication of the zero-knowledge proof to a computing system; and in response to the computing system successfully verifying the zero-knowledge proof, receive data that enables the computing device to perform an action that requires the computing device to have the one or more properties. Receive an indication of the zero-knowledge proof that the computing device has one or more properties from the computing device; verify that the zero-knowledge proof proves that the computing device has the one or more properties; and in response to successfully verifying the zero-knowledge proof, grant the computing device permission to perform an action that requires the computing device to have the one or more properties.

[0010] In some aspects, the technology described herein relates to an apparatus that includes: means for generating a zero-knowledge proof that a computing device has one or more properties; means for sending an indication of the zero-knowledge proof to a computing system; and means for receiving data that enables the computing device to perform an action that requires the computing device to have the one or more properties in response to the computing system successfully verifying the zero-knowledge proof.

[0011] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a computing device, cause the one or more processors to: generate a zero-knowledge proof that the computing device has one or more properties; send an indication of the zero-knowledge proof to a computing system; and in response to the computing system successfully verifying the zero-knowledge proof, receive data that enables the computing device to perform an action that requires the computing device to have the one or more properties.

[0012] The details of one or more examples are set forth in the accompanying drawings and the description below.Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a conceptual diagram illustrating an example environment for remote attestation according to one or more aspects of the present disclosure.

[0014] Figure 2 is a block diagram illustrating further details of an example computing device according to one or more aspects of the present disclosure.

[0015] Figure 3 is a block diagram illustrating further details of an example computing system in accordance with one or more aspects of the present disclosure.

[0016] Figure 4 Example techniques for remote authentication according to aspects of the present disclosure are illustrated.

[0017] Figure 5 is a flow chart of an example process for an example computing device to authenticate having one or more attributes according to aspects of the present disclosure.

[0018] Figure 6 is a flow chart of an example process for an example computing system to perform remote authentication of an example computing device according to aspects of the present disclosure.

[0019] Figure 7 is a flow chart of an example process for remote authentication according to aspects of the present disclosure.

[0020] Figure 8 is a flow chart of an example process for remote authentication according to aspects of the present disclosure. DETAILED DESCRIPTION

[0021] Figure 1 is a conceptual diagram illustrating an example environment for remote authentication according to one or more aspects of the present disclosure. Figure 1 In the example of , environment 100 may include a computing system 102 in communication with a computing device 110 via a network 130 .

[0022] Computing system 102 may represent any suitable computing system capable of both sending and receiving information to and from a network, such as network 130, such as one or more desktop computers, laptop computers, mainframes, servers, cloud computing systems, etc. In some examples, Figure 1 The components of the illustrated computing system 102 may reside and execute on the same or separate computing devices and systems operated by and / or under the control of one or more entities. In some examples, computing system 102 may represent one or more cloud computing systems that provide access to their respective services via the cloud.

[0023] The computing system 102 may include a verifier module 106 and one or more registers 108. The verifier module 106 may perform the operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and / or executing at the computing system 102 to perform functions associated with performing remote authentication of the computing device 110 and verifying mathematical proofs. The computing system 102 may utilize multiple processors or multiple devices to execute the verifier module 106, as a virtual machine executing on underlying hardware, as one or more services of an operating system or computing platform, and / or as one or more executable programs at an application layer of a computing platform of the computing system 102. The one or more registers 108 may be any suitable data repository for storing data associated with performing remote authentication of the computing device 110, such as a database, a repository, a blockchain, a journal, a certificate authority, etc.

[0024] Network 130 represents any public or private communication network for transmitting data between computing systems, servers, and computing devices, such as cellular, Wi-Fi, and / or other types of networks. Network 130 may include one or more network hubs, network switches, network routers, or any other network equipment that are operatively coupled to each other to provide information exchange between computing system 102 and computing device 110. Computing device 110 and computing system 102 may send and receive data across network 130 using any suitable communication technology. Each of computing system 102 and computing device 110 may be operatively coupled to network 130 using a corresponding network link, such as Ethernet, Wi-Fi, or any other type of wired and / or wireless network connection.

[0025] Computing device 110 represents an individual mobile or non-mobile computing device. Examples of computing device 110 include mobile phones, tablet computers, laptop computers, desktop computers, servers, mainframes, set-top boxes, televisions, wearable devices (e.g., computerized watches, computerized eye-mounted devices, computerized headsets, computerized gloves, etc.), home automation devices or systems (e.g., smart thermostats or home assistant devices), personal digital assistants (PDAs), gaming systems, media players, e-book readers, mobile television platforms, car navigation or infotainment systems, or any other type of mobile, non-mobile, wearable, and non-wearable computing devices. Computing device 110 may not include and / or use specialized hardware and / or firmware for proving the integrity of computing device 110 or for providing any hardware security assurances, such as a trusted platform module (TPM) chip or other physical security mechanism.

[0026] Computing device 110 may include proof module 116. Proof module 116 may perform the operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and / or executing at computing device 110 to perform functions associated with generating a mathematical proof that computing device 110 has one or more properties. Computing device 110 may utilize multiple processors or multiple devices to execute proof module 116, as a virtual machine executing on underlying hardware, as one or more services of an operating system or computing platform, and / or as one or more executable programs at an application layer of a computing platform of computing device 110.

[0027] Computing device 110 may be permitted to perform certain actions only if computing system 102 can verify that computing device 110 has certain properties, such as having a specific configuration of data, software, hardware, and / or a combination thereof. Thus, computing system 102 may perform remote authentication of computing device 110 to determine whether computing device 110 has one or more properties required in order for computing device 110 to be permitted to perform an action, and computing system 102 may permit computing device 110 to perform the action only if computing system 102 can verify that computing device 110 has the one or more required properties. Examples of specific properties of computing device 110 include: whether the version of firmware installed at computing device 110 is within a specified version range, whether firmware installed at computing device 110 at the factory or via a software update has been modified and / or tampered with, whether computing device 110 has been modified, whether computing device 110 is in a valid configuration, whether a specific peripheral device is connected and / or not connected to computing device 110, whether the manufacturing date of computing device 110 is within a specified date range, and / or any combination thereof.

[0028] For example, in order for computing device 110 to play a video stream encrypted using digital rights management (DRM), the policy associated with the DRM may require confirmation that the display pipeline of the hardware of computing device 110 has not been tampered with before launching the stream. Therefore, computing system 102 may perform remote authentication of computing device 110 to determine whether computing device 110 has this property that its display pipeline has not been tampered with. In another example, in order for computing device 110 to execute a particular video game application, the video game may have a policy that no external human interface device (HID) is connected to computing device 110. Therefore, computing system 102 may perform remote authentication of computing device 110 to determine that no external HID is connected to computing device 110.

[0029] The computing system 102 may be able to perform full remote authentication of the computing device 110 without requiring the computing device 110 to have and / or use dedicated hardware and / or firmware (such as a Trusted Platform Module (TPM) chip or other physical security mechanism) to prove the integrity of the computing device 110. Although the dedicated hardware and / or firmware can provide hardware security assurance that the computing device has not been modified or otherwise compromised, including such dedicated hardware in computing devices may increase the manufacturing cost of these computing devices. Further, if the dedicated hardware of a computing device is ever compromised, the computing device may be permanently prevented from providing hardware security assurances, which may prevent the computing device from performing certain functions that require such hardware security assurances.

[0030] Alternatively, in order for computing system 102 to verify that computing device 110 has one or more properties required in order for computing device 110 to perform a particular action, computing device 110 may generate a mathematical proof that computing device 110 has the one or more properties (e.g., is in a particular configuration), and may send the proof to computing system 102. In response to receiving the mathematical proof, computing system 102 may verify the mathematical proof that computing device 110 has the one or more properties. If computing system 102 verifies that the mathematical proof provided by computing device 110 proves that computing device 110 has the one or more properties, computing system 102 may grant computing device 110 permission to perform the particular action.

[0031] Computing device 110 may generate a mathematical proof that computing device 110 has the one or more properties in the form of a zero-knowledge proof, which is a cryptographic technique in which a prover (e.g., computing device 110) may prove to a verifier (e.g., computing system 102) that the prover possesses knowledge of a secret parameter (called a witness) that satisfies a certain relationship, without revealing the witness or any additional information to the verifier or anyone else. In the example of proving that computing device 110 is in a particular configuration, the zero-knowledge proof may prove that computing device 110 is in a particular configuration without revealing the configuration of computing device 110 or any other information about computing device 110. That is, a zero-knowledge proof that proves that computing device 110 has one or more properties may not reveal any additional information about other properties that computing device 110 may or may not have.

[0032] An example of a zero-knowledge proof is a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof. zk-SNARK proofs are succinct due to their very small size, so that verification of zk-SNARK proofs can be performed relatively quickly. zk-SNARK proofs are also non-interactive, so that only one set of information can be sent to the verifier for verification without any interaction from the verifier (i.e., without sending messages back and forth to and from the verifier), thereby reducing the amount of network traffic communicated between computing device 110 and the verifier (e.g., computing system 102). zk-SNARK proofs can also guarantee semantic security for the prover within polynomial time constraints. If an adversary who receives either of the two plaintexts m0 and m1 cannot guess with a probability higher than ½ whether a given ciphertext is an encryption of plaintext m0 or an encryption of plaintext m1, then the encryption scheme for encrypting the plaintext can be proven to be semantically secure. Therefore, zk-SNARK proofs guarantee semantic security, making it infeasible for an adversary to extract information from a zk-SNARK proof other than proof that computing device 110 has one or more properties. A zk-SNARK proof cannot be constructed without access to a witness, such that the witness is verified to be present when the proof is generated. Computing device 110 may construct a zk-SNARK proof using an identity, which may be a unique piece of information bound to computing device 110, such as a password or other information known only to computing device 110, and a witness, which is a secret parameter such that the zk-SNARK proof mathematically proves that computing device 110 has knowledge of the witness.

[0033] In an example of proving that computing device 110 possesses one or more properties required to perform an action, the witness may be a secret parameter, such as in the form of a hash, an alphanumeric string, or any other piece of data, that indicates that computing device 110 possesses the one or more properties required to perform the action, and proving module 116 of computing device 110 may generate a zk-SNARK proof that mathematically proves that computing device 110 possesses the witness without indicating the witness itself in the zk-SNARK proof. Computing system 102 may also possess the witness. Thus, verifier module 106 of computing system 102 may verify the zk-SNARK proof by determining whether the zk-SNARK proof actually proves that computing device 110 possesses the witness.

[0034] Using zero-knowledge proofs to prove that computing device 110 is in a particular configuration may enable computing system 102 to perform remote authentication of computing device 110 without hardware security guarantees, thereby enabling computing system 102 to perform remote authentication of computing device 110 without including or using specialized hardware and / or firmware to provide such hardware security guarantees. By using zero-knowledge proofs to perform remote authentication of computing device 110, the techniques of the present disclosure may improve the reliability and security of computing device 110 by enabling computing device 110 to not rely on the use of specialized hardware and / or firmware to provide such hardware security guarantees that may fail and / or may be compromised.

[0035] Furthermore, because zk-SNARK proofs are both highly concise and non-interactive, using zk-SNARK proofs to prove that computing device 110 is in a particular configuration may enable computing device 110 to reduce the amount of data sent to computing system 102 via network 130 to prove that computing device 110 is in a particular configuration, compared to other techniques for proving that computing device 110 is in a particular configuration. Thus, the techniques of this disclosure may reduce bandwidth utilization of network 130 by computing device 110 to prove that computing device 110 is in a particular configuration.

[0036] Additionally, zk-SNARK proofs may be highly computationally efficient compared to other techniques for proving that computing device 110 is in a particular configuration. The computational efficiency of zk-SNARK proofs may reduce the processing overhead of computing device 110 generating a zk-SNARK proof to prove that computing device 110 is in a particular configuration, and the processing overhead of computing system 102 determining whether a zk-SNARK proof proves that computing device 110 is in a particular configuration.

[0037] In addition, since zero-knowledge proofs can prove that computing device 110 is in a specific configuration without revealing the configuration of computing device 110 or any other information about computing device 110, using zero-knowledge proofs to prove that computing device 110 is in a specific configuration can minimize the amount of information about computing device 110 that is leaked or sent to other parties. Therefore, the technology of the present disclosure can be able to protect the privacy and confidentiality of computing device 110.

[0038] In one illustrative example, computing system 102 may determine that a cryptographic sum of certain applications executed at computing device 110 is a certain value (e.g., 47) when computing device 110 is in a particular configuration. The cryptographic sum of certain applications executed at computing device 110 may be a witness, and computing device 110 may generate a zk-SNARK proof that mathematically proves that computing device 110 possesses the value of the cryptographic sum of certain applications executed at computing device 110 (e.g., 47) without revealing the actual value of the cryptographic sum. Computing system 102 may verify the zk-SNARK proof to determine whether the proof successfully proves that the cryptographic sum of applications executed at computing device 110 possessed by computing device 110 matches the cryptographic sum determined by computing system 102, and upon successful verification of the proof, determines that the computing device is in the particular configuration.

[0039] In some examples, computing system 102 may not be able to make a binary determination as to whether the zk-SNARK proof actually proves that computing device 110 possesses the witness. Instead, computing system 102 may determine a probability that the zk-SNARK proof actually proves that computing device 110 possesses the witness, and computing system 102 may compare the determined probability to a probability threshold to determine whether the zk-SNARK proof is successfully verified as proving that computing device 110 possesses the witness. That is, if computing system 102 determines that the probability that the zk-SNARK proof actually proves that computing device 110 possesses the witness is above the probability threshold, computing system 102 may determine that the zk-SNARK proof is successfully verified as proving that computing device 110 possesses the witness.

[0040] The probability threshold may be adjustable based on, for example, the risk preference of computing device 110, as a lower probability threshold may increase false positives (i.e., successful verification does not actually prove that computing device 110 possesses the witnessed zk-SNARK proof), while a higher probability threshold may increase false negatives (i.e., unsuccessful verification does not actually prove that computing device 110 possesses the witnessed zk-SNARK proof). Examples of probability thresholds include 95%, 99%, etc.

[0041] If computing system 102 is able to successfully verify proof that computing device 110 has one or more attributes, computing system 102 may grant computing device 110 permission to perform a particular action. Granting computing device 110 permission to perform an action may include granting computing device 110 access to a particular resource, such as access to a cryptographic key (e.g., an encryption key) that authorizes computing device 110 to perform the one or more actions. For example, if computing system 102 is able to successfully verify proof that computing device 110's display pipeline has not been tampered with, computing system 102 may grant computing device 110 access to a cryptographic key used to decrypt an encrypted video, thereby enabling computing device 110 to decrypt and play back the encrypted video.

[0042] One or more registers 108 of computing system 102 may serve as a trusted log of events for recording information associated with verification of one or more properties of computing system 102. Computing system 102 or any other entity may not be able to delete any information from one or more registers 108. Instead, computing system 102 may only be able to add information to one or more registers 108. In this way, one or more registers 108 may serve as a trusted log of information regarding whether computing device 110 has been successfully verified as having one or more properties in order to grant computing device 110 permission to perform certain actions.

[0043] In some examples, each time computing system 102 verifies an attestation that computing device 110 possesses one or more properties, computing system 102 may add an entry to one or more registers 108 that includes information associated with the verification of the attestation, such as whether computing system 102 was able to successfully verify the attestation, the one or more properties being proven, an action that requires computing device 110 to possess the one or more properties, etc. Thus, one or more registers 108 may provide information about whether computing device 110 is currently successfully verified as possessing the one or more properties in order to grant computing device 110 permission to perform certain actions.

[0044] For example, an entity storing an encryption key for decrypting an encrypted video for playback may determine whether computing system 102 has verified computing device 110 as having one or more properties required to play back the encrypted video (e.g., a secure video playback data path) based on information stored in one or more registers 108. If the information stored in one or more registers 108 indicates that computing system 102 has verified computing device 110 as having one or more properties required to play back the encrypted video, the entity may grant computing device 110 permission to play back the encrypted video, such as by sending computing device 110 an encryption key for decrypting the encrypted video.

[0045] Contract 120 associated with computing device 110 may govern the actions that computing device 110 is permitted to perform based on the state of computing device 110. For example, contract 120 may be a cryptographic contract, such as a smart contract, that associates each of one or more actions with a particular one or more properties of computing device 110, such that computing device 110 may be permitted to perform the action only if computing device 110 can be verified to have the one or more properties associated with the action as specified by contract 120.

[0046] One or more entities may determine the actions that computing device 110 is permitted to perform based at least in part on verifying the state of computing device 110, and computing device 110 may generate contract 120 based on parameters determined by the one or more entities. Such parameters may indicate one or more actions and, for each of the one or more actions, indicate associated one or more properties of computing device 110 that, if verified, allow computing device 110 to perform the action. One or more entities may be trusted parties, such as a manufacturer of computing device 110, a provider of an operating system for computing device 110, and / or other parties that may be trusted to determine the actions that computing device 110 is permitted to perform based at least in part on verifying the state of computing device 110. In this manner, multiple entities or parties may be able to jointly create a contract that is split between multiple entities for access to one or more services and / or actions by computing device 110.

[0047] Computing device 110 may generate contract 120 by generating cryptographic key material based on parameters determined by one or more entities and generating contract 120 using the cryptographic key material. In some examples, the cryptographic key material may be actual bytes or numbers in a cryptographic key used for cryptographic calculations, such as bytes and numbers of a cryptographic key used to generate contract 120 and / or otherwise secure transactions and data involved in contract 120. Contract 120 acts as a signature of one or more authenticatable states of computing device 110, such as the state of firmware of computing device 110, and is bound to unique information on computing device 110, which is referred to herein as an identity. The identity associated with computing device 110 is bound to computing device 110 through a witness. In examples where computing device 110 generates contract 120, the witness may be in the form of a verification, such as a password entered by a user.

[0048] When a valid contract does not exist, computing device 110 may generate contract 120. This may mean that computing device 110 may generate contract 120 if computing device 110 has not previously generated a contract or the previously generated contract has been invalidated. The previously generated contract may have been invalidated if computing device 110 cannot prove that computing device 110 has one or more properties specified by the previously generated contract. For example, if the previously generated contract specifies that the firmware of computing device 110 is not compromised, and if the firmware of computing device 110 is subsequently compromised after the previously generated contract was generated, computing system 102 may invalidate the previously generated contract.

[0049] Enabling computing device 110 to generate contract 120 even after invalidating a previously generated contract may enable computing device 110 to have additional flexibility to be modified without preventing computing device 110 from being able to perform actions that require remote authentication of properties of computing device 110. For example, a user of computing device 110 may root the firmware of computing device 110, which may cause computing system 102 to invalidate a contract that specifies that the firmware of computing device 110 has not been modified. Subsequently, the user may be able to reinstall an unmodified version of the firmware of computing device 110, and computing device 110 may be able to generate a valid contract that specifies that the firmware of computing device 110 has not been modified.

[0050] Computing device 110 may, in response to generating contract 120, send contract 120 to computing system 102. In some examples, computing device 110 may cryptographically sign contract 120 using information known to computing system 102 and computing device 110 but unknown to other parties, and may send signed contract 120 to computing system 102.

[0051] In response to receiving the contract 120, the computing system 102 may verify the contract 120, such as by determining whether the contract 120 is signed using valid information known to the computing system 102. The computing system 102 may, in response to successfully verifying the contract 120, generate an authentication proof of the computing device 110 and add the authentication proof to the one or more registers 108. That is, the computing device 110 may add an entry to the one or more registers 108 indicating that the computing device 110 has one or more properties specified by the contract 120 and / or that the contract 120 is a valid contract between the computing device 110 and the computing system 102.

[0052] Computing device 110 may sign contract 120 after generating contract 120 and sending the contract to computing system 102 by formulating a zero-knowledge proof that computing device 110 has one or more attributes and sending the zero-knowledge proof to computing system 102. That is, once computing device 110 has generated contract 120 that specifies computing device 110 as having one or more attributes, computing device 110 may send a zero-knowledge proof that computing device 110 has the one or more attributes by signing contract 120 using the zero-knowledge proof that computing device 110 has the one or more attributes.

[0053] Computing system 102 may attempt to verify the zero-knowledge proof in response to receiving the zero-knowledge proof that computing device 110 is in a particular state and sending the zero-knowledge proof to computing system 102. That is, computing system 102 may determine whether the zero-knowledge proof successfully proves that computing device 110 has one or more properties specified by contract 120 to perform an associated action.

[0054] If computing system 102 determines that the zero-knowledge proof does not prove that computing device 110 has one or more properties specified by contract 120 to perform an associated action, computing system 102 may invalidate contract 120. If computing system 102 determines that the zero-knowledge proof proves that computing device 110 has one or more properties specified by contract 120 to perform an associated action, computing system 102 may permit computing device 110 to perform an action associated with the one or more properties of computing device 110 as specified by contract 120, such as by granting computing device 110 access to resources used by computing device 110 to perform the action associated with the one or more properties of computing device 110. For example, computing system 102 may grant computing device 110 access to an encryption key by sending the encryption key to computing device 110, which computing device 110 uses to decrypt an encrypted video. In this way, computing system 102 may use successful verification of a zero-knowledge proof to temporarily control access and authorization to assets and resources of computing device 110.

[0055] If computing system 102 determines that the zero-knowledge proof proves that computing device 110 has one or more properties specified by contract 120 to perform an associated action, computing system 102 may perform ratcheting of a cryptographic key used to securely communicate with computing device 110, such as via use of a double ratchet algorithm. For example, because computing device 110 sends an indication of the zero-knowledge proof to computing system 102 by signing contract 120, contract 120 may serve as a cryptographic key for communications between computing device 110 and computing system 102. Thus, whenever computing system 102 successfully verifies that computing device 110 has one or more properties specified by contract 120, computing device 110 may perform ratcheting of contract 120, such that even if contract 120 is compromised (e.g., stolen from computing device 110), ratcheting of contract 120 may prevent a malicious actor from using the stolen cryptographic key to compromise communications between computing system 102 and computing device 110.

[0056] After computing device 110 has generated contract 120, and after computing device 110 successfully verifies the zero-knowledge proof that computing device 110 has one or more properties specified by contract 120 to perform the associated action, computing system 102 may proceed to perform remote authentication of computing device 110. That is, computing device 110 may proceed to generate and send to computing system 102 the zero-knowledge proof that computing device 110 has the one or more properties specified by contract 120, and computing system 102 may attempt to verify the zero-knowledge proof that computing device 110 has the one or more properties specified by contract 120.

[0057] For example, if a software application executing at computing device 110 performs an action that requires computing device 110 to prove that computing device 110 has one or more properties specified by contract 120, computing device 110 may perform remote attestation that computing device 110 has the one or more properties specified by contract 120 whenever the software application is launched, and / or may perform such remote attestation periodically while the software application executes. In this way, computing system 102 may be able to ensure that contract 120 remains valid so as to continue to grant the software application permission to perform actions.

[0058] Figure 2 is a block diagram illustrating further details of an example computing device according to one or more aspects of the present disclosure. Figure 2 The computing device 210 is hereinafter referred to as Figure 1 The example of computing device 110 is shown for description.

[0059] Figure 2The computing device 210 may be an example of a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a mainframe, a set-top box, a television, a wearable device, a home automation device or system, a gaming system, a media player, an e-book reader, a mobile television platform, a car navigation or infotainment system, or any other type of mobile, non-mobile, wearable, and non-wearable computing device configured to receive and output an indication of notification data. Figure 2 Only one particular example of computing device 210 is illustrated, and many other examples of computing device 210 may be used in other situations and may include a subset of the components included in the example computing device 210, or may include Figure 2 Additional components not shown.

[0060] like Figure 2 As shown in the example of FIG. 2 , computing device 210 includes UIC 212, one or more processors 240, one or more input components 242, one or more communication units 244, one or more output components 246, and one or more storage components 248. The one or more storage components 248 of computing device 210 also include attestation module 216, contract module 252, software application 254, and contract 220. Attestation module 216 may be Figure 1 The example of the proof module 116 shown, and the contract 120 may be Figure 1 An example of a contract 120 is shown.

[0061] Communication channel 250 can interconnect each of components 240, 212, 244, 246, 242, and 248 for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channel 250 can include a system bus, a network connection, an inter-process communication data structure, or any other method for conveying data.

[0062] One or more input components 242 of computing device 210 can receive input. Examples of input are tactile input, audio input, and video input. In one example, input components 242 of computing device 210 include a presence-sensitive display, a touch-sensitive screen, a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting input from a human or a machine.

[0063] One or more output components 246 of computing device 210 may generate output. Examples of output are tactile output, audio output, and video output. In one example, one or more output components 246 of computing device 210 include a presence-sensitive display, a sound card, a video graphics adapter card, a speaker, a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, a light field display, a haptic motor, a linear actuator, or any other type of device for generating output to a human or a machine.

[0064] The one or more communication units 244 of the computing device 210 can communicate with external devices via one or more wired and / or wireless networks by sending and / or receiving network signals over one or more networks. Examples of the one or more communication units 244 include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and / or receive information. Other examples of the one or more communication units 244 may include a shortwave radio, a cellular data radio, a wireless network radio, and a universal serial bus (USB) controller.

[0065] The UIC 212 of the computing device 210 may be hardware used as an input and / or output device for the computing device 210. For example, the UIC 212 may include a display component, which may be a screen where the UIC 212 displays information, and a presence-sensitive input component, which may detect objects at and / or near the display component.

[0066] One or more processors 240 may implement functionality and / or execute instructions within the computing device 210. For example, one or more processors 240 on the computing device 210 may receive and execute instructions stored by one or more storage components 248 that implement functionality of the attestation module 216, the contract module 252, and the software application 254. The instructions executed by the one or more processors 240 may cause the computing device 210 to store information within the one or more storage components 248 during program execution. Examples of the one or more processors 240 include application processors, display controllers, sensor hubs, and any other hardware configured to operate as a processing unit. The one or more processors 240 may execute instructions of the attestation module 216, the contract module 252, and the software application 254 to perform actions or functions. That is, the attestation module 216, the contract module 252, and the software application 254 may be capable of being operated by the one or more processors 240 to perform various actions or functions of the computing device 210.

[0067] One or more storage components 248 within computing device 210 may store information for processing during operation of computing device 210. That is, computing device 210 may store data accessed by attestation module 216, contract module 252, and software application 254 during execution at computing device 210. In some examples, one or more storage components 248 are temporary storage, meaning that the primary purpose of one or more storage components 248 is not long-term storage. One or more storage components 248 on computing device 210 may be configured as volatile memory for short-term storage of information, and therefore the stored contents are not retained in the event of a power outage. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art.

[0068] In some examples, storage component(s) 248 also include one or more computer-readable storage media. Storage component(s) 248 may be configured to store larger amounts of information than volatile memory. Storage component(s) 248 may be further configured as non-volatile memory space for long-term storage of information and retaining the information after power on / off cycles. Examples of non-volatile memory include a magnetic hard disk, an optical disk, a floppy disk, flash memory, or in the form of an electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Storage component(s) 248 may store program instructions and / or information (e.g., data) associated with attestation module 216, contract module 252, software application 254, and contract 220. Attestation module 216 may be executed at one or more processors 240 to perform operations associated with Figure 1 The functionality of the proof module 116 is similar to that of the previous one.

[0069] Software application 254 may represent any suitable software application executing on, at, or in computing device 210. A user of computing device 210 may interact with an interface (e.g., a graphical user interface) associated with software application 254 to cause computing device 210 to perform functions. There may be numerous examples of software application 254, and numerous examples include video streaming applications, calendar applications, personal assistants or prediction engines, search applications, map or navigation applications, transportation service applications (e.g., bus or train tracking applications), social media applications, gaming applications, email applications, messaging applications, internet browser applications, or any and all other applications that may be executed at computing device 210.

[0070] In some cases, software application 254 may not be permitted to perform actions if computing device 210 does not have certain attributes. For example, if software application 254 is an online banking application, software application 254 may not be able to receive a security token from an online banking website to securely perform online banking activities with the banking website if the version of the firmware of computing device 210 is outside an acceptable firmware version range. Therefore, in order to perform certain actions, software application 254 may attempt to prove that computing device 210 has one or more attributes that may be required for computing device 210 to perform those certain actions.

[0071] The contract module 252 can be configured to generate a contract that specifies actions and, for each action, specifies one or more properties that the computing device 210 may need to have in order to perform the action. For example, the contract module 252 can be executed at one or more processors 240 to generate a contract 220 that is Figure 1 The illustrated example of a contract 120 is associated with a software application 254, specifies an action for the software application 254 and an associated one or more specified properties that the computing device 210 needs to have in order to perform the action.

[0072] Contract module 252 may be configured to generate contract 220 associated with software application 254 before software application 254 performs actions specified in contract 220. In some examples, contract module 252 may be configured to generate contract 220 when software application 254 is installed at computing device 210, when software application 254 is first launched, whenever software application 254 is updated, or at any other suitable time.

[0073] The contract module 252 may be configured to receive a Figure 1 The computing system 102 shown in the figure receives one or more parameters associated with the contract 220. In some examples, the one or more parameters may indicate an action associated with one or more attributes, and the contract module 252 may be configured to generate a contract 220 that associates the indicated action with the indicated one or more attributes based on the one or more parameters. For example, the contract module 252 may be configured to generate cryptographic key material based on the one or more parameters, and may use the cryptographic key material to generate the contract 220.

[0074] Contract module 252 may be configured to generate contract 220 in the form of a cryptographic key that may be used to authenticate computing device 210 and / or software application 254 as an entity that may be granted permission to perform actions specified in contract 220. In some examples, contract module 252 may be further configured to generate contract 220 using secret authentication information, such as a password entered by a user (e.g., at one or more input components 242) or other suitable authentication input (e.g., a fingerprint).

[0075] In some examples, contract module 252 can be configured to cryptographically sign contract 220 using information known to computing device 210 and the computing system performing remote authentication of computing device 210, but unknown to other parties. Examples of such information may include a serial number or other information that uniquely identifies computing device 210 that is unknown to other parties. Thus, computing device 210 can send contract 220 to the computing system performing remote authentication of computing device 210.

[0076] After contract module 252 sends contract 220 to the computing system that performs remote authentication of computing device 210, computing device 210 may attempt to prove that computing device 210 has one or more properties specified by contract 220 in order for software application 254 to perform an associated action specified by contract 220. For example, computing device 210 may attempt to prove that computing device 210 has one or more properties specified by contract 220 each time software application 254 is launched, in response to software application 254 invoking an associated action specified by contract 220, etc. In some examples, computing device 210 may periodically attempt to prove that computing device 210 has one or more properties specified by contract 220 while software application 254 is executing at one or more processors 240.

[0077] Attestation module 216 may attempt to prove that computing device 210 has one or more properties specified by contract 220 by formulating a zero-knowledge proof (such as a zk-SNARK proof) that computing device 210 has the one or more properties, and may send the zero-knowledge proof to a computing system that performs remote attestation of computing device 210. The zero-knowledge proof may prove that computing device 210 has one or more properties specified by contract 220 without transmitting any other information about computing device 210. For example, to prove that the version of the firmware of computing device 210 is within a specified version range, the zero-knowledge proof may prove that the version of the firmware of computing device 210 is within the specified version range without transmitting the actual version of the firmware of computing device 210 or any other additional information.

[0078] Attestation module 216 may be configured to send an indication of the zero-knowledge proof to the computing system performing remote attestation by cryptographically signing contract 220 using the zero-knowledge proof and sending contract 220 signed using the zero-knowledge proof to the computing system performing remote attestation of computing device 210. If the computing system is able to successfully verify that computing device 210 has the zero-knowledge proof of one or more attributes specified by contract 220, the computing system may grant computing device 210 permission to perform the specified action.

[0079] Specifically, computing device 210 may receive data that enables computing device 210 and / or software application 254 to perform an action specified by contract 220. For example, if the action specified by contract 220 is to decrypt and play back an encrypted video stream, computing device 210 may receive an encryption key that enables software application 254 to decrypt and play back the encrypted video stream. In another example, if the action specified by contract 220 is to authenticate software application 254 with an online banking system, computing device 210 may receive a security token that enables software application 254 to authenticate with an online banking system using the security token.

[0080] Figure 3 is a block diagram illustrating further details of an example computing system in accordance with one or more aspects of the present disclosure. Figure 3 The computing system 302 is hereinafter referred to as Figure 1 An example of a computing system 102 is described. Figure 3 Only one particular example of computing system 302 is illustrated, and many other examples of computing system 302 may be used in other situations and may include a subset of the components included in example computing system 302, or may include Figure 3 For example, computing system 302 may include a server cluster, and each of the servers constituting the server cluster constituting computing system 302 may include the server described herein. Figure 3 All or some of the components described in order to perform the technology disclosed herein.

[0081] like Figure 3 As shown in the example of FIG. 3 , the computing system 302 includes one or more processors 340, one or more communication units 342, and one or more storage components 348. The storage component 348 includes a checker module 306, one or more entity modules 352, and one or more registers 308. The checker module 306 is Figure 1 The example of the checker module 106 shown, and one or more registers 308 are Figure 1 An example of one or more registers 108 is shown.

[0082] The one or more processors 340 may implement functionality associated with the computing system 302 and / or execute instructions associated with the computing system. Examples of the one or more processors 340 include an application processor, a display controller, an auxiliary processor, one or more sensor hubs, and any other hardware configured to function as a processor, a processing unit, or a processing device. The checker module 306 and the one or more entity modules 352 may be operable by the one or more processors 340 to perform various actions, operations, or functions of the computing system 302. For example, the one or more processors 340 of the computing system 302 may retrieve and execute instructions stored by the one or more storage components 348 that cause the one or more processors 340 to perform operations of the checker module 306 and the one or more entity modules 352. When executed by the one or more processors 340, the instructions may cause the computing system 302 to store information within the one or more storage components 348, for example, in one or more registers 308.

[0083] The one or more communication units 342 of the computing system 302 can communicate with external systems via one or more wired and / or wireless networks by sending and / or receiving network signals over one or more networks. Examples of the one or more communication units 342 include a network interface card (e.g., such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a global positioning satellite (GPS) receiver, or any other type of device that can send and / or receive information. Other examples of the one or more communication units 342 can include a shortwave radio, a cellular data radio, a wireless network radio, and a universal serial bus (USB) controller.

[0084] Communication channel 350 can interconnect each of components 340, 342, and 348 for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channel 350 can include a system bus, a network connection, an inter-process communication data structure, or any other method for conveying data.

[0085] One or more storage components 348 within computing system 302 may store information for processing during operation of computing system 302 (e.g., computing system 302 may store data accessed by checker module 306 and one or more entity modules 352 during execution at computing system 302). In some examples, one or more storage components 348 are temporary storage, meaning that the primary purpose of one or more storage components 348 is not long-term storage. In this example, one or more storage components 348 may be configured as volatile memory for short-term storage of information, and thus the stored contents are not retained in the event of a power outage. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art.

[0086] In some examples, one or more storage components 348 may also include one or more computer-readable storage media. In some examples, one or more storage components 348 include one or more non-transitory computer-readable storage media. One or more storage components 348 may be configured to store a larger amount of information than is generally stored by volatile memory. One or more storage components 348 may be further configured as non-volatile memory space for long-term storage of information and retain information after power on / off cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. One or more storage components 348 may store program instructions and / or information (e.g., data) associated with the checker module 306. One or more storage components 348 may include a memory configured to store data or other information associated with the checker module 306 and one or more registers 308.

[0087] The computing system 302 is configured to execute Figure 1 To perform remote authentication of a computing device, the computing device may generate an associated contract 320, which is Figure 1 In an example of contract 120, computing system 302 can use contract 320 to perform remote authentication of a computing device, and contract 320 also acts as a cryptographic key for secure communications between computing system 302 and the computing device.

[0088] To assist the computing device in generating the contract 320, one or more entity modules 352 associated with and / or under the control of an entity related to the computing device may be configured to generate one or more parameters. The one or more parameters may specify an action and associated one or more attributes that the computing device may use to generate the contract 320 that specifies one or more attributes that the computing device may need to have in order to perform the action.

[0089] Each of the one or more entity modules 352 can be associated with and / or under the control of an entity related to a computing device for which the computing system 302 performs remote attestation. Examples of entities include a manufacturer of the computing device, a provider of an operating system for the computing device, a developer of a software application executing at the computing device, etc.

[0090] Each entity module in one or more entity modules 352 can specify one or more properties of a computing device that can be verified by the corresponding entity module as one or more parameters. For example, an entity module associated with a provider of an operating system and / or under the control of the provider of the operating system can specify properties related to the operating system of the computing device as one or more parameters. In another example, an entity module associated with a manufacturer of a computing device and / or under the control of the manufacturer of the computing device can specify properties related to the hardware and / or firmware of the computing device as one or more parameters. Therefore, the computing system 302 can be configured to send the parameters generated by each entity module in one or more entity modules 352 to the computing device for use in generating the contract 320.

[0091] Computing system 302 may be configured to receive contract 320 from a computing device for which computing system 302 performs remote authentication, and may be configured to verify contract 320 to determine whether contract 320 is a valid contract in response to receiving contract 320. For example, if contract 320 is cryptographically signed using secret information that may be known only to computing system 302 and the computing device that signed contract 320, verifier module 306 may be configured to verify the cryptographic signature of contract 320, and may determine that contract 320 is a valid contract in response to successfully verifying the cryptographic signature.

[0092] Verifier module 306 can be configured to, in response to determining that contract 320 is a valid contract, generate an authentication proof of the computing device and add the authentication proof to one or more registers 308. That is, computing system 302 can add an entry to each register in one or more registers 308 indicating that the computing device has one or more properties specified by contract 320 and / or that contract 320 is a valid contract between the computing device and computing system 302.

[0093] In some examples, each register in the one or more registers 308 is associated with and / or under the control of a corresponding entity module in the one or more entity modules 352. For example, if the one or more entity modules 352 include the following two entity modules: an entity module associated with a manufacturer of the computing device and an entity module associated with a provider of an operating system for the computing device, each of the two entity modules can be associated with and / or control a corresponding register in the one or more registers 308.

[0094] After receiving and validating the contract 320, the computing system 302 may be configured to receive a zero-knowledge proof that the computing device has one or more properties specified by the contract 320. For example, the computing system 302 may be configured to receive the contract 320 cryptographically signed using the zero-knowledge proof. The verifier module 306 may, in response to receiving the contract 320 cryptographically signed using the zero-knowledge proof, verify that the contract 320 received from the computing device is a valid cryptographic key via any suitable technique for validating a cryptographic key, such as by comparing the received contract 320 to a contract 320 stored in one or more storage components 348.

[0095] If verifier module 306 successfully verifies contract 320, then verifier module 306 may be configured to verify that the zero-knowledge proof successfully proves that the computing device has one or more properties specified by contract 320 to perform an associated action. For example, if it can be proven that the computing device has one or more properties specified by contract 320 to perform an associated action if the zero-knowledge proof proves knowledge of a cryptographic sum of certain properties of the computing device, then verifier module 306 may be configured to determine whether the zero-knowledge proof actually proves such knowledge of the cryptographic sum of certain properties of the computing device.

[0096] In some examples, one or more entity modules 352 may be configured to verify whether the zero-knowledge proof proves that the computing device has one or more properties specified by the contract 320 to perform the associated action. As discussed above, each of the one or more entity modules 352 may specify one or more properties of the computing device that may be verified by the corresponding entity module as one or more parameters. Thus, each of the one or more entity modules 352 may be configured to verify whether the zero-knowledge proof proves that the computing device has one or more properties specified by the corresponding entity module. For example, if a first entity module in the one or more entity modules 352 specifies a first one or more properties, and if a second entity module in the one or more entity modules 352 specifies a second one or more properties, the first entity module may be configured to verify whether the zero-knowledge proof proves that the computing device has the first one or more properties, and the second entity module may be configured to verify whether the zero-knowledge proof proves that the computing device has the second first one or more properties.

[0097] In some examples, if each entity module in the one or more entity modules 352 successfully verifies within a specified time window that the zero-knowledge proof proves that the computing device has one or more properties specified by the corresponding entity module, then the verifier module 306 can determine that the zero-knowledge proof proves that the computing device has each of the properties specified by the contract 320. If the verifier module 306 determines that the zero-knowledge proof does not prove that the computing device has one or more properties specified by the contract 320 to perform the associated action, the verifier module 306 can be configured to invalidate the contract 320. For example, the verifier module 306 can be configured to update each register in the one or more registers 308 to indicate that the contract 320 is not valid and that the computing device has not proved that the computing device has each of the one or more properties specified by the contract 320.

[0098] If verifier module 306 successfully verifies the zero-knowledge proof as proving that the computing device has each of the one or more attributes specified by contract 320, computing system 302 may permit the computing device to perform an action associated with the one or more attributes as specified by contract 320, such as by granting the computing device access to resources used by the computing device to perform the action. For example, computing system 302 may grant computing device 110 access to an encryption key for decrypting an encrypted video stream by sending the encryption key to the computing device.

[0099] In some examples, to grant a computing device access to resources used by the computing device to perform an action specified by contract 320, one or more entity modules 352 may be configured to update one or more registers 308 to indicate that the computing device has been successfully verified as having one or more properties specified by contract 320 for performing an action specified by contract 320. For example, if a first entity module specifies a first one or more properties specified in contract 320, and if a second entity module specifies a second one or more properties specified in contract 320, the first entity module may be configured to add an entry in a first register in one or more registers 308 to indicate that the computing device has the first one or more properties, and the second entity module may be configured to add an entry in a second register in one or more registers 308 to indicate that the computing device has the first one or more properties.

[0100] The computing system 302 and other third-party systems may use the information indicated in the one or more registers 308 to determine whether to send one or more resources to the computing device to enable the computing device to perform the action specified by the contract 320. For example, if the action specified by the contract 320 is an action to play back an encrypted video stream, the system storing the encryption key for decrypting the encrypted video stream may determine whether the computing device is permitted to play back the encrypted video stream based on the information in the one or more registers 308. If the system determines that the computing device is permitted to play back the encrypted video stream based on the information in the one or more registers 308, the system may send the encryption key for decrypting the encrypted video stream to the computing device.

[0101] In some examples, if verifier module 306 successfully verifies the zero-knowledge proof as proving that the computing device has each of the one or more properties specified by contract 320, computing system 302 can be configured to perform ratcheting of cryptographic keys used to securely communicate with the computing device, such as via use of a double ratcheting algorithm, such as by performing ratcheting of contract 320. Computing system 302 can perform ratcheting of contract 320 such that even if contract 320 is compromised, ratcheting of contract 320 can prevent a malicious actor from using a stolen cryptographic key to compromise communications between computing system 302 and the computing device.

[0102] Figure 4 Example techniques for remote authentication according to aspects of the present disclosure are illustrated. Figure 4 As shown, the computing system 402 (which is Figure 1 The computing system 102 and Figure 3 302) may perform operations on computing device 410 (which is Figure 1 The computing device 110 and Figure 2remote authentication of computing device 210) to verify whether computing device 410 has one or more attributes to grant computing system 402 permission to perform one or more actions.

[0103] One or more entities may determine actions that computing device 410 is permitted to perform based at least in part on verifying the state of computing device 410, and may agree on a set of parameters indicating one or more actions, and for each of the one or more actions, agree on an associated state of computing device 410 that, if verified, would allow computing device 410 to perform the action. Figure 4 In the example of , the one or more entities may include the following two entities: entity 450A and entity 450B that can determine and generate parameter 440.

[0104] Entity 450A and entity 450B may be trusted parties, such as a manufacturer of computing device 410, a provider of an operating system for computing device 410, an application developer, and / or other parties that may be trusted to determine actions that computing device 410 is permitted to perform based at least in part on verifying a state of computing device 410. For example, entity 450A may be a provider of an operating system for computing device 410, and entity 450B may be a manufacturer of computing device 410.

[0105] Entities 450A and 450B may collude to determine parameters 440 used by computing device 410 to generate contract 420. The parameters may indicate one or more actions and, for each of the one or more actions, indicate associated one or more properties of computing device 410 that, if verified, allow computing device 410 to perform the action. For example, each of entities 450A and 450B may determine one or more properties of computing device 410 that may be required in order to allow computing device 410 to perform an action, one or more properties of computing device 410 that may be verified by the respective entities 450A and 450B, etc., to determine and generate parameters 440.

[0106] exist Figure 4 In the example of FIG. 4 , if computing device 410 has attributes 422A, 422B, and 422C, entities 450A and 450B may determine and generate parameters indicating actions that may be performed by computing device 410. Attributes 422A, 422B, and 422C may include any combination of hardware attributes, software attributes, and the like.

[0107] Computing device 410 may generate cryptographic key material 424 using parameters 440 generated by entities 450A and 450B, and may generate contract 420 (which is a cryptographic key material) based at least in part on key material 424. Figure 1For example, computing device 410 may generate contract 420 based on parameters 440 determined by entities 450A and 450B, which may indicate actions that computing device 410 is permitted to perform if computing device 410 has attributes 422A, 422B, and 422C.

[0108] Contract 420 acts as a signature of one or more authenticatable states of computing device 410, such as the state of the firmware of computing device 410, and is bound to unique information on computing device 410, which is referred to herein as an identity. The identity associated with computing device 410 is bound to computing device 110 through a witness. In examples where computing device 410 generates contract 420, the witness may be in the form of a verification, such as a password entered by a user. Thus, computing device 410 may generate contract 420 based at least in part on cryptographic key material 424 and a form of verification, such as a password entered by a user.

[0109] Computing device 410 may also cryptographically sign contract 420 using information known to computing system 402 that performs remote attestation of computing device 410 and / or known to entities 450A and 450B. For example, such information may be information known at the time of manufacture of computing device 410. Thus, computing device 410 may send cryptographically signed contract 420 to computing system 402. Computing system 402 may, in response to receiving cryptographically signed contract 420, verify the cryptographic signature of contract 420, and may, upon successful verification, store contract 420 and update registers 408A and 408B to add the authentication proof of computing device 410.

[0110] Multiple entities may each be associated with a corresponding register, as different entities may attest to different portions of the attestation generated by computing device 410. Figure 4 In the example of , entity 450A may be a software entity, such as a provider of an operating system for computing device 410, and may attest to software properties of computing device 410. Thus, entity 450A may be associated with register 408A that stores attestation of the software state of computing device 410. Similarly, entity 450B may be a hardware entity, such as a manufacturer of computing device 410, and may attest to hardware properties of computing device 410. Thus, entity 450B may be associated with register 408B that stores attestation of the hardware state of computing device 410. Figure 4 In the example of , computing system 402 may add authentication proof of software attributes of computing device 410 in register 408A and authentication proof of hardware attributes of computing device 410 in register 408B upon successful verification of contract 420 .

[0111] Computing device 410 may generate a zero-knowledge proof, such as a zk-SNARK proof, that computing device 410 has one or more properties specified by contract 420 as being required to perform an action, and may send an indication of the zero-knowledge proof to computing system 402. For example, computing device 410 may cryptographically sign contract 420 using the zero-knowledge proof, and may send contract 420 that has been cryptographically signed using the zero-knowledge proof to computing system 402.

[0112] Computing system 402 may attempt to verify the zero-knowledge proof in response to receiving an indication of a zero-knowledge proof, such as in the form of a contract 420 cryptographically signed using the zero-knowledge proof. That is, computing system 402 may determine whether the zero-knowledge proof successfully proves that computing device 110 has one or more properties specified by contract 420 to perform an associated action.

[0113] exist Figure 4 In the example of , computing device 410 may generate a zero-knowledge proof that, in its current state, computing device 410 has attributes 422A-422C, where attribute 422A is a software attribute and attributes 422B and 422C are hardware attributes. As discussed above, multiple entities may each verify a portion of a proof received from computing device 410. That is, if the proof attempts to prove that computing device 410 has multiple attributes, each of the entities may verify a subset (i.e., less than all) of the multiple attributes.

[0114] Therefore, in Figure 4 In the example of , entity 450A, which is a software entity, can verify that the portion of the proving computing device 410 of the zero-knowledge proof has the software attribute 422A, and can add an entry in register 408A, which indicates whether entity 450A can successfully verify that the proving computing device 410 of the zero-knowledge proof has the software attribute 422A. Similarly, entity 450B can verify that the portion of the proving computing device 410 of the zero-knowledge proof has the hardware attributes 422B and 422C, and can add an entry in register 408B, which indicates whether entity 450B can successfully verify that the proving computing device 410B of the zero-knowledge proof has the hardware attributes 422B and 422C.

[0115] Verifier module 406 (which is Figure 1In some examples, the verifier module 406 can determine whether the computing system 102 can successfully verify the zero-knowledge proof that the computing device 110 has each of the attributes 422A-422C within a specified time window, which can be 5 seconds, 30 seconds, 1 minute, etc. Limiting the amount of time used to verify the zero-knowledge proof can prevent unlimited delimitation and other ways for malicious actors to compromise the integrity of the remote attestation. In some examples, the verifier module 406 can also perform the proof verification described above as being performed by entities 450A and 450B.

[0116] If verifier module 406 determines that computing system 102 is able to successfully verify the zero-knowledge proof that proves computing device 110 has each of attributes 422A-422C within the specified time window, verifier module 406 can determine that computing device 410 has successfully proved that computing device 410 has each of attributes 422A-422C, and computing system 402 can grant computing device 410 permission to perform actions associated with attributes 422A-422C. For example, because registers 408A and 408B include the authentication proof that computing device 410 has proved that computing device 410 has attributes 422A-422C, a third party (e.g., an external system) can send a cryptographic key to computing device 410 based on the authentication proof in registers 408A and 408B, and computing device 410 can use the cryptographic key to perform actions associated with attributes 422A-422C, such as decrypting an encrypted video for playback.

[0117] If verifier module 406 determines that computing device 410 has successfully proved that computing device 410 has each of properties 422A-422C, computing system 402 can perform ratcheting of contract 420 according to a cryptographic ratcheting algorithm, such as a double ratcheting algorithm. Performing ratcheting of contract 420 can enable computing system 402 and computing device 410 to ensure that communications between computing system 402 and computing device 410 can remain secure even if contract 420 is stolen or otherwise known to a malicious actor.

[0118] If verifier module 406 determines that computing system 102 cannot successfully verify the zero-knowledge proof proving that computing device 110 possesses each of properties 422A-422C within the specified time window, verifier module 406 may determine that computing device 410 failed to prove that computing device 410 possesses each of properties 422A-422C. Therefore, computing device 410 may invalidate contract 420, including updating registers 408A and 408B with information indicating that computing device 410 failed to prove that computing device 410 possesses properties 422A-422C.

[0119] Figure 5 is a flowchart of an example process for an example computing device to authenticate an entity having one or more attributes according to aspects of the present disclosure. In some examples, Figure 5 The process shown can be done by Figure 1 The computing device 110 shown is executed. In some implementations, Figure 5 The example process shown may include Figure 5 The blocks described in the example process may include additional blocks, fewer blocks, different blocks, or blocks arranged in a different manner than those depicted in the example process. Additionally or alternatively, two or more blocks in the blocks of the example process may be executed in parallel.

[0120] like Figure 5 As shown, in order to prove that computing device 110 has one or more properties required to perform an action, computing device 110 may determine whether there is a valid contract that specifies that if computing device 110 has the one or more properties, computing device 110 is allowed to perform the action (502). If computing device 110 determines that there is no valid contract (No at step 502), computing device 110 may generate a contract 120 that specifies that if computing device 110 has the one or more properties, computing device 110 is allowed to perform the action (504).

[0121] For example, computing device 110 may generate cryptographic key material based on parameters determined by one or more entities associated with computing device 110, and may use the cryptographic key material to generate contract 120. In some examples, computing device 110 may also receive an authentication factor, such as a password entered by a user of computing device 110, and may use the cryptographic key material to generate contract 120 based on the entered password.

[0122] Computing device 110 may send contract 120 to computing system 102 (506), which performs remote authentication of computing device 110. For example, computing device 110 may sign contract 120 using information known only to computing device 110 and computing system 102, and may send the signed contract 120 to computing system 102.

[0123] Computing device 110 may generate a zero-knowledge proof that computing device 110 has one or more properties required to perform an action (508) after sending contract 120 to computing system 102, or in response to determining that there is a valid contract 120 (yes at step 502), and send the zero-knowledge proof to computing system 102 (510). In some examples, the zero-knowledge proof may be a zk-SNARK proof or any other suitable zero-knowledge proof.

[0124] Computing device 110 may receive permission to perform an action in response to computing system 102 successfully verifying the zero-knowledge proof that computing device 110 has one or more properties required to perform the action (512). For example, computing device 110 may receive data from computing system 102 or another remote computing system that enables computing device 110 to perform an action that requires computing device 110 to have one or more properties. Such data may be an encryption key that enables computing device 110 to decrypt certain encrypted content, third-party resources, etc.

[0125] Figure 6 is a flowchart of an example process for an example computing system to perform remote authentication of an example computing device according to aspects of the present disclosure. In some examples, Figure 6 The process shown can be done by Figure 1 The computing system 102 shown is executed. In some implementations, Figure 6 The example process shown may include Figure 6 The blocks described in the example process may include additional blocks, fewer blocks, different blocks, or blocks arranged in a different manner than those depicted in the example process. Additionally or alternatively, two or more blocks of the blocks in the example process may be executed in parallel.

[0126] like Figure 6 As shown, computing system 102 may receive contract 120 from computing device 110, the contract specifying an action that requires computing device 110 to prove that computing device 110 has one or more properties (602). Computing system 102 may verify contract 120, such as by determining whether contract 120 is signed using a valid signature, and may record the authentication proof of computing device 110 in one or more registers 108 upon successful verification of contract 120 (604).

[0127] Subsequently, computing system 102 may receive from computing device 110 an indication that computing device 110 has a zero-knowledge proof of one or more properties specified in contract 120 (606). For example, computing system 102 may receive contract 120 that has been digitally signed using a zero-knowledge proof.

[0128] Computing system 102 may attempt to verify the zero-knowledge proof received from computing device 110 to determine whether the zero-knowledge proof successfully proves that computing device 110 has one or more properties (608). If computing system 102 cannot verify the zero-knowledge proof proves that computing device 110 has one or more properties (no at 610), computing system 102 may invalidate contract 120 (612). For example,

[0129] If computing system 102 successfully verifies that the zero-knowledge proof proves that computing device 110 has one or more attributes (yes at 610), computing system 102 may grant computing device 110 permission to perform actions specified in contract 120 that require computing device 110 to prove that computing device 110 has the one or more attributes (614). For example, computing system 102 may add an entry in one or more registers 108 indicating that computing device 110 has the one or more attributes required to perform an action. Computing system 102 and other third-party computing systems may rely on the entry in one or more registers 108 to determine that computing device 110 has permission to perform an action. For example, an external system may send a cryptographic key to computing device 110 that computing device 110 may use to perform an action based on an entry in one or more registers 108 indicating that computing device 110 has the one or more attributes required to perform an action.

[0130] If computing system 102 successfully verifies that the zero-knowledge proof proves that computing device 110 has one or more properties (yes at 608), computing system 102 may also perform ratcheting of contract 120. Whenever computing device 110 successfully proves that computing device 110 has one or more properties required to perform an action as specified by contract 120, computing device 110 may perform ratcheting of contract 120, which may help ensure secure communications between computing device 110 and computing system 102.

[0131] Figure 7 is a flow chart of an example process for remote authentication according to aspects of the present disclosure. Figure 7 is Figure 2 and Figure 3 According to the example, Figure 7 One or more process boxes can be Figure 3 The computing system 302 is shown executing.

[0132] like Figure 7 As shown, the process may include one or more processors 340 of computing system 302 receiving an indication from computing device 210 that computing device 210 has a zero-knowledge proof of one or more properties, such as a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof (block 702). For example, one or more processors 340 of computing system 302 may receive an indication from computing device 210 that computing device has a zero-knowledge proof of one or more properties, as described above.

[0133] like Figure 7As further shown, the process may include one or more processors 340 verifying that the zero-knowledge proof proves that computing device 210 has one or more properties (block 704). For example, one or more processors 340 of computing system 302 may verify that the zero-knowledge proof proves that computing device 210 has one or more properties.

[0134] like Figure 7 As shown, the process may include one or more processors 340, in response to successfully verifying the zero-knowledge proof, granting computing device 210 permission to perform an action that requires the computing device to have one or more properties (block 706). For example, one or more processors 340 of computing system 302 may, in response to successfully verifying the zero-knowledge proof, grant computing device 210 permission to perform an action that requires computing device 210 to have one or more properties, such as granting computing device 210 access to a resource. In some examples, one or more processors 340 may grant computing device 210 permission to perform an action by sending a cryptographic key to computing device 210 that enables computing device 210 to perform the action.

[0135] In some examples, the contract specifies, for each respective one of the one or more actions, the respective one or more properties that the computing device 210 needs to have in order to perform the action. The contract may specify, for the action, that the computing device 210 needs to have one or more properties in order to perform the action. In some examples, the one or more processors 340 may, in response to the computing device 210 generating the contract, add an authentication certificate of the computing device 210 to the register to indicate that the contract is valid.

[0136] In some examples, the contract specifies that computing device 210 needs to have a second one or more properties in order to perform the second action for the second action. One or more processors 340 may receive from computing device 210 an indication of a second zero-knowledge proof that computing device 210 has the second one or more properties. One or more processors 340 may verify that the second zero-knowledge proof proves that computing device 210 has the second one or more properties. One or more processors 340 may invalidate the contract in response to failure to successfully verify the second zero-knowledge proof.

[0137] In some examples, to receive from computing device 210 an indication that computing device 210 has a zero-knowledge proof of one or more properties, one or more processors 340 may receive from computing device 210 a contract signed using the zero-knowledge proof. In some examples, one or more processors 340 may perform ratcheting of the contract in response to successfully verifying the zero-knowledge proof.

[0138] In some examples, one or more processors 340 may send a plurality of parameters for generating a contract to computing device 210. In some examples, a first one or more parameters of the plurality of parameters are specified by a first entity, and a second one or more parameters of the plurality of parameters are specified by a second entity. In some examples, the first entity is a manufacturer of computing device 210, and the second entity provides an operating system for computing device 210.

[0139] In some examples, in order to verify that the zero-knowledge proof proves that the computing device 210 has one or more properties, the one or more processors 340 may verify that the zero-knowledge proof proves that the computing device 210 has a third one or more properties, verify that the zero-knowledge proof proves that the computing device 210 has a fourth one or more properties, and in response to successfully verifying that the zero-knowledge proof proves that the computing device 210 has the third one or more properties and proving that the computing device 210 has the fourth one or more properties within a specified time window, determine that the zero-knowledge proof has been successfully verified.

[0140] Figure 8 is a flow chart of an example process for remote authentication according to aspects of the present disclosure. Figure 8 is Figure 2 and Figure 3 In some implementations, Figure 8 One or more process boxes can be Figure 2 The computing device 210 is shown executing.

[0141] like Figure 8 As shown, the process may include generating a zero-knowledge proof that a computing device has one or more properties (block 802). For example, one or more processors 240 of computing device 210 may generate a zero-knowledge proof that computing device 210 has one or more properties, such as a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof, as described above. Figure 8 As further shown, the process may include sending, by one or more processors, an indication of the zero-knowledge proof to a computing system (block 804). For example, one or more processors 240 of computing device 210 may send an indication of the zero-knowledge proof to computing system 302, as described above. Figure 8As further shown, the process may include receiving, by one or more processors, data that enables the computing device to perform an action that requires the computing device to have one or more properties in response to the computing system 302 successfully verifying the zero-knowledge proof (block 806). For example, one or more processors 240 of computing device 210 may receive data that enables computing device 210 to perform an action that requires computing device 210 to have one or more properties in response to the computing system 302 successfully verifying the zero-knowledge proof, such as by receiving a cryptographic key that enables computing device 210 to perform the action, as described above.

[0142] In some examples, the contract may specify, for each respective one of the one or more actions, the respective one or more properties that the computing device 210 needs to have in order to perform the action, and may specify, for the action, the one or more properties that the computing device 210 needs to have in order to perform the action. The one or more processors 240 of the computing device 210 may receive a plurality of parameters for generating the contract and may generate the contract based at least in part on the parameters. In some examples, a first one or more parameters of the plurality of parameters are specified by a first entity, and a second one or more parameters of the plurality of parameters are specified by a second entity.

[0143] In some examples, to generate a contract based at least in part on the plurality of parameters, one or more processors 240 may generate cryptographic key material based at least in part on the plurality of parameters, and may use the cryptographic key material to generate the contract. In some examples, to generate a contract based at least in part on the plurality of parameters, one or more processors 240 may determine verification information associated with computing device 210, and may generate the contract based at least in part on the verification information. In some examples, such verification information may include a password.

[0144] In some examples, to send an indication of the zero-knowledge proof, one or more processors 240 may sign the contract using the zero-knowledge proof and may send an indication of the signed contract to computing system 302. In some examples, computing device 210 may be unable to provide a hardware guarantee that computing device 210 has one or more properties.

[0145] Aspects of the disclosure include the following examples.

[0146] Example 1. A method comprising: receiving, by one or more processors of a computing system, an indication of a zero-knowledge proof from a computing device that the computing device has one or more properties; verifying, by the one or more processors, that the zero-knowledge proof proves that the computing device has the one or more properties; and in response to successfully verifying the zero-knowledge proof, granting, by the one or more processors, the computing device permission to perform an action that requires the computing device to have the one or more properties.

[0147] Example 2. The method of Example 1, wherein the zero-knowledge proof is a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof.

[0148] Example 3. The method of any of Examples 1 and 2, wherein granting the computing device permission to perform the action further comprises: granting, by one or more processors, the computing device access to the resource.

[0149] Example 4. The method of any one of Examples 1 to 3, wherein granting the computing device permission to perform the action further comprises: sending, by the one or more processors, to the computing device a cryptographic key that enables the computing device to perform the action.

[0150] Example 5. The method of any one of Examples 1 to 4, wherein the contract specifies, for each respective one of the one or more actions, respective one or more properties that the computing device needs to have in order to perform the action.

[0151] Example 6. The method of Example 5, wherein the contract specifies that the computing device needs to have one or more properties in order to perform the action.

[0152] Example 7. The method of any of Examples 5 and 6, further comprising: in response to the computing device generating the contract, adding, by the one or more processors, an authentication certificate of the computing device to the register to indicate that the contract is valid.

[0153] Example 8. A method as described in any of Examples 5 to 7, wherein the contract specifies that the computing device must have one or more second attributes in order to perform the second action, further comprising: receiving, by one or more processors, an indication of a second zero-knowledge proof from the computing device that the computing device has the second one or more attributes; verifying, by one or more processors, that the second zero-knowledge proof proves that the computing device has the second one or more attributes; and in response to an inability to successfully verify the second zero-knowledge proof, invalidating the contract by the one or more processors.

[0154] Example 9. A method as described in any of Examples 5 to 8, wherein receiving an indication from a computing device that the computing device has a zero-knowledge proof of one or more attributes further includes: receiving, by one or more processors, a contract signed using the zero-knowledge proof from the computing device.

[0155] Example 10. The method of any one of Examples 5 to 8, further comprising: in response to successfully verifying the zero-knowledge proof, performing ratcheting of the contract by one or more processors.

[0156] Example 11. The method as described in any one of Examples 5 to 9 further includes: sending a plurality of parameters for generating a contract to a computing device by one or more processors.

[0157] Example 12. The method of Example 11, wherein: a first one or more parameters of the plurality of parameters are specified by a first entity, and a second one or more parameters of the plurality of parameters are specified by a second entity.

[0158] Example 13. The method of Example 12, wherein the first entity is a manufacturer of the computing device and the second entity provides an operating system for the computing device.

[0159] Example 14. A method as described in any of Examples 12 and 13, wherein verifying that the zero-knowledge proof proves that the computing device has one or more properties further includes: verifying, by one or more processors, that the zero-knowledge proof proves that the computing device has a third one or more properties; verifying, by one or more processors, that the zero-knowledge proof proves that the computing device has a fourth one or more properties; and in response to successfully verifying within a specified time window that the zero-knowledge proof proves that the computing device has the third one or more properties and proving that the computing device has the fourth one or more properties, determining, by the one or more processors, that the zero-knowledge proof has been successfully verified.

[0160] Example 15. A system comprising: a memory storing instructions; and one or more processors executing the instructions to perform the method as described in any one of Examples 1 to 14.

[0161] Example 16. An apparatus comprising: a component for performing the method as described in any one of Examples 1 to 14.

[0162] Example 17. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a computing system, cause the one or more processors to perform the method of any one of Examples 1 to 14.

[0163] Example 18. A method comprising: generating, by one or more processors of a computing device, a zero-knowledge proof that the computing device has one or more properties; sending, by the one or more processors, an indication of the zero-knowledge proof to a computing system; and receiving, by the one or more processors, an indication that enables the computing device to perform an action that requires the computing device to have the one or more properties in response to the computing system successfully verifying the zero-knowledge proof.

[0164] Example 19. The method of Example 18, wherein the zero-knowledge proof is a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof.

[0165] Example 20. A method as described in any of Examples 18 and 19, wherein receiving data that enables a computing device to perform an action that requires the computing device to have one or more attributes further includes: receiving, by one or more processors, a cryptographic key that enables the computing device to perform the action.

[0166] Example 21. A method as described in any of Examples 18 to 20, wherein the contract specifies, for each corresponding action of the one or more actions, the corresponding one or more properties that the computing device needs to have in order to perform the action.

[0167] Example 22. The method of Example 21, wherein the contract specifies that the computing device needs to have one or more properties in order to perform the action.

[0168] Example 23. The method as described in any of Examples 21 and 22 further includes: receiving, by one or more processors, a plurality of parameters for generating a contract; and generating, by one or more processors, the contract based at least in part on the parameters.

[0169] Example 24. The method of Example 23, wherein: a first one or more parameters of the plurality of parameters are specified by a first entity, and a second one or more parameters of the plurality of parameters are specified by a second entity.

[0170] Example 25. A method as described in any of Examples 23 and 24, wherein generating a contract based at least in part on multiple parameters further includes: generating cryptographic key material based at least in part on multiple parameters by one or more processors; and generating the contract using the cryptographic key material by one or more processors.

[0171] Example 26. A method as described in any of Examples 23 to 25, wherein generating a contract based at least in part on multiple parameters further includes: determining, by one or more processors, verification information associated with the computing device; and generating, by one or more processors, the contract based at least in part on the verification information.

[0172] Example 27. The method of Example 26, wherein the verification information includes a password.

[0173] Example 28. A method as described in any of Examples 21 to 27, wherein sending an indication of a zero-knowledge proof further includes: signing a contract using the zero-knowledge proof by one or more processors; and sending an indication of the signed contract to a computing system by one or more processors.

[0174] Example 29. The method of any of Examples 21 to 28, wherein the computing device does not provide a hardware guarantee that the computing device has one or more properties.

[0175] Example 30. A computing device comprising: a memory storing instructions; and one or more processors executing the instructions to perform a method as described in any one of Examples 18 to 29.

[0176] Example 31. An apparatus comprising: a component for performing the method as described in any one of Examples 18 to 29.

[0177] Example 32. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform the method of any one of Examples 18 to 29.

[0178] By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, flash memory, or any other storage medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave is used to send instructions from a website, server or other remote source, then the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other temporary media, but are directed to non-temporary tangible storage media. Disks and optical disks as used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks and blue-ray disks, where disks usually reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

[0179] Instructions may be executed by one or more processors such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuit systems. Therefore, as used herein, the term "processor" may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. In addition, the techniques may be fully implemented in one or more circuits or logic elements.

[0180] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in the present disclosure to emphasize the functional aspects of the apparatus configured to perform the disclosed techniques, but the various components, modules, or units are not necessarily required to be implemented by different hardware units. Instead, as described above, the various units may be combined in a hardware unit, or provided by a collection of interoperable hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

[0181] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

Claims

1. A method comprising: Generating, by one or more processors of a computing device, a zero-knowledge proof that the computing device has one or more properties; sending, by the one or more processors, an indication of the zero-knowledge proof to a computing system; as well as In response to the computing system successfully verifying the zero-knowledge proof, data is received by the one or more processors that enables the computing device to perform an action that requires the computing device to have the one or more properties.

2. The method of claim 1, wherein the zero-knowledge proof is a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof.

3. The method of any one of claims 1 and 2, wherein receiving the data that enables the computing device to perform an action that requires the computing device to have the one or more attributes further comprises: A cryptographic key is received by the one or more processors that enables the computing device to perform the action.

4. The method of any one of claims 1 to 3, wherein the contract specifies, for each respective one of one or more actions, respective one or more properties that the computing device needs to have in order to perform the action, and wherein the indication of sending the zero-knowledge proof further comprises: Signing the contract by the one or more processors using the zero-knowledge proof; as well as An indication of the signed contract is sent, by the one or more processors, to the computing system.

5. The method of claim 4, further comprising: receiving, by the one or more processors, a plurality of parameters for generating the contract; as well as The contract is generated, by the one or more processors, based at least in part on the plurality of parameters.

6. The method of claim 5, wherein: A first one or more parameters of the plurality of parameters are specified by a first entity and a second one or more parameters of the plurality of parameters are specified by a second entity.

7. The method of any one of claims 5 and 6, wherein generating the contract based at least in part on the plurality of parameters further comprises: generating, by the one or more processors, cryptographic key material based at least in part on the plurality of parameters; as well as The contract is generated by the one or more processors using the cryptographic key material.

8. The method of any one of claims 5 to 7, wherein generating the contract based at least in part on the plurality of parameters further comprises: determining, by the one or more processors, authentication information associated with the computing device; as well as The contract is generated, by the one or more processors, based at least in part on the verification information.

9. The method of claim 8, wherein the authentication information comprises a password.

10. The method of any one of claims 1 to 9, wherein the computing device does not provide a hardware guarantee that the computing device has the one or more properties.

11. A computing device comprising: a memory storing instructions; as well as one or more processors that execute the instructions to: generating a zero-knowledge proof that the computing device has one or more properties; sending an indication of the zero-knowledge proof to a computing system; as well as In response to the computing system successfully verifying the zero-knowledge proof, receiving data that enables the computing device to perform an action that requires the computing device to have the one or more properties.

12. The computing device of claim 11, wherein the zero-knowledge proof is a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof.

13. The computing device of any one of claims 11 and 12, wherein to receive the data that enables the computing device to perform an action that requires the computing device to have the one or more attributes, the one or more processors further execute the instructions to: A cryptographic key is received that enables the computing device to perform the action.

14. The computing device of any one of claims 11 to 13, wherein the contract specifies, for each respective one of one or more actions, respective one or more properties that the computing device needs to have in order to perform the action, and wherein to send the indication of the zero-knowledge proof, the one or more processors further execute the instructions to: Signing the contract using the zero-knowledge proof; and An indication of the signed contract is sent to the computing system.

15. The computing device of claim 14, wherein the one or more processors further execute the instructions to: receiving a plurality of parameters for generating the contract; and The contract is generated based at least in part on the plurality of parameters.

16. The computing device of claim 15, wherein: A first one or more parameters of the plurality of parameters are specified by a first entity and a second one or more parameters of the plurality of parameters are specified by a second entity.

17. The computing device of any one of claims 15 and 16, wherein generating the contract based at least in part on the plurality of parameters further comprises: generating, by the one or more processors, cryptographic key material based at least in part on the plurality of parameters; as well as The contract is generated by the one or more processors using the cryptographic key material.

18. The computing device of any one of claims 15 to 17, wherein to generate the contract based at least in part on the plurality of parameters, the one or more processors further execute the instructions to: determining authentication information associated with the computing device; and The contract is generated based at least in part on the verification information.

19. The computing device of claim 18, wherein the authentication information comprises a password.

20. A non-transitory computer-readable storage medium comprising instructions that, when executed by one or more processors of a computing device, cause the one or more processors to: generating a zero-knowledge proof that the computing device has one or more properties; sending an indication of the zero-knowledge proof to a computing system; as well as In response to the computing system successfully verifying the zero-knowledge proof, receiving data that enables the computing device to perform an action that requires the computing device to have the one or more properties.

21. A method comprising: Receiving, by one or more processors of a computing system, from a computing device an indication that the computing device possesses a zero-knowledge proof of one or more properties; verifying, by the one or more processors, that the zero-knowledge proof proves that the computing device has the one or more properties; as well as In response to successfully verifying the zero-knowledge proof, the computing device is granted permission by the one or more processors to perform an action that requires the computing device to have the one or more properties.

Citation Information

Cited By

  • Method and System for Providing Triple-Gate Authentication by Using Public Key Label

    KR103025105B1