CN112560072A

CN112560072A - Key management method, device, medium and equipment based on block chain

Info

Publication number: CN112560072A
Application number: CN202110187195.5A
Authority: CN
Inventors: 徐文超; 申子熹
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-02-18
Filing date: 2021-02-18
Publication date: 2021-03-26
Anticipated expiration: 2041-02-18
Also published as: CN112560072B

Abstract

The present disclosure provides a method for managing a key based on a blockchain, a device for managing a key based on a blockchain, a computer-readable storage medium, and an electronic device, which relate to the technical field of blockchains, and include: receiving a cochain request signed by at least one signer; verifying the legality of the sub-account signature in the uplink request; if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of the main account signature in the uplink request; the signature parties corresponding to the sub-account signature and the main account signature are different; if the signature of the main account has validity, judging that the uplink request has validity; responding to the uplink request and identifying the response result, and packaging and writing the response result into the block chain account book. Therefore, the data in the request can be doubly encrypted in a multi-party encryption mode by implementing the method, so that double decryption is required when the block chain node decrypts, and the data security is guaranteed.

Description

Key management method, device, medium and equipment based on block chain

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a method and an apparatus for managing a key based on a blockchain, a computer-readable storage medium, and an electronic device.

Background

Generally, asymmetric encryption technology is used in a block chain to encrypt data to ensure data security. One node in the block chain encrypts the data needing to be linked through a private key, and the node holding the public key corresponding to the private key can decrypt the data and identify the data together, so that data linking is completed. For enterprises, a private key used in the asymmetric encryption technology is usually stored in a server, so that automatic signing of each project program in the enterprise is facilitated. However, an enterprise usually has multiple departments, and different departments are responsible for different project programs, and all data to be linked is encrypted by using one private key through the centralized signature mode, so that risks easily exist, and once the private key is lost, the data security is difficult to guarantee.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The embodiment of the disclosure can perform double encryption on data in a request in a multi-party encryption manner, so that double decryption is required when a blockchain node decrypts the data, thereby ensuring data security.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to an aspect of the present disclosure, there is provided a method for managing a key based on a block chain, including:

receiving a cochain request signed by at least one signer;

verifying the legality of the sub-account signature in the uplink request;

if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of the main account signature in the uplink request; the signature parties corresponding to the sub-account signature and the main account signature are different;

if the signature of the main account has validity, judging that the uplink request has validity;

responding to the uplink request and identifying the response result, and packaging and writing the response result into the block chain account book.

According to an aspect of the present disclosure, there is provided a block chain-based key management apparatus including:

a request receiving unit, configured to receive a ul request signed by at least one signer;

the signature verification unit is used for verifying the validity of the account signature in the uplink request;

the signature verification unit is also used for verifying the validity of the main account signature in the uplink request when the sub-account signature has validity and the uplink request meets double verification conditions; the signature parties corresponding to the sub-account signature and the main account signature are different;

the result judging unit is used for judging the legality of the uplink request when the legality of the main account signature exists;

and the request response unit is used for responding to the uplink request, identifying the response result and packaging and writing the response result into the block chain account book.

In an exemplary embodiment of the present disclosure, the signature content of the sub-account signature includes the request content of the uplink request, and the signature content of the primary account signature includes the request content and the sub-account signature; alternatively, the signature content signed by the sub-account and the signature content signed by the main account both comprise the request content.

In an exemplary embodiment of the present disclosure, the apparatus further includes:

a signer type determining unit, configured to determine the signer type of the uplink request according to a type of codes in the uplink request; wherein one type of code is used as a unique representation of a signing party corresponding to the sub-account signature; if the signer type is organization, the uplink request is judged to meet the double check condition.

the request uplink unit is used for storing the uplink request in the transaction pool when the type of the signing party is personal; responding to the request in the transaction pool according to the preset unit time length; and performing consensus on the response results and packaging the response results into blocks to be written into a block chain account book.

In an exemplary embodiment of the present disclosure, the signer type determination unit determines that the uplink request satisfies the double check condition, including:

and detecting whether the signature of the primary account is empty, and if not, judging that the uplink request meets double check conditions.

and the storage unit is used for storing the uplink request to the to-be-signed pool when the signer type determination unit detects that the signature of the primary account is empty, so that the signer corresponding to the signature of the primary account signs the uplink request when monitoring the uplink request.

In an exemplary embodiment of the present disclosure, a signer corresponding to a primary account signature signs a uplink request when monitoring the uplink request, including:

when a signature party corresponding to the primary account signature monitors a chain loading request, performing compliance detection on request content in the chain loading request;

if the request content is detected to be in compliance, the signature party corresponding to the primary account signature carries out signature on the uplink request, so that the primary account signature is not null.

In an exemplary embodiment of the present disclosure, the signature verification unit verifies validity of a primary account signature of the uplink request, including:

detecting whether signature content corresponding to the primary account signature contains a sub-account signature and request content of a cochain request;

if so, determining a second type of code corresponding to the first type of code and acquiring a public key corresponding to the second type of code; wherein the class two codes are for a unique representation as a signer corresponding to the primary account signature;

verifying whether a public key corresponding to the second-class code is consistent with a public key in the main account signature;

and if the signatures are consistent, judging that the signature of the main account is legal.

and the type changing unit is used for changing the type of the signing party from an organization to an individual and storing the uplink request into the transaction pool when the signature verification unit detects that the second type of code corresponding to the first type of code does not exist.

