Backup and Recovery System and Methods for Cryptocurrency Hardware Wallet

U.S. patent application Ser. No. 18/200,318 filed May 22, 2023 and titled “UTILIZING TWO-TERMINAL RESISTIVE SWITCHING MEMORY TO STORE VALIDATION DATA OF AN INTEGRATED CIRCUIT DEVICE”, and U.S. patent application Ser. No. 18/218,948 filed Jul. 24, 2023 and titled “SECURE MICROCONTROLLER WITH UNIFIED RRAM AND SUB-MODULE ADDRESSING AND ACCESS CONTROL” are hereby incorporated by reference herein in their respective entireties and for all purposes.

The subject disclosure relates generally to improved utility and reliability for secure digital transactions, and as one illustrative example: backup or recovery of cryptocurrency validation data algorithms.

Security in electronic communication is relevant at micro and macro scales, from operations of components within a single die to network communications of communicatively interconnected computing devices. Moreover, communication security is relevant at various scales in between the micro and macro levels, as well as for unconventional (or even heretofore unknown) inter-operations of electronic devices. Although variations exist, probably the most common application in the modern context for securing electronic communication is with cryptographic algorithms.

As a general characteristic, cryptographic algorithms tend to leverage highly complex computational schemes that make breaking the algorithm practically impossible, though in most cases not theoretically impossible. The greater the complexity of the cryptographic algorithm the more practical difficulty in breaking it. For this statement to be true, however, certain mathematical assumptions that the algorithm relies upon must also hold true. One such assumption is the true randomness of a numbering scheme leveraged by an algorithm. Where systematic patterns exist within the numbering scheme or the mechanism utilized to generate (random) numbers, an algorithm is more vulnerable to being compromised. To this end, the national institute on standards and technology (NIST) maintains tests for randomness of number generators for use in cryptography applications (see, e.g., A. Rukhin, et al., “A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications”, NIST, vol. 800-22, no. rev 1a, p. 131, 2010).

One potential vulnerability for secure communications is memory utilized to store secure data. Hacking techniques can leverage knowledge about how a memory operates at a cell or array level, how a memory stores bits of data, physical effects of operations of the memory and so forth to infer information about secure data stored in the memory. Such knowledge rarely yields the secure data in and of itself. However, even where only minor correlation about some bits of the stored data can be correctly inferred, the theoretical or mathematical security of stored data can be undermined. This in turn can reduce the difficulty of compromising the secure data by brute force calculations or other conventional means.

In addition to confidence in storing secure data, the inventor of the present application has proposed techniques for generating data with memory elements. For instance, stochastic characteristics of resistive-switching structures have been proposed by the inventor as suitable for generating non-correlated data for random number generation, or similar applications. Each of these applications has met different needs for electronic memory applications or specialty data generation applications.

In light of the above, the Assignee of the present disclosure continues to develop and pursue practical utilizations of integrated circuit devices for secure communications.

The following presents a simplified summary of the specification in order to provide a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate the scope of any particular embodiments of the specification, or any scope of the claims. Its purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented in this disclosure.

The present disclosure provides for backup of multi-party computation (MPC) security data utilized for securing digital transactions. One illustrative and non-limiting example can include: backup of cryptographic key shards utilized with a MPC cryptocurrency transaction service. For instance, a computing device participating in generation of MPC secure data can retain a segment of the MPC secure data, and can encrypt and store an encrypted segment at a second device (e.g., a cloud server device, a hardware wallet device, another computing device, or the like, or a suitable combination of the foregoing). A recovery service or recovery application at the second device can facilitate recovery of the MPC secure data segment at an additional device not involved in generation of the MPC secure data. The recovery service or application can facilitate recovery of the MPC secure data segment in the event the computing device—and the MPC secure data segment retained at the computing device—is lost.

In an aspect of the disclosed embodiments, disclosed is a method for securing MPC security data. The method can comprise generating security data for an encryption application for a cryptocurrency transaction, splitting the security data into an integer, M of security data segments, where M is greater than one and distributing M−1 data segments of the M security data segments to respective M−1 distinct devices, and retaining an Mdata segment at an Mdevice. Furthermore, the method can comprise encrypting the Mdata segment at the Mdevice producing an encrypted data segment and generating decryption data for decrypting the encrypted data segment. Still further, the method can comprise distributing the encrypted data segment and the decryption data to a first of the M−1 distinct devices. In addition to the foregoing, the method can comprise initiating a recovery application for the encrypted data segment and for the decryption data at least at the first of the M−1 distinct devices facilitating access to the encrypted data segment and the decryption data at an M+1device.

Further aspects of the presently disclosed embodiments provide a method for recovery of data. The method can comprise forming a connection with a server device that manages access to a first encrypted key shard of a MPC encryption key and that stores a second encrypted key shard of the MPC encryption key, wherein the first encrypted key shard is generated at a second device different from the server device. The method can further comprise logging in to a recovery application for the MPC encryption key and providing login information at the recovery application. Additionally, the method can comprise providing identifying information at the recovery application, wherein the identifying application distinguishes the first encrypted key shard or distinguishes the second device. Moreover, the method can comprise obtaining access to a decrypted first key shard by accessing the first encrypted key shard through the recovery application.

