PUF and blockchain-based IoT event recorder and method

Abstract

This invention provides a method and system for proving whether malicious tampering occurred in a PUF (Potentially Unauthorized File). [Solution] The device 1000 comprises a PUF module 603 and one or more outer layer components 1002 that provide at least a portion of an unsecured channel for inputting a challenge to the PUF module and receiving the response returned. The internal logic of the PUF module includes a logging mechanism that automatically logs the record of the challenge and / or response to a logging medium, e.g., a blockchain. The device sends a first message to be recorded on the blockchain, submits a query to check that the first message has been recorded on the blockchain without tampering, and, if so, sends a second messaging transaction to be recorded on the blockchain.

Description

[Technical Field]

[0001] One aspect of this disclosure relates to the field of physically hard-to-replicate functions, or PUFs. Another aspect relates to secure communication via blockchain. [Background technology]

[0002] A physically hard-to-replicate function (PUF) is a term used to describe a function that involves deterministic but unpredictable physical phenomena. PUFs are sometimes also called physical random number functions. A PUF takes an input called a "challenge" and, depending on the challenge and the physical phenomenon employed by the PUF, produces a corresponding output called a "response." PUFs are sometimes classified as strong or weak. A strong PUF can produce a response for many different challenges, typically taking on any value for the challenge. A weak PUF can produce a single response or a small number of responses (typically, the challenge cannot take on any value). In other words, a strong PUF has many challenge-response pairs (it has a large challenge-response space), while a weak PUF has a single challenge-response pair or a limited number of challenge-response pairs (it has a small or limited challenge-response space). According to one definition, a weak PUF has a large number of responses that increase linearly with the number of challenge bits, or more generally, responses that do not increase beyond linearity with respect to the number of challenge bits or any other parameter (in other words, a weak PUF cannot scale up its challenge response space; i.e., at most, the challenge response space scales linearly).

[0003] A known example of a strong PUF is an optical PUF. For example, an optical PUF may include a laser, an optical sensor, and a solid optical medium in which bubbles or other such artifacts are set. The laser is shone through the optical medium at a controllable angle, producing a diffraction or scattering pattern (the effect of bubbles or artifacts in the medium). The sensor is positioned and configured to sense this pattern. The challenge is the angle of the laser, and the response is generated based on the sensed pattern.

[0004] An example of a weak PUF is an SRAM PUF. In this case, the challenge is powering on the SRAM (Static Random Access Memory). Because there are slight manufacturing differences between SRAMs, when powered on, the SRAM cells enter a unique pattern of 0 / 1 states, thereby forming the characteristic fingerprint of each individual SRAM. The PUF is configured to output this as the response after power-on.

[0005] PUFs can be used as a means of generating keys for use in cryptographic algorithms (for example, to sign or encrypt documents). Another use of PUFs is in identifying devices, such as computer devices that incorporate PUFs. If the expected response to a given challenge has been determined in advance, a verifier can later challenge a target device and check whether it gives the expected response, thereby checking whether the target device is the device associated with the expected response.

[0006] Because the challenge-response space is limited, input-output (I / O) interfaces to weak PUFs tend to be restricted to only one or a limited number of parties (for example, only one or a limited number of trusted parties may be physically or legally granted access to the PUF, or the interface to the PUF may be password protected, or similar). That is, only one or more parties of interest can have access to the inputs to the PUF that need to submit challenges and the outputs used to receive the returned responses. On the other hand, with strong PUFs, the I / O interface to a strong PUF may be widely available to a large or unlimited number of parties, not all of whom are necessarily known or trusted parties. This is because the challenge-response space is large enough that it is not feasible for an adversary to enumerate all challenge-response pairs, and therefore the adversary's ability to freely access the PUF should not compromise its security by allowing enumeration and spoofing of the PUF, as is the case with weak PUFs.

[0007] In different technological fields, blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained on each of several nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and is widely publicized. A blockchain contains a chain of blocks of data, and each block contains one or more transactions. Each transaction, other than so-called "coinbase transactions," refers to a previous transaction in a sequence that may span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed later. Transactions submitted to the blockchain network are included in a new block. New blocks are created by a process often referred to as "mining," which involves each of several nodes competing to perform "proof of work," that is, competing to solve a cryptographic puzzle based on a defined representation of an ordered, approved, and pending transaction waiting to be placed in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and the publication of a block can be achieved simply by publishing the block header.

[0008] Transactions in a blockchain can be used for one or more purposes, including transmitting digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or time-ordering index pointers. Blockchains can also be used to layer additional functionality on top of them. For example, a blockchain protocol may allow additional user data or indices to data to be stored within a transaction. There is no predetermined limit on the maximum amount of data that can be stored within a single transaction, and therefore increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0009] Nodes in a blockchain network (often referred to as "miners") perform a distributed transaction registration and verification process, which will be explained in more detail later. In summary, in this process, nodes approve transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for them. Once a valid solution is found, the new block is propagated to other nodes in the network, thereby enabling each node to record the new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the network's nodes, where it is propagated. The node receiving the transaction can then compete to find a proof-of-work solution that incorporates the approved transaction into a new block. Each node is configured to enforce the same node protocol, which may include one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor incorporated into blocks. Assuming a transaction is approved and thus accepted onto the blockchain, the transaction (including any user data) is registered and indexed as an immutable public record on each node in the blockchain network.

[0010] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction," which distributes the amount of digital assets, i.e., the number of tokens. The detection and rejection of invalid transactions is enforced by the activity of competing nodes acting as agents of the network, who are incentivized to report and block illegal activity. The widespread disclosure of information allows users to continuously audit the performance of nodes. The mere publication of block headers allows participants to ensure the continuous integrity of the blockchain.

[0011] In the “output-based” model (sometimes referred to as the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output includes an element specifying the amount of digital asset that can be derived from a series of transactions in progress. Consumable outputs are sometimes referred to as UTXOs (“unspent transaction output”). Outputs may further include a lock script that specifies the conditions for the future redemption of the output. A lock script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction, and may further include an unlock script to unlock the lock script of the pointed-to output. So consider a pair of transactions, which we will call the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output specifying the amount of digital asset, and includes a lock script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input containing a pointer to the output of the first transaction, and a lock release script for unlocking the output of the first transaction.

[0012] In such a model, when a second target transaction is sent to the blockchain network and propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not already been redeemed by another previous valid transaction. A node that discovers a target transaction is invalid according to any of these conditions will neither propagate it (to register it as a valid transaction, but possibly an invalid transaction) nor include it in a new block to be recorded on the blockchain.

[0013] An alternative type of transaction model is the account-based model. In this model, each transaction defines the transfer amount not by referencing the UTXO of a preceding transaction within a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored and constantly updated by a node separate from the blockchain. [Overview of the project] [Problems that the invention aims to solve]

[0014] PUFs can be embedded within devices such as event data recorders (EDRs) (sometimes referred to as "black box" recorders). For example, they may be used later in investigative or litigation proceedings to demonstrate the identity of a device that produced a particular result. However, there is a potential problem that devices can be susceptible to malicious manipulation of challenges or responses, for example, in denial-of-service attacks or to disrupt investigations or proceedings. For example, a scrambler may be placed at the input and / or output of a device, thereby transforming the challenge before it is input to the device or transforming the response output by the device, or malware may be installed on the device, thereby performing such transformations internally. It is desirable to provide a means of proving whether such malicious manipulation has occurred. [Means for solving the problem]

[0015] According to a first aspect disclosed herein, a device is provided comprising a PUF module and one or more outer layer components. The PUF module comprises a physically hard-to-replicate function (PUF) and an internal PUF interface logic configured to receive an input challenge and output an output response which is a deterministic function of the input challenge, the deterministic function being the PUF. One or more outer layer components provide at least a portion of an unsecured channel for inputting an input challenge to the internal interface logic of the PUF module and receiving an output response which is output and returned by the internal interface logic. At least one of the outer layer components is susceptible to tampering with the input challenge and / or output response by a malicious process, but the PUF module, including the internal PUF interface logic, is enclosed within the device housing, isolated from the one or more outer layer components, and therefore protected from tampering by a malicious process. The internal PUF interface logic comprises a logging mechanism configured to automatically log a record of the input challenge and / or output response to a logging medium.

[0016] In some embodiments, the log medium may include the device's local memory, such as tamper-proof memory, one-time writable memory, and / or memory embedded within the interface logic. Alternatively, the log medium may include a publicly accessible medium outside the device, such as a blockchain.

[0017] Another potential vulnerability that may arise when a PUF device logs records on-chain, or when any other sending party or device attempts to communicate with a receiver via the blockchain, is that the communication between the sender and the blockchain could be disrupted and tampered with.

[0018] A computer implementation method is provided which includes the steps of: a) sending a first messaging transaction to be recorded on a blockchain, wherein the first messaging transaction includes a first message and respective information directing the first message to the second entity so that the second entity can identify the first message on the blockchain; b) submitting a query to check that the first message has been recorded on the blockchain without tampering; and c) sending a second messaging transaction to be recorded on a blockchain, provided that it is determined that the first message has been recorded on the blockchain without tampering in accordance with the query, wherein the second messaging transaction includes a second message and respective information directing the second message to the second entity so that the second entity can identify the first message on the blockchain.

[0019] The first and second embodiments may be used together or independently of each other.

[0020] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced only as examples. [Brief explanation of the drawing]

[0021] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram illustrates some examples of transactions that can be recorded on the blockchain. [Figure 3] This diagram illustrates the outline of the PUF challenge and response. [Figure 4] This is a schematic block diagram of the system including the PUF. [Figure 5A]This is a schematic block diagram of an extended PUF according to the embodiments disclosed herein. [Figure 5B] This is a schematic block diagram of the extended PUF in non-extended operating mode. [Figure 6] This is a schematic diagram of a system in which a trusted third party or publishing media is involved in the distribution of challenge-response pairs. [Figure 7] This is a schematic flowchart of the verification process according to the embodiments disclosed herein. [Figure 8A] This figure illustrates a schematic method for generating a set of challenges from a master challenge, as disclosed herein. [Figure 8B] This figure illustrates a schematic method for generating a set of challenges from a master challenge, as disclosed herein. [Figure 8C] This figure illustrates a schematic method for generating a set of challenges from a master challenge, as disclosed herein. [Figure 9] This diagram illustrates a schematic method for recording response data on a chain. [Figure 10] This is a schematic block diagram of a device equipped with an embedded PUF module. [Figure 11] This is a schematic block diagram showing a PUF device that logs records onto the blockchain. [Figure 12] This is a schematic block diagram illustrating insecure channels and communication over the blockchain. [Figure 13] This is a schematic block diagram of a system that provides protection against communications involving insecure channels. [Modes for carrying out the invention]

[0022] The robustness of systems such as key generation systems and privacy-protecting identity systems for both humans and machines can be improved by the involvement of physically hard-to-replicate functions (PUFs). These may be the parties interacting with each other and / or autonomous machines, or public systems such as blockchains.

[0023] These functions, based on physical systems and guaranteed by the assumption that there are random, undecidable, and irreproducible variations in the manufacture of physical devices, can be used to strengthen the established link between human identity and that device, or even to establish an unforgeable, unique identity for the device itself.

[0024] In the literature, PUFs are classified into weak and strong types, distinguished by their different characteristics. In some embodiments below, a generalized extended PUF (ePUF) framework is also provided for describing practical PUF devices that have the advantages of both types of PUFs. That is, ePUFs can generate a wide range of challenge-response pairs for use in applications while maintaining practicality and cost-effectiveness for implementation.

[0025] More generally, various embodiments relating to the management of PUFs and challenge-response pairs are disclosed herein. These different embodiments may be used individually or in any combination. These include, for example, the following: I. Extended PUF for extending the challenge-response space of PUF, II. A set of blockchain-independent protocols for establishing human and / or device identities by using ePUF devices. III. Frameworks for improving these identity protocols by leveraging blockchain technology. IV. Techniques for lightweight memory of challenge-response pairs, V. Event logging system and method for use with PUF-based modules, and VI. A set of novel applications for ePUF devices to various problems, such as KYC implementation for simplified payment verification (SPV) processes and device-verifiable computations.

[0026] 1. Physically Hard-to-Repeat Functions (PUFs) - Introduction The term "physically hard-to-replicate function (PUF)" refers to a class of physical systems and devices that function as general-purpose stochastic functions. These PUFs are often uniquely characterized by their physical properties, typically at the submicron scale, which can be uniquely identified and verified by examining these properties using physical stimuli. At a higher level, PUFs can be thought of as functions that map challenges to responses, and these pairs are often referred to as challenge-response pairs (CRPs). Notation F:C->R∀(C,R)∈Φ F Such a mapping F can be described using C and R represent challenge and response, respectively, and Φ F This is the set of all challenge-response pairs in the format (C,R) that can be generated by PUF.

[0027] The unique physical properties of a PUF are typically a result of random process variations inherent in the manufacturing of physical devices such as silicon chips. Typical assumptions made regarding PUFs are as follows: 1. It is difficult to completely determine the parameters of a physical system through any form of analysis. 2. The parameters of the physical system are unknown to any party, including the authorized manufacturer of the device used as a PUF. This assumption is often referred to as manufacturer-resistance.

[0028] These assumptions allow the PUF to be used to generate unpredictable yet deterministic responses to any challenge. In this challenge-response process, the PUF is treated like a physical black box, as illustrated in Figure 3.

[0029] Figure 3 shows PUF302 modeled as a physical black box. Submitter 103S submits Challenge C as input to PUF302, and in response, PUF302 generates a corresponding response R. The submitter submits the challenge from a device such as the submitter's computer device (not shown), which may be the same or a different device on which PUF302 itself is implemented.

[0030] Submitter 103S may be a party that generates challenge-response (CR) pairs as part of a setup phase (see example below) to establish a set of expected responses linked to the identity of a target party or device. Alternatively, Submitter 103S may be a verifier that submits a challenge in a later verification phase to verify that the generated responses match the expected responses, and thus can verify the identity of a target party possessing a target device or PUF, including PUF 302.

[0031] In another exemplary scenario, submitter 103S may be a party that wishes to use a generated response as a key for use in a cryptographic application such as a blockchain application, or as a seed for generating a key (for example, to sign a blockchain transaction).

[0032] Figure 4 shows a system with an example interface to the PUF302. The system comprises a processor 402 and a PUF302. The interface comprises interface logic 404, which is stored in memory and configured to run on the processor 402. The memory in which the interface logic 404 is stored may include one or more memory units employing one or more storage media (e.g., magnetic media such as magnetic disks or tapes, or electronic media such as ROM, EPROM, EEPROM, flash memory, SRAM, or DRAM). The processor 402 may comprise one or more processing units (e.g., a general-purpose processor such as a CPU, or an application-specific or accelerator processor such as a GPU, DSP, or cryptographic processor). It is also possible that the interface logic 404 may instead be partially or entirely implemented in dedicated hardware circuitry, or in configurable or reconfigurable circuitry such as a PGA or FPGA.

[0033] Submitter 103S submits a challengee C to PUF 302 via interface logic 404 using a device (not shown). The device used by submitter 103S can be, for example, an external computer device or the same computer device on which the processor 402 is implemented. The PUF 302 then returns a corresponding response R to submitter 302's device via interface logic 404. In some embodiments, which will be described in more detail later, the interface logic 404 may include access control logic 406 that restricts access to the PUF 302 to only certain parties, for example, parties who can present recognized credentials such as a password, PIN, or biometric information. and / or, the physical interface to the device with the processor 402 may be restricted by being located in a room or complex accessible only to authorized personnel, or by being stored in a locked box or cabinet. However, in alternative systems, the interface logic 404 may be made available for any party to query with a challenge.

[0034] The PUF challenge-response process enables the generation of pseudo-random data values ​​by extracting these challenges from selected responses. For example, a PUF can be used as a key generator to extract random, reproducible data to be used in cryptography. Note that PUF302 operates in a deterministic and reproducible manner, such that when given the same challenge on multiple separate occasions, the PUF yields the same response.

[0035] There are many different physical systems that can be used as PUFs, and many different implementations of PUFs that use these systems. An exemplary example of a PUF is an optical medium containing bubbles, which, when explored with a laser, produces a response diffraction or "speckle" pattern that is deterministically determined by (i) the position of the laser and (ii) small parameters of the optical medium.

[0036] 1.1. PUF Classes 1.1.1 Weak PUF: Weak PUFs are characterized by having a small challenge-response space, often with a CRP space size of |Φ F It has only a single challenge such that |=1. Generally, the challenge-response space for a weak PUF is thought to be of the order of 0(n), where n is the number of components in the PUF that are susceptible to uncontrollable manufacturing variations.

[0037] In the case of a weak PUF, it is also typically assumed that access to the PUF's response is restricted. This is because, since the number of CRPs served by a weak PUF is small, an adversary could enumerate all such pairs within a reasonable time and thus mimic or "spoof" the PUF's behavior. This restriction is sometimes referred to as a restricted challenge-response interface when describing the behavior of a weak PUF.

[0038] These characteristics make weak PUFs most naturally suited for use in cryptographic applications as key generators, where one (or a few) CRPs generated by a PUF can be used as secret keys for cryptographic operations, such as encrypting non-volatile memory (NVM) on a device or using them as HMAC symmetric keys. In such cases, the key derived from the PUF response must be kept secret for the security of both the cryptographic process being performed and the PUF itself, and should only be known to the device owner.

[0039] A prominent and widely implemented example of a weak PUF is the SRAM PUF, where "SRAM" refers to "Static Random Access Memory." The design of the SRAM PUF leverages the variability in the "power-on" state of SRAM chips, with each SRAM cell within the chip having a unique fingerprint due to the variability in whether it is in a "0" or "1" state when the chip is powered on.

[0040] In this case, the PUF configuration is considered weak because there is only one fixed mode for exploring the PUF (i.e., by powering on the SRAM chip), and therefore only a single CRP. In this case, the sole "challenge" is powering on the SRAM chip, and the response is a unique fingerprint derived from its power-on state. Access control to ensure the confidentiality of the response can also be implemented using existing memory access control policies or mechanisms in place on the device in which the SRAM PUF is used, or alternative mechanisms employed on the device.

[0041] A characteristic feature of some PUF implementations, such as in the case of SRAM PUFs, is the use of error correction in the responses generated by the PUF to ensure that the same challenge yields the same response in a conditional and time-invariant manner. Details of such error correction techniques are known to those skilled in the art. In some cases, the error correction process may require the PUF device to be "registered" first and to provide a source of helper data that is combined with subsequently generated responses on demand to facilitate error correction.

[0042] 1.1.2. Strong PUFs: In contrast to weak PUFs, strong PUFs are characterized by having a large space of possible challenge-response pairs (CR-pairs, or CRPs) that can be utilized. This large space of CRPs means that it is considered impossible for an adversary to enumerate all challenge-response pairs within the domain of a strong PUF in polynomial time. This property means that strong PUFs may generally have unprotected challenge-response interfaces, but this does not compromise security by allowing enumeration and spoofing of the PUF, as is the case with weak PUFs, even if an adversary has free access to the PUF. This class of PUFs is Φ F It is also said that strong PUFs produce unpredictable responses, even from the perspective of an adversary who knows a large subset of the domain, which means that strong PUFs behave more like cryptographic hash functions with large domains.

[0043] However, a strong PUF is subject to the restriction that only the response R should be given by the PUF when challenge C is presented, and no other information about the PUF's internal workings or operations should be leaked during the process. This restriction mitigates various analytical attacks that an adversary might attempt to characterize the physical system underpinning the PUF's behavior. These are often referred to in the literature as modeling attacks.

[0044] Similar to weak PUF configurations, some strong PUF configurations may rely on error correction techniques to ensure the accuracy of the response produced by the device.

[0045] The primary existing application of strong PUFs is to facilitate authentication and identification of systems using unique challenge-response mechanisms. These mechanisms rely on protocols that directly involve the creation of CRPs as a shared secret between two parties, and in many cases, at least one party must generate a table of CRPs before the time (initial setup) when they will be used as authentication tokens for the other party.

[0046] One of the earliest examples of strong PUF implementations was the optical PUF system. In this configuration, the PUF includes an optical medium containing randomly distributed physical defects resulting from manufacturing variations that scatter incident light. This PUF can be explored by a laser beam directed at the optical scattering medium. In this case, the direction and polarization of the incident beam form a challenge, and the observed scattering pattern is considered the response of the PUF.

[0047] However, this robust PUF configuration is complex to implement due to the fact that the measurement device is isolated from the rest of the PUF device and is difficult to integrate directly with the semiconductor components. This, in addition to the cost associated with the device itself, and the lack of portability of the configuration reduces its practicality for everyday applications.

[0048] A strong electrical PUF, known as Arbiter PUF (APUF), has since been proposed, overcoming some of these problems. This configuration utilizes signal multiplexing and leverages runtime delays in electrical components. Many other strong PUF configurations have been proposed in parallel, but many lack practical suitability for widespread use, and many have associated weaknesses regarding security and potential attack vectors. For example, a very problematic potential attack is a man-in-the-middle attack, in which an attacker can intercept a challenge submitted in plaintext and spoof the assurance calculation.

[0049] 1.1.3. Controlled PUFs: A third class of PUFs, known as controlled PUFs (CPUFs), are improvements on existing strong PUF configurations, but use them as building blocks. These PUFs take a strong PUF and apply additional control logic to restrict access to the PUF, otherwise distinguishing them from uncontrolled strong PUFs that may have an unprotected challenge-response interface.

[0050] As shown in Figure 4, the control logic 406 applied to the PUF, which is now part of a larger PUF device, can mediate access to the PUF 302 itself. This means that the control logic component 406 can limit which challenges are presented to the PUF and even control how the subsequent responses are revealed to the user.

[0051] In a CPUF configuration, preferably, the control logic component 406 should be embedded within or encapsulated within a strong PUF component. According to one definition of CPUF, a PUF is said to be controlled if it can only be accessed through an algorithm that is physically linked to the PUF in an inseparable manner (i.e., any attempt to circumvent the algorithm would lead to the destruction of the PUF). This embedding should make it considerably difficult to explore the control logic.

[0052] This establishes a mutually beneficial relationship between the PUF component and the control logic component, each mitigating certain types of attacks on the other. Specifically, encapsulating the control logic within the PUF device itself protects the control logic from physical or invasive attacks that would irreparably damage the PUF component and alter its response, while the control logic naturally protects the PUF component from protocol-level attacks that extract other information about the CRP or the underlying internal physical system of the PUF itself.

