Method and corresponding system for controlling the secure execution of the operation of an interconnection device

Abstract

The invention relates to a method and a corresponding system for controlling the operation of a plurality of interconnected devices each having a hardware Trusted Execution Environment (TEE) and a controller, wherein each controller possesses a token attributed by a directing server and the TEE of each device is adapted to respond to authentication challenges via a Zero-Knowledge Proof (ZKP) protocol and to generate and verify single-use ownership digital signatures and their respective ownership signature verification challenges. The token can be transferred from one interconnected device to another either in an online manner via the server or in an offline manner via direct communication between the devices.

Description

Technical Field

[0001] This invention relates to the field of guidance and control of operations performed by a plurality of devices equipped with communication units having secure hardware components operable to exchange data via secure wired or wireless data transmission and authentication protocols. Background Technology

[0002] Today, interconnected devices via wired or wireless networks are widely used, such as industrial robots that collaborate to perform various tasks within a factory according to industrial manufacturing processes, and mobile devices such as mobile phones, laptops, or tablets. All these devices must exchange data with each other and with servers. These devices are typically equipped with processing and communication units to exchange and process data received via communication networks. For example, interconnected robots are often guided by servers (which have processing and communication components as well as storage components such as databases) to receive instructions for performing tasks.

[0003] In this context of interconnected devices, numerous hardware and software solutions have been developed to provide secure data transmission over networks. For example, US 2012117380 A1 discloses methods for granting authorization to access automated systems, computer programs, and computer-based objects within automated systems. The security of data exchange over networks against intrusion by (untrusted) parties is enhanced through the use of data encryption. For instance, "Rich Operating System Execution Environments" (REEs) have been developed (e.g., Android). TM However, this is not always sufficient to prevent (physical) intrusion and data integrity. Therefore, physical protections for processing units, or at least parts of them, have been developed to increase security. For example, the industry has developed the Trusted Execution Environment (TEE) standard, which uses both hardware and software to protect data (e.g., ARM TrustZone technology from ARM Holdings, see also references [1] and [2]). A Trusted Execution Environment (TEE) is a secure zone for the processor: as an isolated execution environment, it ensures 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 enclosed zone. A secure enclosed zone is a protected area within the processing device that serves as memory for the TEE used to process sensitive data. To the rest of the device and other processing running on it, the secure enclosed zone is like an opaque box: no data or code within it can be viewed from the outside. For example, when parsing a query from an application on a client driver, the processing device determines whether the query contains any operations on encrypted data that requires access to the secure enclosed zone. For queries that require access to the secure enclosed zone: (i) the client driver sends the column encryption key (via a secure channel) required for the operation to the secure enclosed zone, and (ii) the client driver then submits the query along with encrypted query parameters for execution. During query processing, data or column encryption keys are not exposed in plaintext outside the secure enclosed zone (the processing device delegates cryptographic operations and computations on encrypted columns to the secure enclosed zone). The secure enclosed zone (within the processing device) can access sensitive data and corresponding column encryption keys stored in encrypted database columns in plaintext. Before submitting a query involving encirclement calculation to the processing unit, the client driver within the application must verify, based on a given technology (e.g., VBS "Virtualization-based Security"), whether the secure encirclement is a genuine encirclement and whether the code running within the encirclement has been signed for execution within the encirclement.

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

[0006] There is also the ZKP protocol to sign digital artifacts with a new key that does not have a key value, i.e., without having to learn how to actively respond to signature proofs (e.g., via “covert” (see [6], [7]), valid (see [8], [9],

[10] ), or proxy (see

[11] ) signatures).

[0007] However, in response to potential intrusions that alter the integrity of execution data, and when controlling the execution of operations performed by interconnected devices, especially when the devices are not owned (or fully controlled) by the same entity (and therefore must manage some “untrusted” devices), there is still a need to improve security and robustness so that only sensitive data strictly necessary for the execution of the operation can be transmitted, unauthorized (repeated) use of transmitted data can be prevented, and traceability of data exchange can be ensured. Summary of the Invention

[0008] According to one aspect, the present invention relates to a method for controlling multiple devices via a server connected to a database, each device being equipped with a processing unit, a communication unit, and a hardware trust execution environment (TEE) with memory, the TEE being securely connected to the communication unit via a dedicated secure hardware path, and each device being controlled by a corresponding controller, the communication units being adapted to securely communicate with each other via a wireless or wired point-to-point communication link for offline communication, the server being adapted to securely communicate with the communication units of each device via a wired or wireless communication network for online communication, the server and the communication units being adapted to transmit data using an encryption protocol, and the server and the TEE of each device being adapted to respond to verification challenges via a zero-knowledge proof protocol (ZKP) and to generate and verify a single-use ownership digital signature and its corresponding ownership signature verification challenge, wherein:

[0009] The database managed by the server stores digital tokens. Each token delivered by the server includes a unique token identifier, corresponding token data assigned by the server and including the server's signature, and a token ownership query corresponding to a unique controller that owns the token, wherein the token is owned by the server to the unique controller.

[0010] In the event that a token owned by controller A of device A is transmitted offline to another controller B of another device, controller A first sends an offline transmission request to the server via online communication using the device's communication unit. The offline transmission request includes the token's unique identifier and a one-time use offline signature of the Trusted Execution Environment (TEE) of controller A's device. Upon receiving the offline transmission request, the server checks whether the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A. Upon receiving and verifying the token ownership query response from controller A, the server verifies whether the one-time use offline signature of the TEE is valid. If the one-time use offline signature of the TEE is valid, the server replaces the token ownership query corresponding to the token's unique identifier with the TEE ownership query corresponding to the one-time use offline signature of the TEE, and sends back a confirmation message indicating successful replacement of the token ownership query along with the data required for controller A's device's TEE to begin executing the token. If the one-time use offline signature of the TEE is invalid, the server sends back a corresponding failure message corresponding to the invalid one-time use offline signature to controller A.

[0011] Upon receiving the confirmation message, the TEE of controller A's device begins executing the token, and the communication unit of controller A's device exposes the running token to the communication unit of controller B's device. Then, controller B continuously observes, synchronizes with, and checks the running token within the trusted execution environment of controller B's device.

[0012] (i) Whether the token was signed by the server.

[0013] (ii) Whether the token owner is controller A, and

[0014] (iii) Is the token running in the trusted execution environment of controller A's device?

[0015] Then, controller A's device changes the token ownership challenge of the running token to support controller B, and controller B continuously observes a copy of the token with the changed token ownership challenge within the trusted execution environment of controller B's device.

[0016] The TEE of the device of controller B stops running the token and generates a stop certificate. Then, controller B pushes a transmission request containing the unique identifier of the token, the stop certificate and the changed token ownership query to the server online. Upon receiving the transmission request, the server checks whether the request is valid. If the request is valid, the server makes the corresponding change for the token ownership query in the database.

[0017] At step (ii) of the above method, at the device of controller B which communicates offline with the communication unit of the device of controller A, the TEE of the device of controller B can check whether the token owner is controller A via the zero-knowledge proof protocol, namely the ZKP protocol.

[0018] At step (iii) of the above method, at the device of controller B which communicates offline with the communication unit of the device of controller A, the TEE of the device of controller B can check whether the token is running in the trusted execution environment of the device of controller A via dynamic system state synchronization / reconstruction and the ZKP protocol for TEE signing.

[0019] In the above method, controller A can change the token ownership challenge of the running token to support controller B through oblivious computing at the device of controller A, which communicates offline with the device of controller B.

[0020] According to the above method, when the TEE of the device controlled by controller B stops running the offline token:

[0021] - The TEE of the device of controller B can generate a verifiable one-time signature that proves that the offline token has been stopped and contains a verifiable check on the original TEE's one-time use offline signature, and the device of controller B can generate a one-time use ownership challenge signature.

[0022] - Controller B may add the verifiable one-time signature, a provable check of the original TEE's single-use offline signature, and a single-use ownership challenge signature to the transmission request, and push the transmission request online to the server; and

[0023] Upon receiving the transmission request, the server can check whether the transmission request is valid by performing the following steps:

[0024] Check if the token with the unique identifier of the received token is indeed offline, and then if the token is offline,

[0025] Verify the validity of the received one-time signature, and if the one-time signature is valid, then use the received original TEE to challenge ownership in a single offline signature transaction.

[0026] Check whether the received single-use ownership challenge signature is valid, and if the single-use ownership challenge signature is valid, replace the token ownership challenge stored for the token's unique identifier in the database with the received modified token ownership challenge.

[0027] In the event that the token fails to run on the TEE of device A, or if the token is stopped from running before it is transmitted to device B,