and the request discarding unit is used for judging that the primary account signature is not legal and discarding the uplink request when the signature verification unit detects that the public key corresponding to the second class of codes is inconsistent with the public key in the primary account signature.

before the request receiving unit receives the uplink request signed by at least one signing party, a signing party corresponding to the sub-account signature generates request content through a subordinate account and signs the request content to obtain a sub-account signature;

the signature party corresponding to the sub-account signature sends the sub-account signature to the signature party corresponding to the main account signature, so that the signature party corresponding to the main account signature signs the sub-account signature to obtain the main account signature;

and the signer corresponding to the primary account signature generates a uplink request according to the primary account signature and broadcasts the uplink request in the block chain network, so that the node in the block chain network can check the legality of the sub-account signature of the uplink request.

In an exemplary embodiment of the present disclosure, the signature verification unit verifies the validity of the sub-account signature of the uplink request, including:

and detecting whether the signature content corresponding to the sub-account signature contains the request content, and if so, judging that the sub-account signature is legal.

According to an aspect of the present application, there is provided an electronic device including: a processor; and a memory for storing executable instructions for the processor; wherein the processor is configured to perform the method of any of the above via execution of the executable instructions.

According to an aspect of the application, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any one of the above.

According to an aspect of the application, a computer program product or computer program is provided, comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method provided in the various alternative implementations described above.

The exemplary embodiments of the present application may have some or all of the following advantages:

in an example embodiment of the present application, a block chain-based key management method may receive a ul request signed by at least one signer; verifying the legality of the sub-account signature in the uplink request; if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of the main account signature in the uplink request; the signature parties corresponding to the sub-account signature and the main account signature are different; if the signature of the main account has validity, judging that the uplink request has validity; responding to the uplink request and identifying the response result, and packaging and writing the response result into the block chain account book. According to the above technical description, on one hand, the data in the request can be doubly encrypted in a multi-party encryption manner, so that the block chain node needs to be doubly decrypted when decrypting, and thus the data security is guaranteed. In another aspect of the application, a mode of encrypting by using one private key for a plurality of accounts can be continued, and based on secondary encryption on the basis, the number of the private keys is not increased on the premise of guaranteeing data security, so that the utilization rate of a storage space is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 is a schematic diagram illustrating an exemplary system architecture of a blockchain-based key management method and a blockchain-based key management apparatus to which an embodiment of the present application may be applied.

FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Fig. 3 schematically shows an alternative structure diagram of the distributed system applied to the blockchain system according to an embodiment of the present application.

Fig. 4 schematically shows a schematic diagram of a Block Structure (Block Structure) according to an embodiment of the present application.

Fig. 5 schematically shows a flow chart of a method of block chain based key management according to an embodiment of the present application.

Fig. 6 schematically shows a sequence diagram of public key uplink manner according to an embodiment of the present application.

Fig. 7 schematically shows a signature structure diagram according to an embodiment of the application.

Fig. 8 schematically shows a signature validity checking flow diagram according to an embodiment of the present application.

Fig. 9 schematically shows a sequence diagram of a block chain based key management method according to an embodiment of the present application.

Fig. 10 schematically shows a flow chart of a method of block chain based key management according to an embodiment of the present application.

Fig. 11 schematically shows a block diagram of a block chain-based key management apparatus according to an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present application.

Furthermore, the drawings are merely schematic illustrations of the present application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Fig. 1 is a schematic diagram illustrating a system architecture of an exemplary application environment to which a blockchain-based key management method and a blockchain-based key management apparatus according to an embodiment of the present application may be applied.

As shown in fig. 1, the system architecture 100 may include one or more of

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. The

terminal devices

101, 102, 103 may be various electronic devices having a display screen, including but not limited to desktop computers, portable computers, smart phones, tablet computers, and the like. It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. For example, server 105 may be a server cluster comprised of multiple servers, or the like.

The key management method based on the blockchain provided by the embodiment of the present application is generally executed by the server 105, and accordingly, the key management device based on the blockchain is generally disposed in the server 105. However, it is easily understood by those skilled in the art that the key management method based on the blockchain provided in the embodiment of the present application may also be executed by the

terminal device

101, 102, or 103, and accordingly, the key management apparatus based on the blockchain may also be disposed in the

terminal device

101, 102, or 103, which is not particularly limited in the exemplary embodiment. For example, in one exemplary embodiment, the server 105 may receive at least one signer-signed uplink request; verifying the legality of the sub-account signature in the uplink request; if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of the main account signature in the uplink request; the signature parties corresponding to the sub-account signature and the main account signature are different; if the signature of the main account has validity, judging that the uplink request has validity; responding to the uplink request and identifying the response result, and packaging and writing the response result into the block chain account book.

It should be noted that the computer system 200 of the electronic device shown in fig. 2 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 2, the computer system 200 includes a Central Processing Unit (CPU) 201 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 202 or a program loaded from a storage section 208 into a Random Access Memory (RAM) 203. In the RAM 203, various programs and data necessary for system operation are also stored. The CPU 201, ROM 202, and RAM 203 are connected to each other via a bus 204. An input/output (I/O) interface 205 is also connected to bus 204.

The following components are connected to the I/O interface 205: an input portion 206 including a keyboard, a mouse, and the like; an output section 207 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 208 including a hard disk and the like; and a communication section 209 including a network interface card such as a LAN card, a modem, or the like. The communication section 209 performs communication processing via a network such as the internet. A drive 210 is also connected to the I/O interface 205 as needed. A removable medium 211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is mounted on the drive 210 as necessary, so that a computer program read out therefrom is installed into the storage section 208 as necessary.