In other aspects of the disclosed embodiments, provided is a server device. The server device can comprise a memory for storing application instructions and application data for providing a cryptocurrency validation service for a plurality of remote devices and a processor for executing the application instructions. The server device can additionally comprise a secure storage device for storing secure data associated with the cryptocurrency validation service and a network communication interface coupled to a wide area network. The application instructions can include communicatively coupling, by the network communication interface, to a first device of the plurality of remote devices by way of the wide area network connection, and communicatively coupling, by the network communication interface, to a second device of the plurality of remote devices by way of a limited, single address interface of the second device utilizing the wide area network. Furthermore, the application instructions can comprise generating, by the processor, a N×M encryption key, where M is a number of key shards associated with the N×M encryption key and N is a number of key shards required to produce a valid digital signature with the N×M encryption key or to read the valid digital signature. Moreover, the application instructions can comprise distributing, by the network communication interface, a first key shard to the first device and a second key shard to the second device and receiving, by the network communication interface, an encrypted first key shard and associated decryption data, and saving the encrypted first key shard and associated decryption data to the secure storage device. In addition to the foregoing, the application instructions can comprise initiating, by the processor and the network communication interface, a recovery application facilitating conditional access to the encrypted first key shard and the decryption data for an additional remote device excluded from the plurality of remote devices.

The following description and the drawings set forth certain illustrative aspects of the specification. These aspects are indicative, however, of but a few of the various ways in which the principles of the specification may be employed. Other advantages and novel features of the specification will become apparent from the following detailed description of the specification when considered in conjunction with the drawings.

Threats to security and validity of electronic devices by way of hacking and illicit access are widespread. Mechanisms to secure and authenticate an electronic device and inter-device network communication include cryptography, virtual private networking, combinations of these and others. In the event that electronic devices engaged in network communication are properly authenticated, the communication channel between the devices may still be vulnerable. This is often addressed by encrypting data before transmitting important communications onto a network. Virtual private networks (VPNs) can utilize a tunneling protocol, which can include encryption, between an electronic device and a communication network, between two networks, and so forth. But hacking efforts continue to identify and exploit weaknesses in security of electronic devices and electronic communications.

As one example, access to an electronic device involved in a network communication can be utilized to compromise the communication and even other devices involved in the communication. To illustrate, illicit modification or substitution of a component of an electronic device (e.g., a nonvolatile memory, a firmware, an encryption key, etc.), can effectively compromise the electronic device itself. Moreover, fabrication techniques utilized to create a chip, while cost effective and efficient, can leave inherent vulnerabilities in the chip itself. As another illustration, internal device packaging that facilitates communication between fabricated components that constitute an electronic device (e.g., inter-chip bonding that also facilitates inter-chip communication, or printed circuit board communication lines connecting chips, etc.) can be vulnerable to illicit direct physical access that compromises communication within a device itself. Similarly, physical access to a chip can be leveraged to retrieve secret security data used to encrypt communications, thereby compromising those communications. Also, network communications can potentially be compromised by accessing components of a network, sub-components thereof, or the data transmitted therein. Several core deficiencies in electronic devices and electronic communication are often exploited to compromise security in digital transactions.

An electronic device can be constructed to be resistant to illicit physical access. In some examples, an electronic device can be constructed to include a secure element that has physical countermeasure (PCM) shield and is resistant to hacking. Secret data—such as a cryptocurrency key, secret user data, sensitive data, and so on—can be stored in a memory embedded within the secure element and protected by the PCM shield. Inclusion of a secure element can deter some hacking and illicit access attempts, but others can still be effective if communication pathways between the secure element and a processor, device controller, memory structure utilized by the processor, and so on, are not protected by the PCM shield. This can occur, for instance, in bonded chip devices in which the secure element is formed on one chip that is bonded to a second chip containing the processor or device controller and memory utilized by the processor/controller. Particularly where the bonding mechanism is utilized for communication between the processor/controller and the secure element, illicit access to any of the processor/controller, processor/controller memory or merely the bonding mechanism can facilitate hacking of the secure element, however. More generally, if a controller or processing device accessing the secure element is unprotected by the PCM shield, the controller becomes a point of vulnerability. In addition, if a communication link between the secure element and controller is not protected or covered by the PCM shield, data transport on the communication link can also be a point of weakness (even if the processing device has separate physical countermeasures, security, and so on).

In addition to electronic device structural vulnerabilities, many secure element devices suffer from archaic single-key security architectures and do not have the computational capacity or memory to take advantage of sophisticated architectures such as multi-party computation (MPC). Single-key security also imposes a threat of asset loss through loss of a single security key, or loss of a single electronic device storing the security key. Backup mechanisms for preventing key loss or recovery of lost security keys are archaic and very limited. Embodiments of the present disclosure leverage a sophisticated MPC encryption and decryption framework and provide comprehensive backup and recovery of lost or compromised security data.

Disclosed embodiments include a secure electronic device that integrates a secure element with a high capacity processing device, storage memory and working memory in a single monolithic chip structure (e.g., see, infra). A secure bus structure can be integrated within the monolithic chip structure as well, facilitating secure communication between the processor and secure element. In these embodiments, the PCM shield protecting the secure element also protects the processor, storage memory, working memory and secure bus structure, providing a much more robust resistance to hacking. Moreover, the secure element can be constructed to store secret data and to implement algorithms for processing the secret data. Optionally the secure element can include embedded hardware logic configured for implementing the algorithms that achieves highly accelerated processing for such algorithms (as compared, for example, to software logic or general purpose hardware logic). In at least some embodiments, the secure element can include embedded hardware logic that can be utilized to execute cryptocurrency transactions, blockchain transactions, or the like, among others. Examples can include: generating a digital signature with a cryptographic key (or key share(s)) stored in the secure element, reading (e.g., in the context of validating) a digital signature generated by other secret data/key, authenticating security, login or user data, performing blockchain hash functions, performing “mining” computations for a blockchain or a cryptocurrency, among many others.

