System and methods for PUF-based digital currency using propagation of provenance and zero trust protocols

Abstract

A digital currency where a physical unclonable function (PUF) engenders devices with the twin properties of being verifiably enrolled as a member of a legitimate set of eCash devices and of possessing a hardware-based root-of-trust. A hardware-obfuscated secure enclave (HOSE) is proposed as a means of enabling a PUF-based propagation-of-provenance (POP) mechanism, which allows eCash tokens (eCt) to be securely signed and validated by recipients without incurring any third party dependencies at transfer time. The POP scheme establishes a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminating in redemption at the token-issuing authority. A light-weight mutual-zero-trust (MZT) authentication protocol establishes a secure channel between any two fielded devices. The POP and MZT protocols, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between online and offline devices.

Description

SYSTEM AND METHODS FOR PUF -BASED DIGITAL CURRENCYUSING PROPAGATION OF PROVENANCE AND ZERO TRUST PROTOCOLSRELATED APPLICATIONS

[0001] This application claims the benefit of priority under 35 U.S.C. § 119 to U.S. Provisional Application No. 63 / 638,750, filed on April 25, 2024, the entire contents of which are incorporated herein by reference.BACKGROUND1. Field of Technology

[0002] The invention relates to digital currency. More specifically, the invention relates to a physical unclonable function (PUF)-based digital currency that leverages two security protocols for the secure and validated exchange of electronic money (eCash).2. Background of the Invention

[0003] Electronic money presents unique challenges not commonly associated with security protocols providing, e.g., a secure communication channel. An electronic money ecosystem defines a set of protocols and security properties for enabling the creation and validation of electronic cash tokens (eCt), as well as secure transfers between end-users. A typical incarnation consists of a token-issuer (TI), e.g., a central bank, a set of financial institutions (FI), e.g., commercial banks, and a consumer population. The TI defines the root-of-trust for the entire ecosystem, while the FIs provide accounting services to subsets of the consumer population.

[0003] Unlike paper money, eCash presents unique challenges not commonly associated with security protocols providing. An inherent property of paper money is anonymity, which hides the identity of the purchaser of goods and services. Anonymity also substantially reduces the barrier for adversaries to create counterfeits.

[0004] By contrast, fiat money is naturally resistant to counterfeiting, owing to the cost of the paper and inks, but copying digital representations of eCt is trivial and nearly cost-free.Similarly, dishonest users who engage in the double spending, z.e., use the same eCt to purchase goods and services from different vendors, is difficult to prevent, particularly for offline value transfer operations where users are not able to consult with a trusted-third party (TTP) (in another term, a trusted intermediate).

[0005] Supplemental to these primary goals of an eCash system is a mechanism for identifying malicious actors, who might engage in attacks on other devices or who may collude to launder money. Yet another desirable property is a mechanism to recover lost funds, which would occur if the device is lost or stolen, or is destroyed. The implementation of these supplemental servicesrequires disclosure of the user’s identity, and therefore, eCash protocols must resolve these issues through coordination across multiple TTPs, as a means of preventing abuse by the TTP themselves.

[0006] What is needed is an eCash system with robust security functions that solves the issues with current systems, while supporting forensic and recovery of loss of funds. The invention satisfies this need.SUMMARY OF INVENTION

[0007] A digital currency is introduced where a physical unclonable function (PUF) engenders devices with the twin properties of being verifiably enrolled as a member of a legitimate set of eCash devices and of possessing a hardware-based root-of-trust. A hardware-obfuscated secure enclave (HOSE) is proposed as a means of enabling a PUF-based propagation-of-provenance (POP) mechanism, which allows eCash tokens (eCt) to be securely signed and validated by recipients without incurring any third-party dependencies (such as a TTP) at transfer time. The POP scheme establishes a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminating in redemption at the token-issuing authority.

[0008] A light-weight mutual-zero-trust (MZT) authentication protocol establishes a secure channel between any two fielded devices (devices used by end-users of the eCash system). The POP and MZT protocols, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between online and offline devices.

[0009] Provided is a digital currency (eCash) system, and the system comprises: a plurality of eCash devices, a plurality of end-users, each of which exclusively uses one of the plurality of eCash devices, a token issuer (TI) that defines and provides a root-of-trust for the system, a plurality of financial institutions (FI) that provides accounting services, a plurality of trusted intermediaries that can be consulted in an on-line mode of eCash tokens (eCt) transferring to provide authentication credentials for two end-users who seek secure transfers of eCts therebetween, a physical unclonable function (PUF) primitive installed on each of the plurality of eCash devices, wherein the PUF primitive engenders the plurality of end-user devices with properties of being verifiably enrolled as a member of a legitimate set of eCash devices and of possessing a hardware-based root-of-trust, a hardware-obfuscated secure enclave (HOSE) as a means of enabling a PUF-based propagation-of-provenance (POP) protocol, which allows eCash tokens (eCt) to be securely signed and validated by recipients without incurring any third-party dependencies at transfer time, wherein the POP protocol establishes a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminatingin redemption at the TI, and wherein the HOSE is implemented as a set of state machines embedded in a hardware portion of each of the plurality of eCash devices, a light-weight mutual- zero-trust (MZT) authentication protocol, collectively implemented and facilitated by the PUF primitive, a secure hash function primitive, and a symmetric encryption algorithm primitive, establishes a secure channel between any two devices of the plurality eCash devices, wherein the POP protocol and MZT protocol, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between the plurality of eCash devices, online and offline.

[0010] In one embodiment of the provided eCash system, the PUF primitive generates a number of authentication bitstrings, encryption keys, and random nonces by utilizing within-die variations in a set of path delays as a source entropy, wherein the set of path delays are measured through an engineered netlist of shift-registers and logic gates fan-in and fan-out to create an exponentially diverse matrix of signal paths that traverse a rectangular region of a field programmable gate array (FPGA) fabric, wherein the PUF primitive incorporates a mode switch to enable the entropy source and a random number generation algorithm to be used as a true- random number generator (TRNG), which in turn supplies an exponentially large number of random nonces for cryptographic operations.

[0011] In another embodiment of the provided eCash system, the PUF primitive constructs authentication bitstring based challenges and responses by using the engineered netlist of shiftregisters and logic gates, a binary vectors database, a time-to-digital converter (TDC) control module, a multiplexer (MUX), a block RAM (BRAM), a DVDiff module, a GPEVCal module which removes variations in delays in traduced by global performance differences, a SpreadF actors module which removes delay bias introduced by differences in the length of test paths to produce an entropy optimized delay value, and a BitGen module which converts the entropy optimized delay value to an authentication bitstring.

[0012] In yet another embodiment of the provided eCash system, the TI comprises timing databases that encapsulate and compress a subset of a challenge-response space of each of the plurality eCash devices and are used by the TI to carry out mutual authentication and session key authentication with other entities in the system.

[0013] In yet another embodiment of the provided eCash system, each of the plurality of enduser devices is enrolled, by the PUF primitive, according to a pre-set enrollment operations under the MZT protocol, with the TI as a member of the legitimate set of eCash devices represented by the identifier of the device and an authentication token (AT) created using a SHA-3 secure hash function on a 256-bit long-lived key (LLK) XORed with a 256-bit nonce (n), both of which are generated by the PUF primitive.

[0014] In yet another embodiment of the provided eCash system, a first end-user (Alice) and a second end-user (Bob) of the plurality of end-users conduct an in-field process under the MZT protocol when Alice contacts Bob for goods or services in an environment where a direct communications channel is established between their respective eCash devices, wherein the infield process comprises in-field authentication and session key generation facilitated by the PUF primitives on their respective eCash device, and an authorization token database installed on their respective eCash device.

[0015] In yet another embodiment of the provided eCash system, the TI, under the POP protocol, bootstraps each of the plurality of end-user eCash devices during which, for each of the plurality of eCash devices, the TI, by using an authorization token database thereon, to generate and distribute an anonymous POP cryptographic tuple to the eCash device.

[0016] In yet another embodiment of the provided eCash system, the TI, an end-user (Alice), and an FI that Alice uses, under the POP protocol, interact to conduct a withdrawal of a fund from Alice’s account maintained in the FI, during which Alice, while remaining anonymous to the TI, is verified by the TI for her authenticity, and a plurality of anonymous eCts is generated by the TI in the case that Alice’s account is verified by the FI for having sufficient fund, and transmitted to the FI, which forward the plurality of anonymous eCts to Alice.

[0017] In yet another embodiment of the provided eCash system, a first end-user (Alice), under the POP protocol, pays a second end-user (Bob), during which Alice and Bob, under the MZT protocol, authenticate with each other by using, in part, an Alice-Bob MZT session key, Alice pays a plurality of eCts to Bob by encrypting them with the Alice-Bob MZT session key, and Alice and Bob, by using their respective POP cryptographic tuple, to authenticate and propagate the provenance of the plurality of eCts.

[0018] In yet another embodiment of the provided eCash system, a third end-user (Charlie), under the POP protocol, deposits a plurality of anonymous eCts to a FI that he uses, during which the TI is invoked to validate the provenance and validity of the plurality of eCts, the TI and the FI mutually authenticate using a timing-based authentication protocol, the FI and Charlie mutually authenticate by using the MZT protocol, and in the case of all of the plurality of eCts are validated, the FI credits Charlie’s account, and the plurality of eCts are marked as redeemed in an eCt database on the TI.

[0019] Provided is a method for using digital currency (eCash) within an eCash system that comprises a plurality of eCash devices, a plurality of end-users, each of which exclusively uses one of the plurality of eCash devices, a token issuer (TI) that defines and provides a root-of-trust for the system, a plurality of financial institutions (FI) that provides accounting services, a plurality of trusted intermediaries, a physical unclonable function (PUF) primitive installed oneach of the plurality of eCash devices, a hardware-obfuscated secure enclave (HOSE) which, as a means of enabling a PUF-based propagation-of-provenance (POP) protocol, is implemented as a set of state machines embedded in a hardware portion of each of the plurality of eCash devices, a light-weight mutual-zero-trust (MZT) authentication protocol, collectively implemented and facilitated by the PUF primitive, a secure hash function primitive, and a symmetric encryption algorithm primitive, the method comprises: verifiably enrolling, by the PUF primitive, each of the plurality of eCash devices as a member of a legitimate set of eCash devices that possesses a hardware-based root-of-trust, consulting, in an on-line mode of eCash tokens (eCt) transferring, one of the plurality of trusted intermediaries to provide authentication credentials for two endusers who seek secure transfers of eCts therebetween, signing and validating eCash tokens by recipients thereof without incurring any third-party dependencies at transfer time, establishing, by the POP protocol, a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminating in redemption at the TI, and establishing, in an off-line mode of eCash tokens (eCt) transferring, a secure channel between any two devices of the plurality eCash devices, wherein the POP protocol and MZT protocol, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between the plurality of eCash devices.

[0020] In an embodiment of the provided method, further step comprising: generating, by the PUF primitive, a number of authentication bitstrings, encryption keys, and random nonces by utilizing within-die variations in a set of path delays as a source entropy, wherein the set of path delays are measured through an engineered netlist of shift-registers and logic gates fan-in and fan-out to create an exponentially diverse matrix of signal paths that traverse a rectangular region of a field programmable gate array (FPGA) fabric, wherein the PUF primitive incorporates a mode switch to enable the entropy source and a random number generation algorithm to be used as a true-random number generator (TRNG), which in turn supplies an exponentially large number of random nonces for cryptographic operations.

[0021] In another embodiment of the provided method, further step comprising: constructing, by the PUF primitive, authentication bitstring based challenges and responses by using the engineered netlist of shift-registers and logic gates, a binary vectors database, a time-to-digital converter (TDC) control module, a multiplexer (MUX), a block RAM (BRAM), a DVDiff module, a GPEVCal module which removes variations in delays in traduced by global performance differences, a SpreadFactors module which removes delay bias introduced by differences in the length of test paths to produce an entropy optimized delay value, and a BitGen module which converts the entropy optimized delay value to an authentication bitstring.

[0022] In another embodiment for the provided method, further step comprising: carrying out, by the TI by using timing databases thereon that encapsulate and compress a subset of a challenge-response space of each of the plurality eCash devices, mutual authentication and session key authentication with other entities in the system.

