Verification system and method

Abstract

To provide a computer-implemented method for granting payment by a targeter to a verifier.SOLUTION: The method includes, by a verifier: performing payment verification to verify a funding source of a target; and performing identity verification to verify an identity of the target. The identity verification comprises: accessing response data stored in a data store in association with the identity of the target, said data store being implemented at a third party computing facility of a trusted third party or on a peer-to-peer public medium, the response data comprising either: a) a stored instance of the response to the challenge; or b) an attestation comprising a transformation of the response. Payment is granted on condition that the outputs of both payment verification and identity verification are true.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present disclosure relates to a process for performing system-based verification of a challenge and a response, for example, from a physically unclonable function (PUF). [Background technology]

[0002] A physically unclonable function (PUF) is a technical term for a function that involves deterministic but unpredictable physical phenomena. PUFs are also called physical random functions. A PUF receives an input, called a "challenge," and generates a corresponding output, called a "response," depending on the challenge and the physical phenomenon used by the PUF. PUFs are sometimes classified as strong or weak. A strong PUF can generate responses for many different challenges and typically accepts any value of the challenge. A weak PUF can generate responses for only a single response or a few responses (typically, the challenge cannot take any value). In other words, a strong PUF has many challenge-response pairs (a large challenge-response space), while a weak PUF has a single challenge-response pair or a limited number of challenge-response pairs (a small or limited challenge-response space). By one definition, the number of responses of a weak PUF is linear with respect to the number of challenge bits, or more generally, does not grow faster than linearly with respect to other parameters.

[0003] A known example of a strong PUF is an arbitrary PUF. For example, an arbitrary PUF may have a laser, an optical sensor, and a solid optical medium with bubbles or other such defects set in the medium. The laser is shone through the optical medium at a controllable angle, generating a diffraction or scattering pattern (which is the effect of the bubbles or defects in the medium). The sensor is configured to sense this pattern. The challenge is the angle of the laser, and a 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 to turn on an SRAM (Static Random Access Memory). Due to slight manufacturing differences between one SRAM and another, the SRAM cells will power up into a unique pattern of 0 / 1 states, which forms a characteristic fingerprint of each individual SRAM. The PUF is configured to output this as a response upon power-up.

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

[0006] Due to the limited challenge-response space, the input / output (I / O) interface to a PUF tends to be restricted to only one party or a limited number of parties (e.g., only one or a limited number of trusted parties may be physically or legally authorized to access the PUF, or the PUF's interface may be password-protected). That is, only the party or parties in question may have access to the inputs to the PUF needed to submit a challenge and the outputs from which the responses are received. On the other hand, for a strong PUF, the I / O interface to the strong PUF may be made widely available to a large or unlimited number of parties, not all of whom are necessarily known or trusted. The reason is that the challenge-response space is large enough that it is not practically possible for an adversary to enumerate all of the challenge-response pairs, and thus, even if an adversary has free access to the PUF, it should not compromise its security by allowing enumeration and spying on the PUF, as is the case with weak PUFs.

[0007] In a different technical field, blockchain refers to a distributed data structure in which multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") maintain a replicated copy of the blockchain and make it publicly available. A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a previous transaction in the sequence, which may span one or more blocks and predates one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often generated through a process called "mining." Mining involves multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. A blockchain may be pruned at some nodes, and block publication can be achieved simply by publishing the block header.

[0008] Transactions in a blockchain may be used for one or more of the following purposes: transferring digital assets (i.e., some digital tokens), ordering a collection of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow additional user data or indexes to data to be stored in a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, allowing increasingly complex data to be incorporated. For example, this may be used to store electronic documents, audio, or video data within the blockchain.

[0009] Nodes in a blockchain network (often referred to as "miners") perform a distributed transaction registration and validation process, described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a block template. For that block template, the nodes attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network. Each node can then record a new block on the blockchain. To record a transaction on the blockchain, for example, a user (a blockchain client application) sends the transaction to one of the network's nodes for propagation. The nodes receiving the transaction compete to find a proof-of-work solution that will incorporate the validated 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 not propagated or included in a block. Once a transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) remains registered and indexed as an immutable public record at each node in the blockchain network.

[0010] Nodes that successfully solve the proof-of-work puzzle and produce the latest block are typically rewarded with a new transaction, called a "coinbase transaction," distributing a certain amount of digital assets, i.e., a certain number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, who act as agents of the network and have an incentive to report and block fraud. Widespread publication of information allows users to constantly audit node performance. Publication of simple block headers allows participants to ensure the ongoing integrity of the blockchain.

[0011] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of a digital asset derivable from the ongoing sequence of transactions. A spendable output is subsequently referred to as a UTXO (unspent transaction output). An output may further include a locking script that specifies the conditions for future redemption of that output. A locking 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 previous transaction and may further include an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as the first and second transactions (or "target" transactions). The first transaction includes at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking that output. The second, target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock 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 to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlock script meets all of the one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not already been redeemed by another previous valid transaction. A node that determines that the target transaction is invalid according to any of these conditions will not propagate the transaction (as a valid transaction) (although it may register an invalid transaction) or include it in a new block to be recorded in the blockchain.

[0013] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing the UTXO of a previous transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0014] According to one aspect disclosed herein, a computer-implemented method for authorizing a payment by a target party to a verifier is provided, the method including, by the verifier: performing a payment verification to verify the source of funds of the target party and outputting a result of true if the target passes the payment verification; and performing an identity verification to verify the identity of the target party. Identity verification includes: accessing response data stored in a data store associated with the identity of the target, the data store being implemented in a third-party computing facility of a trusted third party or on a peer-to-peer public medium, the response data including either a) a stored instance of a response to a challenge or b) an attestation including a transformation of the response; sending a request including the challenge to the target and receiving in response a further instance of the response; and performing a comparison and outputting a true result for a match, the comparison including either a) comparing the stored instance of the response with the further instance of the response or b) comparing the attestation to the same transformation applied to the further instance of the response. Payment is granted provided that both the payment verification and identity verification outputs are true. [Brief explanation of the drawings]

[0015] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] 1 shows a schematic diagram of a PUF challenge and response. [Figure 4]1 is a schematic block diagram of a system having a PUF. [Figure 5] 1A and 1B are schematic block diagrams of an extended PUF according to an embodiment disclosed herein in a non-extended mode of operation; [Figure 6] A schematic diagram of a system involving a trusted third party or public medium for distribution of challenge-response pairs. [Figure 7] 1 is a schematic flow chart of a verification process according to an embodiment disclosed herein. [Figure 8] 1A-C illustrate a schematic diagram of a method for generating a set of challenges from a master challenge according to an embodiment disclosed herein. [Figure 9] Schematic showing how response data is recorded on the chain. [Figure 10] Schematic representation of the commercial SPV process flow between Alice (customer) and Bob (seller). [Figure 11] 1A is a schematic block diagram of a traditional privacy model, and FIG. 1B is a schematic block diagram of a privacy model according to an embodiment disclosed herein. [Figure 12] 1 shows a schematic representation of the "Compliance" branch of the payment interaction (numbered) along with the SPV flow, according to an embodiment disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0016] The robustness of systems such as key generation systems and privacy-preserving identity systems for both humans and machines can be improved by the involvement of Physically Unclonable Functions (PUFs). These can be parties and / or autonomous machines interacting with each other or with public systems such as blockchains.

[0017] These functions are based on physical systems and are secured under the assumption of random, undeterminable, and unrepeatable variations in the manufacturing of physical devices, and can be used to strengthen the link established between a person's identity and their device, as well as to establish an unforgeable, unique identity for the device itself.

[0018] In the literature, PUFs are classified into weak and strong types, which are categorized according to their different properties. In one aspect, we provide a generalized extended PUF (ePUF) framework to describe practical PUF devices that combine the advantages of both these types of PUFs. That is, ePUFs can generate a wide range of challenge-response pairs for use in applications while remaining practical and cost-effective to implement.

[0019] More generally, various aspects relating to PUFs and the management of challenge-response pairs are disclosed herein. These different aspects can be used individually or in any combination. These include, for example: I. Expanded PUF to expand the challenge-response space of PUF; II. A set of blockchain-agnostic protocols for establishing the identity of humans and / or devices using ePUF devices; III. A framework for leveraging blockchain to improve these identity protocols; IV. Techniques for lightweight storage of challenge-response pairs; V. A series of novel applications of ePUF devices to diverse problems, such as implementing KYC for simplified payment verification (SPV) processes and for device-verifiable computations.

[0020] 1. Physically Unclonable Functions (PUFs) - Introduction The term physically unclonable function (PUF) refers to a class of physical systems and devices that act as general-purpose random functions. These PUFs are uniquely characterized by physical properties, often at the submicron scale, meaning that they can each be uniquely identified and verified by probing those properties with physical stimuli.

[0021] At a high level, a PUF can be thought of as a function that maps challenges to responses. These pairs are often called challenge-response pairs (CRPs). To describe such a map F, we can use the following notation: F: C→R ∀(C,R)∈Φ F where C and R represent the challenge and response, respectively, and Φ F is the set of all challenge-response pairs of the form (C,R) that can be generated by the PUF.

[0022] The unique physical properties of a PUF are typically the result of random process variations inherent in the manufacturing of physical devices such as silicon chips. Assumptions typically made about PUFs are: 1. It is difficult to completely determine the parameters of a physical system by any form of analysis; 2. The parameters of the physical system are unknown to any party, including the original manufacturer of the device used as a PUF. This assumption is often called manufacturer-resistance.

[0023] With these assumptions, a PUF can be used to generate an unpredictable yet deterministic response to an arbitrary challenge. This challenge-response process treats the PUF like a physical black box, as shown in Figure 3.

[0024] 3 shows a PUF 302 modeled as a physical black box. A submitter 103S submits a challenge C as input to the PUF 302, and in response, the PUF 302 generates a corresponding response R. The submitter submits the challenge from a device, such as the submitter's computing device (not shown), which may be the same or a different device than the device on which the PUF 302 itself is implemented.

[0025] The submitter 103S may be the party that generates challenge-response (CR) pairs as part of a setup phase (examples of which are provided below) to establish a set of expected responses linked to the identity of a target person or device, or the submitter 103S may be a verifier that submits challenges in a later verification phase to verify that the generated responses match the expected responses, thereby verifying the identity of the target device with the PUF 302 or the target person who owns the PUF.

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

[0027] FIG. 4 illustrates a system including an example of an interface to a PUF 302. The system includes a processor 402 and the PUF 302. The interface includes interface logic 404 stored in memory and configured to operate on the processor 402. The memory in which the interface logic 404 is stored may include one or more memory units using 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 include 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 cryptoprocessor). It is also not excluded that the interface logic 404 may instead be implemented, in part or in whole, by dedicated hardware circuitry or by configurable or reconfigurable circuitry such as a PGA or FPGA.

[0028] The submitter 103S uses a device (not shown) to submit a challenge C to the PUF 302 via the interface logic 404. The device used by the submitter 103S may be, for example, a computing device, either an external computing device or the same computing device on which the processor 402 is implemented. The PUF 302 then returns a corresponding response R to the submitter's 302 device via the interface logic 404. In some embodiments, discussed in more detail below, the interface logic 404 may include access control logic 406 that restricts access to the PUF 302 to only certain parties (e.g., 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, for example, by being located in a room or complex accessible only to authorized personnel or kept in a locked box or cabinet. However, in alternative systems, the interface logic 404 may be made available for any party to query the challenge.

[0029] The PUF's challenge-response process allows for the generation of pseudo-random data values ​​by deriving these challenges from selected responses. For example, a PUF can be used as a key generator to derive random, repeatable data for use in cryptography. Note that because the PUF 302 operates in a deterministic and repeatable manner, when given the same challenge on multiple separate occasions, the PUF will provide the same response.

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

[0031] 1.1. Classes of PUFs 1.1.1 Weak PUFs: Weak PUFs are characterized by having a small challenge-response space, and many only have a single challenge. Thus, the size of the CRP space is |Φ F |=1. In general, the challenge-response space of a weak PUF is considered to be on the order of O(n), where n is the number of components in the PUF that are subject to uncontrollable manufacturing variations.

[0032] In the case of weak PUFs, it is also typically assumed that access to the PUF's responses is constrained. This is because the number of CRPs served by a weak PUF is small, making it possible for an adversary to enumerate all such pairs in a reasonable amount of time and thus emulate or "spoof" the PUF's behavior. This constraint is sometimes referred to as a restricted challenge-response interface when discussing the behavior of weak PUFs.

[0033] These properties make weak PUFs most naturally suited for use as key generators in cryptographic applications. In this case, one (or a few) CRPs generated by the PUF may be used as a secret key for a cryptographic operation, such as for encrypting on-device non-volatile memory (NVM) or for use as an HMAC symmetric key. In such cases, for both the security of the cryptographic process being performed and the security of the PUF itself, the key derived from the PUF's response needs to be kept secret and known only to the device owner.

[0034] A prominent and widely implemented example of a weak PUF is the SRAM PUF, where the term "SRAM" refers to "static random access memory." The design of an SRAM PUF exploits variations in the "powered-on" state of an SRAM chip, each of which has a unique fingerprint due to the variations in whether the SRAM cells within the chip are in a "0" state or a "1" state when the chip is powered on.

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

[0036] One 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 gives the same response in a manner that is invariant across conditions and time. Details of such error correction techniques are known to those skilled in the art. In some cases, the error correction process may require that the PUF device be initially "registered" to provide a source of helper data that is later combined with responses generated on demand to facilitate error correction.

[0037] 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) available. This large space of CRPs means that it is considered practically impossible for an adversary to enumerate all challenge-response pairs in the domain of a strong PUF in polynomial time. This property means that strong PUFs may in general have unprotected challenge-response interfaces, since even if an adversary has free access to the PUF, they will not compromise security by being able to enumerate and spoof the PUF, as is the case with weak PUFs. This class of PUFs is characterized by Φ F It is also said to produce responses that are unpredictable even from the perspective of an adversary who knows a large subset of , which means that a strong PUF behaves like a cryptographic hash function with a large domain.

[0038] However, a strong PUF is constrained such that when presented with a challenge C, the PUF should only give a response R, without leaking any other information about the PUF's inner workings or behavior in the process. This constraint is intended to mitigate various analysis attacks that an adversary can use to attempt to characterize the physical system that underpins the PUF's behavior. These are often referred to in the literature as modeling attacks.

[0039] As with weak PUFs, some strong PUF constructions may rely on error correction techniques to ensure the accuracy of the responses generated by the device.

[0040] The primary existing use of strong PUFs is to facilitate system authentication and identification using inherent challenge-response mechanisms. These mechanisms rely on protocols that involve the generation of a CRP as a shared secret directly between two parties, and often require at least one party to generate a table of CRPs in advance (initial setup) to be used as the other's authentication token.

[0041] One of the earliest examples of strong PUF implementations was the optical PUF system. In this construction, the PUF contains an optical medium containing randomly distributed physical defects as a result of manufacturing variations, which scatter incident light. This PUF construction can be probed by a laser beam directed at the light-scattering medium. In this case, the direction and polarization of the incident beam form the challenge, and the observed scattering pattern is taken as the PUF response.