In particular, according to embodiments of the present application, the processes described below with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 209 and/or installed from the removable medium 211. The computer program, when executed by a Central Processing Unit (CPU) 201, performs various functions defined in the methods and apparatus of the present application.

The system related to the embodiment of the invention can be a distributed system formed by connecting a client, a plurality of nodes (any form of computing equipment in an access network, such as a server and a user terminal) through a network communication mode.

Taking a distributed system as an example of a blockchain system, referring To fig. 3, fig. 3 is an optional structural schematic diagram of the blockchain-based key management device 300 applied To the blockchain system, which is provided by the embodiment of the present invention and is formed by a plurality of nodes 301 (any form of computing devices in an access network, such as servers and user terminals) and a client 302, the blockchain-based key management device 300 may be any node in the plurality of nodes, a Peer-To-Peer (P2P, Peer To Peer) network is formed between the nodes, and the P2P Protocol is an application layer Protocol operating on a Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or a terminal, can join to become a node, and the node comprises a hardware layer, a middle layer, an operating system layer and an application layer.

Referring to the functions of each node in the blockchain system shown in fig. 3, the functions involved include:

1) routing, a basic function that a node has, is used to support communication between nodes.

Besides the routing function, the node may also have the following functions:

2) the application is used for being deployed in a block chain, realizing specific services according to actual service requirements, recording data related to the realization functions to form recording data, carrying a digital signature in the recording data to represent a source of task data, and sending the recording data to other nodes in the block chain system, so that the other nodes add the recording data to a temporary block when the source and integrity of the recording data are verified successfully.

For example, the services implemented by the application include:

2.1) wallet, for providing the function of transaction of electronic money, including initiating transaction (i.e. sending the transaction record of current transaction to other nodes in the blockchain system, after the other nodes are successfully verified, storing the record data of transaction in the temporary blocks of the blockchain as the response of confirming the transaction is valid; of course, the wallet also supports the querying of the electronic money remaining in the electronic money address.

And 2.2) sharing the account book, wherein the shared account book is used for providing functions of operations such as storage, query and modification of account data, record data of the operations on the account data are sent to other nodes in the block chain system, and after the other nodes verify the validity, the record data are stored in a temporary block as a response for acknowledging that the account data are valid, and confirmation can be sent to the node initiating the operations.

2.3) Intelligent contracts, computerized agreements, which can enforce the terms of a contract, implemented by codes deployed on a shared ledger for execution when certain conditions are met, for completing automated transactions according to actual business requirement codes, such as querying the logistics status of goods purchased by a buyer, transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods; of course, smart contracts are not limited to executing contracts for trading, but may also execute contracts that process received information.

3) And the Block chain comprises a series of blocks (blocks) which are mutually connected according to the generated chronological order, new blocks cannot be removed once being added into the Block chain, and recorded data submitted by nodes in the Block chain system are recorded in the blocks.

Referring to fig. 4, fig. 4 is an optional schematic diagram of a Block Structure (Block Structure) provided in the embodiment of the present invention, where each Block includes a hash value of a transaction record stored in the Block (hash value of the Block) and a hash value of a previous Block, and the blocks are connected by the hash values to form a Block chain. The block may include information such as a time stamp at the time of block generation. A block chain (Blockchain), which is essentially a decentralized database, is a string of data blocks associated by using cryptography, and each data block contains related information for verifying the validity (anti-counterfeiting) of the information and generating a next block.

In the entire system of blockchains, the private key is the master of the entire account, and possession of the private key has possession of the entire account asset. Currently, enterprises usually store private keys in a server so that each project program can be automatically signed. The secure management of assets is particularly important for businesses (e.g., exchanges) where it is difficult to secure data once the private key is lost.

The present exemplary embodiment provides a key management method based on a block chain. The key management method based on the block chain may be applied to the server 105, and may also be applied to one or more of the

terminal devices

101, 102, and 103, which is not particularly limited in this exemplary embodiment. Referring to fig. 5, the block chain-based key management method may include the following steps S510 to S550.

Step S510: and receiving the uplink request signed by at least one signer.

Step S520: and verifying the legality of the sub-account signature in the uplink request.

Step S530: if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of the main account signature in the uplink request; and the signature party corresponding to the sub-account signature and the main account signature is different.

Step S540: if the primary account signature is legal, the uplink request is judged to be legal.

Step S550: responding to the uplink request and identifying the response result, and packaging and writing the response result into the block chain account book.

By implementing the method shown in fig. 5, the data in the request can be doubly encrypted in a multi-party encryption manner, so that the block chain node needs to be doubly decrypted when decrypting, thereby ensuring the data security. In addition, a mode of encrypting by using one private key for a plurality of accounts can be continued, and on the basis of secondary encryption, the number of the private keys is not increased on the premise of ensuring data security, so that the utilization rate of a storage space is improved.

The above steps of the present exemplary embodiment will be described in more detail below.

In step S510, at least one signer signed uplink request is received.

Wherein the at least one signer may comprise a signer signed by the primary account and/or a signer signed by the sub-account. The uplink request may be signed at least once by at least one signer before receiving the uplink request signed by the at least one signer.

In step S520, the validity of the sub-account signature in the uplink request is verified.

