Peer-to-peer network as application level cryptocurrency and blockchain interface

Abstract

The invention relates to a peer-to-peer network as an application-level cryptocurrency and blockchain interface, which implements a secure peer-to-peer network with a computing device through an unsecure network connection. Each computing device may include or be coupled to a provenance attestation hardware. The provenance hardware may be validated through secure storage or other modalities of public available data, such as trusted servers, or valid provenance data. Once verified on the peer-to-peer network, the peer-to-peer node may provide or receive network services, such as a blockchain service, a cryptocurrency transaction service, a smart contract-supporting service, a token exchange, a survey service utilizing provenance proof data, a distributed data backup service, a distributed computing service, and the like.

Description

[0001] References merged

[0002] U.S. Patent Application No. 18 / 753,784, filed June 25, 2024, entitled "BACKUP AND RECOVERY SYSTEM AND METHODS FOR CRYPTOCURRENCY HARDWARE WALLET"; U.S. Patent Application No. 18 / 406,899, filed January 8, 2024, entitled "CRYPTOCURRENCY HARDWARE WALLET ON MONOLITHIC CHIP WITH COMMONPHYSICAL COUNTERMEASURES AND SECURE MEMORY"; U.S. Patent Application No. 18 / 218,948, filed July 6, 2023, entitled "SECURE MICROCONTROLLER WITH UNIFIED RRAM AND SUB-MODULEADDRESSING AND ACCESS CONTROL"; and U.S. Patent Application No. 18 / 218,948, filed May 22, 2023, entitled "UTILIZING TWO-TERMINAL RESISTIVE SWITCHING MEMORY TO STORE". The entire contents of U.S. Patent Application No. 18 / 200,318, entitled “VALIDATIONDATA OF AN INTEGRATED CIRCUITDEVICE” and U.S. Patent Application No. 17 / 708,491, filed March 30, 2022, entitled “DYNAMIC HOST ALLOCATION OF PHYSICAL UNCLONABLE FEATUREOPERATION FOR RESISTIVE SWITCHING MEMORY”, are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure generally relates to improving the usability and reliability of secure digital transactions, as an illustrative example: a peer-to-peer network in which peer nodes provide application services for blockchain or cryptocurrency networks. Background Technology

[0004] Security in electronic communications is relevant at both the microscopic and macroscopic levels, from the operation of components within a single die to network communications of interconnected computing devices. Furthermore, communication security is relevant across various scales between the microscopic and macroscopic levels, as well as in unconventional (or even previously unknown) inter-operations of electronic devices. Despite these differences, in the modern environment, the most common application for securing electronic communications is likely cryptographic algorithms.

[0005] As a general characteristic, encryption algorithms tend to employ highly complex computational schemes, making them virtually impossible to break in practice, though not theoretically impossible in most cases. The higher the complexity of an encryption algorithm, the more difficult it is to break in practice. However, for this to hold true, certain mathematical assumptions upon which the algorithm relies must also hold. One such assumption is the true randomness of the numbering scheme used by the algorithm. If systematic patterns exist in the numbering scheme or the mechanism used to generate (random) numbers, the algorithm is easier to break. To this end, the National Institute of Standards and Technology (NIST) has been continuously testing the randomness of number generators used in cryptographic applications (see, for example, A. Rukhin et al., “A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST, Vol. 800–22, Rev. 1a, p. 131, 2010).

[0006] A potential vulnerability in secure communications lies in the memory used to store secure data. Hackers can exploit knowledge about how memory operates at the cell or array level, how data bits are stored, and the physical effects of operations performed on memory to infer information about the secure data stored there. This knowledge itself rarely yields the secure data directly. However, even correctly inferring only a tiny correlation between certain bits of the stored data can compromise its theoretical or mathematical security. This, in turn, makes it easier to crack the secure data through brute-force calculations or other conventional methods.

[0007] Another potential vulnerability in secure communications lies in the authenticity of the manufacturing components of communication devices. Some hacking techniques attempt to replace trusted devices or components with compromised replacements. These compromised replacements might be placed in the authentication network to improperly report the compromised device as valid, or within edge devices involved in secure communications, intermediate devices such as network routers and hubs, or other links in the network. If the security patterns affecting network communications involve compromised devices, network communications may be compromised.

[0008] As network computing becomes increasingly practical in personal and organizational communications, digital commerce, and financial asset exchange, the need to enhance network computing security will persist. In light of the foregoing, the assignee of this disclosure continues to develop and pursue practical applications and integrated circuit devices to enhance the usability and security of network communications over public and private networks. Summary of the Invention

[0009] The following is a simplified summary of this specification to provide a basic understanding of some aspects thereof. This summary is not a broad overview of this specification. Its purpose is neither to identify key or essential elements of this specification, nor to define the scope of any particular embodiment or any claim. Its purpose is to present some concepts of this specification in a simplified form as a prelude to the more detailed descriptions presented in this disclosure.

[0010] This disclosure provides secure data to verify nodes in a computing network and mitigate or prevent forgery on the network. Valid nodes can act as trusted devices and are coupled to (or embodied as) nodes in the blockchain to provide blockchain services. Node verification can be restarted when a computing device joins the network. This can be extended to consumer edge devices, allowing non-dedicated or non-enterprise hardware to operate as trusted devices and provide blockchain services to client devices, whether edge (client) devices or even enterprise (client) devices.

[0011] In one or more embodiments, this disclosure provides an electronic device. The electronic device may include a communication interface facilitating communication with a remote device via a network, a processor for executing instructions relating to digital assets within an asset account associated with proof-of-origin (PoO) data, and a storage medium containing the instructions. The instructions may include: receiving a login from a remote device to the asset account; sending a query for PoO data in response to the login; receiving a response to the query; extracting data from the response; and verifying the data from the response as PoO data. Furthermore, the instructions may include, in response to verifying the PoO data, authorizing the remote device to access and control the digital assets.

[0012] Another aspect of the disclosed embodiments provides a method of operating a computing device. The method may include initiating peer-to-peer network communication with a remote device on a network via a communication interface of the computing device, and initiating communication with a node device of a blockchain network via the communication interface. The method may further include forming a query for proof-of-origin (PoO) data that is unique or substantially unique to the remote device via a processor coupled to a memory and coupled to the communication interface. Furthermore, the method may include transmitting the query to the remote device on the peer-to-peer network via the communication interface, and receiving a response to the query, which includes the data, via the communication interface. Additionally, the method may include verifying the data as PoO data via the processor, and in response to verifying the data as PoO data, performing an application service on behalf of the remote device using the blockchain network via the processor.

[0013] In another aspect of the disclosed embodiments, this disclosure provides a computing network. The computing network may include a first computing device having a network communication interface, a short-range network connection, a memory storing instructions for a blockchain service application, and a processor for executing the instructions stored in the memory. The computing network may also include a second computing device having a second network communication interface and a second short-range network connection. The computing network may further include an integrated circuit (IC) device including proof-of-origin (PoO) data generated from non-volatile memory cells embedded within the IC device using a physically unclonable function (PUF) or true random number generation (TRNG) algorithm, wherein the IC device is communicatively coupled to the second computing device via the second short-range network connection. In some aspects, the first and second computing devices may be communicatively coupled in a peer-to-peer network. In other aspects, the first computing device may be configured to be communicatively coupled to a blockchain node of a blockchain network. In still other aspects, the first computing device may be configured to verify a client account associated with the second computing device via PoO data and execute a blockchain service application on behalf of the client account in response to verifying the PoO data.

[0014] The following description and accompanying drawings illustrate certain illustrative aspects of this specification. However, these aspects indicate only a few of the many ways in which the principles of this specification can be employed. Other advantages and novel features of this specification will become apparent from the following detailed description when considered in conjunction with the accompanying drawings. Attached Figure Description

[0015] Various aspects or features of this disclosure are described with reference to the accompanying drawings, wherein like reference numerals are used to denote the same elements throughout. Numerous specific details are set forth in this specification to provide a thorough understanding of this disclosure. However, it should be understood that certain aspects of this disclosure may be practiced without these specific details, or using other methods, components, materials, etc. In other instances, well-known structures and devices are shown in block diagram form to facilitate the description of this disclosure.

[0016] Figure 1 This is a block diagram of an example integrated circuit (IC) device formed on a monolithic semiconductor die, according to one aspect of the disclosed embodiments;

[0017] Figure 2 A diagram illustrating an example device verification for a blockchain network according to one aspect of the disclosed embodiments;

[0018] Figure 3 A block diagram of an example IC device having trust root data configured to be derived from an IC device, according to another aspect of the disclosed embodiments;

[0019] Figure 4 For the combination shown in another aspect of this disclosure Figure 3 A diagram of an example secure peer-to-peer (P2P) network for IC devices;

[0020] Figure 5 This is a secure P2P network coupled with blockchain network communication that has integrated and peer-to-peer application support, as shown in another disclosed aspect.

[0021] Figure 6 A block diagram of hardware identifiers and application processing devices on a single chip according to another aspect of the disclosed embodiments;

[0022] Figure 7 This is an example peer-to-peer source blockchain application service for a secure P2P network, as shown in another aspect of the disclosed embodiments.

[0023] Figure 8 A flowchart illustrating an example method for providing blockchain application services within a secure P2P network, as shown in the disclosed additional aspects;

[0024] Figure 9 and Figure 9A A flowchart illustrating an example method for protecting peer nodes within a P2P network through a blockchain service application, as shown in one or more of the disclosed aspects.

[0025] Figure 10 A block diagram illustrating an exemplary electronic operating environment according to one or more of the disclosed embodiments;

[0026] Figure 11 This is a block diagram of an exemplary computing environment shown according to one or more embodiments of the present disclosure. Detailed Implementation

[0027] introduction

[0028] Blockchain networks offer substantial utility in digital commerce, including the rapid and efficient exchange of cryptocurrency assets. However, as more business and investment value shifts to digital assets, and more business is conducted through cryptocurrency exchanges, the incentive for hackers and illicit activities to steal, compromise, or otherwise interfere with the security of cryptocurrency assets and exchanges grows. One mechanism for disrupting digital commerce is identity spoofing. Because digital commerce typically relies on data to identify different parties on the network, identity spoofing can be easily achieved by transmitting false identity data across the network. Data used to identify entities on the network can include Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, Subscriber Identity Module (SIM) numbers, Integrated Circuit Card Identification (ICCID), International Mobile Subscriber Identity (IMSI) numbers, International Article Numbers (IAN), Personal Identification Numbers (PINs), and so on. By generating false identity data and impersonating these false identities as independent entities, malicious actors can impersonate entities on the network. Because data can be copied almost without limit, the number of forged entities can be virtually unlimited once a successful data forgery technique is discovered. This undermines network security and reliability. Various aspects of this disclosure provide a secure integrated circuit device configured to derive a root of trust data that is unique or substantially unique to the integrated circuit device. This allows the root of trust data to be used to identify the integrated circuit device, or associated computing device, on the network. Because the root of trust data is extremely difficult to forge, the reliability of network entities can be significantly improved when verified through the root of trust data.

[0029] More generally, threats to the security and effectiveness of electronic devices through hacking and unauthorized access are widespread. Mechanisms used to protect and authenticate electronic devices and network communications between devices (especially on insecure networks) include encryption, virtual private networks (VPNs), and combinations thereof. Even if the electronic devices involved in network communications are properly authenticated, the communication channels between devices may still be vulnerable to attack. This is typically addressed by encrypting data before transmitting critical communications over the network. Virtual private networks (VPNs) can utilize tunneling protocols between electronic devices and communication networks, or between two networks, which may include encryption. However, hacking efforts continue as security advances, attempting to identify and exploit weaknesses in electronic devices and electronic communications. The need for robust and comprehensive anti-hacking capabilities has been one of the factors slowing the development of applications that exchange value over insecure networks such as the Internet.