In some disclosed embodiments, a secure element can include logic to de-centrally generate secret data as part of a MPC data generation algorithm involving an electronic device containing the secure element communicatively coupled with one or more other computing devices (e.g., via a network, peer-to-peer communication, or the like, or a suitable combination of the foregoing). The logic can yield a secret data share at the secure element that, in combination with some or all secret data shares generated at the one or more other computing devices, form decentralized secret data (e.g., a decentralized encryption key). The secure element can include logic to store the secret data share at a digital storage within the secure element (and optionally encrypt and distribute an encrypted secret data share to an external remote device participating in the MPC data generation algorithm). Moreover, the secure element can utilize the hardware logic to perform MPC digital signature algorithms and MPC digital signature validation algorithms (among others) as part of MPC computations (e.g., see, infra) utilizing the secret data share. In further embodiments, the secure element can perform a data share backup process or a data share recovery process as described throughout the present disclosure. A monolithic secure element device (e.g., see, infra) can include a secure communication interface, which can be limited to a hardware interface (e.g., wired) with a mobile device or computing device, or can include a limited wide area network interface (e.g., wired or wireless) that can access only a limited set of network nodes, such as a secure network node, to facilitate fully symmetric MPC communications, in some embodiments.

Further embodiments of the present disclosure provide for backup, recovery, or the like, of secret data utilized to enable access to a digital asset. The digital asset can be a cryptocurrency, a digital currency, a non-fungible token, a blockchain asset, a user login identifier such as a password, PIN or other identifier, and so on. In various embodiments, the secret data utilized to access the digital asset can be MPC-generated data involving multiple computing devices executing an MPC secret data generation algorithm. The MPC secret data generation algorithm can be executed concurrently by a plurality of the multiple computing devices over a network (the plurality can be all of the devices or a subset thereof) or can be executed by one of the multiple computing devices on behalf of the others. Execution of the MPC secret data generation algorithm produces M segments or shares of secret data (e.g., a standalone de-centrally generated secret key; a secret key of a public/private key pair; and so forth), where M is a positive integer greater than one. In some embodiments, each of the M secret data shares can generate respective digital signatures that can be properly validated by a second number: N, of the M secret data shares. Described differently: N secret data shares can be utilized to properly validate a digital signature generated by any one (or more) of the M secret data shares. Depending on a MPC secret data generation algorithm utilized by the multiple computing devices, N can be a positive integer fromto M. In various embodiments of the present disclosure, N can be less than M.

For backing up MPC generated secret data shares (or segments), each of M secret data segments can be stored at respective computing devices of the multiple computing devices utilized to generate the secret data segments. In addition, a first secret data segment stored at a first computing device can be encrypted with encryption data to generate an encrypted first secret data segment. The encrypted first secret data segment together with first decryption data (configured to re-generate the first secret data segment from the encrypted first secret data segment; or when combined with additional decryption data, can re-generate the first secret data segment) can be transmitted to and stored at least at a second computing device (e.g., see, infra) and optionally to other computing devices (of the multiple computing devices, or of a separate device not participating in the generation of the MPC secret data). Further, a second secret data segment stored at a second computing device (of the multiple computing devices utilized to generate the secret data) can be encrypted with second encryption data to generate an encrypted second secret data segment. The encrypted second secret data segment together with second decryption data (configured to re-generate the second secret data segment from the encrypted second secret data segment) can be transmitted to and stored at least at another of the multiple computing devices (and optionally at a separate device not participating in the generation of the MPC secret data). In some embodiments, the first computing device can transmit the encrypted first secret data segment and first decryption data for storage at the second computing device and at a third computing device(s) of the multiple computing devices, and the second computing device can transmit the encrypted second secret data segment and the second decryption data for storage at the first computing device and at the third computing device(s) of the multiple computing devices. In some embodiments, the third computing device can be a server device, such as a cloud server device providing a cryptocurrency backup and recovery service (e.g., see). This cloud server device can be separate from or in addition to a cryptocurrency storage and transaction service, for instance, such as a cloud-enabled MPC cryptocurrency storage and transaction service, or similar.

Further embodiments of the present disclosure provide for recovery of a secret data segment. In at least some embodiments, the recovery can be implemented at a new computing device not included in the multiple computing devices utilized to generate secret data of which the secret data segment is a part, without compromising security of digital assets secured by the secret data. The new computing device can login to a recovery service at a server device that is among the multiple computing devices, and upon providing valid identification data can receive an encrypted backup of the secret data segment and associated decryption data. The new computing devices can decrypt the encrypted backup of the secret data segment to re-generate the secret data segment, and participate with one or more other of the multiple computing devices (such as the server device, a hardware wallet device, and so forth; see, infra) having respective secret data segments to perform an MPC validation of the secret data (e.g., generate a digital signature; validate a digital signature; and so forth). This MPC validation then enables a digital transaction pertaining to the digital assets secured by the secret data. Where the MPC algorithm generating the secret data is an N of M MPC algorithm, introduced previously, the new computing device can participate with N−1 other devices of the multiple computing devices to perform the MPC validation of the secret data. This allows a lost device of the multiple computing devices to be replaced by the new computing device, facilitating recovery of lost data stored on the lost device, in various embodiments of the present disclosure.

