Decentralized remote attestation process

Abstract

A decentralized remote attestation method for attesting the authenticity of an Attester peer (20) within a network of peers sharing a ledger (50) involves a Verifier peer (30) and an Oracle device (40) having a secure enclave and a random number generator. The Attester (30) publishes a public key to 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 to the ledger (50). The Verifier (30) generates a challenge using the random number and the public key and publishes the challenge to the ledger. The Attester (20) solves the challenge using the private key and publishes a proof to the ledger (50). After publishing the proof to the ledger (50), the Oracle (40) publishes the encryption key. Figure for the abstract: [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, called peers in the present text, connected in a decentralized network. The invention also relates to a method for verifying the authenticity of a peer. Prior art

[0002] Remote Attestation is a security service in which one device, called a "verifier," verifies the integrity and authenticity of another device, called a remote "attester." The goal 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 involves the use of computing and memory resources on the part of the attesting and verifying devices.

[0005] A peer-to-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 a client and a 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-to-peer network, peers are autonomous and make individual decisions about 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 point of control or failure makes the network robust against outages 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 handle aspects such as routing, resource discovery, and data replication.

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

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

[0011] However, remote attestation as generally practiced requires that, for a peer i to be able to establish that peer j is trusted, peers i and j perform a remote attestation with peer i in the role of verifying and peer j in the role of attesting. A network comprising many peers will therefore require significant computing resources dedicated to security so that the peers can attest to each other two by two.

[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 attesting devices than verifying each device individually. Generally, swarm attestations are used in large peer networks to gain efficiency. Many works based on the use of a centralized verifying 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 the attestations of several attesters and aggregate them according to a tree structure to route them more efficiently to the verifying device. Techniques such as DARPA [Ref. 10], SCAPI [Ref. 11], slimloT [Ref. 12] or PROVE [Ref.13] further introduce a mechanism to ensure the legitimacy of the "attest" devices and to monitor their presence in the swarm. Other works, including DIAT [Ref. 14], US-AID [Ref. 15], ESDRA [Ref. 16] or PASTA [Ref. 17], consider that the "verify" devices are peers in the network, capable of autonomously attesting their neighbors. However, the result of the attestation is not publicly verifiable, leading each peer acting as "verifier" to carry out the protocol in its entirety.

[0014] The SANA swarm attestation protocol [Ref. 18] relies on a multi-signature scheme to aggregate attestation results across a large group of devices. In SANA, each device is provided with an asymmetric key pair. Each attester uses its secret key to sign its attestation. The attestations are then aggregated and can be verified by any verifying peer that knows the attester devices' public key. However, SANA does not provide details on the generation of the challenge (credential) that the attester device (called a prover in SANA) signs to attest its legitimacy. The generation of this challenge, which includes a secret Nonce, is crucial to avoid attacks by replay. Furthermore, the aggregation of attestations within the network makes the network not very dynamic and not very scalable. In addition, it is not indicated 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 “attester” and “verifier” interchangeably. But 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 is started. This makes this solution difficult to maintain and does not allow scaling (impossible to add new peers or remove peers).

[0016] The PROVE protocol aims to provide a solution enabling the public verifiability of attestations within a network of distributed devices, using a publication / subscription mechanism, without relying on the use of a public key infrastructure "PKI", and without sending an attestation request to the "attester" peer. PROVE is based on the use of a "broker" agent which transmits to the subscribed "verify" devices the attestations published by the "attester" devices.

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

[0018] The SCRAPS protocol [Ref. 20] operates asynchronously within a network of devices using a blockchain. The verification of the attestation is delegated to a smart contract that acts as a proxy peer verifier. 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 security component manufacturer must deploy its smart contract in the network blockchain. It must record the public key of each security component used by the peers in the blockchain.Finally, it must deploy the attestation scheme supported by the components at the agent level. The implementation of this solution becomes extremely cumbersome, as the manufacturer of the security components 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 overcomes the aforementioned drawbacks by proposing, according to a first aspect, a decentralized remote attestation method, attesting to the authenticity of an "attesting" peer within a network of peers sharing a ledger. The attestation process involves a "verifying" peer within the peer network and an "oracle" device. The "oracle" device includes a secure enclave and a random number generator. The attestation process involves the following steps: 1. generation, by the “attesting” peer, of a pair of asymmetric keys comprising a private key and a public key, 2. publication, by the “attesting” peer, 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 an encrypted random number 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 the “verify” peer, of a challenge from the number unique random using public key, 8. publication, by the “verified” peer, of the challenge in the registry, 9. generation, by the “attesting” peer, of a proof containing the random number by solving the challenge using the private key, 10. publication, by the peer “attester”, of the proof in the register, 11. after publication of the evidence in the register, publication, by the “oracle” device, the encryption key in the registry.

[0041] A peer network is understood to mean several devices connected remotely by, 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, a memory and a communication module.

[0042] A register is understood to mean a decentralized register or log or ledger, shared between the peers of the peer network, possibly replicated by each peer of the peer network and in which operations or publications are recorded in a certain order and can no longer be modified once recorded. A decentralized register can be created using a technology such as, for example, a blockchain or a decentralized database or a “Directed Acyclic Graph”.

[0043] The random number can be kept secret by the “oracle” and the peer “verify” until step 11.

[0044] Such arrangements allow for attestation by each peer in the peer network that 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 characteristics, taken in isolation or in all technically possible combinations.

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

[0047] The use of a blockchain register, also called a ledger, makes it easy to make the register decentralized, i.e. shared and replicated, 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 sending 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 when carrying out the attestation process.

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

[0051] The use of a hardware security component for the generation of an asymmetric key pair by the "attesting" peer makes it possible to increase the security of the peer network by considerably reducing the risk of usurpation of the identity of a peer or the corruption of a peer.

[0052] According to one embodiment, the hardware security component is a TPM component, in English, Trusted Platform Module, and step 1 comprises 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, makes it possible to have a reliable and easily available security component. TPM security components also make it possible to produce endorsement keys whose certification can be verified with a public key infrastructure, in English, PKI, or Public Key Infrastructure.

[0054] According to one embodiment, the “oracle” device is a peer of 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 “verify” peer comprises the “oracle” device in an application embedded in a trusted zone.

[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 provides a decentralized remote verification method, verifying the authenticity of an "attest" peer within a network of peers sharing a ledger. The verification method involves a "verify" peer and comprises the following steps: 1. attestation of the peer “attest” according to the attestation method of the first aspect of the invention, 1. verification, by the peer “verifier”, of the posterity of the publication of the encryption key in the registry compared to the publication of the proof in the registry, 2. calculation of the random number, by the “verifying” peer, from the encrypted random number using the encryption key, 3. verification, by the peer “verifier”, of the presence of the random number in the proof, 4. generation, by the “verifying” peer, of a control challenge from the random number using the public key, 5. verification, by the “verify” peer, of the correspondence between the control challenge and the challenge.

[0058] The “verify” peer involved in the verification process may be the same “verify” peer as the “verify” peer of the attestation process or another peer in the peer network. Such arrangements make it possible to carry out the steps of the attestation process only once for an “attest” peer. The other peers may only carry out the steps of the verification process as a “verify” peer in order to ensure the authenticity and integrity of the “attest” peer.

[0059] According to a third aspect, the present invention provides a decentralized remote verification method, verifying the authenticity of an "attest" peer within a network of peers sharing a register. The "attest" peer comprises a TPM security hardware component. The verification method involves a "verify" peer and comprises the following steps: 1. attestation of the peer “attest” according to the attestation method of the first aspect of the invention, 2. verification, by the peer “verifier”, of a certification of the endorsement key with a public key infrastructure, 3. verification, by the peer “verifier”, of the posterity of the 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 the “verifying” peer, from the encrypted random number using the encryption key, 5. verification, by the peer “verifier”, of the presence of the random number in the proof, 6. generation, by the “verifying” peer, of a control challenge from the random number using the public key, 7. verification, by the “verify” peer, of the correspondence between the control challenge and the challenge.

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

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

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

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

[0064] [Fig.3] a schematic representation of an exemplary embodiment of the method 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 peer includes an “oracle” device.

[0067] In these figures, identical references from one figure to another designate identical or similar elements. For reasons of clarity, the elements represented are not necessarily on the same scale, unless otherwise stated.

[0068] Detailed description of particular embodiments of the invention

[0069] [Fig.l] 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 represented. The “attest” peer 20 and the “verify” peer 30 are members of a decentralized peer network. By peer, for example, is meant a device comprising a processing unit, an 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” loT network.

[0070] Registry 50 means a distributed registry among the peers who are members of the peer network. Registry 50 stores publications from peers in the order of publication, the peer issuing the publication is also registered. All or part of the register may eventually be replicated by peers in the peer network.

[0071] The “oracle” device 40 is a device independent of the other peers of the peer network and secure. The “oracle” device 40 comprises a secure enclave and a unique random number generator. The “oracle” device is connected to the peers of the peer network and to the registry. The “oracle” device 40 may be, for example, a device comprising a processing unit, an electronic memory and a communication module.

[0072] The “attest” peer 20 generates 1 a pair of keys comprising a private key A and a public key A. A pair of keys is understood to mean a pair of asymmetric cryptographic keys comprising a private key and a public key, the private key allowing a message to be signed that only the corresponding public key can verify. The “verify” peer 30 may, for example, ask the “attest” peer 20 to carry out an attestation. The “attest” peer publishes 2 in a register 50 the public key A.

[0073] The “oracle” device 40 generates 3 an encryption key, key B, and a random number. The random number, also called Nonce or secret, is a unique number that cannot be predicted by a third party. The “oracle” device 40 generates 4 an encrypted random number by encrypting the random number using key B. The “oracle” device 40 transmits 5 the random number to the “verify” peer 30 in a secure manner.

[0074] The establishment of a secure communication channel between the “oracle” device 40 and the “verify” peer 30 may be carried out, 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] A challenge is understood to mean a cryptographic challenge also called a “credential” containing the random number in encrypted form.

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

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

[0079] The “attesting” peer publishes the proof in the register 50. Once the proof is 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 usurp the identity of the peer “attest” by producing a proof containing the random number without having solved the challenge, simply by decrypting the already published encrypted random number.

[0081] The “oracle” device 40 may, for example, be notified by the registry 50 of the publication of the proof by the “attesting” peer, or be notified directly by the “attesting” peer. In another example, the “oracle” device 40 may monitor the registry and publish the key when it has observed the publication of the proof.

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

[0083] Each peer in the peer network will then be able to 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 by requiring fewer computing resources than by using a prior art attestation method.

[0084] [Fig.2] is a schematic representation of an example of a method of verification according to the third aspect of the invention. [Fig. 2] also represents 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 of the peer network. The attestation 12 takes place according to the first aspect of the invention. Then, a “verify” peer verifies 14 that the publication of the encryption key in the registry is subsequent to the publication of the proof. In this way, the “verify” peer ensures that the “attest” peer, when attesting, was not aware of the random number when solving the challenge. The “verify” peer of the verification method according to the second or third aspect of the invention may be the same peer as the “verify” peer having carried out the attestation method according to the first aspect of the invention.The "verify" peer of the verification method according to the second or third aspect of the invention may also be another peer of the peer network than the "verify" peer of the attestation method. In this way, a peer seeking to ensure the authenticity and / or integrity of another peer of the peer network may only carry out the verification method if the peer whose authenticity and / or integrity is sought to be ensured has already carried out the attestation method with another "verify" peer.

[0085] The "verify" peer calculates 15 the random number by decrypting the encrypted random number present in the register 50 using the encryption key also present in the register.

[0086] After calculating the random number, the “verify” peer 30 verifies 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 verifies 18 that the control challenge corresponds to the challenge published by the “attest” peer 20 in the register when carrying out the attestation process. In this way, the “verify” peer 30 ensures that the attest peer has indeed solved the challenge that only possession of the private key made it possible to solve.

[0087] According to one embodiment, each peer of the peer network comprises a hardware security component. When a peer of the peer network must attest its authenticity and / or its integrity, the peer takes the role of “attesting” peer. It will be able to carry out step 1 of generating an asymmetric key pair using its hardware security component, which makes it possible to protect the generation of the asymmetric key pair from intrusion or observation by a third party. The private key may also be stored within the hardware security component with a reduced risk of security violation.

[0088] According to one embodiment, the hardware security component is a TPM “Trusted Platform Module” component, for example, a TPM 2.0 component. The TPM security component may generate during step 1 two pairs of asymmetric keys: an endorsement key pair commonly noted EK and EKpub as well as an attestation key pair AK and AKpub. In this case, the verification method may include a verification step 13 of the certificate of the public endorsement key EKpub with a public key infrastructure. Such a public key infrastructure is generally made accessible by a security component manufacturer. This step will ensure that the attesting peer 20 includes a security component that has indeed been provided by a trusted manufacturer.

[0089] [Fig.3] is a schematic representation of an exemplary embodiment of a verification method 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 represented. The TPM security component of the “attest” peer 20 is also represented. In this schematic representation the random number is called Nonce, the encryption key, cipherKey, the challenge, Credential and the proof, decipheredCredential. The publication steps are indicated by the term Register. In this exemplary embodiment, the verification method comprises a additional step of publication by the peer “verifying” 30 of the random number in the register 50. This step is indicated by “Register Nonce of Peer j”. Thanks to this additional step, another peer subsequently seeking to ensure the authenticity / integrity of the peer attester will be able to carry out the verification method according to the invention without calculating 15 the random number, the decrypted random number already being available in the register.

[0091] According to one embodiment, the register 50 is a blockchain register, also called a “ledger”. The blockchain makes it possible to decentralize the register while maintaining a good level of security and reliability.

[0092] According to one embodiment, the triggering of the following steps of the attestation method may be carried out by one of the peers of the peer network via the sending of a transaction to a smart contract of the blockchain: 1. publication, by the “attest” peer (30), of the public key in the registry (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 an encrypted random number 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 “verify” peer (30), of the challenge in the register (50), 2. generation, by the “attest” peer (20), of a proof containing the random number by solving the challenge using the private key, 3. publication, by the peer “attest” (20), of the proof 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 registry (50).

[0093] The use of a smart contract to trigger these steps, to possibly provide the implementation instructions and to possibly trigger other steps of the attestation process as well as steps of the verification process, makes it possible to avoid additional exchanges between the peers participating in the attestation and between the participating peers and the “oracle” device. The smart contract could take, for example, 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 peer mapping (address => akParam) public ak; / / AK of the peer 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 in use / / event that allows to retrieve 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 informs the role that each account address can adopt.

[0211] [Fig.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, may adopt the role of “verify” peer 30 or “attest” peer 20 when carrying out an attestation or verification method according to the invention. In order to maintain an attestation with two parties, an “attest” peer 20 cannot be the “verify” peer 30 during its attestation or during its verification. The “oracle” device 40 must be able to set up a secure communication channel with each peer of the peer network in order to be able to transmit the random number confidentially to the "verifying" peer 30 during the attestation process. This secure communication channel could, for example, be carried out using a key exchange method by smart contract deployed on a blockchain [Ref. 21]. Several "oracle" devices could intervene within the peer network with a mechanism for selecting the "oracle" device responsible for each attestation. In this way, the robustness of the peer network could be increased because the failure of an "oracle" device would no longer prevent the peers of the network from carrying out attestations.

[0212] [Fig.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 zone in each peer of the peer network. The “oracle” device will still have a separate identity with the registry from that of the peer embedding it. A “verifying” peer will request its embedded “oracle” device when carrying out an attestation method according to the invention. A dynamic monitoring method may be implemented to guarantee the authenticity of the embedded “oracle” device during each publication.

Claims

Claims

1. A decentralized remote attestation method, attesting the authenticity of an "attest" peer (20) within a network of peers sharing a ledger (50), involving a "verify" peer (30) within the network of peers and involving an "oracle" device (40), the "oracle" device (40) comprises 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), ô.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, lO.publication, by the “attest” peer (20), of the proof in the register (50), 11.after publication of the proof in the register (50), publication, by the “oracle” device (40), of the encryption key in the register (50).

2. The attestation method of claim 1 wherein the register (50) is a blockchain register.

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

4. Attestation method according to one of the preceding claims in which the “attester” peer (20) comprises a hardware security component and in which the generation of the asymmetric key pair of step 1 is carried out using the hardware security component.

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

6. Attestation method according to one of the preceding claims in which the “oracle” device (40) is a peer of the peer network.

7. Attestation method according to claims 1 to 5 in which the “verify” peer (30) comprises the “oracle” device (40) in an application embedded in a trusted zone.

8. A decentralized remote verification method, verifying the authenticity of an "attest" peer (20) within a network of peers 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 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 encrypted random number 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 the peer “verify” (30), of the correspondence between the control challenge and the challenge.

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

12. attestation of the “attest” peer (20) according to the attestation method of claim 5, 13. verification, by the peer “verify” (30), of a certification of the endorsement key with a public key infrastructure, 14. verification, by the peer “verify” (40), of the posterity of the publication of the encryption key in the registry compared to the publication of the proof in the registry, 15. calculation of the random number, by the “verify” peer (30), from the encrypted random number using the encryption key, 16. verification, by the peer “verify” (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 the peer “verify” (30), of the correspondence between the control challenge and the challenge.

Images