[0028] The TEE of the device of controller A can generate a verifiable one-time signature proving that the offline token has been stopped, and the device of controller A can generate a one-time use ownership query signature corresponding to the new token ownership query of controller A.

[0029] Controller A can send a return request to the server, the return request instructing the server to return the token, along with the verifiable one-time signature and the one-use ownership challenge signature, back online;

[0030] Upon receiving the return request, the server can check whether the request is valid by performing the following steps:

[0031] Verify that the token is indeed offline, then

[0032] The original single-use offline signature is challenged, and the received one-time signature is verified to be valid. If the one-time signature is valid and the received single-use ownership challenge signature is verified to be valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with a new token ownership challenge.

[0033] According to the above method, in the case of transmitting a token owned by controller A of device A online to another controller B of another device, the transmission may involve:

[0034] - The unique identifier of the token to be transmitted is sent from controller A to controller B via the device's communication unit.

[0035] - The controller B sends back the single-use ownership query signature via the communication unit of the other device.

[0036] - A transmission request is sent from controller A to the server, the transmission request specifying the unique identifier of the token and the single-use ownership challenge signature received from controller B.

[0037] Upon receiving the transmission request, the server checks whether the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A.

[0038] Upon receiving and verifying the ownership response from controller A, the server verifies the validity of the single-use ownership signature of controller B in the transmission request, and

[0039] If the single-use ownership signature is valid, the server replaces the token ownership query corresponding to the token's unique identifier with a token ownership query corresponding to controller B, and sends a transmission confirmation back to controller A.

[0040] In the event that the single-use ownership signature is invalid, the server sends a transmission failure message back to controller A.

[0041] According to another aspect, the present invention relates to a system for controlling multiple devices via a server connected to a database, each device being equipped with a processing unit, a communication unit, and a hardware trust execution environment (TEE) with memory. The TEE is securely connected to the communication unit via a dedicated secure hardware path, and each device is controlled by a corresponding controller. The communication units are adapted to securely communicate with each other via a wireless or wired point-to-point communication link for offline communication, and the server is adapted to securely communicate with the communication units of each device via a wired or wireless communication network for online communication. The server and the communication units are adapted to transmit data using an encryption protocol, and the server and the TEE of each device are adapted to respond to verification challenges via a zero-knowledge proof protocol (ZKP) and to generate and verify a single-use ownership digital signature and its corresponding ownership signature verification challenge.

[0042] in:

[0043] The server is adapted to deliver digital tokens and store the delivered tokens in a database. Each token delivered by the server includes a unique token identifier, corresponding token data assigned by the server and including the server's signature, and a token ownership query corresponding to the unique controller to which the server owns the token.

[0044] In order to perform offline transfer of a token owned by controller A of device A to another controller B of another device,

[0045] Controller A first sends an offline transmission request to the server via online communication using the device's communication unit. The offline transmission request includes a token unique identifier and a one-time offline signature of the Trusted Execution Environment (TEE) of Controller A's device.

[0046] Upon receiving the offline transmission request, the server checks whether the token unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A;

[0047] Upon receiving and verifying a token ownership challenge response from controller A, the server verifies whether the TEE single-use offline signature is valid. If the TEE single-use offline signature is valid, the server replaces the token ownership challenge corresponding to the token unique identifier with a TEE ownership challenge corresponding to the TEE single-use offline signature, and sends back a confirmation message indicating successful replacement of the token ownership challenge along with the data required for the TEE of controller A's device to start executing the token. If the single-use offline signature is invalid, the server sends back a corresponding failure message corresponding to the invalid single-use offline signature to controller A.

[0048] Upon receiving the confirmation message, the TEE of controller A's device begins executing the token, and the communication unit of controller A's device exposes the running token to the communication unit of controller B's device. Then, controller B continuously observes, synchronizes with, and checks the running token within the trusted execution environment of controller B's device.

[0049] (i) Whether the token was signed by the server.

[0050] (ii) Whether the token owner is controller A, and

[0051] (iii) Is the token running in the trusted execution environment of controller A's device?

[0052] Then, controller A's device changes the token ownership challenge of the running token to support controller B, and controller B continuously observes a copy of the token with the changed token ownership challenge within the trusted execution environment of controller B's device.

[0053] The TEE of controller B's device stops running the token and generates a stop certificate. Then, controller B pushes a transmission request online to the server containing the token's unique identifier, the stop certificate, and a challenge to the changed token ownership.

[0054] Upon receiving the transmission request, the server checks whether the request is valid, and if the request is valid, the server makes the corresponding change in the database regarding the token ownership query.

[0055] In the above system, in order to perform the operation of checking (ii) whether the token owner is controller A, the TEE of the device of controller B can check whether the token owner is controller A via the zero-knowledge proof protocol, i.e., ZKP protocol, at the device of controller B which is communicating offline with the communication unit of the device of controller A.

[0056] In order to perform the operation of checking (iii) whether the token is running in the trusted execution environment of the device of controller A, the TEE of the device of controller B can check whether the token is running in the trusted execution environment of the device of controller A at the device of controller B, which is communicating offline with the communication unit of the device of controller A, via dynamic system state synchronization / reconstruction and the ZKP protocol for TEE signing.

[0057] According to the above system, controller A can change the token ownership challenge of the running token to support controller B through an unintentional calculation at the device of controller A, which communicates offline with the device of controller B.

[0058] According to the system, when the TEE of the device of controller B stops running offline tokens,

[0059] - The TEE of the device of controller B can generate a verifiable one-time signature that proves that the offline token has been stopped and contains a verifiable check on the original TEE's one-time use offline signature, and the device of controller B can generate a one-time use ownership challenge signature.

[0060] - Controller B can add the verifiable one-time signature, the provable check of the original TEE's single-use offline signature, and the single-use ownership challenge signature to the transmission request, and can push the transmission request online to the server via the communication unit of Controller B's device; and

[0061] Upon receiving the transmission request, the server can check whether the transmission request is valid by performing the following operations:

[0062] Check if the token with the unique identifier of the received token is indeed offline, and then if the token is offline,

[0063] Verify the validity of the received one-time signature, and if the one-time signature is valid, then use the received original TEE to challenge ownership in a single offline signature transaction.

[0064] Check whether the received single-use ownership challenge signature is valid, and if the single-use ownership challenge signature is valid, replace the token ownership challenge stored for the token's unique identifier in the database with the received modified token ownership challenge.

[0065] In the above system, if the token fails to run via the TEE of controller A, or if the token is stopped running before it is transmitted to controller B:

[0066] - The TEE of the device of controller A can generate a verifiable one-time signature proving that the offline token has been stopped, and the device of controller A generates a one-time use ownership query signature corresponding to the new token ownership query of controller A.

[0067] - Controller A can send a return request to the server via online communication using the communication unit of the device of Controller A. The return request instructs the server to return the token online together with the verifiable one-time signature and the one-time use ownership challenge signature.

[0068] Upon receiving the return request, the server can check whether the request is valid by performing the following operations:

[0069] Verify that the token is indeed offline, then

[0070] The original single-use offline signature is challenged, and the received one-time signature is verified to be valid. If the one-time signature is valid and the received single-use ownership challenge signature is verified to be valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with a new token ownership challenge.

[0071] According to the above system, in the case of online transmission of a token held by controller A of one device to another controller B of another device, the transmission can be performed by the following operations:

[0072] - The unique identifier of the token to be transmitted is sent to controller B via offline communication between the communication unit of controller A's device and the communication unit of controller B's device.

[0073] - The single-use ownership query signature of controller B is sent back via offline communication between the communication unit of controller B's device and the communication unit of controller A's device.

[0074] - A transmission request is sent to the server via online communication by controller A through the communication unit of controller A's device. The transmission request specifies a unique token identifier and a single-use ownership challenge signature received from controller B.

[0075] Upon receiving the transmission request, the server checks whether the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A via online communication with the communication unit of the device connected to controller A.

[0076] - Upon receiving an ownership response from controller A via online communication with the device of controller A, the server verifies the validity of the single-use ownership signature of controller B in the transmission request.

[0077] If the single-use ownership signature is valid, the server replaces the token ownership query corresponding to the token's unique identifier with a token ownership query corresponding to controller B, and sends a confirmation back to controller A via online communication with the communication unit of the device connected to controller A.

[0078] In the event that the single-use ownership signature is invalid, the server sends a transmission failure message back to controller A via online communication with the communication unit of the device of controller A.

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

[0080] Figure 1 A system including a server (S) for guiding the operation of two interconnected devices D(A) and D(B) is schematically shown.

[0081] Figure 2 An embodiment is illustrated in which a token owned by controller A of device D(A) is transmitted online to another controller B of another device D(B).