As utilized herein, the term “substantially” and other relative terms or terms of degree (e.g., about, approximately, roughly, and so forth) are intended to have the meaning specified explicitly in conjunction with their use herein, or a meaning which can be reasonably inferred by one of ordinary skill in the art, or a reasonable variation of a specified quality(ies) or quantity(ies) that would be understood by one of ordinary skill in the art by reference to this entire specification (including the knowledge of one of ordinary skill in the art as well as material incorporated by reference herein). As an example, a term of degree could refer to reasonable manufacturing tolerances about which a specified quality or quantity could be realized with fabrication equipment. Thus, as a specific illustration, though non-limiting, for an element of a resistive switching device expressly identified as having a dimension of about 50 angstroms (A), the relative term “about” can mean reasonable variances about 50 A that one of ordinary skill in the art would anticipate the specified dimension of the element could be realized with commercial fabrication equipment, industrial fabrication equipment, laboratory fabrication equipment, or the like, and is not limited to a mathematically precise quantity (or quality). In other examples, a term of degree could mean a variance of +/−0-3%, +/−0-5%, or +/−0-10% of an expressly stated value, where suitable to one of ordinary skill in the art to achieve a stated function or feature of an element disclosed herein. In still other examples, a term of degree could mean any suitable variance in quality(ies) or quantity(ies) that would be suitable to accomplish an explicitly disclosed function(s) or feature(s) of a disclosed element. Accordingly, the subject specification is by no means limited only to specific qualities and quantities disclosed herein, but includes all suitable variations of a specified quality(ies) or quantity(ies) reasonably conveyed to one of ordinary skill in the art by way of the context disclosed herein.

illustrates a block diagram of an example integrated circuit devicefor an electronic device (e.g., a secure computing device, a secure element, a digital hardware wallet on monolithic chip, and so forth) according to one or more embodiments of the present disclosure. Integrated circuit deviceincludes an array(s)of two-terminal resistive-switching memory cells (though other magnetic switching or charge-trapping two-terminal memory cells or even three-terminal memory cells can be utilized instead or in addition, in some disclosed embodiments). Array(s)of memory can include resistive switching memory cells, and different portions of the resistive switching memory cells can be characterized for different memory or data generation functions. Example functions of resistive switching memory cells of array(s)can include PUF data generation or storage, true random number generation (TRNG) or storage, one-time programmable (OTP) data storage and many-time programmable (MTP) data storage (also referred to as rewritable or program/erase). Different groups of memory cells of array(s)are provided to implement these functions. In an embodiment, array(s)of memory can have all resistive switching memory cells characterized for one function (e.g., PUF data, TRNG data, MTP data or OTP data). Multiple resistive-switching memory cells can be aggregated to define a differential PUF bit (or a differential TRNG bit), or a single cell can define a PUF bit (or TRNG bit) in other embodiments. Thus, depicted inare PUF memory cells(which can also include TRNG cells), OTP memory cellsas well as MTP or rewritable/reversibly programmable memory cells. Array(s)of resistive-switching memory cells can be characterized for other types of memory cell functions not specifically depicted in, where suitable.

As shown, array(s)of two-terminal resistive-switching memory cells can be a unified memory structure, whereas in other embodiments, a different array (having a distinct access control) can define separate memory cells. In yet another embodiment, each of MTP cells, OTP cellsand PUF cellscan be embodied in distinct resistive switching arrays having respective access controls. More generally, one or more of: PUF cells, OTP cellsand MTP cellscan be separate memory structures from array(s)of memory. For example, OTP cellscan be located externally to array(s)on a different portion of a monolithic semiconductor chip. Alternatively, in other embodiments, OTP cells(or MTP cells, or PUF cells) can be at least in part included within array(s)of memory. For instance, OTP cellscan be embodied as an array among a set of arrays that form array(s)of two-terminal resistive-switching memory, a block of memory within such an array(s), a set of pages within one or more blocks or arrays, or other suitable arrangement.

Access controlcan be configured to limit access to array(s)or portions of array(s). In an embodiment, access controlcan be implemented in conjunction with a bus providing electronic communication with an array(s)of memory cells (e.g., see MCU busor SE busof, infra). Different buses can have different access control settings in various embodiments. For instance, access controlassociated with an array(s)of a disclosed secure element can have a core/process controlconfigured to limit a processor, a core of a processor, a process or thread running on a processor, or the like, which can access the array(s)associated with the secure element. Another access controlassociated with a bus facilitating electronic communication with an array(s)for storing application code, or with a volatile memory for maintaining operating data of an application in execution, can have few or no core/process controlaccess restrictions for the processor(s), core(s), processes or process threads implemented within a monolithic semiconductor chip such as IC device. Access controlcan also enforce access limitations to array(s)for external commands or data received at a command/data interface(see below).

