Computer-implemented method for authenticating a first device to a second device

Abstract

Method for authenticating a first device to a second device, the method comprising:      receiving, by the first device a secret information and a SUIT which comprises a result information being a result of a problem obtained using the secret information on the problem;      sending the SUIT from the first device to the second device;      executing a ZKP suitable for the problem included in the SUIT, including prompting the first device to provide a proof information;      verifying, by the second device, that the proof information received from the first device is indicative of the secret information solving the problem specified by the SUIT;      if this is confirmed, authenticating the first device, and authorizing a transaction with the first device; and      in case of a triggering event involving the first device, recovering the real identity associated with the first device.Fig. 1

Description

COMPUTER-IMPLEMENTED METHOD FOR AUTHENTICATING A FIRST DEVICE TO A SECOND DEVICE TECHNICAL FIELDThe present invention is directed at a computer-implemented method for authenticating a first device to a second device. The present invention is further directed at a system for authenticating a first device to a second device. BACKGROUND ARTIt is known to interconnect several devices via wired or wireless networks so that they cooperate to perform various tasks. Example of such devices include industrial robots executing operations within a factory according to industrial manufacturing processes or within a warehouse to store and move goods according to transportation or delivery processes, but also mobile devices like mobile phones, laptops or tablet computers, or Internet of Things (IoT) devices. All those devices must exchange data between each other.  There is a need for improving security and robustness in controlling execution of operations performed by interconnected devices, particularly in case the devices are not owned (or under full control) by a same entity or person, meaning that the devices cannot necessarily trust one another. It is desirable for the devices to register with one another before they cooperate to ensure a certain level of trust and / or reliability on the other device. It is further desirable for the devices to cooperate in a privacy-preserving manner. An objective of the present invention is the provision of an improved authentication of a first device to a second device. SUMMARY OF THE INVENTIONAccording to a first aspect, a computer-implemented method for authenticating a first device to a second device using a single use identity token (SUIT) associated with the first device and generated by an N-th entity is provided. The N-th entity being part of a service comprising N entities with N≥1, the 1st entity mapping a real identity associated with the first device to a 1st identification information, the real identity forming a 0-th identification information, if N≥2, the N-th entity mapping the (N-1)-th identification information with the SUIT, and if N≥3, each i-th entity creating an i-th identification information and mapping it to an (i-1)-th identification information and storing a mapping information about the mapping, wherein 2≤i≤N-1. The method comprises:receiving, by the first device, (i) a secret information provided by the N-th entity, and (ii) the SUIT which comprises a result information, the result information being a result of a problem obtained using the secret information on the problem, the problem being suitable for a zero knowledge proof (ZKP) and the SUIT being signed by the N-th entity through an N-th signature; sending the SUIT from the first device to the second device;by the second device, verifying the N-th signature of the received SUIT;if the second device validates the N-th signature, by the second device, executing the ZKP suitable for the problem included in the SUIT, the execution of the ZKP including prompting the first device to provide a proof information, the proof information being an indicator that the first device holds the secret information;in response to the prompt from the second device, sending the proof information from the first device to the second device;verifying, by the second device, that the received proof information is indicative of the secret information solving the problem specified by the SUIT;if the received proof information is indicative of the secret information solving the problem, authenticating the first device by the second device, and authorizing, by the second device, a transaction with the first device, the transaction including a subsequent exchange of data between the first and the second device; andin case of a triggering event involving the first device, recovering the real identity associated with the first device by (i) sending the SUIT received by the second device to the N-th entity to retrieve the (N-1)-th identification information, and (ii) if N≥2, recovering each (i-1)-th identification information with 1≤i≤N by sending each i-th entity the i-th identification information. This authentication method allows the second device to register (authenticate) the first device for transactions with the second device without knowing the real identity of the first device, wherein the real identity of the first device is however retrievable in case that this becomes desirable, by tracing the real identity of the first device back through a chain of N entities. As a result, the first and second devices can be used as interconnected devices while reducing any risks on either side regarding identity of the devices and the data transferred. The first and second devices can be devices used in an industrial context (such as robots or transport devices), computer devices, mobile devices (such as smartphones, laptops, tablets or the like) and / or Internet of Things (IoT) devices. The first and the second device can belong to a same organization or person, but are preferably owned by different organizations or persons, so that they do not trust one another and operate in an untrusted environment. The first and second devices can be meant to communicate through a wired or wireless network to jointly perform specific tasks, such as to exchange and / or store data, to assemble objects in a production site or the like. The first and the second device preferably each include a communication unit for communicating with one another, a processing unit for controlling information sent to the other device or received from the other device through the communication unit, and / or a storage unit for storing information to be sent to the other device or received from the other device. All communications between the first device, second device and N entities can be performed via a wired or wireless network. Moreover, all communications can be performed in an encrypted manner, using public and / or private keys. The service including N entities is preferably a system with several (N) actors which belong to yet another organization or person than the first and second devices. In particular, the service belongs to multiple organizations or persons. The N entities can be computer devices associated with an organization, a government, or the like. Jointly, the N entities can provide a chain of all identification information, thereby linking the real identity of the first device to any of its i-th identification information. Individually however, each of the N entities may only provide one chain link which maps the i-th identification information with the (i-1)-th identification information. The service of N entities preserves the first device’s privacy but can reveal the real identity of the first device by collaboration of all N entities, for example in case of an audit and / or a fraudulent activity. N is an integer of at least one. The larger N, the higher the privacy of the real identity of the first device. An individual entity in particular cannot reveal the real identity of the first device based on the SUIT. The real identity of the first device can include its owner’s name, an ID or passport number of the first device’s owner, and / or any other information allowing to uniquely identify the first device’s owner. The real identity of the first device can also include a serial number of the first device, and / or any other information allowing to uniquely identify the first device. Each of the identification information can be provided as a sequence of numbers and / or letters.  The chain of identification information held by the N entities in particular includes, in a storage unit of each entity i, storing the i-th identification information together with the (i-1)-th identification information. To create the chain of all identification information, the first entity creates the first identification information and stores it with the real identity received from the first device. The second entity (i=2) receives the first identification information from either the first device or the first entity, creates the second identification information and stores it with the first identification information received from the first device. This continues with increasing number of N until all entities have stored the identification information they created with the identification information of the previous entity. The identification information created by an i-th entity together with the identification information of the previous entity (i-1) forms the mapping information of the i-th entity. The N-th entity in particular does not create an N-th identification information but instead creates one or several SUITs, which are mapped to the (N-1)-th identification information. It could be said that the identification information of the N-th entity can form or include one or several SUITs, but it is to be noted that the SUITs have different formats and contents than the identification information of previous entities. In particular, each (N-1)-th identification information is mapped to multiple SUITs, each being used only once and not reused by the second device (hence “single use identity token”). The single use of each SUIT can be ensured using ZKP. In particular, ZKP ensures that SUITs cannot be reused by multiple interactions between users.   The SUIT can be a token that the N-th entity provides to the first device and which the first device requires to authenticate to the second device in order to perform a transaction. Only the N-th device can link the SUIT provided to the first device to the first device’s (N-1)-th identification information. The SUIT cannot directly reveal the real identity of the first device. In particular, only the N-th device can issue a valid SUIT for the first device. The SUIT can include a result to a problem, wherein said problem can take the form of an equation or the like, which has a variable that is set to a value corresponding to the secret information. The secret information is associated with the SUIT and provided to the first device by the N-th entity. The problem is suitable for a ZKP verification, meaning that the second device can use a ZKP to verify that the first device holding the SUIT indeed holds the secret information. The SUIT can be signed by a digital N-th signature of the N-th entity which allows verifying, by the second device, that the SUIT was legitimately issued by the N-th entity.  Before making a first transaction with a first device, the second device in particular authenticates the first device through the method steps described above. The transaction can include any exchange of data (in particular critical data) relating to a joint manufacturing or transport process, to a joint calculation, to a digital asset transfer or the like. To initiate the authentication, the first device can send one of its SUITs to the second device. The second device verifies the N-th signature of the received SUIT, thereby ensuring that the SUIT has indeed been generated by the N-th entity and has not been altered since generation. In case that the verification of the digital signature by the second device indicates that the SUIT is not generated by the N-th entity or has been altered, the second device does not authenticate the first device, thereby not allowing any transaction with the first device. In case that the verification of the digital signature by the second device indicates that the SUIT is generated by the N-th entity and has not been altered (validation of the N-th signature), the second device proceeds further with the authentication process and executes the ZKP. The ZKP is specific to the problem included in the SUIT so that it can be said that the ZKP is specified by the problem included in the SUIT, even though the ZKP is usually not part of the SUIT. The ZKP is a method that enables the first device (the prover) to convince another party, i.e. the second device (the verifier) of the truth of a statement (the proof information) while keeping all other knowledge about the statement a secret. In other words, it enables the prover to persuade the verifier that a certain claim is true without revealing any information about how they arrived at the answer. The ZKP can guarantee that sensitive information such as the secret information stays private during the verification process. The ZKP can be either an iterative ZKP (iZKP) or a non-iterative ZKP.  The fundamental properties of ZKP are:Completeness: If a statement is true, a honest verifier will be convinced of the proof of truth shared via an honest prover. An honest prover should be able to convince a honest verifier of its truth.Soundness: If a statement is false, an honest verifier will not be convinced by the proof of a cheating prover.Zero-knowledge: If the statement is true, the verifier will learn nothing about the statement itself besides its correctness. As part of executing the ZKP, the second device can ask (prompt) the first device to provide the proof information and if the first device holds the secret information, it provides the proof information to the second device. Depending on the nature of the problem, the secret information and / or the ZKP, the received proof information is indicative, within a predetermined probability, of whether the first device holds the secret information or not. Namely, if the problem is an equation, the secret information is for example said to solve the problem if a result of the equation corresponds to the result information when the secret information is used as a variable of the equation. The second device in particular includes a processing unit for analyzing the received proof information and determining whether or not it is indicative of a secret information solving the problem. If the proof information is indicative of the secret information solving the problem, the second device successfully authenticates the first device. Otherwise, if the proof information is not indicative of the secret information solving the problem, the second device can stop the authentication process of the first device. In case of a successful authentication, and in particular only in this case, the second device authorizes a transaction between the first and the second device. Such a transaction can be any action requiring an exchange of data between the first and the second device that is subsequent to the authentication of the first device to the second device. Preferably, the transaction includes an exchange of data required for a technical action, such as manufacturing data, robot control data or the like.  This authentication allows ensuring that the second device is communicating with a legitimate first device (i.e. with the first device as registered by the N entities), which provides a guarantee to the second device for data integrity and the like. Moreover, the first device does not have to share its real identity with the second device, ensuring privacy. The second device can however retrace the real identity of the first device if needed, for example in case of fraud.  In detail, the real identity of the first device can be retrieved by the second device and / or an auditor in case of a triggering event. Preferably, the real identity of the first device is retrieved only in case of the triggering event, and is otherwise kept hidden. The triggering event can be a fraud (for example a data leak of confidential data sent to by the second device to the first device) and / or an external audit by an auditor. To obtain the real identity of the first device, the chain of identification information held by the N entities needs to be unbundled by obtaining every single mapping information stored by each of the N entities. This is done by addressing the N entities in decreasing order. From the N-th entity, which maps the SUIT to the (N-1)-th identification information, the (N-1)-th identification information is obtained upon sending the N-th entity the SUIT. From the (N-1)-th entity, which maps the (N-1)-th identification information to the (N-2)-th identification information, the (N-2)-th identification information is obtained upon sending the (N-1)-th entity the (N-1)-th identification information. This process can be repeated for every entity until the 1st entity provides the 0-th identification information, which corresponds to the real identity of the first device. The real identity may be provided to the second device and / or to the auditor. In either case, the retrieving of the real identity requires the SUIT as provided to the second device and the collaboration of all individual N entities. Therefore, in case of necessity, the real identity of the first device can be retrieved, and it can be made available to the second device or to an auditor. This can allow to take necessary measures against the first device, such as to blacklist the first device, or make its owner pay a fine. The method of the first aspect relies on centralized identification (ID), in which the N entities are centrally responsible for providing and holding the identification information of multiple first devices at each level. The described method of the first aspect does not rely on verifiable credentials, and in particular does not require decentralized ID. In particular, the N-th device does not associate a verifiable credential to the SUIT. The secret information is in particular not part of a verifiable credential. According to an embodiment, the method further comprises:generating the SUIT by the N-th entity, comprising:by the first device, requesting the N-th entity for generation of the SUIT including sending the (N-1)-th identification information to the N-th entity;authenticating the first device to the N-th entity based on the (N-1)-th identification information; generating the SUIT and mapping it with the (N-1)-th identification information. The SUIT can be generated upon request by the first device by sending the (N-1)-th identification information to the N-th entity. The N-th entity may generate each SUIT with an associated validity timestamp, which indicates a time period during which the SUIT can be used. When the first device runs out of SUITs, the above method of generating one or several SUITs can be repeated.  According to a further embodiment, N≥2 and generating the SUIT by the N-th entity further comprises, before the step of generating the SUIT and mapping it with the (N-1)-th identification information:sending a SUIT generation request and the (N-1)-th identification information from the N-th entity to the (N-1)-th entity;by the (N-1)-th entity, validating the SUIT generation request under consideration of the received (N-1)-th identification information; sending an approval information from the (N-1)-th entity to the N-th entity; andgenerating the SUIT and mapping it with the (N-1)-th identification information by the governor device only upon receiving the approval information. The generation of the SUIT may require confirmation by the (N-1)-th entity about the (N-1)-th identification information, thereby ensuring that the N-th entity is indeed allowed to generate a SUIT in accordance with the (N-1)-th entity’s rules. According to a further embodiment,the ZKP is an interactive ZKP (iZKP);the execution of the ZKP including several instances of prompting the first device to provide a proof information; andthe step of authorizing, by the second device, the transaction with the first device being performed only if all the received proof information are each indicative of a secret information solving the problem specified by the SUIT. In interactive ZKPs (iZKPs), there is a need in multiple rounds of interaction between the prover and the verifier where in each round of interaction, the degree of trust that the verifier acquires in the prover is increasing. iZKPs often consist of decision problems for which a given solution can be verified as correct or incorrect in polynomial time by a deterministic Turing machine (nondeterministic polynomial time (NP) problems). Accordingly, in case of an iZKP, the second device asks the first device to provide a proof information in multiple iterations. Accordingly, the first device sends the second device a first proof information, and if the second device finds that the first proof information is indicative of the first device holding the secret information, the second device asks the first device to provide a further proof information. The first device then sends a further proof information and if the second device finds that the further proof information is also indicative of the first device holding the secret information, the second device asks the first device to provide yet another further proof information.  This can be repeated for a predetermined number of times or until one of the proof information received by the second device is not indicative of the first device holding the secret information, in which case the iZKP and the authentication process are stopped. When the second device receives M proof information, the second device’s degree of confidence in the first device holding the secret information is 1 – (1 / 2)^M. In the alternative case in which the ZKP is a non-iterative ZKP, there is a need for a single message from the prover to the verifier. Non-iterative-ZKPs are applicable where heavy computation on client-side is preferred over conducting multiple interactions between the parties to reduce communication between prover and verifier (e.g., in blockchain solutions and digital signatures). According to a further embodiment, the problem includes a discrete logarithm problem of the form (g^x) mod p, p being a prime number, g being a generator and x being the secret information. This will be described in greater detail here-below. According to a further embodiment, the problem includes a sudoku puzzle, wherein the secret information is a cell or cell group of the solved sudoku puzzle. The prover can claim a valid solution to a sudoku puzzle. The verifier challenges with random cells, and the prover responds without revealing the entire solution. The entire solution to the sudoku puzzle and / or part thereof can form the secret sudoku puzzle. According to a further embodiment, the problem includes a Hamiltonian circuit problem, wherein the secret information is a Hamiltonian path. The prover claims he holds a valid Hamiltonian circuit for a given graph (Hamiltonian path, corresponding to the secret information) without revealing the circuit details. The verifier challenges the prover to demonstrate that he can visit each vertex exactly once. According to a further embodiment, the problem includes a traveling salesman problem (TSP), wherein the secret information is a length of a Hamiltonian path. This is similar to the Hamilton circuit problem. The prover asserts a specific length Hamiltonian cycle in a city graph. The verifier is then challenged with random cities to show the ability to visit all within distance constraints without disclosing the actual tour. According to a further embodiment, the problem includes a 3-Coloring map puzzle, wherein the secret information is a full coloured graph. The prover claims a valid 3-coloring of a graph. The verifier challenges with random edges, and the prover responds without revealing the entire colouring (which is the secret information). According to a further embodiment, the problem includes a subset sum problem, wherein the secret information is a target sum of the subset sum problem. The prover convinces the verifier of a subset-sum to a specific value from a given set of numbers without revealing the subset elements. According to a further embodiment, the problem includes a Boolean satisfiability (SAT) problem, wherein the secret information is a statement satisfying a Boolean formula. The prover convinces the verifier that he can satisfy an assignment for a boolean formula. The verifier challenges with random variables, proving satisfiability without revealing the assignment. According to a further embodiment, the problem includes the discrete logarithm problem of the form (g^x) mod p, the SUIT including a value of (g^x) mod p, which is denoted S, wherein g and p are public information, wherein the execution of the ZKP by the second device includes:the second device asks the first device to share its value for C, wherein C = (g^r) mod p, r being an integer that is randomly chosen by the first device but unknown to the second device, wherein 0≤r<(p-1);the first device generates a random integer, sets it as r, calculates C for the generated random number, and transmits the calculated value of C to the second device;the second device asks the first device to prove its knowledge of the secret information by sending a random bit b to the first device;if b=0, the first device sends z=r to the second device, and if b=1, the first device calculates and sends z=(x+r) mod (p-1) to the second device, z forming the proof information;if b=0, the second device verifies whether C=(g^z) mod p holds, and if b=1, the second device verifies whether (S*C) mod p =(g^z) mod p holds, which is indicative that the received proof information is a secret information solving the problem. In this example, the construction of the SUIT relies on the discrete log problem (DLP). DLP is a prime candidate for iZKPs. The challenge lies in efficiently computing the exponent x to which a fixed number g must be raised to obtain another number S modulo p. To ensure confidentiality and authenticity, iZKPs allow the prover to prove knowledge of a secret exponent x (secret information) without disclosing it. DLP is a strong foundation for establishing trust and confidentiality in a variety of cryptographic protocols, including iZKPs, thanks to its mathematical properties that enable efficient and secure interactive interactions. The best practice to provide a sufficient level of security is to use a prime p, which is 2048 bits. “g” denotes an integer used as a public parameter in the protocol. “p” denotes a (large) prime number used as a public parameter in the protocol. “x” denotes the secret information held by the first device, i.e. the secret value that the first device wants to prove it knows without revealing it to the second device (verifier). “S” denotes an integer calculated as S = (g^x) mod p, wherein S can be part of the SUIT or correspond to the SUIT. “r” denotes a random integer generated by the first device in the protocol. “C” is calculated as C = (g^r) mod p, and sent by the first device to the second device as part of the protocol. “b” is a random bit (0 or 1) sent by the second device to the first device, challenging its response (proof information). “z” denotes the response (proof information) provided by the first device based on the challenge bit "b".  According to a further embodiment, the method further comprising repeating the step described in view of the execution of the ZKP for the DLP for a predetermined number of times.  This repetition increases the second device’s degree of confidence in the first device holding the secret information, which is 1 – (1 / 2)^M when the second device receives M proof information. According to a further embodiment, N=3. In this case, the first entity (i=1) can be an identity service (IS) which can be a service that hold the mapping of the real identity of first devices and their pseudonymous identities (first identification information). The IS can be any organization which is trusted by users of devices and government to handle the real identity of the devices. The IS can hold a private and public key-pair, wherein it uses its private key to make a digital signature and its public key is accessible to all the devices that can be used to verify the digital signature of IS. It is assumed that the public key of the IS is distributed along with a certificate that can be used to validate the authenticity of the IS and its public key. The second entity (i=2) can be an escrow service (ES) that holds the mapping of the pseudonymous identities (first identification information) of devices and their second identification information. ES can be any organization which is trusted by users of devices and government to handle the mapping of the identification information. The ES holds a key-pair, where it uses its private key to decrypt the information that was encrypted using its public key (which is publicly available). The N-th entity can be a governor entity (G) which is a device of a party that is neutral concerning the interests of giver, getter, and optionally auditor, that arbitrates and enforces rules to achieve compliance. It can be any organization which is trusted by users of the devices and government to handle issuing of one-time transaction identities (SUITs), such as, central banks. Preferably, N≥3 to reduce the traceability of the real identity and increase the privacy of the first device. According to a second aspect, an authenticating system for authenticating a first device to a second device using a single use identity token (SUIT) associated with the first device and generated by an N-th entity is provided. The authenticating system includes the first device, the second device and a service comprising N entities with N≥1, the N-th entity being the N-th entity, whereinthe 1st entity is configured to map a real identity associated with the first device to a 1st identification information, the real identity forming a 0-th identification information;if N≥2, the N-th entity is configured to map the (N-1)-th identification information with the SUIT;if N≥3, each i-th entity is configured to create an i-th identification information, to map it to an (i-1)-th identification information and to store a mapping information about the mapping, wherein 2≤i≤N-1; andthe first device, the second device and the N entities are configured to perform the steps of the method of the first aspect or any embodiment thereof.  All features described in view of the first aspect or any embodiment thereof also hold for the authentication system of the second aspect. In particular, the authentication system includes the first device, the second device and the N entities. In particular, each of the first device, second device and N entities includes a processing unit, a communication unit and a storage unit. The storage unit can be configured to store the data to be sent or received by the first / second device and / or N entities, such as the identification information, the SUIT or the like. The communication unit can be configured to send and / or receive the data to the other devices and / or entities. The processing unit can be configured to process the received data, for example to determine whether the received proof information is indicative of the secret information. The processing unit can further be configured to control the communication unit and / or the storage unit. The present invention will be described more fully hereinafter with reference to the accompanying figures in which like numerals represent like element throughout the different figures, and in which prominent aspects and features of the invention are illustrated.  BRIEF DESCRIPTION OF THE FIGURESFig. 1 shows a computer-implemented method for authenticating a first device to a second device; Fig. 2 shows an example of a method for registering the first device with a service of N entities;Fig. 3 shows an example of a method for retrieving the real identity of the first device;Fig. 4 shows an example of a method for generating SUITs;Fig. 5 shows an example of a method for executing the ZKP; andFig. 6shows an authentication system. DETAILED DESCRIPTIONThe computer-implemented method of Fig. 1 shows a method for authenticating a first device 1 to a second device 2. The first device 1 and the second device 2 are each drones used to transport packages. The two device 1, 2 are from different manufacturers or transport providers so that they cannot share all types of information with one another as they do not trust one another. Still, the two devices 1, 2 need to cooperate to pass packages from the first device 1 to the second device 2 (or the opposite order).  Before they pass packages between one another, the second device 2 executes the method of Fig. 1 to authenticate the first device 1. This registers the first device 1 with the second device 2 in a manner that does not disclose the real identity of the first device 1 (in particular of its manufacturer) while allowing to track down this real identity if required. The second device 2 may additionally be authenticated by the first device 1 in an equivalent manner.  To be eligible for authentication by the second device 2, the first device 1 is registered with a service formed of N entities, which are denoted E1, E2, …, E(N-1) and EN. An example for a registration or enrolment of the first device 1 with the N entities is described in view of Fig. 2. In the shown example, N=3, wherein the first entity E1 (i=1) is an identity service (IS), the second entity E2 (i=2) is an escrow service and the third entity EN or E3 (i=3) is a governor entity. In the enrolment as described in Fig. 2, the first device 1 is enrolled with the three devices E1 – E3. This is a one time task and is performed when a new first device 1 enters the system. Once this phase is completed, the first device 1 is allowed to perform other tasks (e.g. receiving SUITs, transacting with other device, etc.) in the system. Encryption-decryption and digital signature are used by various actors to securely complete the enrolment of the first device 1.  Fig. 2 presents the steps involved in the enrolment of the first device 1. In a step S10 of Fig. 2, the first device 1 enrols with the identity service E1 by providing a serial number or a device biometric of the first device 1, or a government ID and / or biometric data of a user of the first device 1 to the identity service. This provided information forms the real identity RI of the first device 1, also referred to as identification information 0, II0. In a step S11, the identity service E1 receives the RI data and optionally validates the authenticity of the data with the government. On successful validation, the identity service E1 generates a pseudonymous random identification information (first identification information), denoted by II1, and maps the real identity RI with the newly generated identification information II1 for storage of this mapping information. Then, the identity service E1 encrypts the identification information II1 with the public key of the escrow service E2 and finally signs it with a digital signature and shares it with the first device 1 in step S12 of Fig. 2. The first device 1 saves the signed encrypted identification information II1 in its database (storage unit) and in step S13, the first device 1 shares the same with the escrow service E2 to complete the enrollment. In a step S14 of Fig. 2, the escrow service E2 validates the digital signature of the identity service E1 and then decrypts it to obtain the first identification information II1. It generates another pseudonymous random ID, which forms the second identification information and is denoted by II2,and maps it with the first identification information II1 in the database. It also shares the signed second identification information II2 to the first device 1 in a step S15. Note that the escrow service E2 can only link the second identification information II2 with the first identification information II1.  Upon receiving the signed second identification information II2, the first device 1 generates a key pair and saves the signed second identification information II2, private key, and public key in its database. To complete the enrollment, the first device 1 provides the signed second identification information II2 and self-generated public key to the governor entity EN in a step S16. In a step S17, the governor entity EN validates the digital signature of the escrow service E2 on the second identification information II2 and saves the second identification information II2 along with the public key in the database. Preferably, the governor entity EN maps the second identification information II2 with a SUIT generated for the first device 1. The generation of the SUIT will be described in more detail in the following in view of Fig. 4. Now that the first device 1 is enrolled with the N entities, the first device 1 can be authenticated by the second device 2, as explained with reference to Fig. 1 in the following. Namely, in a step S1, the first device 1 receives, from the governor entity E3, a signed message containing the SUIT, a secret information x related thereto, and numbers p and g (where g and p are numbers having values that are publicly known, p being a prime number). The SUIT here comprises a value S taken by the discrete logarithm problem (DLP) of the form S=(g^x) mod p. The first device 1 stores the received SUIT and secret information x in a storage unit of the first device 1. The first device 1 wanting to authenticate with the second device 2, it initiates the authentication by sending a signed message containing the SUIT, p and g to the second device 2 in a step S2. The second device 2, in a step S3 of Fig. 1, verifies whether the SUIT has been signed by the governor entity E3 and has not been altered. If this is validated (output “Y” at step S3), the process continues with step S4. Otherwise (output “N” at step S3), the authentication process terminates. In step S4, the second device 2 executes a ZKP to prompt the first device 1 to provide a proof information proving that it holds the secret information x, but without sharing the secret information x itself. In a step S5, the first device 1 provides the second device 2 with the requested proof information. In a step S6, the second device 2 verifies that the proof information indicates that the first device 1 holds the secret information x. If this is confirmed in step S6 (output “Y” in step S6), the process continues with step S7. Otherwise, if the proof information is not indicative of the first device 1 holding the secret information x, the authentication process is stopped (“N” as the output of S6). In step S7, authentication of the first device 1 to the second device 2 is confirmed. Thereby, the second device 2 authorizes the first device 1 to approach it and to pass a package to it. In the present example, the transaction includes receiving, by the first device 1, information about the precise position of the second device 2, and accordingly pass a package to the second device 2 by the first device 1. It can be advantageous to authenticate the second device 2 by the first device 1 otherwise the second device 2 can share a false location to the first device 1 and the first device 1 has not base to track its real identity if the second device 2 if it is malicious. Subsequent step S8 is only executed in case of a triggering event such as a data leakage, a fraud, refusal to pass on the package or the like by the first device 1. In this case, the real identity RI of the first device 1 can be retrieved using the SUIT provided by the second device 2, as will be detailed below in view of Fig. 3. In detail, Fig. 3 presents the process of revealing the real identity RI in case of a triggering event. It is assumed that the second device 2 shares the SUIT (in case of the triggering event) to a device of the regulating authority. The regulating authority shares the SUIT with a device of an auditor 3 and asks to reveal the first device’s 1 real identity based on the SUIT. All steps of Fig. 3 can be included in step S8 of Fig. 1. In step S20, the auditor connects with the governor entity E3. The auditor 3 shares the SUIT with the governor entity E3 and asks for the second identification information II2 of the owner of the SUIT (i.e. of the first device 1). In step S21, the governor entity E3 looks into the database and finds the given SUIT’s owner expressed as the second identification information II2, which the governor entity E3 G shares with the auditor 3. In step S22, the auditor 3 connects with the escrow service E2.  The auditor 3 shares the second identification information II2 with the escrow service E2 and asks for the first identification information II1 of the first device 1. In step S23, the escrow service E2 looks up the first identification information II1 in its database and shares it with the auditor 3. In step S24, the auditor 3 connects with the identity service E1 and shares the first identification information II1 with the identity service E1 and asks for the first device’s real identity RI. In step S25, the identity service looks into its database and finds the real identity RI of the first device based on the given first identification information II1. The identity service E1 shares the real identity RI with the auditor 3. The auditor 3 can submit the real identity RI to the regulating authority after getting the real identity RI. Fig. 4 shows an example of the SUIT generation by the governor entity E3, which can be performed prior to the steps S1 – S8 of Fig. 1. In this phase, the governor entity E3 generates SUITs for the first device 1 so that the first device 1 may perform transactions with other devices, including the second device 2. Ideally, the steps of the method of Fig. 4 follow the enrollment process described in view of Fig. 2. SUITs come with a validation timestamp hence if the SUITs expire or the first device 1 does not have any SUITs remaining (since for every new transaction a new SUIT is used), it can regenerate the SUITs by the method of Fig. 4. In a step S30, the first device 1 requests the governor entity E3 for SUITs by providing the second identification information II2 (i.e. the (N-1)-th identification information) and an encrypted validity timestamp using the first device’s private key. In a step S31, the governor entity E3 uses the second identification information II2 to retrieve the public key of the first device 1 from the database of the governor entity E3, and uses it to decrypt the validity timestamp. Once the validity timestamp is decrypted, the governor entity E3 checks whether it is valid (by checking that difference between the received timestamp and the current time should be less than an agreed threshold). Only if it is confirmed that the validity timestamp is valid, in a step S32, the governor entity E3 initiates a SUITs generation request to the escrow service E2 by providing the second identification information II2. In a step S33, the escrow service E2 logs the SUITs generation request of the given second identification information II2 and approves the governor entity’s request for generating SUITs or not. Only in case of approval by the escrow service E2, the approval information is sent to the governor entity E3 in step S34. On getting confirmation from the escrow service E2, the governor entity E3 generates the SUITs along with validation timestamps (i.e., expiration timestamps for the SUITs) and maps them with the second identification information II2 in its database (step S35). In a step S36, the governor entity E3 shares the following information digitally signed: the secret information x, p (prime number), g (generator), the SUIT (generated such as to include S=(g^x) mod p, and the validation timestamp to the first device 1. Fig. 5 shows an example of a method for performing the ZKP, which can be part of the method steps described in view of Fig. 1. In detail, in step S40, in an initial communication, the first device 1 shares with the second device 2 certain public parameters including the integer g and the large prime number p, as well as the SUIT, which includes the integer value S = (g^x) mod p, where "x" is the secret information value that the first device wants to prove she knows. Step S40 of Fig. 5 can correspond to step S2 of Fig. 1. In a step S41, the second device 2 validates the digital signature of the governor entity E3 and checks the validation timestamp. If the SUIT is not expired (“Y” in step S41), the second device 2 will save the validation timestamp and the SUIT to its database. If the SUIT is expired (“N” in step S41), the authentication is stopped at this stage. In a step S42, the ZKP execution is started and the second device 2 confirms the SUIT’s validity to the first device 1 and asks it to share the value of C (C = g^r mod p). In a step S43, the first device 1 generates a random integer "r", calculates C = (g^r) mod p and sends the result C to the second device 2. In a step S44, the second device 2 challenges the first device 1 to prove its knowledge of "x" without revealing "x" itself. For this, the second device sends a random bit "b" (0 or 1) to the first device 1, requesting it to provide either "r" or "(x+r) mod (p-1)" depending on the value of "b”. In the step S45, the first device 1 computes "z" according to the value of “b". If b=0, the first device 1 sends "z = r", and if b=1, the first device 1 sends "z = (x+r) mod (p-1)" as the proof information. In step S46, the second device 2 verifies, if b=0, that C = (g^z) mod p holds, and if b=1, that (S * C) mod p = (g^z) mod p holds. If the first device 1 is a cheater, there is a 50% chance that the second device 2 will catch the lie, as the first device 1 will not be able to answer both of the challenges. For this purpose, when used as part of an iZKP, the steps S42 to S45 can be repeated M times, and thus the degree of confidence of the second device 2 in the first device 1 increases with increasing M as 1-(1 / 2)^M. Steps S42 to S45 can be part of steps S4 and S5 described in view of Fig. 1. Fig. 6 shows an authentication system 100 for authenticating the first device 1 to the second device 2 by performing the method of Fig. 1.The authentication system 100 includes, as actors, the first device 1, the second device 2, and the N entities E1 – EN. All actors of the authentication system 100 communicate via a wireless communication network 101, such as a Wi-Fi. The actors of the authentication system are configured to perform the method steps described in view of Fig. 1 to 5.  The invention can be used in many other contexts than that of the above-mentioned (non-limiting) examples of drones. For example, the described method and system can be used in the IoT (Internet of Things) context, in particular in a smart home scenario involving at least a first and a second device from different manufacturers, e.g., smart lights, smart TV, and a security system, Zero-Knowledge Proofs (ZKP) can be employed to facilitate secure and private interactions, as described above. Each device is linked to a central smart home hub and programmed to understand the ZKP protocol. When an IoT device needs to communicate with another IoT device (such as with the smart lights), it generates a ZKP that validates a condition (e.g., being within a specific channel) without revealing specific data. The receiving device, e.g. the smart light verifies this proof and acts accordingly adjusting the light intensity according to the proof. As another example, a first device may be a smartphone owned by a person having a digital wallet, a second device may be another smartphone owned by another person with a corresponding digital wallet, and the transaction may represent a digital cash transaction between the wallets. The invention can then secure the operations of transfer of cash between the wallets via the smartphones. An alternative use case could for example include the first device 1 being a smartphone and the second device 2 being a printing service, the phone 1 sending the printing service 2 photos as a transaction, and the printing service 2 authenticating the phone 1 without knowing the real identity of the user thereof, but with the possibility to track the identity in case of receiving a virus from the phone 1 or in case of non-payment by the phone’s owner. The first device 1 and the second device 2 can each be a robot in a production site, which work together to create and assemble a product. Moreover, the number N of entities can be smaller or larger than 3. The above disclosed subject-matter is to be considered illustrative, and not restrictive, and serves to provide a better understanding of the invention defined by the independent claims.   REFERENCE NUMERALS1first device2second device3auditor100authentication system101communication network               ABSTRACT Computer-implemented method for authenticating a first device to a second device Method for authenticating a first device to a second device, the method comprising:receiving, by the first device a secret information and a SUIT which comprises a result information being a result of a problem obtained using the secret information on the problem; sending the SUIT from the first device to the second device;executing a ZKP suitable for the problem included in the SUIT, including prompting the first device to provide a proof information;verifying, by the second device, that the proof information received from the first device is indicative of the secret information solving the problem specified by the SUIT;if this is confirmed, authenticating the first device, and authorizing a transaction with the first device; andin case of a triggering event involving the first device, recovering the real identity associated with the first device. Fig. 1

Claims

1.A computer-implemented method for authenticating a first device (1) to a second device (2) using a single use identity token (SUIT) associated with the first device (1) and generated by an N-th entity, the N-th entity being part of a service comprising N entities with N≥2, the 1st entity mapping a real identity associated with the first device (1) to a 1st identification information, the real identity forming a 0-th identification information, the N-th entity mapping the (N-1)-th identification information with the SUIT, and if N≥3, each i-th entity creating an i-th identification information and mapping it to an (i-1)-th identification information and storing a mapping information about the mapping, wherein 2≤i≤N-1; the method comprising:receiving (S1), by the first device (1), (i) a secret information provided by the N-th entity, and (ii) the SUIT which comprises a result information, the result information being a result of a problem obtained using the secret information on the problem, the problem being suitable for a zero knowledge proof (ZKP) and the SUIT being signed by the N-th entity through an N-th signature; sending (S2) the SUIT from the first device (1) to the second device (2);by the second device (2), verifying (S3) the N-th signature of the received SUIT;if the second device (2) validates the N-th signature, by the second device (2), executing (S4) the ZKP suitable for the problem included in the SUIT, the execution of the ZKP including prompting the first device (1) to provide a proof information, the proof information being an indicator that the first device (1) holds the secret information;in response to the prompt from the second device (2), sending (S5) the proof information from the first device (1) to the second device (2);verifying (S6), by the second device (2), that the received proof information is indicative of the secret information solving the problem specified by the SUIT;if the received proof information is indicative of the secret information solving the problem, authenticating (S7) the first device (1) by the second device (2), and authorizing, by the second device (2), a transaction with the first device (1), the transaction including a subsequent exchange of data between the first and the second device (2); andin case of a triggering event involving the first device (1), recovering (S8) the real identity associated with the first device (1) by (i) sending the SUIT received by the second device (2) to the N-th entity to retrieve the (N-1)-th identification information, and (ii) recovering each (i-1)-th identification information with 1≤i≤N by sending each i-th entity the i-th identification information. 2.The method of claim 1, further comprising:generating the SUIT by the N-th entity, comprising:by the first device (1), requesting (S30) the N-th entity for generation of the SUIT including sending the (N-1)-th identification information to the N-th entity;authenticating the first device (1) to the N-th entity based on the (N-1)-th identification information; generating (S35) the SUIT and mapping it with the (N-1)-th identification information. 3.The method of claim 2, wherein generating the SUIT by the N-th entity further comprises, before the step of generating (S35) the SUIT and mapping it with the (N-1)-th identification information:Sending (S32) a SUIT generation request and the (N-1)-th identification information from the N-th entity to the (N-1)-th entity;by the (N-1)-th entity, validating (S33) the SUIT generation request under consideration of the received (N-1)-th identification information; sending (S34) an approval information from the (N-1)-th entity to the N-th entity; andgenerating (S35) the SUIT and mapping it with the (N-1)-th identification information by the governor device only upon receiving the approval information. 4.The method of any one of claims 1 to 3, whereinthe ZKP is an interactive ZKP (iZKP);the execution (S4) of the ZKP including several instances of prompting the first device (1) to provide a proof information; andthe step of authorizing (S7), by the second device (2), the transaction with the first device (1) is performed only if all the received proof information are each indicative of a secret information solving the problem specified by the SUIT. 5.The method of any one of claims 1 to 4, wherein the problem includes:a discrete logarithm problem of the form (g^x) mod p, p being a prime number, g being a generator and x being the secret information;a sudoku puzzle, wherein the secret information is a cell or cell group of the solved sudoku puzzle;a Hamiltonian circuit problem, wherein the secret information is a Hamiltonian path;a traveling salesman problem (TSP), wherein the secret information is a length of a Hamiltonian path;a 3-Coloring map puzzle, wherein the secret information is a full coloured graph;a subset sum problem, wherein the secret information is a target sum of the subset sum problem; and / ora Boolean satisfiability (SAT) problem, wherein the secret information is a statement satisfying a Boolean formula.      6.The method of claim 5, wherein the problem includes the discrete logarithm problem of the form (g^x) mod p, the SUIT including a value of (g^x) mod p, which is denoted S, wherein g and p are public information, wherein the execution of the ZKP by the second device (2) includes:the second device (2) asks (S42) the first device (1) to share its value for C, wherein C = (g^r) mod p, r being an integer that is randomly chosen by the first device (1) but unknown to the second device (2), wherein 0≤r<(p-1);the first device (1) generates (S43) a random integer, sets it as r, calculates C for the generated random number, and transmits the calculated value of C to the second device (2);the second device (2) asks (S44) the first device (1) to prove its knowledge of the secret information by sending a random bit b to the first device (1);if b=0, the first device (1) sends (S45) z=r to the second device (2), and if b=1, the first device (1) calculates and sends (S45) z=(x+r) mod (p-1) to the second device (2), z forming the proof information;if b=0, the second device (2) verifies (S46) whether C=(g^z) mod p holds, and if b=1, the second device (2) verifies (S46) whether (S*C) mod p =(g^z) mod p holds, which is indicative that the received proof information is a secret information solving the problem. 7.The method of claim 6, further comprising repeating the steps of claim 6 for a predetermined number of times. 8.The method of any one of claims 1 to 7, wherein N=3. 9.An authenticating system (100) for authenticating a first device (1) to a second device (2) using a single use identity token (SUIT) associated with the first device (1) and generated by an N-th entity, the authenticating system including the first device (1), the second device (2) and a service comprising N entities with N≥2, the N-th entity being the N-th entity, whereinthe 1st entity is configured to map a real identity associated with the first device (1) to a 1st identification information, the real identity forming a 0-th identification information;the N-th entity is configured to map the (N-1)-th identification information with the SUIT;if N≥3, each i-th entity is configured to create an i-th identification information, to map it to an (i-1)-th identification information and to store a mapping information about the mapping, wherein 2≤i≤N-1; andthe first device (1), the second device (2) and the N entities are configured to perform the steps of the method of any one of claims 1 to 8.   

Images