[0082] Figure 3 The schematic diagram illustrates the main operations of “extraction,” “exchange,” and “push” involved in the controllers CA and CB according to the present invention between server S and devices D(A) and D(B) to enable offline transmission of tokens between D(A) and D(B).

[0083] Figure 4 An embodiment of the operation of retrieving a token from server S by controller CA of device D(A) in preparation for the offline transmission of a token T owned by controller CA to controller CB of device D(B) according to the present invention is illustrated.

[0084] Figure 5A An embodiment of the operation according to the present invention is shown in which the run token RT owned by the controller CA of device D(A) is transmitted offline to the controller CB of device D(B).

[0085] Figure 5B yes Figure 5A The continuation of.

[0086] Figure 6A An embodiment of the operation according to the present invention is shown, in which the controller CB, having received the token from the controller CA of device D(A), stops device D(B) from running the token RT and pushes the corresponding transmission request PUSONL online.

[0087] Figure 6B yes Figure 6A The continuation of. Detailed Implementation

[0088] according to Figure 1The above schematically illustrated embodiment of the invention involves a server S directing operations performed by multiple devices (only two devices are shown here: D(A) and D(B)) (e.g., industrial robots in a factory or automated machines on a distribution line). Each device has a processing unit PU and a communication unit CU. Each device is controlled by a corresponding controller (here, controller A (“CA”) and controller B (“CB”)). The server S has computing power and a communication module that allows direct data transmission with the devices, i.e., in online data transmission via a wired or wireless communication network CN (e.g., the Internet), using an encrypted communication protocol and an ownership verification protocol involving a single-use ownership digital signature and a corresponding ZKP (“zero-knowledge proof”) based on a challenge. According to the invention, secure data transmission includes the exchange of tokens. The server S can create a digital token T, which includes a corresponding token unique identifier Tid (e.g., a serial number, possibly alphanumeric), specific token data assigned by the server S and including the server's digital signature SDS, and a token ownership challenge Toc corresponding to a controller (to which the token has been attributed by the server S). Optionally, a server signature SDS can be added to the token unique identifier instead of the token allocation data. This allocated token data can be, for example, programming instructions to be executed by a device of the controller or an application to be run on the processing unit of said device. The server S manages a database DB that stores the tokens. The first two “entries” of the token, namely the token unique identifier Tid and the token allocation data (with the server signature SDS), are immutable, while the third entry (i.e., the token ownership challenge Toc) can be altered (depending on possible transfers of the token from one controller to another). The third entry of the token is an encrypted ownership key or any function, data, or code that allows for an unintentional challenge to ownership without revealing the owner. The server S stores the tokens in the database DB and updates the DB contents based on various transfers of the tokens between devices via communication links. According to the invention, each controller can communicate directly with the server S via online data transfer and the ZKP protocol to know the tokens owned by that controller, the corresponding token unique identifier of the token, and the allocated token data.

[0089] Operations performed by the devices, particularly in cases where devices collaborate to accomplish complex tasks, involve the transfer of tokens between devices without the involvement of a server S; i.e., offline data transfer between these devices. Offline communication between devices (i.e., between their respective wireless units) via wireless communication links (e.g., LANs such as Wi-Fi or PANs such as Bluetooth, IrDA, wireless USB, or NFC) or via wired communication links (e.g., LANs such as Ethernet) also utilizes communication protocols with single-use ownership digital signatures and ownership signature verification challenges (i.e., "ownership challenges") and verification based on the ZKP protocol. The processing unit (PU) and communication unit (CU) of each device are securely connected to a corresponding Trusted Execution Environment (TEE). Each TEE of the device has memory and is securely connected to the device's communication unit (CU) via a dedicated secure hardware path. The communication units (CUs) of the devices can communicate with each other via the Zero-Knowledge Proof (ZKP) protocol to verify the signatures (signature proofs) of digital artifacts through the communication link CL (offline) in offline mode (i.e., without involving the server S), to exchange tokens and access the unique token identifiers and allocation data of the tokens. Once an offline exchange of tokens has been performed between the two controllers of the two devices according to a given offline exchange protocol (see below), the controller that has received one or more tokens contacts the server in online mode (via the communication unit of the device, through the communication network CN) and transmits a list of the tokens received offline, notifying the server S of the transmission at a later stage. Furthermore, the server S can inadvertently compile the list of unique token identifiers transmitted offline. In contrast, each controller of the devices can inadvertently (i.e., without revealing its own identity) query the server S (via online communication between the communication unit of the device and the server) to know the list of tokens (and their allocation data) owned by the controller according to the (updated) content in the database DB.

[0090] According to the present invention, the transfer of tokens between two controllers can be implemented in online or offline mode. Figure 2 This diagram illustrates an embodiment of an online-to-offline (ONLTRF) transmission of a token T owned by controller CA of device D(A) to another controller CB of device D(B). This transmission involves the following operations:

[0091] - The controller CA sends the token unique identifier Tid of the token T (which is owned by the controller CA) that the controller CA wants to send to the controller CB. That is, the token unique identifier Tid is sent by the controller CA to the communication unit CU of the device D(B) via the communication link CL through the communication unit CU of the device D(A).

[0092] - When the controller CB receives the transmitted Tid by its (communication unit), the controller CB generates a single use ownership challenge signature GEN SUOCS(B) of the controller CB, and then sends the generated single use ownership challenge signature SUOCS(B) of the controller CB back to the controller CA (the communication unit of the device D(A)) via the communication unit CU of the device D(B) through CL.

[0093] - Upon receiving the Single Use Ownership Challenge Signature (SOUCS(B)) from the controller CB, the controller CA sends an Online Transmission Request (ONLTRF(A)) to the server S, containing the token unique identifier Tid and the received Single Use Ownership Challenge Signature (SOUCS(B)) from the controller CB. That is, the transmission request ONLTRF(A) is sent from the communication unit CU of D(A) to the server S via the communication network CN (see [link to documentation]). Figure 2 (the subgraph "par");

[0094] - Upon receiving the transmission request ONLTRF(A), server S checks (see...) Figure 2 Whether the token unique identifier Tid in the subgraph "alt [when OK]" transmission request is indeed stored in the database DB along with the corresponding token ownership challenge Toc (usually the ownership challenge corresponding to the controller CA), that is, whether the server S obtains the corresponding Tid and Toc (see Figure 2 The operation GET[Tid, Toc]) is performed. Then, if the token is stored in the DB, the server S sends the token ownership query Toc to the controller CA. That is, the server S sends Toc to the communication unit CU of the device D(A) of the controller CA via the communication network CN.

[0095] - When a Toc is received, the controller CA will send the ownership response ANS(Toc) to the received ownership challenge Toc back to the server S. That is, the communication unit CU of D(A) sends the ownership response calculated by the processing unit PU of D(A) via the communication network CN.