[0023] In yet another embodiment of the provided method, further step comprising: enrolling each of the plurality of end-user devices, by the PUF primitive thereon, according to a pre-set enrollment operations under the MZT protocol, with the TI as a member of the legitimate set of eCash devices represented by the identifier of the device and an authentication token (AT) created using a SHA-3 secure hash function on a 256-bit long-lived key (LLK) XORed with a 256-bit nonce (n), both of which are generated by the PUF primitive.

[0024] In yet another embodiment of the provided method, further step comprising: conduct an in-field process under the MZT protocol between a first end-user (Alice) and a second end-user (Bob) of the plurality of end-users when Alice contacts Bob for goods or services in an environment where a direct communications channel is established between their respective eCash devices, wherein the in-field process comprises in-field authentication and session key generation facilitated by the PUF primitives on their respective eCash device, and an authorization token database installed on their respective eCash device.

[0025] In yet another embodiment of the provided method, further step comprising: bootstrapping, by the TI, under the POP protocol, each of the plurality of end-user eCash devices during which, for each of the plurality of eCash devices, the TI, by using an authorization token database thereon, to generate and distribute an anonymous POP cryptographic tuple to the eCash device.

[0026] In yet another embodiment of the provided method, further step comprising: conducting a withdrawal of a fund from an end-user (Alice), wherein the TI, an end-user (Alice), and an FI that Alice uses, under the POP protocol, interact to conduct a withdrawal of a fund from Alice’s account maintained in the FI, during which Alice, while remaining anonymous to the TI, is verified by the TI for her authenticity, and a plurality of anonymous eCts is generated by the TI in the case that Alice’s account is verified by the FI for having sufficient fund, and transmitted to the FI, which forward the plurality of anonymous eCts to Alice.

[0027] In yet another embodiment of the provided method, further step comprising: paying, by a first end-user (Alice), under the POP protocol, a second end-user (Bob), during which Alice and Bob, under the MZT protocol, authenticate with each other by using, in part, an Alice-Bob MZT session key, Alice pays a plurality of eCts to Bob by encrypting them with the Alice-Bob MZT session key, and Alice and Bob, by using their respective POP cryptographic tuple, to authenticate and propagate the provenance of the plurality of eCts.

[0028] In yet another embodiment of the provided method, further step comprising: depositing, by a third end-user (Charlie), under the POP protocol, a plurality of anonymous eCts to a FI that he uses, during which the TI is invoked to validate the provenance and validity of the plurality of eCts, the TI and the FI mutually authenticate using a timing-based authentication protocol, the FI and Charlie mutually authenticate by using the MZT protocol, and in the case of all of the plurality of eCts are validated, the FI credits Charlie’s account, and the plurality of eCts are marked as redeemed in an eCt database on the TI.

[0029] Features and technical benefits other than those explicitly described above will be apparent from a reading of the following Detailed Description and a review of the associated drawings. This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term “techniques,” for instance, may refer to system(s), method(s), computer-readable instructions, module(s), algorithms, hardware logic, protocol(s), algorithm(s), mechanism(s), and / or operation(s) as permitted by the context described above and throughout the document.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a schematic diagram for SiRF PUF Architecture and Algorithm.FIG. 2 is a schematic diagram for MZT enrollment and authentication process between Token Issuer, Alice and Bob (two end-users).Fig. 3 is a schematic flowchart depicting the Mutual-Zero-Trust in-field authentication and session key generation between Alic and Bob.FIG. 4 presents a high-level model of the PUF-Cash protocol.FIG. 5 presents Propagation-of-provenance (POP) database storage and challenge vector generation scheme.FIG. 6 presents PUF-Cash operations for bootstrap between the Token Issuer (TI) and Alice.FIG. 7 presents PUF-Cash message exchange for withdrawal operation between Alice, the Financial Institution (FI) and the Token Issuer (TI).FIG. 8 presents PUF-Cash operations for transfer between Alice and Bob.FIG. 9 presents PUF-Cash operations for deposit between Charlie (another end-user), the Financial Institution (FI) and the Token Issuer (TI).FIG. 10 presents a system set up for evaluating the PUF-Cash.FIG. 11 presents (a), run time performances for a certain number of eCt transferred for Withdrawal, Transfer and Deposit operations, and (b). NIST test results.FIG. 12 presents an adversarial attack model to read out device response.FIG. 13 illustrates, in a schematic block diagram, a computing environment being used in accordance with all embodiments. The environment, in all embodiments, may also include ancillary software modules (not shown, but are implicitly represented as Computer programs).DETAILED DESCRIPTION OF THE INVENTION

[0030] Various embodiments and aspects of the inventions will be described with reference to details discussed below, and the accompanying drawings will illustrate some embodiments. The following description and drawings are illustrative of the invention and are not to be construed as limiting the scope of the invention. Numerous specific details are described to provide an overall understanding of the present invention to one of ordinary skill in the art.

[0031] Reference in the specification to “one embodiment” or “an embodiment” or “another embodiment” means that a particular feature, structure, or characteristic described in conjunction with the embodiment can be included in at least one embodiment of the invention but need not be in all embodiments. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.

[0032] Embodiments of the device / method are base on a hardware security foundation that gives rise to hardware-backed security infrastructure. The authentication bitstrings, encryption keys and random nonces utilized within the proposed MZT and PUF-Cash protocols are derived from a strong physical unclonable function (PUF) called the shift-register reconvergent-fanout (SiRF) PUF. The SiRF PUF is the physical root-of-trust in the PUF-Cash ecosystem, across TI, the FI and end-user devices.

[0033] FIG 1 illustrates a SiRF PUF architecture and a couple of algorithms executed thereon (1000).3.1 SiRF PUF Architecture

[0034] The SiRF PUF utilizes within-die variations in a set of path delays as a source of entropy. Path delays are measured through an engineered netlist of shift-registers and logic gates constructed with fan-in and fan-out, referred to as reconvergent-fanout, to create an exponentially diverse matrix of signal paths that traverse a rectangular region of the FPGA fabric (22x23 CLBs). The architecture incorporates a mode switch to enable the entropy source and algorithm to be used as a true-random number generator (TRNG), which is able to supply an exponentially large number of random nonces for cryptographic operations.3.2 Challenge and Response Construction

[0035] The challenge for the SiRF PUF consists of several components, annotated as Chlnga 1004 and Chlngb 1048. The v argument to Chlnga designates a vector of bitstrings, which control the configuration of the paths through the netlist of shift-registers and logic gates. Paths are timed by the Control module 1034 via clocks 1002, which launches a set of rising transitions into the SiRF netlist 1006 using the Launch FFs. The Control module selects a path output using the MUX 1020 (multiplexer) which routes emerging signal transitions to a time-to-digital converter (TDC 1022). The TDC creates high resolution digitized representations (delay values or DVs 1030) of the path delays. The Control module carries out a sequence of path timing operations using a sequence of v vectors to produce a set of 2048 rising delay values DVR and a set of 2048 falling delay values DVF. The DV are stored in a BRAM 1036 located within the programmable logic and are used as inputs to a post-processing algorithm used to generate authentication bitstrings and keys.

[0036] The LFSR seed argument, v, of Chlnga is used to select a sequence of binary vectors, which are extracted from a VecsDB database stored locally on the device (not shown here in FIG 1 but included in the message exchange diagrams such as FIG 6’s 6028). As described later, the 32-bit LFSR seed is negotiated between the client and server, and serves a dual purpose of reducing the amount of data exchanged between client and server, and additionally obscures the sequence of challenge vectors extracted and applied during authentication from any adversaries observing the exchange.

[0037] The remaining components of the challenges are given as p, SF and HD. The p component specifies parameters to the SiRF PUF algorithm, which are used as input to a sequence of mathematical operations (1050, 1052, 1054, 1056, and 1058) applied to the 4096 DV values stored in the BRAM 1036. The first operation, carried out by the DVDiff module 1050, creates 2048 differences (DVD) by subtracting unique pairings of DVF from DVR. Note that there are 222 or 4 million unique DVD that can be generated from the sets of rise and fall DV. The LFSR seed parameter component of p specifies a single unique set of 2048 DVD to use in subsequent steps.

[0038] The DVD are then calibrated using the GPEVCal module 1052 to remove variations in delay introduced by global performance differences, as well as non-nominal temperature and supply voltage environmental conditions, with the output being calibrated DVD values, labeled DVDc. A third operation carried out by the SpreadF actors module 1054 removes delay bias introduced by differences in the length of the tested paths, which is accomplished through the application of SpreadF actors, (SF), to produce DVDco. These are then converted into an authentication bitstring or key by the BitGen module. The HD component refers to helper datathat is needed by the BitGen module 1056 for regeneration. The components of the challenge, including the SF and the helper data HD 1058 produced during enrollment, are stored in a database to enable the device to regenerate the bitstring or key at any point in the future and potentially under adverse environmental conditions. It is noted that the modules mentioned above are algorithms implemented in software programs installed on the SiRF PUF primitive or implemented in programmable logics which are part of the SiRF PUF primitive.3.3 Strong Timing-Based Authentication and Key Generation Protocol Primitives

[0039] Mutual authentication (MA) and session key generation (SKG) is accomplished using one of two low-level PUF-based protocols. The timing-based (TB) version requires ATDB 1044 and NATDB 1046 timing databases 1042 stored on the Token Issuer (TI). The timing databases encapsulate and compress a subset of the challenge-response space of each device, and are used exclusively by the Token Issuer (TI) to carry out MA and SKA with other entities in PUF-Cash ecosystem.

[0040] The TB functions utilized by the TI are annotated in the diagrams as MA I or MA^ (for mutual authentication) and SKG I or SKG^ (for session key generation). The subscript NA refers to non-anonymous mutual authentication, where the authenticating device ID, e.g., IDx, is derived privately by the TI using the NATDB. The subscript A refers to an anonymous mutual authentication, where the TI is able to confirm that the device has been provisioned, but is not able to identify the end-user’s identity.

[0041] The ATDB and NATDB are built with distinct DV 1030, and the ordering of the device timing data sets in the two databases is scrambled to generate anonymity. The SiRF PUF has 16 million unique paths that can be timed, making it possible to select large numbers of unique DV per database. For the current experiments, the number of DV per device stored in the databases is limited to 10,144 (5072 DVR and 5072 DVF).

[0042] Lighter- weight versions of MA and SKG (referred to as mutual-zero-trust or MZT) are annotated in the diagrams as MAMZT and SKGMZT . The MZT versions are based on authentication tokens, and are used between pairs of devices and between a customer device and the FI.

[0043] Additional PUF-based security functions leveraged in the proposed MZT and PUF-Cash protocols include true-random-number-generation (TRNG) and long-lived key (LLK) generation. As key generation requires reliable reproduction of bitstrings, the functions leverage three reliability enhancing techniques integrated into the SiRF PUF algorithm, namely GPEVCal, thresholding and XMR.4. Mutual-Zero-Trust protocol

[0044] Referring to FIG 2, which depicts a Mutual-Zero-Trust Protocol via a MZT enrollment and authentication process 2000 between Token Issuer (TI 2002), Alice 2004 and Bob 2006(two factitious end-users of eCash payment system).

[0045] An eCash payment system should support trusted payment transactions in any type of environment, including scenarios in which the payer and payee cannot consult with a trusted third party (TTP) to assist with authentication i.e. offline mode. In such cases, trust within the two-party system must be derived from the devices themselves. We use the term mutual-zero- trust (MZT) to describe this scenario, in contrast to environments in which peers (other customers) can be consulted to build a trusted relationship, or a TTP is available to provide authentication credentials for the two entities.

[0046] Supporting transactions which might occur between arbitrary pairs of customer devices in an offline context, where neither device has connectivity to a remote service, means that each device must store MZT data about other customer devices. The data composition must be compact to be practical for an embedded system, while simultaneously providing each device with sufficient confidence that the established channel and the counter-party device can be trusted. In this section, we describe a MZT system that meets these requirements.4.1 MZT Enrollment Operations

[0047] The security properties of the MZT protocol are derived from three primitives: the SiRF PUF primitive, a secure hash function primitive (implemented as a software module, which can be hard-wired in a hardware module such as a programmable logic) and a symmetric encryption algorithm (also implemented as a software module, which can be hard-wired in a hardware module such as a programmable logic). The PUF serves as the root-of-trust and is the source of entropy, secure hash provides obfuscation and data integrity while the symmetric encryption algorithm provides confidentiality. The integration of the three primitives provides a highly secure and lightweight mechanism for enabling Alice and Bob to communicate sensitive information.

