Decentralized remote attestation process

Abstract

The invention relates to a decentralized remote attestation method for verifying the authenticity of an Attester peer (20) within a peer network sharing a ledger (50), involving a Verifier peer (30) and an Oracle device (40) comprising a secure enclave and a random number generator. The Attester (30) publishes a public key in the ledger (50). The Oracle (40) generates a unique random number and an encryption key, then encrypts the random number and sends it via a secure channel to the Verifier. The Oracle (40) publishes the encrypted random number in the ledger (50). The Verifier (30) generates a challenge using the random number and the public key and publishes the challenge in the ledger. The Attester (20) solves the challenge using the private key and publishes a proof in the ledger (50). After the proof is published in the ledger (50), the Oracle (40) publishes the encryption key. Figure for the abridged version: [Fig. 1]

Description

Title of the invention: Decentralized remote attestation method Technical field of the invention

[0001] The invention relates to a decentralized remote attestation method. The invention relates in particular to the remote attestation of devices, referred to as peers in this text, connected in a decentralized network. The invention also relates to a method for verifying the authenticity of a peer. Previous technique

[0002] Remote Attestation is a security service in which one device, called the "verifier," remotely verifies the integrity and authenticity of another device, called the "attester." The objective is to ensure that the remote system has not been compromised by malware or unauthorized modifications.

[0003] This security service generally involves the verification device creating a cryptographic challenge containing a secret (usually a random number). The attesting device then solves this challenge to demonstrate its authenticity and integrity.

[0004] Remote attestation therefore necessarily implies the use of computing and memory resources by the devices to attest and verify.

[0005] A peer network, also called a decentralized peer-to-peer (P2P) network, is a computer network model where each participating device, called a peer, acts as both client and server, sharing its resources (such as bandwidth, storage space or computing power) directly with other peers without requiring a central server or administrative authority.

[0006] In a peer network, peers are autonomous and make individual decisions regarding how they share data and with whom they communicate. Also, files or data are distributed across the network, sometimes redundantly, which increases resilience and availability.

[0007] The absence of a central control point or failure makes the network robust against failures and targeted attacks because there is no single target that could disable the entire network.

[0008] A decentralized P2P network has the ability to organize and optimize itself without external intervention. Internal algorithms manage aspects such as routing, resource discovery, and data replication.

[0009] Decentralized P2P networks are particularly popular for applications such as file sharing, communication systems, and systems of Distributed storage and cryptocurrencies. However, they can pose challenges in terms of security, reliability and performance for certain uses.

[0010] The implementation of remote attestations between peers in a decentralized network therefore makes it possible to address the security problem inherent in decentralized peer networks.

[0011] However, remote attestation as generally practiced requires that, for peer i to establish that peer j is trustworthy, peers i and j perform remote attestation with peer i acting as the verifier and peer j as the attester. A network with many peers will therefore require significant computing resources dedicated to security so that peers can attest to each other.

[0012] The prior art proposes several protocols to address this problem:

[0013] Swarm attestation [Ref. 1] consists of attesting a network of devices in such a way that verification is more efficient when verifying a set of attested devices than when verifying each device individually. Generally, swarm attestations are used in large peer networks to increase efficiency. Many projects based on the use of a centralized "verify" device, such as SEDA [Ref. 2], LIS A [Ref. 3], SHela [Ref. 4], EAPA [Ref. 5], SAP [Ref. 6], WISE [Ref. 7], CoRA [Ref. 8], or FADIA [Ref. 9], collect attestations from several "attest" devices and aggregate them according to a tree structure to route them more efficiently to the "verify" device. Techniques such as DARPA [Ref. 10], SCAPI [Ref. 11], slimloT [Ref. 12] or PROVE [Ref.

[13] further introduce a mechanism to guarantee the legitimacy of the "attesting" devices and to monitor their presence in the swarm. Other works, notably DIAT [Ref. 14], US-AID [Ref. 15], ESDRA [Ref. 16] or PASTA [Ref. 17], consider the "verifying" devices to be network peers, capable of autonomously attesting to their neighbors. However, the result of the attestation is not publicly verifiable, leading each peer acting as "verifying" to perform the entire protocol.

[0014] The SANA swarm attestation protocol [Ref. 18] relies on a multi-signature scheme to aggregate attestation results within a large group of devices. In SANA, each device has an asymmetric key pair. Each "attest" device uses its secret key to sign its attestation. The attestations are then aggregated and can be verified by any "verify" peer that knows the public key of the "attest" devices. However, SANA does not provide details on the generation of the challenge credential that the "attest" device (called a "prover" in SANA) signs to attest to its legitimacy. The generation of this challenge, which includes a secret nonce, is crucial to prevent attacks by Replay. Furthermore, the aggregation of attestations within the network makes the network inflexible and slow to evolve. In addition, it is not specified how the devices are authenticated.

[0015] PERMANENT [Ref. 19] is a protocol that leverages blockchain technology to make remote attestation publicly verifiable. The PERMANENT protocol considers a peer-to-peer network of untrusted devices where participants can play the roles of "attest" and "verify" interchangeably. However, this protocol is implemented at the peer consensus level, which is the element that ensures the availability of the blockchain. In the case of PERMANENT, this consensus is closed, meaning that it is no longer possible to add a device to the consensus once the blockchain has started. This makes the solution difficult to maintain and does not allow for scalability (it is impossible to add or remove new peers).

[0016] The PROVE protocol aims to provide a solution enabling the public verifiability of attestations within a network of distributed devices, through a publish / subscribe mechanism, without relying on the use of a public key infrastructure (PKI), and without sending an attestation request to the peer (attest). PROVE relies on the use of a broker agent that transmits the attestations published by the devices (attest) to the subscribed verifier devices.

[0017] Deployed in large-scale distributed networks, these protocols are tricky to use because they require synchronicity of devices.

[0018] The SCRAPS protocol [Ref. 20], on the other hand, operates asynchronously within a network of devices using a blockchain. Verification of the attestation is delegated to a smart contract, which acts as a peer verifier proxy. The secret is a time-stamped value, generated by the blockchain and known to all peers in the network. The attesting device generates an attestation within a security hardware component and sends the attestation to a smart contract in the form of a transaction signed by its private key. The smart contract executes the verification process on the blockchain. For the incoming transaction to be valid, the manufacturer of the security component must deploy its smart contract on the network's blockchain. It must also register the public key of each security component used by the peers on the blockchain.Finally, it must deploy the attestation scheme supported by the components at the agent level. Implementing this solution becomes extremely complex, as the security component manufacturer must be involved in the blockchains of all peer networks using this solution. References

[0019] [Ref. 1] Ambrosin M., Conti M., Lazzeretti R., Rabbani MM, Ranise S., “Collective remote attestation at the internet of things scale: State-of-the-art and future challenges”, IEEE Communication Survey and Tutorials, 2020, vol 22, n°4

[0020] [Ref. 2] Asokan N., Brasser F., Ibrahim A., Sadeghi A.-R., Schunter M., Tsudik G., et al., “SEDA: Scalable embedded device attestation”, In Proceedings of the 22nd ACM SIGSAC conference on computer and communications security, 2015

[0021] [Ref. 3]Carpent X., El Defrawy K., Rattanavipanon N., Tsudik G., “LIghtweight Swarm Attestation: a taie of two LISA-s”, In Proceedings ACM on Asia conférence on computer and communications security, 2017, pp. 86-100

[0022] [Ref. 4]Rabbani M.M., Vliegen J., Winderickx J., Conti M., Mentens N., “SHeLA: Scalable heterogeneous layered attestation”, IEEE Internet Things Journal, 2019, vol 6, n°6

[0023] [Ref. 5]Yan W., Fu A., Mu Y., Zhe X., Yu S., Kuang B., “EAPA: Efficient attestation résilient to physical attacks for loT devices”, In Proceedings of the 2nd international ACM workshop on security and privacy for the internet-of-things, 2019, PP- 2-7

[0024] [Ref. 6]De Oliveira Nunes I., Dessouky G., Ibrahim A., Rattanavipanon N., Sadeghi A.-R., Tsudik G., “Towards systematic design of collective remote attestation protocols”, In IEEE 39th international conférence on distributed computing Systems”, 2019, http: / / dx.doi.org / 10.1109 / ICDCS.2019.00120

[0025] [Ref. 7]Ammar M., Crispo B., “WISE: A lightweight intelligent swarm attestation scheme for the internet of things”, ACM Trans Internet Things, 2020; vol 1, n°3, http: / / dx.doi.org / 10.1145 / 3386688

[0026] [Ref. 8]Diop A., Laurent M., Leneutre J., Traoré J., “CoRA: A scalable collective remote attestation protocol for sensor networks”, In Fumell S., Mori P., Weippl E. R., Camp O., In Proceedings of the 6th international conférence on information Systems security and privacy, SCITEPRESS; 2020, pp. 84-95, http: / / dx.d0i.0rg / l 0.5220 / 0008962700840095

[0027] [Ref. 9]Mansouri M., Jaballah W.B., Ônen M., Rabbani M.M., Conti M., “FADIA: Fairness driven collaborative remote attestation”, In Proceedings 14th ACM conférence on security and privacy in wireless and mobile networks, 2021, pp. 60-71

[0028] [Ref. 10]Ibrahim A., Sadeghi A.-R., Tsudik G., Zeitouni S., “DARPA: Device attestation résilient to physical attacks”, In Proceedings of the 9th ACM conférence on security and privacy in wireless and mobile networks, 2016, pp. 171-82

[0029] [Ref. 1 l]Kohnhâuser F., Büscher N., Gabmeyer S., Katzenbeisser S., “SCAPI: a scalable attestation protocol to detect software and physical attacks”, In Proceedings lOth ACM conférence on security and privacy in wireless and mobile networks, 2017, pp.75-86

[0030] [Ref. 12]Ammar M., Washha M., Ramabhadran G.S., Crispo B., “SlimloT: Scalable lightweight attestation protocol for the internet of things”, In IEEE conférence on dependable and secure computing, 2018, pp. 1-8, http: / / dx.doi.org / 10.1109 / DE SEC.2018.8625142

[0031] [Ref. 13] Edlira Dushku, Md. Masoom Rabbani, Jo Vliegen, An Braeken, Nele Mentens, “PROVE: Provable remote attestation for public verifiability“, Elseiver, Journal of Information Security and Applications, vol. 75, june 2023, 103448, https: / / www.sciencedirect.com / science / article / pii / S2214212623000327

[0032] [Ref. 14] Abera T., Bahmani R., Brasser F., Ibrahim A., Sadeghi A., Schunter M., “DIAT: Data integrity attestation for résilient collaboration of autonomous System”, In 26th annual network & distributed System security symposium”, 2019

[0033] [Ref. 15] Ibrahim A., Sadeghi A.-R., Tsudik G., “US-AID: Unattended scalable attestation of loT devices”, In IEEE 37th symposium on reliable distributed Systems”, 2018, pp. 21-30

[0034] [Ref. 16] Kuang B., Fu A., Yu S., Yang G., Su M., Zhang Y., “ESDRA: An efficient and secure distributed remote attestation scheme for loT swamis”, IEEE Internet Things Journal, 2019

[0035] [Ref. 17] Kohnhâuser F., Büscher N., Katzenbeisser S., “A practical attestation protocol for autonomous embedded Systems”, In IEEE European symposium on security and privacy, 2019, pp. 263-78

[0036] [Ref. 18] Ambrosin M., Conti M., Ibrahim A., Neven G., Sadeghi A.-R., Schunter M., “SANA: Secure and scalable aggregate network attestation”, In Proceedings ACM SIGSAC conférence on computer and communications security, 2016

[0037] [Ref. 19] Sigurd Frej Joël Jorgensen Ankergard, Dushku, Edlira Dushku, Nicola Dragoni, “PERMANENT: Publicly Vérifiable Remote Attestation for Internet of Things Through Blockchain“, In: Foundations and Practice of Security (FPS 2021), Lecture Notes in Computer Science, vol 13291, Springer, Cham, https: / / doi.org / 10.1007 / 978-3-031-08147-7_15

[0038] [Ref.

[20] Petzi L, Yahya AEB, Dmitrienko A, Tsudik G, Prantl T, Kounev S. SCRAPS: Scalable collective remote attestation for Pub-Sub loT networks with untrusted proxy verification. In: 31st USENIX security symposium. Boston, MA: USENIX Association; 2022, URL https: / / www.usenix.org / conference / usenixsecurity22 / presentation / petzi

[0039] [Ref. 21] Patent EP3506557 Presentation of the invention

[0040] The present invention remedies the aforementioned drawbacks by proposing, according to a first aspect, a decentralized remote attestation method, attesting to authenticity of a peer "attesting" within a peer network sharing a ledger. The attestation process involves a peer "verifying" within the peer network and an "oracle" device. The "oracle" device includes a secure enclave and a random number generator. The attestation process comprises the following steps: 1. generation, by the peer "attesting", of an asymmetric key pair comprising a private key and a public key, 2. Publication, by the peer "attesting", of the public key in the registry, 3. generation, by the "oracle" device, of a unique random number and of an encryption key, 4. generation, by the "oracle" device, of a random number encrypted from the unique random number using the encryption key, 5. Transmission, by the "oracle" device, of the unique random number, via a secure communication channel, to the "verify" peer. 6. Publication, by the "oracle" device, of the encrypted random number in the register, 7. Generation, by peer "verification", of a challenge based on the number unique random number generator using the public key 8. Publication, by peer review, of the challenge in the registry. 9. generation, by the peer "attesting", of a proof containing the random number by solving the challenge using the private key, 10. Publication, by the peer "attesting", of the evidence in the register, 11. After publication of the evidence in the register, publication by the "Oracle" device, of the encryption key in the ledger.

[0041] A peer network is defined as several devices connected remotely via, for example, an internet or GSM network, or a combination of several remote connection technologies. Each device, called a peer, in the peer network comprises at least one processing unit, one memory, and one communication module.

[0042] A ledger is defined as a decentralized ledger, log, or register shared among the peers of the peer network, possibly replicated by each peer in the peer network, in which operations or publications are recorded in a specific order and cannot be modified once recorded. A decentralized ledger can be implemented using a technology such as, for example, a blockchain, a decentralized database, or a Directed Acyclic Graph.

[0043] The random number may be kept secret by the "oracle" and the "verify" pair until step 11.

[0044] Such arrangements allow for attestation of each peer in the peer network, which can be easily verified by each of the other peers in the peer network. This attestation requires neither the involvement of a device manufacturer nor the use of a blockchain block as a random number, also called a secret or Nonce, nor the use of a smart contract as a "verify" proxy.

[0045] In particular embodiments the invention may further comprise one or more of the following features, taken individually or in all technically possible combinations.

[0046] According to one embodiment, the ledger is a blockchain ledger.

[0047] The use of a blockchain ledger makes it easy to decentralize the ledger, i.e. to share and replicate it, which makes it very difficult to falsify.

[0048] According to one embodiment, steps 2 to 6 and 9 to 11 are triggered by peers of the peer network via the sending of a transaction to a smart contract deployed in the blockchain.

[0049] The use of a smart contract to trigger these steps makes it possible to decentralize the orchestration of the attestation process and thus avoids additional communications between the "attest" peer, the "verify" peer and the "oracle" device during the execution of the attestation process.

[0050] According to one embodiment, the peer "attest" includes a security hardware component and step 1 uses the security hardware component.

[0051] The use of a security hardware component for the generation of an asymmetric key pair by the "attest" peer increases the security of the peer network by significantly reducing the risk of peer identity theft or peer corruption.

[0052] According to one embodiment, the security hardware component is a TPM component, in English, Trusted Platform Module, and step 1 involves the generation of an endorsement key and an attestation key.

[0053] The use of a TPM security component, using, for example, the TPM 1.2 or TPM 2.0 protocol, provides a reliable and readily available security component. TPM security components also allow the generation of endorsement keys whose certification can be verified against a Public Key Infrastructure (PKI).

[0054] According to one embodiment, the "oracle" device is a peer in the peer network. An "oracle" device that is a member of the peer network as an independent device makes it easy to secure the "oracle" device.

[0055] According to one embodiment, the peer "verify" includes the "oracle" device in an application embedded in a trusted area.

[0056] An "oracle" device embedded in each peer of the peer network makes it possible to decentralize the function of the "oracle" device and thus avoid a single point of failure.

[0057] According to a second aspect, the present invention proposes a decentralized remote verification method for verifying the authenticity of an "attesting" peer within a peer network sharing a ledger. The verification method involves a "verifying" peer and comprises the following steps: 1. Peer attestation "attest" according to the attestation procedure for the first aspect of the invention, 1. Peer verification ("verify") of the subsequent publication of the encryption key in the registry relative to the publication of the proof in the registry. 2. Calculation of the random number, by peer "checking", from the encrypted random number using the encryption key, 3. Peer verification ("verify") of the presence of the random number in the proof. 4. Generation, by peer "verification", of a control challenge from the random number using the public key, 5. verification, by peer "verify", of the correspondence between the control challenge and the challenge.

[0058] The "verifying" peer involved in the verification process may be the same "verifying" peer as the "verifying" peer in the attestation process or another peer in the peer network. Such arrangements allow the steps of the attestation process to be performed only once by an "attesting" peer. The other peers may only perform the steps of the verification process as "verifying" peers in order to ensure the authenticity and integrity of the "attesting" peer.

[0059] According to a third aspect, the present invention proposes a decentralized remote verification method for verifying the authenticity of an "attest" peer within a peer network sharing a ledger. The "attest" peer includes a TPM security hardware component. The verification method involves a "verify" peer and comprises the following steps: 1. Peer attestation "attest" according to the attestation procedure for the first aspect of the invention, 2. Peer verification ("verification") of an endorsement key certification with a public key infrastructure, 3. Peer verification ("verify") of the subsequent publication of the encryption key in the registry compared to the publication of the proof in the registry. 4. Calculation of the random number, by peer "verification", from the encrypted random number using the encryption key, 5. Peer verification ("verify") of the presence of the random number in the proof. 6. Generation, by peer "verification", of a control challenge from the random number using the public key, 7. verification, by peer "verify", of the correspondence between the control challenge and the challenge.

[0060] The step of verifying the certification of the endorsement key provided by the peer's TPM device "attest" ensures that the TPM component is certified by a TPM component manufacturer. This further enhances the security of the peer network. Presentation of the figures

[0061] The invention will be better understood upon reading the following description, given by way of non-limiting example, and made with reference to the figures:

[0062] [Fig-1] a schematic representation of an example of the attestation process according to the first aspect of the invention,

[0063] [Fig.2] a schematic representation of an example of the verification process according to the third aspect of the invention,

[0064] [Fig.3] a schematic representation of an example of an embodiment of the process of verification according to the third aspect of the invention,

[0065] [Fig.4] a schematic representation of a peer network in which the device "Oracle" is a peer,

[0066] [Fig.5] a schematic representation of a peer network in which each pair includes an "oracle" device.

[0067] In these figures, identical reference numerals from one figure to another designate identical or analogous elements. For clarity, the elements shown are not necessarily to the same scale, unless otherwise stated.

[0068] Detailed description of particular embodiments of the invention

[0069] Figure 1 is a schematic representation of an example of an attestation method according to the first aspect of the invention. An "attest" peer 20, a "verify" peer 30, an "oracle" device 40, and a register 50 are shown. The "attest" peer 20 and the "verify" peer 30 are members of a decentralized peer network. A peer is understood, for example, to be a device comprising a processing unit, electronic memory, and a communication module. The peers are connected within the peer network by one or more telecommunication means. The decentralized peer network could, for example, be an Internet of Things (IoT) network.

[0070] A register 50 is understood to be a register distributed among the peer members of the peer network. The register 50 stores peer publications in the order of publication, the The peer who published the work is also registered. All or part of the registry may eventually be replicated by peers in the peer network.

[0071] The "oracle" device 40 is independent of the other peers in the peer network and is secure. The "oracle" device 40 includes a secure enclave and a unique random number generator. The "oracle" device is connected to the peers in the peer network and to the register. The "oracle" device 40 could, for example, be a device comprising a processing unit, electronic memory, and a communication module.

[0072] The "attest" peer 20 generates a key pair comprising a private key A and a public key A. A key pair is understood to be a pair of asymmetric cryptographic keys comprising a private key and a public key; the private key allows a message to be signed, and only the corresponding public key can verify it. The "verify" peer 30 can, for example, request the "attest" peer 20 to perform an attestation. The "attest" peer publishes the public key A in a ledger 50.

[0073] The "oracle" device 40 generates a nonce, key B, and a random number. The random number, also called a secret, is a unique number that cannot be predicted by a third party. The "oracle" device 40 generates an encrypted random number by encrypting the random number using key B. The "oracle" device 40 transmits the random number securely to the "verifier" peer 30.

[0074] Establishing a secure communication channel between the "oracle" device 40 and the "verify" peer 30 can be achieved, for example, using the TLS "Transport Layer Security" protocol.

[0075] The "oracle" device 40 publishes 6 the encrypted random number in the register 50. Using the public key A, published in the register by the "attest" peer 20, and the random number, transmitted by the "oracle" device 40, the "verify" peer 30 generates 7 a challenge.

[0076] The term "challenge" refers to a cryptographic challenge, also called a "credential," containing the random number in encrypted form.

[0077] The peer "verify" publishes 8 the challenge in the register 50. Then, the peer "attest" can generate 9 a proof from the challenge using the private key A.

[0078] Proof is understood to mean a message demonstrating that the peer "attesting" has solved the challenge. The proof includes the random number in plain text.

[0079] The peer “attest” publishes 10 the proof in the register 50. Once the proof has been published in the register 50, the “oracle” device 40 publishes the encryption key, key B, in the register 50.

[0080] The "oracle" device must only publish the encryption key after the "attest" device has published the proof. Otherwise, a third party could impersonate the to "prove" by producing a proof containing the random number without having solved the challenge, simply by deciphering the already published encrypted random number.

[0081] The "oracle" device 40 may, for example, be notified by the register 50 of the publication of the evidence by the "attest" peer, or be notified directly by the "attest" peer. In another example, the "oracle" device 40 may monitor the register and publish the key when it has observed the publication of the evidence.

[0082] Once the attestation process has been completed, register 50 contains all the publications in the following order: - publication by the peer "attest" 20 of the public key, - publication by the "oracle" device 40 of the random number, - publication by the peer "verify" 30 of the challenge, - publication by peer "attesting" 20 of the evidence, - publication by the "oracle" device 20 of the encryption key.

[0083] Each peer in the peer network can then consult the register 50 and verify the validity of the attestation to ensure the authenticity of the "attesting" peer 20 without the "attesting" peer 20 having to solve new cryptographic challenges. In this way, the security of the peer network can be ensured while requiring fewer computing resources than using a prior art attestation method.

[0084] Figure 2 is a schematic representation of an example of a method of Verification according to the third aspect of the invention. Figure 2 also illustrates the steps of an example of a verification method according to the second aspect of the invention. The verification method according to the second aspect of the invention begins with the attestation 12 of an "attest" peer in the peer network. The attestation 12 is carried out according to the first aspect of the invention. Then, a "verify" peer verifies 14 that the publication of the encryption key in the ledger is subsequent to the publication of the proof. In this way, the "verify" peer ensures that the "attest" peer, at the time of their attestation, was unaware of the random number when solving the challenge. The "verify" peer in the verification method according to the second or third aspect of the invention may be the same peer as the "verify" peer who performed the attestation method according to the first aspect of the invention.The "verify" peer of the verification process according to the second or third aspect of the invention can also be a different peer in the peer network than the "verify" peer of the attestation process. In this way, a peer seeking to ensure the authenticity and / or integrity of another peer in the peer network can perform only the verification process if the peer whose authenticity and / or integrity is being verified has already performed the attestation process with another "verify" peer.

[0085] The "check" pair calculates 15 the random number by deciphering the encrypted random number present in register 50 using the encryption key also present in the register.

[0086] After calculating the random number, the "verify" peer 30 checks 16 that the random number is present in the proof published in the register by the "attest" peer 20. Using the public key and the random number present in the register, the "verify" peer 30 generates 17 a control challenge. The "verify" peer 30 then checks 18 that the control challenge corresponds to the challenge published by the "attest" peer 20 in the register during the attestation process. In this way, the "verify" peer 30 ensures that the attest peer has indeed solved the challenge, which could only be solved by possessing the private key.

[0087] In one embodiment, each peer in the peer network includes a security hardware component. When a peer in the peer network needs to attest to its authenticity and / or integrity, the peer assumes the role of the "attest" peer. It can perform step 1 of generating an asymmetric key pair using its security hardware component, thereby protecting the generation of the asymmetric key pair from intrusion or observation by a third party. The private key can also be stored within the security hardware component with a reduced risk of security breach.

[0088] In one embodiment, the security hardware component is a Trusted Platform Module (TPM), for example, a TPM 2.0 component. In step 1, the TPM security component may generate two asymmetric key pairs: an endorsement key pair, commonly denoted EK and EKpub, and an attestation key pair, AK and AKpub. In this case, the verification process may include a step 13 of verifying the endorsement public key certificate EKpub against a public key infrastructure. Such a public key infrastructure is generally made available by a security component manufacturer. This step will ensure that the peer attester 20 contains a security component that was indeed provided by a trusted manufacturer.

[0089] Fig. 3 is a schematic representation of an example of an embodiment of a verification process according to the third aspect of the invention.

[0090] The "attest" peer 20, the "verify" peer 30, the "oracle" device 40, and the register 50 are shown. The TPM security component of the "attest" peer 20 is also shown. In this schematic representation, the random number is named Nonce, the encryption key cipherKey, the challenge credential, and the proof decipheredCredential. The publication steps are indicated by the term Register. In this embodiment, the verification process includes a An additional step of peer publication 30 of the random number in the register 50 is "verifying" the random number. This step is indicated by "Register Nonce of Peer j". Thanks to this additional step, another peer subsequently seeking to verify the authenticity / integrity of the attesting peer can perform the verification process according to the invention without calculating the random number 15, as the deciphered random number is already available in the register.

[0091] According to one embodiment, register 50 is a blockchain register, also called a "ledger". The blockchain allows the register to be decentralized while maintaining a good level of security and reliability.

[0092] According to one embodiment, the triggering of the following steps of the attestation process can be carried out by one of the peers of the peer network via the sending of a transaction to a smart contract on the blockchain: 1. Publication, by the peer "attesting" (30), of the public key in the register (50), 2. generation, by the "oracle" device (40), of a unique random number and an encryption key, 3. generation, by the "oracle" device (40), of a random number encrypted from the unique random number using the encryption key, 4. transmission, by the "oracle" device (40), of the unique random number, via a secure communication channel, to the "verify" peer (30), 5. publication, by the "oracle" device (40), of the random number encrypted in the register (50), 1. Publication, by the peer "verify" (30), of the challenge in the register (50), 2. Generation, by the peer "attest" (20), of a proof containing the random number by solving the challenge using the private key, 3. publication, by the peer "attesting" (20), of the evidence in the register (50), 4. after publication of the evidence in the register (50), publication, by the "oracle" device (40), of the encryption key in the register (50).

[0093] Using a smart contract to trigger these steps, to optionally provide execution instructions, and to optionally trigger other steps in the attestation process as well as steps in the verification process, avoids additional exchanges between the peers participating in the attestation and between the participating peers and the "oracle" device. The smart contract could, for example, take the following form:

[0094] / / SPDX-License-Identifier: UNLICENSED

[0095] pragma solidity A0.6.6;

[0096] contract dd23890 {

[0097] address creator;

[0098]

[0099]

[0100]

[0101]

[0102]

[0103]

[0104] H certificate key EK struct ekParam { uint256 qname; uint256 name; uint crypto; / / ECC or RSA bytes32[2] pub; / / public key EK(X, Y) each coordinate is 32 bytes bytes32[] pem; / / TPM endorsement key certificate signed by PKI (ECC or RSA)

[0105]

[0106]

[0107]

[0108]

[0109]

[0110] [YES]

[0112]

[0113]

[0114]

[0115]

[0116]

[0117]

[0118]

[0119]

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126]

[0127] } / / parameterized AK struct akParam { uint256 qname; uint256 name; / / ak_qname = ek_qname 1 ak_name uint crypto; / / ECC or RSA bytes32[2] pub; / / public key AK(X, Y) each coordinate is 32 bytes} / / Structure of 1 attestation for 1 index cipheredNonce struct cipheredNonce { address targetedAttester; / / peer attester to prove address issuingOracle; / / address of the Oracle account that produced ciphered Nonce bytes32[] credential; / / publication by the verifier bytes32[] decipheredCredential; / / publication by 1 ATTESTER uint256 cipherKey; / / publication by ORACLE} / / role of participants struct role { bool Oracle; bool Verify; bool Attest;} / / mapping of variables mapping (address => role) public player; / / role that an account address can adopt

[0128]

[0129]

[0130] mapping (address => ekParam) public ek; / / EK of the pair mapping (address => akParam) public ak; / / AK of the pair mapping (uint256 => cipheredNonce) public attestation; / / elements of 1 attestation for 1 index cipheredNonce published by 1 ORACLE

[0131]

[0132] mapping (uint256 => address) public usedNonce; / / nonce already used / / event that allows retrieving an attestation in the chain;

[0133]

[0134]

[0135] event hereIsCipheredNonce(uint256 _cipheredNonce); event hereIsCredential(uint256 _cipheredNonce, address _targetedAttester); event hereIsDecipheredCredential(uint256 _cipheredNonce, address _targetedOracle) ;

[0136]

[0137]

[0138]

[0139]

[0140]

[0141]

[0142]

[0143] / ** * Constructor function ** / constructor () public { creator = msg.sender;} / / CREATOR enregistre le rôle des participants function registerRole(address _player, bool _oracle, bool _verifier, bool _attester) public returns (bool){

[0144]

[0145]

[0146]

[0147]

[0148]

[0149]

[0150]

[0151] require(msg.sender == creator, "only creator is allowed to register rôles"); player[_player].Oracle = _oracle; player[[_player].Vérifier = _verifier; player[[_player]. Attester = _attester; return true;} / / ATTESTER publie sa cle EK function registerEK(uint256 _qname, uint256 jiame, uint _crypto, bytes32[2] memory _pub, bytes32[] memory _pem) public returns (bool){

[0152] require(player[msg.sender] .Attester == true, "msg.sender must be an Attester de vice");

[0153]

[0154]

[0155]

[0156]

[0157]

[0158]

[0159]

[0160]

[0161] ek[msg.sender].qname = _qname; ek[msg.sender].name = jiame; ek[msg.sender].crypto = _crypto; ek[msg.sender].pub = _pub; ek[msg.sender].pem = _pem; return true;} / / ATTESTER publie sa cle AK function registerAK(uint256 _qname, uint256 jiame, uint _crypto, bytes32[2] memory _pub) public returns (bool){

[0162] require(player[msg.sender].Attester == true, "msg.sender must be an Attester de vice");

[0163]

[0164] ak[msg.sender].qname = _qname; ak[msg.sender].name = jiame; .

[0165] ak[msg.sender].crypto = _crypto;

[0166] ak[msg.sender].pub = _pub;

[0167] return true ;

[0168] }

[0169] / / ORACLE publie cipheredNonce pour 1 Attester

[0170] function registerCipheredNonce(uint256 _cipheredNonce, address _targetedAttester) public returns (bool){

[0171] require(player(msg.sender). Oracle == true, "msg.sender must be an ORACLE");

[0172] require(player(_targetedAttester). Attester == true, "_targetedAttester must be an ATTESTER");

[0173] require(msg.sender != _targetedAttester, "msg.sender and _targetedAttester must be indépendant");

[0174] require(attestation[_cipheredNonce].targetedAttester == address(OxO), "cipheredNonce is already used");

[0175] attestation[_cipheredNonce].targetedAttester == _targetedAttester;

[0176] attestation[_cipheredNonce].issuingOracle == msg.sender

[0177] émit hereIsCipheredNonce(_cipheredNonce);

[0178] return true;

[0179] }

[0180] / / VERIFIER publie Credential pour 1 Attester

[0181] function registerCredential(uint256 _cipheredNonce, bytes32[] memory _credential) public returns (bool){

[0182] require(player(msg.sender).Verifier == true, "msg.sender must be a VERIFIER");

[0183] require(attestation[_cipheredNonce].targetedAttester != address(OxO), "a valid targetAttester must be already registered");

[0184] require(msg.sender != attestation[_cipheredNonce].targetedAttester, "msg.sender and targetedAttester must be indépendant");

[0185] require(attestation[_cipheredNonce]. credential [0] == bytes32(0), "no credential must already be registered");

[0186] attestation[_cipheredNonce] .credential = _credential;

[0187] émit hereIsCredential(_cipheredNonce, attestation[_cipheredNonce].target edAttester);

[0188] return true;

[0189] }

[0190] / / ATTESTER publie decipheredCredential

[0191] function registerDecipheredCredential(uint256 _cipheredNonce, bytes32[] memory _decipheredCredential, uint256 _nonce) public returns (bool){

[0192] require(msg.sender == attestation[_cipheredNonce].targetedAttester, "msg.sender must be targetedAttester");

[0193] require(attestation[_cipheredNonce].credential[0] != bytes32(0), "acredential should be registered");

[0194] require(attestation[_cipheredNonce]. decipheredCredential[O] == bytes32(0), "no decipheredCredential must be registered");

[0195] require(usedNonce[_nonce] == address(OxO), "the nonce must not be already used");

[0196] attestation[_cipheredNonce] .decipheredCredential = _decipheredCredential;

[0197] usedNonce[_nonce] = msg.sender;

[0198] émit hereIsDecipheredCredential(_cipheredNonce, attestation[_ciph eredNonce].issuingOracle);

[0199] return true;

[0200] }

[0201] / / ORACLE publie cipherKey utilise pour cipheredNonce

[0202] function registerCipherKey(uint256 _cipheredNonce, uint256 _cipherKey) public returns (bool){

[0203] require(msg.sender == attestation[_cipheredNonce].issuingOracle, "cipherKey must be disclosed by ORACLE which issues cipheredNonce");

[0204] require(attestation[_cipheredNonce].decipheredCredential[0] != bytes32(0), "a decipheredCredential must be registered");

[0205] require(attestation[_cipheredNonce].cipherKey == 0, "no cipherKey must be registred");

[0206] attestation[_cipheredNonce] .cipherKey = _cipherKey;

[0207] return true;

[0208] }

[0209] }

[0210] Each peer and each oracle device accesses the smart contract through its account address in the blockchain. An entity, named "CREATOR" in the smart contract, configures the account address of each peer / oracle device and specifies the role that each account address can assume.

[0211] Figure 4 is a schematic representation of a peer network in which the "oracle" device 40 is a peer. Each peer in the peer network, indicated as "peer" in the figure, can assume the role of "verify" peer 30 or "attest" peer 20 when performing an attestation or verification process according to the invention. In order to maintain an attestation with two parties, an "attest" peer 20 cannot be the "verify" peer 30 when attesting or verifying. The "oracle" device 40 must be able to establish a secure communication channel with each A peer in the peer network is required to confidentially transmit the random number to the "verify" peer 30 during the attestation process. This secure communication channel could, for example, be implemented using a smart contract key exchange method deployed on a blockchain [Ref. 21]. Multiple "oracle" devices can operate within the peer network, with a mechanism for selecting the "oracle" device responsible for each attestation. This enhances the robustness of the peer network, as the failure of one "oracle" device will no longer prevent the network's peers from performing attestations.

[0212] Figure 5 is a schematic representation of a peer network in which each peer includes an "oracle" device. In this embodiment, the "oracle" device is embedded in a trusted execution area within each peer of the peer network. The "oracle" device will nevertheless have a distinct identity with the registry from that of the peer embedding it. A "verifying" peer will request its embedded "oracle" device during the execution of an attestation process according to the invention. A dynamic monitoring process can be implemented to guarantee the authenticity of the embedded "oracle" device during each publication.

Claims

Demands

1. A decentralized remote attestation method for attesting the authenticity of an "attest" peer (20) within a peer network sharing a ledger (50), involving a "verify" peer (30) within the peer network and involving an "oracle" device (40), the "oracle" device (40) comprising a secure enclave and a random number generator, the attestation method comprises the following steps:

1. generation, by the "attest" peer (20), of an asymmetric key pair comprising a private key and a public key, 2. publication, by the "attest" peer (30), of the public key in the ledger (50), 3. generation, by the "oracle" device (40), of a unique random number and an encryption key, 4. generation, by the "oracle" device (40), of a random number encrypted from the unique random number using the encryption key, 5.transmission, by the "oracle" device (40), of the unique random number, via a secure communication channel, to the "verify" peer (30), 1. publication, by the "oracle" device (40), of the encrypted random number in the register (50), 7. generation, by the "verify" peer (30), of a challenge from the unique random number using the public key, 8. publication, by the "verify" peer (30), of the challenge in the register (50), 9. generation, by the "attest" peer (20), of a proof containing the random number by solving the challenge using the private key, 10. publication, by the "attest" peer (20), of the proof in the register (50), 11. after the publication of the proof in the register (50), publication, by the "oracle" device (40), of the encryption key in the register (50).

2. A method of attestation according to claim 1 wherein the ledger (50) is a blockchain ledger.

3. A method according to claim 2 wherein steps 2 to 6 and 9 to 11 are triggered by one of the peers in the peer network via sending of a transaction towards a smart contract deployed in the blockchain.

4. A method of attestation according to any one of the preceding claims wherein the "attest" pair (20) comprises a security hardware component and wherein the generation of the asymmetric key pair of step 1 is carried out using the security hardware component.

5. A method according to claim 4 wherein the security hardware component is a TPM component and wherein step 1 comprises generating an endorsement key and an attestation key using the TPM component.

6. A method of attestation according to any one of the preceding claims wherein the "oracle" device (40) is a peer of the peer network.

7. A method of attestation according to claims 1 to 5 in which the peer "verify" (30) includes the "oracle" device (40) in an application embedded in a trusted area.

8. A decentralized remote verification method, verifying the authenticity of an "attest" peer (20) within a peer network sharing a ledger, involving a "verify" peer and comprising the following steps:

12. attestation of the "attest" peer (20) according to the attestation method of any one of the preceding claims, 14. verification, by the "verify" peer (30), of the posterity of the publication of the encryption key in the ledger (50) with respect to the publication of the proof in the ledger (50), 15. calculation of the random number, by the "verify" peer (30), from the random number encrypted using the encryption key, 16. verification, by the "verify" peer (30), of the presence of the random number in the proof, 17. generation, by the "verify" peer (30), of a control challenge from the random number using the public key, 18.verification, by peer "verify" (30), of the correspondence between the control challenge and the challenge.

9. A decentralized remote verification method, verifying the authenticity of an "attest" peer (20) within a peer network sharing a ledger, the "attest" peer (20) includes a TPM security hardware component, the verification method involves a "verify" peer (30) and includes the following steps:

12. Peer attestation “attest” (20) according to the attestation method of claim 5, 13. Verification, by peer "verify" (30), of a certification of the endorsement key with a public key infrastructure, 14. Verification, by peer "verify" (40), of the posterity of the publication of the encryption key in the registry with respect to the publication of the proof in the registry, 15. Calculation of the random number, by the peer "check" (30), from the encrypted random number using the encryption key, 16. Verification, by peer review (30), of the presence of the random number in the proof, 17. Generation, by peer "verification" (30), of a control challenge from the random number using the public key, 18. verification, by peer “verify” (30), of the correspondence between the control challenge and the challenge.

Images