Secure reuse of private keys for dynamic groups of nodes

Abstract

A computer-implemented method may be provided. The computer-implemented method includes: i) broadcasting, by a node in a blockchain network, a transaction transferring one or more digital assets to a public group address associated with a conference public key, the public group being associated with one or more other digital assets associated with other members of the conference; ii) generating private key shares to be used in a threshold signature scheme, in which at least a threshold of private key shares must be used to generate a valid signature by combining partial signatures representing the conference, and wherein other holders of the private key shares are other members of the conference who have joined the conference by transferring their respective digital assets to the public group address; and iii) collaboratively generating a valid signature for a transaction from the public group address using the private key shares.

Description

Technical Field

[0001] The present invention relates generally to distributed ledgers and, more particularly, to methods and systems for providing decentralized control of digital assets associated with a digital ledger. Background Art

[0002] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variants.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which in turn consist of transactions and other information. Each transaction can be a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so that the blocks become linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs, which specify how and by whom the outputs of the transaction can be accessed. These scripts can be written using a stack-based scripting language.

[0004] It would be extremely advantageous if blockchain could be used to automate tasks and processes that are not purely limited to cryptocurrency-denominated payments. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more general in its application.

[0005] As blockchain technology is extended to provide new features, it is important to maintain the security of the blockchain and the digital assets represented therein. Extended feature sets that rely on blockchains may be vulnerable to attack by malicious parties. Therefore, it is useful to provide methods and apparatus that provide additional security for blockchains or new features of blockchains, or control ownership of digital assets to maintain the integrity of the blockchain.

[0006] Furthermore, as new improvements or modifications to blockchains are developed, it would be helpful to have techniques for controlling the transfer of digital assets from one blockchain to another while maintaining the integrity of both blockchains. It would therefore be desirable to provide improved methods and apparatus that improve blockchain technology in one or more of these aspects. Summary of the invention

[0007] Thus, according to the present invention there is provided a method as defined in the accompanying claims.

[0008] As described in more detail below, a conference can be formed on a blockchain network. A conference can be an open member group that any node in the blockchain network can join when it submits sufficient stake to a pool associated with the conference. For example, a node can join a conference by transferring a digital asset such as a digital currency or other stake or value to a resource (e.g., an account) associated with the conference. A conference can be partially protected by distributed generation of private key shares. Each private key share can be used by its holder to generate a partial signature for a transaction. A threshold signature scheme can be used to generate a valid signature for such a transaction by using a threshold of at least a partial signature. Member deposits may be confiscated for malicious behavior.

[0009] Advantageously, by using distributed generation of key shares and other security features, key shares can be protected from malicious activity by group members or non-group members. This security combined with the use of a threshold signature scheme can allow for the formation of autonomous decentralized groups that can be used for any of a variety of purposes, including, for example, providing a two-way anchor. More specifically, the threshold signature scheme can allow a group to control digital assets that are encumbered by a public key associated with the group.

[0010] Thus, according to the present invention, a computer-implemented method may be provided. The computer-implemented method may include: i) broadcasting, by a node in a blockchain network, a transaction to transfer one or more digital assets to a public group address associated with a conference public key, the public group address being associated with one or more other digital assets associated with other members of the conference; ii) generating private key shares to be used in a threshold signature scheme, wherein at least a threshold of private key shares must be used to generate a valid signature by a combination of partial signatures representing the conference, and wherein other holders of the private key shares are other members of the conference who joined the conference by transferring their respective digital assets to the public group address; iii) cooperatively generating a valid signature for a transaction from the public group address using the private key shares; iv) detecting a request to allocate a new key share; and v) cooperating with other members of the conference to issue a private key share of the same public key for a new member of the group.

[0011] In some implementations, the threshold signature scheme is an Elliptic Curve Digital Signature Algorithm.

[0012] In some embodiments, the computer-implemented method may further include: i) detecting malicious activity by a malicious party, wherein the malicious party is one of the other members of the conference; and ii) confiscating at least a portion of digital assets previously transferred by the malicious party to the public group address. In some embodiments, confiscating may include transferring to a non-spendable address, and in some embodiments, may include collaborating with other members of the conference to use the private key share for valid signing of transactions to the non-spendable address.

[0013] In some embodiments, the computer-implemented method may further include: i) detecting a reallocation request; ii) working with other conference members to transfer all digital assets in the public group address to a new public address associated with a new public key; and iii) generating a new private key share.

[0014] In some embodiments, the computer-implemented method may further include confirming that a share of a private key previously held by the member who has left the conference has been deleted from a node associated with the member. In some embodiments, the node associated with the member who has left the conference includes a trusted execution environment that provides a certification of the deletion of the share of the private key previously held by the member. In some embodiments, each member's trusted execution environment may be configured to periodically certify all transactions that they have partially signed and / or they may be required to broadcast such a certification before their deposit is required to be returned.

[0015] In some implementations, the conference public key encumbers digital assets received from group members and non-group members, and detecting the request to allocate new key shares includes identifying conference members using attributes included in at least a portion of a transaction of a digital asset to the public group address.

[0016] In some implementations, the private key share is generated and used on a trusted execution environment within the node.

[0017] In some embodiments, the computer-implemented method may also include: i) receiving a request from a requestor who is a member of a conference to withdraw digital assets previously deposited by the requestor and currently controlled by the conference; ii) evaluating the request against determined criteria; and iii) using the private key share to collaboratively generate a digital signature and using the digital signature to transfer the digital assets previously deposited by the requestor back to the requestor.

[0018] According to the present invention, an electronic device may be provided. The electronic device comprises: an interface device; a processor coupled to the interface device; and a memory coupled to the processor. The memory stores computer executable instructions, which configure the processor to perform the method described herein when executed.

[0019] According to the present invention, a computer-readable storage medium may be provided, wherein the computer-readable storage medium includes computer-executable instructions, which, when executed, configure a processor to perform the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention are described below by way of example only and with reference to the accompanying drawings, in which:

[0021] Figure 1 A block diagram illustrating an exemplary blockchain network.

[0022] Figure 2 A block diagram illustrating an exemplary electronic device that may function as a node in a blockchain network.