[0053] The uses of CPUF are almost the same as those of strong PUF, but they can be achieved in a more robust way. In particular, guaranteed computation and proof of execution can be easily achieved with the protocol outlined above.

[0054] Early examples of CPUFs, which extend the design of strong arbiter PUFs (APUFs), require control logic to intertwine with the APUF itself in the manner already described, so that the control logic and APUF protect each other from different types of attacks. Controlled APUF designs generate a large set of CRPs from a single static response from an integrated circuit (IC) by incorporating the transient response of the system.

[0055] Another known example of a controlled PUF is the PUF-FSM configuration. This involves a strong PUF (actually an APUF) paired with a finite state machine (FSM) that acts as control logic to restrict access to the challenge-response interface of the APUF component itself.

[0056] 1.2. Discussion 1.2.1. Practicality: It is acknowledged in the literature that producing strong PUFs that are practical, lightweight, and can be integrated with standard complementary metal-oxide-semiconductor (CMOS) components is extremely difficult. In contrast, it may be obvious that weak PUFs, such as SRAM PUFs, are inexpensive to produce and can be combined with integrated circuit architectures.

[0057] 1.2.2. Attacks against PUFs: Many different attacks have been proposed and studied, and different attacks may target specific PUF configurations or classes. Some of the most widely known attack types are listed below. • MITM attacks – These attacks target uncontrolled strong PUFs, and adversaries may intercept challenges made in plaintext to falsify or spoof the PUF's response, especially when used in assurance calculations. • Modeling attacks – These attacks demonstrate vulnerabilities to many strong PUF configurations, such as APUF. • Selection challenge attacks – These attacks also impact strong PUF and are part of the motivation for moving towards a CPUF architecture.

[0058] Furthermore, various PUF designs have other problems in some cases, such as a lack of uniqueness, which can allow vulnerabilities to be exploited that compromise the security of the PUF system under consideration.

[0059] 1.2.3 Security Models: Security models for PUFs tend to share some similarities, such as the assumption that the random process or manufacturing variability that causes CRP is manufacturer-resistant, and the assumption that the physical system of a PUF is difficult to characterize by analytical means. However, there are also some differences among the security models for the three main classes of PUFs. • Weak PUF - The security of a weak PUF relies on the assumption that its CRP is kept secret, otherwise the device could be enumerated and forged. This means that a weak PUF can be used to provide a source of entropy for cryptographic operations and a secure storage of that entropy, but the actual CRP response data itself is never publicly revealed in the process. • Strong PUF - The security of a strong PUF relies on the fact that its CRP space tends to grow exponentially with respect to the number of challenge bits, and therefore enumerating the entire space is not feasible within a reasonable timeframe. This means that the CRP response of a strong PUF can be revealed by the device, unlike in the case of a weak PUF. • Controlled PUF - The security of a controlled PUF is determined by a combination of control logic that protects against protocol-level attacks and the PUF itself that protects against physical attacks.

[0060] Two characteristics distinguish strong PUFs from weak PUFs. First, strong PUFs have a large set of CRPs. This means that strong PUFs have a large challenge space Φ. FThis means that a weak PUF typically has only one (or a few) challenges available. A strong PUF is further considered unpredictable with respect to any and all known CRPs. In other words, knowledge of any number of CRPs is not advantageous in predicting the response to a new challenge.

[0061] Secondly, a strong PUF can have an unprotected challenge-response interface. It is assumed that a given strong PUF does not require access control logic to restrict access to the challenge-response interface. This means that any party with physical access to the PUF can, at will, apply a challenge and obtain a response without revealing any additional information about the PUF or its physical characteristics.

[0062] A controlled PUF has a protected challenge-response interface, but also a large challenge-response space, similar to a strong PUF.

[0063] 2. Extended PUF (ePUF) Next, we disclose a system and method for extending the challenge-response (CR) space of a PUF by generating multiple secondary CR pairs from a given CR pair of a base PUF 302. This may be referred to herein as an "extended PUF" or "ePUF". The idea can also be used, for example, to extend the challenge-response space of a weak PUF having only one or a limited number of intrinsic CR pairs, without the complexity or impracticality of typical strong PUF mechanisms (such as optical PUFs requiring lasers, optical media, and sensors). However, in principle, the disclosed technique can also be used more generally to extend the number of CR pairs of any base PUF, whether weak, strong, controlled, or whatever, or to transform the CR pairs of any PUF for other purposes such as obfuscation or reusability.

[0064] Figure 5A shows an extended PUF (ePUF) 500 according to an embodiment disclosed herein. The ePUF 500 comprises a constituent base PUF 302, which may be, for example, a conventional weak PUF. The ePUF 500 further comprises a transformation function 502, a hash function such as a cryptographic hash function (e.g., SHA256). The ePUF 500 also comprises an interface logic 404', which may be similar to the interface logic 404 described in relation to Figure 4, but has additional interface functionality. The interface logic 404' and the transformation function 502 may be implemented in software, for example in embedded firmware, which is stored in memory and arranged and configured to run on a processor 402 (as shown in Figure 4, but performing the additional functionality of interface 404' and the transformation function 502). The memory in which the interface function 404' and the translation logic 504 are stored may include one or more memory units employing one or more storage media (e.g., magnetic media such as magnetic disks or tapes, or electronic media such as ROM, EPROM, EEPROM, flash memory, SRAM, DRAM, fuse latches, etc.). The processor on which these are executed may comprise one or more processing units (e.g., a general-purpose processor such as a CPU, or an application-specific or accelerator processor such as a GPU, DSP, or cryptographic processor). It is also possible that the interface logic 404' and / or the translation function 502 may instead be partially or entirely implemented in dedicated hardware circuitry, or in configurable or reconfigurable circuitry such as a PGA or FPGA.

[0065] Interface logic 404' is operablely coupled to the conversion function 502 and optionally to the base PUF 302. The base PUF 302 is operablely coupled to the conversion function. Interface logic 404' is positioned and configured to receive input from and provide output to submitter 103S's device (not shown in Figure 5A), which may be the same device or an external device on which ePUF 500 is implemented. Submitter 103S may be the party using ePUF 500 to perform setup and generate a set of challenges and expected responses to be linked to an identity for future reference, or may be the verifier (or challenger generating responses to provide to the verifier) ​​to later use the PUF to verify whether the generated responses match previously established expected responses. In another exemplary application, submitter 103S may also use ePUF 500 to generate responses for use as keys, or as a seed for generating keys. For example, this could be used as a cryptographic key to encrypt or sign a message, such as signing part of a blockchain transaction.

[0066] The base PUF302 is operable to receive a "primary" challenge Cw as input and generate a "primary" response Rw as output. In this specification, a "primary" challenge-response (CR) pair refers to a base, base of the configuration PUF302, or a "native" (i.e., intrinsic) CR pair. In some embodiments, the base PUF302 may be capable of generating only a single base (i.e., primary) response Cw in response to a single challenge Cw, like a weak PUF.

[0067] During operation, interface logic 404' receives challenge data (challenge input) from the submitter 103S device, which includes at least one "secondary" challenge Ci. In addition, a primary (base) challenge Cw is input to the base PUF 302 to generate a primary (base) response Rw. In one embodiment, submitter 103S is required to include the base challenge Cw in the challenge data input to ePUF 500, and interface logic 404' routes this to the base PUF 302 to generate the primary response Rw. However, in other embodiments, it is not excluded that the primary challenge Cw is input to the base PUF 302 from an internal source such as memory, a fuse latch, or dedicated circuitry. In any case, the conversion function 502 is arranged and configured to receive, as input, a) a secondary challenge Ci, as received in the challenge data input from the submitter, and b) a primary response Rw, as generated by the base PUF 302. The transformation function 502 is a function configured to deterministically map combinations of these onto unique "secondary" response Ris corresponding to specific combinations of Ci and Rw input to the transformation function 502. Secondary challenge-response pairs may be referred to herein as "secondary" in the sense that they are layered on top of primary (base) CR pairs, which are generated in part based on primary responses Rw. These may also be called "extended layers" or "supplementary" challenges and responses.

[0068] In embodiments, the transformation function 502 includes a hash function, such as a cryptographic hash function, e.g., an SHA or DSA hash function. There are at least two different ways in which the hash function can be used. Firstly, the transformation function 502 includes a hash of a preimage, the preimage includes a combination (e.g., concatenation) of the received secondary challenge Ci and the generated primary response, i.e., Ri = H(Ci| |Rw). Or, more generally, the preimage may also include other elements and / or other forms of combination other than concatenation.

[0069] In the second alternative approach, the transformation function 502 includes a hash of the preimage, the preimage includes the received secondary challenge, and the hash function is initialized with the generated primary response, i.e., Ri = H(Ci), where H is initialized by Rw. Or, again, more generally, the preimage of H can include other elements as long as it includes at least Ci. Being initialized by Rw means that the mapping of the preimage to the output defined by the hash function H itself depends on Rw.

[0070] In the previous case, the mapping of the preimage to the output caused by H does not depend on Rw; rather, the preimage depends on Rw. That is, in the previous paragraph, the preimage depends on Rw, while in this paragraph, only H depends on Rw.

[0071] More generally, however, in principle, any function can be used for each possible Ci within the domain contained by ePUF500, as long as the combination of Ci and Rw is deterministically and uniquely mapped to the respective values ​​of Ri.

[0072] The secondary challenge Ci can take any of a number of different possible values, and the conversion function 502 maps these values ​​to the respective values ​​of the secondary response Ri, based on the value of a particular received secondary challenge Ci and the value of the primary response Rw. Thus, the ePUF 502 can extend the CR space of a given primary (base) CR pair to multiple secondary CR pairs. In embodiments, Ci can take any value within the range of values ​​supported by the variable used (for example, if it is a 32-bit integer, then 2 32 (It can take any of the following values.)

[0073] In some embodiments, the ePUF500 may be able to operate in an alternative operating mode, as shown in Figure 5B. In this case, the interface logic 404' detects that the input challenge data contains only the primary challenge—Cw. In response, it routes the received value of Cw to the base PUF302 and the resulting primary response Rw to the submitter 103S's device. In other words, in this embodiment, the ePUF500 can also operate in a “legacy” or “non-extended” mode.

[0074] Optionally, depending on the application, the interface logic 404' may include access control logic 406, which restricts access to only a limited number of possible submitters 103S by granting access only to parties who can present credentials (e.g., password, PIN, or biometric input) that are recognized as mapping to an authorized party. In this case, the ePUF 500 can also be considered a form of CPUF.

[0075] Alternatively, the physical interface to the ePUF500 can be legally or physically protected by keeping the device equipped with the ePUF500 in a room or premises accessible only to a limited group of parties, or by keeping it in a locked box, cabinet, or room. In this case, the ePUF500 can be thought of as a kind of extended weak PUF.

[0076] As an alternative to, or in addition to, such physical limitations on the interface to the PUF, access may be restricted by limiting access to the primary challenge. For example, target party 103T ("Alice," described below) may be the only party that knows the Cw.

[0077] However, as another alternative means, access to the interface logic 404' may not be restricted, for example, any party may freely inquire via the Internet. In this case, the ePUF 500 can be considered as a kind of strong PUF 502 created by extending a weak base PUF mechanism.

[0078] The arrangement configuration shown in FIG. 5A provides a new hybrid class of PUF devices, referred to herein as extended PUF (ePUF), which can be generally used as a framework for many applications as presented later.

[0079] The ePUF can be defined as a physical device or system as shown in FIG. 5A, which essentially combines three modules: a base PUF 302 such as a weak PUF, a transformation function 502 such as a cryptographic hash function, and an interface logic module 404'. As described, the ePUF 500 can be "extended" with respect to a regular PUF 302 by introducing a transformation function 404' such as a cryptographic hash function, but it changes the size of the unique challenge space Φ F from approximately |Φ| of the base weak PUF 302 to |Φ| >> 1 which is restricted instead by the choice of the hash function rather than the physical system of the weak PUF. F | F | This is because it increases from 1 to >> 1.

[0080] The idea of realizing a system that combines the large CRP space of a strong PUF and the practicality of a weak PUF has itself been investigated previously. It is known to use multiple FPGA-based weak PUFs in a combined operation to form a system with the characteristics of a strong PUF. The intention here is, in part, to "extend" the CRP space of the base weak PUF. However, existing configurations with this property are actually limited. In the case of the above-mentioned FPGA design, the system has to be built on an FPGA and still has a relatively low CRP space (about 2 10It is affected by ).

[0081] The ePUF designs disclosed herein are designed to be extremely lightweight, requiring only the addition of an interface logic component 404' and a cryptographic hash function (or other such transformation function) 502 to an existing weak PUF 302. For example, if an SRAM PUF is selected as the widely used weak PUF 302, the addition of the two remaining modules 404' and 502 should not result in significant overhead and can be implemented, for example, as a small algorithm in software (e.g., firmware) or as a relatively simple hardware circuit. Furthermore, the space of possible outputs of the ePUF 500 is extended to the range of the selected hash or transformation function 502, which is considerably larger than the above. For example, if the SHA-256 hash function is selected, the space of possible outputs (and therefore CRPs) immediately becomes 2 256 It can be scaled down to -1, eliminating the need to scale hardware overhead beyond embedding the hash function module itself.

[0082] Figure 5A shows a schematic design for the Extended PUF (ePUF) 500. Embodiments in which a cryptographic hash function is used also mean that the ePUF 500 has the characteristic that its CRP is unpredictable, which is also true for strong PUF systems.

[0083] The control logic element 406 of the ePUF device can also be generalized in this configuration. The control logic 406 can be simply implemented as physical security, similar to that of an SRAM PUF, for example, if this is appropriate for the application.

[0084] Alternatively, the control logic module 406 may be implemented as a software control module similar to the one used with the CPUF, which is actually embedded within the PUF device itself, providing the cross-security benefits of encapsulation described earlier.

[0085] However, one point that distinguishes this ePUF design from the CPUF design is that there are no strict requirements for the control logic that should be implemented in this way.

[0086] An invasive attack on the control module 406 does not necessarily have to be assumed to alter the behavior of the weak PUF component 302 in the ePUF design. Instead, the implementation form of this element can be chosen on a case-by-case basis.

[0087] 2.1. Challenges and Responses to ePUF The set of challenge-response pairs corresponding to ePUF (C,R) ∈ Φ F It can be defined as follows: Φ F ={(C w ,R w ),(C1,R1),(C2,R2),..., (C N ,R N )}, F:C i →R i , ∀i∈(1,N) F w :C w →R w Here, (C w ,R w ) is a privileged CRP that corresponds to a weak PUF302 base challenge response, on map F w The map F is defined by the unique physical properties of the weak PUF. The pair (Cw,Rw) may be referred to herein as the base or primary pair of the ePUF. Conversely, the map F is defined by the cryptographic hash function selected for the ePUF. Figures 5A and 5B show that (Figure 5B) the challenge is to extract a response from ePUF500 where the challenge is Cw only, and (Figure 5A) the challenge also includes Ci.

[0088] In some embodiments of the extended PUF, all challenges C i i∈{1 ,} 2, ..., N} includes Base Challenge C w It must be accompanied by the base response R w As shown in Figure 5A, all other responses R i It is incorporated into the process for generating it.

[0089] The process shown in Figure 5A for generating generic CRP using ePUF is applicable to any other challenge C i By applying this base secret pairing to the base challenge response pair (C w ,R w It is designed to use the base pair (C) from the ePUF. The algorithm used to generate CRP from the ePUF is designed to use the base pair (C) in a deterministic way. w ,R w It can be modified for specific purposes, provided that it uses ). A simple example of such an algorithm is represented as getResponse(), which can be written as follows: getResponse() Input: Challenge 1. Obtain the challenge from the user / client. 2. Check if challenge == Cw. i. If yes: 1. C w We explored the weak PUF module and R w Get 2. Response←R w Set ii. If no: 1. Challenge C w Components and C i Separate into components. 2. C w We explored the weak PUF module and R w Get 3. C i and R w Send this to the hash function module. 4. hash(C i,R w Calculate H). 5. Response←hash(C i ,R w Set H). 3. Return a response. Output: Response

[0090] function hash(C i ,R w H(H) is a general-purpose function used to compute a hash digest using the cryptographic hash function H. The function hash() is, in simple cases, H(C) i ||R w It can be implemented in numerous ways, such as simply calculating the value R, or by simply calculating the value R. w The tedious calculation of using as the initial vector for the hash function H

[0091]

number

[0092] It can also be implemented by [this method]. In any case, the output of hash() is C i and R w It depends on both.

[0093] Figures 5A and 5B show that the ePUF500 may have interface logic 404', which optionally includes a control logic module 406. In the embodiment, there are two possible paths to take when generating a response, the path in Figure 5B is one in which the challenge is simply C w Used when the challenge is C w A new value C associated with it i It is used when this is the case. This is deterministic.

[0094] The disclosed ePUF design may be used to provide any of the following and / or other advantages: • A large CRP space defined by the domain and range of the selected hash function. • Flexibility to separate control logic from the PUF itself. • A weak PUF security primitive.

[0095] This means that users can use ePUF devices in the same way as CPUF devices, but controlled access to the PUF is (I) weak PUF base CRP(C w ,R w This includes both (II) securely storing the data and (II) restricting physical access to the PUF device to only the intended users. In this model, the base pair (C w ,R w ) acts like a master key, and from there the format (C i ,R i A very large number of other CRPs can be derived from C i This information may be submitted by an external party or a third party.

[0096] 2.2. Applications of ePUF The possible applications (use cases) of ePUF devices can be broadly categorized into at least the following two types: 1. Linking identity to activities or computational operations, and 2. To function as a key generator for cryptographic operations.

[0097] Application (1) is most commonly implemented using existing strong PUFs, and application (2) is most commonly implemented using existing weak PUFs. The fact that ePUF configurations are a combination of their respective characteristics means that they can be treated equally well for either application. In application (1), the advantage is that such an application can be implemented much more easily using ePUFs than with the strongest or most controlled PUFs.

[0098] 3. Identity Link System This section discloses a general-purpose framework for linking either a human or machine identity to a PUF device.

[0099] In some embodiments, an extended PUF (ePUF) may be used. The intention here is to formulate a PUF architecture that provides a robust yet highly generalized and flexible identity system that can be reused for many different use cases. The characteristics we aim for in its configuration are as follows: • Large CRP space comparable to that of a strong PUF, • Practicality comparable to those with weaker PUF, and • More flexible control logic than that of CPUF.

[0100] The ePUF design can be used as a foundational model for PUFs used in various identity establishment protocols. Embodiments may allow end-user or machine independence in the process. Where existing schemes that may be reused to use ePUF rely on a trusted third party to have direct access to the PUF device at setup, the proposed ePUF-based system may allow the end-user of the PUF device to establish their identity and participate in subsequent authentication without requiring a third party to have local or direct access to the device at setup.

[0101] Several implementations could improve and further extend the robustness of these Identity Link protocols by introducing a public blockchain. Two concepts that could be adopted here are (A) the use of blockchain as a tamper-proof CRP management system, and (B) the use of a blockchain network as a timestamp service to mediate request-response messages used in the Identity Link protocol and provide an efficient revocation system.

[0102] Figure 6 shows an exemplary system for identity linking and verification according to embodiments disclosed herein. Figure 7 shows a corresponding method.

[0103] The system comprises a PUF module 603, the target party 103T's computer equipment 102T, and a response data store 601. The PUF module 603 may comprise an ePUF 500 as already described with respect to Figures 5A and 5B, or alternatively, a conventional PUF 302 or PUF plus conventional interface logic 404 as already described with respect to Figures 3 and 4. The response data store 601 is part of a third-party computer equipment 602, which may be managed by a trusted third party, or alternatively, a decentralized peer-to-peer storage medium such as a blockchain. The third-party equipment 602 may include, for example, server equipment including one or more server units located at one or more geographical sites (cloud storage technology is known in the art itself). The system may further include the verifier 103V's computer equipment 102V, or in some alternative cases, the verifier may interact directly with the PUF module 603, the target party's computer equipment 102T, or the third-party computer equipment 602.

[0104] In this specification, any reference to the activities of a user or party 103, or similar activities, whether those of a verifier 103V, target party 103T, or a third party, includes the possibility that the party is performing activities through its computer equipment 102. For brevity, this is understood to be implicitly included, although it does not necessarily need to be explicitly stated each time. This covers both possibilities: A) the activity is triggered by or performed under the control of a party through manual user input to the computer equipment; or B) the activity is performed automatically by the computer equipment on behalf of the party (where it is said that a party performs an activity does not necessarily mean that a human user of that party manually triggers the activity, but rather that the party's equipment autonomously performs the activity on behalf of that party). To avoid doubt, it should also be noted that a party may refer to a single individual or group or people or organizations, such as a corporation, charity, government agency, or local or academic institution.

[0105] The target party 103T's computer device 102T may be operably connected to the response data store 601 (for example, by connecting to a third-party device 602). The verifier 103V's computer device 102V may be operably connected to the response data store 601 (for example, by connecting to a third-party device 602). The target party 103T's computer device 102T may be operably connected to the verifier 103V's computer device 102V. Any of these connections may be formed over one or more networks, such as one or more wide area networks, such as the Internet or a mobile cellular network. In embodiments, any of these connections may be established based on a shared secret, for example, shared between the two parties in interest, formed over their respective secure channels. Wherever two parties are said to communicate in any way, such as by sending a challenge or receiving a response, it is understood that this includes the possibility that such communication may be carried out via any preferred direct or network connection between their respective computer equipment (102V, 102T, 102T, 602, or 102V, 602). For brevity, this is understood to be implicitly included, although it does not necessarily need to be explicitly stated each time.

[0106] The target party 103T is a party whose identity should be verified based on the PUF module 603, or who owns, or is otherwise involved with or associated with a device that should be verified based on the PUF module 603. The verifier 103V is the party that should perform the verification. There may be multiple verifiers 103V (each operating through its own computer equipment 102V), but for ease of illustration, only one is shown in Figure 6. The PUF module 603 may be said to possess the target party 103T. It may be embedded in its computer equipment 103T, or connected to it, for example, as a peripheral, or via a local network or a combination thereof (for example, interface logic 404 / 404' may be implemented on computer equipment 103T, and PUF 302 may be an external peripheral). Alternatively, the PUF module 603 may be said to have a good understanding of trusted third parties. This can be connected to or incorporated into a third-party computer device 602, for example, as a peripheral device, or via a local network, or a combination thereof (for example, interface logic 404 / 404' may be implemented on the third-party computer device 602, and PUF302 may be an external peripheral device).

[0107] Generally, either the target party 103T, the verifier 103V, or a third party may assume the role of the submitter, as already described with respect to Figures 3, 4, and 5. Either the target party 103T, the verifier 103V, or a third party may assume the role of the submitter, or, using the PUF module 603, assume the role of the setter, establishing one or more sets of CR pairs and linking them to the identity of the target party 103T for use in a later verification phase. Several specific exemplary scenarios will be described in more detail later.

[0108] The response data store 601 stores the response data generated by the PUF module during the setup phase. The data store 601 stores this response data in relation to evidence of the target's identity, which may be the target party 103T or the target party 103T's device. The verifier 103V has access to the response data store 601 and can use it to verify the target's identity later during the verification phase. To do this, the verifier 103V challenges the target to generate a response Ri to a challenge Ci that was previously included in the set of challenges used during the setup phase. If the target can generate the expected response according to what is stored in the response data store 601, this is evidence that the target possesses or controls the PUF module 603 and can therefore be assumed to be the same party whose identity was captured during the setup phase.

[0109] In one alternative modification form, the response data store 601 may store one or more public keys of one or more public-key-private key pairs generated, for example, by using the response generated in the setup phase as a seed. If the target later signs a message (e.g., a document or blockchain transaction) using one of the private keys, the verifier can verify the signature using the corresponding public key from the response data store 601. Note that in such a modification form, the term “response data” is used in a broader sense to refer to data derived from response Ri, which is not necessarily the explicit value or proof of response Ri.

[0110] The response data store 601 may be publicly accessible, or access may be restricted to a limited set of one or more parties, including at least one verifier 103V. It may be hosted on a third-party system 602, or in a peer-to-peer manner, or alternatively, implemented on the computer equipment 102T of the target party 103T or the computer equipment 102V of verifier 103V.

[0111] Referring to Figure 7, this method comprises two phases: a setup phase 702 and a verification phase 704. In the setup phase, in step 710, either the target party 103T acting as the setup party or a third party submits a set of one or more challenges Ci (i=1,...,n, where n>=1) to the PUF module 603. These are secondary challenges when ePUF500 is used. If the target party 103T possesses the PUF module 603 and is performing the setup, the challenges Ci may be generated by the target party 103T or received from the third-party system 602 or the verifier 103V. If the third party possesses the PUF module 603 and is performing the setup, the challenges may be generated by the third-party system 602 or received from the target party 103T or the verifier 103V. In either case, in the response, the PUF module 603 generates a corresponding set of response Ri based on PUF302 / 500. These are second-order responses in the case of ePUF500. Therefore, this method generates a set of CR pairs {Ci,Ri}.

[0112] In the embodiment, access to the PUF module 903 is restricted so that only the target party 103T (and the setup party, if different parties) can obtain access to the response Ri. This can be achieved by access control logic 404 or 404' which can grant access only to parties who can present recognized credentials such as passwords, PINs, or biometric data. And / or, access to the physical interface with the PUF module 603 can be physically protected, such as by storing it in a locked container, cabinet, or room, or legally protected, such as by storing the PUF module 603 in a room or complex where only specific personnel are allowed access. As another alternative or additional restriction, in the case of ePUF 501, knowledge of the primary challenge Cw may be restricted so that only the target party 103T (and, in the embodiment, a trusted third party acting as a separate setup party) knows the Cw.

[0113] In step 720, the method includes storing response data in the response data store 601. In embodiments, the stored response data includes a record of the generated CR pairs {Ci,Ri}. The record of each CR pair includes a record of each response Ri stored in a manner indicating the corresponding challenge Ci of the pair. In embodiments, the stored record of each response Ri includes an explicit value of the response, i.e., the actual value of Ri, which is explicitly disclosed to a verifier 103V who can read the record. The value may be stored in plaintext or encrypted if the verifier has a decryption key to decrypt the value, but nevertheless, the stored value is still said to be an explicit value for the purposes of this specification in the sense that it is explicitly disclosed to the verifier 103V. Alternatively, the record of the response may also include a “proof” of the response Ri, which includes a deterministic transformation of Ri. One example is a hash H(Ri) or a double hash H 2 This would involve remembering the value of (Ri). This is the same transformation that the verifier applies to R'i (for example, H(R'i) or H 2This method allows checking whether the value of response R'i is the same as that recorded in the store by checking whether (R'i) matches the proof. This has the advantage that the actual value of response Ri is not disclosed. Therefore, this modified form of the method may be particularly useful when store 601 is a public medium such as a blockchain. However, encryption would be another possibility.