[0030] As a specific example, unauthorized access to electronic devices participating in network communications can be used to disrupt the communications, or even damage other devices involved in the communications. To illustrate, unauthorized modification or replacement of components of an electronic device (e.g., non-volatile memory, firmware, encryption keys, etc.) can effectively compromise the device itself. Furthermore, while the manufacturing techniques used to produce chips are cost-effective and efficient, they may leave inherent vulnerabilities in the chips themselves. As another illustration, the internal device packaging that facilitates communication between the manufacturing components constituting an electronic device (e.g., inter-chip bonding that also facilitates inter-chip communication, or printed circuit board communication lines connecting chips, etc.) may be vulnerable to unauthorized direct physical access, thereby compromising communication within the device itself. Similarly, physical access to chips can be exploited to retrieve secret, secure data used for encrypted communications, thereby compromising those communications. Furthermore, network communications can be potentially compromised by accessing components of the network, its sub-components, or the data transmitted within it. Several core flaws in electronic devices and electronic communications are frequently exploited to compromise the security of digital transactions.

[0031] Various embodiments of this disclosure include electronic devices configured to resist unauthorized physical access. In some examples, the electronic device may be configured to include a secure element with physical countermeasure (PCM) shielding and resistant to hacking attacks. Secret data—such as proof-of-origin data, root of trust data, derived data from the root of trust data (e.g., hashed root of trust data), cryptocurrency keys, secret user data, sensitive data, etc.—may be stored in memory embedded within the secure element and protected by the PCM shielding. The secret data may be generated at least in part from a PUF or TRNG algorithm implemented within such electronic device (e.g., resistive switching memory, MOS transistor memory, SRAM memory, etc.). Such data may be unique or substantially unique for the embedded memory (and the electronic device). The inclusion of a secure element can prevent some hacking attacks and unauthorized access attempts, but other attacks may still be effective if the communication path between the secure element and the processor, device controller, memory structure utilized by the processor, etc., is not protected by PCM shielding. For example, this could occur in a chip bonding device where a secure element is formed on a chip bonded to a second chip containing a processor or device controller and memory utilized by the processor / controller. If the controller or processing device accessing the secure element is not protected by PCM shielding, both the controller and the communication link between the controller and the secure element (e.g., chip-to-chip bonding) become vulnerable points.

[0032] Besides structural vulnerabilities in electronic devices, many secure element devices suffer from outdated single-key security architectures and lack the computational power or memory to leverage complex architectures such as multi-party computation (MPC). Single-key security also poses a threat of data or asset (e.g., digital assets) loss due to the loss of a single security key or the single electronic device storing that key. Embodiments of this disclosure can utilize a sophisticated MPC encryption and decryption framework that stores secure data in embedded resistive memory with strong resistance to unauthorized physical access. In the case of network interactions, highly secure proof-of-origin data available at various network nodes can be used for decentralized and distributed authentication of nodes within the network. Proof-of-origin data can be stored on a monolithic integrated circuit (IC) device with strong PCM shielding (e.g., see below). Figure 3 and Figure 6In some embodiments, proof-of-origin data may be authenticated at a trusted server device of the manufacturer of the monolithic IC device (e.g., see U.S. Patent Application No. 18 / 200,318, filed May 22, 2023, entitled “UTILIZING TWO-TERMINAL RESISTIVE SWITCHING MEMORY TOSTOREVALIDATION DATA OF AN INTEGRATED CIRCUIT DEVICE,” which is incorporated above by reference). In other embodiments, proof-of-origin data may be authenticated by a network node against trusted proof-of-origin data stored in the network node’s secure memory. In still other embodiments, proof-of-origin data may be generated from a physically unclonable function (PUF) implemented using a resistive switching memory embedded in the monolithic IC device in response to a request for proof-of-origin data issued by a network node (e.g., see below). Figure 1 And U.S. Patent Application No. 17 / 708,491, filed on March 30, 2022, entitled “DYNAMICHOST ALLOCATION OF PHYSICAL UNCLONABLE FEATURE OPERATION FOR RESISTIVE SWITCHING MEMORY” (incorporated above by reference).

[0033] The disclosed embodiments include a secure IC device in a single monolithic chip architecture that stores proof-of-origin data that can be used to verify a computing device coupled to the secure IC device. The computing device can operate on an insecure network and provide proof-of-origin data to verify the computing device as a trusted node on the insecure network. In at least one non-limiting aspect of the disclosed embodiments, verification of the proof-of-origin data can be performed at a trusted server device maintained by the manufacturer of the IC device; however, other modalities for verifying unique or substantially unique proof-of-origin data are within the scope of this disclosure. In some embodiments, the proof-of-origin data can be used to protect communications involving the computing device on an insecure network. As an example, the proof-of-origin data can be used to generate secure data (e.g., a public-private key pair or other suitable cryptographic architecture) that can encrypt and decrypt secure communications of the computing device. In some aspects of this disclosure, the proof-of-origin data can be used, at least in part, by the computing device to generate an MPC key share with one or more other computing devices connected to the insecure network. In such aspects, the MPC key share can be used to encrypt or decrypt communications on the insecure network.

[0034] In some of the disclosed embodiments, the disclosed IC device may include hardware logic for accelerating cryptographic algorithm computation, such as generating secret data, generating MPC security data, participating in the encryption and decryption of data using MPC key sharing, and providing blockchain services to client nodes on a peer-to-peer network (such as cryptocurrency wallet applications, digital asset trading applications, smart contract applications, etc.) (e.g., hereinafter). Figure 6 In such embodiments, the hardware logic may include atomic logic sequences that can be organized in different sequences and combinations to implement various algorithmic computations. These atomic logic sequences can significantly increase the range and scale of algorithms that the IC device can compute, while minimizing the chip area consumed by hardware-accelerated logic circuitry (e.g., see above-incorporated U.S. Patent Application No. 18 / 406,899). Figures 2-4 ).

[0035] As used herein, the term “substantially” and other relative terms or degree terms (e.g., approximately, about, roughly, roughly, etc.) are intended to have the meaning explicitly specified herein, or the meaning that a person skilled in the art could reasonably infer, or a reasonable variation in a specified quality or quantity that a person skilled in the art would understand by reference to the entire specification (including the knowledge of a person skilled in the art and the material incorporated herein by reference). As an example, a degree term may refer to a reasonable range of manufacturing tolerances, with respect to which a specified quality or quantity can be achieved using manufacturing equipment. Thus, as a specific illustration (but not a limitation), for an element explicitly identified as having a resistive switching device with a size of about 50 angstroms (A), the relative term “about” may refer to a reasonable variation of about 50 A that a person skilled in the art would expect the specified size of the element to be achievable using commercial manufacturing equipment, industrial manufacturing equipment, laboratory manufacturing equipment, etc., and is not limited to a mathematically precise quantity (or quality). In other examples, a degree term may refer to a variation of + / - 0.3%, + / - 0.5%, or + / - 0.10% of an explicitly stated value, where suitable for a person skilled in the art to achieve the stated function or feature of the element disclosed herein. In other examples, the term "degree" may refer to any suitable variation in quality or quantity that would be appropriate for implementing the explicitly disclosed function or feature of the disclosed element. Therefore, this specification is by no means limited to the specific quality and quantity disclosed herein, but includes all suitable variations in the specified quality or quantity that are reasonably conveyed by one of ordinary skill in the art through the context of this disclosure.

[0036] Overview

[0037] Figure 1This is a block diagram of an exemplary integrated circuit (IC) device 100 for an electronic device (e.g., a secure computing device, a secure element, a digital hardware wallet on a single chip, etc.) according to one or more embodiments of the present disclosure. The IC device 100 includes a secure element 110 comprising an array 112 of embedded resistive memory (ReMEM). The ReMEM may include, for example, two-terminal resistive switching memory cells, but in some disclosed embodiments, other magnetically switched or charge-capture two-terminal or even three-terminal memory cells may be utilized alternatively or additionally. For example, the array 112 of ReMEM may include, as non-limiting examples, magnetically switched memories (e.g., spin torque transfer magnetic memories, etc.), phase-change resistive switching memories, oxygen vacancy resistive switching memories, conductive bridge switching memories, metal oxide resistive switching memories, suboxide resistive switching memories, chalcogenide memories, carbon nanotube memories, organic memories, and resistance wire switching memories, as well as other memories known in the art or reasonably conveyed to those skilled in the art by the context provided herein.

[0038] The array 112 of the embedded ReREM 112 may include resistive-switched memory cells, and different portions of the resistive-switched memory cells may be characterized for different memory or data generation functions. Example functions of the resistive-switched memory cells of array 112 may include physically unclonable function (PUF) data generation, memory storage, or true random number generation (TRNG) data generation. Memory storage functions may include one-time programmable (OTP) data storage and many-time programmable (MTP) data storage (also known as rewritable or programmable / erasable), and are collectively shown as memory cell 114. Memory cells used to generate or store PUF data or TRNG data are collectively shown as PUF cell 115. In one or more embodiments, multiple memory cells may be aggregated to define differential PUF bits (or differential TRNG bits), or in other embodiments, a single cell may define a PUF bit (or TRNG bit). These modes are also embodied within PUF cell 115. The array 112 of the embedded ReMEM may be characterized for... Figure 1 Other types of memory cells not specifically described herein will be characterized, where appropriate.

[0039] As shown, array 112 can be a uniform memory structure, while in other embodiments, different arrays (with different access controls 116) can define separate memory cells. In yet another embodiment, each of memory cells 114 and PUF cells 115 can be embodied in different resistive switching arrays with their respective access controls 116. More generally, one or more of memory cells 114 and PUF cells 115 can be memory structures separate from the embedded ReMEM array 112. For example, OTP cells can be located on different portions (not shown) of a monolithic semiconductor chip, outside of array 112. Alternatively, in other embodiments, other memory cells 114 (or PUF cells 116) can be at least partially included within the memory array 112. For example, memory cells 114 can be embodied as one of a set of arrays forming the embedded ReMEM array 112, a memory block within array 112, one or more blocks, or a set of pages within an array, or other suitable arrangements.

[0040] Access control 116 can be configured to selectively allow or restrict access to array 112 or portions of array 112 based on stored conditions. In one embodiment, access control 116 can be implemented in conjunction with a security element bus (SE bus) 145 that provides electronic communication with the security element 110 (e.g., hereinafter referred to as...). Figure 3 SE bus 355 or Figure 6 (SE bus 645). In various embodiments, different buses may have different access control logic or storage conditions. For example, access control 116 associated with the array 112 of the disclosed security element may have core / process control 118 configured to restrict access to the processor, processor core, process or thread running on the processor, etc., of the array 112 of the embedded ReMEM associated with the security element 110, or to portions of the array 112 (e.g., distinguishing between access to memory cell 114 and access to PUF cell 115). Conversely, another access control 116 (not depicted) associated with a bus facilitating electronic communication with the array 112 for storing application code or with volatile memory for maintaining operational data of an executing application may have little or no core / process control 118 access restrictions for processors, cores, processes, or process threads implemented within a monolithic semiconductor chip such as IC device 100 (e.g., see below). Figure 3 MCU bus 315 or Figure 6 (MCU bus 635). Access control 116 can also enforce access restrictions on array 112 on external commands or data received at command / data interface 130 (see below).

[0041] A controller 120 is provided to perform operations on the embedded ReMEM array 112. Suitable operations may include memory operations, such as reading data from a subset of array 112, writing data to a subset of array 112, and rewriting data at a subset of array 112. Memory operations may include processes such as programming (writing), reading, rewriting, and erasing, suitable for operations on memory cells 114 (including operations suitable for multiple-programmable cells and operations suitable for one-time-programmable cells). Furthermore, memory operations may include processes for generating PUF data or TRNG data on individual PUF cells 115 or on a set of PUF cells 115 defining differential PUF bits. Instructions for implementing memory operations according to various characteristics may be stored in trimin instructions 122. Memory cell operations can be implemented in response to commands from external devices (e.g., via command / data interface 130), which can be implemented by the manufacturer of the integrated circuit device 100 after its manufacture, the distributor or reseller of the integrated circuit device 100 after its manufacture, the end user as part of a chip calibration routine, or as a dynamic process during the operation of the integrated circuit device 100 according to various embodiments.

