Method and system for controlling interconnected devices operating in an untrusted environment

Abstract

The invention relates to a method and a corresponding system for controlling operations performed by a plurality of devices owned by different entities and operating in an untrusted, possibly malicious environment for performing assigned tasks, in which the devices are equipped with processing means and communication means, and operable to securely exchange data with each other via a wired or wireless communication network, thereby preventing intrusion in execution processing of operations required to perform a task and theft or unauthorized use or removal of critical data.

Description

Technical Field

[0001] This invention relates to the field of controlling the operation of multiple devices operating in an untrusted environment and equipped with communication units operable to securely exchange data with each other via wired or wireless communication links. Background Technology

[0002] Not only are devices interconnected and collaborating via wired or wireless networks to perform various tasks—such as industrial robots that perform operations within factories for industrial manufacturing processes or store and move goods within warehouses for transportation or delivery processes—but mobile devices (such as mobile phones, laptops, or tablets) or Internet of Things (IoT) devices are now ubiquitous. Another example involves groups of drones belonging to different owners operating in untrusted (potentially malicious) environments and needing to exchange data to perform certain tasks. All these devices must exchange data with each other and possibly with servers. These devices are typically equipped with processing and communication units to exchange and process received data via communication networks. For example, interconnected robots are often supervised by servers (with processing and communication components, as well as storage components such as databases) to receive instructions for performing tasks and for controlling the execution of those tasks.

[0003] In the context of such interconnected devices, numerous hardware and software solutions have been developed to provide secure data transmission across different networks. By using data encryption, the security against intrusion by (untrusted) parties during data exchange over a network has been improved. For example, "Rich Operating System Execution Environments" (REEs) have been developed (e.g., Android). TM However, this is not always sufficient to prevent (physical) intrusion and maintain data integrity. Therefore, physical protections for processing units or at least parts thereof have been developed to increase security. For example, the industry has developed standards for “Trusted Execution Environments” (TEEs) that use both hardware and software to protect data (e.g., ARM Holdings’ ARMTrustZone technology, see also references [1] and [2]). A Trusted Execution Environment (TEE) is a secure zone for the processor: as an isolated execution environment, it guarantees that internally loaded code and data are protected in terms of the integrity and confidentiality of sensitive data.

[0004] The TEE uses a secure hardware enclave. A secure enclave is a protected area within the processing unit's internal memory that acts as a buffer for the TEE used to process sensitive data. The secure enclave appears as an opaque box to the rest of the unit and other processing running on it: no data or code inside the enclave can be seen from the outside. For example, when parsing a query from an application driven by a client driver, the processing unit determines whether the query contains any operations on encrypted data that require the use of the secure enclave. For queries that require access to the secure enclave: (i) the client driver sends the column encryption key (on a secure channel) required for the operation to the secure enclave, and (ii) the client driver then submits the query to be executed along with encrypted query parameters. During query processing, data or column encryption keys are not exposed in plaintext outside the secure enclave (the processing unit delegates cryptographic operations and computations on encrypted columns to the secure enclave). The secure enclave (within the processing unit) can access sensitive data stored in encrypted database columns and the corresponding column encryption keys in plaintext. Before submitting a query involving enclave computing to the processing unit, the client driver within the application must verify, based on a given technology (e.g., VBS "security based on virtualization"), that the secure enclave is a genuine enclave and that the code running inside the enclave has been signed for use within the enclave.

[0005] In addition, specific communication / verification protocols have been developed to improve the security of data transmission over communication networks (see [3]). For example, there are verification protocols such as "zero-knowledge proofs" (ZKP) (see [4]) for offline verification of digital artifacts' digital signatures (proof of signatures) (see, for example, [5], [6]).

[0006] There are also ZKP protocols for signing digital artifacts, for example via “blind” (see [6], [7]), efficient (see [8], [9],

[10] ) or delegated (see

[11] ) signatures, using a new key whose key value is unknown (i.e., without having to learn how to respond affirmatively to a signature proof).

[0007] Critical data and / or the encryption keys for that data can also be protected by using a hardware security module (HSM), which is a dedicated, highly trusted physical device suitable for performing all major cryptographic operations, including encryption, decryption, authentication, key management, key exchange, etc. HSMs typically have a robust operating system (OS) and restricted, tightly controlled network access protected by a firewall, and they are also tamper-proof and tamper-resistant devices (see, for example,

[12] ).

[0008] However, there remains a need to improve the security and robustness of controls over the execution of operations by interconnected devices relative to potential intrusions that alter the execution of operations and / or data integrity, particularly when the devices are not owned (or under the complete control of) the same entity or person, and especially when the devices are operating in hazardous and malicious environments (potentially compromising data exchange), so that only sensitive data strictly necessary for the secure execution of operations can be transmitted, preventing unauthorized (re)use of transmitted data, and also preventing the traceability of data exchange. Summary of the Invention

[0009] According to one aspect, the present invention relates to a method for controlling and cooperating multiple devices via a reference device to perform a task, each device being owned by a corresponding owner, each device being equipped with a processing unit, a memory, and a communication unit, and adapted to perform operations required to perform the task, wherein the memory of each device stores: a set of corresponding private keys of the device owner; a distributed identifier (DID) of the device owner associated with a set of public cryptographic keys corresponding to the private keys; a programming method adapted to operate on the processing unit of the device to authenticate other devices and the reference device; a set of public cryptographic keys of the other devices; a set of verifiable data; and verifiable credentials of the device owner, each set of verifiable data including corresponding operational parameter data values ​​and associated internal rules required to perform the task. The communication units are adapted to securely communicate with each other via a wireless or wired communication network. The reference device is equipped with a processing module, a memory module, and a communication module, and is adapted to securely communicate with the communication units of each device via the wireless or wired communication network. The reference device and the devices are adapted to transmit data using an encryption protocol. The memory module of the reference device stores a set of corresponding private keys of the reference owner of the reference device, corresponding distributed identifier data (DID) associated with a set of public cryptographic keys respectively corresponding to the private keys of the reference device, and a set of public cryptographic keys of each of the plurality of devices. The reference device and each device are adapted to digitally sign the transmitted receipt using their corresponding stored private keys, and the memory of each device also stores the set of public cryptographic keys of the reference device. The method is characterized in that:

[0010] - Each data transmission between any two devices and between a reference device and any device is encrypted using a private key according to the encryption protocol, and any recipient of a message transmitted according to the encryption protocol authenticates the sender of the received message by decrypting the message using a public key corresponding to the private key used by the owner of the message sender to encrypt the message, and if the message includes a signed transmission receipt, the recipient further verifies whether each signature on the signed transmission receipt is valid.

[0011] - Each signed transmission receipt sent or received by the device is stored in the memory of the device, and each signed transmission receipt sent or received by the reference device is stored in the memory module of the reference device.

[0012] - Whenever the first device sends an encrypted message to the second device via its communication unit, possibly via the reference device, including a signed transmission receipt and indicating the use of a given operation parameter data value to be performed by the second device as part of the task, the signed transmission receipt includes the respective DIDs of the first device, the second device, and the reference device along with the given operation parameter data value; and,

[0013] - When the second device receives the message via its communication unit, it decrypts the message, performs an operation using the operation parameter data value included in the signed transmission receipt in the received message, and the processing unit of the second device removes selected verifiable data whose operation parameter value matches the given operation parameter data value used to perform the operation from the set of verifiable data of the second device stored in the memory of the second device, and separately stores the selected verifiable data in the memory of the second device, generates a proof of the removal and separate storage of the selected verifiable data, and includes the generated proof in the signed transmission receipt, and the second device further signs the signed transmission receipt in the received decrypted message via its processing unit, and sends an encrypted message to the reference device via its communication unit, the encrypted message including the further signed transmission receipt along with the selected verifiable data; and

[0014] - When the communication module of the reference device receives an encrypted message from the second device, including the further signed transmission receipt along with selected verifiable data, the reference device verifies whether the received proof in the received further signed transmission receipt is valid and whether the data of the received selected verifiable data conforms to the associated internal rules; and

[0015] -In the event that any message transmission concerning the operation between the first and second devices, and between either the first or second device and the reference device, has been successfully authenticated with the corresponding receiver and sender, and the data content of any transmitted message has been successfully verified, the reference device further signs a transmission receipt signed by the first and second devices and containing a certificate generated by the second device, and stores it in the reference device's memory module. It then sends an encrypted message containing the further signed transmission receipt to the first and second devices, thereby indicating to both devices that the operation has been performed; and

[0016] - When the communication unit of the second device receives the transmission receipt further signed by the reference device, the second device deletes the selected verifiable data from the memory of the second device.

[0017] For each operation required to perform the (programmed) task, specific corresponding operation parameter data values ​​are sent to the device responsible for executing the operation. The device receiving these specific operation parameter data values ​​then searches for verifiable data in a set of verifiable data stored in its memory and selects verifiable data whose operation parameter data values ​​match these received specific operation parameter data values. The device then executes the operation corresponding to the selected verifiable data (i.e., by using the specific operation parameter data values), and due to the execution of the operation, the device removes the selected verifiable data from its set of device verifiable data stored in its memory and stores these selected verifiable data (along with the set) separately in its memory. Therefore, compared to the "normal interval" in memory corresponding to these verifiable data elements of the set of device verifiable data, the device has stored the selected verifiable data (separately) in a "busy interval" of its memory (i.e., the selected verifiable data is no longer stored as an element of the set). Each instruction sent from one device (possibly via a reference device) to another device to perform an operation is part of a message containing a transmission receipt signed by that device, and this transmission receipt is stored in the memory of the device and, upon receipt, in the memory of the other device. The reference device also stores any received signed transmission receipts and any transmission receipts signed by the reference device in its memory module. System storage of any sent or received transmission receipts (including any proof of modifications made by the device to the storage of verifiable data) allows for strict control over the various operations involved in the execution of tasks assigned to the devices and allows for checking whether each device has correctly updated its set of verifiable data as it moves from one operation to the next. Each device and the reference device can sign a transmission receipt by calculating a hash value of the data content of the transmission receipt using a programmed signature hash function and encrypting the calculated hash value with one of their private keys. According to traditional signature verification schemes, the integrity of a signed transmission receipt, received from the sender and decrypted by the recipient using the sender's public key (corresponding to the private key used for signing), is checked by the recipient using the sender's decryption signature. This involves extracting the hash value of the decryption signature and comparing it with the calculated hash value of the decrypted transmission receipt data. If the two hash values ​​match, the signature is valid, ensuring the integrity of the transmission receipt. Furthermore, the recipient of the encrypted signed transmission receipt can further verify during the decryption phase that the public key used for decryption indeed belongs to the sender's owner, as identified by the owner's DID included in the decrypted signed transmission receipt.

[0018] The owner of the device or the owner of the reference device can be any entity (e.g., a control unit, operator, etc.) that participates in or organizes the operation of the device to collaborate with other devices to perform a given task. The owner may program certain applications on their device and / or interact with the device via specific communication links or interfaces: these aspects are well known to those skilled in the art and are not the subject of this invention. The device can be a robot or mobile device, such as a mobile phone (e.g., programmed to interact with the device for operation), a laptop or tablet computer, or an IoT device. Another example of multiple interconnected devices is a group of drones collaborating to perform a task (e.g., supplying materials to a designated area or closely monitoring a designated area (e.g., via optical sensors, cameras, etc.)). In this case, verifiable data from the drones may correspond to flight commands, for example, for setting the drone's flight parameters (corresponding to specific operational parameter data values), while internal rules may correspond, for example, to authorized values ​​or ranges of flight parameters. If the corresponding operational parameter data value (used to perform the operation) of the verifiable data does not violate its own internal rules, the verifiable data is considered to conform to the internal rules. The device can (e.g., according to programmed instructions) update internal rules for verifiable data to restrict the use of said operating parameter data values ​​for certain operations to be performed by the device, or by another device that must use or receive corresponding operating parameter data values ​​from the device. A specific example of drones competing to perform tasks is in the field of precision agriculture. In precision agriculture, drones can be used to survey crops, collect data on plant health, and spray pesticides or fertilizers. Multiple drone operators can be contracted to survey and manage a single farm, with each operator responsible for different areas or tasks.

[0019] In this scenario, drone operators compete with each other to provide the best service to farmers while also attempting to maximize their own profits. Operators must cooperate to ensure they don't interfere with each other's work, but they also have incentives to cheat, such as flying their drones outside their designated areas to collect more data or spraying more pesticides than needed to complete their tasks faster. To address these issues, regulators can establish rules for operators to follow, such as designated flight paths or limits on the amount of pesticides that can be sprayed. Operators can also share data to improve the overall quality of surveys, but they must be careful to protect their own interests and data privacy.

[0020] According to the embodiments of the above invention, the processing unit clock of each device is synchronized with the processing module clock of the reference device RD, and each device and the reference device RD are adapted to include timestamp data in the transmitted receipt and verify whether there is a timeout relative to the timestamp data in the received transmitted receipt, wherein the operation as part of the task is performed according to the following steps:

[0021] (A) A first device D1 sends a message to a second device D2 via the communication unit of the first device. The message is encrypted by the processing unit of the first device using one of the private keys of the first device stored in the memory of the first device. The message includes data indicating an operation OP to be performed by the second device D2 and a corresponding transmission receipt signed by the first device. The corresponding transmission receipt contains a given operation parameter data value to be used to perform the operation OP and a first timestamp data.

[0022] (B) When the second device D2 receives an encrypted message from the first device D1, the processing unit of the second device decrypts the message using a public cryptographic key corresponding to the private key of the owner of the first device used to encrypt the message, or by using a shared symmetric key negotiated with the private key of the sender of the message, and verifies whether the signature on the received signed transmission receipt is valid, thereby authenticating the first device as the sender of the received message; and the processing unit of the second device verifies whether there is a timeout relative to the first timestamp data in the received signed transmission receipt; and,

[0023] (B1) In the event of authentication failure of the first device D1, invalid signature on the signed transmission receipt, or timeout, the second device D2 sends a corresponding error notification to the reference device via its communication unit, data transmission with the first device D1 is cancelled, and the reference device RD forwards the received error notification to the first device D1; and

[0024] (B2) If the authentication of the first device D1 is successful, the signature on the signed transmission receipt is valid, and there is no timeout, the processing unit of the second device D2 selects verifiable data D2SVD from the set of verifiable data D2VD stored in the memory of the second device D2, wherein the operation parameter data value matches the received given operation parameter data value. The processing unit of the second device D2 updates the internal rules of the selected verifiable data. The second device D2 performs the operation by using the selected verifiable data D2SVD. The processing unit of the second device D2 retrieves the verifiable data D2SVD from the set of verifiable data D2VD stored in the memory of the second device D2. The selected verifiable data D2SVD is removed from the set of verification data D2VD, and the selected verifiable data D2SVD, together with the updated associated internal rules, is stored separately in the memory of the second device D2. A proof PR1 for the removal and separate storage of the selected verifiable data D2SVD is generated. The selected verifiable data D2SVD is incorporated into the message. The generated proof PR1 and the second timestamp data are included in a signed transmission receipt. The transmission receipt is further signed, and the further signed transmission receipt is included in the message. The message is encrypted using one of the private keys of the second device D2, and the encrypted message is sent to the reference device RD.

[0025] (C) When the communication module of the reference device RD receives a message from the second device D2, the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, verifies whether the signature on the transmission receipt is valid, whether there is a timeout relative to the first timestamp data and the second timestamp data, verifies whether the proof PR1 is valid, and whether the received verifiable data D2SVD selected by the second device conforms to the corresponding associated internal rules; and