[0048] The protocol requires the SiRF PUF to generate a 256-bit long-lived key (LLK) and a 256-bit nonce n. These bitstrings are used as input to a hash function to create an authentication token (AT), referred to as ZHK, with Z referring to zero-trust, H for secure hash and K for LLK. In our implementation, SHA-3 is used as the secure hash function. The ZHK authentication tokens are created using the relation given by Eq. 1.ZHK := Hash(LLK © n) (Equation 1)

[0049] The MZT protocol requires Alice and Bob to carry out an enrollment operation with the Token Issuer (TI). Although shown together here, enrollment is carried out separately and usually at different times by Alice and Bob.

[0050] The following sequence of operations, corresponding to the message exchange diagram of FIG 2, defines MZT enrollment.

[0051] 2008: Alice and Bob authenticate non-anonymously via MA I and generate session keys SKTA and SKTB using SKGIVA with the TI. As discussed in the section of “Strong Timing-Based Authentication and Key Generation Protocol Primitives”, Alice and Bob use the TB versions of these security functions since they are interacting with the TI. Non-anonymous authentication allows the TI to identify Alice and Bob as ID A and IDB, respectively. Note that the MANA protocol is privacy-preserving, z.e., the TI derives the IDs based on the responses provided by Alice and Bob.

[0052] 2010: The TI encrypts and then transmits unique challenges to Alice and Bob, labeled ChlngzTa and ChlngzTb respectively.

[0053] 2012 and 2014 respectively: Alice and Bob decrypt and apply their respective challenges to their hardware PUFs, HPUFE, in enrollment mode, to generate a long-lived key, LLKMZT, and helper data HD. Alice and Bob store the challenge information in the MZT LLKDB under challenge number CNi, which includes the components discussed earlier in reference to FIG 1, z.e., vl, pi, SFi and HDi, to enable regeneration of LLKMZT later in the field. As noted above, vl is a 32-bit LFSR seed used to select binary vectors from the VCCDB stored locally on Alice and Bob’s devices.

[0054] 2016: Once the LLKMZT is generated, the TI sends a request to Alice and Bob to generate x ZHKs.

[0055] 2018 and 2020 respectively: Alice and Bob construct a set of tuples {ZHKi, ni} by running their PUFs’ TRNGs to generate a sequence of nonces, ni, which are XORed (z.e., exclusive OR, is a logical operation that returns true if and only if one, but not both, of its inputs is true. In other words, XOR is true when the inputs are different, and false when they are the same.) with LLKMZT and used as the input to the AT creation function given by Eq. 1.

[0056] 2022 and 2023: The tuples are encrypted using SKTA or SKTB and transmitted to the TI. The TI decrypts and stores them along with the field device’s identifier ID A and IDB in its MZT ATDB.

[0057] The TI collects ZHKi from all field devices to build the MZT ATDB. Each entry consumes only 72 bytes, consisting of a 4-byte integer for the IDr and CNx fields, and 32 bytes for each of the ZHKi and m fields. Alice and Bob will retrieve one unique ZHKi tuple from the TI for each device during the distribution operations, labeled as steps 7 through 10 (2024, 2026,2028, 2030, 2032, and 2034) along the lower portion of FIG 2, which they store in their MZT ATDB databases. Note that the protocol and database structure support multiple challenges, e.g., Bob stores ZHKi for a second challenge number, CN2, in his ZHKi. The MZT ATDB database can be stored in a standard off-the-shelf NVM (Non-Volatile Memory), e.g., SD card, where storage capacities of 4 GB or larger are common. Elements within the MZT ATDB could be encrypted for additional security, and processing may be carried out in the hardware-obfuscated secure enclave (HOSE) on the device.4.2 MZT in-field operations

[0058] The MZT in-field process is carried out when Alice contacts Bob for goods or services in an environment where a direct communications channel is established between the two parties. The message exchange protocol is shown in FIG 3, and is described as follows.

[0059] Referring to FIG 3, which schematically shows MZT in-field authentication and session key generation 3000 between Alice 3002 and Bob 3004, it has 8 steps:Step 1 (3006): The transaction begins with Alice sending Bob a request to authenticate and to generate a shared session key.Step 2 (3008): Alice sends Bob an identifier, IDA, that allows Bob to locate the corresponding AT in his MZT ATDB.Step 3 (3010): Bob responds to Alice with an ACK or NAK (labeled status) on whether or not he possesses an AT for Alice. He also transmits his own identifier, IDB.Step 4 (3012): Alice determines if she has an AT for Bob in her MZT ATDB using Bob’s IDB, and transmits a corresponding ACK or NAK to Bob in the status message.Step 5 (3014): Assuming both Alice and Bob have ATs for each other (otherwise the transaction is cancelled), Alice and Bob retrieve the AT for the other party from their MZT ATDB, which is represented by the tuple ZHKX, nxwith x := b or a, respectively.Step 6 (3016) Shared Key Generation: Alice and Bob exchange the nonce components, nx, of the ATs. Both parties regenerate their long-lived keys LLKMZTX using challenge information stored in their MZT LLKDB (not shown), and then compute a local version of the ZHKX' using Hash(LLKMZTX© nx). Alice and Bob create a shared key SKAB by XOR’ing the local copy of ZHKX' with the ZHKXthat they store for the other party in their MZT ATDB.Step 7 (3018) Authentication: Authentication begins with Alice and Bob encrypting the nxthey received from the other party with the newly created shared key SKAB to create enx. Alice and Bob exchange the encrypted nonces enx. They decrypt the enxusing the shared key and then compare the decrypted nxwith the ones they store in their MZT ATDB. The status of the comparison is shared with the other party with each transmitting an ACK or NAK. At thispoint, they have authenticated and possess a shared key assuming both have acknowledged that the nonces nxmatch their own local copies.Step 8 (3020): Refresh ZHKs: Alice and Bob generate new nonces nx nby running their TRNGs, and then compute new AT by hashing (LLKMZTX® nx n). They encrypt the new AT as Cxwith their shared session keys SKAB. They exchange the Cx, and then decrypt the Cxto recover the new AT. They store the new AT in their MZT ATDB, replacing the existing AT used in this transaction.

[0060] The MZT in-field operations are light-weight using only the PUF, secure hash, and symmetric encryption functions. The refresh operation ensures that future transactions can occur between the two parties without either party needing to return to the TI to obtain additional AT. The new AT are generated by Alice and Bob’s PUFs and therefore have the same strong security properties as the original AT that are replaced. The protocol is not subject to desynchronization attacks in which an adversary prevents, e.g., Alice from receiving C2, because Bob does not record state information that Alice stores in her MZT-ATDB. If C2 is not received, then the refresh operation is not performed. Section 8 expounds further on the protocol’s security properties.5. PUF-CASH PROTOCOL

[0061] The operating environment used in the PUF-Cash protocol described here is characterized as offline, requiring Alice and Bob to authenticate using the MZT model. By assuming a bilateral, peer-to-peer trust model, we ensure that two parties can transact regardless of the underlying communications medium.

[0062] Additionally, transitivity of eCt tokens across multiple parties is supported, where transitivity means that a token can be transferred to a new party without requiring synchronization with the token issuer (TI) or any other back-end system. PUF-Cash introduces a novel security primitive called propagation-of-provenance (POP) and a hardware-obfuscated secure enclave (HOSE) as a means of ensuring transitivity in a secure manner. The HOSE prevents Alice from double spending her own eCt. POP and HOSE together enable each party in a chain of eCt transfers to authenticate the eCt that they receive, and to validate provenance back to the point of origin, namely the TI.

[0063] The HOSE is implemented as a set of state machines embedded in a hard-wired portion of the device, or, in the case of FPGAs, in the programmable logic. The HOSE limits interactions and potential attacks from malicious software applications, including the PUF-Cash software components, through an interface consisting of two 32-bit hardware registers. The HOSE incorporates the SiRF PUF for generating keys on-the-fly as needed. Similarly, allsensitive cryptographic operations, specifically AES encryption / decryption and the SHA-3 hash function, are instantiated in the HOSE.5.1 PUF-Cash Overview

[0064] Referring to FIG 4, which schematically depicts a high-level overview of PUF-Cash to highlight the basic operations (bootstrap, withdrawal, MZT authentication and key generation, transfer, and deposit - see 4000). The sequence of numbered operations are described as follows:

[0065] The bootstrap operation (4008) within the PUF-Cash protocol generates and distributes a set of anonymous POP cryptographic tuples (POPx) to customer devices, Alice 4006, Bob 4004, Charlie 4002, etc. The set of POPx are generated as customer long-lived keys using the TFs ATDB, and are therefore anonymous to the TI.

[0066] Alice contacts her FI and requests (4010) a withdrawal from her account, sending the tuple {Amt, IDA, AIDA}, which includes both her non-anonymous ID for the FI and her anonymous AID for the TI. The FI checks her balance (4026) and responds with an ACK (not shown) if she has sufficient funds or a NAK if she does not.

[0067] Assuming Alice has sufficient funds, the FI forwards the Amt and AIDA to the TI (4012) to generate the eCash tokens (eCtA). The TI fetches (4040) Alice’s anonymous POPAfrom the POPDB (4034) using her AIDA, and adds (4038) a withdrawal record to its eCtos database (4032).

[0068] The TI generates the eCtA using a TRNG, and creates signed versions, heCtA, using Alice’s POPAin a XOR-secure-hash operation similar to Equation 1 listed above. The TI then encrypts both of the eCtA and heCtA as ECtA using a shared session key that is created between Alice and the TI anonymously (not shown here but included in message exchange diagrams below), and transmits the ECtA to the FI (4014).

[0069] The FI simply forwards (4016) the ECtA to Alice. The FI, acting as an intermediary, keeps Alice and her eCtA anonymous to the TI. Moreover, her ECtA are also anonymous to the FI because they are encrypted with the Alice-TI session key.

[0070] Alice contacts (4018) Bob for a payment transaction, and then both run the MZT protocol as depicted in FIGs 2 and 3.

[0071] Assuming authentication succeeds, Alice pays (4020) Bob with (a subset of) her ECtA by encrypting them with the Alice-Bob MZT session key. Although not shown here, Alice and Bob use their POPx to authenticate and propagate the provenance of the eCt. The MZT security functions and ECtx transfer operation can be repeated between other pairs of customers, shown here between Bob and Charlie (4022 and 4024).

[0072] At some point in the future, Charlie regains internet connectivity and deposits (4027) the ECtcto his FI. Note that although Alice and Charlie use the same FI as shown, this is not a requirement.

[0073] The FI contacts the TI and asks the TI to validate (4039) the ECtc, as a precursor to the FI accepting the ECtc as a valid deposit.

[0074] Assuming validation succeeds, the FI credits (4028) Charlie’s account, and although not shown, the ECtn are marked as ’redeemed’ in the TI’s eCtz^.5.2 Propagation of Provenance (POP) Qualities

[0075] Referring to FIG 5 (which shows POP database storage and challenge vector generation scheme 5000), the TI uses a specialized process to create the entire set of POPxfor each of the customers’ POPDB (distributed in Step 1 of FIG 4) that significantly reduces the storage requirements for the challenges. The POPx transmitted to Alice and Bob’s device is composed of two components, a population-based component (PBC) and a device-specific component (DSC), each stored in two different databases labeled POPADB and POPBDB in FIG 5. The PBC component is used for all devices in Alice’s POPBDB, and is defined as the tuple (vx, SFX) (5008). The vxcomponent is a 32-bit LFSR seed that selects, via a Vector Select Module 5004, the actual vectors vecsxfrom a separate database called VCCDB (5002) while SFXrepresents a set of SpreadF actors for optimizing POP key generation (from the previous section).

[0076] The DSC components are stored in the POPBDB (5010), one element for each device, and are defined as a tuple (AID , px, ePOPx, HDX) (5012). The AID is a 32-bit integer representing a device’s anonymous ID, the pxcomponent is a 22-bit nonce used to specify the seeds to the LFSRs in the DVDiffs module from Section 3, the ePOPx is the encrypted P F’s response to the challenge for device (256-bits), and HDxis the helper data (2048-bits). Therefore, the size of each POPBDB element is 296 bytes, and is larger than the MZT ATDB which requires only 74 bytes per device entry.