[0114] If the response data is stored in an encrypted format, each response data (e.g., each CR pair) may be encrypted individually, requiring a different decryption key for each to decrypt. Alternatively, a subset or entire set of response data (e.g., all CR pairs for a given target party 103T) may be encrypted together, and all may be decryptable as a group with the same key.

[0115] Response data, such as CR pairs, is stored in the response data store 601 in association with evidence of the target's identity. For example, the target party 103T may be required to generate one or more pieces of identification information, such as a passport, as part of the setup. The evidence held in the response data store 601 in association with the response data may include a copy of this information itself (in plaintext or in an encrypted form accessible to the verifier 103) explicitly stored in association with the response data. Alternatively, if the response data store 601 is managed by a trusted third party or the verifier 103V itself, the mere fact that the response data is registered in the response data store 601 in association with a particular identity may be considered sufficient evidence (assuming the verifier 103V trusts that the setup party and the party managing the response data store 601, such as a trusted third party, have properly checked the target party's identification information during setup).

[0116] In the verification phase 704, in step 730, the verifier 103V accesses the response data store and determines the response data to be used in the verification operation. In an embodiment, there may be multiple potential verifiers 103V, each assigned one or more different subsets of CR pairs. That is, the response data store 601 discloses to a given verifier 103V only the expected response Ri of the CR pair assigned to that party. For example, this scheme may be managed by a trusted third-party system 602. Such a scheme advantageously keeps the CR pairs separate so that one verifier 103V cannot pretend to be a target to the other party. However, this is not essential if all verifiers 103V granted access to the store 601 are trusted parties.

[0117] In one embodiment, verifier 103V initially does not know which challenge it intends to use and determines this by accessing it from datastore 601 along with the corresponding response data (e.g., response or proof). Alternatively, verifier 103V knows in advance which challenge it intends to use and uses this to determine which response data in datastore 601 maps to it.

[0118] In a scenario where a verifier 103V (or any party in fact) accesses data from the blockchain, such as to determine response data and / or challenges, access to the blockchain can be performed either by directly querying nodes in the blockchain network or indirectly by querying an intermediary service that caches blockchain data or mediates queries on behalf of the party seeking access to the blockchain data. For example, verifier 103V could also access data from another service provider that is not directly connected to the blockchain network 106, but might only provide response relation data, and possibly Merkle proofs as well.

[0119] In step 740, verifier 103V submits a challenge Ci to target party 103T, which possesses or controls the PUF module 603. This challenge corresponds to one of the records accessed by verifier 103V from the response data store 601 in step 730. In a scenario where a trusted third party possessed the PUF module 603 during setup, the PUF module 603 may be physically transferred from the trusted third party to target party 103T between setup phase 702 and verification phase 704.

[0120] In response to the submitted challenge Ci, the PUF module 603 generates a corresponding response Ri, which the target party 103V returns to the verifier. In step 750, the verifier checks whether the received response Ri matches the expected response according to the response data accessed from the response data store 601 in step 730.

[0121] As mentioned above, the party performing the setup step 702 may be the target party 103T or a trusted third party storing the response data (e.g., CR pairs). In further modified forms, these steps can be performed by another coordinator, such as a trusted Oracle (in an embodiment, another third party other than the parties, running a third-party computer device 602 with datastore 610). In such embodiments, datastore 601 can be a third-party system 602 (of a different third party) or a public peer-to-peer medium such as a blockchain. and / or, in yet further modified forms, separation can be provided between the party performing the input to the PUF module 603 and the party receiving the output.

[0122] Furthermore, as mentioned above, there are at least two possibilities for how the response Ri is recorded in the response data store 601. The first of these is simply to explicitly store the actual value of Ri itself. In this case, step 750 simply involves comparing the stored value (established in setup 702) with the value R'i (the intended value of the response Ri) currently received in response to the submitted challenge Ci (in verification phase 704). If they match, the method branches to step 760, where it is declared that the identity of the target party 103T has been verified. Otherwise, the method branches to step 770, where it is declared that the identity of the target party 103T has not been verified.

[0123] The second possibility is that only the proof of Ri is stored in the response data store 601, which is, for example, a hash or a double hash. In this case, the verifier 103V applies the same transformation used to generate the proof to the response R'i returned from the target party 103T in the verification phase 704. If this matches the stored proof, the method branches to step 760, where it is declared that the identity of the target party 103T has been verified. Otherwise, the method branches to step 770, where it is declared that the identity of the target party 103T has not been verified.

[0124] In the response data store 601, there are at least two possible ways of indicating that a corresponding challenge Ci is associated with each recorded response Ri. The first is simply to store the explicit values ​​of each CR pair {Ci,Ri}, i.e., the actual values ​​of Ri and Ci (either in plaintext or encrypted). Alternatively, a second, lighter method is for the challenge Ci to store a master challenge Cm from which can be derived according to a given deterministic challenge derivation function f.

[0125] This is illustrated in Figure 8A. Each response Ri is stored in relation to its respective index. Function f is either stored in the response data store 601 or is known in advance to the verifier 103V. In either case, the verifier 103V inputs the master challenge Cm into function f to determine the challenge Ci corresponding to at least one index i of the response Ri. The verifier 103V then uses this challenge Ci to validate the target.

[0126] In some such embodiments, the function f may also be a function of identification information 806, which may be a single piece of identification information or a combination 804 (e.g., concatenated) of multiple pieces of identification information 802 (e.g., passport information, mother's maiden name, and fingerprint information). This may include identification information of a target party 103T. This makes available a set of challenges Ci specific to a particular target party 103T, which is advantageous for security reasons, as uniqueness may be important, for example, if the same third-party system 602 is used to generate challenge sets for different target parties. Using personally identifiable information such as the target party 103T's passport information or mother's maiden name is a good choice because it is something the target party already knows, possesses, and tends to keep secret.

[0127] Alternatively, or in addition, the identification information 806 may contain the identification information of verifier 103V, so that f is a function of the identity of a particular verifier 103V. This could also be used to assign a particular subset of one or more specific challenges to a particular verifier 103V, so that different verifiers 103V are given different challenges Ci to use in verification 704.

[0128] In some embodiments, regardless of how the master challenge Cm is formed, the challenges Ci may be mapped to the master challenge Cm in a chained manner, such that C1 = f(Cm), C2 = f(C1), etc., as shown in Figure 8B. In other words, the first challenge C1 is determined by applying a function f to the master challenge Cm, then the second challenge C2 is determined by applying the same function f to the first challenge, and so on. As an example, f may include a hash function.

[0129] In another form of modification, as shown in Figure 8C, Challenge Ci can be mapped to Master Challenge Cm in a hierarchical manner. This will be explained in more detail later.

[0130] The chained approach is lighter and can be more easily recovered from root information if f() does not require any data other than the root key. In the case of hierarchical derivation, an index in the tree is added, which is unnecessary for a simple chain such as C_m, H(C_m), H(H(C_m))... where f() is simply a hash function.

[0131] Regardless of whether the master challenge is in the form of f() or whether it contains identification information and / or other information, in this embodiment, the master challenge Cm may be received by a third-party system 602 from the target party 103T in setup 702. The third party then stores the received master challenge in datastore 601 (e.g., either locally or on the chain) for future use in verification 704. Alternatively, the third-party system 602 receives a set of challenges Ci from the target party 103T and derives the master challenge Cm from them, for example, by applying the reciprocal of the function f(). In modified forms of these approaches, the third-party system 602 may receive the identification information, master challenge, or set of challenges from somewhere other than the target party 103T, for example, from an Oracle or a coordinator (not shown). It is also possible to use a combination of such approaches (e.g., one set of identification information is received from the target party and the other is obtained from somewhere else). Or, in a further alternative form, no third party is involved, and the target party 103T stores the master challenge itself on the chain (or in some other peer-to-peer public medium).

[0132] In a further modified form of the method in Figure 7, the response data stored in the response data store 601 may not include a record of the CR pairs generated in the setup. Instead, the response data may include the public keys of public-private key pairs, or a set of such public keys, each of which one or more key pairs was generated based on its respective PUF response Ri from the setup phase 702. For example, response Ri may be used as a seed in a public-private key pair generation algorithm. In such an embodiment, the method proceeds as described in Figure 7, except that in step 730 the verifier accesses one of the stored public keys and in step 740 the verifier 103V does not submit a challenge Ci to be entered into the target PUF module 603. Instead, the verifier 103V obtains a message (e.g., a document, file, or part of a blockchain transaction) that has been (intended) signed by the target. This message may be sent to the verifier 103V by the target party 103T, or the verifier 103V may autonomously access it from a public medium such as a blockchain or website. In any case, in step 750, the check involves verifying the signature applied to the message using the public key accessed from store 601 (which is itself based on well-known public-key private-key signature verification techniques, which are well-known in the art).

[0133] Next, several exemplary identity establishment and verification protocols for ePUF or PUF are described more generally by embodiments disclosed herein. We consider the certifier Alice (target party 103T) and the verifier Bob (verifier 103V). There are at least three different challenge types in the PUF identity system. For example, the following is described in relation to ePUF, but more generally, any PUF device can be used (any device including PUF module 603). 1. Remote PUF Challenge - The verifier challenges the prover remotely by requesting a response from Alice to a challenge submitted by Bob. In this mode, the verifier assumes that they know the expected response from the prover's PUF and that the PUF is owned by the rightful owner. 2. Local PUF Challenge - The verifier challenges the prover locally by interacting with a PUF device controlled by Alice. In this mode, it is assumed that the verifier knows something about the prover's identity but nothing about the behavior of its PUF. 3. Cryptographic Challenge - The verifier challenges the verifier to meet some cryptographic requirement related to the verifier's identity, such as by signing the message with a key that is certifiablely linked to the authenticated public key.

[0134] In types 1 and 2, the challenge explicitly relies on the PUF module 603 from both the prover's and verifier's perspectives. The challenge in these cases, and therefore the corresponding verification process, is essentially linked to the operation of the PUF device (a device containing the PUF module 603, e.g., Alice's computer equipment 102T). In these cases, we utilize the property of the PUF device that its physical state is uniquely bound to its identity, and therefore the PUF plays a central role in the identity system being utilized.

[0135] It should be noted that the terms “remote” and “local” specifically refer to the interaction between the verifier and the prover’s PUF when conducting a challenge. This does not preclude remote challenge protocols from having a setup phase that involves prior local interaction between the prover and the verifier.

[0136] However, in Case 3, the challenge and verification process only needs to relate to the PUF device from the prover's perspective. Verification does not depend on the verifier knowing whether the PUF was used by the prover when generating a response to the challenge. In this case, this method simply uses the utility of the PUF as a key generator for Alice, rather than for its utility in linking identity to the device itself.

[0137] Next, exemplary implementations are provided for the setup and verification, as well as optional updates and revocation processes, for the identity system in each of the three operating modes described above. In embodiments, a general trusted third party is involved in the processes related to the PUF-based identity system. This is because such identity systems tend to require such a third party to meaningfully guarantee the integrity and reliability of the identity and associated credentials. Where an individual's identity is to be established and used in such a system, the trusted third party in consideration may be a certification authority, a government agency, or a financial service provider such as a bank.

[0138] When an identity is to be established for a machine or non-human entity, the third party may be the device manufacturer, issuer, regulator, or other relevant entity. This case is particularly suitable for the Internet of Things (IoT) or even the Blockchain of Things (BoT) paradigm, where an identity should be assigned to different members of a network of devices that can collaborate to perform tasks or calculations to achieve some goal.

[0139] 3.1. Remote PUF System 3.1.1. Setup: In the case of a remote PUF challenge, the verifier submitting the challenge C to the prover is assumed to know the expected response R in advance. This means that the setup process in this case must establish a set of CRPs (i.e., at least one) between Alice and the other party, which can be used to derive a shared secret between the parties that can later be used to authenticate Alice's identity.

[0140] As previously stated, Alice establishes this shared secret with a general third party who is prepared to establish her identity, and assumes that this third party may or may not be a verifier who later participates with Alice in the verification process. If the verifier is different from the identity-establishing third party, assume that the verifier may obtain relevant CRP information from the third party that will be used for the shared secret.

[0141] Here, for the setup phase, there are two different options, depending on whether Alice is the only party who can access the PUF device at any time, or whether a trusted third party may also have access to the PUF device only during the setup phase.

[0142] Case 1: Alice has the sole access to the PUF. 1. The ePUF device is manufactured and distributed to Alice. 2. Alice requests to link her identity to the ePUF device by contacting a trusted third party. i. The third party establishes an identification account for Alice and requests proof of Alice's identity. ii. Alice provides relevant identification documents or certificates of qualification to a third party. iii. A third party verifies Alice's identity. 3. Alice and the third party establish a secure communication channel for the remainder of the setup process (e.g., via a standard Diffie-Hellman key exchange). i. Alice and the third party each use the public key P. A , P T Replace it. ii. Alice and the third party use temporary secrets for the rest of the setup communication, S=S A ·P T =P A ·S T To be established independently. iii. Alice and the third party initiate communication over a channel secured by S, such as an AES encrypted channel. 4. A third party challenges Alice on a secure channel C1, C2, ..., C n Send the set. 5. Alice receives responses from the ePUF device R1, R2, ..., R n Obtain it. 6. Alice responds to third parties on a secure channel R1, R2, ..., R n Send. 7. The third party sets the response CRPs for Alice's identity account {(C1,R1),(C2,R2),...,(C n ,R n Remember )}.

[0143] Case 2: A third party accesses the PUF during setup. 1. The third party possesses knowledge of the base pair and hash function. For example, the ePUF device is manufactured and distributed to a trusted third party*. 2. A third party may obtain base CRP(C) from the device. w ,R w ) obtain. 3. Alice requests an identity-linked ePUF device by contacting a third party. This may be done over an unsecured communication channel. i. The third party establishes an identification account for Alice and requests proof of Alice's identity. ii. Alice provides relevant identification documents or certificates of qualification to a third party. iii. The third party verifies Alice's identity and the ePUF device and its base pair (C W ,R W Assign ) to Alice's account. The shared secret is either this CRP or a secret derived from this CRP. 4. The third party sends the ePUF device to Alice.

[0144] (*The device may be initially distributed to Alice and then sent by Alice. However, in most cases, it makes more sense for the device to be distributed directly to a third party. For example, if the device is a smart debit card, the card may be sent from the manufacturer to the issuing bank and then from the issuing bank to the customer, Alice, in accordance with the PUF setup.)

[0145] The setup protocol establishes a shared secret between Alice and a trusted third party, which will later be used to authenticate Alice's identity (or the device containing the PUF) during the verification process. These cases are also similar in that both preferably involve secure communication between Alice and a trusted third party.

[0146] However, the difference between the two cases is that Case 1 achieves secure communication by establishing a secure communication channel, while Case 2 achieves it using physical security.

[0147] Another notable difference between the two protocols in Case 1 and Case 2 is that in Case 2, a trusted third party can derive the same number of CRPs as Alice without PUF, whereas in Case 1, this third party must remember a fixed number of pairs.

[0148] This is an advantage of Case 2 over existing protocols that use PUF devices to set up users, because it allows a trusted third party to remotely generate any number of CRPs, whereas existing protocols may require the trusted third party to cooperate with either the end user or the device manufacturer to do so. The same technical advantage is in Case 1, where Alice uses a base pair (C w ,R w This can be achieved if the step of sending ) to Bob over the security channel (trusting that a third party will not maliciously use the base pair) is added.

[0149] It should be noted that using secure communication during the setup phase allows future communications, such as verification processes, to be transmitted over channels that are not guaranteed to be secure. This has the advantage of allowing verification to be performed with fewer technical constraints, such as the requirement that both parties be online during verification, and only requires additional secure communication overhead for this one-time setup process.

[0150] 3.1.2. Verification: Recall that in remote PUF verification mode, there were two different cases in the setup phase, which are reflected in slightly different remote verification protocols, as detailed below.

[0151] Case 1: Alice has the sole access to the PUF. 1. Bob sets unused CRPs such as (C1,R1), (C2,R2), ..., (C n ,R n Obtained from )}. i. If Bob is also a trustworthy third party, Bob simply takes elements from this set. ii. If Bob is not a trusted third party, Bob will communicate with the third party by requesting Alice's unused CRP. 2. Bob sends Challenge C1 to Alice. 3. Alice retrieves candidate response R'1 from her ePUF device and sends it to Bob. 4. Bob verifies whether R'1 == R1. i. If the answer is yes, the verification is successful. ii. If the answer is no, the verification fails. 5. The pair (C1,R1) is then removed by a trusted third party, leaving the remaining set of challenge-response pairs {(C2,R2),(C3,R3),...,(C n ,R n Leave )}.

[0152] Step 1.ii ensures that the single-use nature of the CRP does not allow any Bob to "impersonate" Alice using a particular CRP, because a trusted third party can simply monitor the use of each pair in each given situation, and a fresh CRP should be used for every authentication attempt.

[0153] Case 2: A third party accessed the PUF during setup. 1. Bob generates a fresh Challenge C for validation. This can be done randomly or deterministically from some other data (e.g., known KYC data, biometrics, images, etc.). 2. Bob sends Challenge C to Alice. 3. Alice retrieves candidate response R' from her ePUF device and sends it to Bob. 4. Bob obtains the expected response R. i. If Bob is a trustworthy third party, then Bob can have R = hash(C,R w The response can be directly calculated by calculating (H)*. ii. If Bob is not a trusted third party, Bob sends C to the third party and requests a response R. 5. Bob verifies whether R' == R. i. If yes, the verification is passed. ii. If no, the verification fails.

[0154] (*This is because a third party has obtained the base pair (C W ,R W ) in the setup protocol (case 2), which means that R W is known to them. Also, the hash function H is assumed to be a public standard such as SHA - 256, which is known to at least the third party, not necessarily everyone.)

[0155] 3.1.3. Update: It may also be desirable to specify the process for Alice and the third party to establish a fresh CRP when given the property of being used only once in verification (and other useful protocols such as login).