[0042] However, this strong PUF construction is complex to implement due to the fact that the measurement device is separate from the rest of the PUF device and is also difficult to directly integrate with semiconductor components. This, in addition to the costs associated with the device itself and the lack of portability of the device, reduces its usefulness for everyday applications.

[0043] Subsequently, an electrically integrated strong PUF known as an arbiter PUF (APUF) has been proposed that overcomes some of these issues. This construction utilizes signal multiplexing to exploit runtime delays in electrical components. Many other strong PUF constructions have been proposed in parallel, but many lack practical suitability for widespread use, and many have associated weaknesses in terms of security and potential attack vectors. For example, a highly problematic potential attack is the man-in-the-middle attack, where an attacker can intercept a challenge submitted in plaintext and spoof the provable computation.

[0044] 1.1.3. Controlled PUFs: A third class of PUFs, known as controlled PUFs (CPUFs), improves on existing strong PUF constructions but uses them as building blocks. These PUFs take strong PUFs and apply additional control logic that constrains access to the PUF. This distinguishes them from uncontrolled strong PUFs, which may have an unprotected challenge-response interface.

[0045] 4, the control logic 406 applied to the PUF, which is now part of a larger PUF device, may mediate access to the PUF 302 itself. This means that the control logic component 406 can constrain which challenges are presented to the PUF and control how subsequent responses are revealed to the user.

[0046] In a CPUF construction, the control logic component 406 should preferably be embedded within or encapsulated by a strong PUF component. According to one definition of a CPUF, a PUF is said to be controlled if it can only be accessed via an algorithm that is physically linked to the PUF in an inseparable manner (i.e., any attempt to circumvent the algorithm will result in the destruction of the PUF). This embedding should make probing of the control logic significantly more difficult.

[0047] This establishes a mutually beneficial relationship between the PUF component and the control logic component, with each mitigating certain types of attacks against the other. That is, 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. Meanwhile, the control logic naturally protects the PUF component from protocol-level attacks that attempt to extract CRPs or other information about the internal physics underlying the PUF itself.

[0048] The uses of CPUFs are largely the same as for strong PUFs, but can be achieved in a more robust manner. In particular, certified computations and proof of execution can be easily achieved using the protocols outlined above.

[0049] Early examples of CPUFs, which extended the design of strong arbiter PUFs (APUFs), required that the control logic be intertwined with the APUF itself in the manner already described, so that the control logic and the APUF mutually 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.

[0050] Another known example of a controlled PUF is the PUF-FSM construction, which has a strong PUF (actually an APUF) in association with a finite state machine (FSM) that acts as the control logic that constrains access to the challenge-response interface of the APUF component itself.

[0051] Discussion Practicality: It is recognized in the literature that it is extremely challenging to fabricate strong PUFs that are practical, lightweight, and can be integrated with standard complementary metal-oxide semiconductor (CMOS) components. In contrast, weak PUFs, such as SRAM PUFs, are inexpensive to manufacture and can be trivially combined with integrated circuit architectures.

[0052] 1.2.2 Attacks against PUFs: Several different attacks have been proposed and studied, and different attacks may target specific PUF constructions or classes. Some of the most widely known attack types are: MITM attacks – These attacks target uncontrolled strong PUFs, particularly when used for certified computation, allowing an adversary to intercept challenges made in plaintext in order to forge or spoof the PUF's response. Modeling attacks – These attacks demonstrate vulnerabilities to many strong PUF constructions, including APUF. Chosen challenge attacks – These attacks affect even strong PUFs and are part of the motivation for moving to CPUF architectures.

[0053] Additionally, various PUF designs have other issues, such as a lack of uniqueness in some cases, which can lead to exploits that undermine the security of the PUF system in question.

[0054] 1.2.3 Security Models: Security models for PUF construction tend to share some similarities, such as the assumption that the random process or manufacturing variations that underlie their CRPs are 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 between the security models for the three major PUF classes mentioned above. Weak PUFs - The security of a weak PUF relies on the assumption that its CRP is kept secret, otherwise the device can be enumerated and impersonated. This means that a weak PUF can be used to provide a source of entropy for cryptographic operations and secure the storage of that entropy, but the actual CRP response data itself is not publicly revealed in the process. Strong PUFs - The security of strong PUFs relies on the fact that their CRP space tends to be exponential with respect to the number of challenge bits, making enumeration of the entire space practically infeasible in a reasonable timeframe. This means that the CRP responses of a strong PUF can be revealed by a device, unlike those of a weak PUF. Controlled PUFs - The security of a controlled PUF is determined by a combination of the control logic, which protects against protocol-level attacks, and the PUF itself, which protects against physical attacks.

[0055] Two properties of strong PUFs that distinguish them from weak PUFs are: First, a strong PUF has a large set of CRPs, which means that a strong PUF can solve a large challenge space ΦF , a weak PUF typically means that only one (or a few) challenges are available. Furthermore, a strong PUF is considered unpredictable with respect to any and all known CRPs, i.e., knowing any number of CRPs provides no advantage in predicting the response to a new challenge.

[0056] Second, 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 constrain access to the challenge-response interface. This means that any party with physical access to the PUF can arbitrarily apply challenges and obtain responses without revealing any additional information about the PUF or its physical properties.

[0057] Controlled PUFs have a protected challenge-response interface, but also a large challenge-response space like strong PUFs.

[0058] 2. Extended PUF (ePUF) The following discloses systems and methods for expanding the challenge-response (CR) space of a PUF by generating multiple secondary CR pairs from a given CR pair of the base PUF 302, sometimes referred to herein as an “expanded PUF” or “ePUF.” This idea can be used, for example, to expand the challenge-response space of a weak PUF with only one or a limited number of inherent CR pairs without the complexity and impracticality of typical strong PUF mechanisms (e.g., optical PUFs require lasers, optical media, and sensors). However, in principle, the disclosed techniques can be used more generally to expand the number of CR pairs of any base PUF, whether weak, strong, controlled, etc., or to transform the CR pairs of any PUF for other purposes, such as obfuscation or reusability.

[0059] FIG. 5A illustrates an extended PUF (ePUF) 500 according to embodiments disclosed herein. The ePUF 500 includes a component-based PUF 302, which may be, for example, a conventional weak PUF. The ePUF 500 further includes a transformation function 502, for example, a hash function such as a cryptographic hash function (e.g., SHA256). The ePUF 500 also includes interface logic 404′, which is similar to the interface logic 404 discussed in connection with FIG. 4 but may have additional interface functionality. The interface logic 404′ and the transformation function 502 may be implemented, for example, in software, for example, embedded firmware, stored in memory and configured to run on a processor 402 (as shown in FIG. 4 but which performs the additional functionality of the interface 404′ and the transformation function 502). The memory in which the interface function 404' and the conversion logic 504 are stored may have one or more memory units using 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 they execute may have one or more processing units (e.g., general-purpose processors such as CPUs, or application-specific or accelerator processors such as GPUs, DSPs, cryptoprocessors, etc.). It is also not excluded that the interface logic 404' and / or the conversion function 502 may instead be implemented partly or wholly in dedicated hardware circuits, or in configurable or reconfigurable circuits such as PGAs or FPGAs.

[0060] The interface logic 404′ is operatively coupled to the transformation function 502 and, optionally, to the base PUF 302. The base PUF 302 is operatively coupled to the transformation function. The interface logic 404′ is configured to receive input from and provide output to a submitter's 103S device (not shown in FIG. 5A ). The submitter's device may be, for example, a computing device, and may be the same device in which the ePUF 500 is implemented or an external device. The submitter 103S may be the party that uses the ePUF 500 to perform setup and generate a set of challenges and expected responses that are linked to an identity for future reference, or it may be a verifier that later uses the PUF to verify whether the generated responses match previously established expected responses (or a challengee that generates responses to provide to the verifier). In another example application, the submitter 103S may use the ePUF 500 to generate responses for use as keys or as seeds for generating keys. For example, it can be used as a cryptographic key to encrypt or sign messages, e.g., to sign part of a blockchain transaction.

[0061] The base PUF 302 is operable to generate as an output a “primary” response Rw in response to receiving as an input a “primary” challenge Cw. A “primary” challenge-response (CR) pair here refers to the base or “native” (i.e., inherent) CR pair of the underlying component PUF 302. In some embodiments, the base PUF 302 may be capable of generating only a single base (i.e., primary) response Cw in response to a single challenge Cw, such as a weak PUF.

[0062] In operation, the interface logic 404′ receives challenge data (challenge input) from the submitter 103S device, including at least a “secondary” challenge Ci. A primary (base) challenge Cw is input to the base PUF 302 to generate a primary (base) response Rw. In an embodiment, the submitter 103S is requested to include the base challenge Cw in the challenge data input to the ePUF 500, and the interface logic 404′ routes this to the base PUF 302 to generate a primary response Rw. However, in other embodiments, it is not excluded that the primary challenge Cw be input to the base PUF 302 from an internal source, such as memory, a fuse latch, or dedicated circuitry. In any case, the transformation function 502 is configured to receive as input: a) the secondary challenge Ci received in the input challenge data from the submitter, and b) the primary response Rw generated by the base PUF 302. Transformation function 502 is a function configured to deterministically map these combinations to a unique respective "secondary" response Ri corresponding to that particular combination of Ci and Rw input to transformation function 502. Secondary challenge-response pairs are referred to herein as "secondary" in the sense that they are generated in part based on the primary response Rw and are layered on top of the primary (base) CR pair. They may also be referred to as "augmentation layer" or "supplemental" challenges and responses.

[0063] In an embodiment, transformation function 502 comprises a hash function, e.g., a cryptographic hash function such as a SHA or DSA hash function. There are at least two different ways in which a hash function can be used. First, transformation function 502 comprises a hash of a pre-image, where the pre-image comprises a combination (e.g., concatenation) of the received secondary challenge Ci and the generated primary response, i.e., Ri = H(Ci||Rw). Alternatively, more generally, the pre-image can include other elements and / or other forms of combination other than concatenation.

[0064] In a second, alternative approach, the transformation function 502 includes a hash of the preimage, which 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. Alternatively, and more generally, the preimage of H can include other elements as long as it includes at least Ci. Initialization by Rw means that the mapping of the preimage to the output, as defined by the hash function H, itself depends on Rw. 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 depended on Rw, and in this paragraph, only H depends on Rw.

[0065] More generally, in principle, any function can be used as long as it deterministically and uniquely maps combinations of Ci and Rw to respective values ​​of Ri for each possible Ci in the domain accepted by ePUF 500.

[0066] The secondary challenge Ci can take on any of many different possible values, and the conversion function 502 maps them to respective values ​​of the secondary response Ri based on the particular received value of the secondary challenge Ci and the value of the primary response Rw. Thus, the ePUF 502 can expand the CR space of a given primary (base) CR pair to multiple secondary CR pairs. In embodiments, Ci can take on any value within the range of values ​​supported by the variables used (e.g., for a 32-bit integer, it can take on any of 2^32 values).

[0067] In some embodiments, the ePUF 500 may be capable of operating in an alternative mode of operation, as shown in FIG. 5B. In this case, the interface logic 404' detects that the input challenge data includes only a primary challenge Cw. In response, it routes the received Cw value to the base PUF 302 and routes the resulting primary response Rw to the submitter 103S device. That is, in this embodiment, the ePUF 500 is also capable of operating in a "legacy" or "non-augmented" mode.

[0068] Optionally, depending on the application, the interface logic 404' may include access control logic 406 that restricts access to only a limited number of possible presenters 103S, such as by granting access only to parties that can present credentials (e.g., passwords, PINs, or biometric inputs) that it recognizes as being mapped to authorized parties. In this case, the ePUF 500 may be considered a form of a CPUF. Alternatively, the physical interface to the ePUF 500 may be legally or physically protected, such as by storing the device containing the ePUF 500 in a room or premises that only a limited set of parties are allowed to access, or by storing it in a locked box, cabinet, or room. In this case, the ePUF 500 may be considered a type of extended weak PUF.

[0069] As an alternative or in addition to such physical constraints on the interface to the PUF, access may be restricted by restricting access to the primary challenge, for example, target 103T ("Alice" below) may be the only party who knows Cw.

[0070] However, in another alternative, access to the interface logic 404′ may be unrestricted, for example, open to any party via the internet. In this case, the ePUF 500 can be considered a kind of strong PUF 502 created by extending the weak base PUF mechanism.

[0071] The configuration shown in Figure 5A provides a new hybrid class of PUF devices, referred to herein as extended PUFs (ePUFs), which can be used generally as a framework for many applications, as will be shown later.

[0072] An ePUF may be defined as a physical device or system having three cooperating modules, as shown in FIG. 5A: a base PUF 302, such as an intrinsically weak PUF; a transformation function 502, such as a cryptographic hash function; and an interface logic module 404'. As mentioned above, the ePUF 500 may be "augmented" with respect to the regular PUF 302 by introducing a transformation function 404', such as a cryptographic hash function. It is possible to define a unique challenge space Φ for the base weak PUF 302. F The size of |Φ F |~1 to |Φ F |≫1. The size is now limited by the choice of hash function, not the physical system of a weak PUF.

[0073] The idea of ​​creating a system that combines the large CRP space of a strong PUF with the practicality of a weak PUF has been pursued before. It is known to use multiple FPGA-based weak PUFs in combined operation to create a system with the characteristics of a strong PUF. The intention here is, in part, to "expand" the CRP space of the base weak PUF. However, existing constructions of this nature are limited in practice. In the case of the aforementioned FPGA design, the system must be built on an FPGA, which still requires a relatively low CRP space (~2 10 ) is subject to restrictions.

[0074] The ePUF design disclosed herein is designed to be extremely lightweight in that it only requires 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 remaining two modules 404', 502 could be implemented, for example, as a small algorithm in software (e.g., firmware) or a relatively simple hardware circuit, and should not result in significant overhead. Furthermore, the space of possible outputs of the ePUF 500 extends to the range of the selected hash or transformation function 502, which is significantly larger than the above. For example, if the SHA-256 hash function is selected, the space of possible outputs (and therefore CRPs) quickly becomes 2 256 -1, and does not require scaling hardware overhead beyond embedding the hash function module itself.

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

[0076] The control logic element 406 of the ePUF device may be generalized in this construction. The control logic 406 may be implemented simply as a physical security, similar to an SRAM PUF, for example, if appropriate for the application.

[0077] Alternatively, the control logic module 406 may be implemented as a software control module similar to that used in a CPUF, where it is actually embedded in the PUF device itself to provide the mutual security benefits of the encapsulation described above, although what particularly distinguishes ePUF designs from CPUF designs is that there is no strict requirement that the control logic be implemented in this way.

[0078] It is not necessarily assumed that an invasive attack on the control module 406 will necessarily alter the behavior of the weak PUF component 302 in the ePUF design. Instead, the implementation of this element may be chosen on a case-by-case basis.

[0079] 2.1. Challenge and Response for ePUFs The challenge-response pair (C, R) ∈ Φ corresponding to the ePUF F The set of 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 where (C w ,R w ) is a privileged CRP corresponding to the challenge and response that forms the basis of the weak PUF 302, and the map F w is defined by the unique physical properties of the weak PUF. w ,R w ) is sometimes referred to herein as the base pair or primary pair of the ePUF. The map F is in turn defined by the cryptographic hash function chosen for the ePUF. Figures 5A-B show the extraction of a response from the ePUF 500, and in Figure 5B the challenge is C w In (A in Figure 5), the challenge is C i Also includes.