[0077] The primary benefit of the larger POP database is related to the strength of the authentication process. The challenge information stored by Alice for, e.g., Bob’s device, requires Bob’s device to generate the response to Alice’s stored challenge, and the challenge that Alice’s stores (at least initially) has not been exposed a priori to Bob’s device. This is true because the TI provides Alice with Bob’s response to this challenge (as the ePOPn component) by running a ’soft PDF’ version of the SiRF PDF algorithm using the anonymous timing data stored in the ATDB. The soft PDF is able to produce the same response that Bob’s device generates for this challenge.

[0078] Moreover, Alice is able to refresh Bob’s entry in her DB after every engagement with Bob in two different ways. In one scenario, Alice generates a new challenge for Bob’s device bychanging the pn component (LFSR seeds) in POPBDB, and then asks Bob to generate a new response. She then replaces the DSC component of Bob’s entry in her POPBDB with the new information. In the second scenario, Alice authenticates with the TI and asks the TI to perform this operation. Although this requires Alice to be online, it prevents Bob from seeing Alice’s next challenge for him.5.3 PUF-Cash Protocol Details

[0079] The message exchange diagrams for the four PUF-Cash operations are described in this section. The Bootstrap operation (illustrated in FIG 6) is carried out after device manufacture, and at any point in the field under the condition that Alice is online, z.e., has internet connectivity. Once Alice has engaged the TI in a bootstrap operation, she can perform any one of the three primary PUF-Cash operations: Withdrawal (illustrated in FIG 7), Transfer (illustrated in FIG 8), and Deposit (illustrated in FIG 9). Note, her very first transaction must be a Withdrawal. All transactions with TI are preceded with MA, e.g., MAM, and SKG, e.g., SKG I. SKG produces a shared key SKX, where is replaced with the initials of the authenticating parties, e.g., SKTF refers to the shared session key between the TI and FI.Although the details of TB security functions are presented in previous work, the enrollment and regeneration functions for the POPBDB are similar and are outlined in Section 8.2 for completeness.5.3.1 Bootstrap.

[0080] The message exchange diagram for Bootstrap is shown in Fig. 6. The sequence of operations performed by Alice and the TI are numbered within circles in the figure. The shaded regions identify operations carried out within the HOSE, z.e., the programmable logic region of the FPGA.

[0081] Referring to FIG 6 that illustrates PUF-Cash bootstrap operations (6000) between the Token Issuer 6002 and a user Alice 6004.Step 1 (Generate LLKhose 6006): Alice and the Token Issuer (TI) mutually authenticate and generate a shared session key, SKTA. Mutual authentication is done anonymously. Upon successful authentication, the TI affirms that Alice’s device is a genuine SiRF-instantiated PUF device with anonymous ID, AIDA.Step 2 (6008): The TI generates random values for vhose and phose to enable the TI and Alice to enroll and regenerate, respectively, a long-lived key, LLKhose. The LLKhose will be used by TI and Alice to encrypt and decrypt POP data. The term vhose is used as the seed to pseudo-randomly select vectors, e.g. vecsxfrom the VCCDB (6028), as shown in FIG 5, and phose specifies the LFSR seed for the SiRF PUF DVDiff module. The anonymous timing data, DV, for a random subset of devices corresponding to paths timed by vecsx, is extracted from the ATDB (6030) and used togenerate a set of SpreadF actors, SFhose. The TI runs a software version of the SiRF PUF in enrollment mode, SPUFE, which produces the LLKhose key and the HDhose helper data.Step 3 (6010): The TI encrypts the tuple (vhose, SFhose, phose, HDhose) with its session key SKTA as Ci and transmits it to Alice. Alice decrypts Ci and inserts the challenge data into her HOSEDB 6032.Step 4 (6012): Alice reads the challenge information from her HOSEDB and runs her hardware PUF in regeneration mode, HPUFR, to produce LLKhose.Step 5 (6014 Generate POP): The TI generates a set of POP elements for a set of devices from the population by first generating random values for VA and pA and extracting a set of vectors vecsA. It then extracts the timing values, DV, for a random subset of devices from ATDB 6030 corresponding to vecsA. GenSF is called to generate the SpreadF actors, SF+A, for all possible DVD, that can be created from the selected 2048 DV / ? and 2048 DV / - . From the discussion in Section 3.2, the D V ? and DVz-can be paired in 222possible ways to create unique DVD. Therefore, the size of SF+A 1S 4 million bytes. This enables Alice to refresh her POP challenge and response information after a successful transfer operation with any device in her POPDB.Step 6 (6016): The TI generates a set of 256-bit POPi responses to the challenge for a set of devices zz, using the DVi corresponding to each of the devices i. Alice’s response, POP A, is stored in the verifier’s ATDB for signing and validating eCt during withdrawals and deposits, respectively.Step 7 (6018): The challenge components, VA and SF+A, and the tuple sets {AID / ?, pA, POPn, HDn} are encrypted with Alice’s LLKhose by the TI. The POPA component in Alice’s tuple is set to null.Step 8 (6020): The TI sends the encrypted packet CL to Alice, which she decrypts within her HOSE. She stores the VA and SF+Ain her POPADB 6034. These components of the challenge are used for all customers she interacts with.Step 9 (6022): She then creates separate records for each of the customers / in the POPBDB database 6034 and stores the AIDi and HDi components. The PA component is replicated in each database record and will be used as the initial value during the first eCash transaction with a customer.Step 10 (6026): The POPi are re-encrypted with Alice’s LLKhose and stored as ePOPi. This protects the customer responses in the event an adversary gains access to Alice’s device and attempts to extract information from the POPBDB 6034. Note that Alice’s ePOPi does not need to be stored (is null) because she can regenerate it with her PUF.

[0082] The size of the subset of DV extracted from the ATDB and used as input to GenSF in Step 5 needs to be large enough to characterize the entire population. In our implementation, we usesets of DV corresponding to 30 customers. The subset of the customer population for which the TI creates POPi for Alice in Step 6 can be selected by Alice’s device from preferences she specifies in advance, or learned over time from online eCash transactions she engages in.5.3.2 Withdrawal

[0083] Referring to FIG. 7, it shows the following series of message exchanges and cryptographic operations 7000 are carried out between Alice 7006, the FI 7004 and TI 7002 to enable Alice to obtain a set of anonymous eCt for payment transactions with end-users or commercial vendors.Step 1 (7008): The TI and FI mutually authenticate and generate a session key, SKTF using the non-anonymous TB protocol primitives.Step 2 (7010): The FI and Alice mutually authenticate and generate a session key, SKFA, using the MZT protocol primitives.Step 3 (7012): Alice creates a ciphertext packet, Ci, containing her anonymous ID called AID A, and requested withdrawal amount, Amt, and sends the packet to FI.Step 4 (7014): FI decrypts Ci with SKFA, checks Alice’s balance and responds to Alice with an ACK if she has enough funds in her account, or a NAK if she does not.Step 5 (7016): If the response is ACK, the transaction continues (otherwise it is cancelled) with FI encrypting AIDA and Amt as C2 and transmitting the packet to TI. TI decrypts C2.Step 6 (7018): TI and Alice generate a session key SKTA using procedure SKGA (which utilizes the anonymous timing database). The FI serves as a pass-through intermediary. The SKGA process is nearly identical to the Generate LLKhose (Step 2 of Bootstrap) where the TI generates a challenge, runs SKTA := SPUFE (z.e., assigning SPUFE to SKTA) and sends the challenge and helper data encrypted to FI (not shown). The FI forwards the packet to Alice, and Alice decrypts and regenerates SKTA by running her hardware PUF in regeneration mode. Note that Alice remains anonymous to TI because the TI draws the challenge and DV from ATDB 7038 using her AIDA.Step 7 (7020): The TI extracts Alice’s POPAfrom the ATDB using her AIDA.Step 8 (7022): The TI generates a set of eCtA using its GenNonce() function, equivalent to one 256-bit nonce for each 1 cent token of Alice’s requested Amt, and records the eCtAin its eCtDB 7046 along with her AIDA and POPA. The latter two components can be used for recovering lost funds and tracking malicious actors, but are otherwise not needed.Step 9 (7024): The TI creates signed versions of the eCtA, labeled as heCtA, by XORing each eCtA with POPA, and then hashing the result. The eCtA and heCtA are then encrypted with POPA to prevent observation or manipulation attacks from the processor-side. The encrypted versions, ECtA, are encrypted again with the TI-Alice session key, SKTA, in a packet C3. Thedouble encryption adds an additional layer of obscurity to the FI and to network packet eavesdropping.Step 10 (7026): The TI transfers C3 through the FI to Alice, who decrypts C3 to recover the ECtA and passes them to the HOSE for processing.Step 11 (7028): Alice’s HOSE fetches challenge information from the POP DBs as ChlngAa, and runs Alice’s hardware PUF in regeneration mode, HPUR, to reproduce POPAa. The subscript Aa should be read as "Challenge for Alice from Alice". The ECtA are then decrypted and validated by the HOSE. Validation is accomplished by recreating the signatures, heCtA , using the eCtA and the locally generated POPAa, and comparing them with the received versions, heCtA.Step 12 (7029): If any of the signature comparisons fail, then the process is aborted. Otherwise, Alice updates her challenge to ChlngAa by incrementing the PA component, and then running HPUFE to generate a new POPAa . She updates her POPBZV? record with pA and HDA , and creates new signatures heCt*A for the eCtA. She encrypts the eCtA and heCt*A and adds the new ECtA to her eCtDB 7046. She also re-encrypts any existing elements with the new POPAa . This type of key rolling scheme reduces the likelihood of a successful differential power analysis attack carried out on Alice’s device.Step 13 (7030): If the previous step succeeds, Alice encrypts the new POPAa with the original POPAa as C4, and then sends an ACK with the C4 to TI through the FI. Otherwise, she sends a NAK only.Step 14 (7032): If FI receives an ACK, it updates the AcctDB by deducting the Amt from her account.Step 15 (7034): If TI receives an ACK, it decrypts C4 with POP \ to recover POPAa . The TI updates Alice’s POP in its ATDB database 7038 with the new version. If a NAK is received, it removes the eCtA.

[0084] It is noted that in some of the above steps, various databases (VCCDB 7036, ATDB 7038, AcctDB 7040, POPBDB 7044, eCtDB 7046) are get involved.5.3.3 Transfer

[0085] Referring to FIG 8, it shows that the PUF-Cash protocol supports the transfer of eCt 8000 between offline entities, as illustrated by the message exchange diagram for two devices labeled Alice 8002 and Bob 8004. The transfer protocol is carried out exclusively between Alice and Bob, and is transitive, z.e., Bob can pay Charlie (not shown), etc.Step 1 (8006): Alice sends Bob a request to transfer Amt to Bob. Bob accepts the transfer request. Alice and Bob mutually authenticate and generate a session key, SKAB, using MZT protocol.Step 2 (8008): Bob extracts a challenge from his POP DBs, with subscript Ab indicating "Challenge for Alice from Bob". Bob encrypts the challenge Chings with his session key SKAB as Ci and transmits it to Alice.Step 3 (8010): Alice decrypts Chings and passes it into her HOSE. Alice’s HOSE fetches Chings and regenerates both POP Aa and POP Ab by running HPUFR. Alice then fetches a subset of her encrypted ECtAfrom her eCtDB 8032 and decrypts it with her regenerated POPAato recover the tuple {eCtAs, heCtAs}. Following that, she validates the database stored eCtAs by creating heCtAs with POPAa and compares them with the heCtAs extracted from the database. The process is aborted if a mismatch is detected. If not, the eCtAs subset is signed with POP Ab as heCt*As, and the tuple, ECtAs , is encrypted with AES using POP Ab as the secret key. The re-signing of Alice’s eCt with a key that Bob stores and only Alice can generate is a key feature of the scheme.Step 4 (8012): Alice encrypts the ECtAs with SKAB as C2 and transmits it to Bob, who decrypts and transfers it to his HOSE.Step 5 (8014): Bob regenerates his LLKhose and POPBb using challenges from the HOSE^ and POP DBs, respectively. He uses his LLKhose to decrypt Alice’s ePOPA as POP Ab, and then uses POP Ab to decrypt ECt’ As to recover Alice’s eCtAs and heCt*As. He validates them by creating heCt’As and comparing with heCt*As received from Alice.Step 6 (8016):Bob records the result of the validation process as Resp := ACK or NAK. Bob also updates Alice’s challenge by randomly modifying the PA parameter in his POPBDB to produce a new challenge, ChlngAb . He encrypts the Resp and the new challenge with POP Ab as C3 and transmits it to Alice.Steps 7.1 (8018) and 7.2 (8020): Alice transfers C3 into her HOSE, decrypts and aborts if the Resp is NAK. Similarly, Bob aborts if Resp is NAK. Otherwise, Alice removes the spent tuples {ECtAs, hECtAs} from ECtAand stores the updated ECt*Aback to her eCtDB.Step 8 (8022): Alice generates a new response, POPAb , using the new challenge, ChlngAb , encrypts it along with the new helper data HDA using the original POPAb as C4 and transmits it to Bob.Step 9 (8024): Bob hashes Alice’s eCtAs as heCf’As and encrypts them with the eCtAs using his POPBb as ECtB, which he stores to his eCtDB. He then decrypts C4 to recover Alice’s POP’ Ab and HD’A. Bob encrypts POP’Ab with his LLKhose as ePOP’A, and updates his POPBDB with the new challenge (PA ), encrypted response CPOPA and helper data HDA .