[0156] Case 1: Alice has the only access right to the PUF. In this case, another secure channel is established between Alice and the third party to transmit challenges and responses, similar to the setup. We assume that Alice has at least one remaining CRP in the form of (C i ,R i ) to establish a shared secret S = H(R i ) or a similar form, or has access to the previous shared secret S = S A ·P T =P A ·S T from the DH key exchange. 1. Alice and the third party establish a secure communication channel using the shared secret S. This can be derived in many ways, and the protocol is agnostic to this. 2. The third party sends a set of challenges C1, C2,..., C n to Alice over the secure channel. 3. Alice obtains responses R1, R2,..., R n from the ePUF device. 4. Alice responds to third parties on a secure channel R1, R2, ..., R n Send. 5. The third party sets the response CRPs for Alice's identity account {(C1,R1),(C2,R2),...,(C n ,R n Remember )}. Note that steps 2-5 are at least identical to setup steps 4-7.

[0157] Alice to a third party on the channel (C w ,R w Please also refer to the previous comments regarding conveying ).

[0158] Case 2: A third party accessed the PUF during setup. In this case, the third party accessed the base pair (C w ,R w Since we have knowledge of both the CRP and the hash function H(), we can indirectly generate any number of CRPs. This means that there is no requirement for interactive updates in this case.

[0159] 3.1.4. Revocation: A further part of the identity system may be for specific ePUF devices that are to be revoked and are therefore no longer used for identity purposes. The revocation process is simple and can be carried out either as (i) revocation by a third party independent of Alice, the user, or (ii) revocation by Alice as communicated as a revocation request.

[0160] The first case does not require any technical means involving an ePUF or anything else. The second case does not require any protocol or solution specific to ePUF, because a good example of the need for expiration in the first case is when Alice loses the physical device containing the ePUF, or when it is damaged in any way.

[0161] However, if Alice still has physical control of the device and optionally desires to leverage ePUF in the revocation process, it may be stipulated that Alice's request be authenticated using one of the CRPs (or its derived shared secret) established between Alice and a third party, such as using HMAC or, in each case, an encrypted message using the CRP response or secret as the key. However, for the reasons mentioned above, this is by no means considered a strict requirement of the system.

[0162] 3.2. Local PUF System 3.2.1. Setup: The setup that can be used for a local PUF is exactly the same as the setup for a remote PUF, but the difference between the local and remote cases lies in how the verification steps are performed below.

[0163] 3.2.2. Verification: In this scenario, verification is performed locally. This means that the verification process requires both the prover (Alice) and the verifier (Bob) to be in the same physical location.

[0164] This scenario could be relevant to legal proceedings (regarding human identity) if, for example, Alice is legally required to use an ePUF device to interactively manipulate the investigation locally, or if an analysis of an IoT system should be performed (regarding device identity) and the system administrator may want to explicitly check the response of a particular device locally. This could also be relevant to settlement scenarios.

[0165] Other scenarios where such a process may be applicable include the diagnosis of a vehicle after a collision, where authorities would want to determine precisely which digital component issued the command. In this case, input C could be some environmental or dynamic condition, and response R would be part of the command given by the device.

[0166] The difference between the local PUF verification protocol, outlined below, and the previous remote PUF verification protocol is that this local protocol does not assume that the verifier has prior knowledge of the ePUF response. In other words, the response generated in the local verification process is not available to the verifier in advance.

[0167] However, in this scenario, the challenges used in the verification process may have some significance. For example, if the identity is a base pair of embedded ePUF components (C w ,R w Consider a machine that could be considered to be [a specific device]. A verification process may be performed to verify that it was this particular device that previously produced an output R from a given input C. 1. Bob obtains the relevant Challenge C to submit to the ePUF device based on the CRP(C,R) of interest. 2. Bob gains access to the ePUF device. 3. Bob uses the ePUF device to calculate the candidate response R'=hash(C,R w Generates H). 4. Bob verifies whether R' == R. i. If the answer is yes, the verification is successful. ii. If the answer is no, the verification fails.

[0168] In these scenarios, Bob does not know the candidate response R' beforehand, but rather verifies that the response now received from the PUF device matches a previously generated response. For example, this could be used (e.g., in a courtroom) to verify that the person (Alice) or dominant device that generated the response is the same person or device that is now present (e.g., in a courtroom). For example, in the digital component example, this would be configured to generate R based on some input challenge C and then issue a command. For example, if the device is a self-driving car and the component receives a challenge derived from, or containing, the data "the car in front is too close", a response R is generated, and R triggers the component to issue a command to apply the brakes. Thus, in retrospective diagnostic verification, the verifier wants to believe that the car slowed down and verify that the condition was indeed "the car in front is too close" which triggered that response.

[0169] 3.2.3. Update: The process for generating the updated CRP can follow the same logic as submitted for the remote case, but the key difference in this scenario is that it applies only to validation.

[0170] 3.2.4. Expiration: The same techniques described for remote expiration are also applicable here.

[0171] 3.3. Encryption PUF System 3.3.1 Setup: In this case, Alice establishes her identity with a third party using standard cryptographic methods, but in the process, she uses an ePUF device.

[0172] In this scenario, a third party may, at their discretion, have knowledge that the ePUF is being used in the process. Similarly, with respect to an identity established in this manner, the identity verifier may or may not know that the ePUF device is involved in the identity verification process. In other words, the following protocol only stipulates that Alice, the owner of the device, has knowledge that the ePUF device is involved in the identity system. 1. The ePUF device is manufactured and distributed to Alice. 2. Alice requests to establish an encrypted identity by contacting a trusted third party. i. The third party establishes an identification account for Alice and requests proof of Alice's identity. ii. Alice provides relevant identification documents or certificates of qualification to a third party. iii. A third party verifies Alice's identity. 3. Alice chooses an encryption method to establish an encrypted link to her identity, for example, to establish an authenticated asymmetric key pair using her CRP. i. A third party receives the public key P from Alice. A Obtain P A =s A G is an EC key pair. ii. A third party can use Alice's private key s A It requests that the message m be signed using (for example, via ECDSA). iii. Alice signed the ECDSA signature (P A Generate ,m) and send it to a third party. iv. A third party verifies the signature. 4. If the signature is valid, the third party may use key P A This will be proven by comparing it with Alice's identity.

[0173] Step 3 involves using a cryptographic scheme of the user's choice, but we assume that the relevant key involved in this process is a derived key of the CRP response known only to Alice. In the example selected above, the private key S A is, S A =H(R) means that it is derived from a specific ePUF response R.

[0174] 3.3.2 Verification: In the encryption case, identity verification is performed using the encryption information established during the encryption setup phase, which was detailed earlier. In this case, we take the example that an authenticated EC asymmetric key pair is established for Alice's identity during setup, and that key is used for verification.

[0175] However, the following protocol can be easily adapted to other cryptographic schemes, where appropriate, simply by replacing the existing setup and verification protocols with those schemes. The difference here is that the ePUF device is used as a secure key generator for the setup and verification processes, which reduces the risk of malicious risk to Alice, the key holder. 1. Bob has Identity Link Information P A For example, obtain an authenticated key. i. If Bob is a trusted third party, Bob can simply take P from Alice's account. A Take it out. ii. If Bob is not a trusted third party, Bob will communicate with the third party and request an authenticated public key for Alice. 2. Bob selects a message for Alice to sign and sends it to her. 3. Alice generates a signature for message m. i. If Alice wants to sign with her authenticated key, sign Sig(P A Generates ,m). ii. If Alice wants to sign with a one-time used derived key, Alice will sign with Sig(P αGenerates P α =P A +H(d)·G and d are some one-time use data*. 4. Alice sends the signature to Bob. At this point, Alice may also send data d if Bob is not yet aware of it. 5. Bob is P A Verify the signature by matching it with the public key using (and d) where applicable. i. If the signature verification is successful, the identity verification will also be successful. ii. If signature verification fails, identity verification will also fail.

[0176] (*This data may be relevant to verification, such as invoice messages or biometric fuzzy matching data. Data d may be selected by Bob or Alice. Alternatively, d may be a shared secret known to Alice and Bob, for example, it may be derived using Diffie-Hellman key exchange and / or HMAC.)

[0177] The cryptographic verification process described above can be applied to independently established identities, as explained in the previous section, when the identity is established using EC or similar cryptographic primitives such as PGP keys.

[0178] 3.3.3. Update: The process of updating Alice's identity here does not depend on the use of an ePUF device in key generation, so as such, there is no need to specify a particular method here. Instead, P A Standard methods for updating authenticated keys, such as those mentioned above, may be used.

[0179] For signing or other cryptographic processes required by existing processes, it can simply be assumed that ePUF is involved in key generation.

[0180] 3.3.4. Failure: Similarly, there is no need to specify a particular failure protocol here, and it follows the standard mechanism. Once again, it may be assumed that the ePUF is involved in the background as the key generator for the relevant cryptographic operations.

[0181] 3.4. Independent PUF Mechanism 3.4.1 Setup: In an independent case where an ePUF device is used to establish an identity, consider a scenario where an entity wishes to establish either a human identity independent of any third party or a device identity within a closed system. The only party involved in this process is the "owner" of the ePUF device, which is Alice, who will ultimately be the prover in subsequent verification.

[0182] Case 1: Alice establishes a human identity. 1. Alice acquires an ePUF device. 2. Alice probes the ePUF with a challenge C. 3. Alice obtains a response R from the ePUF. 4. Alice uses the pair (C, R) to establish an identity for herself. i. Alice can establish an unauthenticated identity key P A using an encryption setup. ii. Alice publishes her identity key for her identity. 5. Alice may wish to publish a proof for her CRP, such as the double hash H 2 (R) of the response.

[0183] This case, where Alice establishes a "self-sovereign" identity for herself, is somewhat useful in that it provides a unique and reproducible device identifier for devices controlled solely by Alice. However, the absence of a trusted third party in such an identity system means that a verifier must later trust the link between the certifier's identity and the certifier's device. This could have very limited applications in the real world.

[0184] Case 2: Alice established an identity with the device. 1. Alice obtains the ePUF device. 2. Alice explores the ePUF in Challenge C. 3. Alice obtains the response R from the ePUF. 4. Alice uses the pair (C, R) to establish her identity for the device within her system. i. Alice maps the pair (C, R) to her device. ii. Alice maintains a database of all her devices and CRP mappings. 5. Alice has a double hash of the response H 2 You may wish to publish your proof of your CRP levels, such as (R).

[0185] In the above case, we can see that when we create a "self-sovereign" identity for a device, the design is very useful within a closed system, and administrators can focus their attention on simply identifying different devices within the system. This can also be helpful for proof to others later on. However, the absence of a trusted third party during setup still limits who can prove that the device has not been tampered with, depending on the scenario.

[0186] It should be noted that Case 1 and Case 2 are the same process but may have different intended purposes. Therefore, Case 1 and Case 2 can be seen together as methods for generating a “self-sovereign” identity for a human or machine, in the latter case, where the system administrator (such as Alice in an IoT system) is a trustworthy entity. In both cases, Alice is a trustworthy entity.

[0187] 3.4.2 Verification: The verification process in this case is as simple as exploring the ePUF device with a given challenge and examining its response. More complex proof or evidence against external parties may be built upon this to prove identity.

[0188] 3.4.3 Update: In this case, the update process is simply a repetition of the setup process, with the administrator (Alice in this case) listing additional CRPs for forward use.

[0189] 3.4.4. Expiration: In this scenario, the only type of identity expiration is when the administrator (Alice) wishes to independently revoke the identity, since there are no third parties involved in this process. This means that expiration can be as simple as deactivating Alice on the ePUF device and purging the CRP database.

[0190] Later sections will disclose how this loss of self-sovereignty can be made more robust through blockchain proof and evidence presentation, thereby allowing for the later convincing of external parties.

[0191] 3.5. Identity-based CRP management In the aforementioned remote PUF-based identity systems, the one-time use nature of the CRP used to authenticate identity in the setup and verification protocols presents a CRP management challenge to the parties involved.

[0192] For example, if a trusted third party does not access the PUF device during setup, many CRPs {(C1, R1),(C2, R2), ..., (C n , R n It may be desirable for the following to be enumerated. Furthermore, since the ePUF itself acts as a deterministic pseudo-random mapping of challenges to responses, the responses appear to be unrelated to each other. Therefore, the burden of a trusted third party tabulating and remembering a set of CRPs for its users or clients quickly becomes a scaling problem when they have to serve a large number of users.

[0193] Figure 8A illustrates the deterministic derivation of the challenge from identification data according to the embodiments disclosed herein.

[0194] According to such an embodiment, in order to address the issue of burden on a trusted third party, CRP management is implemented for challenges C1, C2, ..., C n This is primarily dealt with in the generation of challenges. The idea here is that challenges should be deterministically (and possibly hierarchically) derived from a single master challenge, or from the master data from which the master challenge is derived. This concept is similar to the use of hierarchical deterministic (HD) wallets for managing one-time Bitcoin keys, in that they are designed to allow a trusted third party (or another relevant party) to recover all relevant challenges using only the master data known as the "wallet seed" in the Bitcoin scenario.

[0195] In some such embodiments, Alice's (target party 103T) identification data 806 is used as master data to generate a wide-ranging challenge for determining which CRP is used in an identity system, such as the one proposed in the previous section. The identification data itself may consist of a combination 804 of different data elements 802, but in the combination, they preferably have the following characteristics: • Uniqueness - Identifying data is unique to the entities it relates to. • Confidentiality - Identification data is known only to the entity (or its owner) to which it pertains.

[0196] Simple examples of components of identification data may include passport numbers, national health insurance numbers, names, dates of birth, or answers to security questions (e.g., mother's maiden name), or, in the case of device identification, serial numbers and manufacturing information. However, it is recognized that data obtained by more sophisticated technological means, such as fingerprint or facial recognition data, may also be used, which can be extracted using fuzzy magic techniques to preserve uniqueness.

[0197] In embodiments, the “identification data” used as the master input from which the set of challenges is derived may include the diversity described above. One reason for this is to ensure that the information retains confidentiality about as many trusted third parties as possible, given that some of the protocols in the previous section rely on sharing challenges with third parties and / or external verifiers. Identification data containing multiple components would be difficult for any third party to completely replicate without the consent of the verifier Alice.

[0198] A mechanism for deterministically generating a CRP using identification data is shown in FIG. 8A. The components of the identification data are first combined by process “A” (804), which may be concatenation, bitwise operations (e.g., XOR), or any other relevant combinatorial operation, and this operation is required to preserve privacy by converting raw data into an unreadable form.

[0199] Next, the identification data is converted into a master challenge C m using a hash function or a similar process. Finally, the master challenge is used to deterministically derive a sequence of one-time use challenges C1, C2, ..., C n using a derivation function f(). In an embodiment, as shown in FIG. 8B, the derivation function f() may include a hash function and nonce injection, whereby each successive challenge is generated as C i =SHA256(C i-1 , i), where i acts as a nonce.

[0200] Process A, the generation of challenge C from the identification data, and the derivation function f() can all be configured according to the requirements of a particular implementation. m

[0201] FIG. 8C shows another specific example, namely, a hierarchical and deterministic derivation of challenges (responses are not depicted). As shown in FIG. 8B, it may be desirable to derive one-time use challenges C m from master C in a hierarchical manner. In this case, CRP management is further improved by the fact that the generation of a particular challenge does not need to depend on all of the previous challenges as in the previous case. i

[0202] ​The use of deterministic derivation of challenges based on identity data reduces storage overhead for both the prover Alice and trusted third parties in identity protocols. Either party only needs to store the identification data (or a subset thereof) and can recalculate the required challenges as needed.

[0203] Furthermore, Alice also has the option to reshape her privacy by choosing to retain or share as much information as she wishes with each identification service, but there is also the trade-off of potentially storing more data herself.

[0204] 4. Exemplary Blockchain Systems Next, we describe exemplary blockchain systems that may be employed in some embodiments of this disclosure. "Alice" and "Bob" are merely arbitrary names for the two parties, and Alice and Bob do not necessarily have the same roles in this section as they do in the previous or following sections.

[0205] In some embodiments, response data based on the output of a PUF can be stored on the chain, as described, for example, in the previous section. Response data stored on the chain can take the form of the actual response itself, a transformation of the response such as a hash or double hash (a so-called proof or hash commit), or the public key of a public-private key pair derived from the PUF response. Whatever form the on-chain response data takes, it is something that allows another verifier to check whether the target response or signature presented as proof of identity is as expected. In further embodiments, the blockchain can be used as a means of managing the challenge-response pair, such as updating or revoking it.

[0206] Next, we will describe an example of a blockchain system that could be used to implement such features.

[0207] 4.1. Exemplary System Overview Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, a wide-area internet, typically such as the Internet. The packet-switched network 101 may include a plurality of blockchain nodes 104 that can be arranged and configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be arranged and configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0208] Each blockchain node 104 includes the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 includes processing equipment, including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage devices in the form of non-temporary computer-readable media. Memory may include one or more memory units employing one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disc drives.

[0209] Blockchain 150 contains data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within a decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean completely memorizing blockchain 150. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 remembers the block header (described below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to a kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 contains at least one input and at least one output. Each output specifies an amount representing the quantity of digital assets as property, one example being user 103, whose output is cryptographically locked (requiring the user's signature or other solution to unlock and thereby redeem or spend it). Each input points to the output of the preceding transaction 152, thereby linking the transactions.

[0210] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining the order of the blocks 151. Each transaction 152 (other than coinbase transactions) contains a pointer that points to the previous transaction, defining the order of the sequence of transactions (note: the sequence of transactions 152 is allowed to fork). The chain of block 151 traces back to the genesis block (Gb) 153, which was the first block in the chain. One or more early original transactions 152 in chain 150 pointed to the genesis block 153 rather than a preceding transaction.

[0211] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. This term as used herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid, to which the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0212] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or “consumed” in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be accepted. Thus, “preceding” as used herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in a temporal sequence, and therefore does not necessarily preclude transactions 152i, 152j from being created or sent out of order (see the following explanation of orphan transactions). A preceding transaction 152i can also equally be called a previous transaction or preceding transaction.

[0213] The input to transaction 152j also includes input authorization, such as the signature of user 103a, whose output of the preceding transaction 152i is locked. The output of transaction 152j can then be cryptographically locked to a new user or entity 103b. Transaction 152j can therefore transfer to the new user or entity 103b the amount defined in the input of the preceding transaction 152i, as defined in the output of transaction 152j. In some cases, transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to give change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0214] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or organization, wishes to formulate a new transaction 152j (either manually or through an automated process adopted by the party), the implementing party sends the new transaction from its computer terminal 102 to the recipient. The formulating party or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (currently typically a server or data center, but in principle, it could be another user terminal). It is also not ruled out that the party 103 formulating the new transaction 152j may send this transaction directly to one or more blockchain nodes 104, and in some examples, not send it to the recipient. The blockchain node 104 that receives the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i to which the new transaction assigns, the condition typically includes checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may be modified simply by the blockchain node protocol alone, or by a combination of these.In any case, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 then apply the same test according to the same blockchain node protocol, and so on, forwarding the new transaction 152j to one or more further nodes 104. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0215] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., consumed) is, according to the blockchain node protocol, whether it has still been validly redeemed by the input of another, preceding transaction 152j. Another condition for a transaction to be valid is that the output of the preceding transaction 152i, which attempts to redeem it, has not yet been redeemed by another transaction. Again, if it is not valid, transaction 152j is not propagated (unless it is flagged as invalid for a warning and propagated) or recorded on blockchain 150. This protects against double spending, where a transaction executor attempts to allocate the output of the same transaction multiple times. The account-based model, on the other hand, prevents double spending by maintaining an account balance. Again, there is a defined order of transactions, so the account balance has a single, predefined state at any given time.

[0216] In addition to approving transactions, blockchain node 104 competes to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce," such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has a specific predefined number of leading zeros. This is just one particular type of proof-of-work puzzle, and other types are not excluded. A characteristic of hash functions is that they have an unpredictable output for a given input. Therefore, this search can only be performed by brute force, and thus a substantial amount of processing resources are consumed at each blockchain node 104 attempting to solve the puzzle.

[0217] The first blockchain node 104 to solve the puzzle publishes it to the network 106, providing the solution as proof that other blockchain nodes 104 in the network can easily check (given a hash solution, it is easy to check that it satisfies the condition for the hash output). The first blockchain node 104 propagates the block to the threshold consensus of other nodes that accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then become recorded as a new block 151 in blockchain 150 by each of the blockchain nodes 104. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the chain. The significant amount of effort required to create a proof of work solution, for example in the form of a hash, signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously accepted transaction, which is otherwise known as double-spending. Once created, block 151 is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106, and therefore cannot be modified. The block pointer 155 also imposes an order on block 151. Since transaction 152 is recorded in an ordered block at each blockchain node 104 within the network 106, this thus provides an immutable public ledger of transactions.

[0218] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet public at any given time, depending on when they began searching for the solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any possible "forks" that may occur, such as when two blockchain nodes 104 solve the puzzle within a very short time between them such that conflicting views of the blockchain propagate between the nodes 104. In short, whichever branch of the fork grows the longest will become the definitive blockchain 150. It should be noted that this should not affect users or agents of the network when the same transaction appears in both forks.

[0219] According to the Bitcoin blockchain (and most other blockchains), the node that successfully constructs a new block 104 is granted the ability to newly allocate an additional accepted amount of digital assets in a new special type of transaction that distributes an additional predetermined amount of digital assets (as opposed to agent-to-agent or user-to-user transactions that transfer an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but is sometimes called an "initiating transaction" or "generating transaction." This typically forms the first transaction of a new block 151n. Proof of work signals the node constructing the new block's intention to follow protocol rules that will allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, for example, 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which the transaction was published. This fee is usually referred to as the "transaction fee" and is explained below.

[0220] Due to the resources involved in transaction approval and publication, typically each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can also take the form of a user terminal or a group of network-connected user terminals.

[0221] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more roles according to the blockchain node protocol and to process transaction 152. It will be understood herein that any activity attributed to the blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or at lower layers such as the operating system layer or protocol layer, or at any combination thereof.

[0222] Also connected to the network 101 are the computer devices 102 of multiple parties 103, each acting as a consumer user. These users can interact with the blockchain network 106, but they do not participate in approving transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., retrieving copies of the blockchain from a blockchain node 104).

[0223] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on top of the blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 as they do not perform the necessary roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 by connecting to (i.e., communicating with) the blockchain nodes 106, thereby utilizing the blockchain 150. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. By purely illustrative means, the first party 103a is referred to herein as Alice, and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob herein may be replaced with “the first party” and “the second party,” respectively.

[0224] Each computer device 102 of Party 103 comprises one or more processors, each processing unit including, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further includes memory, i.e., computer-readable storage device in the form of a non-temporary computer-readable medium. This memory may include one or more memory units employing one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as an SSD, flash memory, or EEPROM, and / or an optical medium such as an optical disc drive. The memory on each computer device 102 of Party 103 stores software, each including at least one instance of a client application 105, which is arranged and configured to run on the processing unit. It will be understood that any activity attributed to a given Party 103 in this specification may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 includes at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0225] The client application 105 may first be provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example, downloaded from a server, or it may be provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0226] The client application 105 has at least a “wallet” function, which primarily has two functions. One of these is that each party 103 creates, authorizes (e.g., signs), and sends a transaction 152 to one or more Bitcoin nodes 104, which then propagates it throughout the network of blockchain nodes 104, thereby enabling it to be included in blockchain 150. The other is to report to each party the amount of digital assets they currently own. In an output-based system, this second function includes matching the amounts belonging to the party of interest, as defined in the outputs of various transactions 152 scattered throughout blockchain 150.