Controlleris provided to perform operations on array(s)of two-terminal resistive-switching memory cells. Suitable operations can include memory operations, such as reading data from, writing data to, overwriting data at, and so on, subsets of array(s). Memory operations can include processes such as program (write), read, overwrite, erase, and so forth, suitable for operation of MTP cells, and operations to program (write) or read OTP cells. Still further, memory operations can include processes for generating PUF data on individual PUF cells, or on a group(s) of PUF cellsdefining a differential PUF bit. Instructions for implementing memory operations according to the various characterizations can be stored in trim instructions. Memory cell operations can be implemented in response to a command from an external device (by way of command/data interface, for example), which can be implemented by a manufacturer post-fabrication of integrated circuit device, by a distributor or reseller of integrated circuit deviceafter fabrication, by an end-user as part of a chip calibration routine, or as a dynamic process during operation of integrated circuit device, according to various embodiments. As an illustrative example, a host device communicatively coupled to integrated circuit devicecan issue a host command to generate PUF data. In at least some disclosed embodiments, a host command to generate PUF data can be part of an MPC secret data generation, where the secret data, one or more shards of the secret data or a suitable combination of the foregoing are generated at PUF cellswith a PUF data generation operation. In various embodiments, trim instructionscan store protocols to implement memory operations for MTP cells, OTP cellsand PUF cellsconsistent with those characterizations.

Also illustrated in integrated circuit deviceis an input(s)and output(s). In some embodiments, input(s)can include (or provide a pathway for) data to be stored within array(s)of two-terminal resistive-switching memory cells, such as MTP cellsor OTP cells. Output(s)can output data stored within resistive switching devices of array(s). In some embodiments, output(s)can output data that results from computations utilizing data stored in two-terminal resistive-switching memory cells.

A command/data interfaceis provided to receive memory commands from an external device and respond to those commands. Further, data to be written to array(s)can be received by way of command/data interface, and data output from array(s)can be provided over command/data interface. Command/data interfacecan include a direct physical interconnect to an electronic device or a short range wireless interconnect in one or more embodiments (e.g., see peer-to-peer communicationof, infra), or can include a limited and direct communication over a wide area network in other embodiments (e.g., see optional direct & limited communication, infra).

depicts a network diagram of an example multi-party computation (MPC) environmentaccording to alternative or additional embodiments of the present disclosure. MPC environmentcan facilitate a secure digital transaction with high data security and application flexibility. Moreover, MPC environmentcan be configured to facilitate backup, recovery or like applications for secure digital transactions in one or more embodiments.

A transaction on a blockchain, such as a Bitcoin transaction on the Bitcoin blockchain can be secured with a single private key. The private key can be maintained by a user on a user electronic device (e.g., a self-custodial or user-custodial digital wallet device) or can be maintained by a service provider such as a digital currency exchange (e.g., a non-custodial digital wallet device or service). Each variety has benefits and detriments. The self-custodial digital wallet gives the user full and exclusive control over their private key and digital cryptocurrency assets. However, losing the wallet device, password or passphrase could result in loss of the cryptocurrency assets. The non-custodial wallet preserves the private key for the user, providing convenience. But it also requires trust, as the service has full control over the cryptocurrency assets. MPC environmentprovides a hardware wallet device(s)and a MPC framework (e.g., a N of M MPC framework) that enables a user to self-validate a cryptocurrency transaction or to coordinate with a server device to validate the cryptocurrency transaction. Accordingly, MPC environmentcan be configured to avoid any single electronic device as being fatal to recovery of cryptocurrency assets. In addition, MPC environmentcan provide flexibility and convenience available with cloud-based digital transaction services without surrendering control over the cryptocurrency assets to the service provider. In some embodiments, MPC environmentcan even avoid loss of multiple electronic devices as being fatal to recovery of the cryptocurrency assets, by implementing disclosed recovery methods with MPC environment.

In general, for blockchain applications, validation of a transaction affecting an asset registered on a blockchain is typically done by the blockchain itself. A cryptocurrency algorithm utilized by MPC environment(e.g., an N of M multi-party computation algorithm) can be implemented as a signing algorithm to produce or confirm a valid transaction signature associated with the transaction. As a more specific example, the cryptocurrency algorithm can utilize a MPC algorithm to generate secret data and segments of the secret data for decentralized execution of a signing algorithm. In this example, each device containing a segment of the secret data (e.g., a secret data share, a private key share of a private key of a public-private key pair, etc.) can cooperate with other such devices to produce a valid digital signature, or validate a similarly produced digital signature, and participate in a transaction of a digital asset secured by the secret data. Moreover, the valid transaction signature can be produced while maintaining secrecy of each secret data segment.

MPC environmentcan utilize an N of M MPC algorithm for validating a transaction (e.g., a digital signature, etc.) associated with a cryptocurrency asset. M is a first integer defining a total number of secret data segments (e.g., private keys, private key portions, private key shares, or the like) defined for secret data securing the cryptocurrency algorithm, and N is a second integer defining a second number of the M secret data segments that are required to validate a digital signature generated by a private key share generated from the MPC algorithm. As an example, in a 3 of 3 MPC algorithm, a total number of secret data segments is 3, and a second number of the secret data segments required to validate a digital signature generated by one (or more) of the secret data segments of the MPC algorithm is also 3. Thus, for a 3 of 3 MPC algorithm, all of the secret data portions must be provided to validate (execute) the MPC algorithm. As another example, in a 2 of 3 MPC algorithm, the total number of secret data segments defined for the 2 of 3 MPC algorithm is 3, and the second number of secret data segments required to validate a digital signature generated by another secret data segment(s) of the MPC algorithm is (any)of the 3 total secret data segments.