[0086] It is noted that in some of the above steps, various databases (HOSEDB 8030, POPADB 8028, POPBDB 8026, eCtDB 8032) are get involved.5.3.4 Deposit

[0087] Referring to FIG 9, it shows the deposit operation that involves the TI 9002, FI 9004 and an end-user device, e.g., Charlie 9006, where anonymity is preserved between the TI and Charlie. The steps are described in the following numbered sequence.Step 1 (9008): The TI and FI mutually authenticate and generate a session key, SKTF, using the TB protocol.Step 2 (9010): The FI and Alice mutually authenticate and generate a session key, SKFA, using MZT protocol.Step 3 (9012): Charlie fetches challenge information and runs his hardware PUF to regenerate LLKhose and POPec. Charlie selects a subset of his ECtc and then decrypts them using his POPec as eCtcs and heCtcs. Charlie then validates his eCt and aborts if validation fails.Step 4 (9014) and Step 4.1 (9016): Charlie constructs a packet consisting of his AIDc, Amt and ECtcs. The packet is encrypted with SKFA as Ci, and transmitted to the FI. The FI recovers the elements in Ci, re-encrypts them with SKTF as C2 and transmits them to the TI.Step 5 (9018): The TI decrypts C2 to recover AIDc, Amt, and the corresponding tokens ECtcs. It then reads POPc from ATDB using AIDc, and decrypts the ECtcs using Charlie’s POPc.Step 6 (9020): The TI searches for each of the eCtcs in the master eCtDB and checks if they are marked valid, i.e., still in circulation. If all eCtcs are valid, then signatures are created using Charlie’s POPc as heCtAs. For convenience, it is assumed that some of the tokens in Charlie’s possession were originally withdrawn by Alice (eCt \), to show the complete cycle for any given eCtA.Step 7 (9022): The TI assigns Resp := ACK if all (Amt) of the eCt and heCt validation processes succeed, and NAK otherwise. The TI encrypts Resp as C3 with SKTF and transmits it to the FI.Step 8 (9024): FI decrypts C3, records Resp, re-encrypts Resp with SKFA as C4, and transmits it to Charlie.Step 9 (9026): Charlie’s HOSE decrypts C4 and aborts if Resp is a NAK. Otherwise, he deducts the deposited subset of eCt and heCt from his database and generates a new challenge and corresponding POP ' cc. He encrypts and stores the new ECtc element to his eCtDB, and re- encrypts other elements in his database with the new POP <^if any exist. He encrypts POP ' cc as Cs using the original POPec and transmits it to FI.Step 10 (9028): Once FI receives Cs, if Resp == ACK, it credits Charlie’s account with Amt.Step 11 (9030): Once TI receives Cs and Resp == ACK, it marks all of Charlie’s eCt as invalid (redeemed) in the eCtDB. Otherwise, it aborts.Step 12 (9032): If Resp != NAK (Resp is not equal to NAK), the TI decrypts Cs and updates Charlie’s POP in its ATDB.

[0088] It is noted that in some of the above steps, various databases (HOSEDB 9036, POPADB 9040, POPBDB 9042, eCtDB 9044, ATDB 9038, and AcctDB 9046) are get involved.6. System Setup

[0089] The present system contains hardware and software, and their run-time overheads associated with the implementation of the PUF-Cash protocol on our test bed are analyzed.

[0090] Referring to FIG 10, it shows a test bed 10000 consists of one server and three devices. The token issuer (TI) 10002 is implemented on a Dell PowerEdge T440 Server with 32 1.8 GHz processors and 128 GB of main memory. The financial institution (FI) 10006, Alice 10008 and Bob 10010 run on a set of Digilent ZYBO-Z7 boards 10012, which utilize Xilinx Zynq 7010 SoCs. The processor system (PS) incorporates a 667 MHz dualcore Cortex-A9 processor, which has access to 1 GB of DRAM and a 1 Gbit / sec ethemet port. The programmable logic side (PL) has 17,600 LUTs and 240 KB of PL-side block RAM (BRAM). TI, FI, Alice, and Bob devices are interconnected via a network switch 10004.

[0091] The TI and FI applications are implemented as multi -threaded C programs, while customer device applications are single-threaded. The FI and device implementations are codesign applications, where network and database functions are implemented in C on the PS, while encryption, secure hash, SiRF PUF authentication bitstring and key generation functions are implemented as state machines in the PL. The TI emulates the SiRF PUF in software. The server and devices are connected to a network switchl0004 with 1 Gbit / sec of available bandwidth.

[0092] Various databases (HOSEDB 10016, eCtDB 10024, POPDB 10026, MZT_ATDB 10018, ActDB 10020, ChlngDB 10022) are involved in the analysis to test, in part, the database size overhead.Table 1. PL-side resource utilization on the Zynq 7010

[0093] The PL resources used by the SiRF PUF Engine and SiRF PUF netlist (Entropy source) are given in Table 1. The percentage of resources used by all SiRF PUF components is shown in the 4th column. The overheads of other components of the HOSE, z.e., AES and SHA-3 cryptographic functions, are also presented in columns 5 and 6. The LUT row shows that SiRF PLTF utilization is 37.72%, while utilization of the cryptographic functions is slightly larger at 39.41%. However, the two 32-bit multipliers and 20 KB BRAM used by the SiRF PLTF, which are mapped into hardwired components on the FPGA, will make the SiRF PUF larger than the cryptographic functions in an ASIC implementation.Database Size Overhead.Table 2. Database Size Overhead

[0094] The TI, FI and field-device applications utilize the sqlite3 database management software. The database size overheads for each of the databases shown in Fig. 10 are given in Table 2, with CD used as an abbreviation for the customer device. The TI stores SiRF provisioning data in the NATDB and ATDB for 140 ZYBO devices, each with 5072 DVR and 5072 DVR records (Rec), which supports a challenge-response space of more than 224 bits per device (Note that the entire CRP space is 235 bits per device using the SiRF netlist configuration shown in FIG 1, which is discussed further in Section 8.1). Although each DV can be represented as a 16-bit fixed point integer with 4 digits of precision, indexing and other bookkeeping within the database engine increase the size to 60 bytes per DV record. Therefore, with 10,144 DV per device, the total storage is 594.3 KB per device. The right-most column shows the total size of these databases after populating them with provisioning data from 140 FPGAs.

[0095] The ChallengeDB, utilized by all entities in the PUF-Cash system, is 1 MB in size. Individual record sizes within the MZT ATDB is given as 80 bytes per entry. From FIG 2, a record consists of a 32-byte ZHK and nonce, and two 4-byte integers, leaving 8 bytes for database overhead. Assuming each device stores a record for 140 other devices in the population, the overhead is 10.9 KB.

[0096] The POPDB is composed of two component tables. The POPADB stores 4 MB of SF, which is used for all customers, and is therefore fixed in size. The POPBDB record size is 296 bytes, leading to a size overhead of 40.5 KB assuming each device stores data for 140 other devices. Combined with the fixed overhead of the POPADB, the storage per device is 4.04 MB. The size of the challenges stored in the MZT and HOSE DBs is small at 4.6 KB per device. The total overhead for a CD is the sum of the last four rows, and is slightly larger than 5 MB.7 EXPERIMENTAL RESULTS

[0097] Hardware experiments are used measure the performance of the PUF-Cash protocol operations. In each experiment, the timing information is collected as the protocol executes the withdraw-transfer-deposit sequence using an increasing number of eCts of sizes 1, 5, 10, 50, 100, up to 500,000, for a total of 12 sequences. In each sequence, the entire set of tokens are processed through all operations, thereby tokens are created, transacted and deleted, leaving the database in an empty state at the beginning of the next sequence. In addition, the POP LLKs generated in each experiment are stored to a file to allow an assessment of their statistical quality. The experiment as described is performed 40 times for statistical significance and to determine the limits on the transfer times.7.1 Run Time Analysis

[0098] The processing and transfer times associated with the withdrawal, transfer and deposit operations within the PUF-Cash protocol are plotted in FIG 11(a) 11002. The processing times, and 3<J limits, are plotted as a function of the number of eCt processed. The run times include the time taken to complete all operations specified in the message exchange diagrams, including the network transfer times between devices.

[0099] The processing time of all three operations is linear with respect to the number of tokens. The transfer operation, which occurs exclusively between Alice and Bob’s devices, possesses the largest processing time overhead. This is due largely to the limited processing capability of the devices. The processing times associated with the smaller value transfer operations, e.g., from 1 cent to 10,000 ($100), are upper bounded at approximately 6 seconds. Processing times for amounts larger than 10,000 begin to diverge, but remain less than 20 seconds up to 100,000 eCt ($1000). These processing times are competitive with existing state of the art payment systems where settlement occurs at the end of the transaction.Table 3. SiRF PUF Primitive Run Time Analysis. Mean and ±3<J values are given. All times in seconds (s).

[0100] Table 3 gives mean run times and 3<J limits for the timing-based (TB) authentication and key generation operations. The mean time for each operation is less than 1 second for all operations except LLK Enroll. Table 4 gives the run time for the Bootstrap operation carried out at device startup.Table 4. PUF-Cash Primitive Run Time Analysis. Average transfer times per 100 elements plus fixed overhead time. All times in seconds (s).

[0101] (see FIG 6). The value given corresponds to the total transfer time for 100 POPx elements, which includes a fixed overhead of 3.5 seconds. The transfer times correspond to approximately 17 POPx per second. MZT enrollment time (also performed during Bootstrap) translates to approximately 4000 MZT authentication tokens per second, with a fixed overhead of 3.0 seconds. A typical sequence performed at startup includes DA, VA, SE, two LLK regeneration operations and the Bootstrap and MZT Enroll operations. The authentication and key generation operations (DA, VA, SE and LLK Regen) take approximately 4 seconds. For 100 POP LLKs and MZT ATs, the total startup time is 4 + 9.4 + 3.025 = 16.36 seconds.7.2 POP LLK Statistical Analysis

[0102] In this section, we assess the statistical quality of the LLKs generated during runs of the PUF-Cash protocol. The MZT protocol utilizes only one LLK in the protocol, and therefore nearly all of the LLK analyzed are produced by the POP protocol.

[0103] The message exchange diagrams for withdrawal, transfer and deposit shown in FIGs 7, 8 and 9 incorporate LLK refresh operations, which are annotated as POP'ry. In each withdraw- transfer-deposit sequence, Alice generates a new LLK for herself during withdrawals and a second new LLK on behalf of Bob during transfers, and Bob generates a new LLK during deposits. Therefore, during the execution of the 12 sequences in each experiment, 36 LLKs are generated. The 40 repeated runs of the experiment yield a total of 1440 256-bit LLKs.

[0104] The 1440 LLKs are used as input to the NIST statistical test suite. Given the limited size of the bitstrings (256 bits), only six of the NIST statistical tests are applicable, as shown in FIG 11(b) 1104. The minimum pass threshold for a set size of 1440 bitstrings, and with a set to the default value 0.01, is 1414. All six tests passed, with the Runs test representing the worst-case pass, i.e., at 1418 passing bitstrings.

[0105] Inter-bitstring Hamming distance (Inter-HD) is commonly used to measure uniqueness among the bitstrings. Inter-HD is computed by pairing bitstrings under all combinations andthen counting the number of bits that differ in each pairing. The ideal result occurs when half of the bits in any pairing of the bitstrings differ. (Equation 2)