[0096] When an ownership response ANS(Toc) is received from the controller CA and the server S performs a verification VER ANS(Toc) of the response, the server S verifies (see operation VER SUOCS(B)) that the single-use ownership signature SUOCS(B) of the controller CB in the transmission request ONTR(A) is valid. If the single-use ownership signature SUOCS(B) is valid, the server S provides a token ownership challenge Toc' corresponding to the received single-use ownership signature SUOCS(B) of the controller CB (see operation Toc' = FUN[SUOCS(B)], indicating that Toc' is based on SUOCS(B)), and replaces the token ownership challenge Toc corresponding to the token unique identifier Tid in the database DB with the token ownership challenge Toc' (see operation REP Toc' → Toc), and sends a "transmission confirmation" message CT back to the communication unit CU of the device D(A) of the controller CA. In the event that the single-use ownership signature SUOCS(B) is invalid, the server S sends a "transmission failed" message FT back to the controller CA via the communication network CN (see [link]). Figure 2 The subgraph “alt[NOT OK]”). The controller CB can send an ownership query containing the token unique identifier Tid of the received token T to the server S via (via the communication unit CU of device D(B)) (see Figure 2The subgraph "loop [until RES or timeout]" operation QRYOWN[Tid]" checks whether ownership has changed (i.e., token transfer from controller CA to controller B) via online communication between its device D(B)'s communication unit CU and server S. Upon receiving the ownership query, server S obtains the (updated) token ownership challenge corresponding to the received Tid from database DB (see operation GET[Tid, Toc]) and sends the obtained token ownership challenge Toc back to the communication unit CU of device B(B) of controller CB. Upon receiving the token ownership challenge Toc, controller CB sends an ownership response ANS(Toc) to server S in response to the received ownership challenge Toc; that is, the communication unit CU of D(B) sends the ownership response ANS(Toc) calculated by the processing unit PU of D(B) via communication network CN. Upon receiving the ownership response ANS(Toc), server S verifies the received response (see operation RES = VER ANS(Toc)), and server S sends the result RES back to the communication unit CU of device D(B) of controller CB. If the result RES is positive, it indicates to controller CB that the token transfer has been performed (i.e., controller CB is now the owner of token T registered in database DB). In practice, device D(B) immediately begins checking and polling until a positive result is obtained or the time expires.

[0097] Figure 3 The schematic diagram illustrates the main operations of “extraction,” “exchange,” and “push” involved in the controllers CA and CB according to the present invention between server S and devices D(A) and D(B) to enable offline transmission of tokens between devices D(A) and D(B).

[0098] Figure 4 The diagram illustrates an embodiment of the invention as follows: The controller CA of device D(A) retrieves a token T offline from server S in preparation for the offline transmission of the token T, owned by controller CA, to the controller CB of device D(B) (see also...). Figure 3 The operation "extract" is mentioned above. This extraction involves the following operations:

[0099] Before going offline, the controller CA of device D(A) first sends an offline transmission request FETOFF(A), which includes the token unique identifier Tid and the TEE one-time use (offline) signature TEE-SUS(A) of the trust execution environment D(A)TEE of device D(A). In practice, the communication unit CU of device D(A) sends the token unique identifier Tid of the token T to its D(A)TEE, and then the D(A)TEE generates the trust execution environment one-time use signature GEN TEE-SUS(A) and sends the generated TEE-SUS(A) back to the communication unit CU of device D(A). Device D(A) then sends an offline transmission request FETOFF(A)[Tid, TEE-SUS(A)] containing the token unique identifier Tid and the TEE one-time use signature TEE-SUS(A) to the server S (via online communication through the communication network CN).

[0100] -Upon receiving the offline transmission request FETOFF(A) [Tid, TEE-SUS(A)] (see...) Figure 4 When the subgraph "alt[when OK]" is on the top, the server S checks that GET(Tid, Toc) is indeed in the database DB along with the token unique identifier Tid and the corresponding token ownership query Toc. Then, the server S sends the token ownership query Toc to the controller CA (that is, S sends Toc to the communication unit CU of the device D(A) of the controller CA via the communication network CN).

[0101] The communication unit CU of the device D(A) of the controller CA receives the token ownership challenge Toc from S, the processing unit PU of the device D(A) calculates the corresponding ownership challenge response ANS(Toc) to the received Toc, and the communication unit CU of the device D(A) sends the ownership challenge response ANS(Toc) back to the server S.

[0102] Upon receiving and verifying the ownership challenge response VERANS(Toc) from the controller CA, the server S verifies the validity of the TEE single-use offline signature TEE-SUS(A) received along with the corresponding offline transfer request FETOFF(A)[Tid, TEE-SUS(A)]. If the TEE single-use offline signature TEE-SUS(A) is valid, the server S generates a token ownership challenge Toc' corresponding to the valid TEE single-use offline signature TEE-SUS(A) and Toc' = FUN[TEE-SUS(A)]. In the database, the server replaces the token ownership challenge Toc corresponding to the token unique identifier Tid with the token ownership challenge Toc' corresponding to the TEE single-use offline signature TEE-SUS(A) (see operation REP Toc'→Toc). Then, server S sends a “run token” RT back to device D(A)TEE, and then the device D(A)TEE of controller CA begins to execute token RT (see sub-diagram “RUNRT [until stop]”), and server S also sends an acknowledgment message CM back to device D(A) communication unit CU, which indicates that token RT is running in D(A)TEE and can be transmitted.

[0103] In the event that the single-use offline signature TEE-SUS(A) is invalid, the server S sends a corresponding failure message FM to the communication unit of the device D(A) of the controller CA via the communication network CN.