[0023] Figure 3 is a flow chart of an exemplary method of initiating a conference.

[0024] Figure 4 is a flow chart of an exemplary method of joining a conference.

[0025] Figure 5 is a flow chart of an exemplary method for confiscating digital assets.

[0026] Figure 6 is a flow chart of an exemplary method of reallocating key shares.

[0027] Figure 7 is a flow chart of another exemplary method of reallocating key shares.

[0028] Figure 8 is a flow chart of an exemplary method of returning a deposit. DETAILED DESCRIPTION

[0029] Blockchain Network

[0030] First reference Figure 1 . Figure 1An exemplary blockchain network 100 associated with a blockchain is shown in block diagram form. The blockchain network can be a public blockchain network, which is a peer-to-peer open member network that anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of a blockchain protocol (under which the blockchain network 100 operates) can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102.

[0031] The electronic devices running the blockchain protocol and forming the nodes 102 of the blockchain network 100 may be various types of devices including, for example, desktop computers, laptop computers, tablet computers, servers, mobile devices such as smart phones, wearable computers such as smart watches, or other electronic devices.

[0032] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, which may include wired and wireless communication technologies. Such communication follows the protocol associated with the blockchain.

[0033] Nodes 102 maintain a global ledger of all transactions on the blockchain. Therefore, the global ledger is a distributed ledger. Each node 102 can store a complete copy or a partial copy of the global ledger. For example, a block may include a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, the block acts as a record of transactions from one address to another address. The party that requires the transaction to be included in the block proves that they are authorized to initiate the transfer by signing the request with the private key corresponding to their public key. If the request is signed validly, the transfer is only added to the block.

[0034] There can be a one-to-one correspondence between public keys and addresses. That is, each public key is associated with a single address. Therefore, any references herein to transferring a digital asset to or from a public key (e.g., paying into a public key) and to transferring a digital asset to or from an address associated with the public key refer to the common operation.

[0035] Some nodes 102 participate as validation nodes. Transaction validation may involve checking signature(s), confirming references to valid UTXOs, etc.

[0036] Figure 1 The example includes five nodes 102, three of which are mining nodes 104. In practice, the number of nodes 102 or mining nodes 104 may be different. In many blockchain networks, the number of nodes 102 and mining nodes 104 may be much greater than Figure 1 Quantity shown.

[0037] As described below, the various nodes 102 may cooperate to form a group that will be referred to herein as a conference 110. In the illustrated example, three nodes 102 are shown as participants in the conference 110. However, the actual number of conference 110 members may be much larger.

[0038] The conference 110 is an open membership group that can be joined by any node 102 when sufficient stake is submitted to a pool associated with the conference 110. For example, a node can join a conference by transferring digital assets (such as digital currency or other stake or value) to an account associated with the conference 110. The node 102 that joins the conference can be any node in the blockchain network, including mining nodes and non-mining nodes. In at least a portion of the application of the conference (such as when the conference performs a two-way anchor as described below), nodes that act as conference members monitor the blockchain in the sense that they download (but do not necessarily retain) the complete blockchain.

[0039] In various known systems involving groups formed by nodes of a blockchain network, group membership is fixed. In contrast, nodes can join and leave conference 110. Conveniently, by allowing such flexible group membership, conference 110 can reduce overhead compared to systems such as SecureCoin by avoiding the need to repeatedly form node groups from scratch.

[0040] Techniques for joining, leaving, and participating in conference 110 are discussed in more detail below.

[0041] Electronic device operating as a node

[0042] Figure 2 is a block diagram illustrating components of an exemplary electronic device 200 that can act as a peer-to-peer blockchain network 100 ( Figure 1 ) in node 102( Figure 1 ). The exemplary electronic device 200 may also be referred to as a processing device. The electronic device may take various forms, including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or other types of forms.

[0043] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores a computer software program, which includes machine-readable instructions and data for performing the functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement communication with the blockchain network 100 ( Figure 1 ) associated with the protocol.

[0044] The memory 220 can store the blockchain network 100 ( Figure 1 )'s global ledger or a portion thereof. That is, the memory 220 may store all blocks or a portion of blocks of the blockchain, such as the latest block, or a portion of information in some blocks.

[0045] Although the memory 220 is Figure 2 Although shown as a single box in the figure, in fact, the electronic device 200 may include multiple memory components. The memory components may be of various types, for example, including RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. In addition, although the memory 220 is shown separately from the processor 210, the processor 210 may also include an embedded memory.

[0046] like Figure 2 As shown, the processor 210 may include a secure area such as a trusted execution environment (TEE) 250. TEE 250 is an isolated execution environment that provides additional security for the electronic device 200, such as isolated execution, integrity of trusted applications, and asset confidentiality. TEE 250 provides such an execution space: the execution space guarantees that the computer instructions and data loaded in the TEE 250 are protected in terms of confidentiality and integrity. TEE 250 can be used to protect the integrity and confidentiality of important resources (such as keys). TEE 250 is implemented at least in part at the hardware level so that instructions and data executed in TEE 250 are protected from access and manipulation from the rest of the electronic device 200 and external parties such as the owner of the electronic device. Data and calculations within TEE 250 are protected from the party operating the node 102 that includes TEE 250.

[0047] The TEE 250 may be operated to instantiate the enclave and then add pages of memory one at a time while cumulatively hashing. Similar operations may also be performed on a remote machine (which may be the developer machine or another machine) so that the remote machine determines and stores the expected hash. Thus, the contents of the enclave may be verified by any remote machine to ensure that the enclave is running the approved algorithm. Verification may be performed by comparing hashes. Once the enclave is fully built, it is locked. Code may be run in the TEE 250 and secrets may be sent to the code, but the code cannot be changed. The final hash may be signed by a proof key and made available to the data owner to verify it before the data owner sends any secrets to the enclave.