[0227] Note: While it may be described that various client functions are integrated into a given client application 105, this is not necessarily limited. Instead, any client function described herein may instead be implemented in two or more different applications, for example, interfaced via an API or one plugging into the other. More generally, client functions may also be implemented in the application layer, or in a lower layer such as the operating system, or any combination thereof. The client application 105 will now be described, but it should be understood that this is not an exhaustive description.

[0228] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, actually inspect the transactions of other parties within blockchain 150, as blockchain 150 is a public facility that in part provides trust to transactions through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward transaction 152 to propagate throughout the blockchain network 106. The transaction protocol and node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model together. The same transaction protocol is used for all 152 transactions within blockchain 150. The same node protocol is used by all 104 nodes within network 106.

[0229] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in blockchain 150, Alice formulates the new transaction (using the wallet function of Alice's client application 105) according to the relevant transaction protocol. Alice then sends transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 most frequently connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in transaction 152.

[0230] Alternatively, this condition can be defined simply by a built-in feature of the Node protocol, or by a combination of scripts and the Node protocol.

[0231] Subject to passing a test to determine if a newly received transaction 152j is valid (i.e., if it is "approved"), any blockchain node 104 receiving transaction 152j adds the new approved transaction 152 to the ordered set of transactions 154 maintained on that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j forward propagates the approved transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then, assuming transaction 152j is valid, this means it will immediately propagate throughout the network 106.

[0232] After being allowed to enter the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 begins a competition to solve a proof-of-work puzzle on the latest version of each pool 154 containing the new transaction 152 (other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but remember that whoever gets there first defines the set of transactions contained in the latest block 151. Ultimately, blockchain node 104 will solve the puzzle on the portion of the ordered pool 154 containing Alice's transaction 152j). After proof-of-work is performed on the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Each transaction 152 contains a pointer to a previous transaction, and therefore the order of transactions is also immutably recorded.

[0233] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views on which instance is "valid" before all blockchain nodes 104 agree that the published instance is the only valid instance, and the instance is published in the new block 151. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance is recorded in blockchain 150, that blockchain node 104 must accept this as well and discard (i.e., treat as invalid) the first instance it accepted (i.e., the one not published in block 151).

[0234] An alternative type of transaction protocol operated by several blockchain networks may be referred to as an “account-based” protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the transfer amount not by referencing the UTXO of a preceding transaction within a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored and constantly updated by the network’s nodes, separate from the blockchain. In such a system, transactions are ordered using the account’s running transaction aggregate (also called the “position”). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an arbitrary data field may also be signed in a transaction. This data field may refer to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0235] 4.2. UTXO Base Model Figure 2 illustrates an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it can be equally implemented on other exemplary blockchain networks.

[0236] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure including one or more inputs 202 and one or more outputs 203. Each output 203 may include an unused transaction output (UTXO) which can be used as the source for the input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value that specifies the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201 which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0237] For example, Alice 103a wants to create transaction 152j that transfers the amount of a digital asset of interest to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This takes the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction on blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could also refer to any preceding (i.e., previous) transaction that still has the unused output 203 locked in Alice.

[0238] The preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time she sends it to network 106. It may already be included in one of the blocks 151 at that point, or still awaiting in an ordered set 154, in which case it will immediately be included in the new block 151. Alternatively, Tx0 and Tx1 may be created together and sent to network 106, or Tx0 may even be sent after Tx1 if the node protocol allows buffering of “orphan” transactions. The terms “preceding” and “following” as used herein in the context of transaction sequences refer to the order of transactions in a sequence as defined by transaction pointers specified in the transactions (which transaction points to which other transactions, etc.). These may also be equivalently replaced with “preceding element” and “following element,” or “preceding element” and “descendant,” “parent” and “child,” or such. This does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (previous transaction or "parent") will not be confirmed until the parent transaction is confirmed, and unless it is confirmed. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or the node's behavior, it may be discarded to wait for its parent or buffered for a certain period of time.

[0239] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, which is here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining the conditions that must be met by the unlock script of the subsequent transaction's input 202 for the subsequent transaction to be approved and thus the UTXO to be successfully redeemed. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically defines unlock conditions that include the condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0240] A lock script (also known as scriptPubKey) is a snippet of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S) used in blockchain networks. The lock script specifies the information necessary to consume transaction output 203, such as the requirement for Alice's signature. The unlock script appears within the transaction output. The unlock script (also known as scriptSig) is a snippet of code written in a domain-specific language that provides the information necessary to satisfy the criteria of the lock script. For example, this could include Bob's signature. The unlock script appears within transaction input 202.

[0241] Therefore, in the example given, the UTXO0 of output 203 of Tx0 is redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid) by Alice's signature Sig P A Lock script that requires [Checksig P A It has [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a pointer to Tx1 (for example, using its transaction ID, TxID0, which in this embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 in order to distinguish it from any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script containing Alice's cryptographic signature, which is created by Alice applying a secret key from a key pair to a predefined portion of the data (sometimes called a "message" in cryptography). <Sig P A >Furthermore, the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, by the node protocol, or a combination thereof.

[0242] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where these conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function composed of a lock script (a stack-based language in this example). Equivalently, scripts can be executed one after the other via a common stack, rather than concatenating them. In any case, when executed together, the scripts contain Alice's public key P, such that the lock script is located in the output of Tx0. AThe unlock script within the input of Tx1 authenticates that it contains Alice's signature, which signs the expected portion of the data. For this authentication to be performed, the expected portion of the data itself ("the message") must also be included. In this embodiment, the signed data includes the entirety of Tx1 (and therefore does not require another element specifying the signed portion of the data in plaintext, as it already exists in its entirety).

[0243] The details of authentication using public-secret cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, another entity, such as node 104, given Alice's public key and the plaintext message, can authenticate that the message must have been signed by Alice. Signature typically involves hashing the message, signing the hash, and tagging the message with this signature, so that anyone holding the public key can authenticate the signature. Therefore, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., may in embodiments mean signing the hash of that data portion or part of a transaction.

[0244] If the unlock script for Tx1 satisfies one or more conditions specified in the lock script for Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 valid. This means that blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106, thereby propagating it throughout network 106. After Tx1 is accepted and placed in blockchain 150, this is defined as having used UTXO0 from Tx0. Note that Tx1 can only be valid if it consumes an unused transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transaction 152. In fact, a given blockchain node 104 may maintain a separate database marking which UTXO 203 was consumed in which transaction 152, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction within blockchain 150.

[0245] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0246] In the UTXO-based transaction model, it should be noted that a given UTXO must be consumed as a whole. A portion of the amount defined in a UTXO cannot be "left behind" as consumed while another portion is being consumed. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs in Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder in the second output of Tx1 to give herself change or to pay another party.

[0247] In practice, Alice would typically need to include a fee for the Bitcoin node 104 to successfully place her transaction 104 into block 151. If Alice does not include such a fee, Tx0 will be rejected by blockchain node 104 and, although technically valid, will not be propagated and cannot be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not wish to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to blockchain node 104 publishing the transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has only one input UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which won the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily ruled out that, alternatively or in addition, a transaction fee may be explicitly specified in one of the UTXO203 of transaction 152.

[0248] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 somewhere within blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the entirety of UTXOs in various transactions 152 throughout blockchain 150. There is no single number stored somewhere within blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function within the client application 105 to aggregate and match the values ​​of all the various UTXOs locked to each party that have not yet been consumed in another previous transaction. This can be done by querying a copy of blockchain 150, such as one stored in one of the Bitcoin nodes 104.

[0249] It should be noted that script code is often expressed in general terms (i.e., without using the exact language). For example, operation codes (opcodes) may be used to express specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates a non-consumable output of a transaction that can store data within the transaction, thereby immutably recording the data within blockchain 150. For example, the data may include documents that are desired to be stored on the blockchain.

[0250] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. A digital signature is a signature of specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the output to sign depend on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0251] A lock script is sometimes called a "scriptPubKey," referring to the fact that it typically contains the public keys of the parties whose transactions are locked. An unlock script is sometimes called a "scriptSig," referring to the fact that it typically provides the corresponding signature. However, more generally, in all applications of Blockchain 150, it is not essential that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0252] 4.3. Side Channels As shown in Figure 1, the client applications on Alice and Bob's computer devices 102a and 102b, respectively, may each have additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on chain 150 until one of the parties chooses to broadcast it to network 106. Sharing a transaction in this way is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition to the above, the side channel 107 may be used to exchange any other transaction relation data such as keys, negotiated amounts or terms, data content, etc.

[0253] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, side channel 107 as referred to anywhere in this specification may include any one or more links via one or more network technologies or communication media for exchanging data "off-chain," i.e., apart from the blockchain network 106. If multiple links are used, a bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob exchange some information or data or similar over side channel 107, this does not necessarily imply that all parts of this data must be transmitted over the exact same link or network of the same type.

[0254] Side channel 107 may include a secure channel that employs secure communication techniques known to enable secure and confidential off-chain communication between parties such as Alice and Bob. For example, the secure channel may be based on a shared secret shared between the parties communicating over the secure channel. Such a channel may be used for communication between verifier 103V and target party 103T, for example, enabling verifier 103V to submit a challenge to PUF302 / 500 held by the target party and receive a corresponding response.

[0255] 5. Blockchain-based PUF identity verification As mentioned in the previous section, the response data, which serves as a record of the response, can be stored on a public blockchain rather than employing a trusted third-party system 602. The response data is data determined at setup and can later be used by Validator 103V ("Bob") to test the assertion of the target's identity by the target party 103T ("Alice"). Again, it should be noted that Alice and Bob are merely arbitrary labels and do not necessarily have the same roles here as in the general overview of the blockchain system given in Section 4 (if Bob was consuming the output of Alice's transactions).

[0256] As previously explained, the response data for a given CR pair {Ci,Ri} (whether stored on the chain or elsewhere) is determined in setup phase 702 and may include any of the following, to be stored for future reference by verifier 103V: i) Explicit values ​​of the challenge Ci and / or response Ri (either plaintext or encrypted), or ii) An explicit value of response Ri linked to a master challenge Cm from which a specific challenge Ci for each response Ri can be derived, or iii) Proof of response Ri (e.g., hash or double hash) along with the explicit value of challenge Ci, or iv) A proof of response Ri linked to a master challenge Cm from which a specific challenge for each response Ri can be derived (e.g., hash or double hash), or v) The public key of the public-private key pair derived from response Ri.

[0257] As shown in Figure 9, in whatever form it takes, during setup phase 702, such response data 901 can be stored in the output 203 of transaction 152S recorded on blockchain 150. This may hereafter be referred to as a stored transaction. This may be recorded on the chain, for example, using the technique described in Section 4 above, where again, note that Alice is not necessarily the target party 103T and Bob is not necessarily the verifier 103V—in fact, the target party 103T, now referred to as Alice, may be the one who formulates and sends the stored transaction 152S to be recorded on the chain. As another example, a trusted third party may formulate a template for the stored transaction to the target party 103T, complete it by including the response data 901 generated during setup, and then transfer it to be recorded on the chain. The target party 103T may send the stored transaction 152S directly to one of the blockchain nodes 104 so that it propagates through the blockchain network 106, or it may send it indirectly through another party, such as a trusted third party. As yet another example, the target party 103T may send its response data 901 to a trusted third party, which then formulates it within a storage transaction 152 and sends it so that it is recorded on the chain.

[0258] Response data 901 may be stored within the unavailable output of stored transaction 152S. For example, this can be made unavailable when using the Script protocol with OP_RETURN, or OP_RETURN followed by OP_FALSE (in some blockchain protocols like BTC or BCH, the output is made unavailable if OP_RETURN is included, but in other protocols like BSV, both OP_FALSE and OP_RETURN are required to make the output unavailable). BTC (Bitcoin), BTC (Bitcoin Cash), and BSV (Bitcoin Satoshi Vision) are different exemplary implementations of the blockchain systems described earlier.

[0259] Alternatively, response data 901 can be embedded within the consumable output of storage transaction 152S. For example, this can be kept consumable by including OP_RETURN without OP_FALSE. Another example is embedding the data in a consumable lock script by including it immediately before the OP_DROP code. This would apply equally to BTC, BCH, and BSV.

[0260] In one embodiment, response data 901 for multiple sets of different CR pairs {Ci,Ri} of a given target party 103T can be stored. These can be stored in the same output 203 or different outputs 203 of storage transaction 152, or in combinations of some in the same output and some in different outputs. These can be stored in the same storage transaction 152S, or the response data 901 for different CR pairs can be stored in different storage transactions 152S, or in combinations of some in the same transaction and some in different transactions.

[0261] It should be noted that on-chain storage is not necessarily limited to the account-based model. In an alternative deployment, response data 901 may be stored in one or more smart contracts of one or more transactions in the account-based model.

[0262] In verification phase 704, when verifier 103V wishes to verify the identity of the target, verifier accesses blockchain 150 to retrieve response data 901 corresponding to a specific CR pair from memory transaction 152S. In embodiments, this gives verifier 103V a response Ri corresponding to a specific challenge Ci, or a proof (e.g., a hash or double hash) of that response Ri. Verifier 103V also submits a challenge Ci to target party 103V and, in response, receives a response R'i that is (claimed to be) generated by target party 103T (or its device) by inputting the received challenge Ci into PUF module 603. Verifier 103V then compares the returned response R'i with the version retrieved from memory transaction 152S on the chain, or the same transformation (e.g., H(R'i) or H) used for proof of the received response. 2 Apply (R'i)) and compare it to the proof retrieved from memory transaction 152S on the chain. In any case, if this comparison yields a match, the target is verified.

[0263] The verifier 103V may access blockchain 150 via one of the nodes 104 of blockchain network 106, or by obtaining response data from any external party, which may also provide a Merkle proof that its data (i.e., transaction) is included in the blockchain.

[0264] In embodiments where response data 901 is stored on a public medium such as blockchain 150, it may be desirable that the actual response value Ri itself is not publicly or unrestrictedly disclosed. Otherwise, any malicious party could see Ri on the chain and then impersonate the target party 103T when challenged with Ci. Therefore, instead, proof of Ri (e.g., H(Ri) or H 2 It may be preferable to store only (Ri)) as response data 901 held on the chain, or to store the explicit value of Ri, but in encrypted form. Alternatively, in some cases, the proof may also be stored on the chain in encrypted form.

[0265] If there are potentially multiple verifiers, storing the Ri or its proof in encrypted form allows the target party 103T or a trusted third party to control which verifier 103V can retrieve the stored data 901 corresponding to which of the CR pairs. This can be achieved by giving the decryption key for a particular response data 901 to only one given verifier, and the decryption key for another response data 901 to only another verifier. The distribution of decryption keys can also be managed by the target party 103T or a trusted third party. Each verifier or subset of verifiers is given its own subset of one or more decryption keys to access each subset of response data 901 (e.g., CR pairs). Preferably, the subsets are mutually exclusive. However, in other implementations, they may overlap (e.g., different groups within the same organization may have access to overlapping subsets of CR pairs).

[0266] As a variation of this, if the response data 901 (e.g., CR pairs) is stored in a third-party system 602 rather than on-chain, other means may be employed to ensure that each verifier only has access to its own subset of the CR pairs (or more generally, the response data), instead of distributing the decryption key (or in addition to that). For example, the trusted third-party system 602 may maintain a password-protected account for each verifier, which they must log in to in order to gain access to the challenge, and that account may only have access to its own CR pairs.

[0267] Such a scheme may be advantageous in terms of security. If the response Ri of a given CR pair is to be disclosed to one verifier 103V, it may be desirable that the same CR pair not be used by another verifier 103V. Otherwise, the first verifier 103V could use the now known response Ri to pretend to another verifier that they are the target party 103T. However, if all potential verifiers 103V who have access to the response data 901 are trustworthy, it is not essential to take measures to prevent this.

[0268] In a further modified form, the response data 901 stored on the chain may also take the form of the public key of the target party 103T, which is the public key of a public-private key pair generated at setup based on the corresponding response Ri (for example, using it as a seed). In this case, the verifier 103V accesses the public key from the stored transaction 152S and uses it to verify the message signed by the target party 103T with the corresponding private key. In some cases, the public key may also be stored on the chain in an encrypted form so that different public keys may be assigned for use by different verifiers 103V.

[0269] As shown in Figure 9, in embodiments employing an output (e.g., UTXO-based) model, this can be used to provide an efficient mechanism for managing CR pairs (or keys derived therefrom). Management here may include, for example, updating or revoking CR pairs or keys after they have already been consumed (used for verification).

[0270] To do this, a new modifier transaction 152M is recorded on blockchain 150. It has an input 202 that points to one of the outputs 203 of storage transaction 152S, which stores the response data 901 to be revoked or updated. This may be referred to as “consuming,” “redeeming,” or “allocating” its output (though note that this does not necessarily mean the transfer of monetary value). At the level of the Layer 2 protocol, as recognized by the Validator 103V, this is understood to mean that the response data 901 of the pointed storage transaction 152S or output 203 is no longer in use. If the modifier transaction 152M itself contains the response data 901' in one of its own outputs, this is considered to mean that the new response data 901' represents a replacement for the previous response data 901 (e.g., a new CR pair). If the Validator accesses blockchain 150 to find the response data to use in its validation operation, it will use the updated version 901' rather than the replaced version. On the other hand, if modifier transaction 152U does not contain replacement response data 901, the response data 901 is simply considered to be retracted in the storage transaction 152S or output 203 that it points to.

[0271] In some embodiments, the response data 901 is embedded in a consumable output of a storage transaction 152S and can be canceled or updated by consuming (i.e., allocating or redeeming) a particular output 203 in which the response data 901 (e.g., a CR pair) is stored. In some such embodiments, different response data 901 corresponding to different CR pairs can be stored in separate outputs 203 of the same storage transaction 203 and can be canceled or updated individually.

[0272] In other embodiments, the response data 901 is stored in the non-consumable output of the storage transaction 152S and can be canceled or updated by consuming (i.e., allocating or redeeming) a different consumable output of the storage transaction 152S. In some such embodiments, multiple storage data 901 corresponding to multiple different CR pairs (stored in the same or different non-consumable outputs) can be canceled or updated by consuming the same consumable output of the same transaction 152S.

[0273] As an exemplary use case, the record of response data 901 corresponding to a CR pair can be revoked or updated after it has been consumed, i.e., used for verification. This can apply whether response data 901 is an explicit record of Ri, a proof, or a public key derived from Ri. In any case, this can be advantageous for security reasons, as response data now released into the world can no longer be used again.

[0274] Modifier transaction 152M may be formulated and sent by target party 103T to be recorded on the chain. This may be sent directly to blockchain node 104 for propagation, or indirectly to node 104 via an intermediary party. Alternatively, a trusted third party may send a template transaction for the target party to complete (e.g., by adding signature and / or replacement response data 901'), and then forward it directly or indirectly to node 104 to be recorded on the chain. Another possibility is that a trusted third party may formulate modifier transaction 152M (based on some data sent from target part 103T, possibly including a template or, for example, replacement response data 901'), and then the trusted third party may send modifier transaction 152M to node 104 to be recorded on the chain. It should be noted that all these options may similarly apply to how memory transaction 152S is recorded on blockchain 150.

[0275] According to the various concepts described above, a system is therefore provided for i) linking identity (or other relevant information such as public keys) to a UTXO and using the consumption state of this UTXO as a proxy for the validity of identity credentials, and ii) establishing a set of transactions that perform efficient identity management operations such as setup, revocation, renewal, and verification. This process is efficient in that the number of communications is reduced, as all parties can refer to the blockchain to see when CRP was consumed or when an identity was revoked, rather than all parties having to communicate with each other at all times.

[0276] Such technologies could be used to extend the framework to link identity to PUF devices, as previously presented, by minimizing reliance on third-party KYC (Know Your Customer) providers for processing CRP data used in verification. This goal could be achieved by partially replacing the role, or rather some of its functions, of KYC providers with a public blockchain, thereby allowing users to instantiate their own identity credentials related to ePUF devices independently of any third party.

[0277] While the role of a trusted third party in an identity system cannot necessarily be completely avoided, the process of identity management can be improved, and the involvement in the process and the associated burdens can at least be reduced.

[0278] 5.1. Linking PUF Identity to UTXO Set A first aspect of how the use of blockchain can improve identity systems like those described in the previous section is by using the unused transaction output set (UTXO set) of a public blockchain to manage the CRP related to PUF identity.

[0279] This section discloses two different example mechanisms for mapping CRPs to members of a UTXO set and using their status as "consumed" or "unused" as an indicator of whether each particular CRP was consumed in the identity verification process. The first mechanism involves embedding CRP data into consumable UTXOs, while the second mechanism involves pairing them with consumable UTXOs. In either case, additional data related to the CRPs, or the identity of interest, may optionally be included in the system.

[0280] 5.1.1. Embedding into a Consumable UTXO: The first mechanism is to bind the CRP to a consumable UTXO that is a transaction output containing a script whose conditions may be satisfied by future inputs, and therefore can be consumed by future consuming transactions. There are many different options for implementing such embedding, but for our purposes this generally consists of at least the following lock script: [Checksig P] OP_RETURN<Rep(C, R)> [Checksig P] is a standard pay-to-public-key-hash (P2PKH) lock script, where Rep(C,R) is a representation of a specific challenge-response pair (C,R).