[0106] Equation 2 gives the expression for Inter-HD for a pair of devices (i, j) of length |bs| = 256 bits. Inter-HD is computed across all possible pairings of 1440 bitstrings, i.e., 1440*1439 / 2 = 1,036,080 combinations, and averaged. The mean Inter-HD is 49.9992%, which is very close to the ideal value of 50%. No failures of any type were observed in LLK regeneration over the 8+ hour run of the experiments.8. SECURITY ANALYSIS

[0107] The TB authentication, session key generation and long-lived key generation PUF primitives act as the root-of-trust for the entire system, and as such, represent the primary targets of an attack. The TI extends the root-of-trust to customer devices using two different lighterweight mechanisms. The security properties of the MZT and POP protocols, characterized as single LLK and challenge-response-based multi-LLK, respectively, draw from the root-of-trust by virtue of the amount and type of security related information transferred and stored on the devices. From the message-exchange diagrams, the security-sensitive data utilized by the MZT and POP protocols always originates from the TI, and is authenticated and encrypted in transit by the TB primitives. This requires adversaries to focus their attack on the PUF-based authentication and session key generation functions localized to customer devices. We assume a Dolev-Yao adversary model where the attacker has significant computational resources, can eavesdrop on communication channels, and can intercept and manipulate packets as desired.8.1 CRP Space Analysis

[0108] The TB security properties are rooted in the SiRF P F’s physical source of entropy. The size of the CRP space when utilizing DV sets of size 5072 (the number of DVR and DVF stored in each of the NATDB and ATDB databases in our experiments) is given by 50722* 223 / 5072, yielding a total CRP space size of more than 235possibilities in cases where the TI stores all possible sets in its timing databases.8.2 Model-Building Attack Analysis

[0109] With the CRP space defined, we next describe an attack scenario where the adversary collects CRPs from a device-under-attack (DU A), as a precursor to building a machine-learning model.

[0110] Referring to FIG 12, the message exchange diagram shown in the figure gives the sequence of operations Under MANA / A Protocol 12000 carried out when the device 12002 requests authentication, which occurs as the first action in mutual authentication (MANA / A) inFIGs. 2, 6, 7 and 9. Note that LLK generation and transmission is gated and encrypted by the MANA / A and SKGWA / A functions. Therefore, the adversary 12004 must first defeat these security functions to extract response-based bitstrings, namely LLKs, from the PUF. The following sequence describes the attack:Step 1 (12006): The device 12002 controls the start of the transaction by sending an Authentication request message to the adversary on the right. The adversary is assumed to be in possession of the device to initiate this request.Step 2 (12008): The adversary 12004 then specifies two parameters, zv and px . The vxparameter specifies a 32-bit seed to an LFSR, that is used to pseudo-randomly select a set of vectors from the VCCDB 12014. We assume the adversary is in possession of a copy of the VCCDB and algorithm used by the DUA. The zv and px parameters are sent to the DUA.Step 3 (12009): The device 12002 defines Ztby XOR’ing the adversary-generated px with the output of its TRNG. The ^ parameter is used by both the DUA and adversary to seed another LFSR in the DVDiffs module that defines the pairing combinations of DVR and DVrused to create the DVD. We assume the adversary knows the LFSR primitive used by the device to create the DVD. The adversary cannot, however, control the final value of px. The px parameter is transmitted to the adversary.Step 4 (12010): The adversary 12004 extracts the vector sequence from the NQCDB 12014 using a copy of the algorithm that the device uses. The adversary accesses an instance of the NAUa? (not shown) to extract timing data for the paths tested by the vectors. Since the adversary does not have access to the TI version of this database, he / she must create a version using simulation experiments, which assumes he / she has layout information related to the SiRF PUF instantiated on the DUA. The adversary constructs a 2048-byte array of SpreadF actors, SFX, from the data extracted from the NAUa?. If SiRF PUF layout information is available, the SFXmay represent good approximations to what the TI provides to the device during a genuine exchange, otherwise the SFxare random guesses. The adversary transmits the SFxto the device.Step 5 (12012): The device selects vecsxand runs the SiRF PUF in enrollment mode, HPUFE, to produce helper data HDX. The HDXis a bitstring of length 2048 bits, which reflects which of the device-computed DVDco are strong (1), and which are weak (0). The HDXis transmitted to the adversary for storage and analysis.

[0111] From this description, the adversary controls the challenge sequence parameter, Vx, and optimization parameters, SFX, and receives a helper data bitstring, HDX, as the response. The Vx can be manipulated by the adversary to force specific paths to be timed while the SFXcan be manipulated incrementally to force weak bits to become strong, and vise versa. However, the actual response bits are not revealed (or even computed) by the SiRF PUF. Also note that thedevice can limit the rate of authentication attempts, which would limit the amount of data the adversary can collect over a given period of time.

[0112] It is the adversary’s goal to produce an HDXbitstring that is highly correlated to the HDXthat would be produced by the device under any arbitrary challenge, as a means of spoofing the identity of the genuine device to the TI. This requires the adversary to send accurate estimates of the SFxto the device during the model-building phase, to enable it to learn the bit classification, weak or strong, corresponding to each of the 2048 DVDm

[0113] The effectiveness of the model-building attack can be evaluated during the verifier authentication stage, where the device compares the HDXbitstring input by the adversary with the version it creates internally. The adversary again controls the ztrand SFXtransmissions to the device but must now provide an FOX that is highly correlated to HDXproduced internally by the device. To date, we have been unsuccessful in attempts to carry out this type of attack.

[0114] Session key generation, SKG ^ / 4 is gated by the success of verifier authentication and is not performed unless the adversary succeeds in convincing the device it is communicating with an authentic server. Although response bitstrings are sent in the clear over the network for SKG ^ / 4 the gating of this operation by MA«4 the size of the CRP space and the lack of control over the parameter / t will make it difficult to gather sufficient information to build an accurate model. If the adversary instead just eavesdrops on genuine device-TI authentications, the adversary will be tasked with identifying data communicated to / from a specific device because the M J 4 functions are privacy -preserving, and therefore, they do not reveal the identity of the device in the exchanged messages.8.3 Protocol Security Properties

[0115] The security properties of MZT enrollment operation (FIG 2), as well as all communication between customer devices and the TI during the bootstrap, withdrawal and deposit transactions utilize MA«4 and therefore, they inherit the security properties of the TB functions, which were covered above in the context of model-building attacks.

[0116] In contrast, the MZT in-field operations shown in FIG 3 are not preceded with MA«4 and therefore, warrant a separate assessment. In Step 6, a shared key is created by XOR- combining a ZHKykey stored in the MZT ATz^for customer y and a SiRF PUF regenerated key (LLKMZTX). Therefore, the shared key is constructed using information that is not stored in a database. Moreover, although not shown, the data stored in the MZT_AT databases can be encrypted by the LLKhose, and all actions carried out in the HOSE to provide an additional layer of security for the database stored component of the shared key. In Step 7, Alice and Bob exchange nonces, which, by definition, are used only once so their exposure to adversaries isincidental to its security properties of the protocol. In Step 8, the key refresh data is AES- encrypted and is therefore protected by the strong security properties of the AES algorithm.8.4 Ecosystem Attacks

[0117] The PUF-Cash protocol is designed to be resistant to all classes of attacks. For example, signatures and encryption keys are used only once, which increases resistance to side-channel and replay attacks. The HOSE provides a secure environment in the programmable logic (PL-side) by limiting access to the HOSE to two 32-bit memory-mapped registers, and by limiting interactions with the HOSE to a small set of valid operations. The HOSE avoids a wide range of software-based attacks that are possible within internet-connected processor environments. The self-validation, cross-validation and update protocol related to the heCt provides on-the-spot tamper detection capabilities during in-field, offline value transactions. The SiRF PUF challenge characteristics in combination with the proposed POP database scheme gives each fielded device access to large pool of entropy in a highly compressed format, which is key to enabling the aforementioned strengths of PUF-Cash. The HOSE embeds secrets that the untrusted processorside cannot access, and serves as the primary mechanism to prevent duplication and doublespending of eCt. The security properties of the protocol that protect against network-based attacks, e.g., man-in-the-middle, replay attacks and Sybil, as well as properties related to user privacy are similar to those described in previous work.

[0118] However, several attack scenarios are still possible. The most straightforward attack is a database copy-and-replace operation carried out on Alice’s device, where software running on Alice’s processor makes a copy of the eCtz^ before a payment transaction and then overwrites the HOSE updated version with the copy. This malicious operation is equivalent to doublespending because it restores eCt that Alice has just transferred to Bob. Although the TI will eventually detect the double-spent eCt, Alice’s recipients, and others in a transitive sequence of value transfer operations, will be prevented from depositing the duplicated eCt. The root of the problem stems from the inability of the device to 1) maintain state across power cycles, or 2) to restrict updates to the databases stored in its NVM to the HOSE only.9 SUMMARY AND CONCLUSIONS

[0119] A PUF-Cash protocol is proposed, and assessed in FPGA hardware experiments, that leverages two novel security protocols, called propagation-of-provenance (POP) and mutual- zero-trust (MZT), both of which can take place exclusively between two untrusted parties and both constructed to eliminate the need to interact with a trusted authority. POP is applied in this paper to secure the propagation of eCash tokens (eCt) from one customer to another. It leverages the exponential challenge-response space of a strong PUF, called the SiRF PUF, to allow recipients of eCt to authenticate their origin back to the token issuing authority. Successive hand-offs between devices utilize the combination of the payer’s SiRF-instantiated device and the recipients stored PUF responses to authenticate eCt signatures.

[0120] A hardware-obfuscated secure enclave (HOSE) is introduced as a means of alleviating software security issues which are difficult to address in microprocessor environments, and as a means of preventing end-users from attempting to double spend the eCt which they store. The HOSE is implemented entirely in the programmable logic of an FPGA embedded within a system- on-chip (SoC) device. A PUF-Cash protocol implementing bootstrap, withdrawal, transfer and deposit transactions is built on top of the HOSE, and POP and MZT protocols. Future work will investigate database-cloning attacks, network attack scenarios, and will further explore the model-building resistance of the SiRF PUF.

[0121] PUF-Cash possess the following characteristics:

[0122] A TI provides a PUF-based root-of-trust for the entire system and is able to extend the root-of-trust to trusted intermediaries and in-field devices using a lightweight mutual-zero-trust (MZT) protocol.

[0123] End-user (in-field) devices incorporate a strong PUF hardware security primitive, encapsulated in hardware-obfuscated secure enclave (HOSE). The HOSE enables the device to perform security functions related to the management and validation of eCt. The HOSE is completely independent of the untrusted microprocessor environment which is typically colocated on the same system-on-chip (SoC) device.

[0124] A propagation-of-provenance (POP) scheme is proposed which enables transactions between entities receiving eCt to authenticate the eCt of the issuing parties. Moreover, the receiving parties can perform this authentication without the involvement of a TTP. The entire sequence of such authentications establishes provenance back to the TI, which created the eCt.

[0125] The proposed PUF-Cash system supports unlimited transitivity where Alice can pay Bob, and Bob can pay Charlie without the need for any party to interact with a TTP.

[0126] Note that the strong PUF and HOSE provide unique capabilities and, in fact, define orthogonal security components of the system. The strong PUF protects keys and data at rest by eliminating the need to store keys in a non-volatile memory (NVM) and by encrypting protocol artifacts, z.e., those stored in databases on user devices. The HOSE, on the other hand, leverages the PUF-based keys to protect secrets in motion and in use, namely, payment information, customer credentials, and the eCt themselves.

[0127] The novel components of each of the POP exchange protocol and the MZT authentication protocol can be summarized as:

[0128] Aspect 1 : A PUF-based exchange protocol comprises a provenance of an information packet preserved and verified to the originating party, as the information packet is transferred across multiple PUF -instantiated devices in an untrusted network, and

[0129] Aspect 2: a light-weight mutual-zero-trust (MZT) authentication protocol enables two untrusted parties to authenticate securely using information stored in their MZT databases, wherein the information was obtained from a trusted-third party (TTP) at some earlier point in time.

[0130] Specifically, the aspect 1 (POP protocol) has the following features:

[0131] Al. l A PUF -based exchange protocol that allows the provenance of an information packet to be preserved and verified to the originating party, as the information packet is transferred across multiple PUF-instantiated devices in an untrusted network.