[0080] In some embodiments of the extended PUF, as shown in FIG. 5A, all challenges C i , i∈{1,2,…,N} has a base challenge C W must be accompanied by a base response R w is all other responses Ri is incorporated into the process of generating

[0081] The process shown in Figure 5A for generating a generic CRP using an ePUF involves generating a base challenge-response pair (C w ,R w ) and then use this base secret pair to challenge any other i The algorithm used to generate the CRP from the ePUF is designed to ensure that it deterministically generates the base pair (C w ,R w ), which can be tailored to a particular application. A simple example of such an algorithm, denoted getResponse(), can be written as follows: getResponse(): Input: Challenge 1. Get a challenge from the user / client 2. Check challenge==C w ? i. If yes: 1. C w We probe the weak PUF module using R w get 2. Response (R) w Put it as ii. Otherwise: 1. Challenge to C w and C i Separation into components 2. C w We probe the weak PUF module using R w get 3. C i and R w to the hash function module 4. hash(C i ,R w ,H) is calculated. 5. Response←hash(Ci ,R w ,H) 3. Return a Response Output: Response

[0082] The function hash(C i ,R w ,H) is a generic function used to compute a hash digest using a cryptographic hash function H. The function hash() is simply H(C i ||R w ) or by computing the expensive computation H(C i ) Rw can also be implemented by (here the value R w is used as the initial vector for the hash function H). In any case, the output of hash() is C i and R w It depends on both.

[0083] 5A and 5B illustrate that ePUF 500 may include interface logic 404', which optionally includes control logic module 406. In an embodiment, there are two possible paths to take in generating a response, the path in FIG. 5B where the challenge is simply C w The route A in Figure 5 is used when the challenge is C w The new value C is accompanied by i This is deterministic.

[0084] The disclosed ePUF design can be used to provide any of the following advantages and / or others: · A large CRP space defined by the domain and range of the selected hash function. · Flexibility to separate the control logic from the PUF itself. · Weak PUF security primitives.

[0085] This means that a user can use an ePUF device in the same way as a CPUF device, but the controlled access to the PUF is limited to (I) the base CRP (C w ,R w ), and (II) restricting physical access to the PUF device to only intended users.

[0086] In this model, the base pair (C w ,R w ) acts like a master key, from which (C i ,R i ) can be derived, and C i may be submitted externally or by a third party.

[0087] 2.2. Uses of ePUF The potential applications (use cases) of ePUF devices can be broadly classified into at least two main categories. 1. Linking features to activities or computational actions; and 2. Act as a key generator for cryptographic operations.

[0088] Application (1) is the one most commonly implemented by existing strong PUFs, and (2) is the one most commonly implemented by existing weak PUFs. The fact that ePUF construction combines the properties of each means that ePUFs may be treated as being equally suitable for either application. For application (1), the advantage is that such applications may generally be implemented much more easily in practice using ePUFs than most strong or controlled PUFs.

[0089] 3. Feature Linkage System In this section, a general framework for linking human or machine identity to a PUF device is disclosed.

[0090] Embodiments may use an extended PUF (ePUF). The intent here is to formulate a PUF architecture that provides a robust, yet highly generalized and flexible identity system. Such a system can be adapted to many different use cases. The properties we aim to capture in this construction are: ·Large CRP space comparable to strong PUFs; Practicality comparable to weak PUFs; -More flexible control logic than CPUF.

[0091] The ePUF design can be used as a base model for PUFs used in a range of identity establishment protocols. Embodiments may allow end-user or machine independence in the process. Where existing schemes that can also be adapted to use ePUFs rely on a trusted third party having direct access to the PUF device during setup, the proposed ePUF-based system may allow the end user of a PUF device to establish an identity on their behalf and participate in further authentication, without requiring a third party to have local or direct access to the device during setup.

[0092] Some implementations can improve the robustness of these identity linkage protocols and further extend such protocols by introducing public blockchains. Two concepts that can be adopted here are (A) using blockchain as a tamper-proof CRP management system, and (B) using the blockchain network as a time-stamping service to mediate request-response messages used in identity linkage protocols and provide an efficient revocation system.

[0093] Figure 6 illustrates an exemplary system for identity linkage and verification, and Figure 7 illustrates a corresponding method, according to embodiments disclosed herein.

[0094] The system includes a PUF module 603, a target's 103T computing equipment 102T, and a response data store 601. The PUF module 603 may include an ePUF 500 as described above in connection with FIGS. 5A and 5B, or alternatively, may simply include a conventional PUF 302 or a PUF plus conventional interface logic 404 as described above in connection with FIGS. 3 and 4. The response data store 601 may be part of a third-party computing equipment 602 and managed by a trusted third party, or alternatively, may be a distributed peer-to-peer storage medium such as a blockchain. The third-party computing equipment 602 may include, for example, a server equipment having one or more server units located at one or more geographic sites (cloud storage technology itself is known in the art). The system may also include a verifier's 103V computing equipment 102V, or in some alternative cases, the verifier may directly interact with the PUF module 603, the target's 102T computing equipment, or the third-party computing equipment 602.

[0095] Reference herein to an action by a user or party 103, whether a verifier 103V, a target party 103T, or a third party, covers the possibility that the party is acting through the party's computer equipment 102. For brevity, this is not always explicitly stated, but is understood to be implicitly covered. This covers both A) the action being triggered by or under the control of manual user input into the computer equipment by the party, or B) the action being performed automatically by the computer equipment on behalf of the party (saying that a party performs an action does not necessarily mean that the party's human user manually causes the action to occur, but instead may mean that the party's equipment autonomously performs the action on the party's behalf). For the avoidance of doubt, please also note that a party may refer to a single individual or a group of people or an organization, for example, a company, a charity, a government agency, a local authority, or an academic institution.

[0096] The computer equipment 102T of the target 103T may be operatively connected to the response data store 601 (e.g., by connection to a third-party equipment 602). The computer equipment 102V of the verifier 103V may be operatively connected to the response data store 601 (e.g., by connection to a third-party equipment 602). The computer equipment 102T of the target 103T may be operatively connected to the computer equipment 102V of the verifier 103V. Any of these connections may be formed via one or more networks, for example, one or more wide area networks such as the Internet or a cellular phone network. In embodiments, any of these connections may be formed via respective secure channels, for example, established based on a shared secret shared between the two parties in question. In this document, whenever two parties are said to communicate in some way, such as by sending a challenge or receiving a response, it is understood to cover the possibility that these communications may be carried out via any suitable direct or network connection between the respective computer equipment (102V, 102T; 102T, 602; or 102V, 602). For brevity, this is not always explicitly stated, but is understood to be implicitly covered.

[0097] The target 103T is a party whose identity is verified based on the PUF module 603, or a party that owns or is otherwise responsible for or associated with a device that is verified based on the PUF module 603. The verifier 103V is a party that performs the verification. There may be multiple verifiers 103V (each of which may act through a respective computer equipment 102V), but for ease of illustration, only one is shown in FIG. 6. The PUF module 603 may be owned by the target 103T. It may be embedded in the target's computer equipment 103T, or connected thereto, for example, as a peripheral or via a local network, or a combination (e.g., the interface logic 404 / 404′ may be implemented on the computer equipment 103T, and the PUF 302 may be an external peripheral). Alternatively, the PUF module 603 may be owned by a trusted third party. It may be embedded in the third-party computing equipment 602, or connected to it, for example as a peripheral or via a local network, or a combination (e.g., the interface logic 404 / 404′ may be implemented on the third-party computing equipment 602 and the PUF 302 may be an external peripheral).

[0098] In general, any of the target 103T, the verifier 103V, or a third party can act as the submitter described above in connection with Figures 3, 4, and 5. Any of the target 103T, the verifier 103V, or a third party may act as the submitter, or as a set-up party that uses the PUF module 603 to establish a set of one or more CR pairs and link them to the identity of the target 103T for use in a later verification phase. Some specific exemplary scenarios are discussed in more detail below.

[0099] The response data store 601 stores the response data generated by the PUF module 603 during the setup phase. The data store 601 stores this response data in association with evidence of the target's identity, which can be the target 103T or the target's 103T device. The verifier 103V has access to the response data store 601 and can use it later, during the verification phase, to verify the target's identity. 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 in 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 owns or controls the PUF module 603 and can therefore be assumed to be the same party whose identity was captured during the setup phase.

[0100] In an alternative variant, the response data store 601 may store one or more public keys of one or more respective public-private key pairs generated based on the response(s) generated in the setup phase, e.g., using the responses as seeds. When the target later uses one of the private keys to sign a message (e.g., a document or a blockchain transaction), the verifier can verify the signature using the corresponding public key from the response data store 601. Note that in such variants, the term "response data" is used in a broader sense to cover data derived from a response Ri, rather than necessarily an explicit value or trail of the response Ri.

[0101] The response data store 601 may be publicly accessible, or access may be restricted to only 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, may be implemented on the computer equipment 102T of the target 103T or the computer equipment 102V of the verifier 103V.

[0102] Referring to FIG. 7 , the method includes two phases: a setup phase 702 and a verification phase 704. In the setup phase, in step 710, either the target 103T or a third party, acting as the setup 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 an ePUF 500 is used. If the target 103T owns the PUF module 603 and is performing the setup, the challenges Ci can be generated by the target 103T or received from the third-party system 602 or the verifier 103V. If a third party owns the PUF module 603 and is performing the setup, the challenges can be generated by the third-party system 602 or received from the target 103T or the verifier 103V. In either case, in response, the PUF module 603 generates a set of corresponding responses Ri based on the PUF 302 / 500. These are the secondary responses in the case of the ePUF 500. In this way, the method generates a set of CR pairs {Ci, Ri}.

[0103] In embodiments, access to the PUF module 903 is restricted so that only the target 103T (and the setup party, if a different party) can gain 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 a password, PIN, or biometric data. And / or, access to the physical interface to the PUF module 603 can be physically protected, such as by storing the PUF module in a locked container, cabinet, or room; or legally protected, such as by storing the PUF module 603 in a room or complex that only certain personnel are allowed to access. As another alternative or additional restriction, in the case of the ePUF 501, knowledge of the primary challenge Cw can be restricted so that only the target 103T (and in embodiments, a trusted third party acting as another setup party) knows Cw.

[0104] In step 720, the method includes storing the response data in the response data store 601. In some embodiments, the stored response data includes records of the generated CR pairs {Ci, Ri}. The record for each CR pair includes a record for each response Ri stored in a manner that indicates the corresponding challenge Ci of that pair. In some embodiments, the stored record for each response Ri includes an explicit value for that response, i.e., the actual value of Ri, which is explicitly disclosed to the verifier 103V who can read the record. The value may be stored in plaintext, or encrypted if the verifier has the decryption key to decrypt the value, but the stored value is still referred to as an explicit value for purposes herein in the sense that it is explicitly disclosed to the verifier 103V. Alternatively, the response record may include a "trail" of the response Ri, including a deterministic transformation of Ri. Examples include a hash H(Ri) or a double hash H 2This allows the verifier to check whether the value of response R'i is the same as the value recorded in the store, given the same transformation applied to R'i (e.g., H(R'i) or H 2 (R'i)) matches the trail. This has the advantage that the actual value of the response Ri is not disclosed. This variant of the method may therefore be particularly useful if the store 601 is a public medium such as a blockchain, although encryption would be another possibility.

[0105] If the response data is stored in encrypted form, each response data (e.g., each CR pair) may be encrypted separately and require a different decryption key to decrypt, or alternatively, a subset or the entire set of response data (e.g., all CR pairs for a given target 103T) may be encrypted together, so that they can all be decrypted together as a group using the same key.

[0106] The response data, e.g., a CR pair, is stored in the response data store 601 in association with evidence of the target's identity. For example, the target 103T may be required to generate one or more pieces of identifying information, such as a passport, as part of 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 clear text 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 parties and the party managing the response data store 601, e.g., a trusted third party, properly verified the target's identity during setup).

[0107] During the verification phase 704, in step 730, the verifier 103V accesses the response data store to determine response data to use in the verification operation. In some embodiments, there are multiple potential verifiers 103V, each assigned a different respective subset of one or more of the CR pairs. That is, the response data store 601 only discloses to a given verifier 103V the expected response(s) Ri for the CR pair(s) assigned to that party. For example, this scheme may be managed by a trusted third-party system 602. Such a scheme advantageously keeps CR pairs separate and prevents one verifier 103V from pretending to be the target to another verifier. However, this is not essential if all verifiers 103V given access to the store 601 are trusted.

[0108] In embodiments, the verifier 103V does not initially know the challenge to use and determines this by accessing it along with the corresponding response data (e.g., response or trail) from the data store 601. Alternatively, the verifier 103V knows in advance the challenge it intends to use and uses this to look up what response data is mapped to it in the data store 601.

[0109] In scenarios where the verifier 103V (or indeed any party) accesses data from the blockchain, such as to determine response data and / or challenges, accessing the blockchain may be performed 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, the verifier 103V may not be directly connected to the blockchain network 106, but may access data from another service provider that may simply provide data related to the response, and possibly even a Merkle proof.

[0110] In step 740, the verifier 103V submits a challenge Ci to the target 103T, which owns or controls the PUF module 603. This challenge corresponds to one of the records accessed by the verifier 103V from the response data store 601 in step 730. Note that in scenarios where a trusted third party owned the PUF module 603 at setup time, the PUF module 603 may be physically passed from the trusted third party to the target 103T between the setup phase 702 and the verification phase 704.

[0111] In response to the submitted challenge Ci, the PUF module 603 generates a corresponding response Ri, which the target 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.

[0112] As mentioned above, the party performing the setup step 702 may be the target 103T or a trusted third party that stores the response data (e.g., CR pairs). In a further variation, these steps may be performed by another coordinating party, such as a trusted oracle (a third party other than the party operating the third-party computing facility 602 with the data store 610 in some embodiments). In such an embodiment, the data store 601 may 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 another variation, a separation may be provided between the party performing the input to the PUF module 603 and the party receiving the output.

[0113] Also, there are at least two possibilities for how the response Ri is recorded in the response data store 601. The first is to simply explicitly store the actual value of Ri itself. In this case, step 750 simply involves comparing the stored value (established during setup 702) with the value R'i (the claimed value of the response Ri) just received in response to the submitted challenge Ci (in verification phase 704). If they match, the method branches to step 760, where the identity of the target 103T is declared verified. Otherwise, the method branches to step 770, where the identity of the target 103T is declared not verified.

[0114] A second possibility is that only the trail of Ri is stored in the response data store 601 (e.g., hashed or double hashed). In this case, the verifier 103V applies the same transformation used to generate the trail to the response R'i received from the target 103T in the verification phase 704. If this matches the stored trail, the method branches to step 760, where the identity of the target 103T is declared verified. Otherwise, the method branches to step 770, where the identity of the target 103T is declared not verified.