MPC environmentcan include a first secret data segment: key sharestored at a cloud server(s) device. Cloud server(s) devicecan be maintained by a cryptocurrency transaction service provider, as one example. A second secret data segment: key sharecan be stored at an electronic device (e.g., a computer, a mobile device, a smartphone, or the like) of a user, and one or more additional secret data segments: key sharecan be stored at respective hardware wallet devices, where M is an integer greater than 2. With a single hardware wallet device, MPC environmentcan model a suitable N of 3 MPC algorithm, such as a 2 of 3 MPC algorithm, a 3 of 3 MPC algorithm (or even a 1 of 3 MPC algorithm). With multiple hardware wallet devices(or multiple electronic devices) having respective secret key shares(or), MPC environmentcan implement a N of 4 MPC algorithm, a N of 5 MPC algorithm, and so forth.

An example hardware wallet deviceis shown at, infra. Hardware wallet devicecan be embodied on a single monolithic integrated circuit chip, in some embodiments of the present disclosure. Further, hardware wallet devicecan include a secure element embedded within the monolithic chip in which secret data (or a segment(s) of secret data) can be generated and stored in PUF cells (e.g., see PUF cellsof, supra) of a resistive-switching memory technology. This can make hardware wallet deviceand the secret data stored thereon very difficult to compromise. Note that while hardware wallet deviceincludes electronic hardware (e.g., semiconductor hardware), hardware wallet deviceneed not be exclusively hardware and can also include software, firmware, and the like for implementing executable instructions, performing computing tasks, and so on.

Where an N of M MPC algorithm utilized for MPC environmentdefines N as M−1 (or less), a user can retain personal control over digital assets (e.g., digital currency assets, digital blockchain assets, digital legal instruments or contracts, and so forth), yet utilize cloud server(s)as a backup of one or more secret key shares in the event mobile device(and key share) becomes lost, or in the event that (one of) hardware wallet device(and key share) becomes lost, or the like (e.g., see, infra). As long as the user retains either key shareor key share, in the 2 of 3 MPC algorithm embodiment, the user can connect with cloud server(s)to access key shareand validate the N of M MPC algorithm. Only if both key shareand key shareare lost would the user risk loss of cryptocurrency assets associated with the N of M MPC algorithm. In at least one embodiment, a user can retain a backup hard wallet devicehaving a copy of key shareallowing recovery of cryptocurrency assets even if mobile deviceis lost and one hardware wallet deviceis lost (e.g., see). In another embodiment, the backup hardware wallet devicecan have a key shareto replace the key share, and as long as the N of M MPC algorithm defines N as no larger than 2, a user can validate the N of M cryptocurrency algorithm and recover cryptocurrency assets with just two devices: the backup hardware wallet deviceand key shareand cloud server(s)and key share. Alternatively, MPC environmentcan define multiple backup hardware wallet deviceswith respective key share. In such embodiment, as long as a N−1 numbers of backup hardware wallet devicesand respective key sharesare available for connecting with cloud server(s), the cryptocurrency algorithm can be validated (e.g., with a 3 of 5 cryptocurrency algorithm, two backup hardware wallet devicesand respective key shares can be coupled with cloud serverand key shareto validate the 3 of 5 MPC algorithm, even if both mobile deviceand hardware wallet deviceare lost).

In various embodiments, network communication capability of hardware wallet device(s)can be limited to protect security of key share. In an embodiment, hardware wallet device(s)can be limited to a local-only communicationwith mobile device. Local-only communicationcan be a smartcard port within mobile devicethat can physically receive and communicatively couple to hardware wallet device(s), or a similar port that can physically receive and communicatively couple to hardware wallet device(s), such as a USB card port, a sim card port, and so forth. In other embodiments, local-only communicationcan be a physical communication connection such as a wired USB connection, an IEEE 1394 connection, serial connection, parallel connection, or other suitable wired communication bus connection. In still other embodiments, local-only communicationcan be a local-only wireless connection, such as a Bluetooth® connection, a personal wireless network, or similar. Where hardware wallet device(s)has no communication with cloud server(s), mobile devicecan serve as the common communication device between hardware wallet device(s)and cloud server(s)for MPC environment.

In at least some embodiments, hardware wallet device(s)can be configured to establish an optional remote communicationwith cloud server(s), to enable communication between cloud server(s)and hardware wallet device(s)without requiring mobile deviceas a platform to establish remote communicationbetween mobile deviceand cloud server(s). In such embodiments, optional remote communicationcan be a Wi-Fi connection, a cellular internet connection, or other long-range public or private communication network. In other embodiments, optional remote communicationcan be a dedicated connection, an encrypted connection, such as a virtual private network (VPN) connection, and so forth. Optional remote communicationcan render MPC environmenta fully symmetric MPC network in which any N secret data segments (,,) on respective devices (e.g., cloud device(s), mobile device(s)or hardware wallet device(s)) can cooperate to execute, validate or the like, MPC digital signature algorithms based on the N of M validation framework described herein.