[0042] As an illustrative example, a host device communicatively coupled to integrated circuit device 100 may issue a host command to generate PUF data (or TRNG data). In at least some of the disclosed embodiments, the host command to generate PUF data may be part of a distributed MPC data generation algorithm, wherein an MPC key, one or more shared MPC keys, or a suitable combination thereof is generated at PUF unit 115 via a PUF data generation operation. In another example, a remote device communicatively connected to integrated circuit device 100 via a network (e.g., via command / data interface 130; see below) (directly or indirectly) may issue commands to integrated circuit device 100 (or a computing device connected to or communicatively coupled to integrated circuit device 100; see below). Figure 2 The request is for proof of origin (PoO) data that is unique or substantially unique to the mobile device 220 and hardware identifier device 230. In response to a remote command, the controller 120 can access the PUF unit 115 and retrieve the PoO data that is unique to the integrated circuit device 100, and respond to the remote command with the PoO data. In various embodiments, the fine-tuning instruction 122 can store protocols to implement memory operations of the storage unit 114 and PUF unit 115 consistent with these and other example operations.

[0043] Input 140 and output 150 are also shown in the integrated circuit device 100. In some embodiments, input 140 may include (or provide a path for) data to be stored within the array 112 of embedded ReMEM, such as memory cell 114 or PUF cell 115. Output 150 may output data stored within the resistive memory device of array 112. In some embodiments, output 150 may output calculation results utilizing the data stored in the ReMEM cell.

[0044] A command / data interface 130 is provided to receive memory commands from external devices and respond to those commands. Furthermore, data to be written to array 112 can be received via command / data interface 130, and data output from array 112 can be provided via command / data interface 130. In one or more embodiments, command / data interface 130 may include a direct physical interconnect to an electronic device or a short-range wireless interconnect (e.g., see below). Figure 2 Local-only communication (244) may be included in other embodiments, or may include limited and direct communication over a wide area network (e.g., a connection limited to a predetermined IP address (or set of addresses) of a trusted server device, such as a backup key recovery device).

[0045] Figure 2 This diagram illustrates an exemplary communication environment 200 for facilitating peer node authentication in a peer-to-peer network environment, according to various embodiments of this disclosure. In some embodiments, the communication environment 200 may also facilitate secure communication via remote communication 242, even if remote communication 242 includes an insecure network. The communication environment 200 may even facilitate secure communication from insecure edge devices (e.g., peer nodes, network gateway devices, consumer edge devices, etc.), mitigating or avoiding the need to limit participation in the communication environment 200 to only trusted edge devices. For example, the communication environment 200 may facilitate device authentication and secure communication in wide-area peer-to-peer (P2P) interconnection of untrusted devices utilizing insecure networks (such as the Internet, public networks, insecure private networks, etc.) (see also, for example, below). Figure 4 and Figure 5 This can facilitate trusted interactions between non-dedicated peer nodes, allowing them to provide application services to other peer nodes. It can even be used for high-value applications such as cryptocurrency trading on the blockchain, digital wallet services, digital asset services on the blockchain, and executing smart contracts in conjunction with the blockchain.

[0046] Remote communication 242 can be embodied by any suitable network connection, including public networks, private networks, peer-to-peer (P2P) networks, or other suitable networks, or suitable combinations thereof. Remote communication 242 can include wired or wireless connections to a local area network (LAN) or a larger network (e.g., a wide area network (WAN), which may connect to (or embody multiple connections to) global communication networks, such as the Internet). As an example, remote communication 242 can include suitable public, private, or commercial cellular voice or data networks (e.g., second-generation (2G), third-generation (3G), fourth-generation (4G), 4G Long Term Evolution (LTE), fifth-generation (5G), and other iterations of cellular networks), microwave communication networks (e.g., WiMAX), optical laser communication networks, satellite voice or data networks, Other near-field communication (NFC) wireless networks, Wi-Fi technology networks (such as IEEE 802.11a, b, g, n, etc.), infrared communication networks, etc., or various combinations thereof. Remote communication 242 may alternatively or additionally include wired network connections, including wired network connections to global communication networks such as the Internet. Examples may include Ethernet connections (e.g., Category 3, Category 5, Category 5e, Category 6, Category 6A, etc.), coaxial cable connections, digital subscriber line connections, fiber optic cable connections, or other wired networks, or suitable combinations thereof. Furthermore, various combinations of wired and wireless networks may be incorporated into remote communication 242 (see also, for example, below). Figure 11 ).

[0047] Communication environment 200 depicts a mobile device 220 connected to blockchain network 210 via remote communication 242. In one embodiment, mobile device 220 may be a standalone device or a node in a second network at least partially different from blockchain network 210. For example, the second network may be a peer-to-peer network, a local area network, a wide area network, a private network, a public network, another blockchain network, or a suitable combination of the foregoing. Blockchain network 210 may be a decentralized interconnection of processing devices executing blockchain application 212 (e.g., a first cryptocurrency blockchain application, a second cryptocurrency blockchain application, etc.) and communicatively coupled to one or more networks (such as the Internet, other public networks, private networks, and combinations thereof). Blockchain network 210 may also include one or more cloud devices, server devices (including various enterprise hardware), and consumer processing devices or edge devices.

[0048] Mobile device 220 can communicate with hardware identifier device 230 via local-only communication 244. Local-only communication 244 can be a physical connection or a wireless connection. A physical connection can be any suitable form factor, such as removable media devices (e.g., USB removable media, memory card removable media such as CompactFlash, Memory Stick, Secure Digital (SD), and various iterations such as mini-SD, micro-SD, etc.), peripheral device connections (e.g., USB peripheral connections, serial connections, parallel connections), etc. A wireless connection can be a local area network (LAN) (such as a WiFi connection), or it can be a personal area network, NFC connection, Bluetooth connection, etc.

[0049] Hardware identifier device 230 may contain identifier data that is unique or substantially unique to hardware identifier device 230 (generally referred to herein as proof of origin (PoO) data 232). Substantially unique data may include data with a high statistical probability of being unique, without excluding the mathematical possibility of replication. Large sequences of data may serve as suitable PoO data 232 that are unique to hardware identifier device 230, even if such sequences are theoretically (or practically) reproducible.

[0050] As used herein, PoO data 232 can be used, at least partially, by blockchain nodes of blockchain network 210 to verify hardware identifier device 230 (and optionally mobile device 220, e.g., through a proxy). Therefore, hardware identifier device 230 can be used as a verifiable and trusted hardware device (e.g., a hardware blockchain device, a hardware cryptocurrency wallet device, a hardware digital currency or digital asset device, etc.), thereby eliminating the need for mobile device 220 itself to be a trusted device. In one or more embodiments, hardware identifier device 230 may include embedded ReMEM. Embedded ReMEM can be utilized to generate PUF data or TRNG data that is unique or substantially unique to the embedded ReMEM of hardware identifier device 230, to be used as PoO data 232. This PUF / PoO data 232 is (substantially) unique to the embedded ReMEM of hardware identifier device 230, and can establish proof of ownership of hardware identifier device 230 and proof of origin of communications protected by proof of origin data 232. Therefore, PoO data 232 can confirm that mobile device 220 is not a counterfeit entity, but represents genuine computing hardware connected to blockchain network 210. In alternative or additional embodiments of this disclosure, the hardware identifier device 230 may include an embedded metal-oxide-semiconductor (MOS) transistor, which may be used to generate PUF data or TRNG data that is unique or substantially unique to both the embedded MOS transistor and the hardware identifier device 230. In such embodiments, this PUF or TRNG data generated from the embedded MOS transistor may be used as PoO data 232. In still other embodiments, the hardware identifier device 230 may include an embedded static random access memory (SRAM), which may be used to generate PUF data or TRNG data that is unique or substantially unique to both the embedded SRAM and the hardware identifier device 230, which may be used as PoO data 232 in at least some of such embodiments.

[0051] In another embodiment, mobile device 220 (or hardware identifier device 230) may operate in conjunction with blockchain network 210 to generate MPC security data for protecting communication between such devices via remote communication 242. As an example, the MPC algorithm may be generated by mobile device 220 (or hardware identifier device 230) in conjunction with nodes of blockchain network 210 (and optionally one or more alternative or additional devices—not depicted, but see below). Figure 4 and Figure 5The secure data shares are then used to generate various secure data shares. These secure data shares can then be used to encrypt and decrypt data at various edge devices (e.g., mobile device 220 and nodes of the blockchain network 210) via MPC encryption algorithms. This facilitates node-to-node encryption via remote communication 242. Therefore, PoO data 232 enables the blockchain network 210 to verify the hardware identifier device 230 as a trusted device and participate with the mobile device 220 even in application-level communications that might otherwise compromise nodes of the blockchain network 210. Thus, advanced applications such as client-server interactions can be seamlessly implemented between the blockchain network 210 and the mobile device 220. In a first client-server interaction, the mobile device 220 can be a client of a node of the blockchain network 210, while in a second client-server interaction, a node of the blockchain network 210 can be a client of the mobile device 220. The mobile device 220 can provide services to individual client nodes of the peer-to-peer network in a third client-server interaction, including providing blockchain application services to client nodes in conjunction with the blockchain network 210. In other words, the communication environment 200 can facilitate seamless interaction and collaboration between node devices and peer node devices, blockchain node devices, and combinations thereof on insecure networks, acting as client devices, server devices, or both. This maximizes the efficiency and effectiveness of decentralized hardware in providing application services between decentralized hardware devices in network communication.

[0052] As an illustrative example, blockchain network 210 may include an application embodying blockchain application 212. Blockchain application 212 enables nodes of blockchain network 210 to operate as server devices, providing blockchain data services via remote communication 242. Mobile device 220 may include P2P application 222, which enables mobile device 220 to act as a peer-to-peer network (e.g., see below). Figure 4 The mobile device 220 may also include a blockchain / wallet application 224 configured to operate as a server node, which provides blockchain services in conjunction with the blockchain network 210. Example blockchain services may include digital wallet services, cryptocurrency trading services, smart contract services utilizing blockchain, web survey application services combining smart contract services and blockchain, or suitable combinations thereof.

[0053] Figure 3This is a block diagram illustrating an exemplary hardware identifier device 300 according to various aspects of the disclosed embodiments. In one or more aspects, the hardware identifier device 300 may be embodied on a single monolithic chip. As a result, a common physical countermeasures shield (PCM shield) 350 may protect data and communications stored at the hardware identifier device 300. In some of the disclosed aspects, components of the hardware identifier device 300 may communicate only within the monolithic chip, protecting in-chip communications from unauthorized access and enhancing the reliability of data security. Data transmitted from the hardware identifier device 300 may be restricted by instructions stored in embedded memory 322 or by conditions set at access control 357, or both. In one or more embodiments, the hardware identifier device 300 may perform the functions described above. Figure 2 The hardware identifier device 230 disclosed in the communication environment 200 has functions, although the hardware identifier device 300 is not limited to the functions disclosed in the communication environment 200.