[0115] In the response data store 601, there are at least two possibilities for how a corresponding challenge Ci can be indicated as being associated with each recorded response Ri. The first is to simply store explicit values ​​for each CR pair {Ci, Ri}, i.e., by storing the actual values ​​of Ri and Ci (in the clear or encrypted). Alternatively, in accordance with embodiments disclosed herein, a second, more lightweight way is to store a master challenge Cm, from which the challenge Ci can be derived according to a predetermined deterministic challenge derivation function f.

[0116] This is shown in Figure 8A. Each response Ri is stored in association with its respective index. The function f is either stored in the response data store 601 or is known a priori to the verifier 103V. In either case, the verifier 103V inputs the master challenge Cm into the function f to determine a challenge Ci corresponding to the index i of at least one of the responses Ri. The verifier 103V then uses this challenge Ci to verify the target.

[0117] In some such embodiments, the function f may be a function of the identity 806, which may be a single identity or a combination 804 (e.g., concatenation) of multiple identities 802 (e.g., passport information, mother's maiden name, fingerprint information), which may include the identity of the target 103T. This allows for a set of challenges C that are unique to a particular target 103T, which is advantageous for security reasons, for example, because uniqueness may be important if the same third-party system 602 is used to generate challenge sets for different targets. Using personal identities such as the target's 103T's passport information or mother's maiden name is a good option because they are things the person already knows or has and tends to keep private.

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

[0119] 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. That is, a first challenge C1 is determined by applying a function f to the master challenge Cm, then a second challenge C2 is determined by applying the same function f to the first challenge, etc. By way of example, f may include a hash function.

[0120] In another variation, challenges Ci may be mapped hierarchically to master challenges Cm, as shown in Figure 8C, which will be discussed in more detail below.

[0121] A chained approach is more lightweight and easier to recover from the 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 not necessary for simple chains like C_m, H(C_m), H(H(C_m))... where, for example, f() is simply a hash function.

[0122] Regardless of the form of f() or whether the master challenge includes identification and / or other information, in some embodiments, the master challenge Cm may be received by the third-party system 602 from the target 103T during setup 702. The third party then stores the received master challenge in the data store 601 (e.g., locally or on-chain) for future use in verification 704. Alternatively, the third-party system 602 receives the set of challenges Ci from the target 103T and derives the master challenge Cm therefrom, for example, by applying the inverse of the function f(). In variations on these approaches, the third-party system 602 may receive the identification, master challenge, or set of challenges from somewhere other than the target 103T, for example, from an oracle or coordinating party (not shown). A combination of such approaches may also be used (e.g., one identification is received from the target and one is obtained elsewhere). Or, in a further alternative, no third party is involved and the target 103T stores the master challenge on-chain (or in some other peer-to-peer public medium) itself.

[0123] In a further variation of the method of FIG. 7 , the response data stored in the response data store 601 may not include a record of the CR pair(s) generated during setup. Instead, the response data may include a public key of a public-private key pair, or a collection of such public keys, where each of the one or more key pairs was generated based on a respective PUF response Ri from the setup phase 702. For example, the 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 FIG. 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 the target's PUF module 603. Instead, the verifier 103V obtains a message (e.g., a document, file, or part of a blockchain transaction) purportedly signed by the target. This message may have been sent by the target 103T, or the verifier 103V may have autonomously accessed it from a public medium such as a blockchain or a website. In either case, in step 750, the check involves verifying the signature applied to the message using the public key accessed from store 601 (based on known public-private key signature verification techniques, which themselves are well known in the art).

[0124] The following now describes some exemplary identity establishment and verification protocols for ePUFs, or more generally PUFs, according to embodiments disclosed herein. Consider a prover, Alice (target 103T), and a verifier, Bob (verifier 103V). In a PUF identity system, there are at least three different challenge types. While the following describes ePUFs as an example, more generally any PUF device can be used (any device with a PUF module 603).

[0125] 1. Remote PUF Challenge - The verifier remotely challenges the prover by requesting a response from Alice to a challenge submitted by Bob. This mode assumes that the verifier knows the response(s) expected from the prover's PUF and that the PUF is in possession of its legitimate owner.

[0126] 2. Local PUF Challenge - The verifier challenges the prover locally by interacting with a PUF device controlled by Alice. This mode assumes that the verifier knows something about the prover's identity but nothing about the behavior of its PUF.

[0127] 3. Cryptographic Challenge - The verifier challenges the prover to meet some cryptographic requirement related to the prover's identity, such as by signing a message with a key that is provably linked to the certified public key.

[0128] In the cases of Type 1 and Type 2, the challenge explicitly depends on the PUF module 603 from both the prover and the verifier's perspective. In these cases, the challenge, and therefore the corresponding verification process, is intrinsically linked to the operation of the PUF device (e.g., a device that has the PUF module 603, such as Alice's computing equipment 102T). In these cases, we are using the property of the PUF device that its physical state can be uniquely bound to an identity, and thus the PUF plays a central role in the identity system used.

[0129] Note that the terms "remote" and "local" refer specifically to the interaction between the verifier and the prover's PUF at the time of the challenge. This does not preclude a remote challenge protocol from having a setup phase involving local interaction between the prover and verifier beforehand.

[0130] 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 a PUF was used by the prover in generating the response to the challenge. In this case, the method simply uses the utility of the PUF as a key generator for Alice, rather than its utility in binding an identity to the device itself.

[0131] Below, exemplary implementations of the setup and verification, and optional update and revocation processes, for an identity system in each of the three aforementioned modes of operation are provided. In embodiments, a common trusted third party is involved in the processes associated with a PUF-based identity system, as such identity systems tend to require such a third party to meaningfully assure the integrity and trust of the identity and associated credentials. When an individual's identity is established and used in such a system, the trusted third party in question may be a certificate authority, a government agent, or a financial services provider such as a bank.

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

[0133] 3.1. Remote PUF System 3.1.1 Setup: In the case of a remote PUF challenge, the verifier who presents a challenge C to the prover is assumed to have prior knowledge of the expected response. That is, the setup process in this case requires establishing a set of CRPs (i.e., at least one) between Alice and another party that can be used to derive a shared secret that can later be used to authenticate Alice's identity.

[0134] Suppose Alice establishes this shared secret with a general third party equipped to establish identity as described above, and this third party may or may not be the verifier who later participates in the verification process with Alice. If the verifier is different from the third party establishing identity, then the verifier may obtain from the third party the relevant CRP information used for the shared secret(s).

[0135] There are two different options for the setup phase, categorized according to whether Alice is the only party with access to the PUF device at all times, or whether a trusted third party also has access to the PUF device only during the setup phase.

[0136] Case 1: Alice has sole access to the PUF 1. An ePUF device is manufactured and distributed to Alice. 2. Alice applies to link her identity to her ePUF device by contacting a trusted third party. i. The third party establishes an identity account for Alice and requests proof of Alice's identity. ii. Alice provides the relevant identity document or credential information to the 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 standard Diffie-Hellman key exchange): i. Alice and the third party each have a public key P A , P T Replace. ii. Alice and the third party independently agree on an ephemeral secret for the remainder of the setup communication, S = S A P T =P A ·S T Establish it as such. iii. Alice and the third party begin communicating over a channel secured by S, e.g., an AES-encrypted channel. 4. A third party challenges Alice with C1, C2, …, C n The set is sent over a secure channel. 5. Alice receives responses R1, R2, …, R from the ePUF device. n Get. 6. Alice sends responses R1, R2, …, R through a secure channel. n to a third party. 7. The third party creates a response CRP set {(C1,R1),(C2,R2),…,(C n ,R n )}.

[0137] Case 2: A third party accesses the PUF during setup 1. A third party has knowledge of the base pair and hash function. For example, ePUF devices are manufactured and distributed to a trusted third party*. 2. The third party receives the base CRP (C w ,R w ) to get the 3. Alice applies for an identity-linked ePUF device by contacting a third party, which may be done over an unsecured communication channel. i. A third party establishes an identity account for Alice and requests proof of Alice's identity. ii. Alice provides the relevant identity document or credential information to the third party. iii. A third party verifies Alice's identity and authenticates the ePUF device and its base pair (C w ,R w ) to Alice's account. The shared secret is or is derived from this CRP. 4. The third party sends the ePUF device to Alice. (*The device may first be 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, after setting up the PUF, the issuing bank may send it to the customer, Alice.)

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

[0139] 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 through physical security.

[0140] Another difference to note between the two protocols, Case 1 and Case 2, respectively, is that in Case 2, the trusted third party can derive the same number of CRPs as Alice without a PUF, whereas in Case 1, this party needs to memorize a fixed number of pairs.

[0141] This is an advantage of Case 2 over existing protocols for setting up a user with a PUF device, as it allows a trusted third party to remotely generate any number of CRPs, whereas in existing protocols the trusted third party may need to cooperate with either the end user or the device manufacturer to do so. Case 1 also requires Alice to send the base pair (C w ,R w ) to Bob (trusting that a third party will not use the base pair maliciously), the same technical advantage can be achieved.

[0142] Note that the use of secure communications during the setup phase allows future communications, such as the verification process, to be transmitted over an insecure channel. This has the advantage of allowing verification to occur with fewer technical restrictions, such as requiring both parties to be online at the time of verification, and only requires the additional secure communications overhead of this one-time setup process.

[0143] 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, detailed below.

[0144] Case 1: Alice has sole access to the PUF 1. Bob assigns an unused CRP, say (C1,R1), to the set {(C1,R1),(C2,R2),…,(C n ,R n )}. i. If Bob is also a trusted third party, then Bob simply takes an element from the set. ii. If Bob is not a trusted third party, Bob communicates with the third party by requesting an unused CRP for Alice. 2. Bob sends Alice a challenge C1. 3. Alice obtains the candidate response R'1 from her ePUF device and sends it to Bob. 4. Bob verifies whether R'1 == R1. If yes, the verification passes. ii. If not, the verification fails. 5. Then, the pair (C1,R1) is removed by a trusted third party, and the set of remaining challenge-response pairs {(C2,R2),(C3,R3),…,(C n ,R n )} remains.

[0145] Note that in step 1.ii., due to the single-use nature of the CRP, it is impossible for any Bob to "impersonate" Alice using a particular CRP, as the trusted third party would simply monitor the use of each pair in each given situation and should use a new CRP for each authentication attempt.