Specifically, the sub-account signature may be a signature of the request content in the uplink request, the sub-account signature may be represented by a character string, and similarly, the main account signature may also be represented by a character string, and the sub-account signature and the main account signature may be hash values. Step S520 may be performed by any node in the block chain. The uplink request conforms to an Interchange Client Address Protocol (ICAP); ICAP is used to reference and process customer accounts, among other things, in an effort to simplify the funds transfer process.

In addition, before step S520, the method may further include steps in the sequence diagram shown in fig. 6, where fig. 6 schematically shows a sequence diagram of a public key uplink manner according to an embodiment of the present application. The sequence diagram may include step S610 and step S620. Specifically, when the public key obtaining request corresponding to the signer of the sub-account signature is detected, the node where the contract administrator is located may perform step S610: distributing an enterprise organization code and an enterprise administrator public key pubkey; and performing step S620: and signing the code + pubkey and broadcasting the signed result so that the common identification node performs common identification on the signed result and packages and writes the result into a public key contract in the block chain, thereby facilitating other nodes to read the public key in the public key contract when verifying the main account signature in the uplink request so as to compare the public key with the public key in the main account signature and further confirm the validity of the signature party corresponding to the public key. Wherein the node at which the contract administrator is located may belong to a party of the user.

As an alternative embodiment, before receiving the ul request signed by at least one signer, the method further includes: a signer corresponding to the sub-account signature generates request content from the subordinate account and signs the request content to obtain a sub-account signature (sign); the signature party corresponding to the sub-account signature sends the sub-account signature to the signature party corresponding to the main account signature, so that the signature party corresponding to the main account signature signs the sub-account signature to obtain a main account signature (extra _ sign); and the signer corresponding to the primary account signature generates a uplink request according to the primary account signature and broadcasts the uplink request in the block chain network, so that the node in the block chain network can check the legality of the sub-account signature of the uplink request.

Specifically, the signer corresponding to the sub-account signature may be an enterprise sub-account, the signer corresponding to the main account signature may be an enterprise administrator account, and one enterprise administrator account may correspond to one or more enterprise sub-accounts, which is not limited in the embodiment of the present application. Similarly, the enterprise organization code corresponding to an enterprise administrator account may be associated with the enterprise organization code of one or more enterprise sub-accounts.

The method for obtaining the signature of the sub-account by the signer corresponding to the signature of the sub-account generating the request content from the subordinate account and signing the request content includes: the signer corresponding to the sub-account signature generates the request content from the sub-account (such as an enterprise sub-account), and signs the request content through the sub-account private key of the signer corresponding to the sub-account signature to obtain the sub-account signature. The signature party corresponding to the primary account signature signs the sub-account signature to obtain the primary account signature, and the method comprises the following steps: the signer corresponding to the primary account signature signs the sub-account signature and the request content through a primary account private key (such as a private key of an enterprise administrator account) to obtain the primary account signature.

Referring to fig. 7, fig. 7 schematically illustrates a signature structure according to an embodiment of the present application. As shown in fig. 7, the signature structure corresponding to the uplink request may include: request content including account address, sub-account signature and primary account signature. Specifically, step S710 may be performed first: the signing party corresponding to the sub-account signature signs the request content, and the sub-account signature can be obtained. Furthermore, the signer corresponding to the sub-account signature can send the sub-account signature and the request content to the signer corresponding to the main account signature. Thus, step S720 may be performed: and the signature party corresponding to the primary account signature signs the sub-account signature and the request content, so that the primary account signature is obtained. Furthermore, the signer corresponding to the primary account signature can generate a uplink request according to the primary account signature and broadcast the uplink request in the blockchain network.

Therefore, the implementation of the alternative embodiment can ensure data security by means of double encryption. When the application is applied to the transaction request based on the ICAP protocol, the legality of the transaction data of each uplink can be guaranteed after the transaction data are subjected to secondary signature, and therefore the security of the transaction data is guaranteed.

As an alternative embodiment, the verifying the validity of the sub-account signature of the uplink request includes: and detecting whether the signature content corresponding to the sub-account signature contains the request content, and if so, judging that the sub-account signature is legal.

Specifically, the request content may include an account address, the account address being compliant with ICAP. The account address may include: the chain prefix, the check code, the enterprise organization code and the account real address, and the structure of the account address can be represented by the following table:

the chain prefix may be used to represent a name or an identifier of a blockchain, and the blockchain in this application may be a federation chain, a private chain, or a public chain, which is not limited in this application. The check code is used for checking the chain prefix, the enterprise organization code and the account actual address to calculate a hash value. The enterprise organization code is represented by a character string and can be used for identifying the type of a signing party; if the type of the signer is an organization, the account of the signer signed by the sub-account may be an enterprise sub-account, for example, the enterprise organization code of the enterprise sub-account may be 1234, 4324, 6547, and the like; if the type of the signing party is personal, the account of the signing party signed by the sub-account can be a personal account, for example, the enterprise organization code of the personal account can be 0000; the account real address may be the address that characterizes the signer by a string of characters carried in base 36.

In addition, the detecting whether the signature content corresponding to the sub-account signature contains the request content includes: and performing hash calculation on the signature content, comparing the obtained hash result with the sub-account signature, and if the hash result is consistent with the sub-account signature, judging that the signature content corresponding to the detected sub-account signature contains the request content. Based on this, if the hash result is detected to be inconsistent with the sub-account signature, it is determined that the signature content corresponding to the detected sub-account signature does not include the request content, so that the uplink request can be discarded.