[0281] This lock script may simply be unlocked by providing a valid signature Sig P on the consumption transaction, and the signature is assumed to be valid for the public key P. Note that any data following the opcode OP_RETURN is not considered when approving the consumption transaction, and therefore this data is treated as arbitrary with respect to the blockchain validator and may be unformatted.

[0282] The data following the OP_RETURN code in the script above is the representation Rep(C,R) of the challenge-response pair (C,R). This representation can be done in various ways depending on the use case of interest. However, a wise example would be to encrypt the CRP using a key k known only to the prover Alice, who owns the PUF. In this case, we could have any of the following representations: Rep(C, R) = Encrypt(C, k), Rep(C, R) = Encrypt(R, k), Rep(C, R) = Encrypt(C || R, k).

[0283] These representations allow Alice to later retrieve or prove any of the challenges, responses, or CRPs that were contained in her UTXO, respectively.

[0284] Encombalancing with additional scripts: It is possible to extend the basic lock script shown earlier to include additional conditions for input scripts that will consume the output in the future. A clever example of such extra conditions would be the following script. [Checksig P][Hash Puzzle H 2 (R)]OP_RETURN<Rep(C,R)> However, [Hash Puzzle H 2 (R)]=OP_HASH160<H(R)> It is OP_EQUAL. Note that other hash function opcodes may be used. Therefore, this modified script requires the consumer to reveal the hash of the challenge R in addition to providing a valid signature of the public key P. The idea is that in some scenarios this could be used for a knowledge proof that the consumer then knows the information H(R) related to the challenge in question R.

[0285] Transaction Model: Assuming the exact structure of the transaction lock scripts to be used has been determined, then we can then choose how to structure the transaction containing these scripts as a way to remember, prove, and manage CRPs.

[0286] This specification discloses a one-to-one mapping of CRPs and associated lock scripts to UTXOs. In other words, every UTXO containing such scripts corresponds to just one CRP related to a particular PUF device.

[0287] Next, there are several options for how to organize these UTXOs into a transaction. The most likely options are as follows: 1. One CRP per transaction. 2. One CRP set per transaction. 3. One PUF per transaction.

[0288] The first option may be applicable in some cases to very infrequently used PUFs, such as rewriting a will, and has the advantage that multiple CRPs are not clearly linked to each other. This can be useful even when extreme privacy is required, as the consumption and exposure of one CRP can be revealed independently of others.

[0289] The transactions in Table 1 below represent an exemplary implementation of the first option. It can be seen that each transaction contains only a single input and output, and therefore each CRP is contained within a different transaction. Once its output is consumed, the transaction's relevance to the identity system effectively ends, except for auditing purposes.

[0290] [Table 1]

[0291] The second option involves multiple CRPs being mapped to their respective UTXOs within a single transaction, which may be more desirable for use cases such as bank cards where the expected frequency of CRP consumption is quite high. The transactions in Table 2 below illustrate how this can be achieved.

[0292] Note that the input signature, likely generated by Alice, may sign the entire set of outputs. This is a single public key P. AIt provides a one-to-many link from one UTXO to a number of CRPs, and therefore to a number of CRPs, while maintaining a one-to-one mapping from one UTXO to a different CRP itself. Also, to avoid reuse, it is assumed that each output / CRP has its own associated public key (all owned by Alice).

[0293] [Table 2]

[0294] The options described above can also be well integrated with embodiments that update CRP sets over time, with a new transaction being issued for each updated set generated. In addition, multiple different CRP sets for the same PUF can be generated and issued simultaneously via parallel, independent (i.e., unrelated on the chain) transactions. This can be useful for establishing identities with multiple different trusted third parties (e.g., different banks), where both identities are established independently but still anchored by the same PUF.

[0295] The third option is one in which a single transaction is used to represent a single PUF, and is simply a more restricted version of option 2, and is not renewable. This may be applicable when a PUF-containing device is given a specific "lifetime" and can only be used for a predetermined number of authentications before a new device is issued to the user.

[0296] 5.1.2. Pairing with a disposable UTXO An alternative to embedding CRPs within disposable UTXOs is simply pairing them with these outputs. In this case, the difference from existing research on digital certificates is that the transaction can be constructed and signed by Alice, as Alice may want to prove her identity independently of any third party.

[0297] [Table 3]

[0298] The diagram above shows an exemplary transaction containing 2n outputs related to n CRPs, where each consumable output is mapped to one of the CRPs, and the CRP representation itself is contained within the corresponding non-consumable output (e.g., OP_FALSE OP_RETURN). Note that the three possible forms of modification for organizing CRPs into transactions and UTXOs also apply here.

[0299] 5.1.3. Discussion Benefits to CRP Management: The concept of mapping CRP to UTXOs can significantly improve CRP management and handling for users of the identity protocol from the previous section. The benefit is that the storage and lookup of CRP can be partially offloaded to the blockchain network 106 and service providers that can facilitate trusted retrieval from there.

[0300] By mapping all "live" CRPs for a specific PUF to UTXOs, the CRP update process can be improved by querying the state of the UTXO set for precise information about the CRPs currently available for a given PUF within the identity system.

[0301] The following is an example of a simple process that utilizes blockchain and the UTXO-CRP mapping convention described above. 1. Alice acquires the PUF device, (C1,R1),(C2,R2),..., (C n ,R n List the sets of CRPs as shown above. 2. Alice has a transaction TxID as shown in Table 2. CRP-SetIt generates and broadcasts it to the blockchain network. 3. Alice spends time consuming multiple CRPs to authenticate her identity with a third party. 4. Alice would like to check if she has enough CRP to cover the activities scheduled for next week. 1. Alice queries blockchain node 104 or a service provider like SPV for TxID. CRP-Set Ask if the throat UTXO is currently unused. 2. Blockchain nodes or service providers can use unused transaction TxIDs. CRP-Set It responds with the number of outputs. 5. If the number returned is insufficient, Alice may perform an identity update process with a trusted third party, or simply enumerate more CRPs for independently established identities. Otherwise, Alice does nothing.

[0302] Embedding vs. Pairing: The choice of whether to embed the CRP within a consuming output or simply pair it with the output gives Alice the option to choose between two different advantages that distinguish these cases.

[0303] If CRP is embedded within the storable output, this incentivizes blockchain nodes 104 to maintain the blockchain network 106 in order to keep the data of these outputs readily available. This means that responses to Alice's queries may be faster, and more importantly, that blockchain nodes are more likely to be able to provide Alice with the raw data of these transaction outputs.

[0304] As previously explained, if the CRP representation Rep(C,R) is included to contain the raw (or obfuscated) data of the challenge, response, or both, this means that Alice can retrieve the relevant information from the blockchain network 106. This allows Alice to replace local storage and run a lighter system on blockchain 150, as embedding the data into a savable output increases the likelihood of high availability for whatever her data may be.

[0305] In contrast, if CRP is only paired with sustainable output, Alice can only determine how many CRPs are available to her, but may not necessarily retrieve the representation data itself from the Bitcoin node. This could mean that if Alice does not maintain a set of CRPs locally, she may have to consult an agent outside the blockchain node network 106.

[0306] Use of double hashing: In the example implementation above, double hash H 2 (Data) has been shown to be usable as an on-chain representation of some Data. The reason for using a double hash in this way is that it also allows a single hash to be exposed on-chain, and it works in principle like a knowledge proof, where the parties know H(Data) and are then connected to Data.

[0307] This is, for example, when Alice shares the actual value of R, H 2 (R) may be useful in a PUF-identity situation recorded on-chain by Alice as a consumption emcamrance that can be fulfilled by a third party providing H(R).

[0308] Multi-party signing: The transactions detailed in this section may also plausibly include more signatures from multiple different parties to help Alice prove her PUF identity. For example, it may be desirable for both Alice and a third-party identity provider to sign the input to a CRP transaction as a way to improve the verifier's trust in Alice's identity. This is particularly relevant if the co-signer is a Certificate Authority that can certify Alice's public key used to sign the blockchain transaction. Multiple parties may be included in the signing process using, for example, threshold signing or key splitting techniques (e.g., Shamir secret sharing) as an alternative to simply multiple signatures (i.e., "multi-sig").

[0309] 5.2. Efficient Identity Management Using Transactions An additional way blockchain can be used in conjunction with PUF-based identity systems, as previously presented, is as an efficient means of revoking identity keys or tokens secured by PUF devices.

[0310] Previous research on digital certificate management has shown that certificates can be issued and revoked on the chain, with corresponding certificate validation processes. Consider a scenario where Alice is willing to cooperate with a certificate authority when proving her PUF-based identity on-chain. The process by which Alice registers a certificate for her identity on-chain is as follows: 1. The Certificate Authority (CA) verifies Alice's identity. 2. The CA creates a certificate transaction. This transaction has the following inputs and outputs: a. Input: CA's UTXO containing the unlock script, which includes the CA's signature and public key. b. Output 1: P2PKH lock script. c. Output 2: OP_RETURN output containing Alice's public key. 3. After the transaction is broadcast and mined, the CA will send Alice the transaction ID.

[0311]

number

[0312] To provide.

[0313] This process concludes with Alice and the Certificate Authority (CA) working together to generate a transaction that includes one non-consumable output, signed by the CA and containing a certificate of Alice's public key, and a consumable output paired with a certificate that the CA can use to revoke the certificate.

[0314] Embodiments disclosed herein use a hybrid of the methods outlined above for digital certificates and methods for establishing PUF-based identities, such as one of the methods described previously. The element added here to the PUF identity system is that a common trusted third party (similar to a CA) can "revoke" the CRP, or the public key in question, by consuming the UTXO.

[0315] The case in which a trusted third party revokes the certificate on Alice's public key relates to the establishment of cryptographic identity, as explained earlier.

[0316] For CR pairs (CRPs) stored on a chain or certified, embodiments disclosed herein provide a scheme that allows a trusted third party to revoke a CRP after it has been used in an authentication process. An exemplary method is as follows: 1. Alice and a trusted third party implement the identity setup protocol (for example, as described above). 2. Next, Alice and a trusted third party wish to use blockchain to manage the CRP generated in step 1, or currently available after step 1. a. Alice maps the CRP to the transaction output using the CRP mapping transaction TxID. CRP-Set This is created. This is shown in Table 4 below. b. Both Alice and trusted third parties have TxIDs. CRP-Set I will sign it. 3. CRP Mapping Transaction TxID CRP-Set It will be broadcast and made public in a blockchain block.

[0317] [Table 4]

[0318] The mapping transactions created in this process are shown in Table 4 above. These are very similar to the CRP mapping transactions shown earlier in Table 2, but differ in that both a trusted third party and Alice sign the inputs, and each UTXO mapped to the CRP can be revoked by the trusted third party consuming it in a future transaction.

[0319] This is advantageous because it allows CRP revocation to be processed without direct communication, with TTP performing the revocation on behalf of the user, further reducing the burden on Alice in the system and making Alice's identity management even lighter.

[0320] 6. Event Log Figure 10 shows an example of device 1000 with an embedded PUF module 603. In an embodiment, this PUF module 603 may comprise the previously described ePUF500, which comprises a PUF302, a conversion function 502, and interface logic 404'. Alternatively, the ePUF500 may comprise only the PUF302 and interface logic 404' (without the conversion function 502). Device 1000 further comprises one or more outer layer components 1002. These may comprise one or more hardware and / or software components. The outer layer components 1002 may, for example, provide an external interface for communication between device 1000 and an external source. The external interface may, for example, provide a port for making a wired connection to the device, or a wireless transceiver for forming a wireless connection. In addition, or alternatively, the outer layer components 1002 may provide applications that run on the processor of device 1000, for example, to carry out the application purpose of the device. The outer layer component 1002 may also comprise one or more components implemented in fixed-function hardware.

[0321] For example, device 1000 may take the form of an event data recorder (EDR), sometimes also referred to as a black box recorder. This could be an EDR designed for use in vehicles such as automobiles or airplanes. In this case, the outer layer component 1002 may contain an EDR application running on the processor of device 1000. However, it should be understood that this is merely one example, and in other embodiments, device 1000 may instead take other forms, such as a general-purpose computer device or a dedicated PUF device for identity verification.

[0322] The PUF module 603 is embedded within (i.e., inside) the housing 1001 of the device 1000, i.e., completely enclosed by the housing 1001. The PUF module 603 is physically configured such that access is not granted to affect the behavior of the PUF module 603, except through input to the interface logic 404', without physically disassembling the device 1000. In some embodiments, the housing 1001 may be provided with a physical lock to prevent access to the PUF module 603 without a suitable key or combination. Alternatively, the housing may be permanently sealed.

[0323] The housing 1001 in which the PUF module 603 is embedded may also enclose one or more of the outer layer components 1002 within the same housing 1001 as the PUF module 603. In the case of external interfaces, such as ports for wired connections to external sources, the interfaces may be located at the physical interface between the housing 1001 and the outside. In the case of applications running on the device's processor, the processor in question may be enclosed by the housing 1001 but may be accessible via external interfaces, such as for accepting external input from external sources.

[0324] Alternatively or additionally, the housing 1001 in which the PUF module 603 is enclosed may include an inner casing within the device 1000 that internally isolates the PUF module 603 from the outer layer components. However, this is not essential, as other measures, which will be discussed shortly, may be taken to physically and / or logically isolate the PUF module 603 from the outer layer components 1002.

[0325] The interface logic 404' of the PUF module 603 includes a logging mechanism 1004, which will be discussed in more detail later. The interface logic 404' may optionally also include access control logic 406, as discussed earlier. In any case, the interface logic 404', including the logging mechanism 1004 and the optional access control logic 406, remains isolated from the outer layer components 1002 so that any malicious tampering with any of the outer layer components 1002 will not affect the internal functionality of the PUF module 603. The interface logic 404' is implemented in either firmware or fixed-function hardware circuitry (i.e., dedicated circuitry), or a combination of firmware and fixed-function hardware circuitry. For the purposes of this text, firmware means software (computer-readable code) that is either i) written to permanent memory (read-only memory (ROM)), ii) stored in memory that is physically protected from external access by being embedded within the housing 1001 without an external interface to the memory and without physically disassembling the device, or iii) stored in memory whose contents can only be updated through a restricted process. For example, in the latter case, the hardware of the interface logic 404' may be configured in hardware to grant access only to update the memory in which the firmware is stored if the operator can present one or more required credentials such as a password, PIN, cryptographic key, or biometric information.

[0326] To the extent that such restrictions are imposed, the memory on which any such firmware is stored may take any preferred form, comprising one or more memory units employing one or more storage media (e.g., magnetic media such as magnetic disks or tapes, or electronic media such as ROM, EPROM, EEPROM, flash memory, SRAM, DRAM, etc.). The processor on which any firmware is executed may comprise one or more processing units (e.g., general-purpose processors such as CPUs, or application-specific or accelerator processors such as GPUs, DSPs, or cryptographic processors). Another option is that the firmware may be implemented in a configurable or reconfigurable circuit such as a PGA or FPGA (in the case of an FPGA, having restricted access to reconfigure).

[0327] In embodiments where the conversion function 502 is employed (as in the case of ePUF500), it may also be implemented in hardware or firmware. The same implementation comments as those described above for the PUF interface logic 404' also apply to the conversion function 502.

[0328] If the outer layer component 1002 includes an application, the memory in which the application is stored can also take any preferred form, including one or more memory units employing one or more storage media (e.g., magnetic media such as magnetic disks or tapes, or electronic media such as ROM, EPROM, EEPROM, flash memory, SRAM, DRAM, etc.). The processor on which the application is executed can also take any preferred form, including one or more processing units (e.g., general-purpose processors such as CPUs, or application-specific or accelerator processors such as GPUs, DSPs, or cryptographic processors). Another option is that the application functionality of the outer layer 102 may be partially or entirely implemented in dedicated hardware circuitry, or in configurable or reconfigurable circuitry such as a PGA or FPGA.

[0329] In some embodiments, the application of the outer layer 1002 runs on a separate processor from the firmware of the PUF module 603. Software running on the outer layer processor may be updatable via an external interface, such as by downloading updates from the internet or installing updates via a wired connection. However, the firmware may not be updatable, or in some embodiments, may only be updatable if an operator can present the required credentials. Another option is for the firmware to run on the same processor as the application, but within a secure, privileged domain of the processor (while the application runs in a separate application domain). For example, the firmware of interface logic 404' may be implemented as part of a secure kernel, stored, for example, in ROM. In this case, the processor is configured to start by running the kernel (privileged domain) when booted, thereby delegating processor cycles to applications running in the application space (application domain), but the processor is configured in hardware so as not to autonomously prevent the application process from overwriting the kernel or returning execution to the kernel after a number of delegated cycles. Details of suitable secure processing techniques for implementing such a secure (privileged) domain are known to those skilled in the art.

[0330] Whatever means are implemented, during operation, the interface logic 404' receives input challenges from the outer layer 1002. For example, this may include receiving input challenges from an application, or via the external interface, or via both the external interface and the application. Thus, the outer layer 1002 provides at least some of the channels for receiving input challenges. The source of the input challenges may be an application running within the outer layer 1002, or an external source. In the latter case, the external source may be local, directly inputting the input challenges to the external interface of device 1000, or remote, sending the input challenges to the external interface of device 1000 via a network. The source of the input challenges may be a human user, or another device or system such as an external computer device.

[0331] The interface logic 404' causes the PUF module 603 to generate an output response in accordance with the PUF 302. When the PUF module 603 takes the form of an ePUF 500, as discussed previously, the input challenge is a quadratic challenge Ci, and the output response is a quadratic response Ri. In this case, the interface logic 404' inputs the quadratic challenge Ci into the conversion function 502, inputs the primary challenge Cw into the PUF 302, which in turn supplies the primary response Rw to the PUF 302, causing the PUF 302 to generate the quadratic response Ri. For further details, please refer again to the previous discussion on ePUF.

[0332] However, in an alternative embodiment, the PUF module 603 does not need to take the form of an ePUF500. For example, the PUF module 603 may simply comprise a PUF302 and interface logic 404'. In this case, the interface logic 404' simply inputs the input challenge directly into the PUF302 without the conversion function 502 and receives the output response returned from the PUF302 as a direct function of the input challenge.

[0333] In any case, the interface logic 404' is positioned and configured to return an output challenge to a destination that may include the same user, device, or system as the source, or to a different destination, or both. The destination may include an application within the outer layer 1002. Alternatively, or additionally, the destination may include an external destination to which the output response is sent via the outer interface of the outer layer 1002, or via the application and the external interface. In the case of an external destination, the destination may be local (receiving the response directly) or remote (receiving the response via an external network). Whether the destination is local or remote, the outer layer 1002 therefore provides at least a portion of the channel through which the output response is supplied to the destination. In the case of an external destination, the destination may include a human user, or another device or system (not shown), such as an external computer device.

[0334] The inclusion of the PUF module 603 within device 1000 enables verification of the identity of device 1000, the party owning the device, or the results produced by the device.

[0335] For example, consider a scenario in which, during a previous reliable setup phase 702, device 1000 registered its response R with a specific challenge C by either a verifying party 103V or a reliable third-party service 202 (see, for example, the previous discussion). Subsequently, during an investigation or litigation proceeding or such, it may be desirable to prove whether a candidate device, under consideration during the investigation or presented as part of the proceedings, is the same device 1000 that was previously registered in the reliable setup phase. To do this, a verifying party 103V (e.g., an investigator, attorney, or court official) can input the same challenge C used during setup into device 1000 and determine whether the resulting candidate result R' is the same as the result R originally registered in the setup phase.

[0336] In an alternative scenario, the previous response does not necessarily need to be registered as part of the setup phase. Instead, device 1000 may be configured to generate a result in the event of some event, and the response R of PUF module 603 from that time may be linked to or mapped to the result. The result may be, for example, the state of one of the outer layer components 1002 or a system being monitored by outer layer component 1002, or may represent this. For example, in an example where device 1000 is an EDR, the result may be a signal generated by the monitored system, such as an onboard computer in a car, airplane, or ship. In some such embodiments, the challenge C input to generate the response R may be one meaningful piece of data about the circumstances that generated the result. For example, the challenge may be a signal from an onboard sensor of a vehicle, such as a distance sensor on the front of a car. The corresponding result may be a command to apply the brakes, which is applied by the onboard computer being monitored by the EDR device 1000. The EDR application within outer layer 1002 is configured to generate a tag that links or maps the result to the response R, and to record the result and tag in a storage location of the EDR application. Tags can be generated in several possible ways, depending on the implementation. For example, a tag could be a cryptographic signature generated by using R as the cryptographic key to sign the result, or it could be a hash-based message authentication code (HMAC) based on R and the result. Digital signature techniques, HMACs, and details of such things are known in the art itself.

[0337] Subsequently, during investigation or litigation proceedings, it may be desirable to prove whether the recorded results were actually generated by a specific EDR1000. To do this, a candidate challenge C' is input into the PUF module 603 to generate a corresponding candidate response R'. If the recorded tag (e.g., signature or HMAC) is authenticated based on the now-generated R', this proves that the recorded results were generated by the EDR.

[0338] For example, consider an EDR from Alice's car involved in some incident, such as a car accident. The challenge C could be, for example, a reading from the car's front distance sensor. The result could be generated based on C. In this example, it could be a decision from the onboard computer to apply the brakes because the reading was too low (the object in front was too close). C is also input to the PUF module 603 (e.g., ePUF). The PUF module generates a response R based on C and PUF 302. R is not necessarily meaningful in itself. However, the result is mapped to R, for example, by generating a signature, by signing the result with R, or by calculating the HMAC (result R). More generally, either the challenge, the result, or both may depend on a measurement, situation, or other such state of the monitored system (whether it be the onboard computer of the car or another vehicle, or any other system that may be monitored by any kind of EDR). For example, the challenge may depend on the state, in any case where the result does not depend on the state value. One example of this is when the result calculated by the EDR is simply a timestamp or index (for example, for basic data recording purposes), meaning that it is not necessary to know the measured or state value, and the timestamp can be derived from something like a system clock or an increment counter.