[0146] Case 2: A third party accessed the PUF during setup 1. Bob generates a new challenge C for verification. This can be done randomly or deterministically from some other data (e.g., known KYC data, biometrics, image). 2. Bob sends Alice a challenge C. 3. Alice obtains the candidate response R' from her ePUF device and sends it to Bob. 4. Bob gets the expected response R. i. If Bob is the trusted third party, then Bob can compute the response directly by computing R=hash(C,Rw,H)*. ii. If Bob is not the trusted third party, Bob sends C to the third party and requests a response R. 5. Bob verifies whether R'==R. If yes, the verification passes. ii. If not, the verification fails. (*This is because the third party has configured the base pair (C w ,R w ) (Case 2), which means that R w (This implies that the hash function is known to a third party. It is also assumed that the hash function is known, if not to everyone, then at least to said third party; i.e., the hash function is a public standard such as SHA-256.)

[0147] 3.1.3. Renewal: Given the single-use nature of CRPs in verification (and other useful protocols, e.g., login), it may be desirable to also specify a process for Alice and third parties to establish new CRPs.

[0148] Case 1: Alice has sole access to the PUF. In this case, a separate secure channel is established between Alice and the third party to transmit the challenge and response, just as in the setup. Alice has S=H(R i ) to establish a shared secret of the form (C i ,R i ) or the previous shared secret S=S from the DH key exchange. AP T =P A ·S T Suppose we have access to 1. Alice and the third party establish a secure communication channel using a shared secret S, which can be derived in many ways and is agnostic to the protocol. 2. A third party challenges Alice with C1, C2, …, C n The set is sent over a secure channel. 3. Alice receives responses R1, R2, …, R from the ePUF device. n Get. 4. Alice sends responses R1, R2, …, R over a secure channel. n to a third party. 5. The third party generates a response CRP set {(C1,R1),(C2,R2),…,(C n ,R n )}. Note that at least steps 2-5 are identical to the setup steps 4-7.

[0149] Alice sends a message to a third party (C w ,R w ) see also the previous comment regarding conveying

[0150] Case 2: A third party accesses the PUF during setup. In this case, the third party accesses the base pair (C w ,R w ) and the hash function H(), we can indirectly generate any number of CRPs, i.e., there is no need for iterative updates in this case.

[0151] 3.1.4. Revocation: A further part of the identity system may be to revoke a particular ePUF device so that it is no longer used for identity purposes. The revocation process is simple and can be performed either as (i) revocation by a third party independent of the user, Alice, or (ii) revocation by Alice communicated as a revocation request.

[0152] In the first case, no technical measures, including ePUFs, are needed. In the second case, no ePUF-specific protocols or solutions are needed. A good example of when revocation would be necessary in the first case would be if Alice lost the physical device containing the ePUF, or if the physical device was somehow compromised.

[0153] However, if Alice still has physical control of the device and it is desired to optionally leverage an ePUF in the revocation process, it may be specified that Alice's request be authenticated using one of the CRPs (or a derived shared secret) established by Alice and the third party, for example by an HMAC or encrypted message using the CRP response or secret as the key in each case, although for reasons discussed above this is not considered a strict requirement of the system.

[0154] 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 is in how the following verification steps are performed.

[0155] 3.2.2 Verification: In this scenario, verification is performed locally, i.e., the verification process requires that both the prover (Alice) and the verifier (Bob) are in the same physical location.

[0156] This scenario may be useful, for example, in court proceedings where Alice is legally required to interact with law enforcement locally using her ePUF device (for human identity), or when analysis of IoT systems is performed where the administrator of the system may want to explicitly check the response of a particular device locally (for device identity). It may also be useful in payment scenarios.

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

[0158] 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 the verifier has prior knowledge of the ePUF response, i.e., the response generated during the local verification process is not available to the verifier in advance.

[0159] However, in this scenario, the challenge used in the verification process is likely to be meaningful in some way, e.g., the identity of the embedded ePUF component's base pair (C w ,R w ), a verification process can be performed to verify that it was this particular device that previously produced output R from a given input C.

[0160] 1. Bob obtains a relevant challenge C to submit to the ePUF device based on the CRP(C,R) in question. 2. Bob gains access to the ePUF device. 3. Bob uses the ePUF device to generate a candidate response R' = hash(C,R w ,H). 4. Bob verifies whether R'==R. If so, the verification passes. ii. If not, the verification fails.

[0161] In these scenarios, Bob does not know the candidate response R' in advance; rather, he is verifying that the response he is currently receiving from the PUF device matches a previously generated response. For example, this can be used to verify that the person (Alice) or device that prevailed and generated the response is the same person or device currently present (e.g., in court). In the digital component example, this would have been configured to issue the command based on some input challenge C upon the generation of R. For example, if the device were a self-driving car and the component received a challenge derived from or including data that said "the car in front is too close," response R would be generated, and triggered by R, the component would issue the command to apply the brakes. Thus, in retrospective diagnostic verification, the verifier might think the car slowed down and want to verify that the condition that triggered that response was indeed "the car in front was too close."

[0162] 3.2.3. Update: The process of generating an updated CRP can follow the same logic as proposed for the remote case, since the main difference in that scenario applies only to validation.

[0163] 3.2.4 Revocation: The same techniques described for remote revocation are valid here.

[0164] 3.3. Cryptographic PUF Systems 3.3.1 Setup: In this case, Alice establishes her identity with a third party using standard cryptographic means, but using an ePUF device in the process.

[0165] In this scenario, a third party may optionally know that an ePUF was used in the process. Similarly, for an identity established in this manner, the identity verifier may or may not know that an ePUF device is involved in the identity verification process. In essence, the following protocol simply specifies that Alice, the device owner, knows that an ePUF device is involved in the identity system.

[0166] 1. An ePUF device is manufactured and distributed to Alice. 2. Alice applies to establish her cryptographic identity by contacting a trusted third party. i. A third party establishes an identity account for Alice and requests proof of Alice's identity. ii. Alice provides the relevant identity document or credential information to the third party. iii. A third party verifies Alice's identity. 3. Alice chooses a cryptographic method to establish a cryptographic link to her identity, for example, to establish an asymmetric key pair authenticated using her CRP. i. A third party receives a public key P from Alice. A where P A =s A ·G is an EC key pair. ii. The third party is responsible for ensuring that Alice has the private key s A , which requests that the message m be signed (e.g., with ECDSA) using iii. Alice generates the ECDSA signature Sig(P A ,m) and send it to the third party. iv. A third party verifies the signature. 4. If the signature is valid, the third party authenticates Alice with key P A Authenticate.

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

[0168] 3.3.2 Verification: In the cryptographic case, identity verification is performed using the cryptographic information established during the cryptographic setup phase detailed above. In this case, take the example where an authenticated EC asymmetric key pair was established for Alice's identity during setup, and now use that key for verification.

[0169] However, the following protocol can be easily adapted for any other cryptographic scheme by simply substituting the existing setup and verification protocols for those schemes as appropriate. The difference here is the use of an ePUF device as a secure key generator for the setup and verification process. This mitigates the risk of malicious compromise for holder Alice.

[0170] 1. Bob receives information P linked to features. A , e.g., to obtain an authenticated key. i. If Bob is the trusted third party, then Bob simply transfers P from Alice's account A Get. ii. If Bob is not the trusted third party, then Bob communicates with the third party and requests a certified public key for Alice. 2. Bob selects a message m for Alice to sign and sends it to Alice. 3. Alice generates a signature for message m. i. If Alice wants to sign with her certified key, she writes the signature Sig(P A ,m). ii. If Alice wants to sign with a single-use derived key, she creates a signature Sig(P α ,m), where P α =P A +H(d)·G and d are some single-use data*. 4. Alice sends her signature to Bob. At this point, if Bob does not already know data d, Alice may also send data d. 5. Bob is P A (and d, if applicable) to verify the signature against the public key. i. If the signature verification is successful, the identity verification is successful. ii. If the signature verification fails, the identity verification fails. (*This data may be relevant to the verification, e.g., fuzzy matching data from an invoice message or biometrics. The data d may be chosen by Bob or Alice. Alternatively, d may be a shared secret known to Alice and Bob, derived e.g., using Diffie-Hellman key exchange and / or HMAC.

[0171] The cryptographic verification process described above may also be applied to independently established identities, as described in the previous section, if the identities were established using similar cryptographic primitives such as EC or PGP keys.

[0172] 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, and therefore there is no need to specify any particular method here. Instead, P A Standard methods for updating authenticated keys, such as

[0173] It may simply be assumed that the ePUF is involved in key generation for any required signature or other cryptographic process required by the existing process(es).

[0174] 3.3.4 Revocation: Similarly, there is no need to specify a specific revocation protocol here, but rather follow standard mechanisms. Again, it may be assumed that the ePUF acts in the background as a key generator for the associated cryptographic operations.

[0175] 3.4. Independent PUF Mechanism 3.4.1 Setup: Establishing Identity Using an ePUF Device In the isolated case, we consider a scenario where an entity wants to establish a human identity, or a device identity within a closed system, independently of any third party. The only party involved in this process is Alice, the "owner" of the ePUF device and the final attester during later verification.

[0176] Case 1: Alice establishes her human identity 1. Alice acquires an ePUF device. 2. Alice probes the ePUF with challenge C. 3. Alice gets the response R from the ePUF. 4. Alice uses the pair (C,R) to establish an identity about herself. i. Alice receives an unauthenticated identity key P A A cryptographic setup may be used to establish ii. Alice publishes her identity key for her identity. 5. Alice may wish to publish a trail of her CRP, such as a double hash of the response, H2(R).

[0177] This case, where Alice establishes a "self-sovereign" identity for herself, is somewhat useful in providing unique and reproducible device identifiers for devices that only Alice controls. However, because there is no trusted third party in such an identity system, the verifier must later trust the link between the prover's identity and the prover's device. This may have very limited use in the real world.

[0178] Case 2: Alice establishes an identity about the device 1. Alice acquires an ePUF device. 2. Alice probes the ePUF with challenge C. 3. Alice gets the response R from the ePUF. 4. Alice uses the pair (C,R) to establish an identity for the device in 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 generates a double hash of the response, H 2 You may wish to publish evidence of your CRP, such as (R).

[0179] In the above example of creating a "self-sovereign" identity for devices, we can see that this design can be very useful in a closed system where an administrator is simply trying to identify the various devices in the system. This can also be useful for attesting to others later. However, because there is no trusted third party during setup, in some scenarios the prover is limited in being able to convince an external verifier that the device has not been altered.

[0180] Note that Case 1 and Case 2 may be considered to be the same process but with different intended purposes. Therefore, Case 1 and Case 2 may be collectively interpreted as a method for generating "self-sovereign" identities for humans or machines, where in the latter case, the system administrator (e.g., Alice in an IoT system) is herself the trusted entity. In both cases, Alice is the trusted entity.

[0181] 3.4.2 Verification: The verification process for this case is as simple as probing the ePUF device with a given challenge and examining its response. On top of this, more complex proofs or evidence for external parties may need to be built to prove the identity to them.

[0182] 3.4.3 Update: The update process for this case is simply a repeat of the setup process, where the administrator (in this case Alice) lists additional CRPs for forwarding use.

[0183] Revocation: In this scenario, since there are no third parties involved in the process, the only type of identity revocation is when the administrator (Alice) wants to revoke the identity on her own. This means that revocation can be as simple as Alice ceasing to use the ePUF device and purging its CRPs from her database.

[0184] In a later section, we will show how this revocation of self-sovereignty can be made more robust with blockchain trails and evidence so that it can later be convincing to external parties.

[0185] 3.5. Feature-based CRP Management In the above, particularly in remote PUF-based identity systems, the single-use nature of the CRPs used to authenticate identities in the setup and verification protocols presents CRP management challenges for the parties involved.

[0186] For example, if a trusted third party does not have access to the PUF device during setup, a number of CRPs may be enumerated {(C1, R1), (C2, R2), ..., (C n ,R n )}. Furthermore, because the ePUF itself acts as a deterministic pseudo-random mapping of challenges to responses, the responses appear unrelated to one another. Therefore, the burden on a trusted third party to catalog and store sets of CRPs for its users or clients quickly presents a scaling problem when a large number of users need to be served.

[0187] FIG. 8A illustrates the deterministic derivation of a problem from identification data in accordance with an embodiment disclosed herein.

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

[0189] In some such embodiments, Alice's (target's 103T) identification data 806 is used as master data for generating a large range of challenges to determine which CRPs are used in an identity system such as those proposed in the previous sections. The identification data itself may include a combination 804 of various data elements 802, but preferably the combination has the following properties: · Uniqueness – the identifying data is specific to the entity to which it relates; · Confidentiality – Identifying data is known only to the entity to which it pertains (or its owner).

[0190] Simple examples of components of identification data might include a passport number, national insurance number, name, date of birth, or answers to security questions (e.g. mother's maiden name), or in the case of device identification, serial number and manufacturing information. However, it is recognised that data obtained by more sophisticated technical means, such as fingerprint or facial recognition data, may also be used. These may be extracted using fuzzy-magic techniques to ensure uniqueness.

[0191] In embodiments, the "identification data" used as the master input from which the set of challenges is derived may include more than one of the above. One reason for this is to ensure that the information remains confidential with respect to as many trusted third parties as possible, given that some of the protocols in the previous sections rely on sharing challenges with third parties and / or external verifiers. Identity data that includes multiple components is more difficult for any third party to completely replicate without the consent of the prover, Alice.

[0192] A mechanism for deterministically generating a CRP using identification data is shown in Figure 8A. The constituent parts of the identification data are first combined by process "A" (804). This may be concatenation, a bitwise operation (e.g., XOR), or any other related combining operation. Note that this operation may attempt to preserve secrecy by converting the raw data into an obfuscated form.

[0193] The identifying data is then converted to a master challenge C by a hash function or similar process. m Finally, the master challenge is transformed into the single-use challenges C1,C2,…,C using the derivation function f(). n In some embodiments, the derivation function f() may include a hash function and nonce injection, and each successive challenge is used to deterministically derive a sequence of C i =SHA256(C i-1 ,i), where i acts as a nonce.

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

[0195] Figure 8C shows another specific example, namely, the hierarchical and deterministic derivation of the challenge (response not shown). As shown in Figure 8B, Master C m From tiered single-use Challenge C i In this case, CRP management is further improved by the fact that the generation of a particular challenge does not have to depend on all previous challenges, as in the previous case.

[0196] The use of deterministic derivation of challenges based on identity data reduces the storage overhead for both the prover Alice and trusted third parties in the identity protocol: any party can simply store the identifying data (or a subset thereof) and recompute the necessary challenges as needed.

[0197] Additionally, Alice also has the option to adjust her privacy by choosing how much information she wants to withhold or share with each identity service. The trade-off is that she may store more data herself.

[0198] 4. Examples of Blockchain Systems The following describes an exemplary blockchain system that may be employed in certain embodiments of the present disclosure. Note that "Alice" and "Bob" are simply arbitrary names for two parties, and Alice and Bob do not necessarily play the same roles in this section as they do in previous or later sections.

[0199] In some embodiments, response data based on the output of the PUF may be stored on-chain, for example, as discussed in the previous section. The response data stored on-chain may take the form of the actual response itself, or a transformation such as a hash or double hash (a so-called trail 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 allows another verifier to check whether the target response or signature presented as proof of identity is as expected. In further embodiments, the blockchain may be used as a means to manage challenge-response pairs, such as by updating or revoking them.

[0200] Below we describe an example of a blockchain system that may be used to implement such functionality.

[0201] 4.1. Example System Overview 1 illustrates an exemplary system 100 implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be organized as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0202] Each blockchain node 104 includes peer computing equipment, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes processing equipment including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment, e.g., application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as a hard disk; electronic media such as a solid-state drive (SSD), flash memory, or EEPROM; and / or optical media such as an optical disk drive.

[0203] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained by each of multiple blockchain nodes 104 within a distributed or blockchain network 106. As previously mentioned, maintaining a copy of the blockchain 150 does not necessarily imply complete memorization of the blockchain 150. Instead, the blockchain 150 may be pruned, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type 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 specific transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to an output of a previous transaction 152, thereby linking the transactions.

[0204] Each block 151 also contains a block pointer 155 that points back to the previously created block 151 in the chain, thereby defining a sequential order for the blocks 151. Each transaction 152 (except coinbase transactions) contains a pointer to the previous transaction, thereby defining an order for sequences of transactions (note: sequences of transactions 152 can branch). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a previous transaction.

[0205] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered collection (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term here is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered collection of transactions that the node 104 has accepted as valid, and therefore the node 104 is obligated not to accept any other transactions that attempt to use the same output.

[0206] For a given current transaction 152j, its (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction or any block 151 in the ordered set 154. The previous transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even transmitted to the network 106. However, the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "precedent" here refers to the preceding in the logical sequence linked by the pointer, not necessarily the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). The previous transaction 152i can equally well be referred to as the previous transaction or predecessor transaction.

[0207] The input of the current transaction 152j also includes, for example, an input authorization, such as the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j can 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 provide change). In some cases, a transaction can have multiple inputs, collecting amounts from multiple outputs of one or more previous transactions and reallocating them into one or more outputs of the current transaction.

[0208] In an output-based transaction protocol like Bitcoin, when a party 103, such as an individual user or an organization, wishes to execute a new transaction 152j (either manually or through an automated process employed by that party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient ultimately transmits this transaction to one or more blockchain nodes 104 in the network 106 (typically a server or data center today, but in principle could also be another user terminal). It is also not excluded that the party 103 executing the new transaction 152j may transmit the transaction directly to one or more blockchain nodes 104, possibly without sending it to a recipient. Blockchain nodes 104 that receive the transaction check whether the transaction is valid according to a blockchain node protocol applied by each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i to which the new transaction assigns it, which condition typically includes at least checking that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined, at least in part, by a script included in the output of the preceding transaction 152i.Alternatively, it may be fixed solely by the blockchain node protocol, or it may result from a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0209] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether it has already been validly redeemed by the input of another, prior transaction 152j, according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the prior transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated as a warning) and is not recorded in the blockchain 150. This protects against double-spends, where a transacting entity attempts to allocate the same transaction output multiple times. On the other hand, an account-based model protects against double-spends by maintaining account balances. Again, because there is a defined order of transactions, the account balance always has a single, defined state.

[0210] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions, in a process commonly referred to as mining. This is supported by "proof-of-work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a certain number of leading zeros. Note that this is just one specific type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0211] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides its solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The first blockchain node 104 propagates the block to threshold consensus among other nodes, which accept the block and thereby enforce the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 pointing to the previously created block n-1 in the chain is also assigned to the new block 151n. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, indicates the first node's intention 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 validated transaction (also known as double-spend). Once created, blocks 151 cannot be modified because they are known and maintained at each blockchain node 104 in the blockchain network 106. Block pointers 155 also enforce a sequential order on blocks 151. This provides an immutable public ledger of transactions because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0212] The various blockchain nodes 104 are constantly competing to solve the puzzle. Depending on when they began searching for a solution or the order in which transactions were received, they may do so based on different snapshots of the pool of unpublished transactions 154 at any given time. Whoever first solves each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, updating the current pool of unpublished transactions 154. Blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol for resolving "forks" that may occur. A fork is when two blockchain nodes 104 solve a puzzle within a very short time of each other, causing competing views of the blockchain to propagate between the nodes. In essence, the longest branch of the fork becomes the definitive blockchain 150. Note that this should not affect users or agents of the network, as the same transactions appear in both forks.

[0213] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional accepted amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional defined amount of digital assets. This special type of transaction is commonly called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof-of-work indicates the node constructing the new block's intent to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generational) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is typically called a "transaction fee" and is discussed later.