[0132] Al.2 Bootstrap: A set of PUF-instantiated devices transfer a set of POP tuples to a trusted-third party (TTP). The TTP stores them in a POP database, and then distributes the POP tuples to the set of devices so that each device has POP tuple information about all other devices in the PUF ecosystem. Each POP tuple incorporates a challenge, helper data and a corresponding PUF-derived long-lived key (LLK) that is unique to each device.

[0133] Al.3 POP protocol: A device requests an information packet, e.g., electronic money or eCt, from a TTP. The TTP represents the originating party which defines the root of the provenance chain for the information packet (eCt).

[0134] Al.4 The TTP retrieves the POP tuple for the requesting device from its POP database and creates a signed version of the information packet by XORing the information packet with requesting device’s LLK embedded in the POP tuple, and then uses the XOR’ed version as input to a secure hash function to produce a signed version, heCt.

[0135] A1.4 The eCt and heCt are encrypted and sent to the requesting device. The requesting device validates the eCt and heCt by generating its LLK using its hardware PUF, and creates its own version of the heCt using the same process. It compares the heCt and if they match, the eCt is validated and accepted, otherwise it is rejected.

[0136] Al.5 The requesting device then becomes a sender device. The sender device contacts another receiver device.

[0137] Al.6 The receiver device looks up the sender’s device POP in its POP database, extracts the challenge and sends the challenge to the sender device.

[0138] Al.7 The sender device applies the challenge to its hardware PUF, generates a LLK, and then signs the eCt by XOR’ing the LLK with the eCt. The XOR’ed version is then used as input to a secure hash to create the new signed version, heCt.

[0139] A1.8 The eCt and heCt are encrypted and transmitted to the receiver device.

[0140] Al.9 The receiver device decrypts the information packet, and retrieves the LLK component from the POP tuple associated with the sender, z.e., the same POP tuple that the receiver extracted the challenge from earlier and sent to the sender device. The LLK that the receiver stores must match the one the sender regenerated using its hardware PUF. This feature provides the most important security property of the propagation of provenance scheme.

[0141] AL IO Inside a secure enclave, the receiver computes a signed version of the eCt using the LLK of the sender device retrieved from its database and compares the signed version with the heCt received from the sender device, and accepts if they match, else the eCt and heCt are rejected. The receiver has now confirmed the provenance of the information packet.

[0142] AL I I Refresh: Assuming the previous step succeeds, the receiver device computes a new challenge and sends it to the sender.

[0143] Al .12 The sender applies the new challenge to its hardware PUF to generate a new LLK and helper data, which are encrypted and sent to the receiver.

[0144] A1.3 The receiver decrypts the packet and replaces the POP tuple elements for the sender in its database with new challenge, helper data and LLK. This new LLK will be used in the next transfer operation with the receiver device.

[0145] Al .14 The transaction is transitive, allowing the receiver to become the sender in a subsequent two-party transfer operation that works identically to that just described.

[0146] The aspect 2 (MZT) has the following features:

[0147] A2.1 A light-weight mutual-zero-trust (MZT) authentication protocol that enables two untrusted parties to authenticate securely using information stored in their MZT databases, that was obtained from a TTP at some earlier point in time.

[0148] A2.2 Enrollment: The PUF-enabled devices obtain a challenge from a TTP that they use to generate a PUF-based long-lived key (LLK).

[0149] A2.3 The PUF-enabled devices store the challenges and PUF-generated helper data in a non-volatile memory (NVM) to enable them to exactly reproduce the LLK at any time.

[0150] A2.4 The PUF-enabled devices generate a sequence of nonces using the PUF-based TRNG.

[0151] A2.5 The PUF-enabled devices perform a bitwise XOR operation using each of the nonces and their LLK as input, to produce a sequence of bitstrings that are then used as input to a secure hash function to produce a sequence of ZHKs.

[0152] A2.6 The ZHKs and nonces are transmitted encrypted to the TTP for storage in a ZHK database on the TTP.

[0153] A2.7 The PUF-enabled devices obtain a set of ZHK and corresponding nonces from the TTP that were generated by other PUF-enabled devices, which are stored by each of the devices in a ZHK database on each device.

[0154] A2.8 Authentication: A prover device sends a request to be authenticated by a verifier device.

[0155] A2.9 The prover device sends its ID to the verifier device, enabling the verifier device to locate the prover’s ZHK in its database.

[0156] A2.10 The verifier device sends the prover an acknowledgement packet (ACK) if it has a ZHK in its database for the prover.

[0157] A2.11 The verifier device sends the prover its ID, enabling the prover to determine if it has a ZHK for the verifier in its ZHK database, which the prover acknowledges by sending an ACK packet to the verifier.

[0158] A2.12 If either the prover or verifier do not have a ZHK element for the other party, then the transaction is cancelled.

[0159] A2.13 If both have ZHKs for the other device, both retrieve the ZHK and corresponding nonce from the ZHK database for the other party.

[0160] A2.14 Shared Key Generation: The verifier and prover transmit their nonces to the other device.

[0161] A2.15 Both the verifier and prover regenerate the LLKs using the stored challenges and helper data they possess in their non-volatile memories (NVMs).

[0162] A2.16 Both the verifier and prover bitwise XOR their LLK with the nonce received from the other party, and use the XOR’ed version as input to a secure hash function to generate a ZHK’.

[0163] A2.17 Both the verifier and prover XOR their ZHK’ with the ZHK stored for the other party in their ZHK database, which results in the generation of a shared secret between the verifier and prover.

[0164] A2.18 Authentication: The verifier and prover encrypt the nonces they received from the other party with the shared secret they possess.

[0165] A2.19 The verifier and prover transmit the encrypted nonces to the other party.

[0166] A2.20 The verifier and prover decrypt the encrypted nonces and compare them with the nonces they store in the ZHK databases (the same ones they transmitted to the other party earlier).

[0167] A2.21 The authentication succeeds if both find the decrypted versions match the stored nonces, verifying that each possess the same shared secret.

[0168] A2.22 Refresh ZHK: The verifier and prover generate a new nonce by running their TRNGs.

[0169] A2.23 The verifier and prover XOR their LLKs with the new nonces, and use them as input to a secure hash function to generate new ZHKs.

[0170] A2.24 The verifier and prover encrypt and transmit the new ZHKs and new nonces to the other party.

[0171] A2.25 The verifier and prover decrypt and replace the ZHKs and nonces they store for the other party with the new ZHK and new nonces they receive from the other party, as a means of preventing replay attacks.

[0172] While the disclosure is susceptible to various modifications and alternative forms, specific exemplary embodiments of the invention have been shown by way of example in the drawings and have been described in detail. It should be understood, however, that there is no intent to limit the disclosure to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure as defined by the appended claims.Additional Embodiment Details

[0173] The present invention may be a system, a method, and / or a computer program product. The computer program product and the system may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

[0174] Embodiments use a computer-enabled system or the like implementing the protocols and operations described above. Some embodiments are in the form of methods (computer- implemented methods) or computer-readable storage medium having encoded thereon computer-executable instructions to cause one or more processing units of a system to perform a computer-implemented method.

[0175] FIG 13 illustrates a computer architecture 1300 that may be used in accordance with certain embodiments. In certain embodiments, the raw sports data collection, storage, and process use computer architecture 1300. The computer architecture 1300 is suitable for storing and / or executing computer readable program instructions and includes at least one processor 1302 coupled directly or indirectly to memory elements 1304 through a system bus 1320. The memory elements 104 may include one or more local memories employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. The memory elements 1304 include an operating system 1305 and one or more computer programs 1306, and the operating system 1305, asunderstood by one skilled in the computer art, controls the operation of the entire computer architecture 1300 and the architecture 1300’s interaction with components coupled therewith such as the shown components (input device(s) 1312, output device(s) 1314, storage(s) 1316, databases 1318, internet 1322, and cloud 1324) and unshown components that are understood by one skilled in the art, and the operating system 1305 may be switched and changed as fit.

[0176] Input / Output (I / O) devices 1312, 1314 (including but not limited to keyboards, displays, pointing devices, transmitting device, mobile phone, edge device, verbal device such as a microphone driven by voice recognition software or other known equivalent devices, etc.) may be coupled to the system either directly or through intervening I / O controllers 1310.

[0177] Input Devices 1312 receive input data (raw and / or processed), and instructions from a user or other source. Input data includes, inter alia, (i) captured images, (ii) captured videos, (iii) captured audios, and (iv) computer or Al generated images / videos / audios.

[0178] Network adapters 1308 may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters 108. Network adapters 1308 may also be communicatively coupled to internet 1322 and / or cloud 1324 to access remote computer resources such as on-premise computing systems (not shown in FIG 13).

[0179] The computer architecture 1300 may be coupled to storage 1316 (e.g., any type of storage device; a non-volatile storage area, such as magnetic disk drives, optical disk drives, a tape drive, etc.). The storage 116 may comprise an internal storage device or an attached or storage accessible by other protocols (e.g., fiber-channel, network). Computer programs 1306 in storage 1316 may be loaded into the memory elements 1304 and executed by a processor 1302 in a manner known in the art.

[0180] Computer programs 1306 may include Al programs or ML programs, primary media processing programs, and ancillary programs, and the computer programs 1306 may partially reside in the memory elements 1304, and partially reside in storage 1316 and partially reside in cloud 1324 or in an on-remise computing system via internet 1322.

[0181] The computer architecture 1300 may include fewer components than illustrated, additional components not illustrated herein, or some combination of the components illustrated and additional components. The computer architecture 1300 may comprise any computing device known in the art, such as a mainframe, server, personal computer, workstation, laptop, handheld computer, telephony device, network appliance, virtualization device, storage controller, virtual machine, smartphone, tablet, etc.

[0182] Input device(s) 1312 transmits input data to processor(s) 1302 via memory elements 1304 under the control of operating system 1305 and computer program(s) 1306. The processor(s) 1302 may be central processing units (CPUs) and / or any other types of processing device known in the art such as FPGAs or programmable logic circuits. In certain embodiments, the processing devices 1302 are capable of receiving and processing input data from multiple users or sources, thus the processing devices 1302 have multiple cores. In addition, certain embodiments involve the use of videos (z.e., graphics intensive information) or digitized information (z.e., digitized graphics), these embodiments therefore employ graphic processing units (GPUs) as the processor(s) 1302 in lieu of or in addition to CPUs.

[0183] All embodiments also comprise multiple databases 1318 for storing desired data. Some raw input data are converted into digitized data format, or broken into more manageable fragments via sharding before being stored in the database 1318 or being used to create the desired output data. It’s worth noting that storage(s) 1316, in addition to being used to store computer program(s) 1306, are also sometimes used to store input data, raw or processed, and to store intermediate data. The permanent storage of input data and intermediate data is primarily database(s) 1318. It is also noted that the database(s) 1318 may reside in close proximity to the computer architecture 1300, or remotely in the cloud 1324, and the database(s) 1318 may be in various forms or database architectures. In some embodiments, the database(s) 1318 may be a distributed database in a sense that the data are spread across the networked storage devices within a media production environment while the management module of the data is hosted on one of the computers within the media production environment

[0184] Computer Architecture 1300 generically represents both an edge-device, a computer server, or an ensemble of computer servers, a mobile computing device (such as a mobile phone), or communicatively coupled and distributed computing resources that collectively have the elements and structures of the Computer Architectures 1300.

[0185] Because certain embodiments need a storage for storing large volumes of photo image / video / audio data, more than one database likely is used.

[0186] The provided method and / or system involves technologically enhancing and streamlining various time-consuming or costly aspects of a media production.

[0187] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0188] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device or a computer cloud via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0189] Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, Java, Python or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages, and scripting programming languages, such as Perl, JavaScript, or the like. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructionsby utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

[0190] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0191] These computer readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0192] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0193] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagramsand / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0194] In all embodiments, a production environment is employed to deploy and run a computing system. A production environment generally is an edge-device mounted on a moving vehicle, an on-premise computing system communicatively connected to the moving vehicle, or a remote cloud system communicatively connected to the moving vehicle. A production environment is different from a training environment in that the production environment feeds the computing system with a real-world input data, whereas a training environment usually feeds a computing system with a pre-organized input data to train the computing system. A production environment is different from a testing environment in that the testing environment feeds the computing system with testing input data which may not be a live production data. Sometimes, a production environment, a training environment, and a testing environment can overlap if they are crafted in a way not to interfere or burden the various production running in the production environment.Additional Notes

[0195] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0196] The uses of the terms of “media”, “media asset”, “media product”, “media file”, and “media product fragment”, in the context of describing the invention, are to be construed to mean a piece of media in its entirety.