[0339] In some embodiments, the EDR application within the outer layer 1002 records at least the signed result and the signature or HMAC. In some such embodiments, it may also record C, if C represents real-world data that caused the result. For example, the result could be that the onboard computer applied the brakes, and C could be a signal from the distance sensor at the front of the vehicle. Then, in a car accident investigation, or in litigation or something similar, Bob has the EDR 1000 and wants to demonstrate the recorded result that is now presented as evidence actually generated by Alice's EDR. To do this, Bob inputs a candidate challenge C' that elicited the result (for example, inputting a low distance readout) into the PUF module 603 via the outer layer 1002 and observes the response R'. If the recorded signature or HMAC is authenticated based on the now generated R', this proves that the recorded result was generated by Alice's EDR. Thus, the PUF module 603 allows checking that it was indeed the same EDR that was present at the time of the event, and that it elicited a particular result based on C or external circumstances. Even if C is context-independent and only the result depends, it is still possible to authenticate an HMAC using (C,R), where R is the key used to generate the tag, e.g., the HMAC key or something similar (regardless of whether C was derived from or depended on a condition). This applies not only to automotive EDRs, but more generally to any type of EDR for monitoring any type of system.

[0340] More generally, there is nothing specific that must be recorded within the outer layer 1002. The outer layer 1002 can optionally output results, responses, and tags, none of these, or all three. For example, a black box recorder does not necessarily need to emit anything when it is operating; it simply acts as a "write-only" system that captures challenges or measurements, etc., until they are investigated later.

[0341] Regardless of the implementation form, there is a potential problem that a challenge is input to the PUF module 603 via at least one of the outer layer components 1002 (e.g., the application and / or external interface), and the corresponding response is output via at least one of the outer layer components 1002, whatever stage it is output at. This is true both during later investigation / procedures and in any initial setup phase, or when the result is originally generated. As stated, the outer layer components form at least part of an insecure channel for receiving input challenges and outputting output responses. This is true regardless of whether the source and / or destination is internal or external to device 1000. Thus, this channel is susceptible to man-in-the-middle (MiM) denial-of-service (DoS) attacks, or perhaps even malicious behavior by the party under investigation (ALIS) to prevent investigation against itself. For example, someone could smuggle a scrambler into the EDR's external interface or download some malware that interferes with the EDR application. Either of these could tamper with the value of the input challenge before it is input to the PUF module 603, or tamper with the value of the output response after it has been output by the PUF 603. This could happen either at the time of the original event (e.g., when the EDR was in Alice's car) or at verification (during the investigation / procedure). If both the source of the input challenge and the destination of the output response are outside and remote of device 1000, there are two potential points of contact for the MiM attack: between the source and the party receiving the challenge, and between that party and device 1000.

[0342] While it may be impossible to completely stop such attacks, it is desirable to be able to detect when they occur.

[0343] To address this, according to this disclosure, the interface logic 404' of the PUF module 603 includes a logging mechanism 1004. This mechanism is configured to automatically log a record of C and / or response R to a logging medium 1006 when an input challenge C is input to the interface logic 404' of the PUF module 603 and a corresponding output response R is generated. That is, the input challenge C as it is input to the interface logic 404' and / or the output response R as it is output by the interface logic 404' are recorded in the log.

[0344] A record of C and / or R may include the explicit values ​​of C and / or R, either in explicit or encrypted form. Alternatively, a record of C and / or R may include a proof of C and / or R, which is a transformation of C and / or R, respectively, e.g., a hash or double hash of C and / or R, that does not reveal their values. In the case of a proof, this allows candidate challenges C' and / or responses R' to be checked against the proof by applying the same transformation to the candidate values. Optionally, the log may also include a tag that maps the resulting R to a result generated at that time (e.g., a signal to apply the brakes). For example, in an embodiment, the log may include the tag and R itself.

[0345] The PUF module 603 is implemented as a self-contained module embedded within device 1000, for example, as an EDR (black box). Its internal functions are isolated from the rest of the EDR's internal components and implemented in a more secure environment, such as hardware or firmware running from ROM, and / or in a secure domain. Therefore, a malicious party cannot tamper with what is happening within the PUF module 603 itself because it is mediated by control logic, but this does not prevent the supply of transformed information to the PUF module 603 caused by tampering with the outer layer 1002 or the information supplied to the outer layer 1002. The logging of CR pairs by the internal logic 1004 of the PUF module 603 provides a means to substantiate such an attack.

[0346] The logging medium 1006 may include internal memory embedded within the interface logic 404' or at least within the device 1000, as shown in Figure 10. Any suitable memory medium, such as electronic media like EPROM, EEPROM, flash memory, SRAM, DRAM, or magnetic media like magnetic disks or tapes, may be used. In such embodiments, the memory is arranged and configured to protect its contents from being altered by any entity other than the logging mechanism 1006. This can be done, for example, by using a writable-only, read-only (WORM) memory, or a tamper-proof memory designed to leave evidence of any tampering or to ensure its contents are only altered by an authorized party (for example, the memory may be configured in hardware to grant write access only to a party who can present recognized credentials such as a password, PIN, key, or biometric information). Alternatively or additionally, the memory of log 1006 may be physically protected from tempering by being physically embedded within a housing, such as in the outer housing 1001 of device 1000, or further, in the internal casing of the PUF module 603 within device 1000. In some cases, the housing may be fitted with a physical lock that requires a physical key or combination to open.

[0347] In yet another alternative or additional option, the log medium 1006 may include a public medium. This may include an immutable public medium such as a blockchain. However, even a modifiable public medium, such as publication on the web, provides some security because any attempt to modify the log is publicly visible. In such an embodiment, the logging mechanism 1004 is equipped with a secure interface to a network such as the internet or a mobile cellular network to enable uploading of the C and / or R records logged to the public log medium 1006.

[0348] In embodiments where the log medium 1006 is outside device 1000 or further outside interface logic 404', preferably, interface logic 404' is provided with a secure channel for transmitting the C and / or R records to medium 1006 to prevent (or at least enable detection if such a thing happens) the records between device 1000 and medium 1006. This can be simply implemented by arranging and configuring the logging mechanism 1004 to output the records being logged in a packet, along with a cryptographic signature and a key for the logging mechanism 1004 generated based on the records, based on any known cryptographic signature technique. If blockchain transaction 152 is used as a packet enclosing the logging data (e.g., placing the logged records at the output of the transaction and including the signature at the input), the blockchain network 106 provides additional protection against this type of attack, and if blockchain transaction 152 is altered in any way that alters the message signed by its input signature, the transaction becomes invalid and does not reach on-chain. Therefore, as long as the log data is signed by the input signature, all that is needed to ensure that the logging data was not tempered during publishing is to verify that it made it on-chain (for example, by providing a Merkle certificate).

[0349] In some embodiments, the logging medium 1006 may include both local internal memory and public medium. In some such embodiments, the logging mechanism 1004 may, however, further log CR pairs (or whatever is being logged) to local memory once per time period (e.g., hourly, daily, weekly, etc., depending on how often they are used and the size of the local memory) when generating an output response to periodically upload batches of the most recent CR pairs logged in the last time period to public medium (e.g., the blockchain). Optionally, the logging mechanism 1004 may clear the locally stored CR pairs each time it uploads a batch to public medium. This allows a verifying party 103V to detect potential malicious behavior in real time by examining the local log. This may be desirable because attacks can be detected as soon as they occur. However, periodically storing logs on public medium also saves local memory by not having to retain all CR pairs in the local log forever. It also helps protect against attacks on local memory, and furthermore, the logs remain available on public media even if the verifying party's connection to device 1000 is lost.

[0350] In further alternative or additional embodiments, logged records may be written to the blockchain in real time after each challenge-response operation performed by the PUF module 603. This may be done as an alternative to, or in addition to, local logging in internal memory. It may also be done as an alternative to, or in addition to, periodic logging of batches of records to the blockchain.

[0351] Whatever means are implemented, the contents of the log medium 1006 will be made available for later reading by the verifying party 103V during the verification phase, for example, during an investigation or legal proceeding.

[0352] There are at least two potential attacks that the logs could be used to detect. The first is tampering with C either within outer layer 1002 or between the source and the outer layer of device 1000.

[0353] One way to check this is for the verifying party 103V (Bob) to check the behavior of the logs during an investigation or procedure to check for malware within the outer layer 1002. If candidate challenge C' is immediately converted in a new log entry C'', verifying party 103V knows that the device is currently infected and unreliable, and therefore its evidence cannot be used.

[0354] Another check is for verifying party 103V (Bob) to verify that candidate challenge C' is equal to one of the input challenges C logged in the past event logs. If so, everything is fine, but if not, this could mean one of the following: the event did not occur, the source of the input challenge (e.g., a distance sensor in the car example) was broken, or the input challenge was tempered at the time of the event. Contextual information can be used to rule out the first two possibilities. For example, a witness might verify that the event did occur (e.g., a car accident), and a technical inspection might demonstrate that the source of the input challenge (e.g., a car distance sensor) is still functioning.

[0355] Another potential attack is the tampering of the output response either within the device's outer layer 1002 or between the outer layer 1002 and the destination. To detect this, later in the investigation / procedure, the verifying party 103V (Bob) will not only authenticate the tags (e.g., signature or HMAC) recorded in association with the result in question, but will also check that the logged response R from the time of the event matches the candidate response R' now generated. If they do not match, it means that some interference occurred, and the evidence must be ignored (it does not prove, in any case, whether the recorded result was generated by Alice's EDR or something similar). Similar checks may be performed in the case of general identity verification.

[0356] It should be noted again that records in C and / or R can be either clear values ​​or proofs, such as hashes of values. In the former case, simply checking for a match involves checking that the recorded value is equal to the candidate value. However, in the case of a proof, checking for a match involves first applying the same transformation (e.g., a hash) to the candidate value and then checking that the transformed candidate value matches the recorded proof.

[0357] 6.1 Local PUF System For example, in a local setup (see Section 3.2), the event log can identify a specific application and prevent types of man-in-the-middle attacks associated with the corresponding verification scenario. Consider a PUF module 603, ePUF500, configured to receive Challenge C, possibly perform some computation, and provide a response that may include the result of the computation and the response R.

[0358] A good example of this is a hashed message authentication code (HMAC) whose output is an HMAC (result R), where the response R is used as the symmetric HMAC key, and the message is the result of the computation performed.

[0359] However, in such circumstances, and if event verification involves providing verifier 103V with physical access to the PUF module 603, it may also be beneficial for the PUF module 603 to generate a log or record of its operation. The reason for this is that an attacker performing an MiM attack on a challenge that is not secure between the PUF module 603 (for example, on an IoT device) and the legitimate owner submitting the desired challenge C to the device may be able to replace it with an alternative challenge C', thereby causing the device to generate a response R' instead of R without the owner Alice realizing that this has happened, and possibly using this in a calculation.

[0360] The logging mechanism 1004 may be sufficient to mitigate such attacks in a manner that reveals the attack during verification. Since we may include processing elements for generating logs and on-device storage 1006 for recording logs, as shown in Figure 10, the logging may influence the design of the particular PUF module 603 itself.

[0361] In one possible implementation, a general-purpose processor within the design may perform the desired computations to produce results, as well as the logic necessary to generate logs. In this setup, all actions performed by the device can be recorded and used, along with a verification process, to corroborate why the device might behave unexpectedly.

[0362] In this “local verification” scenario, we note that we assume that at a future verification time, the verifier 103V will have full access to the PUF module 603 device and will examine its responses. This alternative setup, featuring a logging system, allows the verifier 103V to detect past man-in-the-middle attacks that the owner of the PUF module 603 could not have detected. It should also be noted that the verifier and owner may be the same party, for example, in a closed IoT system.

[0363] In the next section, we explore how this logging system can be enhanced in an embodiment by specifically introducing a public blockchain into the logging process.

[0364] 6.2 Blockchain-based event logging for PUF integrity Another aspect disclosed herein for using blockchain to enhance PUF-based identity systems is to provide a more robust mitigation of the man-in-the-middle attacks described above, and we have introduced the concept of a logging system built into the PUF device to record the actions performed by the device.

[0365] This additional log is intended to provide a means to prevent any party, Alice, Bob, TTP, or others from carrying out any form of man-in-the-middle attack by modifying the submitted Challenge C to form a modified Challenge C' (meaning that the response R' provided by PUF device 1000 does not actually correspond to the correct response R that is expected).

[0366] The log mitigates this problem by ensuring that any modifications made to challenges within transit (i.e., during communication) are detected. However, this relies on the assumption that the log itself has not been tampered with before it is referenced during the investigation reconstruction process outlined above.

[0367] To address this concern, the embodiment thus provides a more robust solution against this type of man-in-the-middle attack by a malicious entity that tampers with and alters the log details itself for the lifetime of the PUF device 1000.

[0368] To achieve this, data logged on the device is submitted to blockchain 150. Preferably, this should be done periodically and possibly on two different timescales, as shown in Figure 11.

[0369] In such embodiments, the log content may first be submitted at processing time (i), and each operation (or request) received by the PUF device triggers the device to submit a transaction to a blockchain containing a record of this operation or request. As shown in Figure 11, this may be done in the form of a resulting HMAC, which can be keyed, for example, using the PUF's own relevant response to the challenge in the request. Alternatively, the result may be encrypted and written to the blockchain in a similar manner.

[0370] Furthermore, the entire log may be periodically written to the blockchain for both (ii) the on-device storage may be purged (reducing the device's storage overhead), and (i) previous proof by the mechanism may be compared with the state of the log at a later point in time. Similarly, this logging may be performed by HMAC, encryption, or similar means, and we do not limit either (i) or (ii) to a specific recording method. The data may be recorded in one or more blockchain transactions in any preferred manner.

[0371] By mirroring the results logged in real time and based on periodic checkpoints, we can minimize the risk of a man-in-the-middle attack going undetected due to malicious tampering of the on-device logging system. Furthermore, by carefully selecting the periodicity of a second form of logging (ii), the system should be able to identify a specific time window in which such tampering may have occurred. This assumption obviously relies on the use of blockchain as a reliable timestamp server.

[0372] 7. Secure communication through channels that are not guaranteed to be secure. The above description included an embodiment in which the PUF device 603 could securely log records on blockchain 150. This idea can be extended to allow any sending entity (a party, or a device, whether it be a PUF device or otherwise) to securely communicate with a receiver via the blockchain, even if the sender is using an insecure channel between the sender and blockchain 150. In this context, insecure means vulnerable to interference and tampering with the message being sent.

[0373] Potential problems are illustrated in Figure 12. The following is described in relation to transmitting user Alice 103a and receiving user Bob 103b, assuming that transmitting user Alice 103a and receiving user Bob 103b are carrying out their respective methods using their respective computer devices 102a and 102b. However, more generally, the same teaching may apply to any transmitting and receiving entities, each of which may be a party to one or more users using user device 102, or alternatively, an autonomous device.

[0374] It is known that two entities communicate via blockchain 150 as a communication medium. As shown in Figure 12, sender Alice sends message M, which is to be recorded in the payload of a transaction on blockchain 150 by the corresponding blockchain network 106, and as a result, receiver Bob can read the message from blockchain 150. For example, message M may be included in the output of a transaction by using the OP_RETURN or OP_PUSHDATA opcode in the lock script. Alice can send message M by formulating the transaction herself and sending that transaction to blockchain network 106, or she can send message M to some intermediate entity that wraps the message in the transaction and forwards it to blockchain network 106.

[0375] In any case, sender Alice may have to send message M to blockchain network 106 via an unsecured channel 1100, for example, one that does not use encryption. This channel may be vulnerable to interference by a malicious party who could tamper with message M by converting it into another message M' or replacing it with another message M' before it reaches blockchain network 106. Even if channel 1100 is encrypted, this does not necessarily prevent a malicious party from tampering with the message (the malicious party cannot know what the original message means and cannot formulate a meaningful alternative message M', but this does not mean that the party cannot send a meaningless message M', for example, as part of a denial-of-service attack).

[0376] Figure 13 shows a configuration that solves this potential problem by providing a mechanism to allow Alice to detect when tampering has occurred and, in that case, to stop sending any further messages over channels that are not guaranteed to be secure.

[0377] Alice's first message to Bob is M i=1 The first transaction Tx(M i=1 We begin by formulating ). Message M i It can be included in the output of a transaction in an output-based (e.g., UTXO-based) model, for example, by including it in the output lock script along with OP_RETURN or OP_PUSHDATA. For example, it can be included in non-consumable output by using OP_RETURN and OP_FALSE. A transaction is directed to Bob by including Bob's address, which Bob can identify on-chain, or a flag F that Bob is monitoring on-chain. Alice also signs the transaction containing the message; that is, Alice generates a signature as a function of Alice's key and at least the portion of the transaction containing the message, and includes the signature within the transaction. Methods for signing a transaction containing a transaction payload are known in the art itself.

[0378] Once formed, Alice sends the first transaction to node 104 on blockchain network 106 so that it is recorded in block 151 on blockchain 150. Alice may send the transaction to node 104 directly or through one or more intermediaries. In any case, the route of the transaction between Alice's computer 102a and node 104 involves one or more unsecured channels 1100, as discussed earlier.

[0379] To detect possible tampering with the first message through this channel, Alice queries blockchain 150 to check whether the first transaction, which contains the first message, is recorded on-chain as expected. Alice can do this by directly querying node 104 on blockchain network 106, or by submitting a query to a trusted intermediary service. The query may return a copy of the message, a transaction identifier, or the transaction itself, which Alice or the trusted service can compare against the sent message, transaction ID, or transaction. Alternatively, the query may return proof of the message, transaction ID, or transaction, such as their Merkle certificates. Another possibility is that Alice could check her own signature. Whatever means are implemented, the query thus allows Alice to check whether the first message is recorded on-chain in the form in which she sent it. If not, this indicates that the first message has been tampered with.

[0380] The first message M1 is a series of messages M that Alice intends to send to Bob via blockchain 150 in the same format as described above. i This could be the first of the following. However, sending the second message M2 (or any subsequent message) is conditional on the above check that the message has not been tampered with between Alice and blockchain 150. Otherwise, Alice will not send the second message M2 or any subsequent message (at least until the cause of the security issue is resolved). In embodiments, the query and check, as well as the blocking of further messages, may be automated steps performed automatically by Alice's computer equipment 102a. Alice may also notify Bob of any detected tampering so that Bob knows to ignore the first message M1. In some embodiments, this notification step may also be automated.

[0381] If the check returns a negative result, meaning that the message is determined not to have been tampered with based on the query, Alice will send a second message M2, and possibly a further message M i=3,4… The first message M2 is sent within the second transaction Tx(M2) in the same format as the first message was sent within the first transaction, with any necessary changes. The second transaction Tx(M2) does not necessarily consume the first transaction Tx(M1), nor does it necessarily depend on the first transaction for consumption. Therefore, in an output-based (e.g., UTXO-based) transaction model, the second transaction does not necessarily have an input directed to the output of the first transaction (or the output of any transaction in the consumption graph between the first and second transactions). In other words, transactions are used to communicate messages within a payload, and checks go beyond, for example, Alice checking for her changes before sending a preceding consumption transaction that consumes the output of the first transaction.

[0382] On the other hand, the check may return a positive result, i.e., based on the query, it is determined that the message has been tampered with. In other words, if the response Alice receives in the failure route is "No, I have never seen this transaction" or "No, I do not have a Merkle certificate for this transaction", this suggests that Alice's transaction has been sabotaged and altered, and as a result it has been invalidated in the process and has not made it to the chain. In this case, Alice does not send a second message M2 (or at least not through the same channel). In an embodiment, this may be an automatic block in which software 105a running on Alice's computer equipment 102a sends the second message.

[0383] Therefore, a form of verification algorithm is provided to ensure the message integrity of a transmitted message. If someone or some device A wishes to transmit a message M to another party B, but is concerned that it may be tampered with and altered, this algorithm can be used to be certain that the message has not been tampered with. This method uses a blockchain as an anchor point for the message, which can be read by both the sender and the receiver, but it has the additional property that if A can read from the blockchain, A can be certain that the message has not changed since the moment it was signed. In summary, embodiments of the algorithm may operate as follows, or similarly: 1. Party A and Party B wish to transmit through an insecure channel. 2. Party A creates a message, packages it within a blockchain transaction, and signs the transaction. 3. Party A submits the transaction to the blockchain network. Party A can query the blockchain for proof that the message has not been modified. For example, Party A could request a Merkle proof for their transaction, which would serve as confirmation that Bob reads the correct message. It works even without trust on the miner (node) because it uses proof of work as proof. 4. Party A attempts to verify the Merkle proof for the transaction it submitted. a. If successful, party A continues to transmit subsequent messages without modification. b. Otherwise, Party A may interrupt / resubmit (perhaps to a different miner) and include a new message indicating that the first message was unsuccessful.

[0384] In other words, this provides a mechanism for party A to make a decision (step 4) regarding how to proceed in the communication channel, for example, based on the validity of the Merkle certificate.

[0385] In this embodiment, the same check for tampering may be applied to the second transaction, with modifications as necessary, as a condition for sending the third transaction.

[0386] In one embodiment, a series of messages M i=1,2,3,… This could include, for example, meaningfully linked content (such as a written document, video, or audio file) that is a different packet within the same overall communication.

[0387] In one embodiment, message M i Similar to itself, each transaction in a series of transactions also has its own flag F i This may include Bob's address. Bob can use this to identify messages addressed to him when he inspects blockchain 150. Alternatively or additionally, Bob's address may be included in each transaction.

[0388] Flag F i This can be used by Bob to identify which messages form part of a series and their positions within that series. In one embodiment, flag F i This can be a function of index value i, where index i indexes the position of each message in the sequence. The function used for this can be a default form known in advance by both Alice and Bob.

[0389] In some such embodiments, during the initial setup phase before communicating a series of messages, Alice and Bob may establish a first flag F1 in the series through a secure side channel 107. Alice and Bob may have the resources and ability to set up a temporary secure channel 107, but may not be able to continue using it later. For example, the secure channel 107 may be an encrypted channel requiring, for example, a Diffie-Hellman key exchange, but Alice and Bob may not be able to use this channel during later communications. This can be useful, for example, when either party will have limited access to storage or device capabilities when communicating messages. For example, Bob may want to "disconnect (off the grid)" and destroy all electronic devices, but still be able to go to an internet cafe and check the blockchain occasionally while using the flag. The advantage is very strong privacy. Another example is when either party needs to be offline at any given time. The blockchain helps by allowing communication to occur whether the recipient is online or not at the time the message is sent.

[0390] The setup phase may include Alice sending a first flag to Bob, or Bob sending a first flag to Alice, or Alice and Bob arranging a first flag according to each other's protocols. The protocols for establishing a shared secret are themselves known in the art. Each flag F i The function that associates index i also associates the first flag F1 or the preceding flag F in the sequence. i-1 It can be a function of . Therefore, the safe channel 107 only needs to be used once in the initial setup phase, and thereafter both Alice and Bob can use each consecutive flag F iBecause they know the form of the function that associates index i with the first flag or preceding flag, Alice and Bob can instead communicate securely via blockchain 150, and only Bob can determine which messages form part of a sequence and in what order they come in.

[0391] Whether or not flag F is used, when Bob identifies a message addressed to him on blockchain 150, Bob can also authenticate the signature using Alice's public key. However, it should be noted that signatures alone do not necessarily provide the desired level of security, and therefore the above mechanism of querying the chain before seeing a second message can be useful in addition to using signatures. If a message has been tampered with, in many cases it will invalidate the transaction and it will never make it onto the chain. So in such a case, assuming Bob knows that the transaction was made by Alice, it is enough for Bob to know that the message has not been modified "for him". Just looking at the signature and Alice's public key in the transaction (which is likely the input) is not enough to be certain that Alice made it, but if Bob verifies the signature himself, Bob can be certain. So this last step is merely an assertion that Bob knows that the origin of a message he believes to be addressed to him was Alice. However, a malicious party could replace Alice's transaction with another transaction validly signed with the malicious party's public key. Such transactions are verified by the blockchain network 106 and recorded on-chain. Bob can verify the signature based on the public key included in the transaction, but if Bob does not know that the public key is linked to Alice's actual identity, he still cannot know whether the message was tampered with. In other words, not being certain that it is Alice's public key means that Bob cannot be certain that the message was not tampered with.

[0392] 8. Conclusion Other variations or use cases of the disclosed technology will become apparent to those skilled in the art after the disclosure herein. The scope of this disclosure is not limited by the embodiments described and is limited only by the accompanying claims.

[0393] For example, some of the embodiments described above have been explained in relation to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104. However, it will be understood that Bitcoin Blockchain is a specific example of Blockchain 150, and the above description may be applied in general to any blockchain. That is, the present invention is by no means limited to Bitcoin Blockchain. More generally, any above references to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104 may be replaced by references to Blockchain Network 106, Blockchain 150, and Blockchain Node 104, respectively. Blockchains, Blockchain Networks, and / or Blockchain Nodes may share some or all of the described properties of Bitcoin Blockchain 150, Bitcoin Network 106, and Bitcoin Node 104 described above.

[0394] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions and not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing them (it should be recalled that these entities are not considered nodes in the preferred Bitcoin network 106).

[0395] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, a node may perform at least one or more of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150, but not all of them. For example, in those other blockchain networks, “node” may be used to refer to a network entity that is configured to create and publish blocks 151, but does not store and / or propagate those blocks 151 to other nodes.

[0396] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware using the same methods described above with reference to blockchain nodes 104.

[0397] It will be understood that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0398] Statement 1. A PUF module comprising a physically hard-to-replicate function (PUF) and an internal PUF interface logic configured to receive an input challenge and output an output response which is a deterministic function of the input challenge, wherein the deterministic function comprises the PUF module and one or more outer layer components that provide at least a portion of an unsecured channel for inputting an input challenge to the internal interface logic of the PUF module and receiving an output response which is output and returned by the internal interface logic, wherein at least one of the outer layer components is susceptible to tampering of the input challenge and / or output response by a malicious process, but the PUF module comprising the internal PUF interface logic is enclosed within the housing of the device, isolated from one or more outer layer components, and therefore protected from tampering by a malicious process, and the internal PUF interface logic comprises a logging mechanism configured to automatically log a record of the input challenge and / or output response to a logging medium.