depicts a block diagram of an example integrated circuit device implemented as a crypto hardware wallet device on a single monolithic chip (hardware wallet device), according to various aspects of the disclosed embodiments. Hardware wallet devicecan include a microcontroller unit (MCU), an on-chip non-volatile memory(e.g., resistive memory: ReMEM, phase change memory (PCM), programmable metallization memory, magneto-resistive memory (MRAM), among others, which are referred to hereinafter as on-chip ReMEMfor convenience) and a volatile memory, as shown. MCUcan include an embedded memory(volatile or non-volatile) in one or more embodiments, which can include at least a portion of on-chip ReMEMor can be separate from and in addition to on-chip ReMEM, in further embodiments. On-chip ReMEMcan store application code for execution at MCU. Volatile memorycan be utilized for operating data associated with executing application code at MCU, at least a portion of which can also be stored at embedded memory, where suitable.

In conjunction with executing a cryptographic application(s), MCUcan communicate with a secure element. As disclosed herein, MCU, on-chip ReMEMand volatile memorycan be embedded together with secure element(and its sub-components) in a single monolithic chip on a single substrate, in various embodiments. This monolithic integration can enhance security of communications between MCUand secure element. Moreover, secure elementcan include hardware-encoded security, secret data or cryptocurrency-related algorithms(which can include, e.g., digital signature algorithms, signature validation algorithms, blockchain validation algorithms, etc.), or other algorithms for application security, user security, digital asset security, or digital transaction security, or suitable combinations of the foregoing, and are hereinafter referred to as hardware encoded security algorithmsfor convenience. These algorithms can be implemented as sets of logic primitives in aspects of the disclosed embodiments, that when executed in a suitable sequence can perform one of the foregoing algorithms, such as a cryptocurrency validation or transaction algorithm. As a brief example, respective logic primitives can define a user authentication process, a cryptocurrency hash algorithm and a validation of a cryptocurrency transaction that when executed in sequence effect a user authentication, cryptocurrency hash computation and a validation of a cryptocurrency transaction.

Hardware encoded security algorithmscan be executed in response to a command(s) received at secure elementfrom MCU. Where embodying cryptographic primitives, hardware encoded security algorithmscan receive commands (or command arguments) specifying a sequence order of executing a plurality of primitives that implement an algorithm more complex than individual primitives. Moreover, different subsets of primitives or different sequences, or combinations thereof, can each implement different algorithms, as would be known in the art or reasonably conveyed to one of ordinary skill in the art by way of the context provided herein.

In a particular example, hardware encoded security algorithmscan include hardware logic encoding MPC digital signature and signature validation algorithms (referred to hereinafter as MPC sign and validation algorithms). MPC sign and validation algorithmscan be utilized to generate or participate in generation of secret data and secret data segments for MPC digital signature applications and MPC signature validation applications. By encoding MPC sign and validation algorithmsin hardware encoded logic, even as a set of logic primitives as introduced above, highly intensive MPC digital signature and MPC signature validation processes can be executed quickly and efficiently, enhancing user experience of such processes when utilizing hardware wallet device.

Secure elementcan include an embedded ReMEM. Embedded ReMEMcan include a secret storagethat includes secret data. In at least one embodiment, embedded ReMEMcan optionally be set to no read/no write to prevent access to secret storage. In such embodiment(s), embedded ReMEMcan have limited processing logic to process a simple query associated with the secret data stored in secret storage, without exposing the secret data external to embedded ReMEM. The simple query can confirm a hash algorithm, confirm an encryption/decryption result, or the like, initiated with the secret data. In other embodiments, embedded ReMEMcan permit access to secret storageon a limited basis. For example, hardware encoded security algorithmscan be permitted to access secret storage, but nothing external to secure element, in an embodiment(s). Secure element(or embedded ReMEM) can be configured to differentiate commands, data requests, and the like, originating at hardware encoded security algorithmsfrom requests originating external to secure element, in such embodiment(s).

In one or more embodiments, secure elementcan include optional volatile memory. Optional volatile memorycan be utilized as working memory to store values of hardware encoded security algorithms. As one example, where a hardware encoded security algorithminvolves execution of multiple logic primitives, a data value(s) resulting from execution of a first logic primitive (e.g., a MPC signature validation) can be held at optional volatile memoryand accessed by a subsequent logic primitive (e.g., a cryptocurrency transaction depending on successful MPC signature validation) to produce a second data value(s), and so on.

In some embodiments of the present disclosure, hardware wallet devicecan include an optional communication interface. Optional communication interfacecan be configured to provide limited communication with an external device, or network. This limited communication can facilitate participation in an MPC algorithm, such as MPC secret data generation, MPC digital signature or MPC signature validation, or the like. Alternatively, or in addition, this limited communication can facilitate receipt and storage of an encrypted secret data segment(s) (and associated decryption data) of one or more computing devices participating in MPC secret data generation and segmentation. In yet another example, this limited communication can facilitate transmission of an encrypted secret data segment generated in part by hardware wallet deviceand associated decryption data to another device for backup storage. In still further examples, this limited communication can facilitate login to a recovery service and recovery of an encrypted secret data segment and associated decryption data, to recover data lost by another hardware wallet deviceat hardware wallet deviceso that the latter can participate in a MPC algorithm, or to facilitate recovery of such encrypted secret data segment and decryption data for another computing device to participate in the MPC algorithm (e.g., see, infra). In at least some embodiments, the limited communication can facilitate validation of a device against data stored at secret storage, authentication of user credentials, executing a cryptographic algorithm, participating in a blockchain validation algorithm, or participating in a multi-party computation (MPC) process associated with any of the foregoing or associated with a like operation.