[0026] (C1) In the event that the signature is invalid, or a timeout occurs, or the proof PR1 is invalid, or the received verifiable data D2SVD selected by the second device does not conform to the corresponding internal rules, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via the communication module of the reference device RD, and the data transmission between the first device D1 and the second device D2 is cancelled; and

[0027] (C2) If the signature is valid, there is no timeout, the proof PR1 is valid, and the received verifiable data D2SVD selected by the second device conforms to the corresponding internal rules, the processing module of the reference device RD includes the verifiable data D2SVD selected by the second device in the message, further signs the signed transmission receipt and appends the further signed transmission receipt to the message, encrypts the message using the private key stored in the memory module, sends the encrypted message to the first device D1, and the processing module of the reference device RD encrypts the further signed transmission receipt using the private key stored in the memory module and sends the encrypted further signed transmission receipt to the second device D2.

[0028] (D) When the communication unit of the first device D1 receives a message from the reference device RD, the processing unit of the first device D1 decrypts the message using the public key corresponding to the private key used by the reference device RD to encrypt the message, and extracts the verifiable data selected by the second device from the message; and,

[0029] (D1) The first device D1 modifies the set of first device verifiable data (D1VD) stored in the memory of the first device D1 by generating and storing a new set of first device verifiable data D1VD' including the extracted verifiable data D2SVD selected by the second device.

[0030] (E) When the communication unit of the second device D2 receives an error notification sent by the reference device RD according to step (C1), the processing unit of the second device D2 transmits the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, to the set of verifiable data D2VD of the second device D2.

[0031] (F) When the communication unit of the second device D2 receives the decryption and verification of the signature of the encrypted signed transmission receipt sent by the reference device RD according to step (C2), the processing unit of the second device D2 deletes the verifiable data D2SVD selected by the second device that is separately stored in the memory of the second device D2.

[0032] In the above context, the timestamp data included in the transmission receipt is not merely a snapshot of the current time. Rather, it represents a time constraint that, if violated, will result in a timeout. Individual devices can express specific timing constraints, and therefore, the most stringent constraint will ultimately govern the timeout. This timestamp data allows for increased security in the operation performed by the device and enables the detection (and reporting) of faults.

[0033] At step (A), the message sent by the first device is encrypted to protect the message content and / or to authenticate itself before the second device. For example, it is possible that the second device challenges the first device, or the first device performs the authentication using authentication encryption with a key combination. Alternatively, at step (B), when the second device receives the message, the processing unit of the second device can authenticate the owner of the message sender by using a shared symmetric key negotiated with the private key of the message sender, and then perform the steps of verifying whether the signature on the received transmission receipt is valid and whether there is a timeout relative to the first timestamp data of the transmission receipt. According to the invention, strong authentication of the sender of an encrypted message including a signed transmission receipt is based on a first stage of decrypting the message using a public key corresponding to the sender's private key used to encrypt the message, and a second stage of verifying that the signature on the (decrypted) signed transmission receipt matches the signature corresponding to the private key. Verification of the validity of the signature on the transmission receipt is also used (if the signature is valid) to ensure the data integrity of the content of the signed transmission receipt.

[0034] According to another embodiment of the invention, the processing unit clock of each device is synchronized with the processing module clock of the reference device RD, and each device and the reference device RD are adapted to include timestamp data in the transmitted receipt and to verify whether there is a timeout relative to the timestamp data in the received transmitted receipt, and wherein the operation as part of the task is performed according to the following steps:

[0035] (A') The first device D1 sends a message to the reference device RD via the communication unit of the first device. The message is encrypted by the processing unit of the first device using one of the private keys of the first device stored in the memory of the first device. The message includes data indicating an operation OP to be performed by the second device D2 and a corresponding transmission receipt signed by the first device. The corresponding transmission receipt contains a given operation parameter data value to be used to perform the operation OP and a first timestamp data.

[0036] When the communication module of the reference device RD receives an encrypted message from the first device D1, the processing module of the reference device RD decrypts the message using a public cryptographic key corresponding to the private key used by the owner of the first device D1 to encrypt the message, thereby authenticating the first device as the sender of the received message. The processing module of the reference device RD also verifies the validity of the signature on the received signed transmission receipt and whether there is a timeout relative to the first timestamp data in the signed transmission receipt.

[0037] (A1') If authentication of the first device D1 fails, or the signature of the transmission receipt is invalid, or a timeout occurs, the reference device RD sends an error message to the first device D1 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and

[0038] (A2') If the authentication of the first device is successful, the signature on the transmission receipt is valid, and there is no timeout relative to the first timestamp data, the processing module of the reference device RD includes the reference device timestamp RDTS in the signed transmission receipt, appends the signed transmission receipt to the message, encrypts the message including the signed transmission receipt using one of the private keys of the reference device RD stored in the memory module of the reference device RD, and sends the encrypted message to the second device D2 via the communication module of the reference device RD.

[0039] (B') When the second device D2 receives an encrypted message from the reference device RD, the processing unit of the second device D2 decrypts the message using a public cryptographic key corresponding to the private key used by the owner of the reference device RD to encrypt the message, thereby authenticating the reference device RD as the sender of the received message, verifying whether the signature of the first device D1 on the received signed transmission receipt is valid, and whether there is a timeout relative to the first timestamp data of the signed transmission receipt and the reference device timestamp data in the message; and,

[0040] (B1') In the event of authentication failure of the reference device RD, invalid signature on the signed transmission receipt, or timeout, the second device D2 sends a corresponding error notification to the reference device RD via its communication unit. The reference device RD forwards the received error notification to the first device D1, and data transmission with the first device D1 is cancelled; and

[0041] (B2') If the authentication of the reference device RD is successful, the signature on the signed transmission receipt is valid, and there is no timeout, the processing unit of the second device D2 selects verifiable data D2SVD from the set of verifiable data D2VD stored in the memory of the second device D2, wherein the operation parameter data value matches the received given operation parameter data value. The processing unit of the second device D2 updates the internal rules associated with the selected verifiable data. The second device D2 performs an operation based on the selected verifiable data D2SVD, and the processing unit of the second device D2 retrieves the verifiable data D2SVD stored in the memory of the second device D2. The selected verifiable data D2SVD is removed from the set of 2VDs, and the selected verifiable data D2SVD, together with the updated associated internal rules, is stored separately in the memory of the second device D2. A proof PR1 corresponding to the removal and separate storage is generated, corresponding to the execution of the operation OP. The selected verifiable data D2SVD is incorporated into the message. The generated proof PR1 and the second timestamp data are included in the signed transmission receipt. The signed transmission receipt is further signed and the further signed transmission receipt is appended to the message. The message is encrypted using one of the private keys of the second device D2, and the encrypted message is sent to the reference device RD.

[0042] (C') When the communication module of the reference device RD receives a message from the second device D2, the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, verifies whether the signature on the signed transmission receipt is valid, and whether there is a timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data in the signed transmission receipt, verifies whether the proof PR1 in the signed transmission receipt is valid, and whether the verifiable data D2SVD selected by the received second device conforms to the corresponding associated internal rules; and

[0043] (C1') In the event of an invalid signature, a timeout, invalid proof of PR1, or the received verifiable data D2SVD selected by the second device not conforming to the associated internal rules, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and

[0044] (C2') If the signature is valid, there is no timeout, the proof PR1 is valid, and the received verifiable data D2SVD selected by the second device conforms to the associated internal rules, the processing module of the reference device RD encrypts the message using the private key stored in the memory module and sends the encrypted message including the signed transmission receipt to the first device D1.

[0045] (D') When the communication unit of the first device D1 receives a message and a signed transmission receipt from the reference device RD, the processing unit of the first device D1 decrypts the message using the public key corresponding to the private key used by the reference device RD to encrypt the message, verifies whether the signature on the signed transmission receipt is valid and whether there is a timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and extracts the verifiable data D2SVD selected by the second device from the decrypted message; and,

[0046] (D1') If the signature on the signed transmission receipt is invalid or a timeout occurs, the first device D1 sends a corresponding error notification to the reference device RD via its communication unit. The reference device RD forwards the received error notification to the second device D2, and data transmission with the first device D1 is cancelled; and

[0047] (D2') If the signature on the signed transmission receipt is valid and there is no timeout, the processing unit of the first device D1 modifies the set of first device verifiable data (D1VD) of the first device D1 stored in the memory of the first device D1 to generate a new set of first device verifiable data D1VD' including the extracted second device-selected verifiable data D2SVD and stores the new set into the set of first device verifiable data (D1VD), generates such included proof PR2, removes the second device-selected verifiable data D2SVD from the message, incorporates the generated included proof PR2 into the signed transmission receipt, encrypts the message using the private key stored in the memory of the first device D1, and forwards the encrypted message including the signed transmission receipt to the reference device RD; and

[0048] (D3') When the communication module of the reference device RD receives a message with a signed transmission receipt sent by the first device D1 according to sub-step (D2'), the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the first device D1 to encrypt the message, and verifies whether the signature on the signed transmission receipt is valid, whether there is no timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, whether the proof PR2 included in the signed transmission receipt is valid, and

[0049] (D4') In the event of an invalid signature, a timeout, or an invalid proof PR2, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled.

[0050] (D5') If the signature is valid, there is no timeout, and the included proof PR2 is valid, the processing module of the reference device RD encrypts the message using a private key from the private key set stored in the memory module, and forwards the encrypted message to the second device D2 via the communication module.

[0051] (E') When the communication unit of the second device D2 receives an error notification sent by the reference device RD according to step (C1'), the processing unit of the second device D2 transmits the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, to the set of verifiable data of the second device D2.

[0052] (F') When the communication unit of the second device D2 receives a message with a signed transmission receipt forwarded by the reference device RD according to step (D5'), the processing unit of the second device D2 decrypts the message using the public key stored corresponding to the private key used by the reference device RD to encrypt the message, and verifies whether the signature on the transmission receipt is valid, whether there is a timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and whether the included proof PR2 is valid; and

[0053] (F1') In the event of an invalid signature, a timeout, or an invalid received proof PR2, the second device D2 sends a corresponding error notification to the reference device RD via its communication unit, data transmission to the first device D1 is cancelled, and the reference device RD forwards the error notification to the first device D1; and

[0054] (F2') If the signature is valid, there is no timeout, and the received proof PR2 is valid, the second device D2 deletes the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, further generates proof PR3 for the deletion, incorporates the generated proof PR3 into the signed transmission receipt, encrypts the message including the signed transmission receipt using one of the private keys of the second device D2, and forwards the encrypted message to the reference device RD; and

[0055] (G') When the communication module of the reference device RD receives a message with a signed transmission receipt forwarded by the second device D2 according to step (F2'), the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, and verifies whether the signature on the transmission receipt is valid, whether there is no timeout relative to the first timestamp data, the reference device timestamp data and the second timestamp data, and whether the received deletion proof PR3 in the signed transmission receipt is valid; and

[0056] (G1') If the signature on the signed transmission receipt is invalid, or a timeout occurs, or the received deletion proof PR3 is invalid, the reference device RD sends a corresponding error notification to the second device D2 and the first device D1 via the communication module of the reference device RD, and the data transmission between the first device D1 and the second device D2 is cancelled; and

[0057] (G2') If the signature on the signed transmission receipt is valid, there is no timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and the received deletion proof PR3 is valid, the processing module of the reference device RD further signs the signed transmission receipt, encrypts the further signed transmission receipt using one of the private keys stored in the memory module, and forwards the encrypted further signed transmission receipt to the first device D1 and the second device D2 via the communication module.

[0058] According to a variation of the invention, at step (C) or (C') of the above method, if the internal rules of the verifiable data D2SVD selected by the received second device specify the use of the verifiable credentials of the respective owners of the first device D1 or the second device D2, the reference device RD further checks the conformity of the verifiable credentials of the respective owners of the first device D1 or the second device D2 to the internal rules by communicating with the first device or the second device respectively via a credential sharing protocol.

[0059] Examples of known credential sharing protocols include: Indy Anoncreds (ZKP) (see, for example

[17] ), W3C CHAPI (non-ZKP) (see, for example

[18] ), and DIF credential list (ZKP or non-ZKP) (the credential list is a specification developed within the Distributed Identity Foundation (DIF) and is intended to be approved as the data format recommended by DIF).

[0060] The possible representation of verifiable data in the device's memory can be achieved using a Merkle tree, as described above, to clearly detect and prove a change from storage in a "normal interval" to storage in a "busy interval." Merkle trees exhibit the advantage of being virtually unforgeable due to the multi-level hashing used to create their nodes (from leaf nodes to the root node). Therefore, in the method described above, each verifiable data point in the set of verifiable data of the device is associated with a corresponding leaf node of a Merkle tree corresponding to the device, each leaf node corresponding to a hash value obtained by hashing the corresponding associated verifiable data using a hash function, the Merkle tree including intermediate nodes up to the root node of the tree, the root node corresponding to the root value of the tree calculated according to the hashing scheme of the Merkle tree, and the Merkle tree being stored in the device's memory.

[0061] - The processing unit of the device is adapted to modify the set of verifiable data stored in the memory of the device in the following manner, the modification corresponding to the removal of given verifiable data from the set: selecting a node of a stored Merkle tree corresponding to each given verifiable data to be removed from the set of stored verifiable data; replacing each removed verifiable data with corresponding placeholder data and hashing each placeholder data using the hash function to obtain corresponding placeholder leaf node values; obtaining a first part of the leaf nodes of a new Merkle tree by replacing the selected leaf nodes with their respective corresponding placeholder leaf nodes, and adjaculating a second part of the leaf nodes, which are separately stored leaf nodes and correspond to the selected leaf nodes of the Merkle tree respectively, adjacent to the first part; and forming the new Merkle tree from the stored Merkle tree by calculating new intermediate nodes of the new Merkle tree up to the new root node of the new Merkle tree with the first part and the second part of the leaf nodes according to the hash scheme using the hash function; and storing the new Merkle tree in the memory of the device.

[0062] - The processing unit of the device is adapted to generate a proof of modification to the set of verifiable data stored in the device's memory, corresponding to the execution of an operation performed by the device using operational parameter data values ​​of the given verifiable data, by sending the new root node value of the new Merkle tree along with root verification data to the reference device. The root verification data includes, respectively, the values ​​of the new placeholder nodes and new intermediate nodes of the new Merkle tree, the values ​​of which have been modified relative to the Merkle tree and are required to retrieve the new root value using the hash function according to the hash scheme; and

[0063] - The processing module of the reference device is adapted to verify that the new root node value of the new Merkle tree received from the device, together with the corresponding root verification data, as proof that the device has performed the operation, matches the test root node value calculated from the received root verification data, thereby verifying that the device has performed the operation.

[0064] - In the case of deleting verifiable data corresponding to the leaf nodes of the separately stored new Merkle tree, the resulting updated Merkle tree is obtained by calculating the corresponding values ​​of the updated intermediate leaf nodes up to the updated root node of the new Merkle tree using the hash function according to the hash scheme only from the first part of the leaf nodes of the new Merkle tree. The updated root node value of the updated Merkle tree, together with the corresponding updated root verification data, constitutes the proof of the deletion of the verifiable data.

[0065] - When specific verifiable data is included in a set of verifiable data stored as an initial Merkle tree in the device's memory, the hash function is used to calculate the corresponding values ​​of additional leaf nodes from each of the included specific verifiable data, and the corresponding final Merkle tree is calculated from the values ​​of the leaf nodes of the initial Merkle tree and the values ​​of the additional leaf nodes according to the hash scheme. The resulting root node value of the final Merkle tree, together with the resulting root verification data, constitutes proof of the inclusion of the specific verifiable data; and

[0066] The processing unit of the device and the processing module of the reference device are adapted to calculate the node values ​​of the Merkle tree using programmed hash functions and hash schemes, and to calculate the root value based on the root verification data.

[0067] In the method described above according to the present invention, at step (B2) or step (B2'), the processing unit of the second device may:

[0068] - Generate a new symmetric encryption key K, and use the generated key K to encrypt specific control fields of each selected verifiable data D2SVD;

[0069] - Encrypt the generated key K so that the encrypted key K can be decrypted using the public cryptographic key of the first device D1; and

[0070] - Further, the encrypted key K, along with each encrypted specific control field, is incorporated into the message.

[0071] Furthermore, at either step (C2) or step (C2'), when the message including the verifiable data D2SVD selected by the second device and the signed transmission receipt is received from the reference device RD, the processing unit of the first device can use the corresponding private key of the first device stored in the memory of the first device to decrypt the encrypted key K to obtain the encryption key K, and use the key K to decrypt each encrypted control field of the verifiable data D2SVD selected by the second device in the received message, thereby allowing the first device D1 to access the control field data of the second device D2 without revealing the data to the reference device RD.

[0072] In the method described above according to the present invention, at step (B) or step (B'), after the received message has been decrypted and before it is verified that the signature of the received transmission receipt is valid and there is no timeout, the second device D2 can perform further level authentication of the first device D1 or the reference device RD by engaging in challenge-response communication with the first device D1 or the reference device RD, respectively. Only when the second device D2 receives a correct response to the challenge sent by the second device D2 to the first device D1 or the reference device RD, respectively, can the processing unit of the second device D2 verify that the signature on the received transmission receipt is valid and there is no timeout relative to the first timestamp data of the message. In the case of an incorrect response to the challenge, the data transmission with the first device D1 is canceled.

[0073] According to another variation of the above method

[0074] -Each DID of the device owner may include a corresponding unique identifier (UID) of the device owner delivered by the identity server (IS) in response to the device owner's one-time registration settings with the identity server.

[0075] Each device can be adapted to communicate with a hosting server (ES) via the communication network, and each owner of the device can perform a one-time registration setup with the hosting server by sending a request via the device to the hosting server containing a unique identifier of the device and a cryptographic commitment to the link secret of the device. Upon receiving the request, the hosting server can create an entropy test vector (ETV) corresponding to a byte block generated by a random number generator and a corresponding asymmetric encryption key pair (OK). pub OK priv ), to determine by first using the private key OK priv Encrypt the received unique identifier (UID) and then use the private key OK. priv The corresponding shielding configuration file (SP) obtained by encrypting the entropy test vector and the encrypted unique identifier is stored as the triple (OK). pub (,SP,UID), and deliver to the device a triple (OK) pub An anonymous verifiable credential C, consisting of SP, UID, and a cryptographic commitment to the link secret of the device. ES The hosting server may be adapted to communicate with the identity server via a communication network and request the identity server to confirm that the unique identifier (UID) received by the hosting server from the device is indeed owned by the owner of the device.

[0076] Each device can be adapted to communicate with the governance server (GS) via a communication network, and each device owner can perform a one-time registration setup with the governance server by first establishing a session with the governance server via the owner's device. During this session, the device uses a temporary DID and the governance server is authenticated. The governance server can then query the device to generate proof of the device owner's registration with the hosting server (ES), and in response, the device can generate an anonymous verifiable credential C based on the one delivered by the hosting server. ES The device provides proof and sends the proof to the governance server. Upon receiving the proof, the governance server can deliver multiple one-time use identity tokens and corresponding verifiable credentials C to the device. GS Each delivered Single Use Identity Token (SUIT) is a public key that can be used to locate the device. pub The string, the verifiable credential C delivered. GS It includes a field for each delivered Single Use Identity Token (SUIT) and a cryptographic commitment to the link secret of the device.

[0077] - In the case where device A in a multi-device network communicates with device B in a multi-device network using a DID that has never been seen before.

[0078] The device B can then interrogate the device A to reveal the corresponding verifiable credential C. GS One of the single-use identity tokens (SUITs) delivered to device A by the governance server is used to prove that the owner of device A has registered with the governance server.

[0079] In response, device A can generate a verifiable credential C that reveals one of the corresponding one-time use identity tokens (SUIT). GS Zero-knowledge proofs, and

[0080] Device B can record the revealed single-use identity token (SUIT) in a signed transmission receipt generated by device A.

[0081] Another invention relates to a system for controlling multiple devices via a reference device to enable the devices to cooperate in performing a task. Each device is owned by a corresponding owner, and each device is equipped with a processing unit, a memory, and a communication unit and is adapted to perform operations required to perform the task. The memory of each device stores: a set of corresponding private keys of the device owner; a distributed identifier (DID) of the device owner associated with a set of public cryptographic keys corresponding to the private keys; a programming method adapted to operate on the processing unit of the device to authenticate other devices and the reference device; a set of public cryptographic keys of the other devices; a set of verifiable data having corresponding operational parameter data values ​​and associated internal rules required to perform the task; and verifiable credentials of the device owner. The communication units of the devices are adapted to securely communicate with each other via a wireless or wired communication network. The reference device is equipped with a processing module, a memory module, and a communication module, and is adapted to communicate securely with each other via the wireless or wired communication network. A wired communication network securely communicates with the communication units of each device. The reference device and the devices are adapted to transmit data using an encryption protocol. The memory module of the reference device stores a set of corresponding private keys of the reference owner of the reference device, as well as corresponding Distributed Identifier Data (DID) and a set of public cryptographic keys corresponding to the private keys of the reference device, and a set of public cryptographic keys of each of the plurality of devices. The reference device and each device are adapted to digitally sign the transmission receipt using their corresponding private keys. The memory of each device also stores the set of public cryptographic keys of the reference device. The clock of the processing unit of each device is synchronized with the clock of the processing module of the reference device RD. Each device and the reference device RD are adapted to include timestamp data in the transmission receipt and to verify whether there is a timeout relative to the timestamp data in the received transmission receipt. The system is characterized in that the devices and the reference device are adapted to perform the steps of the method according to the present invention.

[0082] In particular, when the system is adapted to implement the steps of the further variations of the method of the present invention, the system may further include:

[0083] - An identity server (IS), adapted to communicate with the device via the communication network, and in response to a one-time registration setting by the device's owner with the identity server, delivers the owner's corresponding unique identifier (UID) to the device for association with the device's owner's distributed identifier data (DID).

[0084] - A hosting server ES, adapted to communicate with the device via the communication network, and upon receiving a request from the device containing a unique identifier UID of the device's owner and a cryptographic commitment to the device's link secret, performs a one-time registration of the device's owner in the following manner:

[0085] - Create the corresponding entropy test vector (ETV) and the corresponding asymmetric encryption key pair (OK) for the byte blocks generated by the random number generator. pub OK priv ), to determine by first using the private key OK priv Encrypt the received unique identifier (UID) and then use the private key OK. priv The corresponding shielding configuration file (SP) obtained by encrypting the entropy test vector and the encrypted unique identifier is stored as the triple (OK). pub (,SP,UID), and deliver to the device a triple (OK) pub An anonymous verifiable credential C, consisting of SP, UID, and a cryptographic commitment to the link secret of the device. ES The hosting server is adapted to communicate with the identity server via the communication network and request the identity server to confirm that the unique identifier (UID) received by the hosting server from the device is indeed owned by the owner of the device.

[0086] A governance server GS, adapted to communicate with the device via the communication network and to perform a one-time registration setup with the device's owner when the device establishes a session with the governance server, during which the device uses a temporary DID and the governance server is authenticated, the governance server then challenges the device to generate proof of the device's owner's registration with the hosting server (ES), and in response, the device generates an anonymous verifiable credential C based on the one delivered by the hosting server. ES The system provides proof of identity and sends the proof to the governance server. Upon receiving the proof, the governance server delivers multiple one-time use identity tokens and corresponding verifiable credentials C to the device. GS Each delivered Single Use Identity Token (SUIT) is a public key that can be used to locate the device. pub The string, the verifiable credential C delivered. GS Includes a field for each delivered Single Use Identity Token (SUIT) and a cryptographic commitment to the link secret of the device, and

[0087] -In the case where device A among the plurality of devices communicates with device B among the plurality of devices by using a DID that has never been seen before.

[0088] The device B then interrogates the device A to reveal the corresponding verifiable credential C. GS One of the single-use identity tokens (SUIT) delivered to device A by the governance server is used to prove that the owner of device A has registered with the governance server GS.

[0089] In response, device A generates a verifiable credential C that reveals one of the corresponding one-time use identity tokens (SUIT). GS Zero-knowledge proofs, and

[0090] Device B records the revealed single-use identity token (SUIT) in a signed transmission receipt generated by device A.

[0091] The invention will be described more fully below with reference to the accompanying drawings, in which the same reference numerals denote the same elements in different figures, and in which prominent aspects and features of the invention are illustrated in a non-limiting manner. Attached Figure Description

[0092] Figure 1 The illustration schematically demonstrates how an interconnecting device according to an embodiment of the present invention performs the operations required to perform an assigned task.

[0093] Figure 2 Another embodiment of the invention is illustrated schematically, which has improved security against intrusion during operation of the collaborative device. Detailed Implementation

[0094] According to an embodiment of the present invention, multiple unmanned aerial vehicles (UAVs) D1, D2, ..., DN, belonging to owners OW1, OW2, ..., are collaborating to perform complex tasks: for example, detecting suspicious movement and / or performing video surveillance in a designated area while delivering specific equipment at different locations within that area. Each UAV Di (i=1,...,N) is equipped with a processing unit coupled to a memory and a communication unit, and has a motor coupled to rotor blades to propel the UAV and operate it above the area. Each UAV is also equipped with a power supply (battery) to power its processing unit and its motor. The UAV may also be equipped with (one or more) sensors (e.g., task-appropriate light sensors, thermal sensors, barometers, or radar altimeters, etc.) and cameras (with image processing capabilities) controlled via its processing unit. The memory of each UAV Di (i=1,...,N) stores a set of verifiable data, each verifiable data in the set including corresponding operational parameter data values ​​and associated internal rules, which the UAV Di must use to perform corresponding (programmed) operations as part of the task to be performed by the UAV. The memory of each UAV Di (i=1,…,N) owned by the corresponding owner OWI (i=1,…,N) also stores a set of unique private cryptographic keys belonging to the corresponding owner OWI, a corresponding unique distributed identifier (DID, see, for example, reference

[13] ) of owner OWI associated with a set of public cryptographic keys corresponding to the stored private keys, and verifiable credentials of owner OWI (see, for example, reference

[14] ). The memory of each UAV also stores a set of corresponding public keys of other UAVs. The collaboration of multiple UAVs to perform complex tasks requires the UAVs to be able to exchange data and perform different operations using the exchanged data while performing the task. However, since the environment in which UAVs evolve is untrusted (or even malicious), especially regarding the possibility of intrusion during data exchange (to transfer or destroy data, or to sabotage the execution of the task), it is necessary to protect data exchange and properly identify the parties exchanging data, while minimizing the amount and criticality of the data exchanged to prevent intruders from transferring / destroying critical data. It is particularly important that only devices belonging to authorized owners (including reference devices) can collaborate to perform tasks. During a mission, the drone can be flown by its owner (via a wireless communication network) or using pre-programmed flight commands (stored in its memory and managed by its processing unit).

[0095] According to the present invention, each UAV Di (i=1,…,N) stores a set of verifiable data in its memory, wherein each element in the set (particularly the operational parameter data values ​​of the elements) can be used to allow the UAV to perform certain operations required to perform a task. The memory of each UAV Di also stores, in association with each stored verifiable data, corresponding internal rules that the verifiable data must conform to during the execution of the operation. During the execution of any operation required to perform the task, based on data exchanged with (one or more) other UAVs, the internal rules associated with each verifiable data in the set of verifiable data can be modified and can be used to prove the correct execution of the operation. Therefore, the communication units of the UAVs are adapted to communicate securely with each other via a wireless communication network, and the memory of each UAV Di (i=1,…,N) also stores programming methods suitable for authenticating (one or more) other UAVs, which are suitable for operation on its processing unit. Control of the multiple UAVs is performed via a reference UAV RD (reference device). The benchmark drone RD is owned by the benchmark owner RW and is equipped with a processing module coupled to a memory module and a communication module. It also has a motor coupled to rotor blades to propel the benchmark drone and operate it (alongside other drones) above the area. The benchmark drone RD is also equipped with a power module (battery) to power its processing module and motor. The benchmark drone may also be equipped with various sensors and cameras (with image processing capabilities) suitable for the mission, controlled via its processing module. The memory module of the benchmark drone RD stores a corresponding set of unique private cryptographic keys belonging to the benchmark owner RW and associated with the benchmark owner RW's corresponding unique distributed identifier (RW-DID), a set of public cryptographic keys corresponding to the private keys stored with the benchmark owner, and verifiable credentials of the benchmark owner RW. The memory module also stores the corresponding set of public keys for each drone Di (i=1,…,N). Preferably, the memory module stores the DID of each drone instead of the public keys. More preferably, the memory of any drone also stores the corresponding set of public keys for other drones and the benchmark drone. Then, DID is used to resolve the public key in a timely manner. The advantage is that DID thus allows key rotation without invalidating the knowledge stored in the peer-to-peer drone.

[0096] The baseline drone RD is also adapted to securely communicate with each drone communication unit via a wireless communication network (here, RD uses the same communication link as for communication between drones). The communication units of the baseline drone RD and the drones Di (i=1,…,N) are adapted to transmit data using an encryption protocol. The baseline drone RD and each drone Di are also adapted to digitally sign the transmission receipts for data exchange using their corresponding private keys. The memory of each drone Di (i=1,…,N) also stores a set of public keys corresponding to the private key of the baseline owner RW belonging to the baseline drone RD. Furthermore, the processing unit of each drone is equipped with a clock, the processing module of the baseline drone is also equipped with a clock, and the clocks of the processing units of each drone are synchronized with the clock of the processing module of the baseline drone RD. Each drone and the baseline drone RD are adapted to include timestamp data in the transmission receipts and to verify whether there is a timeout relative to the timestamp data in the received transmission receipts.

[0097] Figure 1 The illustration schematically illustrates a typical secure data exchange between two specific drones (e.g., D1 and D2, owned by owners OW1 and OW2 respectively) controlled by a reference drone RD, for performing operations required to carry out a task according to the above embodiments. Typically, when drone D1 communicates with drone D2 to perform an operation (OP): drone D1 creates a message M1 for drone D2. Message M1 includes a transmission receipt containing first timestamp data TS1 and data specifying the operation OP to be performed by D2, indicating specific operation parameter data values ​​that must be used by D2 to perform the operation. The transmission receipt also includes the corresponding DIDs of drone D1, drone D2, and the reference drone RD (and the given operation parameter data values ​​for the operation OP). Then, the processing unit of D1 signs the transmission receipt TR1 for the transmission of message M1, and thus generates a corresponding signed transmission receipt STR1 and stores STR1 in its memory. The signed transmission receipt STR1 is appended to message M1, and message M1 (including STR1) is encrypted using a private key selected from the set of private keys stored in its memory (belonging to its owner OW1). Then, at step S1, UAV D1 initiates (S) exchange by sending an encrypted message M1 to UAV D2 (via its communication unit on a wireless communication network). The encrypted message M1 includes the signed transmission receipt STR1 (in...). Figure 1 (Shown above as [M1+STR1]). Encryption is used to protect the content of message M1, but will also be used to authenticate D1 (as the sender of the message) before D2.

[0098] When the communication unit of D2 receives the encrypted message [M1+STR1] from D1, which includes a signed transmission receipt, the processing unit of D2 performs step S2, namely:

[0099] - By decrypting the received message using the public key of D1 (owner OW1), which corresponds to the private key used by D1 to encrypt M1 (D1's owner OW1) (this public key is part of the set of D1's public keys stored in D2's memory), the sender of the received message is authenticated as drone D1 belonging to the (authorized) owner OW1 (referred to as D2 authenticating D1). Alternatively, D2's processing unit can use a shared symmetric key negotiated with D1's private key.

[0100] - According to traditional signature verification schemes, the validity of the signature on the received (and decrypted) signed transmission receipt STR1 is verified by checking the data integrity of the signed transmission receipt as follows: decrypt the signature using (decrypted with the public key of D1 above), extract the hash value of the transmission receipt data contained in the decrypted signature, and compare the extracted hash value with the calculated hash value of the decrypted transmission receipt data: if the two hash values ​​match, the signature is valid, and the data integrity of the transmission receipt is ensured. D2 also verifies whether there is a timeout relative to the first timestamp data TS1 of the received (and decrypted) signed transmission receipt STR1; then,

[0101] - In the event of authentication failure of D1, i.e., decryption using the public key corresponding to the private key used by D1 to encrypt the message (stored in the memory of D2) is impossible, or the signature on the received signed transmission receipt STR1 is invalid (i.e., cannot be attributed to OW1, the owner of device D1 authenticated during the decryption phase), or there is a timeout relative to the first timestamp data TS1 extracted from the decrypted signed transmission receipt STR1, then D2 proceeds to step S3: sending the corresponding error notification E1 to the reference UAV RD via D2's communication unit, and canceling data transmission with D1. Upon receiving the error notification E1 from D2, the reference UAV RD proceeds to step S4: forwarding the received error notification E1 to D1 via its communication module, and

[0102] -If D2 successfully authenticates D1 (owner OW1), and the signature on the signed transmission receipt STR1 is valid, and there is no timeout relative to the timestamp data TS1, D2 stores the signed transmission receipt STR1 in its memory and proceeds to step S5, i.e.,

[0103] The processing unit of D2 selects a verifiable data D2SVD from the set of verifiable data D2VDs stored in D2's memory. The verifiable data D2SVD whose corresponding operation parameter data value matches the specific operation parameter data value specified in the received signed transmission receipt STR1 (these parameter data values ​​must be used by D2 to perform the operation OP), and (possibly) updates the internal rules associated with the selected verifiable data D2SVD. This (potential) update of the internal rules by D2 allows for adaptation to some rules related to the exact operation OP to be performed.

[0104] -D2 performs the operation OP using the selected verifiable data D2SVD and the corresponding operation parameter data values. Therefore, the processing unit of D2 modifies the set of verifiable data D2VD (including the corresponding internal rules) stored in its memory by removing the selected verifiable data D2SVD used to perform the operation OP from the set of stored verifiable data, and stores the selected verifiable data D2SVD separately in the memory of D2: therefore, D2SVD is no longer stored as an element of the original set of verifiable data (i.e., before performing the operation OP), and is now stored separately in the "busy area" of memory.

[0105] The processing unit of UAV D2 generates proof PR1 indicating that an operation (OP) has been performed. Proof PR1 demonstrates the storage of (separately stored) D2SVD in the new "busy" area of ​​memory, compared to the previous storage of the original set of verifiable data D2VD in the "normal" area of ​​memory, and the storage of the modified set of verifiable data D2VD'. Proof PR1 shows that verifiable data whose corresponding operation parameter data values ​​have been used to perform the operation OP has been removed from the set of verifiable data, and therefore, this verifiable data will not potentially be reused for another operation (according to the programming operation required to perform the task). The processing unit of D2 includes proof PR1 together with the second timestamp data TS2 in the (decrypted) signed transmission receipt STR1, and further signs the resulting signed transmission receipt to produce a signed transmission receipt STR2. Then, the processing unit of D2 stores STR2 in D2's memory and incorporates the selected verifiable data D2SVD along with the signed transmission receipt STR2 into message M1, thereby generating message M2. The processing unit of D2 encrypts message M2 using one of its private keys; then,

[0106] -D2 proceeds to step S6: It forwards an encrypted message M2, including a signed transmission receipt STR2, to the base UAV RD via its communication unit, as shown in... Figure 1 The above is symbolically represented by [M2+STR2].

[0107] When the communication module of the reference UAV RD receives the encrypted message [M2+STR2] with a signed transmission receipt from D2, the processing module of the reference UAV RD performs step S7, namely:

[0108] - The processing module of the baseline UAV RD authenticates OW2, the owner of D2, as the sender of the received message by decrypting the received message [M2+STR2] using the following public cryptographic key of D2 (referred to as authenticating D2). This public cryptographic key corresponds to the private key used by D2 to encrypt M2 (this public key is part of the set of public keys of the UAV stored in the memory module of RD).

[0109] - Verify that the signature on the (decrypted) signed transmission receipt STR2 (i.e., the signatures of D1 and D2) is valid (i.e., check the data integrity of the transmission receipt STR2 as described above regarding step S2), and verify that there is no timeout relative to the highest time constraint required in the first timestamp data TS1 and the second timestamp data TS2 in STR2.

[0110] - Verify whether the proof PR1 is valid (i.e., corresponding to the separate storage of D2SVD), and whether the received verifiable data D2SVD conforms to the associated (updated) internal rules; then,

[0111] In the event that the signature on STR2 is invalid, or there is a timeout according to the decryption message M2, or the first proof PR1 is invalid, or the verifiable data D2SVD does not conform to the associated internal rules, the reference UAV RD sends a corresponding error notification E2 to UAV D1 via its communication module at step S8 and to UAV D2 at step S9, and the data transmission between D1 and D2 is cancelled.

[0112] - If the signature on STR2 is valid, there is no timeout, the proof PR1 is valid, and the verifiable data D2SVD conforms to the associated internal rules, the processing module of the benchmark UAV RD performs step S10: Records a signed transmission receipt STR2 (including proof PR1) containing data indicating that the first proof PR1 is valid and the verifiable data D2SVD conforms to the associated internal rules in the memory module; the processing module of the benchmark UAV RD further signs the transmission receipt STR2 to generate a signed transmission receipt STR3, stores the signed transmission receipt STR3 in the memory module, appends the signed transmission receipt STR3 to (decrypt) message M2 to generate message M3, encrypts message M3 using one of its private keys stored in the memory module, and the benchmark UAV RD performs step S11: forwards the encrypted message M3, including the signed transmission receipt STR3, to UAV D1 via its communication module, as in Figure 1 The above is represented by [M3+STR3]. The baseline UAV RD also performs step S12: (using one of its private keys stored in the memory module) encrypts the signed transmission receipt STR3, and forwards the encrypted signed transmission receipt STR3 (such as...) to UAV D2 via its communication module. Figure 1 (as shown in [STR3]), thus instructing D2 that the verifiable data D2SVD (stored separately in D2's memory) must be deleted.

[0113] When the communication unit of UAV D1 receives the encrypted message [M3+STR3] with a signed transmission receipt from the reference UAV RD, the processing unit of UAV D1 performs step S13, that is,

[0114] The processing unit of D1 decrypts the encrypted message M3 using the public key of RD (stored in D1's memory) corresponding to the private key used by the reference UAV RD to encrypt message M3, and stores the (decrypted) signed transmission receipt STR3 in D1's memory; and

[0115] - Drone D1 includes the verifiable data D2SVD received in message M3 into its set of verifiable data D1VD (stored in D1's memory), thereby generating a new set of its verifiable data D1VD'. At this stage, as verified by the baseline drone RD, drone D1 has modified its set of verifiable data after drone D2 has indeed performed the required operation OP in the first message M1 sent by D1. Preferably, drone D1 also generates a proof that includes verifiable data D2SVD into its set of verifiable data and stores the generated proof in its memory.

[0116] When the communication unit of UAV D2 receives an error notification E2 from the reference UAV RD at step S9, the processing unit of UAV D2 performs step RES: restoring the separately stored verifiable data D2SVD to its set of verifiable data (and then deleting the separately stored verifiable data D2SVD), thereby retrieving the original set of its verifiable data D2VD. Therefore, only the original set of verifiable data D2VD is retained in D2's memory (data transfer between D1 and D2 failed, so operation OP was not executed).

[0117] When the communication unit of UAV D2 receives the encrypted and signed transmission receipt STR3 sent by the communication module of the reference UAV according to step S12, the processing unit of UAV D2:

[0118] - Using the public key of RD (stored in D2's memory) corresponding to the private key used by the reference drone RD to encrypt the signed transmission receipt STR3, the encrypted signed transmission receipt STR3 is decrypted, thereby authenticating the reference drone RD as the sender of the signed transmission receipt STR3, and storing the signed transmission receipt STR3 in D2's memory; and

[0119] - The processing unit of UAV D2 performs step DEL: deleting the selected verifiable data D2SVD stored separately in D2's memory (the "busy zone" of the memory is deleted), thereby updating D2's memory state by storing only the (modified) set of verifiable data D2VD' in its memory, and indicating that the data transfer between D1 and D2 has been successful and the operation OP has been executed accordingly. Furthermore, UAV D2 generates proof of this deletion of the separately stored D2SVD and stores the generated proof in its memory.

[0120] If D2 does not perform the aforementioned step DEL of deleting the separately stored verifiable data D2SVD in its memory, the benchmark drone RD will immediately detect the anomaly when D2 must perform further operations (e.g., via communication with another drone). This is because the "initial" storage (i.e., the original D2VD, before data exchange with D1) in the "normal interval" of the set of D2's verifiable data indicating D2VD', plus the separately stored D2SVD, will contradict D2's storage state according to the previously signed transmission receipt STR2 containing proof PR1, where proof PR1 indicates that the new "normal interval" must correspond only to the set of stored verifiable data D2VD' (i.e., the final approved storage state according to the proof generated by D2 and stored in its memory). Because D2 delivers (and stores) signed transmission receipts with proofs (for each operation), the benchmark drone can immediately detect any inconsistency between consecutive proofs delivered by D2 (or any other drone). Therefore, the set of verifiable data used for further operations must contain verifiable data D2VD' instead of verifiable data D2VD in the new normal storage area of ​​D2's memory. Consequently, the baseline drone will cancel any further data transfers between D2 and the other drone. Therefore, the erroneous storage state of D2's verifiable data will not propagate the error via transfers to other drones.

[0121] In a preferred variant of the invention, the processing unit of the corresponding UAV Di (i=1,…,N) and the processing module of the baseline UAV RD are adapted to compute the hash value of the data using a programmed hash function H (e.g., a function of the SHA "secure hash algorithm" class, such as the SHA-256 hash function). In this variant, the UAV is able to provide strong proof of operation execution and clearly represent the corresponding changes in the stored verifiable data. According to this variant, for each verifiable data VDi(k) (k=1,…,p) of the UAV Di (i=1,…,N), that is, for each corresponding operation parameter data value and associated internal rule, there exists an associated leaf node Ai(1,k) (k=1,…,p) of a Merkle tree, which is stored in the memory of the UAV (see references

[15] or

[16] ). The leaf node values ​​Ai(1,k) of the Merkle tree for UAV Di are obtained by hashing the verifiable data VDi(k) associated with the leaf node using a hash function H: Ai(1,k) = H(VDi(k)) (k = 1, ..., p). The Merkle tree for UAV Di also includes intermediate nodes, which are set at consecutive intermediate levels up to the root node Ri (the basic level corresponds to the level of the leaf nodes). Each intermediate node value is obtained by hashing the node values ​​of the previous level according to the Merkle tree's regular hashing scheme: for example, the node Ai(2,1) of level 2 (i.e., the level below the leaf node level of the tree) is obtained as Ai(2,1) = H(Ai(1,1)+Ai(1,2)) = H(H(VDi(1))+H(VDi(2))) (where the symbol "+" indicates the concatenation of data)), the next node Ai(2,2) of level 2 is obtained as Ai(2,2) = H(Ai(1,3)+Ai(1,4))= H(H(VDi(3))+H(VDi(4))), and so on. The root node value Ri (i.e., the root value of the tree) is obtained as the concatenation hash of the two node values ​​of the penultimate level of the tree. Due to the concatenation and hashing involved in the tree, it is practically impossible to recalculate the correct root node value if any bit of the digital data has changed in a node (especially in a leaf node). The Merkle tree, as a representation of the verifiable data DiVD (DiVD={VDi(k); k=1,…,p}) of the UAV, is stored in the UAV's memory. According to the standard verification scheme for Merkle trees, a "verification path" consisting only of leaf node values ​​and a small number of intermediate node values ​​(from the second level to the penultimate level of the tree) is sufficient to retrieve the root value using a hash function (depending on the hashing scheme). Therefore, the root node value Ri can ultimately be retrieved from any given leaf node value by hashing that leaf node value only with the concatenation of intermediate node values ​​that constitute the corresponding verification path.The specific intermediate nodes that must be used in the verification path to retrieve the root value can be identified based on the hashing scheme of the Merkle tree. Therefore, the amount of data required to retrieve the root node value in the verification path is significantly less than the amount of data required to compute the baseline root node value based solely on the leaf node values ​​(i.e., by computed all non-leaf node values ​​in the intermediate layers of the tree).

[0122] A Merkle tree, representing the set of verifiable data for the UAV, is stored in the UAV's memory. The UAV's processing unit is adapted to modify the set of verifiable data stored in its memory as a representation of the UAV performing an operation using given verifiable data (corresponding to removing given verifiable data from the set of verifiable data):

[0123] - Select the leaf node of the stored Merkle tree associated with the given verifiable data to be removed from the set of stored verifiable data (i.e., the selected verifiable data).

[0124] Remove the selected leaf nodes from the Merkle tree.

[0125] - Replace the verifiable data corresponding to the removed leaf node with the corresponding placeholder data.

[0126] - Use a hash function to hash the placeholder data to obtain the corresponding placeholder leaf node values, and

[0127] - A new Merkle tree (representing the new storage of verifiable data removed from the "busy zone" of memory) is formed from the stored Merkle tree by replacing the selected leaf nodes with corresponding placeholder leaf nodes, obtaining the first part of the leaf nodes of the new Merkle tree, and then adjaculating the second part of the leaf nodes of the new Merkle tree from the selected leaf nodes by using a hash function according to a hash scheme to compute new intermediate nodes of the new Merkle tree up to the new root node with the first part and the second part of the leaf nodes. The obtained new Merkle tree is then stored in the device's memory and represents the removal and separate storage (via the second part of the leaf nodes) of the given verifiable data from the set of stored verifiable data of the UAV through the two-part structure of its leaf nodes. The second part of the leaf nodes, together with the intermediate nodes computed from these leaf nodes, actually represents the "busy zone" part of the new Merkle tree. The first part of the leaf nodes, together with the intermediate nodes computed from these leaf nodes, actually represents the new "normal zone" part of the new Merkle tree.

[0128] The drone's processing unit can then generate proof that the drone has performed an operation (OP) by sending a new root node value of the new Merkle tree (generated by removing and separately storing selected verifiable data from the drone's set of verifiable data) along with root verification data to a reference drone. This root verification data includes the values ​​of new placeholder nodes and new intermediate nodes in the new Merkle tree, values ​​that have been modified relative to the Merkle tree and are required to retrieve (i.e., recalculate) the new root value using a hash function according to a hash scheme. The reference device's processing module can then verify that the new root node value of the new Merkle tree received from the device, along with the corresponding root verification data (which serves as proof of the device's operation), does indeed match the test root node value calculated solely from the received root verification data, thus performing a further and stronger verification test that the device has performed an operation.

[0129] When specific verifiable data is included in the set of verifiable data stored in the UAV's memory as an initial Merkle tree (e.g., at step (S13) above), corresponding additional leaf nodes are added to the initial Merkle tree. The corresponding values ​​of the additional leaf nodes are calculated from the included specific verifiable data using a hash function, and the corresponding final Merkle tree is calculated from the values ​​of the leaf nodes of the initial Merkle tree and the values ​​of the additional leaf nodes according to a hash scheme. The resulting root node value of the final Merkle tree, together with the resulting root verification data, constitutes a proof (e.g., proof PR2) of including the specific verifiable data in the set of verifiable data of the UAV. The resulting root verification data includes the values ​​of the intermediate nodes and the values ​​of the additional leaf nodes of the final Merkle tree, which have been modified relative to the initial Merkle tree and are required to retrieve the root value of the final Merkle tree using a hash function according to a hash scheme. In this scenario, the processing module of the baseline UAV RD (or any UAV processing unit) can verify that the root node value of the final Merkle tree received from the UAV along with the corresponding root verification data (as proof of the UAV's operation) does indeed match the test root node value calculated solely from the received root verification data, thereby enabling further and stronger verification testing that the UAV has included specific verifiable data in its set of verifiable data.

[0130] In the case of deleting verifiable data corresponding to the separately stored leaf nodes of the new Merkle tree, an updated Merkle tree (no longer containing the separately stored leaf nodes) is obtained by using a hash function (according to the hashing scheme) to calculate the corresponding values ​​of its updated intermediate leaf nodes up to its updated root node only from the first part of the leaf nodes of the new Merkle tree. The updated root node value of the updated Merkle tree, together with the corresponding updated root verification data, constitutes proof of the deletion of the verifiable data. For any given leaf node value, the updated root verification data also includes the values ​​of the intermediate nodes of the updated Merkle tree, which have been modified relative to the new Merkle tree and are required to retrieve the root value of the updated Merkle tree using the hash function according to the hashing scheme. In this case, the processing module of the benchmark UAV can verify that the received updated root node value of the Merkle tree (as proof of the deletion of the verifiable data), together with the corresponding root verification data, does indeed match the test root node value calculated only from the received root verification data, thereby performing a further and stronger verification test that the UAV has deleted the separately stored verifiable data.

[0131] according to Figure 2 The preferred embodiment of the invention, illustratively illustrated in the above example of interconnected drones, still involves the devices (correspondingly drones) not communicating directly, but only via a reference device (correspondingly a reference drone). The devices and the reference device systematically verify the data exchanged between them and authenticate the device (owner) exchanging the data. This embodiment offers the advantage of providing improved security for data exchange, better reliability when operations are performed by the devices, and better protection against intruders transferring / damaging the exchanged data.

[0132] Figure 2This illustration schematically illustrates an example of secure data exchange between two specific drones (e.g., D1 and D2, owned by owners OW1 and OW2 respectively) controlled by a reference drone RD, for performing operations required to carry out a task, according to a preferred embodiment. Furthermore, the processing unit of drone D1 creates a message M1' for drone D2 using specified operation parameter data values ​​included in the corresponding transmission receipt TR1' along with first timestamp data TS1'. Message M1' contains data specifying the operation OP to be performed by D2. The processing unit of drone D1 then signs the transmission receipt TR1' (for the transmission of message M1') to generate a signed transmission receipt STR1', stores the signed transmission receipt STR1' in D1's memory, includes the signed transmission receipt STR1' in message M1', and encrypts message M1' using a private key selected from a private key set stored in D1's memory. UAV D1 then sends an encrypted message M1' with a corresponding signed transmission receipt STR1' to the reference UAV RD at step S1' (via its communication unit). Figure 2 The above is indicated by the symbol [M1'+STR1'] to begin the (S') exchange.

[0133] When the communication module of the reference UAV RD receives an encrypted message [M1'+STR1'] with a transmission receipt from D1, the processing module of the reference UAV RD performs step S2', which involves decrypting the encrypted message M1' using the public key of D1 (stored in the memory module of RD) corresponding to the private key used by the processing unit of the first UAV D1's owner OW1 to encrypt the message M1', thereby authenticating the owner OW1 of D1 as the sender of the received message (referred to as authenticating D1). The processing module of the reference UAV RD also verifies whether the signature on the received transmission receipt STR1' is valid (i.e., corresponding to the signature of UAV D1, the data integrity of the receipt STR1' is checked by using the decrypted signature of D1). The processing module of RD further verifies whether there is a timeout relative to the first timestamp data TS1' of the (decrypted) signed transmission receipt STR1', and

[0134] - In the event that authentication of the owner of D1 fails (i.e., decryption fails with any public key of OW1), or the signature on the transmitted receipt STR1' is invalid, or a timeout occurs relative to TS1', the reference drone RD sends an error message E1' to D1 via its communication module at step S3', and data transmission between D1 and D2 is canceled.

[0135] - If the authentication of OW1, the owner of D1, is successful (i.e., decryption is possible using the public key stored in the memory module of RD, which corresponds to OW1's private key used by D1 to encrypt message M1'), and the signature on the transmission receipt STR1' is valid (i.e., corresponding to D1's signature), and there is no timeout relative to the first timestamp data TS1', at step S4', the processing module of the reference UAV RD stores the signed transmission receipt STR1' in the memory module, includes the reference UAV timestamp RDTS' in the (decrypted) signed transmission receipt STR1' to generate a signed transmission receipt STR2', stores STR2' in the memory module, appends the signed transmission receipt STR2' to (decrypt) message M1' to generate message M2', encrypts message M2' using the private key stored in the memory module to generate an encrypted message M2', and at step S5', sends the encrypted message M2' including the signed transmission receipt STR2' to D2 via its communication module, as in Figure 2 The above is represented by [M2'+STR2'].

[0136] After the communication unit of D2 receives the encrypted message [M2'+STR2'] with the signed transmission receipt from the reference UAV RD, the processing unit of D2 performs step S6', namely:

[0137] - By decrypting the received message [M2'+STR2'] using RD's public cryptographic key (stored in D2's memory), the reference drone RD is authenticated as the sender of the received message. This public cryptographic key corresponds to the private key used by the reference drone owner RW to encrypt M2' by RD (this public key is part of RW's public key set stored in D2's memory).

[0138] - Verify that the signature on D1 of the (decrypted) signed delivery receipt STR2' is valid (indicating that D1 is the original sender of message M2'), and

[0139] - Whether there is no timeout relative to the first timestamp data TS1' of the received (and decrypted) signed transmission receipt STR2' and the baseline UAV timestamp data RDTS' in message M2'; then,

[0140] - If verification of RD (owner RW) as the sender of message M2' fails (i.e., decryption using any public key corresponding to the private key used by RW to encrypt M1' and generate M2'), or if the signature of D1 on the received signed transmission receipt STR2' is invalid, or if there is a timeout relative to the first timestamp data TS1' or the reference drone timestamp data RDTS' extracted from the decrypted signed transmission receipt STR2', D2 proceeds to step S7': sending a corresponding error notification E2' to the reference drone RD via its communication unit and canceling the data transmission with D1. When the error notification E2' is received from D2, the reference drone RD proceeds to step S8': forwarding the received error notification E2' to drone D1 via its communication module (thus notifying D1 that the data transmission with D2 has been canceled), and

[0141] - If D2 successfully authenticates the owner RW of the reference drone RD (i.e., simply, D2 authenticates the sender RD of message M2'), and the signature on the signed transmission receipt STR2' is valid, and there is no timeout relative to the timestamp data TS1' and the reference drone timestamp data RDTS', D2 stores the signed transmission receipt STR2' in its memory and proceeds to step S9', i.e.

[0142] The processing unit of D2 selects verifiable data D2SVD' from its stored set of verifiable data D2VD, wherein the operation parameter data value of verifiable data D2SVD' matches the specified operation parameter data value received in the (decrypted) signed transmission receipt STR2' of message M2', and (possibly) updates the internal rules associated with the selected verifiable data D2SVD'. The UAV D2 then performs operation OP by using these selected verifiable data D2SVD'.

[0143] Once the operation OP is executed by D2, D2's processing unit removes selected verifiable data D2SVD' from its set of verifiable data D2VD' and stores these selected verifiable data D2SVD'' (including associated updated internal rules) separately in its memory. This separate storage of the selected verifiable data D2SVD' corresponds to the storage of said D2SVD' in the "busy zone" of memory. D2's processing unit then generates proof PR1 for the removal and separate storage of the selected verifiable data (because D2 performed the operation OP based on D2SVD'). Preferably, PR1 is proven to be the stored Merkle tree representation of the set of verifiable data of D2, as described above. PR1 is, (generated by removing and separately storing the selected verifiable data D2SVD' from the Merkle tree representation of the set of verifiable data D2VD of UAV D2) the new root node value of the new Merkle tree, and the root verification data, which includes the values ​​of the new placeholder nodes and new intermediate nodes of the new Merkle tree. These values ​​have been modified relative to the values ​​of the Merkle tree and are required to retrieve the new root value using a hash function according to the hash scheme of the Merkle tree. Then, the processing unit of UAV D2:

[0144] - The generated proof PR1 and second timestamp data TS2' (i.e., D2 timestamp data) are included in the (decrypted) signed transmission receipt STR2', and the signed transmission receipt is further signed to generate a signed transmission receipt STR3', and STR3' is stored in the memory of D2.

[0145] - The selected verifiable data D2SVD' (including any associated internal rules that may be updated) along with the signed transmission receipt STR3' are incorporated into message M2' to produce message M3', and

[0146] - Encrypt message M3' using one of the private keys stored in the memory of D2.

[0147] Then, UAV D2 performs step S10': sending an encrypted message M3' (including a signed transmission receipt STR3') to the base UAV RD via its communication unit. This is in Figure 2 It is shown as [M3'+STR3'].

[0148] When the communication module of the reference UAV RD receives the encrypted message [M3'+STR3'] with a signed transmission receipt from D2, the processing module of the reference UAV RD performs step S11', namely:

[0149] - By successfully decrypting the received message M3' using the following public cryptographic key of D2, D2 (owner OW2) is authenticated as the sender of the received message [M3'+STR3'], which corresponds to the private key used by D2's processing unit to encrypt M3' (the public key is part of the UAV's public key set stored in RD's memory module).

[0150] - Verify whether the signature on the signed transmission receipt STR3' is valid (i.e., the signatures of D1 and D2 are valid), and whether there is no timeout relative to the first timestamp data TS1', the reference UAV timestamp data RDTS', and the second timestamp data TS2' indicated in the (decrypted) signed transmission receipt STR3';

[0151] - Verify the validity of proof PR1 and whether the selected verifiable data D2SVD' received from the drone D2 (decrypted) conforms to the corresponding associated (potentially updated) internal rules; then,

[0152] In the event that the signature on STR3' is invalid, or there is a timeout relative to TS1', RDTS', or TS2', or the first proof PR1 is invalid, or the received selected verifiable data D2SVD' does not conform to the associated internal rules, the reference drone RD sends a corresponding error notification E3' to drone D1 via its communication module at step S12' and to drone D2 at step S13', and the data transmission between D1 and D2 is cancelled.

[0153] - If the signatures on the (decrypted) signed transmission receipt STR3' are valid, there is no timeout (relative to TS1', RDTS', and TS2'), the first proof PR1 is valid, and the received selected verifiable data D2SVD' conforms to the associated internal rules, the processing module of the reference UAV RD performs step S14': records the signed transmission receipt STR3' (including proof PR1) and data indicating that proof PR1 is valid and the received selected verifiable data D2SVD' conforms to the associated internal rules in its memory module; encrypts the (decrypted) message M3' using the private key stored in the memory module to generate an encrypted message M4'; and the reference UAV performs step S15': forwards the encrypted message M4' (including the signed transmission receipt STR3') to UAV D1 via its communication module, as in Figure 2 The above is represented by [M4'+STR3'].

[0154] When the communication unit of UAV D1 receives the encrypted message [M4'+STR3'] with a signed transmission receipt from the reference UAV RD, the processing unit of UAV D1 performs step S16', that is,

[0155] The processing unit of D1 uses the following public key of the reference drone RD (stored in the memory of D1) to decrypt the encrypted message M4'. This public key corresponds to the private key of RW used by the reference drone RD to encrypt the (decrypted) message M3' (thus generating the encrypted message M4'), thereby authenticating the reference drone RD as the sender of message M4'.

[0156] - Verify that the signatures (D1 and D2) on the transmission receipt STR3' are valid, and that there are no timeouts relative to the timestamp data TS1', RDTS', and TS2' in the (decrypted) signed transmission receipt STR3' of the (decrypted) message M4'; and

[0157] - If the signature on STR3' is invalid or a timeout occurs (relative to TS1', RDTS', or TS2'), UAV D1 sends a corresponding error notification E4' to the base UAV RD via its communication unit at step S17', indicating that data transmission with UAV D2 is canceled, and at step S18', the base UAV RD forwards the error notification E4' to UAV D2 (thus informing D2 that data transmission with D1 is canceled); and

[0158] -If the signatures on the signed transmission receipt STR3' are all valid and there is no timeout (relative to TS1', RDTS', and TS2'), the processing unit of UAV D1 stores the signed transmission receipt STR3' in D1's memory at step S19', and modifies the set of verifiable data D1VD stored in its memory to generate and store a new set of verifiable data D1VD' including the selected verifiable data D2SVD' received from UAV D2 (the change in the set of verifiable data D1VD is due to the execution of operation OP by D2).

[0159] The processing unit of D1 then generates proof PR2, which includes D2SVD' into its stored set of verifiable data. Given that the set of stored verifiable data D1VD is represented by an "initial" Merkle tree (as described above) stored in D1's memory, the new set of verifiable data for D1 (after including D2SVD') is represented by a "final" Merkle tree, which has additional leaf nodes computed using a Merkle tree hash function from the included selected verifiable data D2SVD'. Based on the Merkle tree hash scheme, the final Merkle tree is computed from the values ​​of the leaf nodes of the initial Merkle tree and the values ​​of the additional leaf nodes. The resulting root node value of the final Merkle tree, together with the resulting root verification data, constitutes proof PR2, which includes the selected verifiable data D2SVD' into the set of verifiable data for D1.

[0160] The processing unit of D1 then incorporates the generated proof PR2 into the (decrypted) signed transmission receipt STR3' to generate a signed transmission receipt STR4', and stores STR4' in D1's memory. It then removes the selected verifiable data D2SVD' from the (decrypted) message M4' and appends the signed transmission receipt STR4' to the message, thereby generating message M5'. The processing unit of D1 then encrypts message M5' using the private key stored in D1's memory. At step S20', UAV D1 sends the encrypted message M5' (including the signed transmission receipt STR4') to the base UAV RD via its communication unit, as follows... Figure 2 As shown in [M5'+STR4'], this indicates to the reference UAV RD that UAV D1 has included the received D2SVD' into its set of verifiable data.

[0161] When the communication module of the reference UAV RD receives the encrypted message [M5'+STR4'] with a signed transmission receipt, the processing module of the reference UAV RD performs step S21', that is,

[0162] - By decrypting the received encrypted message M5' using the following public cryptographic key of D1, D1 (its owner OW1) is authenticated as the sender of the received message [M5'+STR4']. This public cryptographic key corresponds to the private key used by D1 to encrypt message M5' (this public key is part of the UAV's public key set stored in RD's memory module).

[0163] - Verify that the signature on the signed delivery receipt STR4' is valid.

[0164] - Verify that there is no timeout relative to the received timestamp data TS1', RDTS', and TS2' (in the decrypted signed transmission receipt STR4' of decrypted message M5'); and

[0165] - Verify (in STR4') whether the received proof PR2 is valid; then,

[0166] - If the signature on STR4' is invalid, or if there is a timeout relative to the timestamp data TS1', RDTS', or TS2' in the (decrypted) signed transmission receipt STR4', or if the included proof PR2 is invalid, the reference drone RD sends a corresponding error notification E5' to drone D1 via its communication module at step S22' and to drone D2 at step S23', and the data transmission between D1 and D2 is cancelled; and

[0167] - If the signature on STR4' is valid, there is no timeout relative to TS1' and RDTS' and TS2', and the included proof PR2 is valid, the processing module of the reference UAV RD performs step S24': records the signed transmission receipt STR4' (with the included proof PR2) and data indicating that the included proof PR2 is valid in its memory module, encrypts the (decrypted) message M5' using the private key stored in the memory module to generate an encrypted message M6', and performs step S25': sends the encrypted message M6' (including the signed transmission receipt STR4') to the UAV D2 via its communication module, as shown in Figure 2 The above is represented by [M6'+STR4'].

[0168] When the communication unit of UAV D2 receives the encrypted message [M6'+STR4'] with a signed transmission receipt sent by the reference UAV RD according to step S25', the processing unit of D2 performs step S26': decrypting message M6' using the public key (stored in D2's memory) corresponding to the private key used by the reference UAV RD to encrypt message M6', verifying whether the signature on the transmission receipt STR4' (in decrypted message M6') is valid and whether there is a timeout relative to TS1', RDTS', and TS2' (in the decrypted signed transmission receipt STR4' of message M6'), and whether the received proof PR2 (in STR4') is valid, and,

[0169] If the signature on STR4' is invalid, or there is a timeout relative to TS1' or RDTS' or TS2', or the received proof PR2 is invalid, UAV D2 sends a corresponding error notification E6' to the reference UAV RD via its communication unit at step S27', data transmission with D1 is canceled, and the reference UAV RD forwards the error notification E6' to UAV D1 at step S28'.

[0170] -If the signature on STR4' is valid and there is no timeout (relative to TS1', RDTS', and TS2'), and the received proof PR2 is valid, then UAV D2 stores the signed transmission receipt STR4' (including proof PR2) in its memory and proceeds to step S29', i.e.

[0171] The processing unit of D2 deletes the selected verifiable data D2SVD' stored separately in its memory (only a new set of verifiable data D2VD' is retained in D2's memory), generates proof of the deletion PR3, incorporates the generated proof PR3 into the (decrypted) signed transmission receipt STR4' to generate a signed transmission receipt STR5', stores the signed transmission receipt STR5' in D2's memory, appends the signed transmission receipt STR5' to message M6' to generate message M7', encrypts message M7' using the private key stored in D2's memory to generate encrypted message M7', and sends the encrypted message M7' (including the signed transmission receipt STR5') to the reference UAV RD via its communication unit at step S30'. Figure 2 The above is shown as [M7'+STR5'].

[0172] When the set of verifiable data for the stored UAV D2 (with separately stored selected verifiable data D2SVD') is represented as a "new" Merkle tree (as described above), the deletion of the separately stored selected verifiable data D2SVD' (in the "busy interval" section) corresponding to the separately stored leaf nodes of the new Merkle tree creates an updated Merkle tree. This updated Merkle tree is obtained by calculating the corresponding values ​​of its updated intermediate leaf nodes up to its updated root node from only the first part of the leaf nodes of the new Merkle tree (calculated using a hash function according to the Merkle tree's hashing scheme). The updated root node value of the updated Merkle tree, together with the corresponding updated root verifiable data, constitutes proof of the deletion of the selected verifiable data D2SVD'.

[0173] When the communication module of the reference UAV RD receives the encrypted message [M7'+STR5'] with a signed transmission receipt sent by D2 according to step S30', the processing module of the reference UAV RD performs step S31', that is,

[0174] - Decrypt message M7' using the public key corresponding to the private key used by D2 to generate encrypted message M7';

[0175] - Verify that the signature on the signed delivery receipt STR5' is valid, that there is no timeout relative to the timestamp data TS1', RDTS', and TS2' in the decrypted signed delivery receipt STR5' (of the decrypted message M7'), and that the deletion proof PR3 (in STR5') is valid.

[0176] - In the event that the signature on the signed transmission receipt STR5' is invalid, or there is a timeout relative to TS1', RDTS', or TS2', or the deletion proof PR3 is invalid, the reference UAV RD sends a corresponding error notification E7' to D1 via its communication module at step S32' and at step S33', and the data transmission between D1 and D2 is cancelled; and

[0177] -If the signature on the signed transmission receipt STR5' is valid, there is no timeout relative to the timestamp data TS1' and RDTS' and TS2', and the deletion proof PR3 is valid, the processing module of the baseline UAV RD proceeds to step S34':

[0178] - Record in its memory module a signed transmission receipt STR5' (including proof PR3) and data indicating that the UAV D2 has deleted the selected verifiable data D2SVD' stored separately from its memory.

[0179] - Further sign the signed transmission receipt STR5' to generate a signed transmission receipt STR6', and store the signed transmission receipt STR6' in the memory module.

[0180] - Encrypt the signed transmission receipt STR6' using the private key stored in the memory module; and

[0181] The baseline UAV RD forwards the encrypted, signed transmission receipt STR6' to D1 at step S35' and to D2 at step S36' via its communication module. Figure 2The above is symbolically represented by [STR6']. The signed transmission receipt STR6' is a triple-signed receipt: it is signed by D1, D2, and RD. In this embodiment, only the triple-signed transmission receipt can ensure that the operation OP has been successfully executed.

[0182] Therefore, the operation OP, the transmission of the corresponding selected verifiable data D2SVD' to D1 and its inclusion in the set of verifiable data to D1, and the resulting deletion of the selected verifiable data D2SVD' from D2's memory have been performed and fully verified by the baseline UAV RD. Data exchange between UAVs has been minimized, protected by data encryption, signatures and timestamps of transmission receipts, and strictly contingent on the execution of the operation OP required for the assigned task. Furthermore, critical data related to the verifiable credentials of the UAV owner has not been exchanged (and therefore, it is impossible to transfer and use it to compromise the owner), and data exchange between UAVs has been implemented in offline mode (i.e., without communication with multiple entities outside the UAVs, such as servers). At this stage, the baseline UAV RD knows that the new "final" storage state of the set of verifiable data for D2 must correspond to D2VD', and the "old" storage state corresponding to D2VD must be deleted from D2's memory. If D2 fails to delete the selected verifiable data D2SVD' separately stored in its memory at step S29', the reference drone RD immediately detects the anomaly from the received proof PR3. The initial storage state of D2's set of verifiable data (i.e., D2VD) will contradict D2's storage state according to proof PR3, which is included in the signed transmission receipt STR5' delivered by D2 and stored in the reference drone's memory module, thus indicating that the new initial storage state must actually correspond to the set of verifiable data D2VD', i.e., the new initial storage state of the set of verifiable data for further operations must be D2VD' instead of D2VD. Therefore, the reference drone will cancel any further data transmission between D2 and other drones. Thus, the erroneous storage state of D2's set of verifiable data will not propagate the error via transmissions with other drones and will not disrupt the correct execution of the mission.

[0183] When the communication unit of UAV D2 receives an error message E3' from the reference UAV RD at step S13', or an error message E4' from RD at step S18', or an error message E5' from RD at step S23', the processing unit of UAV D2 performs step RES': moves the separately stored selected verifiable data D2SVD' back to its set of verifiable data (i.e., restores the initial set D2VD), and deletes the selected verifiable data D2SVD' separately stored in its memory (i.e., in the "busy zone" of the memory), so that only the initial set of verifiable data D2VD remains in D2's memory (i.e., as in the "initial normal zone" of the memory). In these cases, data transmission between D1 and D2 fails, and therefore operation OP is not executed.

[0184] In a variation of the above embodiment, still exemplified by interconnected drones collaborating to perform a given task, the security level is further improved by allowing the drones (and the baseline drone) to further verify whether the drone owners have properly registered with the authorized entity. In this variation, each drone can also communicate (via a communication network) with an Identity Server (IS), a Hosting Server (ES), and a Governance Server (GS). The Identity Server (IS) can deliver a unique identifier to a drone owned by a registered user, the Hosting Server (ES) can deliver verifiable credentials to a drone owned by a registered user, and the Governance Server (GS) can deliver a one-time-use identity token to a drone owned by a registered user. The possibility of any drone (including the baseline drone) interrogating another drone to prove that the owner of that other drone has registered with the GS (as well as the IS and ES) significantly improves the security of operational execution by preventing any malicious intrusion into the data exchange required to ensure the execution.

[0185] Therefore, according to this variant:

[0186] - Each DID of the drone owner is associated with a corresponding unique identifier (UID) for that owner, which has been delivered by the Identity Server (IS) in response to the drone owner’s one-time registration settings with the Identity Server (IS).

[0187] - Each drone (including the base drone) is adapted to communicate with the hosting server ES via a communication network during the setup phase, and each drone owner can perform a one-time registration setup with the hosting server ES by sending a request via the drone to the hosting server ES containing its unique identifier UID and a cryptographic commitment to the drone's link secret.

[0188] - Upon receiving a request, the hosting server Elasticsearch creates an entropy test vector (ETV) and a corresponding asymmetric encryption key pair (OK) for the byte block generated by the random number generator. pub OK priv ), to determine by first using the private key OK priv Encrypt the received unique identifier UID, and then use the private key OK. priv The corresponding shielded configuration file (SP) is obtained by encrypting the entropy test vector and the encrypted unique identifier UID, and the resulting triple (OK) is stored. pub (,SP,UID), and delivers a triple (OK) to the requesting drone. pub Anonymous verifiable credentials C, including SP, UID, and a cryptographic commitment to the link secret of the drone. ES The two-layer encryption of the unique identifier (UID) allows for partial or partial decryption. Partial decryption allows the hosting server, Elasticsearch, to reveal portions of the data used for internal analysis without simultaneously exposing the rest of the encrypted data. This makes it much more difficult to spy on the hosting server.

[0189] The hosting server ES is adapted to communicate with the identity server IS via a communication network and request the identity server IS to confirm that the unique identifier UID received by the hosting server from the drone is indeed owned by the drone's owner. Each drone (including the base drone) is adapted to communicate with the governance server GS via a communication network, and each drone owner can initiate a one-time registration setup with the governance server GS by first establishing a session with the governance server GS via their drone. During this session, the drone uses a temporary DID and the governance server GS is authenticated. The governance server GS then challenges the drone to generate proof of its owner's registration with the hosting server ES, and in response, the drone generates an anonymous verifiable credential C delivered by the hosting server ES. ES The drone provides proof of its identity and sends that proof to the governance server GS. Upon receiving the proof from the challenged drone, the governance server GS delivers multiple one-time use identity tokens and corresponding verifiable credentials C to the drone. GS Each delivered single-use identity token (SUIT) is a public key that can be used to locate the drone. pub The string, the verifiable credential C delivered. GS It includes a field for each delivered single-use identity token (SUIT) and a cryptographic commitment to the drone's link secret.

[0190] In the case where drone Di among multiple drones Di (i=1,…,N) communicates with another drone Dj (j≠i) among the multiple drones by using a DID that has never been seen before:

[0191] - Drone Dj then questioned Drone Di in order to reveal the corresponding verifiable credential C. GS One of the single-use identity tokens (SUIT) delivered by the governance server GS to the drone Di in i is used to prove that the owner of the drone Di, OWI, has registered with the governance server GS.

[0192] In response, the drone Di generates a verifiable credential C that reveals one of the corresponding one-time use identity tokens SUIT (e.g., SUITi). GS Zero-knowledge proofs (ZKP), and

[0193] - Drone Dj records the revealed single-use identity token SUITi in a signed delivery receipt STR generated by drone Di.

[0194] Therefore, by utilizing the aforementioned registration of drone owners (including the owner of the baseline drone) with the identity server IS, hosting server GS, and governance server GS, and by using any drone (including the baseline drone) to question another drone to check the likelihood that the owner of the other drone is correctly registered, any intrusion by a fake owner during the drone's operation (without revealing the owner's key data) is prevented, and tasks assigned to drones can be performed with maximum security.

[0195] Based on the aforementioned control system using the Identity Server (IS), Hosting Server (ES), and Governance Server (GS), the risk of data leakage regarding the owner of the challenged drone D during the aforementioned data exchange is minimized as follows:

[0196] -IS is unaware of the drone D's SUIT and credentials C. ES Verifiable credential C GS Temporary DID, and it is unknown whether the D is exchanged with other drones;

[0197] -ES doesn't know about the drone D's SUIT, C ES C GS Temporary DID, and the exchange between D and other drones is unknown; and

[0198] -GS does not know the UID of drone D (GS only knows D's SUIT and OK). pub ).

[0199] It can also include an audit server (AUD) responsible for monitoring data exchanges between drones and their internal rules against some stored data operation rules (OpRs). In this case, each drone (including the baseline drone) must store its history of (encrypted) data exchanges with other drones during tasks that can be audited by the audit server AUD.

[0200] This invention can be used in many other contexts besides the (non-limiting) examples described above, such as drones and IoT. For example, the first device could be a smartphone owned by someone with a digital wallet, and the second device could be another smartphone owned by someone else with a corresponding digital wallet, and verifiable data could represent digital cash in the wallet (operational parameter data values ​​representing the face value of banknotes). The invention can then protect the operation of transferring cash between wallets via smartphones. Furthermore, multiple reference devices can be included to control the execution of the operation by the devices.

[0201] The subject matter disclosed above is intended to be illustrative rather than restrictive and is intended to provide a better understanding of the invention as defined in the independent claims.

[0202] References

[0203] [1] M. Sabt, M. Achemlal, A. Bouabdallah: “Trusted ExecutionEnvironment: Wat It is, and What It is Not”, 14th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, August 2015, Helsinki, Finland.

[0204] [2] https: / / en.wikipedia.org / wiki / Trusted_execution_environment (edited on 15 November 2020 at 13:04 (UTC)).

[0205] [3] From Crypto Wiki: cryptowiki.net / index.php?title=Protocols_for_secure_communication_channels (December 27, 2014, 21:54).

[0206] [4] S. Goldwasser, M. Bellare: “Lecture Notes on Cryptography”, July 2008: http: / / www.cs.tufts.edu / comp / 165 / papers / Goldwasser-Bellare-notes-cryptography.pdf

[0207] [5] https: / / en.wikipedia.org / wiki / Digital_signature (edited on 14 December 2020 at 00:29 (UTC)).

[0208] [6] https: / / en.wikipedia.org / wiki / Blind_signature (edited January 4, 2020 at 18:21 (UTC)).

[0209] [7] D. Chaum, EUROCRYPT '90: Proceedings of the workshop on theory and application of cryptographic techniques on Advances in cryptology, February 1991, pp. 458–464.

[0210] [8] Wikipedia. "Signatures with efficient protocols", https: / / en.wikipedia.org / wiki / Signatures_with_efficient_protocols (edited on 14 December 2020 at 02:13 (UTC)).

[0211] [9] Goldwasser S., Ostrovsky R. (1993) Invariant Signatures and Non-Interactive Zero-Knowledge Proofs are Equivalent. In: Brickell E.F. (eds)Advances in Cryptology — CRYPTO’ 92. CRYPTO 1992. Lecture Notes in ComputerScience, vol 740. Springer, Berlin, Heidelberg. https: / / doi.org / 10.1007 / 3-540-48071-4_16。

[0212]

[10] Camenisch J., Lysyanskaya A. (2003) A Signature Scheme withEfficient Protocols. In: Cimato S., Persiano G., Galdi C. (eds) Security inCommunication Networks. SCN 2002. Lecture Notes in Computer Science, vol2576. Springer, Berlin, Heidelberg. https: / / doi.org / 10.1007 / 3-540-36413-7_20。

[0213]

[11] Knox, D.A. and Adams, C. "Digital credentials with privacy-preserving delegation", first published on July 15, 2011, https: / / doi.org / 10.1002 / sec.213, see https: / / onlinelibrary.wiley.com / doi / full / 10.1002 / sec.213).

[0214]

[12] https: / / en.wikipedia.org / wiki / Hardware_security_module (edited on November 20, 2022, 20:18 (UTC)).

[0215]

[13] https: / / en.wikipedia.org / wiki / Decentralized_identifier (November 6, 2022, 19:48 (UTC)) edit; or https: / / www.w3.org / TR / did-core / (July 19, 2022).

[0216]

[14] https: / / en.wikipedia.org / wiki / Verifiable_credentials (edited 9 October 2022 at 2:20 PM (UTC)); or https: / / www.w3.org / TR / vc-data-model / (3 March 2022).

[0217]

[15] https: / / en.wikipedia.org / wiki / Merkle_tree (edited 24 November 2022 at 08:58 (UTC)).

[0218]

[16] US 4,309,569 (Published January 5, 1982).

[0219]

[17] https: / / github.com / hyperledger-archives / indy-anoncreds.

[0220]

[18] https: / / github.com / w3c-ccg / chapi-interop-test-suite.

Claims

1. A method for controlling and cooperating multiple devices via a reference device to perform a task, each device being owned by a corresponding owner, each device being equipped with a processing unit, a memory, and a communication unit, and adapted to perform operations required to perform the task, wherein the memory of each device stores: a set of corresponding private keys of the device owner; a distributed identifier (DID) of the device owner associated with a set of public cryptographic keys corresponding to the private keys; a programming method adapted to run on the processing unit of the device to authenticate other devices and the reference device; a set of public cryptographic keys of the other devices; a set of verifiable data; and verifiable credentials of the device owner, wherein each set of verifiable data includes corresponding operational parameter data values ​​and associated internal rules required to perform the task, and the device's... The communication units are adapted to communicate securely with each other via a wireless or wired communication network. The reference device is equipped with a processing module, a memory module, and a communication module, and is adapted to communicate securely with the communication units of each device via the wireless or wired communication network. The reference device and the devices are adapted to transmit data using an encryption protocol. The memory module of the reference device stores a set of corresponding private keys of the reference owner of the reference device, corresponding distributed identifier data (DID) associated with a set of public cryptographic keys corresponding to the private keys of the reference device, and a set of public cryptographic keys of each of the plurality of devices. The reference device and each device are adapted to digitally sign the transmitted receipt using their corresponding stored private keys, and the memory of each device also stores the set of public cryptographic keys of the reference device. The method is characterized in that: - Data transmissions between any two devices and between the reference device and any device are encrypted using a private key according to the encryption protocol, and any recipient of a message transmitted according to the encryption protocol authenticates the sender of the received message by decrypting the message using a public key corresponding to the private key used by the owner of the message sender to encrypt the message, and if the message includes a signed transmission receipt, the recipient also verifies whether each signature on the signed transmission receipt is valid. - Each signed transmission receipt sent or received by the device is stored in the memory of the device, and each signed transmission receipt sent or received by the reference device is stored in the memory module of the reference device. - Whenever the first device sends an encrypted message to the second device via its communication unit, possibly via the reference device, including a signed transmission receipt and indicating the use of a given operation parameter data value to be performed by the second device as part of the task, the signed transmission receipt includes the respective DIDs of the first device, the second device, and the reference device along with the given operation parameter data value; and, - When the second device receives the message by its communication unit, it decrypts the message, performs the operation using the operation parameter data value included in the signed transmission receipt in the received message, and the processing unit of the second device removes selected verifiable data whose operation parameter value matches the given operation parameter data value used to perform the operation from the set of verifiable data of the second device stored in the memory of the second device, and stores the selected verifiable data separately in the memory of the second device, generates a proof of the removal and separate storage of the selected verifiable data, and includes the generated proof in the signed transmission receipt, and the second device further signs the signed transmission receipt in the received decrypted message via its processing unit, and sends an encrypted message to the reference device via its communication unit, the encrypted message including the further signed transmission receipt together with the selected verifiable data; as well as - When the communication module of the reference device receives an encrypted message from the second device including the further signed transmission receipt along with the selected verifiable data, the reference device verifies whether the received proof in the received further signed transmission receipt is valid and whether the data of the received selected verifiable data conforms to the associated internal rules. as well as -In the event that the corresponding receiver and sender are successfully authenticated for any message transmission between the first device and the second device regarding the operation, and between either the first device or the second device and the reference device regarding the operation, and the data content of any transmitted message is successfully verified, the reference device further signs a transmission receipt signed by the first device and the second device and containing the proof generated by the second device, and stores it in the memory module of the reference device, and sends an encrypted message containing the further signed transmission receipt to the first device and the second device, thereby indicating to both devices that the operation has been performed; as well as - When the communication unit of the second device receives the transmission receipt further signed by the reference device, the second device deletes the selected verifiable data from the memory of the second device.

2. The method according to claim 1, wherein, The processing unit clock of each device is synchronized with the processing module clock of the reference device RD, and each device and the reference device RD are adapted to include timestamp data in the transmitted receipt and to verify whether there is a timeout relative to the timestamp data in the received transmitted receipt, wherein the operation as part of the task is performed according to the following steps: (A) A first device D1 sends a message to a second device D2 via the communication unit of the first device. The message is encrypted by the processing unit of the first device using one of the private keys of the first device stored in the memory of the first device. The message includes data indicating an operation OP to be performed by the second device D2 and a corresponding transmission receipt signed by the first device. The corresponding transmission receipt contains a given operation parameter data value to be used to perform the operation OP and a first timestamp data. (B) When the second device D2 receives an encrypted message from the first device D1, the processing unit of the second device decrypts the message using a public cryptographic key corresponding to the private key of the owner of the first device used to encrypt the message, or by using a shared symmetric key negotiated with the private key of the sender of the message, and verifies whether the signature on the received signed transmission receipt is valid, thereby authenticating the first device as the sender of the received message; and the processing unit of the second device verifies whether there is a timeout relative to the first timestamp data in the received signed transmission receipt; and, (B1) In the event of authentication failure of the first device D1, invalid signature on the signed transmission receipt, or timeout, the second device D2 sends a corresponding error notification to the reference device via its communication unit, data transmission with the first device D1 is cancelled, and the reference device RD forwards the received error notification to the first device D1; and (B2) If the authentication of the first device D1 is successful, the signature on the signed transmission receipt is valid, and there is no timeout, the processing unit of the second device D2 selects verifiable data D2SVD from the set of verifiable data D2VD stored in the memory of the second device D2, wherein the operation parameter data value matches the received given operation parameter data value. The processing unit of the second device D2 updates the internal rules of the selected verifiable data. The second device D2 performs the operation by using the selected verifiable data D2SVD, and the processing unit of the second device D2 retrieves the verifiable data D2VD from the set of verifiable data D2VD stored in the memory of the second device D2. The selected verifiable data D2SVD is removed from the set of D, and the selected verifiable data D2SVD, together with the updated associated internal rules, is stored separately in the memory of the second device D2. A proof PR1 for removing and separately storing the selected verifiable data D2SVD is generated. The selected verifiable data D2SVD is incorporated into the message. The generated proof PR1 and the second timestamp data are included in the signed transmission receipt. The transmission receipt is further signed, and the further signed transmission receipt is included in the message. The message is encrypted using one of the private keys of the second device D2, and the encrypted message is sent to the reference device RD. (C) When the communication module of the reference device RD receives a message from the second device D2, the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, verifies whether the signature on the transmission receipt is valid and whether there is a timeout relative to the first timestamp data and the second timestamp data, verifies whether the proof PR1 is valid and whether the received verifiable data D2SVD selected by the second device conforms to the corresponding associated internal rules; and (C1) In the event of an invalid signature, a timeout, an invalid proof PR1, or the received verifiable data D2SVD selected by the second device not conforming to the corresponding internal rules, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and (C2) If the signature is valid, there is no timeout, the proof PR1 is valid, and the received verifiable data D2SVD selected by the second device conforms to the corresponding internal rules, the processing module of the reference device RD includes the verifiable data D2SVD selected by the second device in the message, further signs the signed transmission receipt and appends the further signed transmission receipt to the message, encrypts the message using the private key stored in the memory module, sends the encrypted message to the first device D1, and the processing module of the reference device RD encrypts the further signed transmission receipt using the private key stored in the memory module and sends the encrypted further signed transmission receipt to the second device D2. (D) When the communication unit of the first device D1 receives a message from the reference device RD, the processing unit of the first device D1 decrypts the message using the public key corresponding to the private key used by the reference device RD to encrypt the message, and extracts the verifiable data selected by the second device from the message; and, (D1) The first device D1 modifies the set of first device verifiable data D1VD stored in the memory of the first device D1 by generating and storing a new set of first device verifiable data D1VD' including the extracted verifiable data D2SVD selected by the second device. (E) When the communication unit of the second device D2 receives an error notification sent by the reference device RD according to step (C1), the processing unit of the second device D2 transmits the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, to the set of verifiable data D2VD of the second device D2. (F) When the communication unit of the second device D2 receives the decryption and verification of the signature of the encrypted signed transmission receipt sent by the reference device RD according to step (C2), the processing unit of the second device D2 deletes the verifiable data D2SVD selected by the second device that is separately stored in the memory of the second device D2.

3. The method according to claim 1, wherein, The processing unit clock of each device is synchronized with the processing module clock of the reference device RD, and each device and the reference device RD are adapted to include timestamp data in the transmitted receipt and to verify whether there is a timeout relative to the timestamp data in the received transmitted receipt, wherein the operation as part of the task is performed according to the following steps: (A') The first device D1 sends a message to the reference device RD via the communication unit of the first device. The message is encrypted by the processing unit of the first device using one of the private keys of the first device stored in the memory of the first device. The message includes data indicating an operation OP to be performed by the second device D2 and a corresponding transmission receipt signed by the first device. The corresponding transmission receipt contains a given operation parameter data value to be used to perform the operation OP and a first timestamp data. When the communication module of the reference device RD receives an encrypted message from the first device D1, the processing module of the reference device RD decrypts the message using a public cryptographic key corresponding to the private key used by the owner of the first device D1 to encrypt the message, thereby authenticating the first device as the sender of the received message. The processing module of the reference device RD also verifies the validity of the signature on the received signed transmission receipt and whether there is a timeout relative to the first timestamp data in the signed transmission receipt; and... (A1') If authentication of the first device D1 fails, or the signature of the transmission receipt is invalid, or a timeout occurs, the reference device RD sends an error message to the first device D1 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and (A2') If the authentication of the first device is successful, the signature on the transmission receipt is valid, and there is no timeout relative to the first timestamp data, the processing module of the reference device RD includes the reference device timestamp RDTS in the signed transmission receipt, appends the signed transmission receipt to the message, encrypts the message including the signed transmission receipt using one of the private keys of the reference device RD stored in the memory module of the reference device RD, and sends the encrypted message to the second device D2 via the communication module of the reference device RD. (B') When the second device D2 receives an encrypted message from the reference device RD, the processing unit of the second device D2 decrypts the message using a public cryptographic key corresponding to the private key used by the owner of the reference device RD to encrypt the message, thereby authenticating the reference device RD as the sender of the received message, verifying whether the signature of the first device D1 on the received signed transmission receipt is valid, and whether there is a timeout relative to the first timestamp data of the signed transmission receipt and the reference device timestamp data in the message; and, (B1') In the event of authentication failure of the reference device RD, invalid signature on the signed transmission receipt, or timeout, the second device D2 sends a corresponding error notification to the reference device RD via its communication unit. The reference device RD forwards the received error notification to the first device D1, and data transmission with the first device D1 is cancelled; and (B2') If the authentication of the reference device RD is successful, the signature on the signed transmission receipt is valid, and there is no timeout, the processing unit of the second device D2 selects verifiable data D2SVD from the set of verifiable data D2VD stored in the memory of the second device D2, wherein the operation parameter data value matches the received given operation parameter data value. The processing unit of the second device D2 updates the internal rules associated with the selected verifiable data. The second device D2 performs the operation according to the selected verifiable data D2SVD, and the processing unit of the second device D2 retrieves the verifiable data D2VD from the set of verifiable data D2VD stored in the memory of the second device D2. Remove the selected verifiable data D2SVD from the set of D, and store the selected verifiable data D2SVD together with the updated associated internal rules separately in the memory of the second device D2. Generate a proof PR1 for the removal and separate storage corresponding to the execution of the operation OP. Incorporate the selected verifiable data D2SVD into the message. Include the generated proof PR1 and the second timestamp data in the signed transmission receipt. Further sign the signed transmission receipt and attach the further signed transmission receipt to the message. Encrypt the message using one of the private keys of the second device D2 and send the encrypted message to the reference device RD. (C') When the communication module of the reference device RD receives the message from the second device D2, the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, verifies whether the signature on the signed transmission receipt is valid and whether there is a timeout relative to the first timestamp data, the reference device timestamp data and the second timestamp data in the signed transmission receipt, verifies whether the proof PR1 in the signed transmission receipt is valid and whether the verifiable data D2SVD selected by the received second device conforms to the corresponding associated internal rules; and (C1') In the event of an invalid signature, a timeout, invalid proof of PR1, or the received verifiable data D2SVD selected by the second device not conforming to the associated internal rules, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and (C2') If the signature is valid, there is no timeout, the proof PR1 is valid, and the received verifiable data D2SVD selected by the second device conforms to the associated internal rules, the processing module of the reference device RD encrypts the message using the private key stored in the memory module and sends the encrypted message including the signed transmission receipt to the first device D1. (D') When the communication unit of the first device D1 receives the message and the signed transmission receipt from the reference device RD, the processing unit of the first device D1 decrypts the message using the public key corresponding to the private key used by the reference device RD to encrypt the message, verifies whether the signature on the signed transmission receipt is valid and whether there is a timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and extracts the verifiable data D2SVD selected by the second device from the decrypted message; and, (D1') If the signature on the signed transmission receipt is invalid or a timeout occurs, the first device D1 sends a corresponding error notification to the reference device RD via its communication unit. The reference device RD forwards the received error notification to the second device D2, and data transmission with the first device D1 is cancelled; and (D2') If the signature on the signed transmission receipt is valid and there is no timeout, the processing unit of the first device D1 modifies the set of first device verifiable data D1VD of the first device D1 stored in the memory of the first device D1 to generate a new set of first device verifiable data D1VD' including the extracted verifiable data D2SVD selected by the second device, and stores the new set into the set of first device verifiable data D1VD, generating such included proof PR2, removing the verifiable data D2SVD selected by the second device from the message, incorporating the generated included proof PR2 into the signed transmission receipt, encrypting the message using the private key stored in the memory of the first device D1, and forwarding the encrypted message including the signed transmission receipt to the reference device RD; and (D3') When the communication module of the reference device RD receives a message with the signed transmission receipt sent by the first device D1 according to step (D2'), the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the first device D1 to encrypt the message, and verifies whether the signature on the signed transmission receipt is valid, whether there is no timeout relative to the first timestamp data, the reference device timestamp data and the second timestamp data, and whether the proof PR2 included in the signed transmission receipt is valid; and (D4') In the event of an invalid signature, a timeout, or an invalid proof PR2, the reference device RD sends a corresponding error notification to the first device D1 and the second device D2 via its communication module, and data transmission between the first device D1 and the second device D2 is cancelled; and (D5') If the signature is valid, there is no timeout, and the included proof PR2 is valid, the processing module of the reference device RD encrypts the message using a private key from the private key set stored in the memory module, and forwards the encrypted message to the second device D2 via the communication module. (E') When the communication unit of the second device D2 receives an error notification sent by the reference device RD according to step (C1'), the processing unit of the second device D2 transmits the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, to the set of verifiable data of the second device D2. (F') When the communication unit of the second device D2 receives the message with a signed transmission receipt forwarded by the reference device RD according to step (D5'), the processing unit of the second device D2 decrypts the message using the public key stored corresponding to the private key used by the reference device RD to encrypt the message, and verifies whether the signature on the transmission receipt is valid, whether there is no timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and whether the included proof PR2 is valid; and (F1') In the event of an invalid signature, a timeout, or an invalid received proof PR2, the second device D2 sends a corresponding error notification to the reference device RD via its communication unit, data transmission to the first device D1 is cancelled, and the reference device RD forwards the error notification to the first device D1; and (F2') If the signature is valid, there is no timeout, and the received proof PR2 is valid, the second device D2 deletes the verifiable data D2SVD selected by the second device, which is separately stored in the memory of the second device D2, further generates proof PR3 for the deletion, incorporates the generated proof PR3 into the signed transmission receipt, encrypts the message including the signed transmission receipt using one of the private keys of the second device D2, and forwards the encrypted message to the reference device RD; and (G') When the communication module of the reference device RD receives a message with the signed transmission receipt forwarded by the second device D2 according to step (F2'), the processing module of the reference device RD decrypts the message using the public key corresponding to the private key used by the second device D2 to encrypt the message, and verifies whether the signature on the transmission receipt is valid, whether there is no timeout relative to the first timestamp data, the reference device timestamp data and the second timestamp data, and whether the received deletion proof PR3 in the signed transmission receipt is valid; and (G1') If the signature on the signed transmission receipt is invalid, or a timeout occurs, or the received deletion proof PR3 is invalid, the reference device RD sends a corresponding error notification to the second device D2 and the first device D1 via the communication module of the reference device RD, and the data transmission between the first device D1 and the second device D2 is cancelled; and (G2') If the signature on the signed transmission receipt is valid, there is no timeout relative to the first timestamp data, the reference device timestamp data, and the second timestamp data, and the received deletion proof PR3 is valid, the processing module of the reference device RD further signs the signed transmission receipt, encrypts the further signed transmission receipt using one of the private keys stored in the memory module, and forwards the encrypted further signed transmission receipt to the first device D1 and the second device D2 via the communication module.

4. The method according to claim 2 or 3, wherein, At steps (C) or (C') respectively, If the internal rules of the verifiable data D2SVD selected by the received second device specify the use of verifiable credentials of the respective owners of the first device D1 or the second device D2, the reference device RD further checks the conformity of the verifiable credentials of the respective owners of the first device D1 or the second device D2 to the internal rules by communicating with the first device or the second device respectively via a credential sharing protocol.

5. The method according to any one of claims 1 to 4, wherein, Each verifiable data in the set of verifiable data of the device is associated with a corresponding leaf node of a Merkle tree corresponding to the device, each leaf node corresponding to a hash value obtained by hashing the corresponding associated verifiable data using a hash function, the Merkle tree including intermediate nodes up to the root node of the tree, the root node corresponding to the root value of the tree calculated according to the hash scheme of the Merkle tree, the Merkle tree being stored in the memory of the device; The processing unit of the device is adapted to modify the set of verifiable data stored in the memory of the device in the following manner, the modification corresponding to the removal of given verifiable data from the set: selecting a node of a stored Merkle tree corresponding to each given verifiable data to be removed from the set of stored verifiable data; replacing each removed verifiable data with corresponding placeholder data and hashing each placeholder data using the hash function to obtain corresponding placeholder leaf node values; obtaining a first part of the leaf nodes of a new Merkle tree by replacing the selected leaf nodes with their respective corresponding placeholder leaf nodes, and adjaculating a second part of the leaf nodes, which are separately stored leaf nodes and correspond to the selected leaf nodes of the Merkle tree respectively, adjacent to the first part; and forming the new Merkle tree from the stored Merkle tree by calculating new intermediate nodes of the new Merkle tree up to the new root node of the new Merkle tree with the first part and the second part of the leaf nodes according to the hash scheme using the hash function; and storing the new Merkle tree in the memory of the device. The processing unit of the device is adapted to generate a proof of modification to the set of verifiable data stored in the device's memory, corresponding to the execution of an operation performed by the device using operational parameter data values ​​of the given verifiable data, by sending the new root node value of the new Merkle tree along with root verification data to the reference device. The root verification data includes, respectively, the values ​​of the new placeholder nodes and new intermediate nodes of the new Merkle tree, the values ​​of which have been modified relative to the Merkle tree and are required to retrieve the new root value using the hash function according to the hash scheme; and The processing module of the reference device is adapted to verify that the new root node value of the new Merkle tree received from the device, along with the corresponding root verification data, which serves as proof that the device has performed the operation, matches the test root node value calculated from the received root verification data, thereby verifying that the device has performed the operation. In the case of deleting verifiable data corresponding to the leaf nodes of the separately stored new Merkle tree, the resulting updated Merkle tree is obtained by calculating the corresponding values ​​of the updated intermediate leaf nodes up to the updated root node of the new Merkle tree using the hash function according to the hash scheme only from the first part of the leaf nodes of the new Merkle tree. The updated root node value of the updated Merkle tree, together with the corresponding updated root verification data, constitutes the proof of the deletion of the verifiable data. When specific verifiable data is included in a set of verifiable data stored as an initial Merkle tree in the device's memory, the hash function is used to calculate the corresponding values ​​of additional leaf nodes from each of the included specific verifiable data, and the corresponding final Merkle tree is calculated from the values ​​of the leaf nodes of the initial Merkle tree and the values ​​of the additional leaf nodes according to the hash scheme. The resulting root node value of the final Merkle tree, together with the resulting root verification data, constitutes proof of the inclusion of the specific verifiable data; and The processing unit of the device and the processing module of the reference device are adapted to calculate the node values ​​of the Merkle tree using programmed hash functions and hash schemes, and to calculate the root value based on the root verification data.

6. The method according to any one of claims 2 to 5, wherein, At either step (B2) or step (B2'), the processing unit of the second device D2: Generate a new symmetric encryption key K, and use the generated key K to encrypt specific control fields of each selected verifiable data D2SVD; The generated key K is encrypted so that the encrypted key K can be decrypted using the public cryptographic key of the first device D1. as well as Furthermore, the encrypted key K, along with each encrypted specific control field, is incorporated into the message.

7. The method according to claim 6, wherein, At either step (C2) or step (C2'), upon receiving the message from the reference device RD, which includes the verifiable data D2SVD selected by the second device and the signed transmission receipt, the processing unit of the first device decrypts the encrypted key K using the corresponding private key of the first device stored in the memory of the first device to obtain the encryption key K, and uses the key K to decrypt each encrypted control field of the verifiable data D2SVD selected by the second device in the received message, thereby allowing the first device D1 to access the control field data of the second device D2 without revealing the data to the reference device RD.

8. The method according to any one of claims 2 to 5, wherein, At either step (B) or step (B'), after the received message has been decrypted and before verifying that the signature of the received signed transmission receipt is valid and there is no timeout, the second device D2 performs further level authentication of the first device D1 or the reference device RD by engaging in challenge-response communication with the first device D1 or the reference device RD, respectively. Only when the second device D2 receives a correct response from the first device D1 or the reference device RD to the challenge sent by the second device D2 to the first device D1 or the reference device RD, respectively, does the processing unit of the second device D2 verify that the signature on the received signed transmission receipt is valid and there is no timeout relative to the first timestamp data in the signed transmission receipt. In the case of an incorrect response to the challenge, data transmission with the first device D1 is canceled.

9. The method according to any one of claims 1 to 8, wherein, Each device owner's DID includes a unique identifier (UID) for that device owner, delivered by the identity server (IS) in response to the device owner's one-time registration settings with the identity server. Each device is adapted to communicate with the hosting server, i.e., ES, via the communication network, and each device owner can perform a one-time registration setup with the hosting server by sending a request via the device to the hosting server containing a unique identifier of the device and a cryptographic commitment to the link secret of the device. Upon receiving the request, the hosting server creates an entropy test vector (ETV) corresponding to a byte block generated by a random number generator, and a corresponding asymmetric encryption key pair (OK). pub OK priv ), to determine by first using the private key OK priv The received unique identifier, i.e., UID, is encrypted, and then the private key OK is used. priv The corresponding shielding configuration file, SP, obtained by encrypting the entropy test vector and the encrypted unique identifier, stores the obtained triple (OK). pub (,SP,UID), and deliver to the device a triple (OK) pub An anonymous verifiable credential C, consisting of SP, UID, and a cryptographic commitment to the link secret of the device. ES The hosting server is adapted to communicate with the identity server via a communication network and request the identity server to confirm that the unique identifier (UID) received by the hosting server from the device is indeed owned by the owner of the device. Each device is adapted to communicate with the governance server, GS, via a communication network. Each device owner can initiate a one-time registration setup with the governance server by first establishing a session with the governance server via their device. During this session, the device uses a temporary DID, and the governance server is authenticated. The governance server then challenges the device to generate proof of the device owner's registration with the hosting server, ES. In response, the device generates an anonymous verifiable credential C based on the one delivered by the hosting server. ES The device provides proof and sends the proof to the governance server. Upon receiving the proof, the governance server delivers multiple single-use identity tokens and corresponding verifiable credentials C to the device. GS Each delivered single-use identity token (SUIT) is a public key that can be used to locate the device. pub The string, the verifiable credential C delivered. GS It includes a field for each delivered Single Use Identity Token (SUIT) and a cryptographic commitment to the link secret of the device. In the case where device A among the plurality of devices communicates with device B among the plurality of devices by using a DID that has never been seen before. The device B then interrogates the device A to reveal the corresponding verifiable credential C. GS One of the single-use identity tokens (SUITs) delivered to device A by the governance server is used to prove that the owner of device A has registered with the governance server. In response, device A generates a verifiable credential C that reveals one of the corresponding one-time use identity tokens (SUIT). GS Zero-knowledge proofs, and The device B records the revealed single-use identity token (SUIT) in a signed transmission receipt generated by the device A.

10. A system for controlling multiple devices via a reference device to enable the devices to cooperate in performing a task, each device being owned by a corresponding owner, each device being equipped with a processing unit, a memory, and a communication unit and adapted to perform operations required to perform the task, wherein the memory of each device stores: a set of corresponding private keys of the device owner; a distributed identifier (DID) of the device owner associated with a set of public cryptographic keys respectively corresponding to the private keys; a programming method adapted to run on the processing unit of the device to authenticate other devices and the reference device; a set of public cryptographic keys of the other devices; a set of verifiable data having corresponding operational parameter data values ​​and associated internal rules required to perform the task; and verifiable credentials of the device owner; the communication units of the devices are adapted to securely communicate with each other via a wireless or wired communication network; the reference device is equipped with a processing module, a memory module, and a communication module and is adapted to communicate with each other via the wireless or wired communication network. The communication units of the devices communicate securely. The reference device and the devices are adapted to transmit data using an encryption protocol. The memory module of the reference device stores a set of corresponding private keys of the reference owner of the reference device, a set of corresponding distributed identifier data (DID), a set of public cryptographic keys corresponding to the private keys of the reference device, and a set of public cryptographic keys of each of the plurality of devices. The reference device and each device are adapted to digitally sign the transmission receipt using their corresponding private keys. The memory of each device also stores the set of public cryptographic keys of the reference device. The clock of the processing unit of each device is synchronized with the clock of the processing module of the reference device RD. Each device and the reference device RD are adapted to include timestamp data in the transmission receipt and to verify whether there is a timeout relative to the timestamp data in the received transmission receipt. The system is characterized in that the devices and the reference device are adapted to perform the steps of the method according to any one of claims 1 to 9.

11. The system of claim 10, further comprising: An identity server (IS), adapted to communicate with the device via the communication network, and in response to a one-time registration setting by the device's owner with the identity server, delivers the owner's corresponding unique identifier (UID) to the device for association with the device's owner's distributed identifier data (DID). A hosting server ES, adapted to communicate with the device via the communication network, and upon receiving a request from the device containing a unique identifier UID of the device's owner and a cryptographic commitment to the device's link secret, performs a one-time registration with the device's owner in the following manner: Create the entropy test vector (ETV) corresponding to the byte block generated by the random number generator, and the corresponding asymmetric encryption key pair (OK). pub OK priv ), to determine by first using the private key OK priv The received unique identifier, i.e., UID, is encrypted, and then the private key OK is used. priv The corresponding shielding configuration file, SP, obtained by encrypting the entropy test vector and the encrypted unique identifier, stores the obtained triple (OK). pub (,SP,UID), and deliver to the device a triple (OK) pub An anonymous verifiable credential C, consisting of SP, UID, and a cryptographic commitment to the link secret of the device. ES The hosting server is adapted to communicate with the identity server via the communication network and request the identity server to confirm that the unique identifier (UID) received by the hosting server from the device is indeed owned by the owner of the device. A governance server GS, adapted to communicate with the device via the communication network and to perform a one-time registration setup with the device's owner when the device establishes a session with the governance server, during which the device uses a temporary DID and the governance server is authenticated, the governance server then challenges the device to generate proof of the device owner's registration with the hosting server ES, and in response, the device generates an anonymous verifiable credential C based on the one delivered by the hosting server. ES The system provides proof of identity and sends the proof to the governance server. Upon receiving the proof, the governance server delivers multiple one-time use identity tokens and corresponding verifiable credentials C to the device. GS Each delivered single-use identity token (SUIT) is a public key that can be used to locate the device. pub The string, the verifiable credential C delivered. GS It includes a field for each delivered single-use identity token (SUIT) and a cryptographic commitment to the link secret of the device, and In one of the plurality of devices, device A communicates with device B using a DID that has never been seen before. The device B then interrogates the device A to reveal the corresponding verifiable credential C. GS One of the single-use identity tokens (SUIT) delivered to device A by the governance server is used to prove that the owner of device A has registered with the governance server GS. In response, device A generates a verifiable credential C that reveals one of the corresponding one-time use identity tokens (SUITs). GS Zero-knowledge proofs, and The device B records the revealed single-use identity token (SUIT) in a signed transmission receipt generated by the device A.

Images