[0399] Statement 2. The internal interface logic of the device described in Statement 1 is implemented, either partially or entirely, in the firmware running on the device's processor.

[0400] Statement 3. The firmware of the device described in Statement 2 is partially or entirely stored in read-only memory (ROM).

[0401] Statement 4. Firmware is implemented in part or all within a secure kernel for the devices described in Statement 1 or 2.

[0402] Statement 5. The internal interface logic is implemented in a fixed-function hardware circuit using one of the devices described in Statements 1 through 4.

[0403] Statement 6. The device described in any of Statements 1 to 5, wherein at least one outer layer component has an external interface for receiving input challenges from an external source and / or supplying output responses to an external destination, and at least one outer layer component is susceptible to a malicious process which includes interfering with and tampering with input challenges and / or output responses between the source and the external interface.

[0404] Statement 7. The source is local to the device, and the external interface is operable to receive input challenges without transmission over a network, as described in Statement 6.

[0405] Statement 8. The source is located remotely from the device, and the external interface of the device described in Statement 6 is operable to receive input challenges from the source over the network.

[0406] Statement 9. A device according to any one of statements 6 to 8, comprising a dedicated PUF device.

[0407] Statement 10. A device as described in any of Statements 1 through 8, in which at least one outer layer component comprises an application that runs on a processor within the device housing, the application is configured to generate an input challenge, and at least one outer layer component is susceptible to a malicious process that includes malware running on the same processor as the application to tamper with the input challenge.

[0408] Statement 11. The internal interface logic is configured to run on a separate processor from the application, as described in Statement 10.

[0409] Statement 12. The internal interface logic is configured to run on the same processor as the application, but within a secure processor privileged domain, while the application runs within the application domain, as described in Statement 10.

[0410] Statement 13. The device is equipped with an Event Data Recorder (EDR), and the application is an EDR application, as described in any of Statements 10 to 12.

[0411] Statement 14. The application is configured to generate results from a system configured to be monitored by an EDR, and the EDR is configured to record the results and tags mapping the output responses to the results, as described in Statement 13.

[0412] Statement 15. A tag is a device as described in Statement 14, which includes a cryptographic signature generated by signing the result in the output response, or a hash-based message authentication code (HMAC) generated as a function of the result and the output response.

[0413] Statement 16. An input challenge is a device described in Statement 14 or 15 that contains meaningful data used by an application, representing that the system state is being monitored.

[0414] Statement 17. The result depends on the data, as described in Statement 16.

[0415] Statement 18. An EDR is an EDR for a vehicle, and the systems that the EDR is configured to monitor include any of the devices described in any of Statements 13 through 17, including the systems of the vehicle.

[0416] Statement 19.1 or more outer layer components are implemented in the same housing as the PUF module, as described in any of Statements 1 through 18.

[0417] Statement 20. A PUF module includes an extended PUF module, the input challenge is a quadratic challenge, the output response is a quadratic response, and the internal PUF interface logic is configured to input a challenge into the PUF to generate a primary response and determine the quadratic response as a deterministic transformation of the primary response and the quadratic challenge, as described in any of Statements 1 through 19.

[0418] Statement 21. A deterministic transformation is a device as described in Statement 20, which includes a hash function.

[0419] Statement 22. The interface logic is configured to directly input an input challenge to the PUF and to directly receive an output response from the PUF as a function of the input response to the device described in any of Statements 1 through 19.

[0420] Statement 23. The log medium is the device described in any of statements 1 through 22, including the device's local memory.

[0421] Statement 24. The local memory is a tamper-proof memory, a one-time write memory, and / or a device embedded in interface logic, as described in Statement 23.

[0422] Statement 25. The log medium on which the PUF interface logic is configured to log records is any of the devices described in Statements 1 through 24, including publicly accessible media outside the device.

[0423] Statement 26. Publicly accessible media to which the PUF interface logic is configured to log records include the devices described in Statement 25, including blockchain.

[0424] Statement 27. The internal PUF interface logic of any of the devices described in any of Statements 1 through 26 is configured to perform logging of records in real time in response to inputs of individual input challenges.

[0425] Statement 28. The internal PUF interface logic of any of the devices described in Statements 1 through 27 is configured to periodically log any received input challenges and / or generated output responses during each instance of a periodic time window.

[0426] Statement 29. The device according to Statement 28, subject to at least Statements 23, 25, and 27, wherein the internal PUF interface logic is configured to log records to the local memory in real time in response to inputs of individual input challenges, and also to perform periodic logging to a publicly accessible medium.

[0427] Statement 30. The logging mechanism of the device described in Statement 29 is further configured to periodically clear logged challenges and / or responses from local memory once they have been logged to a publicly accessible medium.

[0428] Statement 31. The logging mechanism is configured to log recordings in real time to a publicly accessible medium in response to inputs of individual input challenges, as described in Statement 25 or any subsequent statement thereof.

[0429] Statement 32. The internal PUF interface logic of any of the devices described in Statements 1 through 31 is configured to log at least the input challenge record.

[0430] Statement 33. The internal PUF interface logic of any of the devices described in Statements 1 through 32 is configured to log at least the output response.

[0431] Statement 34. A logging mechanism configured to output records within a packet for its logging purposes, and the packet further includes a signature generated based on the cryptographic key of the logging mechanism applied to at least a portion of the packet containing the records, as described in any of the devices described in Statements 1 through 33.

[0432] Statement 35. A device as described in Statement 34, which is subject to at least Statement 26, where the packet contains a blockchain transaction, the record is included in the output of the blockchain transaction, and the signature is included in the input of the transaction.

[0433] Statement 36. A method of using any of the devices described in Statements 1 to 35, comprising the steps of: inputting a candidate challenge to the device via an outer layer unsecured channel in order to cause a PUF module to generate a candidate response and return the candidate response via an unsecured channel after a record of an input challenge and / or output response has been logged to a log medium; and checking for evidence of tampering by checking the candidate challenge against a record of the original input challenge logged to a log medium and / or checking the candidate response against a record of the original output response logged to a log medium.

[0434] Statement 37. The method according to Statement 36, wherein the checking step includes at least checking that the candidate challenge matches the record of the input challenge as recorded on the log medium.

[0435] Statement 38. The method according to Statement 36 or 37, wherein the internal PUF interface logic is further configured to log a record of candidate responses, and the checking step includes at least checking that the logged record of candidate responses matches the candidate response as it was input to the device.

[0436] Statement 39. The method according to any one of statements 35 to 38, wherein the checking step includes at least checking that the candidate response matches the record of the original output response as recorded on the log medium.

[0437] Statement 40. A method using a device of claim 14 or any device claim dependent thereon, the method comprising the step of verifying that the device is the device that produced the result by verifying a tag based on a candidate result, as described in any of statements 36 to 39.

[0438] Statement 41: A computer device comprising a memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code configured to be arranged and executed on the processing unit, and the code is configured to perform any of the methods described in statements 36 to 40 when it is on the processing unit.

[0439] Statement 42: A computer program that is embodied on a non-temporary computer-readable medium and is configured to perform any of the methods described in statements 36 to 40 when executed on one or more processors.

[0440] Statement 43. A computer implementation method comprising: sending a first messaging transaction to be recorded on a blockchain by a first entity, wherein the first messaging transaction includes a first message and respective information directing the first message to the second entity so that the second entity can identify the first message on the blockchain; submitting a query to check that the first message has been recorded on the blockchain without tampering; and sending a second messaging transaction to be recorded on a blockchain, provided that it is determined that the first message has been recorded on the blockchain without tampering in accordance with the query, wherein the second messaging transaction includes a second message and respective information directing the second message to the second entity so that the second entity can identify the first message on the blockchain.

[0441] Statement 44. The method according to Statement 43, wherein a first messaging transaction includes an input pointing to the output of a first funding transaction, and a second messaging transaction includes an input pointing to the output of a second funding transaction, and does not include an input pointing to any output of the first messaging transaction.

[0442] Statement 45. The method according to Statement 43 or 44, wherein the first and second messages are consecutive messages in a sequence of two or more messages, each having a related index within the sequence, each being sent in a messaging transaction by a first entity to be recorded on the blockchain, each messaging transaction containing information that enables the second entity to identify the message on the blockchain, each piece of information in each message containing i) a related index and ii) a flag which is a function of a first flag or leading flag in the sequence, the form of which is known to each of the first and second entities, and the method includes an initial setup phase in which the first and second entities agree on a flag for the first message, thereby enabling them to communicate consecutively across the blockchain using the sequence of messages based on the form of which, the first flag, and the index for each message.

[0443] Statement 46: A computer device comprising a memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code configured to be arranged and executed on the processing unit, and the code is configured on the processing unit to perform the method described in any one of statements 43 to 45.

[0444] Statement 47. A computer program that is embodied on a non-temporary computer-readable medium and is configured to perform any method described in statements 43 to 45 when executed on one or more processors. [Explanation of Symbols]

[0445] 100 Systems 101 Packet-switched network 102 Computer equipment 102a Computer equipment 102b Computer equipment 102T Computer Equipment 102V Computer Equipment 103a User 103b New user or entity 103S Submitted by 103T Target party 103V Verifier 104 Blockchain Nodes 105 Client Applications 106 Peer-to-peer (P2P) network 107 Side Channel 150 Blockchains 151 blocks 151n block 152 transactions 152i Transaction 152j transaction 152M New Modifier Transactions 152S Memory Transaction 152U Modifier Transaction 154. Ordered sets (or "pools") 155 Block pointers 201 Header 202 inputs 203 Output 301 Side Channel 302 PUF 402 Processors 404 Interface Logic 404' Interface Logic 406 Access Control Logic 500 Extended PUF (ePUF) 502 Conversion Functions 504 Conversion Logic 601 Response Datastore 602 Third-party computer equipment 603 PUF module 702 Setup Phase 704 Verification Phase 802 Identification Information 804 combinations 806 Identification Information 901 Response Data 901' Response Data 903 PUF module

Claims

1. It is a device, A PUF module comprising a physically hard-to-replicate function (PUF) and internal PUF interface logic configured to receive an input challenge and output an output response which is a deterministic function of the input challenge, wherein the deterministic function includes the PUF, One or more outer layer components that provide at least a portion of an unsecured channel for inputting the input challenge to the internal PUF interface logic of the PUF module and receiving the output response output and returned by the internal PUF interface logic, Equipped with, At least one of the one or more outer layer components is susceptible to tampering with the input challenge and / or output response by a malicious process, but the PUF module, including the internal PUF interface logic, is enclosed within the device housing, isolated from the one or more outer layer components, and protected from tampering by the malicious process. The device comprises an internal PUF interface logic that includes a logging mechanism configured to automatically log the input challenge and / or output response to a logging medium.

2. The device according to claim 1, wherein the internal PUF interface logic is partially or entirely implemented in firmware running on the device's processor.

3. The device according to claim 2, wherein the firmware is partially or entirely stored in read-only memory (ROM).

4. The device according to claim 1 or 2, wherein the firmware is partially or entirely implemented in a secure kernel.

5. The device according to any one of claims 1 to 4, wherein the internal PUF interface logic is implemented in a fixed-function hardware circuit.

6. The at least one outer layer component includes an external interface for receiving the input challenge from an external source of the device and / or supplying the output response to an external destination of the device. The device according to any one of claims 1 to 5, wherein the malicious process that affects at least one outer layer component includes interfering with and tampering with the input challenge and / or output response between the source and the external interface.

7. The aforementioned source is local to the device, The device according to claim 6, wherein the external interface is operable to receive the input challenge without transmission over a network.

8. The aforementioned source is located remotely from the device. The device according to claim 6, wherein the external interface is operable to receive the input challenge from the source via a network.

9. The device according to any one of claims 6 to 8, comprising a dedicated PUF device.

10. The at least one outer layer component comprises an application that runs on the processor within the housing of the device, The application is configured to generate the input challenge, The device according to any one of claims 1 to 8, wherein the malicious process in which at least one outer layer component is susceptible includes malware that runs on the same processor as the application to tamper with the input challenge.

11. The device according to claim 10, wherein the internal PUF interface logic is configured to run on a processor separate from the application.

12. The device according to claim 10, wherein the internal PUF interface logic is configured to run on the same processor as the application, but within a secure processor privileged domain, while the application runs within an application domain.

13. The aforementioned device includes an event data recorder (EDR), The device according to any one of claims 10 to 12, wherein the application comprises an EDR application.

14. The application is configured to generate results for the system that the EDR is configured to monitor, The device according to claim 13, wherein the EDR is configured to record the result and a tag that maps the output response to the result.

15. The device according to claim 14, wherein the tag includes a cryptographic signature generated by signing the result in the output response, or a hash-based message authentication code (HMAC) generated as a function of the result and the output response.

16. The device according to claim 14 or 15, wherein the input challenge includes meaningful data used by the application that indicates the state of the system is being monitored.

17. The device according to claim 16, wherein the results depend on the data.

18. The aforementioned EDR is an EDR for vehicles, The device according to any one of claims 14 to 17, wherein the system configured to be monitored by the EDR includes the system of the vehicle.

19. The device according to any one of claims 1 to 18, wherein the one or more outer layer components are mounted in the same housing as the PUF module.

20. The PUF module includes an extended PUF module, the input challenge is a quadratic challenge, and the output response is a quadratic response. The device according to any one of claims 1 to 19, wherein the internal PUF interface logic is configured to input a challenge into the PUF to generate a primary response and to determine the secondary response as a deterministic transformation of the primary response and the secondary challenge.

21. The device according to claim 20, wherein the deterministic transformation includes a hash function.

22. The device according to any one of claims 1 to 19, wherein the internal PUF interface logic is configured to directly input the input challenge to the PUF and to directly receive the output response from the PUF as a function of the input response.

23. The device according to any one of claims 1 to 22, wherein the log medium includes the local memory of the device.

24. The device according to claim 23, wherein the local memory is tamper-proof memory, a one-time write memory, and / or is embedded in the internal PUF interface logic.

25. The device according to any one of claims 1 to 24, wherein the log medium, which the internal PUF interface logic is configured to log records, includes a publicly accessible medium outside the device.

26. The device according to claim 25, wherein the publicly accessible medium, to which the internal PUF interface logic is configured to log the records, includes a blockchain.

27. The device according to any one of claims 1 to 26, wherein the internal PUF interface logic is configured to perform logging of the record in real time in response to the input of individual input challenges.

28. The device according to any one of claims 1 to 27, wherein the internal PUF interface logic is configured to periodically log any received input challenges and / or generated output responses during each instance of a periodic time window.

29. The device according to claim 28, dependent on any one of claims 23, 25, and 27, wherein the internal PUF interface logic is configured to log the record to local memory in real time in response to the input of individual input challenges and to perform periodic logging to a publicly accessible medium.

30. The device according to claim 29, wherein the logging mechanism is further configured to periodically clear the logged challenges and / or responses from the local memory once they have been logged to the publicly accessible medium.

31. The device according to claim 25, or any one of claims 26 to 30 dependent on claim 25, wherein the logging mechanism is configured to log the record in real time to a publicly accessible medium in response to the input of an individual input challenge.

32. The device according to any one of claims 1 to 31, wherein the internal PUF interface logic is configured to log at least the records of the input challenges.

33. The device according to any one of claims 1 to 32, wherein the internal PUF interface logic is configured to log at least the recording of the output response.

34. The logging mechanism is configured to output the record within a packet for logging purposes. The device according to any one of claims 1 to 33, wherein the packet further includes a signature generated based on the cryptographic key of the logging mechanism applied to at least a portion of the packet, which includes the record.

35. The aforementioned packet includes a blockchain transaction, The aforementioned record is included in the output of the blockchain transaction, The device according to claim 34, which is dependent on claim 26, wherein the signature is included in the input of the blockchain transaction.

36. A method of using the device described in any one of claims 1 to 35, After the recording of the input challenge and / or output response is logged to the log medium, the step of inputting a candidate challenge to the device via the unsecured channel of one or more outer layer components in order to cause the PUF module to generate a candidate response and return the candidate response via the unsecured channel, The steps include checking for evidence of tampering by checking the candidate challenge against the record of the original input challenge logged on the log medium, and / or checking the candidate response against the record of the original output response logged on the log medium. Methods that include...

37. The method according to claim 36, wherein the checking step includes at least checking that the candidate challenge matches the record of the input challenge recorded on the log medium.

38. The internal PUF interface logic is further configured to log the recording of the candidate responses. The method according to claim 36 or 37, wherein the checking step includes at least checking that the logged record of the candidate response matches the candidate response as it was input to the device.

39. The method according to any one of claims 36 to 38, wherein the checking step includes at least checking that the candidate response matches the recording of the original output response as recorded on the log medium.

40. The method is a method using the device of claim 14 or any device claim dependent thereon, and the method is The method according to any one of claims 36 to 39, further comprising the step of verifying that the device is the device that produced the result by verifying the tag based on the candidate result.

41. Memory including one or more memory units, Apparatus including one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured on the processing device to execute the method described in any one of claims 36 to 40.

42. A computer program that is embodied on a non-temporary computer-readable medium and, when executed on one or more processors, is configured to perform the method according to any one of claims 36 to 40.

43. A computer implementation method, wherein by a first entity, A step of sending a first messaging transaction to be recorded on a blockchain, wherein the first messaging transaction includes a first message and information directing the first message to the second entity so that the second entity can identify the first message on the blockchain. A step of submitting a query to check that the first message has been recorded on the blockchain without tampering, A step of sending a second messaging transaction to be recorded on the blockchain, on the condition that the first message is determined to be recorded on the blockchain without tampering according to the query, wherein the second messaging transaction includes a second message and information directing the second message to the second entity so that the second entity can identify the first message on the blockchain. Computer implementation methods, including those mentioned above.

44. The first messaging transaction includes an input that points to the output of the first funding transaction, The method according to claim 43, wherein the second messaging transaction includes an input pointing to the output of the second funding transaction, and does not include an input pointing to any output of the first messaging transaction.

45. The first message and the second message are consecutive messages in a sequence of two or more messages. Each has an associated index within the sequence, Each of these is transmitted in the respective messaging transaction by the first entity which is to be recorded on the blockchain, Each messaging transaction includes information that enables the second entity to identify the message on the blockchain, Each piece of information in each message includes i) an associated index and ii) a flag which is a function of a first flag or preceding flag in the sequence. The form of the function is known to each of the first entity and the second entity, The method according to claim 43 or 44, further comprising an initial setup phase in which the first entity and the second entity agree on the flags of the first message, thereby enabling them to communicate sequentially across the blockchain using the sequence of messages based on the form of the function, the first flags, and the associated index of each message.

46. Memory including one or more memory units, Apparatus including one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured on the processing device to execute the method described in any one of claims 43 to 45.

47. A computer program that is embodied on a non-temporary computer-readable medium and, when executed on one or more processors, is configured to perform the method according to any one of claims 43 to 45.

Images