[0104] - After the controller CA receives the confirmation message CM related to the runnable token RT and the D(A)TEE has started executing (running) the token RT (see... Figure 5A In the case of [missing information], the communication unit CU of device D(A) of controller CA exposes the run token RT (EXP RT) to the communication unit CU of device D(B) of controller CB. Then, device D(B) of controller CB continuously observes the run token RT (OBS RT) in its Trusted Execution Environment D(B)TEE and synchronizes with the run token RT. In the preferred mode, the Trusted Execution Environment D(A)TEE of device D(A) exposes the run token RT (D(A)TEEEP) via an "Externalized Peripheral Device" (EP) to transmit the run token RT through the (offline) communication link CL (see [missing information]). Figure 5AThe subgraph “loop [until the end]”). Externalized peripheral devices can be, for example: output channels of PAN / LAN communication peripheral devices such as Wi-Fi, Bluetooth, IrDA, wireless USB, or NFC, which are to be paired with corresponding input channels of “internalized peripheral devices” on the device D(B) side; and displays / screens to be paired with cameras as internalized devices to form screen-camera communication settings. As described above, device D(B) can then continuously observe in its trusted execution environment D(B)TEE (see Figure 5A The subgraphs “loop [until CHGTRG]” and “loop [until CHGOWN or timeout]” expose the run token RT. Preferably, the observation RT (via communication link CL) and synchronization with the run token RT are performed via the “internalized peripheral device” (IP) (D(B)TEE IP) of device D(B). The trusted execution environment D(B)TEE then obtains the run token RT from the D(B)TEE IP and checks whether “VER S” (i) the run token RT is signed by server S and whether “VER OWN(A)” (ii) the owner of the run token RT is indeed the controller CA (see Figure 5A The subgraph “loops [until CHGTRG]”. Preferably, the latter operation is performed via a zero-knowledge proof ZKP verification protocol (see [link]). Figure 5A Subgraph VER OWN(A): The communication unit CU of device D(B) sends a ZKP ownership challenge ZKPOWN to the communication unit of device D(A) (offline via communication link CL). The communication unit CU of device D(A) sends back the corresponding ownership challenge response ANS(ZKPOWN) to the communication unit CU of device D(B) and the trust execution environment D(B)TEE of device D(B), and then verifies the response received by VERANS(ZKPOWN). In addition, the trust execution environment D(B)TEE of device D(B) verifies whether the token RT observed in (iii) is indeed running VER RUN(RT) in the trust execution environment of the controller CA's device. This latter operation is performed via the zero-knowledge proof ZKP verification protocol (see Figure 5A The subgraph VER RUN(RT): The communication unit CU of D(B) sends a ZKP running challenge ZKPRUN to the communication unit CU of device D(A) (offline via communication link CL). The communication unit CU of device D(A) sends back the corresponding running challenge response ANS(ZKPR) to the communication unit CU of device D(B) and the trusted execution environment D(B)TEE of device D(B). Then, the response received by VER ANS(ZKPRUN) is verified.

[0105] Then, if conditions (i) to (iii) above are met, device D(B) sends an RTCHK message via communication link CL to let device D(A) know that the run token was indeed signed by S, owned by controller CA, and is being run. If not all of these conditions are met, device D(B) sends the corresponding NOT RTCHK message via communication link CL.

[0106] - On the other hand, when device D(A) receives message RTCHK (see...) Figure 5B In the subgraph “loop [until RTCHK]”, controller CA initiates the transfer of ownership of the run token RT to the supporting controller CB by sending the message CHGOWN(B) to the D(A)TEE via the communication unit CU of device D(A). This operation is preferably performed via the zero-knowledge proof ZKP signature verification protocol (see [link to protocol]). Figure 5B Subgraph “CHGOWN(B)”): D(A) sends a ZKP signature ZKPSIG challenge to D(B), then D(B) sends back a response to the challenge, ANS(ZKPSIG). After verifying the received response, device D(A) changes the ownership of the token running in its TEE to the supporting controller CB (CHGOWN[ANS(ZKPSIG)]) based on the received response. D(A) then sends the corresponding message CHGTRG via communication link CL to inform the controller CB that the ownership of the running token RT has changed (to support CB). Now D(A) is interested in stopping the running of token STOP RT in its D(A) TEE (e.g., to reduce D(A)'s energy consumption), see [link to relevant documentation]. Figure 5B The subgraph "loops [until CHGOWN]". When the token RT has stopped running in the D(A)TEE of device D(A), the D(A)TEE sends a message CT to device D(A) regarding the transmission confirmation.

[0107] - On the other hand, when device D(B) receives the message CHGTRG, the trusted execution environment D(B)TEE of device D(B) is activated via the communication link CL (see... Figure 5A The subgraph "loop [until CHGOWN or timeout)" obtains a run token RT based on the observed run token OBSRT, verifies whether the VER S token is signed by server S, and checks whether the (new) owner of the run token RT is controller CB VEROWN(B) and whether the token is indeed running VER RUN(RT). The latter operation is preferably performed via a zero-knowledge proof ZKP verification protocol (see [link to documentation]). Figure 5AThe subgraph “VER RUN(RT)” shows that D(B) sends a ZKP challenge ZKPRUN to D(A), and then D(A) sends its response to the challenge ANS(ZKRUN) back to D(B). After verifying the received response, device D(B) sends the message CHGOWN via the communication link to inform controller CA that the owner of the token is now controller CB. If the verification of the token being run has a negative result, device D(B) sends the message NOT CHGOWN via the communication link to inform controller A that the owner has not yet been changed.

[0108] - Following the change of ownership, the TEE of controller B's device also has a stop-run token T (see...) Figure 6A The controller B then generates a stop proof and pushes a transfer request PUSONL(B) containing the token unique identifier Tid, the stop proof COTS(B), and the generated single-use ownership challenge signature SUOCS(B) online to the server S.

[0109] Upon receiving the transmission request PUSONL(B), server S checks whether the request is valid, and if the request is valid, server S makes the corresponding change in the database DB to query the token ownership of the token T (i.e., the token with the unique token identifier Tid).

[0110] Figures 6A-6B An embodiment of the operation according to the present invention is shown in which device D(B) of controller CB, having received a token from controller CA of device D(A), stops running token RT and pushes the corresponding transmission request PUSONL online. When the TEE of device D(B) of controller CB stops running offline token RT (STOP RT):

[0111] - The TEE of device D(B) of controller CB generates a checkable one-time signature COTS(B)[RT](GEN COTS(B)[RT]), proving that the offline token RT has been stopped. Device D(B) generates a one-time use ownership signature SUOCS(B))(GENSUOCS(B)), proving that controller B is the owner of the running token. Device D(B) pushes a transmission request containing the token unique identifier Tid of the (stopped) token, the checkable one-time signature COTS(B), and the one-time use ownership signature SUOCS(B) online to the server S PUSONL(B)[Tid, COTS(B), SUOCS(B)];

[0112] Upon receiving the transmission request PUSONL(B), server S checks the validity of the transmission request PUSONL(B) by performing the following steps (see...). Figure 6A The subgraph "alt[when OK]":

[0113] a) Check if the token with the received token's unique identifier Tid is indeed offline. Server S retrieves the token ownership challenge Toc(GET[Tid,Toc]) corresponding to Tid from the database. Then, server S verifies whether the token corresponding to VER OFFLINToc is indeed offline.

[0114] b) Verify the validity of the received checkable one-time signature COTS(B). If valid, then challenge the ownership of token Tid by sending the obtained token ownership challenge Toc online to device D(B). Upon receiving the token ownership challenge Toc, device D(B) sends a corresponding response ANS(Toc) to server S, and server S verifies the received response to the token ownership challenge Toc and the received checkable one-time signature VER COTS(B) via VERANS(Toc). If both ANS(Toc) and COTS(B) are valid, server S generates a new token ownership challenge Toc' (Toc' = FUN[SUOCS(B)]) based on the received single-use ownership signature SUOCS(B) of controller CB, and replaces the token ownership challenge Toc (REP Toc' → Toc) in database DB with the new token ownership challenge Toc' indicating that the owner of the token corresponding to Tid is controller CB, and sends a corresponding confirmation message CM to device D(B).

[0115] The controller CB of device D(B) can check whether server S has indeed changed the ownership of the transmission token with the token's unique identifier Tid by sending the corresponding ownership query QRYOWN[Tid] (see [link]). Figure 6A The subgraph "loops [until RES or timeout]").

[0116] The advantage of the offline transmission described above according to the invention is that, in the case where the token ownership challenge Toc of the running token RT has been changed to the token ownership challenge Toc' supporting the controller CB, both the controller CA and the controller CB have copies of the running token RT in their respective TEEs, but only the controller CB can prove ownership. Therefore, the running token RT cannot be further used (or transmitted) by the controller CA, and can only be used by the controller CB to control the operations corresponding to the token allocation data (via the device D(B)).

[0117] Another advantage of the offline transmission described above according to the invention is that, after the ownership of the token is transferred to the supporting controller B, the controller CA is interested in stopping the operation of the (copy) of the token and deleting it to save energy (e.g., battery energy) of the device D(A).

[0118] In the preferred mode, at device D(B) of controller CB, which communicates offline with the TEE of device D(A) of controller CA (i.e., communication via local communication link CL), the TEE of device D(B) of controller B performs the aforementioned operation of checking (ii) whether token T is owned by controller CA via the zero-knowledge proof protocol ZKP. Therefore, only controller CA and CB of devices D(A) and D(B) know that token T is being transmitted, while server S only knows that token T is running offline.

[0119] Furthermore, in the preferred mode, at the device D(B) of controller B, which communicates offline with the communication unit of device D(A) of controller CA, the TEE of device D(B) of controller B performs the above-mentioned operations via dynamic system state synchronization / reconstruction (see

[12] ,

[13] ) and zero-knowledge proof ZKP for TEE signature to check (iii) whether the token T is indeed running in the trusted execution environment TEE of device D(A) of controller A.

[0120] The purpose of running proofs is to prevent some simple fraud / attacks that can "double-use" (i.e., copy and replay) tokens:

[0121] - Copying: Dynamic tokens prevent double use by preventing the validity of a simple static copy. For example, a simple static copy can be obtained when the token to be used is exposed to device B; that is, a second copy of the token owned by controller A is obtained by simulating controller B through controller A.

[0122] - Replay: Even with dynamic tokens, fast-forward and replay attacks must be prevented to prevent double use. These attacks aim to create a copy of the token that can be used within a finite amount of time; that is, to quickly pre-calculate the future state of the token's forward time for a given number of minutes, and then use both the original token and the fast-forwarded copy by replaying the token within said number of minutes (at the correct speed).

[0123] Therefore, the proof of operation must meet the following requirements:

[0124] As is often the case in cryptography, the cryptographic computations that run a proof must be hard to compute / forge, but easy enough to verify.

[0125] - It must be verifiable primarily within the time slot of its validity (computational complexity);

[0126] - Its effective time slot must be comparable to the execution time of offline transmission (e.g., from seconds to tens of seconds) to prevent multiple parallel / sequential uses (a variant of replay attacks);

[0127] - The proof must ensure that the token has run the required number of steps / iterations since it was retrieved offline, thus proving its partial validity (the server signature proof and ownership signature proof still exist);

[0128] - This method should prevent fast-forward and replay attacks.

[0129] In some other use cases, known solution requirements (with different names) that are very similar to those disclosed in this paper are encountered, for example:

[0130] - Mobile phone-based non-gated public transport ticketing (see

[14] ,

[15] ,

[16] ), in which various solutions are proposed to demonstrate that ticketing / metering trust applications (TA, see

[17] ) never stop during the trip, even when offline; most solutions rely on an increasing number of dedicated registers in the TEE;

[0131] - Prove the elapsed time in the permissioned blockchain consensus protocol (see

[18] ,

[19] ,

[20] ), which proposes a solution using Intel’s Trust Execution Environment (SGX) to ensure two things: 1) the participating nodes genuinely choose a shorter duration of time that is indeed random and not deliberately chosen by the participants to win, and 2) the winner has indeed completed the waiting time; the latter is of interest here.

[0132] Here, for the purpose of enabling tokens offline, these known solutions can be mixed and matched to construct various possible implementations of the proof of operation, following several alternative embodiments.

[0133] a) TEE's Incrementing Register + TEE Signature: This specific implementation is entirely similar to some solutions used in non-gated public transport ticketing. In this simple case, the TEE provides a tamper-evident register that increments in fixed steps over time; when a token is retrieved offline, D(A)TEE receives and stores the retrieval time's (server S) signed timestamp and starts a counter (register). After verification, D(A)TEE exposes the server timestamp and the TEE signature value of the register; D(B)TEE verifies the server timestamp with the server's public key, verifies the register with the TEE public key, and then verifies that the counter / register value is compatible with the current time and the retrieval time: i.e.

[0134] currentTime = fetchTime + countervalue * DT (with appropriate tolerance), where DT is the sampling time when the register is updated; therefore, it is proven that the token trust application in the TEE never stops.

[0135] The implementation is very simple, with very low computational costs for both generation and verification; however, it is almost entirely independent of TEE hardware and trust models.