Therefore, by implementing the optional embodiment, the legality of the signature of the main account can be detected on the premise that the signature of the sub-account is legal by detecting the legality of the signature of the sub-account, so that the utilization rate of computing resources is improved.

In step S530, if the sub-account signature has validity and the uplink request satisfies the double verification condition, the validity of the primary account signature in the uplink request is verified; and the signature party corresponding to the sub-account signature and the main account signature is different.

Specifically, the signature content of the sub-account signature comprises the request content of the uplink request, and the signature content of the main account signature comprises the request content and the sub-account signature; alternatively, the signature content signed by the sub-account and the signature content signed by the main account both comprise the request content. In addition, the double check condition is used to define the condition of the secondary signature verification, that is, the type of the signer of the sub-account signature is an organization.

As an alternative embodiment, the method further includes: determining the type of the signature party of the uplink request according to a type of codes in the uplink request; wherein one type of code is used as a unique representation of a signing party corresponding to the sub-account signature; if the signer type is organization, the uplink request is judged to meet the double check condition.

One type of code may be a corporate code in the structure of the account address. Specifically, determining the signer type of the uplink request according to a type of codes in the uplink request includes: acquiring an enterprise organization code (e.g. 0000) in the uplink request, and determining the type of a signer to which the enterprise organization code belongs according to a preset mapping relation.

Therefore, by implementing the optional embodiment, whether the uplink request meets the condition of the primary account signature verification can be determined before the primary account signature verification is carried out, so that the subsequent primary account signature verification is carried out on the premise of meeting the condition, and the utilization rate of computing resources is improved.

As an alternative embodiment, the method further includes: if the signer type is personal, the uplink request is stored in a transaction pool; responding to the request in the transaction pool according to a preset unit time length (such as 5 s); and performing consensus on the response results and packaging the response results into blocks to be written into a block chain account book.

In particular, the transaction pool is one or more requests in the blockchain network for storing the uplink to be packaged. The BlockChain (BlockChain) is a novel application model based on computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm and the like, and is essentially a decentralized database. As an underlying technology of bitcoin, a blockchain is a string of data blocks generated by using cryptography correlation, and each data block is linked by a random hash (i.e., a hash algorithm), and the next block contains a hash value of the previous block.

Therefore, the implementation of the alternative embodiment can directly perform the packed uplink on the uplink request under the condition that the uplink request does not meet the double verification condition, thereby improving the data uplink efficiency.

As an alternative embodiment, the determining that the uplink request satisfies the double check condition includes: and detecting whether the signature of the primary account is empty, and if not, judging that the uplink request meets double check conditions.

Specifically, detecting whether the primary account signature is null includes: it is detected whether the extra _ sign field contains signature information.

Therefore, the implementation of the optional embodiment can avoid the verification of the signature of the primary account under the condition that the signature of the primary account is empty, thereby avoiding the waste of computing resources.

As an optional embodiment, if it is detected that the primary account signature is null, the method further includes: and storing the uplink request to the pending signing pool, so that the signing party corresponding to the primary account signature signs the uplink request when monitoring the uplink request.

Specifically, the to-be-signed pool is used for storing the request to be signed, and the requests in the to-be-signed pools corresponding to different signing parties are different. Wherein, storing the uplink request to the pending pool comprises: determining another enterprise organization code corresponding to the enterprise organization code in the sub-account signature, namely the enterprise organization code which should appear in the main account signature; further, the uplink request can be stored in the pending pool corresponding to the other enterprise organization code; when the enterprise organization code in the sub-account signature is the enterprise organization code corresponding to the enterprise sub-account, the other enterprise organization code may be the enterprise organization code corresponding to the enterprise administrator account.

Optionally, the storing the uplink request to the pool to be signed so that the signer corresponding to the primary account signature signs the uplink request when monitoring the uplink request, includes: and determining another enterprise organization code corresponding to the enterprise organization code in the sub-account signature, and storing the uplink request into a to-be-signed pool, so that the signing party corresponding to the main account signature signs the uplink request containing the enterprise organization code when the enterprise organization code corresponding to the enterprise organization code in the uplink request is monitored.

Based on this, after storing the uplink request to the pending pool, the method may further include: sending a prompt message to the signer corresponding to the other enterprise organization code; the prompt message may include text, sound effect, and the like, and the embodiment of the present application is not limited.

In addition, the signing party corresponding to the primary account signature signs the uplink request when monitoring the uplink request, including: and the signature party corresponding to the primary account signature carries out signature on the uplink request according to unit time length (such as 1 min).

Therefore, by implementing the optional embodiment, the request lacking the primary account signature can be stored in the to-be-signed pool, so that the related signing party can sign the request in time, and the data chaining efficiency is improved.

As an optional embodiment, the signing party corresponding to the primary account signature signs the uplink request when the uplink request is monitored, including: when a signature party corresponding to the primary account signature monitors a chain loading request, performing compliance detection on request content in the chain loading request; if the request content is detected to be in compliance, the signature party corresponding to the primary account signature carries out signature on the uplink request, so that the primary account signature is not null.

Specifically, the compliance detection of the request content in the uplink request includes: and graphing and outputting the transaction data in the request content, receiving user operation for representing a compliance judgment result, and judging whether the request content is compliant or not according to the user operation.

Therefore, the optional embodiment can be implemented to sign the request content on the premise that the request content meets the specification, so that the security of property data of a signing party is guaranteed.