In some embodiments, optional communication interfacecan be limited to hardware communication protocols such as a short-range wired communication protocol (e.g., universal serial bus (USB), Ethernet bus, Firewire (IEEE 1394) bus, high speed Serial Peripheral Interface (SPI), a parallel interface, or the like; see, infra). In other embodiments, optional communication interfacecan be limited to a short-range wireless interface such as a Wi-Fi interface, a Bluetooth® interface, a personal area network (PAN), or similar. In at least one embodiment, optional communication interfacecan be a dedicated and limited wide area network interface (e.g., a limited Internet connection) having only a set of target Internet Protocol addresses for which communication is permitted, such as an IP address of a cloud service provider's server equipment (e.g., cloud device(s)of, supra).

Internally, hardware wallet devicecan provide different communication bus structures for communications among components thereof. An MCU buscan provide communications between MCUand volatile memoryand on-chip ReMEM. MCU buscan be an unrestricted bus, facilitating all suitable electronic communication between a processor and memory(ies) as known in the art. In addition, an SE buscan facilitate communication between MCUand SE. In at least some embodiments, SE buscan be a limited communication bus. For instance, where MCUis a multi-core processor, SE buscan permit communication between MCUand SEoriginating at a first core of the multi-core processor (e.g., an authorized core; a core having a valid authorization code, etc.) and can deny communication between MCUand SEoriginating at a second core of the multi-core processor (e.g., an unauthorized core; a core not having the valid authorization code, etc.). As another example, SE buscan permit communication between MCUand SEfor an application, a process, or a logic thread being executed by MCUthat is authorized to communicate with SE, or for a process or logic being executed at hardware encoded security algorithmsthat is authorized to communicate with MCU, or to utilize MCUand optional communication interfaceto communicate with an external device(s) (e.g., participate in a MPC data generation, signature, signature validation, backup or recovery process), or a suitable combination of the foregoing (e.g., see U.S. patent application Ser. No. 18/218,948, incorporated by reference hereinabove, atand associated written descriptions, among others thereof).

depicts a block diagram of an example systemfor backup of MPC secret data in further embodiments of the present disclosure. Systemincludes one or more computing device(s)communicatively connected to one or more cloud device(s)by way of remote communication, and communicatively connected to one or more hardware wallet device(s)by way of a peer-to-peer communication. Hardware wallet devicecan optionally be communicatively connected to cloud device(s)by an optional direct & limited communication, in one or more embodiments. Systemcan implement a MPC decentralized generation of secret data (e.g., an MPC encryption key), from which a set of secret data segments can be formed at respective devices,,and optionally where a combined key (incorporating all data segments) is not revealed to any single computing device,,. The secret data segments formed at (or optionally distributed to) respective devices of systemcan be stored therein. For instance, cloud device(s)can generate and store a first key share, computing device(s)can generate and store a second key shareand hardware wallet device(s)can generate and store a Mkey share, where M is an integer greater than 2. For values of M greater than three, systemcan include additional computing devicesor additional hardware wallet devices(or, optionally, an additional cloud device(s)) —communicatively connected by respective remote communications, peer-to-peer communicationsor optional direct & limited communications, as suitable—at which additional secret data segments can be generated and stored.

Computing device(s)can include an encryption applicationconfigured to encrypt key shareutilizing encryption data, and generate an encrypted key share(or more generally, an encrypted secret data segmentof a segment of secret data). The encryption data can be utilized to generate decryption data that can be combined with encrypted key shareto reproduce key share. Moreover, in at least one embodiment of the present disclosure, the decryption data can be segmented into multiple decryption data portions, (also referred to herein as decryption data shards, or decryption key shards, or the like) identified as backup key portionand backup key portion. A copy of encrypted key sharecan be stored at cloud device(s)and hardware wallet device, along with one of the decryption data portions. Specifically: backup key portioncan be stored at cloud device(s)and backup key portioncan be stored at hardware wallet device. To recover key sharethen at a computing device not included in system(e.g., if computing deviceis lost), a new computing device (not depicted, but see, infra) can login to a recovery applicationat cloud device(s)and, with hardware wallet deviceconnected to the new computing device or cloud device(s), recovery applicationcan facilitate providing encrypted key share, backup key portionand backup key portionto the new computing device. The new computing device can then combine backup key portionand backup key portionto regenerate the decryption data, and combine the decryption data with encrypted key shareto recover key share.

Similarly, hardware wallet devicecan include an encryption applicationconfigured to encrypt key shareutilizing second encryption data, and generate an encrypted key share(or more generally, an encrypted secret data segmentof a segment of secret data). The second encryption data can be utilized to generate second decryption data that can be combined with encrypted key shareto reproduce key share. Moreover, in at least one embodiment of the present disclosure, the second decryption data can be segmented into multiple second decryption data portions, identified as backup key portionand backup key portion. A copy of encrypted key sharecan be stored at cloud device(s)and computing device(s), along with one of the second decryption data portions. Specifically: backup key portioncan be stored at cloud device(s)and backup key portioncan be stored at computing device. To recover key share at a computing device, hardware wallet device, etc., not included in system, a new such device can login to recover applicationat cloud device(s)and, with computing device(s)connected to cloud device(s)(and optionally to the new device), recovery applicationcan facilitate providing encrypted key share, backup key portionand backup key portionto the new device. The new device can then combine backup key portionand backup key portionto regenerate the second decryption data, and combine the second decryption data with encrypted key shareto recover key share.