[0054] As shown in the figure, the hardware identifier device 300 may include a microcontroller unit (MCU) 320 and volatile memory 310, as well as an MCU bus 315 for storing and retrieving operational data 312 at the volatile memory 310. The MCU 320 may include embedded memory 322 (volatile or non-volatile), which in some embodiments may include on-chip non-volatile ReMEM. The volatile memory 310 may be used for operational data 312 associated with software or logic executed at the MCU 320. The embedded memory 322 may store logic or code for interacting with the secure element 330 via the SE bus 355. In some aspects, the logic or code may specify rules for complying with access control 357 restrictions for interacting with the secure element 330. Such restrictions may include providing verification data to verify that the MCU 320 is authorized to interact with the secure element 330, or verification data to verify that the core of the MCU 320 (e.g., in the case of a multi-core processing device) is authorized to interact with the secure element 330, or verification data to verify that processes, threads, etc., executed by the (authorized) core of the MCU 320 are authorized to interact with the secure element 330, as defined by access control 357 on the SE bus 355. The embedded memory 322 may include instructions for authorized cores, processes, threads, etc., to access the secret storage 334 of the embedded ReMEM 332 within the secure element 330. Embedded memory 322 may also include instructions for implementing the disclosed functions, such as instructions for generating PUF data (or TRNG data) as identifier or proof of origin (PoO) data for hardware identifier device 300, instructions for retrieving PoO data to verify the proof of possession, instructions for digitally signing data using PoO data to encrypt digitally signed data (e.g., as part of communication for a device coupled to hardware identifier device 300), and instructions for signing data using PoO data or using another device (e.g., a remote device, such as hereinafter). Figure 2 The instructions for digitally decrypting the second PoO data signature of a node in the blockchain network 210 (e.g., in communication with a device coupled to hardware identifier device 300), as well as other suitable identifier functions, proof-of-origin functions, root of trust functions, encryption functions, or security functions for protecting data or communications on an insecure network. Secret storage 334 can be defined as part of a non-volatile embedded ReREM 332 to store identifier data, proof-of-origin data, encryption keys or MPC key sharing, data or algorithms used to implement digital signatures or decrypt digital signature data, etc.

[0055] By generating (e.g., via PUF write commands or TRNG write commands), storing, or retrieving secure data, the MCU 320 can communicate with the secure element 330 via the SE bus 355 without exposing such communication outside the PCM shield 350. As disclosed herein, in various embodiments, the MCU 320 and volatile memory 310 can be embedded together with the secure element 330 (and its sub-components) in a single monolithic chip on a single substrate. This monolithic integration enhances the security of communication between the MCU 320 and the secure element 330.

[0056] Hardware identifier device 300 may include interfaces for use with computing devices (e.g., mobile device 220, nodes of blockchain network 210, nodes of peer-to-peer networks, see examples below). Figure 4 and Figure 5 The physical interface 345 is used for short-range communication coupling. The physical interface 345 may be limited to hardware communication protocols, such as short-range wired communication protocols (e.g., Universal Serial Bus (USB), Ethernet bus, FireWire (IEEE 1394) bus, Serial Peripheral Interface (SPI), parallel interface, optical communication interface, etc.; see below). Figure 11 In alternative or additional embodiments, an optional communication interface 340 may be provided. The optional communication interface 340 may be limited to a short-range wireless interface, such as a Wi-Fi interface. Interfaces, personal area networks (PANs), NFC interfaces, or similar interfaces. In at least one embodiment, the optional communication interface 340 may be a dedicated and limited wide area network interface (e.g., a limited Internet connection) that has only a set of target Internet Protocol addresses that allow communication, such as the IP address of a server device of a cloud service provider (e.g., a trusted manufacturer server device of the manufacturer of hardware identifier device 300—not depicted). Such an optional communication interface 340 may be used to connect to a backup or recovery server to retrieve stored backup secure data, such as a backup of secret storage data 334, or a backup of an MPC key share that, when coupled at least partially with a key share stored at secret storage 334, can facilitate the execution of an MPC digital signature algorithm to encrypt or decrypt data using multiple MPC key shares (e.g., see above-incorporated by reference U.S. Patent Application No. 18 / 753,784).

[0057] Figure 4 This is an exemplary peer-to-peer (P2P) network 400 according to another embodiment of this disclosure. The P2P network 400 can be protected using a corresponding proof-of-origin device provided to each computing device operating within the P2P network 400. The proof-of-origin device may include, for example... Figure 2 Hardware identifier device 230, Figure 3 Hardware identifier device 300 or Figure 6 The hardware application device 600, or any suitable combination thereof. The proof-of-origin device can serve as proof of possession of electronic hardware to mitigate device forgery on the P2P network 400. For example, a computing device can provide proof-of-origin data from a connected proof-of-origin device to any other computing device connected to the P2P network 400. In some embodiments, the proof-of-origin data can be verified to prove that a network node is connected to actual computing hardware and not a fabricated number. The proof-of-origin data can be verified using any suitable modality. Examples include: looking up the proof-of-origin data at a server device of a trusted manufacturer (e.g., verifying that the proof-of-origin data matches a device provided by an certified manufacturer), referencing stored proof-of-origin data located in secure storage, or a suitable combination thereof.

[0058] In some aspects of the disclosed embodiments, proof-of-origin data can be used to facilitate multi-party computation algorithms among multiple computing devices in the P2P network 400. For example, corresponding proof-of-origin data for multiple hardware identifier devices can be used to generate an MPC encryption key share via an MPC key sharing generation algorithm. The MPC encryption key share can be used by associated computing devices for data transmission encryption between computing devices on the P2P network 400. In one or more embodiments, different subsets of computing devices can generate different MPC encryption keys on demand, and there is no limitation. Therefore, device authentication and data encryption can be on-demand functions of the P2P network 400, allowing devices to connect to and disconnect from the P2P network 400 without restriction. When connecting, a proof-of-origin request can be provided to prove that each node connected to the P2P network 400 holds a (valid) proof-of-origin device. An encryption key share can then be generated together with the interconnected devices, facilitating an on-demand encryption environment. Thus, each node of the P2P network 400 can operate as a trusted device. This allows the nodes of the P2P network 400 to dynamically establish client-server relationships, even for high-value services such as blockchain applications, digital wallet applications, cryptocurrency applications, and smart contract applications.

[0059] As a more specific example, MPC secure data can be generated by smartphone 402B in conjunction with one or more other nodes of P2P network 400. As an example, the MPC algorithm can be adopted by smartphone 402B (or PoO device 412B) in conjunction with another node of P2P network 400 to generate various secure data shares between such devices. The secure data shares can then be used to encrypt and decrypt data at various node devices (e.g., smartphone 402B and cloud server 402D; smartphone 402B, mobile device 402C, PoO device 412B and PoO device 412C, and other suitable combinations) using the MPC encryption algorithm. One or more PoO devices can also participate in MPC key generation. In at least one embodiment, smartphone 402B can generate MPC key shares with one or more PoO devices 412B directly coupled to smartphone 402B as an alternative to other nodes of P2P network 400. However, typically, various suitable combinations of node devices and PoO devices in a P2P network 400 can participate in MPC key sharing generation to encrypt transmissions between nodes of the P2P network 400.

[0060] As shown in the figure, the P2P network 400 includes a personal computer 402A and an associated Proof of Origin (PoO) device 412A, as well as various other types of computing devices. These include a cloud server 402D and PoO device 412D, a smartphone 402B and PoO device 412B, and mobile devices 402C and PoO device 412C. Similarly, a cellular phone 402F and PoO device 412F, and a laptop computer 402E and PoO device 412E are also shown. Computing devices 402A, 402B, 402C, 402D, 402E, and 402F are collectively referred to below as computing devices 402A-402F, and PoO devices 412A, 412B, 412C, 412D, 412E, and 412F are collectively referred to below as PoO devices 412A-412F. The number of computing devices 402A-402F connected to the P2P network 400 can theoretically be unlimited, limited only by the availability of network hardware (or software, firmware, etc.) for interconnecting the devices. Furthermore, various computing devices 402A-402F can be connected via different network connectivity modes, including cellular networks, public switched telephone networks (PSTN), DSL networks, cable networks, fiber optic networks, private LANs and WANs, the Internet, and other suitable networks known in the art or reasonably conveyed to a person skilled in the art through the context provided herein. The P2P network 400 can be coupled to one or more service networks, such as blockchain networks and application service networks (see below for example). Figure 5In another embodiment, one or more of the computing devices 402A-402F may be application service computing devices or gateway devices to an application service network, or other suitable connections to shared, networked, or bundled application computing services.

[0061] Because the P2P network 400 uses PoO devices 412A-412F to verify and authenticate nodes connected to it, computing devices 402A-402F can be interchangeable on the P2P network 400. Therefore, a person owning a PoO device 412F can use a cellular phone 402F to connect to and interact with other computers 402A-402F on the P2P network 400, or can exchange the cellular phone 402F for another suitable computing device (laptop, tablet, smartphone, desktop computer, server, enterprise hardware, etc.). Furthermore, computing devices 402A-402F owning PoO devices 412F can participate in client-server interactions with other computers 402A-402F (and PoO devices 412A-412F)—including acting as a client in a client-server relationship, as a server in a client-server relationship, or a combination thereof. By proving ownership of PoO device 412F, different computing devices can be used for computing device 402F on P2P network 400. These computing devices are configured for communication in a network environment (e.g., Internet Protocol (IP) network, Transmission Control Protocol (TCP) network, Transmission Control Protocol / Internet Protocol (TCP / IP) network, cellular interconnection network, satellite communication network, or any other suitable interconnection mechanism for computing devices 402A-402F). In other words, the authentication of nodes connected to P2P network 400 can be independent of computing devices 402A-402F and alternatively dependent on PoO devices 412A-412F. Proof of ownership of PoO devices 412A-412F can be used as a proxy for proof of user / ownership, rather than (or at least in addition to) computing devices 402A-402F.

[0062] Figure 5 This is a block diagram of an exemplary secure peer-to-peer network and blockchain 500 according to another embodiment of the present disclosure. An application-enabled secure P2P network 505 is shown, which can substantially be as described above. Figure 4The P2P network 500 is described at section 400. The P2P network 500 is integrated with (or partially forms) a blockchain having one or more blockchain components 530. For example, a node in the application-enabled secure P2P network 505 can also be a blockchain node containing one or more blockchain components 530. As another example, a node in the application-enabled secure P2P network 505 can be communicatively coupled to a blockchain node containing blockchain components 530. Suitable combinations of the foregoing can be implemented within the scope of this disclosure.

[0063] The blockchain containing blockchain component 530 can be any suitable blockchain, such as a cryptocurrency blockchain (e.g., a first cryptocurrency blockchain, a second cryptocurrency blockchain, etc.), and can be integrated with a third-party integration application service 510. Integration application service 510 may include a (software) wallet service 512, a blockchain oracle service 514 (e.g., for providing trusted real-world data to blockchain component 530 managed, governed, or facilitated by various smart contracts 540), a delegation service 515, a DePIN service 516, a blockchain verification service 518, etc. In at least some embodiments, one or more integration application services 510 may be provided by computing devices 402A-402F of the P2P network 500, utilizing proof-of-holding and device verification available through associated PoO devices 412A-412F. Typically, integration application 510 is provided by enterprise-grade hardware components.

[0064] In addition to the integrated application 510 (provided on enterprise hardware), the secure P2P network 500 may include a peer-to-peer application 520. The peer-to-peer application 520 can run on nodes of the application-enabled secure P2P network 505. These peer nodes can include any computing devices 402A-402F. Due to the secure environment provided by the secure P2P network 500, the peer-to-peer application 520 may also include services provided by the integrated application 510, including (software) blockchain wallet services 522, cryptocurrency trading services 524, digital asset (trading) services 526, smart contract services 528, and other services 529, as well as combinations thereof. Nodes of the application-enabled secure P2P network 505 may utilize other peer nodes for the peer-to-peer application 520, may utilize the services of the integrated application 510, or both.