[0048] TEE 250 can be used to protect the session 110 ( Figure 1 ) to ensure confidentiality and integrity of private key shares associated with conference public keys used by the TEE 250. For example, TEE 250 can be used for the generation and storage of private key shares. The purpose of TEE 250 is to ensure that no member can directly obtain private key shares maintained within the TEE 250 enclave, or obtain information about other private key shares through inter-member communication or cross-enclave communication. The protocol is also robust to compromise of enclave thresholds. In addition, TEE 250 can enable remote attestation, which can be performed by node 102 ( Figure 1 ) is used to prove to other nodes 102 that the TEE 250 is authentic and is running approved computer executable instructions for the protocol implemented by the conference 110. Remote attestation can be provided by the TEE 250 by running a specific code segment and sending a hash of the code inside the enclave, the hash of the code being signed by the internal attestation key for the enclave.

[0049] When a member of conference 110 who previously used a private key share on electronic device 200 chooses to leave the conference, TEE 250 may be used to prove the secure deletion of the private key share. Electronic device 200 may provide proof of deletion to other conference members via a remote attestation protocol provided in TEE 250. Proof of deletion may be required before a member is allowed to withdraw their member deposit. That is, the return of the deposit may be conditional on proving the deletion of the private key share within the member's enclave.

[0050] The TEE 250 may be equipped with a secure random number generator, which is inside the TEE's enclave, which may be used to generate private keys, random challenges, or other random data. The TEE 250 may also be configured to read data from external memory and may be configured to write data to external memory. This data may be encrypted with a secret key that is maintained only inside the enclave.

[0051] The TEE 250 may be implemented using various platforms such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). For example, SGX supports remote attestation, which enables an enclave to obtain signed statements from the processor that is executing a specific enclave that has a given member called a reference. A third-party attestation service such as Intel Attestation Service (IAS) can attest that these signed statements originate from a trusted CPU that complies with the SGX specification.