[0214] Due to the resources involved in validating and publishing transactions, at least each blockchain node 104 typically takes the form of a server, or even an entire data center, including one or more physical server units. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0215] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform its respective role(s) and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein may be performed by software running on the processing unit of the respective computing facility. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0216] Also connected to the network 101 are respective computer facilities 102 of multiple parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing 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 a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0217] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not fulfill the roles required of blockchain nodes. Instead, each party 103 interacts with the blockchain network 106 and thereby utilizes the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective facilities 102 are shown for illustrative purposes: a first party 103a and its corresponding computer facility 102a, and a second party 103b and its corresponding computer facility 102b. It will be understood that many more such parties 103 and their respective computer facilities 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to herein as Bob, although it will be understood that this is not intended to be limiting and that references herein to Alice or Bob can be replaced with "first party" and "second party," respectively.

[0218] The computer equipment 102 of each party 103 includes a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer equipment 102 of each party 103 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks; electronic media such as solid-state drives, flash memory, or EEPROMs; and / or optical media such as optical disk drives. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to run on the processing unit. It will be understood that any actions attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computer equipment 102. The computer equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0220] The client application 105 includes at least a "wallet" functionality, which has two main functions: first, allowing each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 for propagation throughout the network of blockchain nodes 104 and thereby inclusion in the blockchain 150; and second, reporting to each party the amount of digital assets they currently own. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0221] NOTE: While various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may be implemented in a suite of two or more different applications, for example, interfacing via an API or one being a plug-in to the other. More generally, client functionality may be implemented at the application layer or at a lower layer, such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0222] An instance of a client application or software 105 on each computing facility 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 about transactions for which the respective party 103 is the recipient (or indeed to inspect other parties' transactions in the blockchain 150; in embodiments, the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing facility 102 is configured to formulate and send transactions 152 according to a transaction protocol. As previously mentioned, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward the transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0223] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality in her client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her 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 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," examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0224] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new, validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 onward in the network 106. Because each blockchain node 104 applies the same protocol, if transaction 152j is valid, this means that the transaction will soon propagate throughout the network 106.

[0225] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins a race to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever arrives first defines the set of transactions contained in the latest block 151. Ultimately, one blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 containing the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 contains a pointer to the previous transaction, the order of transactions is also immutably recorded.

[0226] Different blockchain nodes 104 may initially receive different instances of a given transaction and may therefore have conflicting views about which instance is "valid" until one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0227] Another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based model, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a previous transaction in a sequence of past transactions. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be signed in a transaction. This data field may point to a previous transaction, for example, if the data field contains a previous transaction ID.

[0228] 4.2 UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting for all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may be implemented in other exemplary blockchain networks as well.

[0229] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain an unspent transaction output (UTXO), which can be used as a source for the input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies the amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include the transaction's ID. In some embodiments, 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 the node 104.

[0230] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes some amount of the digital asset locked to Alice in the 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 FIG. 2. Tx0 and Tx1 are simply arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point back to any preceding (i.e., earlier) transaction that still has unspent outputs 203 locked to Alice.

[0231] The predecessor transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in a new block 151. Alternatively, Tx0 and Tx1 may be generated together and submitted to the network 106, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transaction. These terms may be equivalently interchanged with “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a predecessor transaction (a prior transaction or "parent") will not be validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Orphans may be discarded or buffered for some time to await their parent, depending on the node protocol and / or node behavior.

[0232] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script. The locking script defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script defines the unlocking conditions, which typically include a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0233] A lock script (aka scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S), which is used by blockchain networks. The lock script specifies what information is needed to use the transaction output 203, for example, requiring Alice's signature. The unlock script appears in the transaction output. The unlock script (aka scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the transaction input 202.

[0234] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 is the UTXO A ], which means that Alice's signature, Sig P, must be present for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A Request Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in embodiments is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to distinguish it among any other possible outputs of Tx0. Tx1's input 202 also includes an unlock script that includes Alice's cryptographic signature, created by applying Alice's private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0235] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which runs the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In some embodiments, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] Here, "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function contained in the lock script (a stack-based language in this example). Equivalently, rather than concatenating scripts, scripts may be executed sequentially using a common stack. Either way, when executed together, the scripts will share Alice's public key P, contained in the lock script at the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In embodiments, the signed data includes Tx1 in its entirety (thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since the signed portion of the data is already implicitly present).

[0236] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message with her private key, then, given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging it as a signature on the message, thereby allowing any holder of the public key to authenticate the signature. Thus, any reference herein to signing a particular piece of data or transaction, etc., can, in embodiments, mean signing a hash of that piece of data or transaction.

[0237] If the unlock script for Tx1 satisfies one or more conditions specified in the lock script for Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106 for propagation throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO from Tx0 as spent. Note that Tx1 can only be valid if it uses an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Thus, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0238] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0239] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" some of the amount defined in the spent UTXO while another amount is spent. However, the amount from the UTXO can be divided among multiple outputs of the next transaction. For example, the amount defined in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay another party.

[0240] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include Alice's transaction in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and, thus, while technically valid, may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, any difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0241] Alice and Bob's digital assets consist of UTXOs locked by both parties anywhere in the blockchain 150, in any transaction 152. Thus, typically, a given party's 103 assets are distributed across UTXOs in various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked by each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

[0242] Note that script code is often expressed generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_...." refers to a specific opcode in the Script language. As an example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of the lock script, stores data within the transaction, thereby generating an unspendable output of the transaction that can record the data immutably in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0243] Typically, the input to a transaction is a public key P AIn some embodiments, it is based on ECDSA using the elliptic curve secp256k1. The digital signature signs 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 portion of the outputs that are signed depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0244] A locking script is sometimes called a "scriptPubKey," referring to the fact that each transaction typically contains the public key of the party being locked. An unlocking script is sometimes called a "scriptSig," referring to the fact that it typically supplies the corresponding signature. However, more generally, it is not required in all blockchain150 applications that the condition for a UTXO to be redeemed include authenticating the signature. More generally, one or more conditions can be defined using a scripting language. Thus, the more general terms "locking script" and "unlocking script" are sometimes preferred.

[0245] 4.3. Side Channels As shown in Figure 1, the client applications on Alice's and Bob's respective computing facilities 102a, 102b may have additional communication capabilities. This additional functionality allows Alice 103a to establish another side channel 107 with Bob 103b (at the prompting of either party or a third party). The side channel 107 allows for the exchange of data outside of the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob, without the transaction being registered on the blockchain network 106 or on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0246] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links, via one or more network technologies or communication media, for exchanging data "off-chain," i.e., separately from the blockchain network 106. When multiple links are used, the entire bundle or collection of off-chain links may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange certain information, data, etc., through the side channel 107, this does not necessarily mean that all of this data needs to be transmitted over exactly the same links, or even the same type of network.

[0247] The side channel 107 may include a secure channel using known secure communication techniques to enable secure and private 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 through the secure channel. Such a channel may be used, for example, to communicate between a verifier 103V and a target 103T, such as to enable the verifier 103V to submit a challenge to a PUF 302 / 500 held by the target and receive a corresponding response.

[0248] 5. Blockchain-based PUF Identity Proofing As mentioned in the previous section, the response data, which is a record of the response, may be stored on a public blockchain rather than using a trusted third-party system 602. The response data is data determined at setup time and may later be used by the verifier 103V ("Bob") to test the target's identity claims made by the target 103T ("Alice"). Note again that Alice and Bob are merely arbitrary labels, and Alice and Bob do not necessarily play the same roles as in the general overview of the blockchain system given in Section 4, where Bob consumed the output of Alice's transaction.

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

[0250] Whatever form it takes, as shown in FIG. 9, during the setup phase 702, such response data 901 can be stored in the output 203 of the transaction 152S recorded on the blockchain 150. This may be referred to below as a storage transaction. For example, it may be recorded on-chain using the techniques discussed in Section 4 above. Note again that Alice in this section is not necessarily the target 103T, and Bob in this section is not necessarily the verifier 103V—indeed, the target 103T, now referred to as Alice, may be the one who formulates and submits the storage transaction 152S to be recorded on-chain. As another example, a trusted third party may formulate a storage transaction template for the target 103T, completed by including the response data 901 generated during setup, and forward it to be recorded on-chain. The target 103T may submit the storage transaction 152S directly to one of the blockchain nodes 104 for propagation through the blockchain network 106, or indirectly via another party, such as a trusted third party. As yet another example, the target 103T may send its response data 901 to a trusted third party, which may then formulate it into a storage transaction 152 and send it to be recorded on the chain.

[0251] Response data 901 may be stored in the unusable output of storage transaction 152S. For example, this may be made unusable by OP_RETURN, or OP_FALSE followed by OP_RETURN if using the Script protocol. (In some blockchain protocols, such as BTC and BCH, including OP_RETURN makes the output unusable, while other protocols, such as BSV, require both OP_FALSE and OP_RETURN to make the output unusable.) BTC (Bitcoin), BTC (Bitcoin Cash), and BSV (Bitcoin Satoshi Vision) are different exemplary implementations of the aforementioned blockchain systems.

[0252] Alternatively, the response data 901 may be embedded in the available output of the storage transaction 152S. For example, it can be kept available by including OP_RETURN without OP_FALSE. As another example, the data can be embedded in the available lock script by including it immediately before the OP_DROP code. This applies to BTC, BCH, and BSV as well.

[0253] In various embodiments, response data 901 for multiple different sets of CR pairs {Ci,Ri} for a given target 103T may be stored. These may be stored in the same output 203 of a storage transaction 152, or in different outputs 203, or a combination of some in the same output and some in different outputs. They may be stored in the same storage transaction 152S, or the response data 901 for different CR pairs may be stored in different storage transactions 152S, or a combination of some in the same transaction and some in different transactions.

[0254] Note 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 for one or more transactions in the account-based model.

[0255] In the verification phase 704, when the verifier 103V wishes to verify the identity of a target, the verifier 103V accesses the blockchain 150 to retrieve response data 901 corresponding to a particular CR pair from the storage transaction 152S. In some embodiments, this provides the verifier 103V with a response Ri corresponding to a particular challenge Ci, or a trail (e.g., a hash or double hash) of that response Ri. The verifier 103V also submits a challenge Ci to the target 103V and receives in response (what is purported to be) a response R'i that the target 103T (or its device) generates by inputting the received challenge Ci into the PUF module 603. The verifier 103V then compares the returned response R'i with a version retrieved from the on-chain storage transaction 152S, or applies the same transformation (e.g., H(R'i) or H) to the received response as was used for the trail. 2 (R'i)) and compare this with the trail obtained from the on-chain storage transaction 152S. Either way, if the comparison gives a match, the goal is verified.

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

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

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

[0259] As a variation on this, if the response data 901 (e.g., CR pairs) is stored in a third-party system 602 rather than on-chain, instead of (or in addition to) distributing decryption keys, other means may be used to ensure that each verifier only gains access to their own subset of CR pairs (or more generally, response data). For example, the trusted third-party system 602 may maintain a password-protected account for each verifier, which the verifier is required to log into to gain access to their challenge(s), and is given access only to their own CR pair(s).

[0260] Such a scheme may have security advantages: if a response Ri for a given CR pair is disclosed to one verifier 103V, it may be desirable to not use the same CR pair for another verifier 103V. Otherwise, the first verifier 103V could use the now-known response Ri to appear to another verifier as the target 103T. However, if all potential verifiers 103V with access to the response data 901 are trusted, it is not necessary to take measures to prevent this.

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

[0262] As also shown in Figure 9, in embodiments using an output (e.g., UTXO-based) model, this may be leveraged to provide an efficient mechanism for managing CR pairs (or keys derived therefrom), where management may include updating or revoking CR pairs or keys (e.g., once consumed (e.g., used in validation)).

[0263] To do this, a new modifier transaction 152M is recorded in the blockchain 150. It has an input 202 that points to one of the outputs 203 of a storage transaction 152S where the response data 901 to be revoked or updated is stored. This is sometimes called "spending," "redeeming," or "allocating" the output (note, however, that this does not necessarily imply a transfer of monetary value). At the Layer 2 protocol level recognized by the verifier 103V, this means that the response data 901 in the pointed-to storage transaction 152S or output 203 is no longer used. If the modifier transaction 152M itself includes the response data 901' in one of its outputs, this is interpreted as indicating that the new response data 901' represents a replacement for the previous response data 901 (e.g., a new CR pair). When the verifier accesses the blockchain 150 to find the response data to use in a validation operation, it uses the updated version 901', not the replaced version. On the other hand, if the modifier transaction 152U does not include replacement response data 901, it is interpreted as simply invalidating the response data 901 in the storage transaction 152S or the output 203 to which it points.

[0264] In some embodiments, the response data 901 is embedded in a usable output of the storage transaction 152S and may be revoked or updated by using (i.e., allocating or redeeming) the 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 may be stored in separate outputs 203 of the same storage transaction 203 and may be individually retrieved or updated.

[0265] In other embodiments, response data 901 may be stored in an unspendable output of storage transaction 152S and may be expired or updated by consuming (i.e., allocating or redeeming) different usable outputs of storage transaction 152S. In some such embodiments, multiple storage data 901 (stored in the same or different unspendable outputs) corresponding to multiple different CR pairs may be expired or updated by consuming the same usable output of the same transaction 152S.

[0266] As an exemplary use case, a record of response data 901 corresponding to a CR pair can be revoked or updated once it has been consumed, i.e., used in a validation. This is true whether the response data 901 is an explicit record of Ri, a trail, or a public key derived from Ri. In any case, this can be advantageous for security reasons, so that response data that has now been made public to the world will never be made available again.

[0267] A modifier transaction 152M can be formulated and sent by the target 103T to be recorded on the chain. It may be sent directly to the blockchain node 104 for propagation, or indirectly to the node 104 via an intermediate party. Alternatively, a trusted third party may send a template transaction, which the target completes (e.g., by signing and / or adding replacement response data 901′) and forwards, directly or indirectly, to the node 104 to be recorded on the chain. As another possibility, a trusted third party may formulate the modifier transaction 152M (possibly based on a template or some data sent by the target 103T, including, for example, replacement response data 901′), and then the trusted third party may send the modifier transaction 152M to the node 104 to be recorded on the chain. Note that all of these options may also apply to how the storage transaction 152S is recorded on the blockchain 150.

[0268] According to the various concepts discussed above, a system is provided for i) linking an identity (or other related information such as a public key) to a UTXO and using the spend-state of this UTXO as a proxy of validity for identity credentials; and ii) establishing a set of transactions for performing efficient identity management operations such as setup, revocation, renewal, verification, etc. The process is more efficient in that the number of communications is reduced, as all parties can refer to the blockchain to see when CRPs are spent or an identity is revoked, rather than all parties needing to communicate with each other all the time.

[0269] Such techniques can be used to extend the framework for linking identity to PUF devices, as previously shown, for example, by minimizing reliance on third-party know-your-customer (KYC) providers to process CRP data used in verification. This goal can be achieved by partially replacing the role of the KYC provider, or rather some of its functions, with a public blockchain, allowing users to instantiate their own identity credentials associated with ePUF devices, independent of any third party.

[0270] The role of trusted third parties in identity systems is not necessarily avoided entirely, but in any event the identity management process can be improved, thereby at least reducing the burden associated with their involvement in the process.

[0271] 5.1. Linking PUF Features to UTXO Sets The first way in which the use of blockchain can improve identity systems, as discussed in the previous sections, is by using the public blockchain's unspent transaction output set (UTXO set) to manage the CRPs associated with PUF identities.