[0065] Suitable examples of a smart contract service 528 that can be implemented at a peer-to-peer application 520 in an application-enabled secure P2P network 505 may include an online survey service. The online survey service may distribute data requests to computing devices 402A-402F and, upon receiving data that satisfies the data request, allocate digital assets (e.g., cryptocurrency, digital token, digital coupon, etc.) to an account associated with computing devices 402A-402F. The survey service may include conditions, digital tokens, and user accounts specified in blockchain component 530 (see below), or may be defined solely by the peer-to-peer application smart contract service 528. Data may be encrypted during transmission between nodes in the application-enabled secure P2P network 505 and blockchain nodes in the blockchain network. For example, digital asset transactions involving cryptocurrencies (e.g., a first cryptocurrency, a second cryptocurrency, etc.) with a dedicated blockchain may be reported by computing devices 402A-402F to nodes of the corresponding blockchain for broadcast on said blockchain, as is known in the art. The online survey service can, where appropriate, coordinate with a smart contract 540 containing a blockchain component 530, for example, to ensure that prior conditions are properly met (e.g., data satisfying a data request is received) and to appropriately distribute rewards to users who satisfy data requests (e.g., transferring cryptocurrency tokens 546 to an account on a vault 544 associated with computing devices 402A-402F), where the smart contract service 528 utilizes cryptocurrency with a dedicated blockchain. The proof-of-origin data of PoO devices 412A-412F can also facilitate the submission of subsequent data requests to computing devices 402A-402F, as well as (anonymous) Know Your Customer (KYC) applications, without requiring users of the computing devices to relinquish private information such as names, email addresses, phone numbers, etc. Furthermore, the proof-of-origin data of PoO devices 412A-412F can substantially mitigate or avoid fraudulent survey requests from bot accounts and the unintended activation of smart contract resources (e.g., cryptocurrency, digital tokens, digital coupons, etc.) on counterfeit computing devices, bot devices, or other devices not associated with actual users.

[0066] The peer-to-peer node application 520 can interoperate with the integration application 510 and the blockchain component 530, creating a very robust and dynamic service environment. The blockchain component 530, governed by the smart contract 540 (or peer-to-peer smart contract service 528), may include a decentralized autonomous organization (DAO) 542 and a vault service 544 for storing digital assets (such as user cryptocurrencies (e.g., cryptocurrency tokens 546)) in associated user accounts (e.g., allocated to PoO devices 412A-412F, or allocated to computing devices 412A-412F or users, as applicable), which are also managed by the smart contract 540 (or peer-to-peer smart contract service 528). The smart contract 540 may control the bridging component 548 for interconnecting different blockchains and transactions between blockchains (e.g., the bridging component 548 between a first cryptocurrency blockchain and a second cryptocurrency blockchain is an illustrative example in the cryptocurrency field), as well as for combining the integration application 510 and the peer node application 520 with such blockchains, and other components 549, which will be obvious to those skilled in the art or reasonably conveyed to those skilled in the art through the context provided herein.