[0136] b) Non-trival Dynamic System + Elapsed Time Proof from TEE: This particular embodiment utilizes existing proven time mechanisms in the art to prevent fast-forward and replay attacks, while simultaneously enabling rapid verification of the non-trival iterative dynamic system. In this case, the proof consists of two parts: the initial (X(0)) and current state X((n)) of the non-trival dynamic system (e.g., a chaotic or pseudo-random generator of the form X(n+1) = F(X(n), P), where X(n) is the state at iteration n and P is a vector of control parameters), and proves that it has been iterated by the TEE with the correct step size, i.e., each step from n to n+1 has been separated into a fixed amount of time DT. When the token is retrieved offline, the D(A)TEE receives and stores (signed by the server S): 1) the timestamp of the retrieval time (as in the previous implementation); 2) a set of control parameters P (bifurcation parameters) defining the settings of the non-trival dynamic system; and 3) the initial conditions X(0) of the dynamic system. The TEE uses the public key of server S to verify the server's signature and immediately begins iterating over the dynamic system, updating the state of the dynamic system (X(n+1) = F(X(n), P)) with a fixed step size DT. Furthermore, for each update step, the TEE generates a proof of the elapsed time DT before performing the state update and adds it (AND operator) to the total proof of elapsed time. The proof of elapsed time consists of the number of iterations performed and the total elapsed time, both of which are signed by the TEE. After verification, D(A)TEE exposes: the server timestamp, parameter P, and initial condition X(0) (all signed by the server); and the current state X(n), the number of iterations n, and the total elapsed time (all signed by the TEE). D(B)TEE verifies server information using the server public key and TEE information using the TEE public key. Then it verifies that the proven elapsed time value is compatible with the current time and the fetch time (as in the previous embodiment, currentTime = fetchTime + elapsedTime with appropriate tolerance). Finally, it iterates the dynamic system n times from X(0) to X(n) using parameter P and verifies that the same current state as the state required by the TEE is obtained. Therefore, it is finally proven that the token trust application in the TEE has been executed as expected and has never stopped.

[0137] The latter implementation is slightly more complex than the previous embodiment. For both generation and verification, the latter implementation still has a moderately low computational cost (still higher than the previous case). However, on the other hand, it slightly alleviates the root of trust in the TEE hardware (which is still the only root of trust over time) and adds further cross-checking of the iterative nontrivial dynamic system, which links the root of trust to the server (verifiable receive timestamps X(0) and P) and the integrity of the TEE (always correctly calculating X(n+1) = F(X(n), P)).

[0138] c) Thick Tokens Based on Light Blockchain: This particular embodiment is a further development of the previous embodiment, designed to further reduce the exclusivity of the root of trust in the TEE hardware. For this implementation, the components are essentially the same as the previous implementation, wherein, instead of accumulating proofs of the number of times and iteration steps elapsed, the TEE must generate (computably incalculable) proofs for each executed iteration in the form of a blockchain based on information received from the server S at the time of offline extraction and utilizing blocks for each iteration step. Again, when the token is extracted offline, the D(A)TEE receives and stores (signed by the server): 1) a timestamp of the extraction time; 2) a set of control parameters P defining the settings of the nontrivial dynamic system; and 3) the initial conditions X(0) of the dynamic system. The TEE uses the server's public key to verify the server's signature and: first, creates a proof or runs the root node of the blockchain using the information received from the server, then immediately begins iterating the dynamic system to update its state (X(n+1) = F(X(n), P)), and appends a block to the blockchain for each iteration step. Each block contains a link to the previous block via the hash value of the previous block, the state X(n) of the dynamic system, the current timestamp, and a random number used to solve a relatively easy cryptographic problem, thus providing proof of work. The final block is signed by the TEE. The combination of proof of work and TEE signature prevents fast-forward computations either inside or outside the TEE. After verification, the D(A)TEE exposes the entire blockchain computed beforehand, and after verifying the signature (server S and TEE), the D(B)TEE uses standard blockchain verification techniques to verify the proof that the entire blockchain has been verified; therefore, it proves that the token trust application in the TEE has been executed as expected and has never stopped.

[0139] Both in terms of generation and verification, and in terms of computational power and memory, this implementation significantly mitigates the root of trust in TEE hardware integrity at the cost of greater computational complexity. On the one hand, cryptographic puzzles, even if simply compatible with TEE computational capabilities, still require a dedicated time interval to solve. On the other hand, token proofs grow linearly over time. Assuming a block size of approximately 75 bytes (16-byte hash, 4×8-byte state, 8-byte timestamp, 2-3 bytes random number, 16-byte signature) and a sampling rate of approximately 10 seconds (which is a reasonable maximum span for keeping tokens offline), running the proof over a week would have grown to approximately 4MB, a reasonable but still significant size, especially for individual offline tokens.

[0140] According to the present invention, an alternative embodiment related to a run proof without reconstruction is described below, wherein it is required to be able to internally enforce and externally verify whether the token is running and operating within the TEE. To this end, the internal current state of the trust application (TA) running the token should be exposed from the controller CA device D(A)TEE to the controller CB device D(B), such that the D(B)TEE can verify the consistency of the exposed state with the assumption that the token has been "running" since it was retrieved offline, i.e., verify the run proof. Depending on the chosen embodiment of the run proof, the exposure and observation of the "running" state can be implemented in two possible ways:

[0141] 1. By indirectly exposing the dynamically changing state, and by employing dynamic system reconstruction techniques to completely reconstruct (synchronize) the internal state (see

[12] ,

[13] ); or

[0142] 2. By directly exposing the dynamically changing state, and thus observing the state directly from a dedicated channel (such as NFC, BT, BTLE, or display-to-camera communication).

[0143] The first case is of interest when the running dynamic system following the offline token is designed to run at a faster pace than the step size of issuing the running proof (time signature) (see above). In this case, it may be of interest to reconstruct (synchronize) the rapidly changing dynamic system using a dynamic system synchronization algorithm and verify, at a lower step size, that the state change rules do indeed satisfy the two-part proof of the run: the rapid change rules are based on the expected pattern of the segment, and the extracted parameters correspond to the time signature of the running proof.

[0144] The second scenario is of interest when the running dynamic system following the offline token and the issuance of its running proof are synchronized, in which case all the information required for verifying the running proof is explicitly exposed (transmitted) from device D(A) to device D(B) via the selected channel. For example, assuming a newer running proof must be issued every 10 seconds (a very reasonable step size), and data transmission and computation time should be shared fairly, the following maximum data exchange size will be obtained:

[0145] -NFC: ~256KB

[0146] -BTLE: ~640KB

[0147] -BT: 1.2MB

[0148] - Screen to camera (Full HD camera 20fps): ~3MB

[0149] These are perfectly reasonable amounts of data exchange and verification for all running proof implementations (except for the thick token). For the thick token, only Bluetooth, screen-to-camera, or combined connections are feasible.

[0150] According to an example implementation of the invention, the changing state of the running token can be securely exposed via a connection from the TEE of device D(A) of controller A to an externalized peripheral device (see above) (i.e., without the possibility of malicious interference from a third party or even controller A). Similarly, the state can be securely observed (i.e., without the possibility of malicious interference from a third party or even controller B) via the TEE of device D(B) of controller B (from exposure). This specific implementation of the zero-knowledge transfer method provides maximum security against any intrusion attempt.

[0151] Preferably, in the offline transmission according to the present invention, controller A changes the token ownership challenge of the running token to support controller B by unintentional calculation at device D(A) of controller A when communicating offline with device D(B) of controller B.

[0152] Figure 6B The subgraph “[T@A]” illustrates the aforementioned offline transmission scenario, where the TEE of device D(A) of controller CA fails to execute the offline token with the token unique identifier Tid, or prematurely stops executing the offline token (before it is transmitted to controller CB). In this case:

[0153] - Device D(A) instructs its TEE to STOP RT to stop running token RT, and the processing unit PU of D(A) TEE generates GEN COTS(A)[RT] which can be checked by a one-time signature COTS(A) to prove that the offline token RT has been stopped, and the processing unit PU of device D(A) of controller CA generates a one-time use ownership signature SUOCS(A) corresponding to the token ownership challenge of controller CA.

[0154] - Controller A sends a request PUSONL(A)[Tid, COTS(A), SUOCS(A)] to server S via communication network CN through the communication unit of device D(A). The request instructs server S to return the offline token T with the token unique identifier Tid, along with the checkable one-time signature COTS(A) and the one-time use ownership signature SUOCS(A) to the online network.

[0155] Upon receiving the return request PUSONL(A), server S checks whether the request PUSONL(A) is valid by performing the following steps:

[0156] 1) Server S retrieves the token ownership challenge Toc from database DB using the GET[Tid, Toc] method, where Toc is the token with the unique token identifier Tid (see [link to database DB]). Figure 6B The subgraph in the image is "alt(on success)" and the VER OFFLIN Toc token is indeed offline, then...