[0052] The electronic device 200 acts as a blockchain network 100 ( Figure 1 ) in node 102( Figure 1 ), and may join or otherwise participate in a meeting 110( Figure 1 When a group of digital asset holders pool digital assets (such as digital currency or blockchain network 100( Figure 1 ) other interests or values ​​supported by the meeting 110 is formed.

[0053] Conferences and Threshold Signatures

[0054] The conference 110 can be a permissioned or non-permissioned group. That is, the blockchain network 100 ( Figure 1 ) any node 102 ( Figure 1 ) (i.e., by monitoring and storing at least a portion of the information in the blockchain) can join the conference 110. In order to join the conference 110, the node 102 transfers one or more digital assets to the digital asset pool associated with the conference 110 (i.e., to a public group address associated with one or more digital assets, which are correspondingly associated with other members). The digital asset pool may be referred to as the conference pool. For example, the node 102 may join the conference 110 by transferring (i.e., depositing) such digital assets to an address associated with the conference pool (i.e., transferring to a "conference address" which may also be referred to as a public group address). The digital assets are placed under the control of a group threshold signature with a single public key (referred to as the conference public key). Conference members hold shares of distributedly generated private keys. The number of shares held may be proportional to the amount deposited in the pool.

[0055] Digital assets controlled by conference 110 (including any digital assets transferred to the conference address) are placed under the control of a threshold signature scheme. Under the threshold signature scheme, a group of members whose total private key shares hold more than a threshold value are required to produce a valid signature that allows the digital asset to be transferred out of the control of conference 110. That is, at least a threshold number of private key shares must be used to generate a valid signature for any outbound transfer of a digital asset controlled by conference 110.

[0056] The conference public key blocks digital assets deposited in the conference pool by members of conference 110 in exchange for a share of the private key, as well as any digital assets deposited at addresses associated with the conference pool by members or non-members of conference 1100 (i.e., placed under the full, partial, or conditional control of the conference) (any digital assets that have been deposited for reasons other than obtaining a share of the private key). Non-members or members may deposit digital assets at addresses associated with the conference for a variety of reasons. In an example explained in more detail below, a member or non-member may deposit digital assets into conference 110 to move these assets to another blockchain, which may be referred to as an alternative chain, such as a side chain. A side chain may be a blockchain that runs in parallel with the main blockchain (i.e., parallel to the main chain).

[0057] Because the same conference public key can control member deposits (i.e., digital assets provided by conference members in exchange for private key shares) and digital assets provided by members or non-members for other purposes, at least a portion of deposits to addresses associated with the conference may be specially marked to indicate the type of deposit. For example, a transaction that transfers a digital asset to a conference address may include a tag, identifier, or other attribute indicating the nature of the deposit being made. For example, a transaction that transfers a digital asset to a conference address that is not for the purpose of joining a conference or increasing the stake in a conference membership may include a special identifier to indicate that the deposit is made for other purposes. These identifiers can be used by nodes 102 associated with conference 110 when managing private key generation. More specifically, nodes 102 that deposit digital assets in order to join a group are assigned a private key share for conference 110 (as a result of making a digital asset deposit), while other nodes 102 that deposit digital assets for other purposes (e.g., transfer to a side chain) do not necessarily hold a conference private key share (i.e., corresponding to the conference public key) for the conference.

[0058] The conference 110 can act as an autonomous group in which cooperative behavior is enforced by the threat of confiscating all or part of the member's deposit. Non-cooperative or malicious members may have such digital assets confiscated as a result of joining a cooperative agreement in which many honest members participate. That is, in order to ensure that all nodes 102 operate in accordance with a predetermined agreement or guidelines, member deposits entering the conference pool may be confiscated. Confiscation means permanently preventing the return of member deposits that are deemed confiscated. (One or more) digital assets that form member deposits that are not returned due to malicious activity can remain in the conference pool but not be returned (for example, if a consensus is reached (on an alternative chain) that they should not be returned), be transferred to another non-consumable address immediately or in the future, or be confiscated in other ways, and the nature of the confiscation may depend on whether the conference acts as a bonded validator set for the side chain.

[0059] In addition, when a conference member wishes to leave the conference 110, they can withdraw their member deposit (i.e., request the conference 110 to transfer the member deposit back to the member's personal address). However, the withdrawal of funds is only performed when the group members (i.e., the conference) use a number of private key shares (the number of which exceeds the threshold required to generate a valid digital signature) to approve the withdrawal.

[0060] The threshold signature scheme implemented by conference 110 can be of various types. The threshold signature scheme allows the signing power to be shared among n parties, as long as at least a threshold number of private key shares contribute to the generation of a valid signature. Any subset less than the threshold cannot generate a valid signature. More specifically, each party controls a share of the private signing key and must use a threshold number of key shares to generate a valid signature by combining partial signatures. Any subset of key shares less than the threshold cannot generate a valid signature.

[0061] The threshold signature scheme can be an elliptic curve digital signature algorithm (ECDSA) scheme. For example, the ECDSA scheme can be the type proposed by Ibrahim et al. in "A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme", 2003 EIII 46th Midwest Symposium on Circuits and Systems, 1: 276-280 (2003). The threshold signature scheme is an extension of the digital signature scheme, which is an algorithm based on elliptic curve encryption, in which t+1 key shares from one of the n key share holders are required to reconstruct the private key. The scheme can be used to construct a valid signature without rebuilding the private key, and no party must disclose its key share to the other party.

[0062] Because t+1 key shares are sufficient to reconstruct the secret, the maximum number of adversaries allowed according to the technique is t. In the model of Ibrahim et al., an adversary is an entity that compromises the party holding the secret share and has access to the secret share. Adversaries can be of various types. For example, a Byzantine adversary is an adversary that may pretend to participate in the protocol while in fact they send incorrect information. The ECDSA scheme proposed by Ibrahim is robust to up to t <= n / 4 malicious adversaries. This robustness can be increased to t <= n / 3, but at the cost of higher complexity.

[0063] The ECDSA scheme of Ibrahim et al. is robust against t <= n / 3 blocking adversaries. The blocking adversary can prevent the corrupting party from participating in the protocol or stopping participation midway.

[0064] The ECDSA scheme includes various mechanisms that can be used by nodes 102 to identify malicious or uncooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir secret sharing (SSS). SSS is a form of secret sharing in which a secret is divided into several parts and each of its unique parts is provided to each participant. These parts can be used to reconstruct the secret. In the case where inconsistent shares are provided to different nodes 102, or in the case where a share different from the blind share broadcast to all nodes is secretly sent to a node, a node 102 can use VSS to identify a malicious node 102 or member. Inconsistent shares can be identified by any one of the nodes 102. The sharing of secrets can be verified by including auxiliary information that allows the node 102 to verify that its share is consistent.

[0065] Sending incorrect shares (i.e., shares that are different from the blind shares that were broadcast) to individual nodes can be identified by the intended recipient nodes of the shares. The identification of incorrect shares that were secretly sent to a node can be publicly verified using public verifiable secret sharing (PVSS) techniques. Such techniques can avoid possible delays in spoofing the identification of the sender that may occur without the use of PVSS, and when the incorrect shares are sent, the recipient of the incorrect shares is offline or cut off from a substantial portion of the network.

[0066] Inappropriate behavior, such as providing inconsistent shares to different nodes, can be addressed by conference 110 to prevent malicious behavior. For example, when node 102 ( Figure 1 ) is identified as a malicious party by other nodes 102, multiple nodes 102 (i.e., nodes associated with conference members) exceeding a threshold (e.g., t+1) can cooperate to punish the malicious party. For example, a node 102 can take an action involving digital assets (such as digital currency or other equity or value) deposited by the malicious party to the conference. For example, the conference can burn digital currency, equity, or value by transferring them to an unspendable address, or the conference can confiscate these digital assets by reaching a consensus with other nodes to reject. Nodes 102 that are not misbehaving nodes can also prevent misbehavior by cooperating to exclude misbehaving nodes (e.g., by effectively invalidating key shares; for example, by excluding nodes from participating in the conference protocol, or by re-sharing private keys instead of allocating shares to misbehaving nodes).

[0067] The ECDSA technique described above can be enhanced by using a TEE. For example, consider a strong form of adversary based on the threshold ECDSA signature technique of Ibrahim et al., referred to here as a Byzantine adversary. This type of adversary can behave arbitrarily, for example, they not only refuse to participate in the signing process or stop participating midway, but they may also pretend to participate honestly and send incorrect information. However, by using a TEE, and generating data for signing within the enclave of the TEE storing the secret private key shares, additional security can be provided because it is extremely unlikely that the enclave can be compromised in large numbers. For example, if each TEE is assigned no more than one key share, then it is reasonable to expect that the number of potentially compromised TEEs does not approach the robustness threshold of the Byzantine adversary, assuming n is large enough. This allows the protocol to be secure if it can tolerate a small number of malicious adversaries relative to the total number of key shares.

[0068] For example, if all nodes have a TEE, then acquisition of secrets stored within the enclave can only be achieved with physical access to the nodes if the manufacturer of the TEE has not been compromised, and only with great effort and expense. Such manufacturer-level compromise is expected to be manageable. For example, if the manufacturer falsely claims that a lot of public keys correspond to real TEEs, they can directly access the private key shares and could launch an attack. However, such an attack would require a sufficient number of key shares to allow the manufacturer to produce valid signatures without the help of other nodes. This would mean accumulating a large portion of the total stake, which would be very expensive. Furthermore, by carrying out the attack, a large portion of the value held by the stake would be destroyed.

[0069] When using TEEs, it is useful to consider the robustness of the protocol to "compromised nodes". A compromised node has hardware external to the TEE compromised, but the integrity of the TEE is not compromised. A compromised node can control what information the enclave does and does not receive. Specifically, a compromised node can stop, i.e., avoid participating in the protocol. If information provided to the protocol is required to be signed by a private key held secretly in the enclave (where the corresponding public key is authenticated during attestation), then the private key is as trusted as the enclave itself. Therefore, a compromised node cannot send arbitrary (authenticated) information to the protocol, and may only attempt to interfere by stopping or attempting to trick the enclave into acting incorrectly (e.g., by providing it with outdated information). Therefore, for compromised nodes, a successful attack will require collecting a sufficient number of partial signatures to produce a complete signature. With a TEE, the protocol of Ibrahim et al. is robust to 2t compromised nodes. Since a signature can be produced if n-2t>=2t+1, then any qualified subset of key shares of size 2t+1<=(n+1) / 2 will suffice. Therefore, when using a TEE, the threshold of the threshold signature scheme can be configured to be a number greater than or equal to 50% of the key share, thereby producing a valid signature in the presence of a compromised node.

[0070] Other threshold schemes may be used, including non-ECDSA signature schemes. For example, node 102 may implement conference 110 using a threshold scheme based on the Schnorr scheme.

[0071] Blockchain Network 100( Figure 1 ) in node 102( Figure 1 ) can implement the conference protocol based on the selected threshold signature scheme. Such a node 102 may include a storage device 220 ( Figure 2 ) in which the computer executable instructions implementing the conference protocol are executed. Figure 2 ) when executed, such instructions cause node 102 (such as reference Figure 2 One or more methods of performing a conference protocol on an electronic device 200 of the type described. These methods may include Figures 4 to 8 Any one or combination of methods 300, 400, 500, 600, 700, 800. Thus, the conference protocol may include Figures 4 to 8 The method of claim 300 , 400 , 500 , 600 , 700 , and 800 may be performed by a node in cooperation with other nodes associated with other conference members.

[0072] Meeting Start

[0073] Reference below Figure 3, a method 300 of initiating a conference 110 is shown. The method 300 may be performed by an initial trusting party to establish the conference 110. That is, a node 102 associated with the initial trusting party may perform the method 300.

[0074] Method 300 includes providing a conference public key at operation 302. The conference public key may be provided to other nodes 102 to allow other nodes to pay to the conference public key when they wish to join the conference. That is, other persons may transfer digital assets to an address associated with the conference public key to join the conference.

[0075] At operation 304, the node 102 performing the method 300 allows payment to the public key until one or more conditions are met. For example, the node may allow payment to the public key for a determined time period or a determined number of blocks. After the conditions are met (e.g., after the time period expires or the number of blocks are mined), the node 102 performing the method 300 identifies the initial members of the conference at operation 306.

[0076] After identifying the parties comprising the initial membership of the conference, the private key is divided into private key shares according to a threshold signature scheme at operation 307. The private key shares are then distributed to the identified parties from the node 102 performing the method 300 at operation 308. The private key shares are associated with a threshold signature scheme, which may be of the type described herein.

[0077] During operation 308, nodes 102 identified as conference members cooperate to generate new private key shares and new public keys. The original key shares sent to these nodes by the initial trust party can be used to sign and broadcast transactions to send all digital assets in the conference pool to the new public key, which then becomes the conference public key. That is, during operation 408, a new group public address is established, and the digital assets under the control of the conference are transferred to the new address, which becomes the new address of the group and is associated with the conference public key. After confirming the transfer, the conference can operate without trust. The new group public address is formed as an address that can receive deposits of digital assets from other nodes that wish to join the conference 110 in the future, or for other purposes as described above. It is now considered that the conference members have joined the conference, and these nodes can now operate without the help of the initial trust party. In addition, the initial trust party no longer plays any role in the operation of the conference.

[0078] Join a meeting after it starts

[0079] Reference below Figure 4 , Figure 4 A method 400 of joining a conference is shown. Figure 4 The method 400 may be combined with Figure 3 The method 300 operates, however, Figure 4The method 400 is performed by Figure 3 The same blockchain network 100 ( Figure 1 ) is performed by different nodes in node 102. Figure 4 The method 400 includes obtaining a conference public key at operation 402. The conference public key can be obtained directly from the party initiating the conference, for example, Figure 3 The nodes of method 300 may also be obtained from a third party, for example, included in the blockchain network 100 ( Figure 1 ) A third-party system operating outside of the system. For example, the conference public key may be obtained from a public web server accessible via the public Internet.

[0080] The node 102 performing the method 400 pays the conference public key by broadcasting a transaction of digital assets from a private account associated with the node 102 to the conference address (i.e., the address associated with the conference public key) at operation 404. More specifically, the node 102 broadcasts a transaction to transfer one or more digital assets to a public group address associated with the conference public key. The public group address is the address of the conference pool. The conference pool includes other digital assets associated with other members of the conference. Therefore, once the transaction in operation 404 is added to the block by the mining node 104, the digital assets are transferred to the conference pool including the digital assets of other members. The public group address can receive transfers from parties who wish to join the conference, or from parties who do not wish to join the conference. Parties who do not wish to join the conference transfer digital assets to the conference pool so that the conference can fully, partially or conditionally control these digital assets by using the threshold signature scheme adopted by the conference.

[0081] The transaction at operation 404 may include a tag, identifier, or other attribute that indicates that the party transferring the digital asset wishes to join the conference and that the deposit is being made for that purpose.

[0082] After depositing the digital asset through the conference pool, the node 102 performing the method 400 receives the private key share at operation 406. The node 102 then regenerates the private key share by running a single instance of the protocol at operation 408. The generation of the private key share may be performed within the TEE of the node 102.

[0083] At operation 408, node 102 generates a private key share to be used in a threshold signature scheme, where at least a threshold of private key shares must be used to generate a valid signature for a transaction on behalf of the conference. The holders of other private key shares are other members of the conference who join the conference on a permissioned or permissionless basis by transferring corresponding digital assets to a public group address.

[0084] To regenerate the private key shares, existing conference members may collaborate to update the key shares at operation 408. For example, node 102 may generate a random polynomial of order t with a constant term of zero: Then, node 102 can calculate the point and set it as their private key share. Then, node 102 can use this polynomial The point on is assigned to each existing conference member i=1, ..., n. Each existing conference member (i=1, ..., n) then adds the received value to its existing private key share to obtain a new private key share. Node 102 now has a private key share equivalent to all other members, and the corresponding public key remains unchanged. As described above, the threshold signature scheme can be of various types, including an elliptic curve digital signature algorithm or a threshold scheme based on the Schnorr scheme.

[0085] Private key shares can be in TEE 250( Figure 2 ) and can be securely stored in node 102. For example, the private key share can be stored in TEE 250.

[0086] After private key shares are generated by each node, funds under the previous conference public key control, such as funds transferred to a public group address associated with the original conference public key (through the cooperation of multiple group nodes sufficient to generate a valid signature under the threshold signature scheme) can be transferred to a new conference public key associated with the new private key shares.

[0087] After the private key share is generated at operation 408, it can be used at operation 410 of method 400. The private key share can be used to collaboratively generate a valid signature for a transaction from a public group address that can be broadcast by members. That is, the private key share can be used to help signature generation in a threshold signature scheme. Under the threshold signature scheme, a threshold number of private key shares of the conference need to be used by each member to produce a valid signature, and the signature allows the digital asset to be transferred out of the conference. The node 102 performing method 400 can retrieve the private key share from storage and use the private key share to help signature generation. If a sufficient number of other conference members also use their respective private keys to help signature generation, the signature is generated and a valid outbound transaction can be broadcast. When the mining node 104 of the blockchain network 100 adds the transaction to the mined block added to the blockchain by the consensus of the nodes in the blockchain network 100 and the block is confirmed, the outbound transaction is completed. At this point, the digital assets represented in the transaction can no longer be controlled by the conference. That is, such digital assets can no longer be hindered by the public key of the conference.

[0088] Using the private key share at operation 408 may be performed within the TEE of node 102. The TEE protects the private key share so that other parts of the system or the members themselves cannot access any data stored in the enclave, such as the private key share. Additionally, the TEE protects the private key because if the member wants their deposit back and withdraws their deposit, it cannot keep a copy of the private key because it must delete the private key before proving the return of the member's deposit.

[0089] Figure 4 The method 400 may be performed during or after the initial setup phase. That is, the method 400 may be performed before the initial key shares are distributed (e.g., before the initial key shares are distributed). Figure 3 The process may be performed during operation 308 of method 300 ) or thereafter (e.g., during a rebalancing process discussed in more detail below).

[0090] The transaction at operation 410 may transfer the digital assets back to the party that originally deposited the digital assets into the conference pool. That is, the transfer may return the digital assets to the depositor. The transfer may also transfer the digital assets to other places. For example, the digital assets may be transferred to a third party or a non-consumable address.

[0091] Confiscation of digital assets

[0092] Reference below Figure 5 , illustrating an exemplary method 500 for confiscating digital assets. Figure 5 The method 500 may be performed by the node 102, which may be a node that performs Figure 4 The node of method 400 is the same node. Figure 4 Method 500 is performed after operation 408 of method 400, so that Figure 5 When performing method 500, the node 102 already has access to the private key share.

[0093] At operation 502, node 102 detects malicious activity of a malicious party. The malicious party may be another member of the conference. Malicious activity is detected when node 102 determines that a member of the conference violates a predetermined protocol or guideline. For example, when a node that is a member of the conference reports false information (i.e., erroneous, inconsistent, or otherwise unacceptable information) to other members of the conference, the member may be considered a malicious member.

[0094] In operation 503, in response to detecting malicious activity, node 102 cooperates with other nodes in the conference to suspend the member who is a malicious party. In other words, the conference can exclude the malicious party from further participating in the conference.

[0095] In order to ensure that all nodes 102 operate in accordance with a predetermined protocol or criteria, member deposits entering the conference pool may be confiscated. Confiscation means permanently preventing the return of member deposits that are deemed confiscated. (One or more) digital assets that constitute member deposits that are not returned due to malicious activity may remain in the conference pool but not be returned (in response to a consensus that the action should be taken), be transferred to another non-consumable address immediately or in the future, or be confiscated in other ways, and the nature of the confiscation may depend on whether the conference acts as a collateral validator set for the side chain. For example, in operation 504, in response to detecting malicious activity by a malicious party, the node 102 performing method 500 may use a private key share to provide a partial signature on a confiscation transaction (which is a transaction that transfers a digital asset to a non-consumable address or another node as a reward for exposing the malicious activity). That is, the node cooperates with other nodes of the conference to confiscate at least a portion of the digital assets previously transferred to the public group address (i.e., transferred to the conference pool) by the malicious party. That is, in response to observing a group member violating a predetermined protocol or guideline, a private key share is used to facilitate authorization of a transaction of one or more digital assets associated with the group member and held in the conference pool.

[0096] Because the threshold signature scheme is used with the conference public key, individual nodes acting alone cannot transfer the deposit of another conference member's digital assets out of the conference pool (e.g., to an unconsumable address). In contrast, when a threshold number of private key shares are used by their respective members to generate a valid signature to transfer digital assets (multiple) to another address, or when a member group with at least a threshold number of private key shares reaches a consensus to suspend a member (in operation 503), digital assets can only be confiscated by transfer, which causes any withdrawal request from the suspended member to be automatically ignored. When a digital asset is confiscated by transfer, other addresses to which (one or more) digital assets can be transferred can be associated with an unconsumable address. For example, another address can be an address where a private key does not exist, so no party can access the digital assets bound by the public key of the address. When confirming a transaction to transfer a digital asset to an unconsumable address or when a consensus is reached on the side chain that a digital asset should be confiscated, the digital asset may be considered to have been burned because they can no longer be consumed by any member of the conference or in fact by any node in the blockchain network 100.

[0097] Thus, at operation 504, the node may confiscate the digital asset by using the private key share in cooperation with other members of the conference to generate a valid signature for a transaction to a non-spendable address, and in some embodiments may involve reaching a consensus on the second blockchain that the member's deposit should be permanently deprived of all or part of it.

[0098] Additionally, in some embodiments, the conference can act as a set of bonded validators to secure a proof-of-stake sidechain, and the sidechain can be used as a broadcast channel. For example, conference members can reach a consensus on the sidechain that a member has acted maliciously. This consensus can correspond to a confirmation of a sidechain transaction that contains incriminating evidence of malicious activity. After consensus is reached, any request by a malicious member to withdraw a member's deposit will be rejected and the deposit will be considered confiscated. Confiscated digital assets may be burned at some time in the future. That is, at some later time, a threshold number of members (excluding malicious members) can cooperate to authorize the transfer of confiscated digital assets to a non-spendable address.

[0099] Because the conference is an open group that can be joined by any node 102 of the blockchain network 100 by storing digital assets, group membership can change periodically. When such changes occur, the private key share allocation can be updated. Figure 6 , showing an exemplary method 600 for updating private key share distribution. The method 600 can be performed by the node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0100] Update the private key share distribution with the new public address

[0101] At operation 602 of method 600, node 102 detects a reallocation request, which is a request whose implementation involves reallocating key shares. For example, node 102 may detect that a potential new member has transferred digital assets to a public group address or that an existing member has requested to withdraw a member deposit.

[0102] Digital assets can be transferred to the public group address by the following nodes: nodes that request to join the meeting or increase their participation in the meeting and other nodes that do not request to join the meeting but transfer digital assets to the meeting for other purposes (e.g., transfer digital assets to the side chain, as described below). In operation 602, node 102 can use one or more attributes included in at least a portion of the transaction from digital assets to the public group address to identify the meeting members (i.e., the parties that transfer digital assets to the meeting public key to join the meeting instead of other purposes). For example, certain transactions can be marked as special transactions using attributes in the transaction. These attributes (whether they exist or not) can indicate the purpose of the transfer. For example, when the transferor does not request to join the meeting, a mark can be included in the transaction.

[0103] In response to detecting at operation 602 that its implementation involves a request to redistribute key shares, at operation 604, node 102 Figure 4The method 400 generates a private key share in the manner of operation 408, generating a new private key share. The other member nodes of the conference also generate corresponding private key shares. These private key shares can be used with the threshold signature scheme for the new conference public key. Members who will leave the conference at this time do not generate new private key shares during operation 604 and because they will not be assigned a private key share to be used with the new conference public key, they lose the ability to participate in the conference and are no longer considered as conference members.

[0104] In addition, in response to detecting a reallocation request (a reallocation request is a request whose implementation involves reallocating key shares), in operation 606, node 102 cooperates with other conference members to transfer all digital assets in the public group address to a new public address associated with a new public key (which will later become the new conference public key).

[0105] Therefore, according to Figure 6 In method 600, when the allocation of deposits changes or when a request to withdraw a deposit is received from a member, the private key shares can be regenerated and all digital assets under the control of the conference can be moved to the new public key. The frequency with which conference membership can be updated is limited by the block time of the blockchain network 100. Many applications may only need to rebalance at a low frequency.

[0106] Update private key share distribution while preserving existing public group addresses

[0107] Reference below Figure 7 , another exemplary method 700 for updating the private key share distribution is shown. The method 700 can be performed by the node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0108] exist Figure 7 In method 700, the conference public key does not change each time the allocation of member deposits changes. When a request to allocate new key shares is detected (at operation 702, which may occur by depositing digital assets to a public group address), node 102 cooperates with other members of the conference to issue new private key shares for the same public key to the new members of the group (at operation 704). The number of nodes cooperating is at least the threshold number of nodes required to generate a digital signature under the threshold signature scheme. At operation 704, additional key shares can be allocated while other key shares remain unchanged. This may involve a threshold change (of the threshold signature scheme), but in practice the change may be small. Alternatively, at operation 704, additional key shares can be allocated while updating other key shares. Such an update needs to be accompanied by proof of the deletion of any previous generation of key shares. In this case, new shares can be allocated while maintaining the same threshold (in the context of SSS, this involves sharing a new polynomial of higher order).