[0067] Figure 6 This is a block diagram of an exemplary integrated circuit device implemented on a single monolithic chip as a hardware identifier and application device (hereinafter referred to as hardware application device) 600, according to various aspects of this disclosure. Hardware application device 600 can be used as a proof-of-origin device (e.g., similar to the one described above). Figure 2 Hardware identifier device 230 or Figure 3 The hardware application device 600 (hardware identifier device 300), as described herein. Furthermore, the hardware application device 600 may include executable logic and memory for storing application instructions to implement application functionality at the hardware application device 600. As an example, the hardware application device 600 may include executable logic and memory having instructions for storing and calculating cryptocurrency assets in secure memory, instructions for facilitating cryptocurrency transactions, or other suitable cryptocurrency or blockchain functionality. For example, example blockchain or cryptocurrency application functionality may include: blockchain transaction functionality, blockchain transaction verification functionality, digital token transaction service, digital token transaction verification service, application services involving smart contracts (such as data survey service functionality, decentralized data storage service, data storage compression and decompression functionality, decentralized computing service, DePIN service, etc.), and combinations thereof. Such functionality can be implemented internally to the hardware application device 600 and can represent client devices directly coupled to the hardware application device 600 (e.g., Figure 2This can be implemented via a mobile device 220, or it can represent a remote client device (e.g., computing devices 402A-402F) within the secure P2P network 400, or other networks. In other words, the computing device (e.g., mobile device 220) operates as a server device, establishing a client-server relationship with client devices (e.g., nodes of the blockchain network 210) via remote communication 242. Its server functions can be partially or entirely outsourced to the hardware application device 600 via physical interface 655 (or optional dedicated and limited communication interface 650), through physical interface 655.

[0068] As shown in the figure, the hardware application device 600 may include a microcontroller unit (MCU) 630, on-chip non-volatile memory 620 (e.g., resistive memory: ReMEM, phase-change memory (PCM), programmable metallized memory, magnetoresistive memory (MRAM), etc., hereinafter referred to as on-chip ReMEM 620 for convenience), and volatile memory 610. In one or more embodiments, the MCU 630 may include embedded memory 632 (volatile or non-volatile), which may include at least a portion of the on-chip ReMEM 620, or in another embodiment may be separate from and in addition to the on-chip ReMEM 620. The on-chip ReMEM 620 may store application code for execution at the MCU 630. The volatile memory 610 may be used for operational data associated with the application code executing at the MCU 630, and where appropriate, at least a portion of it may also be stored at the embedded memory 632.

[0069] In conjunction with executing encrypted applications, the MCU 630 can communicate with the secure element 640. As disclosed herein, in various embodiments, the MCU 630, on-chip ReMEM 620, and volatile memory 610 can be embedded together with the secure element 640 (and its sub-components) in a single monolithic chip on a single substrate. This monolithic integration enhances the security of communication between the MCU 630 and the secure element 640. Furthermore, the secure element 640 may include hardware-coded security, secret data, or cryptocurrency-related algorithms 642 (which may include, for example, digital signature algorithms, signature verification algorithms, blockchain verification algorithms, PUF data generation algorithms, MPC key sharing generation algorithms, MPC digital signature and signature verification algorithms, MPC encryption and decryption algorithms, etc.), or other algorithms for application security, user security, digital asset security, or digital transaction security, or suitable combinations thereof, hereinafter referred to as hardware-coded security algorithm 642 for convenience.

[0070] The hardware-coded security algorithm 642 can be primarily (though not necessarily exclusively) implemented during manufacturing. Hardware coding can include hardware-assisted security algorithms and hardware-accelerated security algorithms, or suitable combinations thereof. This makes algorithms executed by the hardware-coded security algorithm 642 largely immune to software-based malware, providing significant security. Furthermore, in some cases, hardware coding can achieve processing times far faster than software processors, sometimes by 10 times or more. Therefore, as a general feature, the hardware-coded security algorithm 642 can significantly enhance the performance and security of computations performed at the hardware application device 600.

[0071] Hardware-coded logical primitives (also known as atomic operations) can be executed independently to produce results (e.g., the result of an atomic algorithm or atomic operation). Furthermore, these atomic operations can also be combined (e.g., executed sequentially) to produce another algorithm, which, in this paper, can be referred to as a molecular operation (combining multiple atomic operations) by extending the atomic analogy. This other algorithm is typically more complex because it combines multiple atomic operations. Moreover, atomic operations can be combined in different sequences to produce other (unique) molecular operations different from the previous molecular operations. Therefore, encoding multiple hardware logic segments to implement a set of atomic operations can be utilized by the MCU630 to execute a fairly diverse set of algorithms, including cryptographic algorithms, blockchain algorithms, service application algorithms (e.g., peer-to-peer application 520), security authentication or verification algorithms, etc. As a brief illustrative example, three logical primitives can be defined separately: a user authentication process, a cryptocurrency hash algorithm, and the verification of cryptocurrency transactions (although each primitive can define a subset of one or more of these algorithms and be combined sequentially to implement a single algorithm). When executed individually, they perform their respective functions. However, when combined and executed sequentially, they perform more complex functions. For example, the three combined logical primitives can be used to achieve: user authentication, cryptocurrency hash calculation, and cryptocurrency transaction verification.

[0072] The hardware-coded security algorithm 642 can be executed in response to a command received from the MCU 630 at the security element 640. When embodying cryptographic primitives, the hardware-coded security algorithm 642 can receive a command (or command parameters) specifying the sequence order of multiple primitives that implement an algorithm more complex than a single primitive. Furthermore, as described herein or known in the art, or reasonably conveyed to those skilled in the art through the context provided herein, different subsets or sequences or combinations thereof of primitives can each implement different algorithms.

[0073] In a specific example, the hardware-encoded security algorithm 642 may include hardware logic encoding an MPC digital signature and signature verification algorithm (hereinafter referred to as MPC signature and verification algorithm 643A). MPC signature and verification algorithm 643A can be used to generate or participate in the generation of secret data and secret data segments for MPC digital signature applications and MPC signature verification applications (e.g., key sharing). By encoding the MPC signature and verification algorithm 643A in hardware-encoded logic, even as a set of logic primitives described above, the highly intensive MPC digital signature and MPC signature verification process can be executed quickly and efficiently, enhancing the user experience of such processes when utilizing hardware application device 600. The hardware-coded security algorithm 642 may also include a zero-knowledge proof (ZKP) algorithm 643B, an authentication algorithm such as FIDO2 643C, a post-quantum cryptography (PQC) algorithm 643D (in cases where appropriate, in addition to the MPC signature and verification algorithm 643A, the ZKP algorithm 643B, and the authentication algorithm 643C), and other suitable algorithms known in the art or reasonably conveyed to a person skilled in the art through the context disclosed herein. Furthermore, the hardware logic 643E associated with the peer node application 520 may also be implemented within the hardware-coded security algorithm 642.

[0074] Illustrative examples of algorithms that can be encoded into the hardware-coded security algorithm 642 may include public-key signature algorithms, authentication and keyderivation algorithms, key agreement algorithms, hash algorithms, encryption algorithms, secret-sharing algorithms, homomorphic encryption algorithms, atomic accelerations of the ZKP algorithm 643B, and suitable combinations thereof. As another (but not limiting) example, public-key signature algorithms may include elliptic curve digital signature algorithms (ECDSA), Schnorr signature algorithms, Edwards-curve digital signature algorithms (EdDSA), etc. Authentication and key derivation algorithms may include (but are not limited to): hash-based message authentication codes (HMAC) and cryptographic key derivation functions 1 (PBKDF1) or PBKDF2. Suitable key exchange algorithms could include the Elliptic Curve Diffie-Hellman (ECDH) algorithm, while suitable hash algorithms could include: secure hash algorithm (SHA), SHA-0, SHA-1, SHA-2, SHA-3, European Research and Development in Civil Engineering (RACE) Integrity Primitives Evaluation (RIPE) Message Digest Algorithm (RIPEMD) 160 (RIPEMD-160), RIPEMD-256, RIPEMD-320, BLAKE2, BLAKE3, BLAKE-256, BLAKE-224, BLAKE-512, BLAKE-384, etc. Furthermore, suitable encryption algorithms could include: Advanced Encryption Standard (AES), ChaCha20, Salsa20, Poly1305, ChaCha20-Poly1305, etc. Secret sharing algorithms may include Shamir's secretsharing (SSS), verifiable secret sharing (VSS), and others, and homomorphic encryption may include the Paillier cryptosystem, etc.

[0075] Secure element 640 may include embedded ReMEM 646. Embedded ReMEM 646 may include secret storage 648, which includes secret data (e.g., identifier data, proof of origin data, root of trust data, derived data derived from the root of trust data (e.g., a hash of the root of trust data), PUF data, etc.). In at least one embodiment, embedded ReMEM 646 may optionally be configured to be unreadable / unwritable to prevent access to secret storage 648. In such an embodiment, embedded ReMEM 646 may have limited processing logic to handle simple queries associated with the secret data stored in secret storage 648 without exposing the secret data outside embedded ReMEM 646. Simple queries may verify hash algorithms, verify encryption / decryption results, etc., initiated using or in combination with secret data (e.g., in an MPC algorithm that partially utilizes secret data and other secret data). In other embodiments, embedded ReMEM 646 may allow access to secret storage 648 on a limited basis. For example, in one embodiment, hardware-coded security algorithm 642 may be allowed to access secret storage 648, but nothing outside secure element 640 may be allowed. In such embodiments, the secure element 640 (or embedded ReMEM 646) can be configured to distinguish between commands, data requests, etc., originating from the hardware-coded secure algorithm 642 and requests originating from outside the secure element 640. In other embodiments, this distinction can be implemented at access control 647 (see below). In still other embodiments, a subset of the secret store 648 (such as proof of origin data) can be authorized for transmission from hardware application device 600 (e.g., on physical interface 655 or optional dedicated and limited communication interface 650) to verify associated computing devices (e.g., computing devices 402A-402F) on the network, while other data is confined to MCU 630 or to hardware algorithm 642, etc.

[0076] In some embodiments, the embedded ReMEM 646 may include circuitry for in-memory processing (or PIM). The PIM circuitry may be incorporated within the embedded ReMEM 646 to facilitate one or more logical or mathematical operations or sequences of logical or mathematical operations within or adjacent to the array structure of the embedded ReMEM 646 (e.g., coupled to sensing circuitry, etc.). In some embodiments, the PIM circuitry may respond to a hardware-coded security algorithm 642 of the secure element 640, or in another embodiment, to a command from the MCU 630 (authorized by access control 647).

[0077] In one or more embodiments, the security element 640 may include optional volatile memory 644. Optional volatile memory 644 can be used as working memory to store values, logical states, logical conditions, etc., of the hardware-coded security algorithm 642. As an example, where the hardware-coded security algorithm 642 involves the execution of multiple logical primitives, a data value generated by the execution of a first logical primitive (e.g., MPC signature verification) can be held in optional volatile memory 644 and accessed by subsequent logical primitives (e.g., cryptocurrency transactions relying on successful MPC signature verification) to generate a second data value, and so on.

[0078] In some embodiments of this disclosure, hardware application device 600 may include an optional communication interface 650. The optional communication interface 650 may be configured to provide limited communication with external devices or networks. This limited communication may facilitate participation in multi-party computation (MPC) algorithms, such as MPC secret data generation, MPC digital signatures or MPC signature verification, or backup or recovery of MPC key sharing. Alternatively or additionally, this limited communication may facilitate receiving and storing encrypted secret data segments (and associated decrypted data) from one or more computing devices participating in MPC secret data generation and segmentation. In yet another example, this limited communication may facilitate transferring a portion of the encrypted secret data segments generated by hardware application device 600 and the associated decrypted data to another device for backup storage. In a further example, this limited communication may facilitate logging into a recovery service and recovering the encrypted secret data segments and associated decrypted data to recover lost data from another hardware application device 600 at hardware application device 600, enabling the latter to participate in MPC algorithms, or to facilitate the recovery of such encrypted secret data segments and decrypted data for another computing device to participate in MPC algorithms. In at least some embodiments, limited communication can facilitate the verification of data stored at secret storage 648, the authentication of user credentials, the execution of cryptographic algorithms, participation in blockchain verification algorithms, or participation in multi-party computation (MPC) processes associated with or similar to any of the foregoing. In at least one disclosed aspect, such limited communication can be utilized on behalf of a client device connected to hardware application device 600 at physical interface 655, or a remote node of a secure peer-to-peer network 500 served by hardware application device 600 (or by computing devices 402A-402F coupled to hardware application device 600).

[0079] In some embodiments, a physical interface 655 is provided to communicatively couple a hardware application device to an external computing device, such as a mobile device 220, a node of a secure peer-to-peer network 400, or a node of a blockchain network 210. The physical interface 655 may employ any suitable physical communication protocol or form factor, such as short-range wired communication protocols (e.g., Universal Serial Bus (USB), Ethernet bus, FireWire (IEEE 1394) bus, High Speed ​​Serial Peripheral Interface (SPI), parallel interface, SD interface, mini-SD interface, micro-SD interface, etc.; see also below). Figure 10 In other embodiments, an optional communication interface 650 for limited or short-range wireless interfaces may be provided, such as a Wi-Fi interface. Interface, personal area network (PAN), NFC network, or similar interface. In at least one embodiment, the optional communication interface 650 may be a dedicated and limited wide area network interface (e.g., a limited Internet connection) that has only a set of target Internet Protocol addresses that allow communication, such as the IP address of a server device of a cloud service provider (e.g., an enterprise node of a secure peer-to-peer network 400, or an application service 510, etc.), for backup or recovery of MPC key-sharing data, device authentication functions, or other suitable security, backup, or recovery functions.

[0080] Internally, the hardware application device 600 may provide different communication bus structures for communication between its components. MCU bus 635 provides communication between MCU 630 and volatile memory 610 and on-chip ReMEM 620. MCU bus 635 may be an unrestricted bus, as known in the art, facilitating all suitable electronic communication between the processor and memory. Furthermore, SE bus 645 facilitates communication between MCU 630 and SE 640. In at least some embodiments, SE bus 645 may be a restricted communication bus at least partially governed by access control 647. For example, in the case where MCU 630 is a multi-core processor, SE bus 645 may be allowed by access control 647 to facilitate communication between MCU 630 and SE 640 originating from a first core of the multi-core processor (e.g., a licensed core; a core with a valid license key, etc.), and may be restricted by access control 647 to communication between MCU 630 and SE 640 originating from a second core of the multi-core processor (e.g., an unlicensed core; a core without a valid license key, etc.). As another example, access control 647 may allow communication between MCU 630 and SE 640 for an application, process, or logic thread executed by MCU 630 and authorized to communicate with SE 640, or for a process or logic executed at hardware-coded security algorithm 642 and authorized to communicate with MCU 630 or utilize MCU 630 and optional communication interface 650 to communicate with external devices (e.g., participate in MPC data generation, signing, signature verification, backup, or recovery processes), or a suitable combination of the foregoing (e.g., see above-referenced U.S. Patent Application No. 18 / 218,948). Figures 3-5 (and related written descriptions, etc.).

[0081] Figure 7 This diagram illustrates an example cryptocurrency service within a peer-to-peer network environment 700, based on alternative or additional aspects of the disclosed embodiments. In a secure peer-to-peer network (such as the one described above)... Figure 4 A non-dedicated peer node 720 is shown within the secure peer-to-peer network 400. The non-dedicated peer node 720 is not limited to trusted enterprise hardware communicatively coupled to the secure peer-to-peer network 400 and operating as a relatively permanent server device. Instead, the non-dedicated peer node 720 can be a node that connects to or disconnects from the secure peer-to-peer network 400 more frequently, and therefore may include non-enterprise hardware devices such as laptops, desktop computers, smart devices, mobile devices, and more generally, consumer computing devices, network edge devices, etc. However, when coupled to the secure peer-to-peer network 400, the non-dedicated peer node 720 may connect to other peer nodes as a client in a client-server relationship, or receive connections from other peer nodes as a server in a client-server relationship, or a combination of both.

[0082] Non-dedicated peer node 720 may include (e.g., built-in) or be connected to (e.g., via physical line, cable, fiber optic, etc., or short-range wireless connection) hardware identifier device 730. Hardware identifier device 730 may include... Figure 3 The components and functions of the hardware identifier device 300. In various aspects of the disclosed embodiments, the hardware identifier device 730 may be compatible with... Figure 6 The hardware application device 600 is substantially similar to, or similar to, other suitable devices disclosed herein, or variations thereof, which may be reasonably understood by one of ordinary skill in the art from the context provided herein. For example, the hardware identifier device 730 may include proof of origin data 732 that is unique (or substantially unique) to the hardware identifier device 730 to prove ownership of the hardware identifier device 730 to other nodes of the secure peer-to-peer network 400. Furthermore, the proof of origin data 732 may be used to generate secure data (e.g., encryption keys, MPC key sharing, etc.) to protect communication between nodes of the secure peer-to-peer network 400 and between devices outside the secure peer-to-peer network (such as mobile device 402C or nodes of the blockchain network 210).

[0083] In various aspects of the disclosed embodiments, the non-dedicated peer node 720 may include a blockchain or wallet service application 722. In the disclosed aspects, the blockchain or wallet service application 722 may include a digital wallet service component configured to provide (software) wallet services to client accounts. The client account may be associated with a mobile device 402C (or its user), or may be associated with a PoO device 230C based on PoO data 232C. Upon receiving a communication request from the mobile device 402C to access the blockchain wallet service provided by the non-dedicated peer node 720, a request 752 for proof-of-origin data may be generated and submitted to the mobile device 402C. In response to request 752, the mobile device 402C may respond using PoO data 232C that is unique (or substantially unique) to the PoO device 230C. After receiving and verifying the PoO data 232C, the non-dedicated peer node 720 may authorize control over the client account associated with the mobile device 402C (or with the PoO device 230C or its user, etc.). Such control may include disposing of cryptocurrency assets (e.g., making purchases using cryptocurrency assets associated with a client account), receiving digital tokens, purchasing cryptocurrency assets, participating in digital actions or activities that affect digital tokens or cryptocurrency assets through smart contracts, participating in digital actions or activities that affect rights to physical assets governed by smart contracts (e.g., ownership contracts for physical assets, ownership contracts for tangible assets, etc.), and other examples.

[0084] Non-dedicated peer node 720 can be communicatively coupled with blockchain nodes of blockchain network 210 via remote communication 742 to facilitate blockchain-related transactions affecting client accounts. Alternatively, blockchain or wallet service application 722 may also include a blockchain application component that, when executed at non-dedicated peer node 720, enables non-dedicated peer node 720 to operate as a blockchain node on blockchain network 210. In these aspects, non-dedicated peer node 720 may broadcast blockchain-related transactions according to blockchain rules (e.g., first cryptocurrency blockchain rules, second cryptocurrency blockchain rules, etc.) incorporated into the blockchain application component of blockchain or wallet service application 722.

[0085] The accompanying drawings contained herein are described in relation to several electronic devices, computing devices, and communication systems that facilitate communication between edge devices on insecure networks. It should be understood that such drawings may include those electronic or computing devices, communication systems, etc., specified therein, some specified devices / systems, or additional devices / systems not explicitly depicted but known in the art or reasonably understood by those skilled in the art from the context provided herein. Components of the disclosed integrated circuit devices may also be implemented as sub-components of another disclosed component (e.g., embedded memory 632 may be partially or wholly a sub-component of on-chip ReMEM 620; access control 647 may be integrated with SE bus 645, etc.), while other components disclosed as sub-components may be separate components in various embodiments (e.g., process / core control 118 may be decoupled from and communicatively connected to access control 116; embedded ReMEM 646 may be decoupled from and communicatively connected to secure element 640, etc.). Furthermore, embodiments within certain drawings of this specification may be applied, in whole or in part, to other embodiments depicted in other drawings, without limitation, solely depending on the suitability for achieving the disclosed functions or purposes as understood by those skilled in the art, and vice versa. As an illustrative (and non-limiting) example, hardware application device 600 may be used instead. Figure 2 Hardware identifier device 230 or Figure 4 Origin verification devices 412A-412F; MCU 330 (and MCU 630) can be incorporated. Figure 10Some or all of the memory array control components (e.g., row control 1004, sense amplifier 1008, column control 1006, clock source 1010, address register 1014, reference and control signal generator 1018, state machine 1020, input / output buffer 1012, command interface 1016), or suitable components of the operating and control environment 1000 or environment 1100 may replace or be added to other components or integrated circuit devices disclosed herein. Furthermore, it should be noted that one or more of the disclosed processes may be combined into a single process that provides aggregate functionality. For example, an encryption algorithm process may include a secure user / device authentication process, and vice versa, to facilitate device authentication and encrypted data transmission over an insecure network through a single process. Components of the disclosed devices and systems may also interact with one or more other components not specifically described but known or reasonably understood by those skilled in the art.

[0086] In view of the exemplary figures described above, refer to Figure 8 and Figure 9 A flowchart will provide a better understanding of the processing methods that can be implemented based on the disclosed topic. To simplify the explanation, Figure 8 and Figure 9 The methods are shown and described as a series of blocks; however, it should be understood and recognized that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in a different order than depicted and described herein or simultaneously with other blocks. Furthermore, not all shown blocks are required to implement the methods described herein, and in some embodiments, additional steps that are known or reasonably understood by one of ordinary skill in the art in the context provided herein may be implemented as part of the disclosed methods within the scope of this disclosure. Moreover, some steps shown in one process may be used in another process where appropriate; other steps in one or more processes may be added to or replace steps in other processes disclosed herein within the scope of this disclosure. Furthermore, it should be further understood that the methods disclosed throughout this specification can be stored on an article of art to facilitate the transfer of such methods to electronic devices, embedded memory stored within electronic devices, etc. As used, the term "article of art" is intended to cover a computer program accessible from any computer-readable device, a device combined with a carrier, or a storage medium, etc.

[0087] Figure 8This is a flowchart of an example method 800 for backup or recovery of digital assets according to an alternative or additional aspect of this disclosure. At 802, method 800 may include receiving a peer-to-peer (P2P) network connection request from a remote device. The remote device may be a server device, such as enterprise hardware, a laptop computer, a personal computer, a mobile device, a smartphone, a cellular phone, a tablet computer, or any other suitable computing device, computing device network, distributed computing device, etc. The connection may be an insecure network connection, or it may be a public network connection, a private network connection, a direct peer-to-peer connection, an indirect peer-to-peer connection, etc., or a suitable combination thereof. At 804, method 800 may include querying the remote device for proof-of-origin (PoO) data that is unique to the secure hardware device. The PoO data may be root trust data, data derived from root trust data, data generated from a physically unclonable function (PUF), data generated from a PUF implemented on a single chip embedded in a resistive switching memory within the secure hardware device, etc., or a suitable combination thereof. At 806, method 800 may include receiving data in response to the query and verifying whether the response data is valid PoO data. Verification may include referencing response data at a trusted hardware device (e.g., a manufacturer's web server), referencing a secure storage device containing valid PoO data, analyzing whether the PoO data conforms to a security algorithm (e.g., generating a digital signature using the PoO data, decrypting digital signature data using the PoO data, etc.), and others, or suitable combinations thereof. At 808, method 800 may include verifying a remote device in response to verifying the PoO data, and at 810, method 800 may include initiating a blockchain or wallet application service for the remote device in response to verifying the remote device.

[0088] In one embodiment, method 800 may further include (e.g., via a communication interface) establishing a second communication with a second remote device. Method 800 may further include receiving a login request from the second remote device for a second client account managing cryptocurrency assets, and sending a second query for second PoO data associated with the second client account. Furthermore, method 800 may include receiving a second response to the second query, extracting second response data from the second response, and determining whether the second response data is valid second PoO data. In response to determining that the second response data is valid second PoO data, method 800 may include authorizing the second remote device to access and control the second client account and cryptocurrency assets.

[0089] Figure 9 and Figure 9AThis is a flowchart of an exemplary method 900 according to an alternative or additional embodiment of this disclosure. At 900, method 900 may include a peer node connected to a peer-to-peer (P2P) network at a computing device. At 904, method 900 may include receiving a query for verification data from the peer node. At 906, method 900 may include retrieving the root of trust (RoT) or derived RoT data of the computing device or a connected security chip. The derived RoT data may be a hash of the RoT data or other algorithmically controlled modifications of the RoT data. At 908, method 900 may include transmitting RoT data to the peer node, and at 910, method 900 may include receiving verification confirmation from the peer-to-peer network. At 912, method 900 may include launching a blockchain or cryptocurrency application at the computing device, and at 914, method 900 may include connecting to a remote device running the blockchain or cryptocurrency application. The remote device running the blockchain or cryptocurrency application may be a blockchain node in a blockchain network. At 916, method 900 may optionally include broadcasting the application service on a peer-to-peer network or a blockchain network. At 918, method 900 may include receiving a connection to the application service from a client device. The client device may be a peer node in a peer-to-peer network, a blockchain node in a blockchain network, or other suitable remote device. At 920, method 900 may include issuing a query for PoO data from the client device, and at 922, method 900 may include receiving data in response to the query. Method 900 in Figure 9A The process continues at 924, where method 900 may further include verifying the received data. At 926, it is determined whether the received data is valid or invalid. If invalid, method 900 may proceed to 928 and may include refusing the client device access to the application service. Otherwise, if the received data is valid PoO data, method 900 may include initiating the blockchain application service for the client device at 930.

[0090] In one embodiment, verifying the received data may further include accessing a trusted server device and submitting the received data to the trusted server device. Additionally, method 900 may include receiving an acknowledgment from the trusted server device that the received data matches valid PoO data. In response to receiving this acknowledgment, method 900 may subsequently include verifying the received data as PoO data.

[0091] In an alternative embodiment, method 900 may include retrieving a set of stored PoO data stored in (secure) memory. Method 900 may further include comparing received data with the set of stored PoO data and determining whether the received data matches a PoO data instance contained in the set of stored PoO data. In response to determining that the received data matches a PoO data instance contained in the set of stored PoO data, method 900 may further include verifying the received data as PoO data.

[0092] In another alternative embodiment, method 900 may include generating a digital signature using the received data and determining whether the digital signature can be decoded using stored valid PoO data. In yet another embodiment, method 900 may include decrypting stored digital signature data using the received data to determine whether the received data is valid PoO data.

[0093] Exemplary operating environment

[0094] Figure 10 Block diagrams of an example operation and control environment 1000 for a memory array 1002 for a memory device are shown according to aspects of this disclosure. In some embodiments, the control environment 1000 and the memory array 1002 may be formed within a single semiconductor die, although this disclosure is not limited thereto, and in other embodiments, some components of the control environment 1000 may be formed on a separate semiconductor die communicatively connected to said semiconductor die. In at least one aspect of this disclosure, the memory array 1002 may include memory selected from a variety of memory cell technologies. In at least one embodiment, the memory array 1002 may include two-ended memory technology arranged in a compact two-dimensional or three-dimensional architecture. Suitable two-ended memory technologies may include resistive switching memory, conductive bridged memory, phase-change memory, organic memory, magnetoresistive memory, etc., or suitable combinations thereof. In a further embodiment, the two-ended memory technology may be two-ended resistive switching technology.

[0095] Column controller 1006 and sense amplifier 1008 may be formed near memory array 1002. Furthermore, column controller 1006 may be configured to activate (or identify for activation) a subset of bit lines of memory array 1002. Column controller 1006 may activate and operate the individual bit lines of the bit line subset using control signals provided by reference and control signal generator 1018, applying appropriate programming, erasing, or read voltages to those bit lines. Inactive bit lines may be held at an inhibit voltage (also applied by reference and control signal generator 1018) to mitigate or avoid bit interference effects on these inactive bit lines.

[0096] Furthermore, the operating and control environment 1000 may include a row controller 1004. The row controller 1004 may be formed near and electrically connected to the word lines of the memory array 1002. The row controller 1004 also utilizes control signals from the reference and control signal generator 1018 to select one or more rows of memory cells with an appropriate selection voltage. Furthermore, the row controller 1004 can facilitate programming, erasing, or reading operations by applying an appropriate voltage at the selected word line.

[0097] The sensing amplifier 1008 can read data from or write data to the active memory cells of the memory array 1002 selected by column control 1006 and row control 1004. Data read from the memory array 1002 can be provided to the input / output buffer 1012. Similarly, data to be written to the memory array 1002 can be received from the input / output buffer 1012 and written to the active memory cells of the memory array 1002.

[0098] Clock source 1010 can provide corresponding clock pulses to facilitate the timing of read, write, and programming operations of row controller 1004 and column controller 1006. Clock source 1010 can further facilitate the selection of word lines or bit lines in response to external or internal commands received by operating and control environment 1000. Input / output buffer 1012 can include command and address inputs, as well as bidirectional data inputs and outputs. Instructions are provided via command and address inputs, and data to be written to and read from memory array 1002 is transferred on bidirectional data inputs and outputs, facilitating connection to external host devices, such as computers or other processing devices (not depicted, but see below for example). Figure 11 Computer 1102).

[0099] The input / output buffer 1012 can be configured to receive write data, receive erase commands, receive status or maintenance commands, output read data, output status information, and receive address data and command data, as well as address data for each command. Address data can be transmitted to the row controller 1004 and column controller 1006 via the address register 1014. Furthermore, input data is transmitted to the memory array 1002 via the signal input line between the sense amplifier 1008 and the input / output buffer 1012, and output data is received from the memory array 1002 via the signal output line from the sense amplifier 1008 to the input / output buffer 1012. Input data can be received from the host device, and output data can be transmitted to the host device via the I / O bus.

[0100] Commands received from the host device can be provided to command interface 1016. Command interface 1016 can be configured to receive external control signals from the host device and determine whether the data input to input / output buffer 1012 is write data, a command, or an address. Input commands can be transmitted to state machine 1020.

[0101] State machine 1020 is configurable to manage the programming and reprogramming of memory array 1002 (and other memory banks of multiple memory arrays). Instructions provided to state machine 1020 are implemented according to control logic configuration, enabling state machine 1020 to manage read, write, erase, data input, data output, and other functions associated with memory cell array 1002. In some aspects, state machine 1020 can send and receive acknowledgments and negative acknowledgments regarding the successful reception or execution of various commands. In further embodiments, state machine 1020 can decode and implement state-related commands, decode and implement configuration commands, etc.

[0102] To perform functions such as reading, writing, erasing, input, and output, state machine 1020 can control clock source 1010 or reference and control signal generator 1018. Control of clock source 1010 can cause output pulses to be configured to enable row controller 1004 and column controller 1006 to perform specific functions. For example, output pulses can be transmitted to selected bit lines via column controller 1006 or to word lines via row controller 1004.

[0103] about Figure 11 The systems, devices, and / or processes described herein may be embodied in hardware, such as a single integrated circuit (IC) chip, multiple ICs, application-specific integrated circuits (ASICs), one or more computing devices, one or more server devices, or arrays of server devices (such as those implemented in networked server (or cloud) services). Furthermore, the order in which some or all process blocks appear in each process should not be considered restrictive. Rather, it should be understood that some process blocks may be executed in multiple orders, and not all orders are explicitly shown herein.

[0104] refer to Figure 11 A suitable environment 1100 for implementing various aspects of the claimed subject matter includes a computer 1102. The computer 1102 includes a processing unit 1104, system memory 1110, a codec 1114, and a system bus 1108. The system bus 1108 couples system components (including, but not limited to, system memory 1110) to the processing unit 1104. The processing unit 1104 can be any of a variety of available processors. Dual microprocessors and other multiprocessor architectures may also be used as the processing unit 1104.

[0105] The system bus 1108 can be any of several types of bus architectures, including memory bus or memory controller, peripheral bus or external bus, or using various available bus architectures (including but not limited to Industry Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronic Devices (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), PCMCIA Bus, FireWire (IEEE 1394), Small Computer System Interface (SCSI), Compute eXpress Link (CXL), High Speed ​​Serial Peripheral Interface (SPI) interface (e.g., HyperFlash, etc.), Internal Integrated Circuit (I... 2 C) Communication protocol, I 3 Local buses (such as C protocol, etc.).

[0106] System memory 1110 includes volatile memory 1110A and non-volatile memory 1110B. The Basic Input / Output System (BIOS), containing basic routines for transferring information (such as during startup) between components within computer 1102, is stored in non-volatile memory 1110B. Furthermore, according to the invention, codec 1114 may include at least one encoder or decoder, wherein at least one encoder or decoder may consist of hardware, software, or a combination of hardware and software. Although codec 1114 is depicted as a separate component, codec 1114 may be contained within non-volatile memory 1110B. By way of illustration and not limitation, non-volatile memory 1110B may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory, end-to-end memory, etc. Volatile memory 1110A includes random access memory (RAM) and may be embodied as cache memory in some embodiments. As an illustration and not a limitation, RAM comes in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and enhanced SDRAM (ESDRAM).

[0107] Computer 1102 may also include removable / non-removable, volatile / non-volatile computer storage media. Figure 11Disk storage 1106 is illustrated, for example. Disk storage 1106 includes, but is not limited to, devices such as disk drives, solid-state drives (SSDs), floppy disk drives, tape drives, Jaz drives, Zip drives, LS-100 drives, flash memory cards, or memory sticks. Furthermore, disk storage 1106 may include individual storage media or storage media combined with other storage media, including, but not limited to, optical disc drives, such as optical disc ROM devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), digital versatile disc ROM drives (DVD-ROM), and Blu-ray discs. To facilitate connection between disk storage device 1106 and system bus 1108, removable or non-removable interfaces, such as storage interface 1112, are typically used. It should be understood that storage device 1106 may store user-related information. This information may be stored on a server or provided to applications running on the user's device. In one embodiment, the type of information stored in disk storage 1106 or transmitted to a server or application may be notified to the user (e.g., via output device 1132). The user may be given the opportunity to opt-in or opt-out to collect this information and / or share it with a server or application (e.g., via input from input device 1142).

[0108] It should be understood that Figure 11 Software that mediates between a user and the basic computer resources described in a suitable operating environment 1100 is described. This software includes an operating system 1106A. The operating system 1106A, which can be stored on disk storage 1106, is used to control and allocate the resources of the computer system 1102. Application program 1106C utilizes the resource management of the operating system 1106A through program modules 1106D and program data 1106D (such as starting / closing transaction tables, etc.), which are stored on system memory 1110 or disk storage 1106. It should be understood that the claimed subject matter can be implemented using various operating systems or combinations of operating systems.

[0109] Users input commands or information to computer 1102 through input device 1142. Input device 1142 includes, but is not limited to, pointing devices such as mouse, trackball, stylus, touchpad, keyboard, keypad, touchscreen, microphone, joystick, gamepad, satellite dish, scanner, TV tuner card, digital camera, digital camcorder, webcam, etc. These and other input devices are connected to processing unit 1104 via input port 1140 through system bus 1108. Input port 1140 includes, for example, serial port, parallel port, game port, and Universal Serial Bus (USB). Output device 1132 uses some of the same type of ports as input device 1142. Thus, for example, a USB port can be used to provide input to computer 1102 and to output information from computer 1102 to output device 1132. Output adapter 1130 is provided to illustrate that some output devices 1132 (such as monitors, speakers, and printers, etc.) require special adapters. Output adapter 1130 includes, by way of illustration and not limitation, video and sound cards that provide a means of connection between output device 1132 and system bus 1108. It should be noted that other devices and / or device systems provide input and output capabilities, such as remote computer 1138.

[0110] Computer 1102 can operate in a networked environment and communicate with one or more remote computers (such as remote computer 1124) via logical connections. Remote computer 1124 can be a personal computer, server, router, network PC, workstation, microprocessor-based device, peer-to-peer device, smartphone, tablet, or other network node, typically including many elements described relative to computer 1102. For simplicity, only storage device 1126 and remote computer 1124 are described. Remote computer 1124 is logically connected to computer 1102 via network 1122 and then via communication interface 1120. Network 1122 includes wired or wireless communication networks such as local area networks (LANs), wide area networks (WANs), and cellular networks. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, token ring, etc. WAN technologies include, but are not limited to, point-to-point links, circuit-switched networks such as Integrated Services Digital Network (ISDN) and its variants, packet-switched networks, and Digital Subscriber Line (DSL).

[0111] Communication interface 1120 is the hardware / software used to connect network 1122 to bus 1108. For clarity, communication interface 1120 is shown as being located inside computer 1102, but it may also be located outside computer 1102. The necessary hardware / software for connecting to network 1122 is only illustrative and includes internal and external technologies such as modems (including ordinary telephone-grade modems, cable modems, and DSL modems), ISDN adapters, and wired and wireless Ethernet cards, hubs, and routers.

[0112] The aspects shown in this disclosure can also be implemented in a distributed computing environment, where certain tasks are performed by remote processing devices linked via a communication network (e.g., multi-party computation (MPC) processes or algorithms). In a distributed computing environment, program modules or stored information, instructions, etc., can reside in local or remote memory storage devices.

[0113] Furthermore, it should be understood that the various components described herein may include circuits that may contain components and circuit elements with appropriate values ​​to implement embodiments of this disclosure. Additionally, it is understood that many of the various components may be implemented on one or more integrated circuit chips. For example, in one embodiment, a set of components may be implemented in a single integrated circuit chip. In other embodiments, one or more of the various components are fabricated or implemented on separate integrated circuit chips.

[0114] Regarding the various functions performed by the aforementioned components, architectures, circuits, processes, etc., the terms used to describe these components (including references to "device"), unless otherwise stated, are intended to correspond to any component (e.g., a functional equivalent) that performs the specified function of the described component, even if it is not structurally equivalent to the disclosed structure that performs the function in the exemplary aspects of the embodiments shown herein. In this regard, it should also be appreciated that the embodiments include a system and a computer-readable medium having computer-executable instructions for performing actions and / or events of various processes.

[0115] Furthermore, while a particular feature may be disclosed for only one of several implementations, said feature may be combined with one or more other features of other implementations, as may be desired and advantageous for any given or particular application. Moreover, within the scope of the use of the term "comprising" and its variations in the Detailed Description or claims, these terms are intended to be inclusive in a manner similar to the term "including".

[0116] In this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise stated or clearly understood from the context, "X adopts A or B" is intended to mean any natural inclusive arrangement. That is, if X adopts A; X adopts B; or X adopts both A and B, then in any of the above cases, "X adopts A or B" holds true. Furthermore, the articles "a" and "an" used in this application and the appended claims should generally be interpreted as meaning "one or more" unless otherwise stated or clearly understood from the context to refer to the singular form.

[0117] In other embodiments, the disclosed embodiments can be advantageously combined or sub-combined. The block diagrams and flowcharts of the architecture are grouped for ease of understanding. However, it should be understood that combinations of blocks, additions of new blocks, rearrangements of blocks, etc., are contemplated in alternative embodiments of this disclosure.

[0118] It should also be understood that the examples and embodiments described herein are for illustrative purposes only, and various modifications or changes made thereto will be made to those skilled in the art and will be included within the spirit and scope of this application and the appended claims.

Claims

1. An electronic device, comprising: comprise: a communication interface that facilitates communication over a network with a remote device; a processor to execute instructions related to managing a digital asset within an asset account, the asset account being associated with provenance of origin (PoO) data; a storage medium containing the instructions, the instructions comprising: receiving a login of the remote device to the asset account; in response to the login, sending a query for the PoO data; receiving a response to the query, extracting data from the response, and validating the data from the response as the PoO data; and in response to validating the PoO data, authorizing the remote device for access and control of the digital asset.

2. The electronic device of claim 1, wherein, the instructions further comprising executing a transaction involving a cryptocurrency asset in response to a command from the remote device.

3. The electronic device of claim 2, wherein, the instructions further comprising: forming a second communication with a node of a blockchain associated with the cryptocurrency asset through the communication interface; and reporting the transaction to the blockchain node for transmission on the blockchain.

4. The electronic device of claim 2, wherein, the instructions further comprising: executing a node application of a blockchain associated with the cryptocurrency asset at the processor; connecting to at least one other blockchain node through the communication interface; and transmitting the transaction on the blockchain.

5. The electronic device of claim 1, wherein, the instructions further comprising: forming a second communication with a second remote device through the communication interface; receiving a login request from the second remote device to a second asset account that manages a second cryptocurrency asset; sending a second query for second PoO data associated with the second asset account; receiving a second response to the second query, extracting second data from the second response, and validating the second data from the second response as the second PoO data; and in response to validating the second PoO data, authorizing the second remote device for access and control of the second cryptocurrency asset.

6. The electronic device of claim 1, wherein, the PoO data is root-of-trust data of a single-chip device or derivative data of the root-of-trust data.

7. The electronic device of claim 6, wherein, the root-of-trust data or derivative data is generated by a physical unclonable function (PUF) algorithm or a true random number generation algorithm, the physical unclonable function (PUF) algorithm or true random number generation algorithm being implemented at a non-volatile memory embedded within the single-chip device and being integrally formed within the single-chip as part of a single-chip manufacturing process.

8. The electronic device of claim 1, wherein, the electronic device is a non-dedicated peer device in a point-to-point network that includes the remote device and the electronic device.

9. A method of operating a computing device, the method comprising: comprise: initiating point-to-point network communication over a network with a remote device through a communication interface of the computing device; initiating communication with a node device of a blockchain network through the communication interface; forming a query for provenance of origin (PoO) data that is unique or substantially unique to the remote device through a processor coupled to a memory and coupled to the communication interface; transmitting the query to the remote device on the point-to-point network through the communication interface; receiving a response to the query containing data through the communication interface; verifying, by the processor, the data as the PoO data; and in response to verifying the data as the PoO data: executing, by the processor, an application service on behalf of the remote device using the blockchain network.

10. The method of claim 9, wherein, verifying the data as the PoO data further comprises: accessing, by the communication interface, a trusted server device; implementing, by the communication interface, a validation process with the trusted server device using the data or derivative data of the data; receiving, by the communication interface, validation from the trusted server device that the data matches the PoO data; and in response to receiving the validation from the trusted server device, verifying, by the processor, the data as the PoO data.

11. The method of claim 9, wherein, verifying the data as the PoO data further comprises: retrieving, by the processor, a set of stored PoO data stored in the memory; comparing the data or derivative data of the data to the set of stored PoO data; determining whether the data or the derivative data of the data matches a PoO data instance contained within the set of stored PoO data; and in response to determining that the data or the derivative data of the data matches the PoO data instance contained within the set of stored PoO data, verifying the data as the PoO data.

12. The method of claim 11, wherein, the memory is a secure memory embedded within a monolithic chip as part of a monolithic manufacturing process, the monolithic chip shielded by a public physical countermeasure (PCM).

13. The method of claim 9, wherein, the PoO data is formed on a non-volatile memory unit of an integrated circuit device associated with the remote device as part of a physical unclonable function (PUF) or true random number generation (TRNG) algorithm.

14. The method of claim 13, wherein, the non-volatile memory unit is a resistive switching memory unit or a metal oxide semiconductor (MOS) transistor formed within the integrated circuit device, and wherein the integrated circuit device is connected to the remote device by a means selected from the group consisting of: an internal communication bus physically fixed within a housing of the remote device, a removable connection to an external communication bus externally open to the housing of the remote device, and a communication coupling with the remote device through a short-range wireless communication interface.

15. The method of claim 9, wherein, executing the application service further comprises facilitating a cryptocurrency transaction at the blockchain network on behalf of a client account associated with the PoO data.

16. The method of claim 9, wherein, executing the application service further comprises facilitating a smart contract at least partially at the remote device and an exchange of a digital asset with a client account associated with the PoO data.

17. A computing network, comprising: comprises: a first computing device having: a network communication interface; and a short-range network connection; a memory storing instructions of a blockchain service application; a processor for executing the instructions stored in the memory; a second computing device having: a second network communication interface; and a second short-range network connection; and ​ An integrated circuit (IC) device includes proof-of-origin (PoO) data generated from a non-volatile memory cell embedded within the IC device by a physical unclonable function (PUF) or a true random number generation (TRNG) algorithm, wherein the IC device is communicatively coupled with a second computing device over a second short-range network connection; wherein: the first computing device and the second computing device are communicatively coupled in a peer-to-peer network; the first computing device is configured to be communicatively coupled with a blockchain node of a blockchain network; and the first computing device is configured to validate a client account associated with the second computing device by the PoO data, and to execute the blockchain service application on behalf of the client account in response to validating the PoO data.

18. The computing network of claim 17, wherein, A second IC device is also included, the second IC device including second PoO data generated from a second non-volatile memory cell embedded within the second IC device, wherein the second IC device is communicatively coupled with the first computing device over the short-range network connection.

19. The computing network of claim 18, wherein, the memory is a secure memory of the second IC device, and wherein the secure memory contains client account data of the client account, including a cryptocurrency asset or a digital asset of the client account.

20. The computing network of claim 19, wherein, execution of the blockchain service application facilitates exchange of the cryptocurrency asset or the digital asset at the blockchain network through the blockchain node.

Images