[0272] This section presents two different exemplary mechanisms for mapping CRPs to members of a UTXO set and using their status as a "spent" or "unspent" state as an indication of whether each particular CRP has been consumed in the identity verification process. The first mechanism involves embedding CRP data into usable UTXOs, while the second mechanism involves pairing CRP data with usable UTXOs. In either case, additional data related to the CRP or the identity in question may also optionally be included in the system.

[0273] Embedding in a Spendable UTXO: The first mechanism binds a CRP to a spendable UTXO, which is a transaction output containing a script whose conditions can be met by future inputs, and thus can be consumed by a future spending transaction.

[0274] 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)> where [Checksig P] is a standard pay-to-public-key-hash (P2PKH) locking script, and Rep(C,R) is a representation of a particular challenge-response pair (C,R).

[0275] This lock script can be unlocked simply by providing a valid signature SigP on the spend transaction, where the signature is considered valid for the public key P. Note that any data following the opcode OP_RETURN is not considered when validating the spend transaction, and thus this data is treated as optional and does not need to be formatted for the blockchain validator.

[0276] The data following the OP_RETURN code in the above script is a representation of the challenge-response pair (C,R), Rep(C,R). This representation can be created in a variety of ways, depending on the use case in question. However, a sensible example would be to encrypt the CRP using a key k known only to the prover Alice who possesses the PUF. In this case, one of the following representations could be used:

[0277] Rep(C,R)=Encrypt(C,k) Rep(C,R)=Encrypt(R,k) Rep(C,R)=Encrypt(C||R,k) These representations allow Alice to later retrieve or prove the challenge, response, or CRP, respectively, that was included in her UTXO.

[0278] Additional script encumbrances: The basic lock script shown above can be extended to include additional conditions on input scripts that use the output in the future. A sensible example of such an additional condition would be the following script: [Checksig P][Hash Puzzle H 2 (R)] OP_RETURN<Rep(C,R)> Here, [Hash Puzzle H 2 (R)]=OP_HASH160<H(R)> OP_EQUAL. Note that other hash function opcodes may be used. This modified script now requires the user to reveal the hash of the challenge R in addition to providing a valid signature on the public key P. The idea here is that in some scenarios, this can be used for proof-of-knowledge that the user knows information H(R) related to the challenge R in question.

[0279] Transaction Model: Given the exact structure of the transaction locking scripts to be used, a choice can be made about how to structure the transactions containing these scripts as a way of remembering, attesting, and managing CRPs.

[0280] Here we disclose a one-to-one mapping of CRPs and associated lock scripts to UTXOs, i.e., every UTXO containing such a script corresponds to exactly one CRP associated with a particular PUF device.

[0281] There are then several options for how to organize these UTXOs into transactions. The most likely possible options are: 1. One CRP per transaction. 2. One CRP set per transaction. 3. One PUF per transaction.

[0282] The first option may be applicable in some cases, such as for very infrequently used PUFs, such as updating a will, and has the advantage that multiple CRPs are not explicitly linked to each other. This may also be useful in situations where extreme privacy is required, since the consumption and revelation of one CRP can be revealed independently of any other CRP.

[0283] The transaction in Table 1 below is an example implementation of the first option. Notice that the transaction contains only a single input and output, and thus each CRP is included in a different transaction. Once the output is spent, the significance of this transaction to the identity system effectively ends, except for auditing purposes. [Table 1]

[0284] The second option may be more desirable for use cases such as bank cards, where the expected frequency of CRP consumption is fairly high, as many CRPs are mapped to each UTXO in a single transaction. The transactions in Table 2 below show how this can be achieved.

[0285] An input signature, likely generated by Alice, can be signed over the entire set of outputs, using a single public key P, while maintaining a one-to-one mapping of UTXOs to the different CRPs themselves. AIt provides a one-to-many link from one output / CRP to many UTXOs and therefore many CRPs. It is also assumed that each output / CRP has its own associated public key (all owned by Alice) to avoid reuse. [Table 2]

[0286] The above options will increase CRP concentration over time. , and a new transaction can be issued for the set each time an updated set is generated. Furthermore, multiple different sets of CRPs can be generated and issued simultaneously for the same PUF via parallel, independent (i.e., unrelated on-chain) transactions. This can be useful for establishing identities with multiple different trusted third parties (e.g., different banks), where each identity is established independently but is still anchored by the same PUF.

[0287] A third option, where a single transaction is used to represent a single PUF, is simply a more constrained version of option 2, where updates are not possible. This may be applicable if the device containing the PUF is given a specific "lifetime", where the device can only be used for a predetermined number of authentications before the user is issued a new device.

[0288] 5.1.2. Pairing with Usable UTXO An alternative to embedding the CRP within the spendable UTXO is to simply pair the CRP with these outputs. In this case, the difference with existing work on digital certificates is that the transaction can be constructed and signed by Alice, as she may want to leave a trail of origin independent of any third party. [Table 3]

[0289] In the diagram above, we can see an example transaction containing 2n outputs related to n CRPs, whereby each spendable output can be mapped to one of the CRPs, and the CRP representation itself is included in the corresponding unspendable output (e.g., OP_FALSE OP_RETURN). It should also be noted that the three possible variants for organizing CRPs into transactions and UTXOs apply here as well.

[0290] Discussion Benefits to CRP Management: The concept of mapping CRPs to UTXOs can significantly improve CRP management and processing for users of the identity protocols from the previous sections. One benefit is that the storage and retrieval of CRPs can be partially offloaded to a service provider that can facilitate the blockchain network 106 and reliable retrieval from the blockchain network 106.

[0291] By mapping all "live" CRPs of a particular PUF to its UTXOs, the CRP update process can be improved by querying the state of the UTXO set for accurate information about the CRPs currently available for a given PUF in the identity system.

[0292] Here's an example of a simple process using the blockchain and UTXO-CRP mapping conventions we've described: 1. Alice acquires a PUF device and sets the set of CRPs as (C1,R1),(C2,R2),…,(C n ,R n ) are listed. 2. Alice receives the transaction TxID as shown in Table 2. CRP-Set and broadcast it to the blockchain network. 3. Alice consumes multiple CRPs over time to authenticate her identity with a third party. 4. Alice now wants to check whether she has enough CRP to cover her expected activities for the next week. 1. Alice contacts a blockchain node 104, or a service provider similar to an SPV, and receives a TxID CRP-Set Ask which UTXOs are currently unspent. 2. The blockchain node or service provider sends a still unused transaction TxID CRP-Set It responds with the number of outputs. 5. If the number returned is insufficient, Alice can either initiate an identity update process with her trusted third party or enumerate more CRPs for independently established identities. Otherwise, Alice takes no action.

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

[0294] When the CRP is embedded within available outputs, this incentivizes the blockchain nodes 104 that maintain the blockchain network 106 to keep the data for these outputs readily available. This means that responses to Alice's queries may be faster, and more importantly, the blockchain nodes are more likely to be able to return the raw data for these transaction outputs to Alice.

[0295] As previously discussed, if the representation of the CRP, Rep(C,R), is included to contain raw (or obfuscated) data for 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 operate a more lightweight system using the blockchain 150, since embedding data in usable outputs increases the likelihood that Alice's data will be highly available regardless.

[0296] In contrast, if CRPs are only paired with available outputs, Alice may only be able to determine how many CRPs are available to her, but may not necessarily be able to retrieve the representation data itself from a Bitcoin node. This may mean that if Alice does not maintain her set of CRPs locally, she will need to consult an agent outside the blockchain node network 106.

[0297] Use of double hash: In the example implementation above, a double hash H 2 It shows that (Data) can be used 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 revealed on-chain, which in principle acts like a proof of knowledge that some party knows H(Data), and the single hash is associated with Data.

[0298] This can be useful, for example, in a PUF identity situation, where H 2 (R) can be satisfied by a third party who provides H(R) (if Alice has shared with them the actual value of R) and recorded on-chain by Alice as a spending encumbrance.

[0299] Multi-party signatures: The transactions detailed in this section may potentially include more signatures from multiple different parties to aid in Alice's attestation of her PUF identity. For example, it may be desirable for both Alice and a third-party identity provider to sign the CRP transaction input(s) as a way to improve verifiers' trust of Alice's identity. This is particularly useful if the countersigner is a certification authority that can show evidence of Alice's public key(s) used to sign the blockchain transaction. As an alternative to simply multiple signatures (i.e., "multi-sig"), multiple parties may be involved in the signing process, for example, through threshold signatures or key splitting techniques (e.g., Shamir Secret Sharing).

[0300] 5.2. Efficient Identity Management Using Transactions An additional way in which blockchain can be used in conjunction with PUF-based identity systems such as those described above is as an efficient means of revoking identity keys or tokens secured by PUF devices.

[0301] Previous work on digital certificate management has known to issue and revoke certificates on-chain, accompanied by a corresponding certificate validation process. Consider a scenario where Alice is willing to cooperate with a certificate authority to attest to her PUF-based identity on-chain. The process by which Alice registers an attestation of her identity on-chain is as follows: 1. A Certificate Authority (CA) verifies Alice's identity. 2. The CA generates a certificate transaction, which has the following inputs and outputs: a. Input: The CA's UTXO with the unlock script containing the CA's signature and public key. b. Output 1: P2PKH locking script. c. Output 2: The OP_RETURN output containing Alice's public key. 3. The transaction is broadcast and once mined, the CA sends Alice the transaction ID TXID CTX-PKA to provide.

[0302] The process boils down to Alice and the certificate authority working together to generate a transaction signed by the CA that contains an unusable output: a certificate for Alice's public key and a paired usable output that the CA can use to revoke the certificate.

[0303] The embodiments disclosed herein use a hybrid of the method outlined for digital certificates above and a method for establishing a PUF-based identity such as one of the methods described above, where an added element to the PUF identity system is the ability for a general-purpose trusted third party (similar to a CA) to "revoke" a CRP or associated public key by spending a UTXO.

[0304] When a trusted third party revokes the certificate for Alice's public key, this is related to the cryptographic identity establishment discussed above.

[0305] For CR pairs (CRPs) stored or attested on-chain, embodiments disclosed herein provide a scheme that allows a trusted third party to revoke a CRP once it has been used in the authentication process. An example method is shown below. 1. Alice and a trusted third party run an identity setup protocol (e.g., as described above). 2. Alice and the trusted third party now wish to use the blockchain for management of the CRPs generated in 1 or now available after step 1. a. Alice creates a CRP mapping transaction TxID that maps the CRP to a transaction output. CRP-Set This is shown in Table 4 below. b. Both Alice and the trusted third party have TxID CRP-Set Sign. 3. CRP Mapping Transaction TxID CRP-Set are broadcast and published in blockchain blocks. [Table 4]

[0306] The mapping transaction created by this process is shown above in Table 4. It is very similar to the CRP mapping transaction shown earlier in Table 2, except that both the trusted third party and Alice sign the input, and each UTXO mapped to the CRP can be revoked by the trusted third party by using it in a future transaction.

[0307] This allows CRP revocation to be handled without direct communication, allowing the TTP to perform revocation on behalf of the user, which has the further advantage of reducing Alice's burden in the system and allowing for lighter-weight identity management for Alice.

[0308] 6. Payment Verification System with Identity Verification Embodiments may combine any of the identity verification schemes disclosed herein with a payment verification scheme, for example, a blockchain-based payment verification scheme such as Simplified Payment Verification (SPV). If both outputs are "true," i.e., both the identity of the target and its source of funds are verified, then the output of the overall process is true, and conditionally, the payment is allowed to proceed.

[0309] This may be used to provide compliance systems, such as know-your-customer (KYC) systems. In embodiments, the disclosed mechanisms provide privacy-preserving KYC systems.

[0310] In embodiments, the combined payment and identity verification mechanism may be incorporated into, for example, a point-of-sale terminal or system to verify the identity of a customer when accepting payments. The embodiments below may be described in the context of such a system, but this is not intended to be limiting; more generally, any of the disclosed techniques may be applied to any system for accepting payments, such as, for example, web-based payments.

[0311] The following is illustrated with respect to SPV as a payment verification process, although this may be replaced by any process for verifying the source of funds of a target, such as non-blockchain-based systems like Worldpay or Visa. Additionally, the means for generating a CR pair may be a PUF module 603 including a PUF or ePUF 500, although in any embodiment this may be replaced more generally by any means for generating a response based on a challenge.

[0312] The concept of Simplified Payment Verification (SPV) was first introduced in the Bitcoin whitepaper in 2008 and has since been further elaborated upon, particularly in the context of point-of-sale (POS) systems.

[0313] The protocol outlined in Figure 10 illustrates how the SPV mechanism is used at the POS during a customer-merchant payment interaction. It first allows the merchant to check the integrity of the customer's existing funds and then confirm that the payment from the customer to the merchant was successful.

[0314] The illustrated POS process is similar to existing (i.e., non-blockchain) payment processing at the merchant's point of sale: the merchant challenges the customer to produce a payment, and the merchant utilizes a payment network or system (e.g., Visa, Worldpay) to verify, within a high degree of certainty, that the payment is valid.

[0315] In a traditional POS, this is facilitated by the merchant maintaining a connection to the payment network and using this connection to confirm the customer's payment at the POS, at which point the payment is made. However, in the non-blockchain world, this situation actually serves a dual purpose from the merchant's perspective. 1. Verifying payments; and 2. Fulfilling Compliance Obligations.

[0316] The first point has already been covered, but the second point can also be important: when a customer pays at a POS system and connects to the payment network via a merchant POS terminal (or, for example, a website), this interaction also serves as a means for the merchant to meet its obligations to comply with financial regulations, such as know-your-customer (KYC) and anti-money laundering (AML) regulations.

[0317] This aspect of compliance may not be active for the merchant, and it may not be apparent from the customer's perspective that compliance is occurring. However, it can be assumed that the act of the customer connecting to the payment network is tantamount to bringing the customer's identity into the payment interaction, and that bringing the customer's identity into the payment interaction is an assurance to the merchant that the requirements for identity involvement in transactions above a certain value threshold can be met. This inclusion of identity (i.e., linking to a bank account) can later be used, as and when needed, if required by regulators or law enforcement agencies to complete necessary compliance checks.

[0318] This second aspect of traditional payments, particularly those aspects of the commercial customer-merchant flow, is entirely different in a blockchain-based model and is not necessarily covered by the existing SPV interactions detailed above.

[0319] A blockchain-based privacy model ("new privacy model") according to embodiments disclosed herein is shown in Figure 11B (identity 1102 → firewall 1150 → transaction 1104 → disclosure 1110). By comparison, that of the existing payments ("traditional privacy model") just discussed is shown in Figure 11A (identity 1102 → transaction 1104 → trusted third party 1106 → counterparty 1108 → firewall 1150 → disclosure 1110). The difference between these scenarios is that the "identity" component is firewalled from the other actors in the payment process.

[0320] This can be seen by returning to the SPV model in Figure 10. In this model, there is no requirement for identifying information to be exchanged between the customer and the merchant in an SPV, and there is no need for such information to be recorded on the blockchain 150 itself. This means that the regulatory compliance aspect (2) that is implicitly achieved by traditional payment systems is not considered by an SPV, which only handles in-situ verification of the payment itself.