As an alternative embodiment, the checking the validity of the primary account signature of the uplink request includes: detecting whether signature content corresponding to the primary account signature contains a sub-account signature and request content of a cochain request; if so, determining a second type of code corresponding to the first type of code and acquiring a public key corresponding to the second type of code; wherein the class two codes are for a unique representation as a signer corresponding to the primary account signature; verifying whether a public key corresponding to the second-class code is consistent with a public key in the main account signature; and if the signatures are consistent, judging that the signature of the main account is legal.

Specifically, detecting whether the signature content corresponding to the primary account signature includes the sub-account signature and the request content of the uplink request includes: performing hash calculation on the subaccount signature and the uplink request; and comparing the calculation result with the signature content corresponding to the signature of the main account, and if the calculation result is consistent with the signature content of the signature of the main account, executing the above-mentioned two types of codes corresponding to the first type of codes and acquiring the public key corresponding to the second type of codes.

Therefore, the optional embodiment can be implemented to verify the validity of the signature of the primary account, so that double signature verification is realized to ensure the validity of the uplink data.

As an alternative embodiment, if it is detected that there is no second-type code corresponding to the first-type code, the method further includes: the signer type is changed from organization to individual and the uplink request is stored in the transaction pool.

If the fact that the second type of codes corresponding to the first type of codes do not exist is detected, it can be judged that the signing party signed by the sub-account does not have the corresponding management party account.

It can be seen that implementing this alternative embodiment can improve the efficiency for data uplink by making changes to the signer type.

As an optional embodiment, if the public key corresponding to the second type of code is not consistent with the public key in the primary account signature, the method further includes: it is determined that the primary account signature is not legitimate and the uplink request is discarded.

Referring to fig. 8, fig. 8 schematically illustrates a flow chart of signature validity checking according to an embodiment of the present application. As shown in fig. 8, the signature validity checking process may include: step 810 to step 880.

Step S810: an uplink request is received. Specifically, the uplink request may be sent by a signer signed by a sub-account or a signer signed by a main account.

Step S820: and detecting whether the signature content corresponding to the sub-account signature contains the request content of the uplink request, and if so, judging that the sub-account signature is legal.

Step S830: and reading the enterprise organization code corresponding to the signer signed by the sub-account in the uplink request so as to determine the type of the signer of the uplink request according to the enterprise organization code. If the signer type is organization, step S840 is performed. If the signer type is personal, step S880 is performed.

Step S840: and detecting whether the signature content corresponding to the primary account signature comprises the sub-account signature and the request content of the uplink request. If so, step S850 is performed. If not, step S870 is performed.

Step S850: and determining the enterprise agency code corresponding to the signing party signed by the main account and acquiring the public key corresponding to the enterprise agency code.

Step S860: and comparing whether the public key in the signature of the main account is consistent with the public key corresponding to the signature party of the signature of the main account. If so, step S880 is performed. If not, step S870 is performed.

Step S870: and judging that the signature of the main account has no validity.

Step S880: and storing the uplink request in a transaction pool, responding the request in the transaction pool according to the preset unit time length, performing consensus on the response result, packaging the response result into a block, and writing the block into a block chain account book.

Therefore, by implementing the optional embodiment, the uplink request can be discarded under the condition that the signature of the primary account is illegal, so that the data security can be guaranteed, and property data loss caused by the stolen use of the private key can be avoided.

In step S540, if the primary account signature is valid, it is determined that the uplink request is valid.

Referring to fig. 9, fig. 9 schematically shows a sequence diagram of a block chain based key management method according to an embodiment of the present application. As shown in fig. 9, the sequence diagram of the block chain-based key management method may include: step S900 to step S980.

Step S900: the terminal device logging in the enterprise administrator account can be used as a signature party of the main account signature to upload information such as enterprise organization codes and administrator public keys to the block chain.

Step S910: the terminal device logging in the enterprise sub-account can be used as a signature party of the sub-account signature to send the sub-account signature and the request content to the terminal device logging in the enterprise administrator account.

Step S920: the terminal device logging in the enterprise administrator account can sign the sub-account signature and the request content, so that a main account signature is obtained, and the uplink request generated according to the main account signature is broadcasted to the block chain.

Step S930: the node in the block chain can verify the legality of the sub-account signature and the main account signature for the uplink request, and if the signature content corresponding to the sub-account signature is detected to comprise the request content and the signature content corresponding to the main account signature comprises the sub-account signature and the request content, the uplink request is stored in the transaction pool. If the primary account signature is detected to be absent, the uplink request is stored in the pending pool.

Step S940: the terminal device logging in the enterprise administrator account may monitor the request in the to-be-signed pool, and if the enterprise organization code corresponding to the enterprise administrator account is monitored, execute step S950.

Step S950: and the terminal equipment logging in the enterprise administrator account acquires the uplink request from the blockchain.

Step S960: and the terminal equipment logging in the enterprise administrator account verifies whether the requested content in the uplink request is in compliance, and if so, the terminal equipment signs the uplink request, so that the uplink request comprises the requested content, the sub-account signature and the main account signature.

Step S970: the terminal equipment logging in the enterprise administrator account can broadcast the uplink request comprising the request content, the sub-account signature and the main account signature into the blockchain, and delete the uplink request in the pending pool.

Step S980: the blockchain stores the uplink request in a transaction pool.