[0109] At operation 702, node 102 may use one or more attributes included in at least a portion of the transaction of the digital asset to the public group address to identify conference members (i.e., parties that transfer digital assets to the conference public key to join the conference and not for other purposes). For example, certain transactions may be marked as special transactions using attributes in the transaction. These attributes (whether present or absent) may indicate the purpose for which the transfer was made. For example, when the transferor did not request to join the conference, a flag may be included in the transaction.

[0110] When members leave a conference using method 700, they can securely delete their private key shares. To ensure that the old member's private key shares are not available, members of the conference can be required to use nodes 102 with special TEEs. A TEE is an architecture implemented at the hardware level that guarantees that instructions and data executed within it are protected from access and manipulation from the rest of the system. A TEE can employ hardware mechanisms to respond to remote attestation queries, which can be used to verify the integrity of the system to external parties (e.g., other nodes in the conference).

[0111] Each member node may use an attested TEE that is configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising the hardware at the integrated circuit level. The secret values ​​generated in this manner will be used for the distributed generation of private key shares (e.g., in Figure 4 The secret value may also be used to establish a shared public key during the setup phase of the conference. The computations associated with the setup protocol are performed within the TEE enclave so that no member or former member can derive any information about their own or other private key shares from inter-member communications or any other method. The enclave within the TEE enables a remote attestation protocol that can be used to prove to other nodes that the TEE enclave is authentic and that it is running approved computer-readable instructions.

[0112] The computations associated with the group change are performed within the TEE enclave. For example, the generation of a new secure random secret that can be used to compute a new polynomial for SSS purposes is performed within the TEE enclave.

[0113] In addition, the purpose of the TEE enclave is to ensure that previous key shares and previous secrets that are no longer in use are securely deleted before returning a member's deposit. More specifically, in order to return a member's deposit, the attestation protocol may require the TEE enclave to attest to the deletion of the key shares. Through the remote attestation protocol, each node 102 can interpret this attestation as a confirmation that the required deletion has occurred on other nodes. Therefore, the method 700 may also include confirming that the private key shares previously held within the TEE of the member leaving the meeting have been deleted from the node associated with the member. This confirmation can be performed by receiving a proof of the deletion of the private key shares. Therefore, the remote attestation protocol can be used to obtain a proof of the deletion of the private key shares previously held in the TEE of the member leaving the meeting.

[0114] Figure 6 Method 600 and Figure 7 The method 700 provides various benefits. For example, Figure 6 The method 600 does not rely on secure deletion, nor does it rely on trusted hardware. However, Figure 6 Method 600 may benefit from such hardware because, in some cases, such hardware may make malicious pooling of key shares less likely.

[0115] Figure 7 Method 700 avoids having to re-lock digital assets under a new conference public key each time membership changes. For example, embodiments of method 700 that employ TEEs may allow for the use of persistent group addresses where group members can come and go without compromising security. Conveniently, in this way, the overhead of having to change group addresses may be avoided while still providing adequate security. Additionally, in some cases, method 700 and Figure 6 The membership can be updated faster than in method 600 because Figure 7 Under method 700, there is no need to add a transaction to the blockchain to move all digital assets to the new public key because the digital assets are not moved to the new public key. Figure 7 Method 700 can be used to update membership without waiting for several blocks to be generated to confirm the transfer of digital assets to the new public key because the public key has not changed.

[0116] Logging out of a meeting

[0117] As mentioned above, group members may sometimes request to leave a conference, and when group members log out of a conference, their digital assets that they deposited into the conference pool may be returned to them. Figure 8 , an exemplary method 800 of returning a deposit is shown in the form of a flow chart. The method can be performed by a node 102 in cooperation with other nodes 102 of a conference.

[0118] At operation 802 of method 800, node 102 receives a withdrawal request from a requestor as a conference member. A withdrawal request may also be referred to as a logout request. A withdrawal request is a request to withdraw a digital asset previously deposited by the requestor and currently controlled by the conference. The request may have been broadcast by the requestor to all conference members.

[0119] In response to receiving the request, node 102 evaluates the request against determined criteria at operation 804. The criteria may be predetermined criteria. If the conference operates according to a conference protocol in which the conference public key does not change each time group membership changes, then at operation 804, node 102 may confirm that the requestor has deleted the private key share. Such confirmation may be obtained using a remote attestation protocol associated with the TEE.

[0120] If the conference protocol is one in which the conference public key is changed when membership changes, node 102 may not confirm the deletion of the private key share because the private key share is no longer valid. Instead, a new conference key may be used and other digital assets under the control of the conference may be transferred to the new conference key.

[0121] If the node 102 approves the withdrawal request based on the evaluation, then at operation 806, the node facilitates the withdrawal of the digital asset. That is, the node 102 uses its share of the private key to cooperatively generate a digital signature and uses the digital signature to transfer the digital asset previously deposited by the requester back to the requester. For example, the digital asset can be sent back to the address from which the digital asset was previously received. Operation 806 is performed according to a threshold signature scheme so that the withdrawal is only performed when at least a threshold number of conference members authorize the withdrawal. Operation 806 is performed after the member who wishes to cancel is suspended for a period of inactivity. This waiting period prevents members from engaging in improper behavior while the protocol for the return of their member deposits is in progress.

[0122] The conferencing protocol can be used for many different purposes. Conferencing provides a secure mechanism for performing various functions. Conferencing can operate trustlessly and provide control over the ownership of digital assets.

[0123] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any figure marks in brackets should not be interpreted as limiting the claims. The words "comprises" and the like do not exclude the presence of elements or steps other than those listed as a whole in any claim or specification. In this specification, "comprises" means "includes" or "consists of...". The singular reference of an element does not exclude the plural reference of these elements, and vice versa. The present invention can be implemented by hardware comprising several different elements, and by a suitably programmed computer. In a device claim that lists several devices, several of these devices can be implemented by one item or the same item of hardware. The mere fact that certain measures are stated in mutually different dependent claims does not mean that the combination of these measures cannot be used to benefit.

Claims

1. A computer-implemented method for controlling a digital asset, comprising: Broadcasting, by a node in the blockchain network, a transaction to transfer one or more digital assets to a public group address associated with the conference public key, the public group address being associated with one or more other digital assets associated with other members of the conference; generating a private key share to be used in a threshold signature scheme, in which at least a threshold number of private key shares must be used to generate a valid signature by combining partial signatures representing the conference, and wherein other holders of the private key shares are other members of the conference who have joined the conference by transferring their respective digital assets to the public group address; and A valid signature for a transaction is collaboratively generated from the public group address using the private key shares.

2. The computer-implemented method of claim 1 , wherein: The threshold signature scheme is an elliptic curve digital signature algorithm.

3. The computer-implemented method of claim 1 , further comprising: detecting malicious activity by a malicious party, wherein the malicious party is one of the other members of the conference; and Confiscating at least a portion of the digital assets previously transferred by the malicious party to the public group address.

4. The computer-implemented method of claim 3, wherein: Confiscation includes transfer to a non-spendable address.

5. The computer-implemented method of claim 4, wherein: Confiscating includes using the private key share in collaboration with other members of the conference to generate a valid signature for a transaction to the non-spendable address.

6. The computer-implemented method according to any one of claims 1 to 5, further comprising: Detect reallocation requests; Working with other conference members to transfer all digital assets in the public group address to a new public address associated with the new public key; as well as Generate a new private key share.

7. The computer-implemented method according to any one of claims 1 to 5, further comprising: detecting a request to allocate a new key share; as well as In cooperation with other members of the conference, a private key share of the same public key is issued to new members of the group.

8. The computer-implemented method of claim 7, further comprising: Confirm that the private key shares previously held by the member who has left the conference have been deleted from the nodes associated with the member.

9. The computer-implemented method of claim 8, wherein the node associated with the member that has left the conference includes a trusted execution environment that provides proof of deletion of the private key share previously held by the member.

10. The computer-implemented method of claim 7, wherein: The conference public key encumbers digital assets received from group members and non-group members, and wherein detecting a request to allocate a new key share includes identifying a conference member using an attribute included in at least a portion of a transaction of a digital asset to the public group address.

11. The computer-implemented method of any one of claims 1 to 5, wherein: The private key share is generated and used on a trusted execution environment within the node.

12. The computer-implemented method of any one of claims 1 to 5, further comprising: Receiving a request from a requestor who is a member of a conference to withdraw a digital asset previously deposited by the requestor and currently controlled by the conference; evaluating the request against determined criteria; as well as A digital signature is collaboratively generated using the private key shares and used to transfer a digital asset previously deposited by the requestor back to the requestor.

13. A computer-readable storage medium comprising computer-executable instructions which, when executed, configure a processor to perform the method of any one of claims 1 to 12.

14. An electronic device comprising: Interface device; a processor coupled to the interface device; A memory is coupled to the processor, wherein computer executable instructions are stored in the memory, and when the computer executable instructions are executed, the processor is configured to perform the method according to any one of claims 1 to 12.

15. The electronic device according to claim 14, wherein: The processor comprises a trusted execution environment, and wherein the computer-executable instructions execute within the trusted execution environment.

Images