[0197] The use of the terms “a” and “an” and “the” and similar references in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0198] Certain embodiments of this invention are described herein, including the best mode known to the inventors for carrying out the invention. It should be understood that the illustrated embodiments are exemplary only, and should not be taken as limiting the scope of the invention.

[0199] Benefits, other advantages, and solutions to problems have been described herein with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and element(s) that may cause benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of the claims. Reference to an element in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more." As used herein, the terms "comprises", “comprise”, "comprising", or a variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, no element described herein is required for practice unless expressly described as "essential" or "critical". Moreover, those skilled in the art will recognize that changes and modifications may be made to the exemplary embodiments without departing from the scope of the present invention. Thus, different embodiments may include different combinations, arrangements and / or orders of elements or processing steps described herein, or as shown in the drawing figures. For example, the various components, elements or process steps may be configured in alternate ways depending upon the particular application or in consideration of cost. These and other changes or modifications are intended to be included within the scope of the present invention, as set forth in the following claims.

[0200] Since each of the end-users of the proposed digital currency (eCash) system / ecosystem exclusively use one of the eCash devices such as smart devices (including smart phones) or computers, or edge devices. Because of the exclusivity among the end-users and the eCash devices, sometimes for the brevity, Alice and Bob and Charlie (examples of end-users) represent the eCash devices they respectively use. And by extension, the authenticity (or, provenance) of Alice and Bob and Charlie refer to the authenticity (or, prevenance) of the eCash devices they respectively use.

Claims

What is claimed is:

1. A digital currency (eCash) system comprising: a plurality of eCash devices, a plurality of end-users, each of which exclusively uses one of the plurality of eCash devices, a token issuer (TI) that defines and provides a root-of-trust for the system, a plurality of financial institutions (FI) that provides accounting services, a plurality of trusted intermediaries that can be consulted in an on-line mode of eCash tokens (eCt) transferring to provide authentication credentials for two end-users who seek secure transfers of eCts therebetween, a physical unclonable function (PUF) primitive installed on each of the plurality of eCash devices, wherein the PUF primitive engenders the plurality of end-user devices with properties of being verifiably enrolled as a member of a legitimate set of eCash devices and of possessing a hardware-based root-of-trust, a hardware-obfuscated secure enclave (HOSE) as a means of enabling a PUF -based propagation-of-provenance (POP) protocol, which allows eCash tokens (eCt) to be securely signed and validated by recipients without incurring any third-party dependencies at transfer time, wherein the POP protocol establishes a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminating in redemption at the TI, and wherein the HOSE is implemented as a set of state machines embedded in a hardware portion of each of the plurality of eCash devices, a light-weight mutual-zero-trust (MZT) authentication protocol, collectively implemented and facilitated by the PUF primitive, a secure hash function primitive, and a symmetric encryption algorithm primitive, establishes a secure channel between any two devices of the plurality eCash devices, wherein the POP protocol and MZT protocol, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between the plurality of eCash devices, online and offline.

2. The eCash system of claim 1, wherein the PUF primitive generates a number of authentication bitstrings, encryption keys, and random nonces by utilizing within-die variations in a set of path delays as a source entropy, wherein the set of path delays are measured through an engineered netlist of shift-registers and logic gates fan-in and fan-out to create an exponentially diverse matrix of signal paths that traverse a rectangular region of a field programmable gate array (FPGA) fabric, wherein the PUF primitive incorporates a mode switchto enable the entropy source and a random number generation algorithm to be used as a true- random number generator (TRNG), which in turn supplies an exponentially large number of random nonces for cryptographic operations.

3. The eCash system of claim 2, wherein the PUF primitive constructs authentication bitstring based challenges and responses by using the engineered netlist of shift-registers and logic gates, a binary vectors database, a time-to-digital converter (TDC) control module, a multiplexer (MUX), a block RAM (BRAM), a DVDiff module, a GPEVCal module which removes variations in delays in traduced by global performance differences, a SpreadFactors module which removes delay bias introduced by differences in the length of test paths to produce an entropy optimized delay value, and a BitGen module which converts the entropy optimized delay value to an authentication bitstring.

4. The eCash system of claim 1, wherein the TI comprises timing databases that encapsulate and compress a subset of a challenge-response space of each of the plurality eCash devices and are used by the TI to carry out mutual authentication and session key authentication with other entities in the system.

5. The eCash system of claim 1, wherein each of the plurality of end-user devices is enrolled, by the PUF primitive, according to a pre-set enrollment operations under the MZT protocol, with the TI as a member of the legitimate set of eCash devices represented by the identifier of the device and an authentication token (AT) created using a SHA-3 secure hash function on a 256-bit long-lived key (LLK) XORed with a 256-bit nonce (n), both of which are generated by the PUF primitive.

6. The eCash system of claim 1, wherein a first end-user (Alice) and a second end-user (Bob) of the plurality of end-users conduct an in-field process under the MZT protocol when Alice contacts Bob for goods or services in an environment where a direct communications channel is established between their respective eCash devices, wherein the in-field process comprises in-field authentication and session key generation facilitated by the PUF primitives on their respective eCash device, and an authorization token database installed on their respective eCash device.

7. The eCash system of claim 1, wherein the TI, under the POP protocol, bootstraps each of the plurality of end-user eCash devices during which, for each of the plurality of eCash devices,the TI, by using an authorization token database thereon, to generate and distribute an anonymous POP cryptographic tuple to the eCash device.

8. The eCash system of claim 1, wherein the TI, an end-user (Alice), and an FI that Alice uses, under the POP protocol, interact to conduct a withdrawal of a fund from Alice’s account maintained in the FI, during which Alice, while remaining anonymous to the TI, is verified by the TI for her authenticity, and a plurality of anonymous eCts is generated by the TI in the case that Alice’s account is verified by the FI for having sufficient fund, and transmitted to the FI, which forward the plurality of anonymous eCts to Alice.

9. The eCash system of claim 1, wherein a first end-user (Alice), under the POP protocol, pays a second end-user (Bob), during which Alice and Bob, under the MZT protocol, authenticate with each other by using, in part, an Alice-Bob MZT session key, Alice pays a plurality of eCts to Bob by encrypting them with the Alice-Bob MZT session key, and Alice and Bob, by using their respective POP cryptographic tuple, to authenticate and propagate the provenance of the plurality of eCts.

10. The eCash system of claim 1, wherein a third end-user (Charlie), under the POP protocol, deposits a plurality of anonymous eCts to a FI that he uses, during which the TI is invoked to validate the provenance and validity of the plurality of eCts, the TI and the FI mutually authenticate using a timing-based authentication protocol, the FI and Charlie mutually authenticate by using the MZT protocol, and in the case of all of the plurality of eCts are validated, the FI credits Charlie’s account, and the plurality of eCts are marked as redeemed in an eCt database on the TI.

11. A method for using digital currency (eCash) within an eCash system that comprises a plurality of eCash devices, a plurality of end-users, each of which exclusively uses one of the plurality of eCash devices, a token issuer (TI) that defines and provides a root-of-trust for the system, a plurality of financial institutions (FI) that provides accounting services, a plurality of trusted intermediaries, a physical unclonable function (PUF) primitive installed on each of the plurality of eCash devices, a hardware-obfuscated secure enclave (HOSE) which, as a means of enabling a PUF-based propagation-of-provenance (POP) protocol, is implemented as a set of state machines embedded in a hardware portion of each of the plurality of eCash devices, a lightweight mutual-zero-trust (MZT) authentication protocol, collectively implemented andfacilitated by the PUF primitive, a secure hash function primitive, and a symmetric encryption algorithm primitive, the method comprising: verifiably enrolling, by the PUF primitive, each of the plurality of eCash devices as a member of a legitimate set of eCash devices that possesses a hardware-based root-of-trust, consulting, in an on-line mode of eCash tokens (eCt) transferring, one of the plurality of trusted intermediaries to provide authentication credentials for two end-users who seek secure transfers of eCts therebetween, signing and validating eCash tokens by recipients thereof without incurring any third- party dependencies at transfer time, establishing, by the POP protocol, a chain of custody starting with token creation, extending through multiple bilateral in-field transactions, and culminating in redemption at the TI, and establishing, in an off-line mode of eCash tokens (eCt) transferring, a secure channel between any two devices of the plurality eCash devices, wherein the POP protocol and MZT protocol, in combination with the HOSE, enables transitivity and anonymity of eCt transfers between the plurality of eCash devices.

12. The method of claim 11, further comprising: generating, by the PUF primitive, a number of authentication bitstrings, encryption keys, and random nonces by utilizing within-die variations in a set of path delays as a source entropy, wherein the set of path delays are measured through an engineered netlist of shift-registers and logic gates fan-in and fan-out to create an exponentially diverse matrix of signal paths that traverse a rectangular region of a field programmable gate array (FPGA) fabric, wherein the PUF primitive incorporates a mode switch to enable the entropy source and a random number generation algorithm to be used as a true-random number generator (TRNG), which in turn supplies an exponentially large number of random nonces for cryptographic operations.

13. The method of claim 12, further comprising: constructing, by the PUF primitive, authentication bitstring based challenges and responses by using the engineered netlist of shift-registers and logic gates, a binary vectors database, a time-to-digital converter (TDC) control module, a multiplexer (MUX), a block RAM (BRAM), a DVDiff module, a GPEVCal module which removes variations in delays in traduced by global performance differences, a SpreadF actors module which removes delay bias introduced by differences in the length of test paths to produce an entropy optimized delayvalue, and a BitGen module which converts the entropy optimized delay value to an authentication bitstring.

14. The method of claim 11, further comprising: carrying out, by the TI by using timing databases thereon that encapsulate and compress a subset of a challenge-response space of each of the plurality eCash devices, mutual authentication and session key authentication with other entities in the system.

15. The method of claim 11, further comprising: enrolling each of the plurality of end-user devices, by the PUF primitive thereon, according to a pre-set enrollment operations under the MZT protocol, with the TI as a member of the legitimate set of eCash devices represented by the identifier of the device and an authentication token (AT) created using a SHA-3 secure hash function on a 256-bit long-lived key (LLK) XORed with a 256-bit nonce (n), both of which are generated by the PUF primitive.

16. The method of claim 11, further comprising: conduct an in-field process under the MZT protocol between a first end-user (Alice) and a second end-user (Bob) of the plurality of end-users when Alice contacts Bob for goods or services in an environment where a direct communications channel is established between their respective eCash devices, wherein the in-field process comprises in-field authentication and session key generation facilitated by the PUF primitives on their respective eCash device, and an authorization token database installed on their respective eCash device.

17. The method of claim 11, further comprising: bootstrapping, by the TI, under the POP protocol, each of the plurality of end-user eCash devices during which, for each of the plurality of eCash devices, the TI, by using an authorization token database thereon, to generate and distribute an anonymous POP cryptographic tuple to the eCash device.

18. The method of claim 11, further comprising: conducting a withdrawal of a fund from an end-user (Alice), wherein the TI, an end-user (Alice), and an FI that Alice uses, under the POP protocol, interact to conduct a withdrawal of a fund from Alice’s account maintained in the FI, during which Alice, while remaining anonymous to the TI, is verified by the TI for her authenticity, and a plurality of anonymous eCts is generated by the TI in the case that Alice’s account is verified by the FI for havingsufficient fund, and transmitted to the FI, which forward the plurality of anonymous eCts to Alice.

19. The method of claim 11, further comprising: paying, by a first end-user (Alice), under the POP protocol, a second end-user (Bob), during which Alice and Bob, under the MZT protocol, authenticate with each other by using, in part, an Alice-Bob MZT session key, Alice pays a plurality of eCts to Bob by encrypting them with the Alice-Bob MZT session key, and Alice and Bob, by using their respective POP cryptographic tuple, to authenticate and propagate the provenance of the plurality of eCts.

20. The method of claim 11, further comprising: depositing, by a third end-user (Charlie), under the POP protocol, a plurality of anonymous eCts to a FI that he uses, during which the TI is invoked to validate the provenance and validity of the plurality of eCts, the TI and the FI mutually authenticate using a timing-based authentication protocol, the FI and Charlie mutually authenticate by using the MZT protocol, and in the case of all of the plurality of eCts are validated, the FI credits Charlie’s account, and the plurality of eCts are marked as redeemed in an eCt database on the TI.

Images