Therefore, the scheme can realize enterprise asset protection based on the ICAP protocol, and particularly can ensure that each on-chain transaction of the employee can be validated only by the approval of an enterprise administrator. Meanwhile, the assets can be guaranteed not to be transferred even if the employee account is lost or misoperation occurs. In addition, can also solve the daily operation of the financial affairs on the chain, transfer on the chain among the prior art can only be that user oneself or platform give the audit, and in this application, financial affairs can only submit the cochain application, can pass through final cochain transaction after finally still needing the administrator to approve.

In step S550, the response result is identified in response to the uplink request, and the response result is packaged and written into the blockchain directory.

Specifically, in response to the uplink request, the method includes: an intelligent contract corresponding to the uplink request may be invoked to respond to the uplink request via the intelligent contract.

Referring to fig. 10, fig. 10 schematically shows a flowchart of a method for block chain based key management according to an embodiment of the present application. As shown in fig. 10, the method for block chain-based key management may include: step S1000 to step S1024.

Step S1000: and the signing party corresponding to the sub-account signature generates request content from the subordinate account, signs the request content to obtain the sub-account signature, and sends the sub-account signature to the signing party corresponding to the main account signature, so that the signing party corresponding to the main account signature signs the sub-account signature to obtain the main account signature.

Step S1002: and the signer corresponding to the primary account signature generates a uplink request according to the primary account signature and broadcasts the uplink request in the block chain network.

Step S1004: and detecting whether the signature content corresponding to the sub-account signature contains the request content by the node in the block chain network, and if so, judging that the sub-account signature is legal.

Step S1006: the node determines the signature party type of the uplink request according to a type of codes in the uplink request; wherein a class of codes is used to act as a unique characterization of the signing party corresponding to the sub-account signature. If the signer type is organization, step S1010 is performed. If the signer type is personal, step S1008 is performed.

Step S1008: and the node stores the uplink request in the transaction pool, responds to the request in the transaction pool according to the preset unit time length, performs consensus on the response result and packs the response result into a block to be written in a block chain account book.

Step S1010: the node detects whether the primary account signature is empty. If so, step S1012 is performed. If not, step S1014 is performed.

Step S1012: the node stores the uplink request into the pending signing pool, so that the signing party corresponding to the primary account signature signs the uplink request when monitoring the uplink request. Then, step S1012 is executed.

Step S1014: the node determines that the uplink request satisfies the double check condition. When the sub-account signature is valid and the uplink request satisfies the double check condition, step S1016 is executed.

Step S1016: the node detects whether the signature content corresponding to the primary account signature contains the sub-account signature and the request content of the uplink request. If so, step S1018 is performed. If not, step S1022 is performed.

Step S1018: the node determines a second type of code corresponding to the first type of code and acquires a public key corresponding to the second type of code; wherein the class two codes are used as a unique representation of the signing party corresponding to the primary account signature.

Step S1020: and the node checks whether the public key corresponding to the second class of codes is consistent with the public key in the signature of the main account. If so, step S1024 is performed. If not, step S1022 is performed.

Step S1022: the node determines that the primary account signature is not valid and discards the uplink request.

Step S1024: the node judges that the signature of the main account has validity, and further judges that the uplink request has validity.

It should be noted that steps S1000 to S1024 correspond to the steps and embodiments shown in fig. 5, and for the specific implementation of steps S1000 to S1024, please refer to the steps and embodiments shown in fig. 5, which are not described herein again.

It can be seen that, by implementing the method shown in fig. 10, the data in the request can be doubly encrypted in a multi-party encryption manner, so that the block chain node needs to be doubly decrypted when decrypting, thereby ensuring data security. In addition, a mode of encrypting by using one private key for a plurality of accounts can be continued, and on the basis of secondary encryption, the number of the private keys is not increased on the premise of ensuring data security, so that the utilization rate of a storage space is improved.

Further, in the present exemplary embodiment, a key management apparatus based on a block chain is also provided. Referring to fig. 11, the block chain-based key management apparatus 1100 may include:

a request receiving unit 1101, configured to receive at least one signed ul request;

a signature verification unit 1102 for verifying the validity of the sub-account signature in the uplink request;

the signature verification unit 1102 is further configured to verify the validity of the primary account signature in the uplink request when the secondary account signature is valid and the uplink request meets the double verification conditions; the signature parties corresponding to the sub-account signature and the main account signature are different;

a result determining unit 1103, configured to determine that the uplink request is valid when the primary account signature is valid;

a request response unit 1104, configured to respond to the uplink request and identify the response result, and package and write the response result into the blockchain ledger.

The signature content of the signature of the sub-account comprises request content of an uplink request, and the signature content of the signature of the main account comprises the request content and the signature of the sub-account; alternatively, the signature content signed by the sub-account and the signature content signed by the main account both comprise the request content.

It can be seen that, with the implementation of the apparatus shown in fig. 11, the data in the request can be doubly encrypted in a multi-party encryption manner, so that the block chain node needs to be doubly decrypted when decrypting, thereby ensuring data security. In addition, a mode of encrypting by using one private key for a plurality of accounts can be continued, and on the basis of secondary encryption, the number of the private keys is not increased on the premise of ensuring data security, so that the utilization rate of a storage space is improved.

a signer type determining unit (not shown) for determining the signer type of the uplink request according to a type of codes in the uplink request; wherein one type of code is used as a unique representation of a signing party corresponding to the sub-account signature; if the signer type is organization, the uplink request is judged to meet the double check condition.