[0157] 2) Server S sends the obtained challenge Toc to device D(A) and verifies VER ANS(Toc), COTS(A)[RT], the response ANS(Toc) sent back by device D(A), and the verifiable one-time signature COTS(A). If they are valid, the server generates Toc' = Fun[SUOCS(A)] controller CA's ownership challenge Toc' based on the received one-time use ownership signature SUOCS(A), replaces the stored token ownership challenge Toc with the new token unique identifier Tid in the database DB, and sends the corresponding confirmation message CM to device D(A). The controller CA of device D(A) can check the ownership by sending the ownership query QRYOWN[Tid] to server S via D(A)'s communication unit (see [link]). Figure 6BThe subgraph "loop [until RES or timeout]" determines whether the offline token with the unique token identifier Tid is indeed owned. In response to the query, server S obtains the corresponding Toc from GET[Tid, Toc]DB and sends the token ownership challenge Toc back to D(A), verifies RES = VER ANS(Toc) (D(A)'s response to the ownership challenge ANS(Toc)), and sends the result of the verification RES back to D(A).

[0158] If any of the above verifications fails, server S sends the corresponding failure message FM to device D(A).

[0159] According to another aspect, the aforementioned invention, which allows the secure exchange of tokens between two devices based on a combination of a running (digital) token (which renders any static or past copies of the token useless) and a cross-device verification function, can also be used in the context of online / offline (i.e., internet on / off) exchange of digital value tokens (representing monetary amounts) between two parties, CA and CB. In this case, the controller may correspond to the owner of the digital value tokens (e.g., an individual or a company), devices D(A) and D(B) may correspond to the corresponding mobile devices of the owners CA and CB (e.g., smartphones, tablets, etc.), and the server S may correspond to the authority to possess a large amount of digital value tokens (e.g., a central bank). In this case, the token data allocated by the server may correspond solely to the face value (monetary amount) of the tokens, along with an authorized digital signature (as proof of the large amount).

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

[0161] References

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

[0163] [2] https: / / en.wikipedia.org / wiki / Trusted_execution_environment (Edited at 13:04, November 15, 2020 (UTC)).

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

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

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

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

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

[0169] [8]Wikipedia."Signatures with efficient protocols",

[0170] https: / / en.wikipedia.org / wiki / Signatures_with_efficient_protocols (edited on 14 December 2020 at 02:13 (UTC)).

[0171] [9]Goldwasser S.,Ostrovsky R.(1993)Invariant Signatures and Non-Interactive Zero-Knowledge Proofs are Equivalent.In:Brickell EF(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.

[0172]

[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.

[0173]

[11] Knox,DAnd Adams,C."Digital credentials with privacy-preservingdelegation," July 15, 2011, https: / / doi.org / 10.1002 / sec.213, (available at https: / / onlinelibrary.wiley.com / doi / full / 10.1002 / sec.213).

[0174]

[12] https: / / en.wikipedia.org / wiki / State_observer(2020 / 11 / 12 / 07:16(UTC))

[0175]

[13] Kevin McGoff,Sayan Mukherjee,Natesh S.Pillai:"StatisticalInference for Dynamical Systems:A review".2012.https: / / arxiv.org / pdf / 1204.6265.pdf。

[0176]

[14] Ekberg,Jan-Erik&Kostiainen,Kari&Asokan,N..(2014):―The UntappedPotential of Trusted Execution Environments on Mobile Devices”,Security&Privacy,IEEE.12.29-37.10.1109 / MSP.2014.38。

[0177]

[15] Ekberg JE.,Tamrakar S.(2012):―Mass Transit Ticketing with NFCMobile Phones”.In:Chen L.,Yung M.,Zhu L.(eds)―Trusted Systems”.INTRUST2011.Lecture Notes in Computer Science,vol.7222.Springer,Berlin,Heidelberg。

[0178]

[16] Tamrakar S.,Ekberg JE.(2013):―Tapping and Tripping with NFC”.In:Huth M.,Asokan N., S.,Flechais I.,Coles-Kemp L.(eds)―Trust andTrustworthy Computing”.Trust 2013.Lecture Notes in Computer Science,vol7904.Springer,Berlin,Heidelberg。

[0179]

[17] ―TEE System Architecture v1.2”|GPD_SPE_009, published December 2018, https: / / globalplatform.org / specs-library / tee-system-architecture-v1-2 / .

[0180]

[18] Sawtooth v1.0.5 documentation: PoET 1.0 Specification,

[0181] https: / / sawtooth.hyperledger.org / docs / core / releases / 1.0 / architecture / poet.html.

[0182]

[19] Medium: Understanding Hyperledger Sawtooth—Proof of Elapsed Time. February 20, 2018,

[0183] https: / / medium.com / kokster / understanding-hyperledger-sawtooth-proof-of-elapsed-time-e0c303577ec1.

[0184]

[20] G. Prisco. Intel Develops ‘Sawtooth Lake‘ Distributed Ledger Technology For The Hyperledger Project. Bitcoin Magazine, April 11, 2016,

[0185] https: / / bitcoinmagazine.com / articles / intel-develops-sawtooth-lake-distributed-ledger-technology-for-the-hyperledger-project-1460397461.

Claims

1. A method for controlling multiple devices via a server connected to a database, each device being equipped with a processing unit, a communication unit, and a hardware trust execution environment (TEE) with memory, the TEE being securely connected to the communication unit via a dedicated secure hardware path, and each device being controlled by a corresponding controller, the communication units being adapted to securely communicate with each other via a wireless or wired point-to-point communication link for offline communication, the server being adapted to securely communicate with the communication units of each device via a wired or wireless communication network for online communication, the server and the communication units being adapted to transmit data using an encryption protocol, and the server and the TEE of each device being adapted to respond to verification challenges and generate and verify a single-use ownership digital signature and its corresponding ownership signature verification challenge via a zero-knowledge proof protocol (ZKP). The method is characterized by: The database managed by the server stores digital tokens. Each token delivered by the server includes a unique token identifier, corresponding token data assigned by the server and including the server's signature, and a token ownership query corresponding to the unique controller that owns the token, wherein the token is owned by the server to the unique controller. In the event that a token owned by controller A of device A is transmitted offline to another controller B of another device, controller A first sends an offline transmission request to the server via online communication using the device's communication unit. The offline transmission request includes the token's unique identifier and a one-time use offline signature of the Trusted Execution Environment (TEE) of controller A's device. Upon receiving the offline transmission request, the server checks that the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A. Upon receiving and verifying the token ownership query response from controller A, the server verifies that the one-time use offline signature of the TEE is valid. If the one-time use offline signature of the TEE is valid, the server replaces the token ownership query corresponding to the token's unique identifier with a TEE ownership query corresponding to the one-time use offline signature of the TEE, and sends back a confirmation message indicating successful replacement of the token ownership query along with the data required for controller A's device's TEE to begin executing the token. If the one-time use offline signature of the TEE is invalid, the server sends back a corresponding failure message corresponding to the invalid one-time use offline signature of the TEE to controller A. Upon receiving the confirmation message, the TEE of controller A's device begins executing the token, and the communication unit of controller A's device exposes the running token to the communication unit of controller B's device. Then, controller B continuously observes the running token, synchronizes with the running token, and checks it within the trusted execution environment of controller B's device. (i) The token is signed by the server. (ii) The token owner is controller A, and (iii) The token is running in the trusted execution environment of the device of controller A; Then, the device of controller A changes the token ownership challenge of the running token to support controller B, and controller B continuously observes copies of the token with the changed token ownership challenge within the trusted execution environment of the device of controller B. The TEE of the device of controller B stops running the token and generates a stop certificate. Then, controller B pushes a transmission request containing the unique identifier of the token, the stop certificate and the changed token ownership query to the server online. Upon receiving the transmission request, the server checks that the request is valid. If the request is valid, the server makes the corresponding change for the token ownership query in the database.

2. The method of claim 1, wherein, In step (ii), at the device of controller B, which is communicating offline with the communication unit of the device of controller A, the TEE of the device of controller B checks whether the token owner is controller A via the zero-knowledge proof protocol, namely the ZKP protocol.

3. The method of claim 1 or 2, wherein, At step (iii), at the device of controller B, which is communicating offline with the communication unit of the device of controller A, the TEE of the device of controller B checks whether the token is running in the trusted execution environment of the device of controller A via dynamic system state synchronization / reconstruction and the ZKP protocol for TEE signing.

4. The method of claim 1 or 2, wherein, The controller A, through an unintentional calculation at its device that communicates offline with the device of controller B, changes the token ownership challenge of the running token to support controller B.

5. The method according to claim 1 or 2, wherein, When the TEE of the device controlled by controller B stops running the offline token, The device of controller B generates a TEE that proves the offline token has been stopped and contains a verifiable one-time signature that includes a verifiable check of the original TEE single-use offline signature, and the device of controller B generates a single-use ownership challenge signature. Controller B adds the verifiable one-time signature, the provable check of the original TEE single-use offline signature, and the single-use ownership challenge signature to the transmission request, and pushes the transmission request online to the server; as well as Upon receiving the transmission request, the server checks whether the transmission request is valid by performing the following steps: The check confirms that the token with the unique identifier of the received token is indeed offline, and then, in the case that the token is offline, The received one-time signature is verified to be valid. Then, if the one-time signature is valid, ownership is challenged using a single offline signature via the received original TEE. If the received single-use ownership challenge signature is valid, and if the single-use ownership challenge signature is valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with the received modified token ownership challenge.

6. The method of claim 1 or 2, wherein, In the event that the token fails to run on the TEE of device A, or if the token is stopped from running before it is transmitted to device B, The TEE of the device of controller A generates a verifiable one-time signature proving that the offline token has been stopped, and the device of controller A generates a one-time use ownership query signature corresponding to the new token ownership query of controller A. The controller A sends a return request to the server, the return request instructing the server to return the token, along with the verifiable one-time signature and the one-use ownership challenge signature, back online; Upon receiving the return request, the server checks the validity of the request by performing the following steps: Verify that the token is indeed offline, then The original TEE is challenged using a one-time offline signature, and then the received one-time signature is verified to be valid. If the one-time signature is valid and the received one-time ownership challenge signature is verified to be valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with a new token ownership challenge.

7. The method of claim 1 or 2, wherein, In the case of transmitting a token owned by controller A of one device online to another controller B of another device, the transmission includes: controller A sending a unique token identifier of the token to be transmitted to controller B via the communication unit of the device; controller B sending back a one-time use ownership query signature via the communication unit of the other device; controller A sending a transmission request to the server, the transmission request specifying the unique token identifier and the received one-time use ownership query signature of controller B; upon receiving the transmission request, the server checks that the unique token identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A; upon receiving and verifying the ownership response from controller A, the server verifies that the one-time use ownership signature of controller B in the transmission request is valid; if the one-time use ownership signature is valid, the server replaces the token ownership query corresponding to the unique token identifier with the token ownership query corresponding to controller B, and sends a transmission confirmation back to controller A; and if the one-time use ownership signature is invalid, the server sends a transmission failure message back to controller A.

8. A system for controlling multiple devices via a server connected to a database, each device being equipped with a processing unit, a communication unit, and a hardware trust execution environment (TEE) with memory, the TEE being securely connected to the communication unit via a dedicated secure hardware path, and each device being controlled by a corresponding controller, the communication units being adapted to securely communicate with each other via a wireless or wired point-to-point communication link for offline communication, and the server being adapted to securely communicate with the communication units of each device via a wired or wireless communication network for online communication, the server and the communication units being adapted to transmit data using an encryption protocol, and the server and the TEE of each device being adapted to respond to verification challenges and generate and verify a single-use ownership digital signature and its corresponding ownership signature verification challenge via a zero-knowledge proof protocol (ZKP). The system is characterized by: The server is adapted to deliver digital tokens and store the delivered tokens in a database. Each token delivered by the server includes a unique token identifier, corresponding token data assigned by the server and including the server's signature, and a token ownership query corresponding to a unique controller that owns the tokens belonging to the server. The system is configured to perform offline transfers of tokens owned by controller A of one device to another controller B of another device. Controller A first sends an offline transmission request to the server via online communication using the device's communication unit. The offline transmission request includes the token's unique identifier and the Trusted Execution Environment (TEE) single-use offline signature of Controller A's device. Upon receiving the offline transmission request, the server checks that the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to controller A. Upon receiving and verifying a token ownership challenge response from controller A, the server verifies that the TEE single-use offline signature is valid. If the TEE single-use offline signature is valid, the server replaces the token ownership challenge corresponding to the token unique identifier with a TEE ownership challenge corresponding to the TEE single-use offline signature, and sends back a confirmation message indicating successful replacement of the token ownership challenge along with the data required for the TEE of controller A's device to start executing the token. If the TEE single-use offline signature is invalid, the server sends back a corresponding failure message to controller A corresponding to the invalid TEE single-use offline signature. Upon receiving the confirmation message, the TEE of controller A's device begins executing the token, and the communication unit of controller A's device exposes the running token to the communication unit of controller B's device. Then, controller B continuously observes the running token, synchronizes with the running token, and checks it within the trusted execution environment of controller B's device. (i) The token is signed by the server. (ii) The token owner is controller A, and (iii) The token is running in the trusted execution environment of the device of controller A; Then, the device of controller A changes the token ownership challenge of the running token to support controller B, and controller B continuously observes a copy of the token with the changed token ownership challenge in the trusted execution environment of controller B's device. The TEE of controller B's device stops operating the token and generates a stop certificate. Then, controller B pushes a transmission request online to the server containing the token's unique identifier, the stop certificate, and a challenge to the changed token ownership. Upon receiving the transmission request, the server checks if the request is valid, and if so, the server makes the corresponding change in the database regarding the token ownership query.

9. The system of claim 8, wherein, In order to perform the operation of checking (ii) that the token owner is controller A, the TEE of the device of controller B is configured to check that the token owner is controller A via the zero-knowledge proof protocol, i.e., ZKP protocol, at the device of controller B which communicates offline with the communication unit of the device of controller A.

10. The system of claim 8 or 9, wherein, In order to perform the operation of checking (iii) that the token is running in the Trust Execution Environment of the device of Controller A, the TEE of the device of Controller B is configured to check, via dynamic system state synchronization / reconstruction and the ZKP protocol for TEE signing, at the device of Controller B which communicates offline with the communication unit of the device of Controller A.

11. The system of claim 8 or 9, wherein, Controller A is configured to inadvertently change the token ownership challenge of the running token to support Controller B via an offline communication unit at the device of Controller A.

12. The system of claim 8 or 9, wherein, The system is configured such that when the TEE of the device of controller B stops running offline tokens, The device of controller B generates a TEE that proves the offline token has been stopped and contains a verifiable one-time signature that includes a verifiable check of the original TEE single-use offline signature, and the device of controller B generates a single-use ownership challenge signature. Controller B adds the verifiable one-time signature, the provable check of the original TEE single-use offline signature, and the single-use ownership challenge signature to the transmission request, and pushes the transmission request online to the server via the communication unit of the controller B's device; as well as Upon receiving the transmission request, the server checks whether the transmission request is valid by performing the following operations: The check confirms that the token with the unique identifier of the received token is indeed offline, and then, in the case that the token is offline, The received one-time signature is verified to be valid. Then, if the one-time signature is valid, ownership is challenged using a single offline signature via the received original TEE. If the received single-use ownership challenge signature is valid, and if the single-use ownership challenge signature is valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with the received modified token ownership challenge.

13. The system of claim 8 or 9, wherein, The system is configured to stop running the token if the TEE of controller A fails to execute the token, or if the token is not transmitted to controller B's device: The TEE of the device of controller A generates a verifiable one-time signature proving that the offline token has been stopped, and the device of controller A generates a one-time use ownership query signature corresponding to the new token ownership query of controller A. The controller A sends a return request to the server via online communication through the communication unit of the controller A device. The return request instructs the server to return the token, along with the verifiable one-time signature and the one-time use ownership challenge signature, to the online server. Upon receiving the return request, the server checks whether the request is valid by performing the following operations: Verify that the token is indeed offline, then The original TEE is challenged using a one-time offline signature, and then the received one-time signature is verified to be valid. If the one-time signature is valid and the received one-time ownership challenge signature is verified to be valid, the token ownership challenge stored in the database for the token's unique identifier is replaced with a new token ownership challenge.

14. The system of claim 8 or 9, wherein, The system is configured such that, in the case of an online transfer of a token held by controller A of one device to another controller B of another device, the transfer is performed by the following operations: The unique identifier of the token to be transmitted is sent to the controller B via offline communication between the communication unit of the controller A's device and the communication unit of the controller B's device; The controller B sends back a single-use ownership query signature via offline communication between the communication unit of the controller B device and the communication unit of the controller A device; The controller A sends a transmission request to the server via online communication through the communication unit of the controller A's device. The transmission request specifies the unique identifier of the token and the single-use ownership challenge signature received from the controller B. Upon receiving the transmission request, the server checks that the token's unique identifier is stored in the database along with the corresponding token ownership query, and then sends the token ownership query to the controller A via online communication with the communication unit of the device of the controller A. Upon receiving and verifying an ownership response from controller A via online communication with the communication unit of the device of controller A, the server verifies that the single-use ownership signature of controller B in the transmission request is valid; If the single-use ownership signature is valid, the server replaces the token ownership query corresponding to the token unique identifier with a token ownership query corresponding to controller B, and sends a transmission confirmation back to controller A via online communication with the communication unit of the device of controller A. as well as In the event that the single-use ownership signature is invalid, the server sends a transmission failure message back to controller A via online communication with the communication unit of the device of controller A.

Images