[0321] Therefore, embodiments of the present disclosure provide a solution to this problem by implementing a PUF-based identity token system in conjunction with existing SPV processes at the point of sale.

[0322] The disclosed solution is for a customer, Alice, who owns a PUF-enabled device, such as a bank card, that also functions as an offline SPV wallet. Alice can use her PUF-enabled bank card to establish her identity with an identity provider (i.e., a trusted third party) using one of the methods described in the previous sections, and then use a CRP shared between Alice and the identity provider to perform a merchant-mediated identity check during the payment interaction.

[0323] 6.1 Setup Consider a scenario in which Alice wants to establish a PUF-based identity provider (e.g., a third party operating third-party system 602), who may be named Ian, using an arbitrary label here.

[0324] Alice expects to make many payments in the future involving many different merchants, and these payments will not be made in Ian's presence. Therefore, in some embodiments, Alice and Ian perform a PUF identity setup process that is intended for many future remote verifications. This means that any of the setup models in the previous sections can be applied.

[0325] For simplicity, a variant may be chosen in which only Alice has access to the PUF module 302 (or other such response challenge-response function) during setup. Details of such a protocol are repeated here. 1. An ePUF device is manufactured and distributed to Alice. 2. Alice applies to link her identity to her ePUF device by contacting Ian. i. Ian establishes an identity account for Alice and requests proof of Alice's identity. ii. Alice provides Ian with any relevant identity documents or credentials. iii. Ian verifies Alice's identity. 3. Alice and Ian establish a secure communication channel via standard Diffie-Hellman key exchange for the remainder of the setup process (e.g., as discussed in previous sections): 4. Ian challenges Alice to C1, C2, …, C n The set is sent over a secure channel. 5. Alice receives responses R1, R2, …, R from the ePUF device. n Get. 6. Alice sends responses R1, R2, …, R through a secure channel. n to Ian. 7. Ian responds to Alice’s feature account with a set of response CRPs {(C1,R1),(C2,R2),…,(C n ,R n )}.

[0326] This setup is sufficient for Alice to use her card for up to n purchases (i.e., payment interactions), consuming at least one single-use CRP during each interaction. It should be noted that if an alternative setup were used in which a third party held the PUF module 603 (or other such challenge-response function), Ian and Alice would not share the n CRPs in advance, but instead Ian could independently generate a CRP and proceed to submit a challenge to Alice at the time of the payment interaction.

[0327] 6.2 Payment Interactions Consider a later point in time when Alice wishes to make a purchase at a POS of a merchant named Bob.

[0328] To initialize the following payment (step 0), Bob makes an SPV payment request to Alice according to the existing SPV model from Figure 10. The payment interaction then splits into two parallel branches: (i) the existing SPV payment interaction and (ii) the KYC compliance protocol described below. This process is also visualized in Figure 12, which shows only the numbered processes for branch 2.

[0329] 0. Bob makes an SPV payment request to Alice. The following branches are executed in parallel:

[0330] Branch 1: 1. The existing SPV mechanism in Figure 17 is executed. 2. Returns TRUE if the process completed successfully, FALSE otherwise.

[0331] Branch 2: 1. Bob requests a CRP from Alice's identity provider, Ian*. 2. Ian provides unused CRP(C,R) to Bob. 3. Bob presents Alice with challenge C and asks for a response from Alice's device**. 4. Alice passes the challenge C to her PUF and generates a candidate response R'. 5. Alice sends candidate response R' to Bob. 6. Bob checks if the response matches and returns TRUE if R'=R, otherwise returns FALSE. 7. If (and only if) both branches return TRUE, the payment is submitted to the Bitcoin network.

[0332] *There may be a step where Bob determines who Alice's identity provider is based on the information Alice gives Bob (assuming there are many possibilities). This can be included as part of step 0, and Alice responds to step 0 with this.

[0333] **This could be implemented by (for example) a card terminal, where Alice puts her card into the terminal to respond. Alternatively, it could be NFC, or simply a message sent from Bob's POS terminal to Alice's terminal (for example a mobile phone containing a PUF).

[0334] Note: This process is not limited to the PUF module 602; more generally, the C,R pair can be abstracted as any kind of authentication token. However, the PUF makes this much more robust, as it acts like a one-way function (making storage easier and the response can be calculated on the fly), and does not require the digital key to be stored in memory.

[0335] The mechanisms outlined above allow merchants to fulfill their obligations within the payment interaction from a compliance perspective, meaning that they can be confident that they have actively participated in, for example, the required KYC and AML precautions by communicating with the identity provider and running an identity verification process in parallel with the standard SPV check process.

[0336] The above protocol achieves the goal of facilitating KYC / AML compliance for blockchain transactions while preserving the privacy of the end user, Alice. Merchant Bob only needs to handle CRP data (C, R) during the above compliance process, which does not need to leak any identifying information about Alice herself. Furthermore, each CRP is single-use, so Bob's knowledge of a particular CRP does not compromise any information about Alice for future identity verification during different payment interactions.

[0337] When this protocol is combined with a blockchain-based CRP management system, it also allows for the CRP to be revoked on-chain instantly if Alice loses physical control of her PUF (e.g., if she loses it). This means that if Alice loses her device / card, KYC helps protect Alice from fraud, benefiting both Alice and the merchant. The blockchain here and its peer-to-peer network benefit the speed of the process by ensuring that CRP revocation can be propagated through the network very quickly.

[0338] As a further alternative or additional extension, the spend transaction that Alice uses to pay Bob may include a token in the payload of the transaction that serves as evidence that the identity verification process was successful.

[0339] 7. Conclusion Other variations or uses of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the disclosure is not limited by the described embodiments, but only by the appended claims.

[0340] For example, some embodiments described above are described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one specific example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

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

[0342] In other embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 in blockchain 150. For example, in these 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.

[0343] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such entities / elements are 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 in the same manner as described above with respect to blockchain nodes 104.

[0344] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program according to any one or more of the following statements may be provided: [Statement 1] A computer-implemented method for authorizing a payment by a target to a verifier, the method including, by the verifier: performing a payment validation to verify the source of funds of the target, and outputting a result of true if the target passes the payment validation; and performing an identity validation to verify the identity of the target, the identity validation including: accessing response data stored in a data store associated with the identity of the target, the data store being implemented in a third-party computing facility of a trusted third party or on a peer-to-peer public medium, the response data including either a) a stored instance of a response to a challenge or b) a trail including a transformation of the response; sending a request including the challenge to the target and receiving in response a further instance of the response; and performing a comparison and outputting a result of true if there is a match, the comparison including either a) comparing the stored instance of the response to the further instance of the response or b) comparing the trail to the same transformation applied to the further instance of the response. The payment is granted conditional on the outputs of both the payment verification and the identity verification being true. [Statement 2] 2. The method of claim 1, wherein the response is the result of the challenge input by a party other than the verifier in a setup phase preceding the method into a PUF module including a Physical Unclonable Function (PUF), and the PUF module generated the stored response in dependence on the given challenge using the PUF. [Statement 3] The method described in statement 2, wherein the PUF module has a PUF and a deterministic transformation function, and is configured to input a base input to the PUF to generate a corresponding base output; and to generate the response by inputting the challenge to the transformation function in relation to the generated base output to generate the response, wherein the transformation function is a function of the challenge and the generated base output. [Statement 4] The method of statement 2, 2 or 3, wherein the party who performed the setup is the target. [Statement 5] 5. The method of any one of statements 1 to 4, wherein the request and receiving the response are performed over a secure channel protected based on a shared secret shared between the verifier and the target. [Statement 6] 6. The method of any one of statements 1 to 5, wherein the data store is implemented on the third-party computer equipment. [Statement 7] 7. The method of claim 6, wherein the third-party computing facilities include one or more server units located at one or more geographic sites. [Statement 8] 8. The method of any one of statements 6 to 7, wherein the party that performed the setup was the trusted third party. [Statement 9] 9. The method of any one of statements 6 to 8, wherein the response data is accessed from the data store of the third-party computing facility through a secure channel secured based on a shared secret shared between the verifier and a trusted third party. [Statement 10] 10. The method of any one of statements 6 to 9, wherein the method includes receiving the challenge and the response data from the trusted third party, and the request sent by the verifier includes the challenge received from the trusted third party. [Statement 11] 11. The method of claim 10, wherein the challenge is received from the data store of the third-party computing facility over a secure channel secured based on a shared secret shared between the verifier and a trusted third party. [Statement 12] 6. The method of any one of statements 1 to 5, wherein the data store is implemented in the peer-to-peer public medium. [Statement 13] 13. The method of claim 12, wherein the peer-to-peer public medium is a blockchain. [Statement 14] 14. The method of claim 13, wherein the method includes accessing the challenge and the response data from the blockchain directly from a node of the blockchain network or indirectly through one or more intermediary service providers, and the request sent by the verifier includes the challenge accessed and received from the blockchain. [Statement 15] 15. The method of claim 13 or 14, wherein the response data is stored in an output of a storage transaction recorded on the blockchain, and the identity verification further includes checking that the response data has not been revoked by a further transaction recorded on the blockchain having an input that points to the output of the storage transaction, and the output result of the identity verification is further conditioned on the response data not being revoked according to the check. [Statement 16] 16. The method of claim 15, wherein the response data is stored in an available output of the storage transaction, and the check includes checking that the input of a further transaction by pointing to the same available output does not cause the response data to expire. [Statement 17] 16. The method of claim 15, wherein the response data is stored in an unusable output of the storage transaction, and the check includes checking that the input of a further transaction does not cause the response data to expire by pointing to a usable output in the same storage transaction. [Statement 18] 18. The method of any one of statements 1 to 17, wherein the source of funds includes one or more funding transactions recorded on a blockchain, and the payment to be authorized includes a usage transaction that points to the funding transactions. [Statement 19] 19. The method of statement 18, including providing a token to be included in the payload of the usage transaction, evidenceing the result of the identity verification, provided that the results of both the payment verification and the identity verification are true. [Statement 20] 20. The method of claim 18 or 19, wherein the payment verification includes a Simplified Payment Verification (SPV) process. [Statement 21] 21. The method of any one of statements 1 to 20, wherein the method is performed from a point-of-sale terminal. [Statement 22] A computer system having a memory having one or more memory units; and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, the code being configured to perform a method according to any one of statements 1 to 21 when present on the processing unit. [Statement 23] 22. A computer program embodied on a non-transitory computer-readable medium, the computer program being configured to perform the method of any one of statements 1 to 21 when executed on one or more processors.

Claims

1. 1. A computer-implemented method for authorizing a transaction between a target and a verifier, the method comprising: performing a first test to verify at least one asset of the target, and outputting a result of true if the target passes the first test; performing a second verification to verify the identity of the target, the second verification comprising: accessing response data stored in a data store associated with the target's identity, the data store being implemented separately from the target and the verifier, the response data including either a) stored instances of responses to challenges, or b) a trail including a transformation of the responses; sending a request including said challenge to said target and receiving in response a further instance of said response; performing a comparison and outputting a true result for a match condition, said comparison comprising either a) comparing said stored instance of said response with said further instance of said response, or b) comparing said trail with the same transformation applied to said further instance of said response; the transaction is permitted on the condition that the outputs of both the first and second validations are true; method.

2. The method of claim 1 , wherein the data store is implemented in a third-party computing facility of a trusted third party or on a peer-to-peer public medium.

3. The method of claim 1 or 2, wherein the method is performed by the verifier.

4. 4. The method of claim 1, wherein the response is the result of the challenge being input by a party other than the verifier in a setup phase preceding the method into a PUF module including a Physical Unclonable Function (PUF), the PUF module using the PUF to generate the stored response in dependence on the predetermined challenge.

5. The PUF module includes a PUF and a deterministic transformation function: - inputting a base input to the PUF to generate a corresponding base output; Inputting the challenge into the transformation function in conjunction with a generated base output to generate the response. wherein the transformation function is a function of the challenge and the generated base output. The method of claim 4.

6. The method of claim 4 or 5, wherein the party who performed the setup is the target.

7. 7. The method of claim 1, wherein the request and receiving the response are performed over a secure channel protected based on a shared secret shared between the verifier and the target.

8. 8. The method of claim 2 or any one of claims 3 to 7 when claim 2 is relied upon, wherein the data store is implemented on the third-party computer equipment.

9. The method of claim 8 , wherein the third-party computing equipment includes one or more server units at one or more geographic sites.

10. The method of claim 8 or 9, wherein the party that performed the setup was the trusted third party.

11. 11. The method of claim 8, wherein the response data is accessed from the data store of the third-party computing facility through a secure channel secured based on a shared secret shared between the verifier and a trusted third party.

12. 12. The method of claim 8, wherein the method includes receiving the challenge and the response data from the trusted third party, and wherein the request sent by the verifier includes the challenge received from the trusted third party.

13. 13. The method of claim 12, wherein the challenge is received from the data store of the third-party computing facility over a secure channel secured based on a shared secret shared between the verifier and a trusted third party.

14. 8. The method of claim 2 or any one of claims 2 to 7 when claim 2 is relied upon, wherein the data store is implemented in the peer-to-peer public medium.

15. The method of claim 14 , wherein the peer-to-peer public medium is a blockchain.

16. 16. The method of claim 15, wherein the method includes accessing the challenge and the response data from the blockchain directly from a node of the blockchain network or indirectly via one or more intermediary service providers, and wherein the request sent by the verifier includes the challenge accessed and received from the blockchain.

17. 17. The method of claim 15 or 16, wherein the response data is stored in an output of a storage transaction recorded on the blockchain, and the second verification further comprises checking that the response data has not been revoked by a further transaction recorded on the blockchain having an input that points to the output of the storage transaction, and an output result of the second verification is further conditioned on the response data not being revoked according to the check.

18. 18. The method of claim 17, wherein the response data is stored in an available output of the storage transaction, and wherein the check includes checking that the input of a further transaction does not stale the response data by pointing to the same available output.

19. 18. The method of claim 17, wherein the response data is stored in an unavailable output of the storage transaction, and wherein the check includes checking that the input of a further transaction does not cause the response data to become stale by pointing to an available output in the same storage transaction.

20. 20. The method of any one of claims 1 to 19, wherein the asset comprises one or more funding transactions recorded on a blockchain, and the transactions to be authorized comprise spend transactions that refer to the funding transactions.

21. 21. The method of claim 20, comprising providing a token to be included in a payload of the usage transaction evidenceing a result of the second verification, provided that the results of both the first verification and the second verification are true.

22. 22. The method of claim 20 or 21, wherein the first verification comprises a Simplified Payment Verification (SPV) process.

23. 23. The method of any one of claims 1 to 22, wherein the method is performed from a point-of-sale terminal.

24. a memory having one or more memory units; a processing device having one or more processing units; 24. A computer system comprising: a memory storing code configured to be executed on the processing unit, the code configured to perform a method according to any one of claims 1 to 23 when present on the processing unit.

25. 24. A computer program embodied on a non-transitory computer readable medium, the computer program being configured to perform the method of any one of claims 1 to 23 when executed on one or more processors.

Images