the request uplink unit (not shown) is used for storing the uplink request in the transaction pool when the type of the signer is personal, responding to the request in the transaction pool according to the preset unit duration, performing consensus on the response result and packaging the response result into a block to be written in the block chain account book.

a storage unit (not shown in the figure) is configured to store the uplink request to the pending pool when the signer type determination unit detects that the primary account signature is empty, so that the signer corresponding to the primary account signature signs the uplink request when monitoring the uplink request.

In an exemplary embodiment of the present disclosure, the signature verification unit 1102 checks the validity of the primary account signature of the uplink request, including:

a type changing unit (not shown) is used for changing the type of the signer from an organization to an individual and storing the uplink request in the transaction pool when the signature verification unit 1102 detects that the second type code corresponding to the first type code does not exist.

a request discarding unit (not shown) configured to determine that the primary account signature is not valid and discard the uplink request when the signature verification unit 1102 detects that the public key corresponding to the class two code does not match the public key in the primary account signature.

before the request receiving unit 1101 receives the uplink request signed by at least one signer, the signer corresponding to the sub-account signature generates request content through the subordinate account, and signs the request content to obtain the sub-account signature;

In an exemplary embodiment of the present disclosure, the signature verification unit 1102 checks the validity of the sub-account signature of the uplink request, including:

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

For details that are not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the key management method based on a block chain described above for the details that are not disclosed in the embodiments of the apparatus of the present application.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method described in the above embodiments.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

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

The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for managing a key based on a block chain is characterized by comprising the following steps:

receiving a cochain request signed by at least one signer;

verifying the legality of the sub-account signature in the uplink request;

if the sub-account signature is legal and the uplink request meets double checking conditions, checking the validity of a main account signature in the uplink request; the signature party corresponding to the sub-account signature and the main account signature is different;

responding to the uplink request and identifying the response result, and packaging and writing the response result into a block chain account book.

2. The method of claim 1 wherein the sub-account signed signature content comprises requested content of the uplink request and the primary-account signed signature content comprises the requested content and the sub-account signature; or, the signature content signed by the sub-account and the signature content signed by the main account both comprise the request content.

3. The method of claim 1, further comprising:

determining the signer type of the uplink request according to a type of codes in the uplink request; wherein the class of codes is for being a unique representation of a signing party corresponding to the sub-account signature;

if the signer type is organization, determining that the uplink request meets the double check condition.

4. The method of claim 3, further comprising:

if the signer type is personal, storing the uplink request in a transaction pool;

responding the request in the transaction pool according to a preset unit time length;

and performing consensus on response results and packaging the response results into blocks to be written into the block chain account book.

5. The method of claim 3 wherein determining that the uplink request satisfies a double check condition comprises:

and detecting whether the signature of the primary account is empty, and if not, judging that the uplink request meets the double check condition.

6. The method of claim 5, wherein if the primary account signature is detected to be null, the method further comprises:

and storing the uplink request to a pending signing pool, so that a signing party corresponding to the primary account signature signs the uplink request when monitoring the uplink request.

7. The method of claim 6, wherein the signing party to which the primary account signature corresponds signs the uplink request while monitoring the uplink request, comprising:

when the signature party corresponding to the primary account signature monitors the uplink request, performing compliance detection on the request content in the uplink request;

and if the request content is detected to be in compliance, the signature party corresponding to the primary account signature carries out signature on the uplink request, so that the primary account signature is not null.

8. The method of claim 4 wherein verifying the validity of the primary account signature of the uplink request comprises:

detecting whether signature content corresponding to the primary account signature comprises the sub-account signature and request content of the uplink request;

if so, determining a second type of code corresponding to the first type of code and acquiring a public key corresponding to the second type of code; wherein the class two code is for a unique representation as a signer corresponding to the primary account signature;

verifying whether a public key corresponding to the second class of codes is consistent with a public key in the primary account signature;

and if so, judging that the signature of the main account is legal.

9. The method of claim 8, wherein if it is detected that there is no second type of code corresponding to the first type of code, the method further comprises:

changing the signer type from the organization to the individual and storing the uplink request in the transaction pool.

10. The method of claim 8, wherein if the public key corresponding to the second type of code is inconsistent with the public key in the primary account signature, the method further comprises:

and judging that the primary account signature has no validity and discarding the uplink request.

11. The method of claim 1, wherein prior to receiving at least one signer-signed uplink request, the method further comprises:

a signer corresponding to the sub-account signature generates request content from a subordinate account and signs the request content to obtain the sub-account signature;

the signing party corresponding to the sub-account signature sends the sub-account signature to the signing party corresponding to the main account signature, so that the signing party corresponding to the main account signature signs the sub-account signature to obtain the main account signature;

and the signer corresponding to the primary account signature generates a uplink request according to the primary account signature and broadcasts the uplink request in the block chain network, so that a node in the block chain network verifies the validity of the sub-account signature of the uplink request.

12. The method of claim 1 wherein verifying the validity of the sub-account signature of the uplink request comprises:

13. A blockchain-based key management apparatus, comprising:

the signature verification unit is further configured to verify the validity of a primary account signature in the uplink request when the sub-account signature is valid and the uplink request meets a double verification condition; the signature party corresponding to the sub-account signature and the main account signature is different;

the result judging unit is used for judging that the uplink request is legal when the signature of the main account is legal;

and the request response unit is used for responding to the uplink request, identifying the response result and packaging and writing the response result into a block chain account book.

14. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the method of any one of claims 1-12.

15. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the method of any of claims 1-12 via execution of the executable instructions.