WO2019218919A1

WO2019218919A1 - Private key management method and apparatus in blockchain scenario, and system

Info

Publication number: WO2019218919A1
Application number: PCT/CN2019/086111
Authority: WO
Inventors: 文白林
Original assignee: 华为技术有限公司
Priority date: 2018-05-15
Filing date: 2019-05-09
Publication date: 2019-11-21
Also published as: CN110492990B; CN110492990A

Abstract

The present application provides a computer system. A rich execution environment (REE) and a trusted execution environment (TEE) are deployed in the computer system; a blockchain technology-based blockchain functional unit is further deployed in the computer system, and a private key management module and a transaction data processing module in the blockchain functional unit are deployed in the TEE, wherein the private key management module is used for creating a private key and storing same in the TEE, and the transaction data processing module is used for encrypting digest data involved in the blockchain functional unit by using the private key. By placing the private key involved in the blockchain scenario at a TEE side for creating, storing, and using, the security of the private key is ensured by means of the TEE of a TrustZone architecture, and the security risk problem caused by the private key in an untrusted environment is solved to some extent, thereby improving the security of a blockchain system.

Description

Private key management method, device and system under blockchain scenario

Technical field

The present application relates to a blockchain technology, and in particular, to a method, device and system for managing a private key in a blockchain.

Background technique

Blockchain refers to data generated and stored in blocks, and connected into a chain data structure in chronological order. All nodes need to participate in the data verification, storage and maintenance of the blockchain system, and new blocks. The creation needs to be confirmed by consensus, and broadcast to each node to achieve network-wide synchronization, and then cannot be changed or deleted. The blockchain is a collection of innovations of various prior art, mainly solving the problem of multi-party trust and efficient coordination. The technologies that make up the blockchain mainly include hash operations (SHA256), digital signatures, P2P (peer-to-peer) networks, and consensus algorithms. Typical application scenarios for blockchain technology include cryptocurrency, finance, supply chain, and the Internet of Things.

Digital signature technology is used to ensure the security of data transmission to a certain extent. Taking the encrypted digital currency scenario as an example, the currency transaction information is stored in the block of each node, and the currency transaction information includes one or more transaction processes, and a transaction process, for example, the address of the A wallet transfers 100 digital coins to the B wallet address ( For example bitcoin). Before transmitting transaction information between different nodes, it is necessary to perform a hash operation on the transaction process to obtain a summary of the transaction process, and then encrypt the digest using the sender's private key, and encrypt the digest and transaction data (or encryption). After the transaction data) is sent to the recipient. The receiver decrypts the received ciphertext digest with the corresponding public key to obtain the digest a, performs a hash operation on the received transaction data to obtain the digest b, compares the digest a and the digest b, and when the digest a and the digest b are the same It is only safe to determine the currency trading information. It can be seen that the digital signature technology can ensure the integrity of the information transmission and at the same time verify the identity authentication of the sender, thereby preventing the occurrence of the repudiation in the transaction. However, how to ensure the security of the private key in the digital signature process and avoid the sender's private key from being obtained by a malicious third party is a problem that needs to be solved in the blockchain field.

Currently, the most common method of private key management is to host the private key on the server of the service provider. The user logs in to the server using the account login method before using the private key to perform related operations. However, there are some drawbacks in this way: if the server is hacked or other vulnerabilities are generated, it is easy to cause the private key to be leaked or lost; the user account may also be stolen; the browser vulnerability in the process of logging in to the server will also be safe for the account. Sexuality has an impact; man-in-the-middle attacks in the process of network transmission and HTTPS certificate hijacking are also a common security risk. Another way is to create and store the private key yourself at the blockchain node device. At present, the security design of most encrypted digital currency wallets is completely dependent on the security boundary of the operating system. The storage and processing of the private key is still stored by using a fixed key or even directly in plaintext, completely relying on the security boundary of the operating system to avoid Illegal access, but whether it is Android (Android), iOS, Windows or Linux, a large number of system security vulnerabilities are exposed and fixed every year, and there are many local rights vulnerabilities in these vulnerabilities. It is easy to break the security design boundary of the operating system and gain the ability to access the private key.

Summary of the invention

The present application provides a private key management method, apparatus, and system, which can be applied to improve the security of a private key in an application scenario involved in a blockchain, thereby improving the security of information stored in a blockchain.

Several aspects of the present application are described below, and it is easily understood that the same or similar parts of the implementations of the following aspects may be referred to each other.

In a first aspect, the present application provides a computer system on which a rich execution environment REE and a trusted execution environment TEE are deployed, the computer system also deploying a blockchain functional unit based on blockchain technology, such as a digital wallet software. The private key management module and the transaction data processing module in the blockchain functional unit are deployed in the TEE. The private key management module is configured to create a private key and store the private key in the TEE. The transaction data processing module is configured to perform encryption on the digest data related to the blockchain functional unit by using the private key.

In some implementations, the generating of the digest data is in the TEE; in other implementations, the generating of the digest data is in the REE, and then the REE sends the digest data to the TEE .

In some implementations, the private key management module is specifically configured to perform encryption on the private key before storing the private key, where the stored private key is an encrypted private key.

In some implementations, the private key management module is specifically configured to perform encryption on the private key by using a password, where the password is updated or periodically updated when the condition is met, and the new password is used to re-execute the private key. Encrypted and stores the private key encrypted with the new password.

In some implementations, the updating condition of the password includes performing encryption of the summary data once.

In some implementations, the password is a random number generated by a hardware random number generator. In other implementations, the random number can also be generated by a software random number generator.

In a second aspect, the present application provides a method for managing a private key, which is applied to a blockchain scenario. The method is applied to a computer system, such as a terminal device, deployed with a rich execution environment REE and a trusted execution environment TEE. A blockchain functional unit, such as digital wallet software, is also deployed on the computer system. The method includes: creating a private key involved in the blockchain functional unit at a TEE, and storing the private key on a TEE side; using the private key to perform a digest on the blockchain functional unit on the TEE side The data is encrypted.

In some implementations, the summary data is generated on the TEE side; in other implementations, the summary data is generated on the REE side, and the summary data is sent to the TEE for TEE The side performs encryption on the summary data.

In some implementations, prior to storing the private key, the method further comprises performing encryption on the private key. It is easy to understand that after encryption, the stored private key is not the original private key, and the encrypted private key needs to be decrypted before using the private key.

In some implementations, performing encryption on the private key and storing the encrypted private key includes performing encryption on the private key by using a password, and the password is updated or periodically updated when the condition is satisfied, and is used after being updated. The new password re-encrypts the private key and stores the private key encrypted by the new password.

In some implementations, updating the password when the condition is satisfied includes updating the password after performing encryption of the summary data once with the private key.

In some implementations, the periodically updating the password comprises: updating the password at regular intervals, and re-encrypting and storing the private key.

In a third aspect, the present application provides a computer system, characterized in that the computer system comprises a memory and a processor, the memory is for storing a computer program, the processor is for reading and executing the computer program to implement The method provided by any of the foregoing implementations.

In a fourth aspect, the present application provides a blockchain system, characterized in that the blockchain system comprises a computer system provided by any aspect of the present application. The computer system can be a terminal device or other type of computer system.

It can be seen that the private key management method, device and system provided by the present application create, store and use the private key involved in the blockchain scenario by using the private key involved in the blockchain scenario.

The trusted execution environment of the architecture provides the security of the private key, which solves the security risk of the private key in the untrusted environment to some extent, and improves the security of the blockchain system. Further, the private key is encrypted in the storage execution, further ensuring security. Moreover, the password of the encrypted private key is changed periodically or under the conditional trigger, so that the security of the password is higher, and the security of the private key is also higher.

DRAWINGS

In order to more clearly illustrate the technical solutions provided by the present application, the drawings will be briefly described below. Obviously, the drawings described below are only some embodiments of the present application.

FIG. 1a is a schematic diagram of a network architecture of a blockchain scenario;

FIG. 1b is a schematic diagram of a system architecture of a terminal device;

2 is a schematic diagram of an interaction process between CA and TA;

3 is a schematic diagram of functional deployment of digital wallet software;

4 is a schematic diagram of a processing flow of a transaction data sender in a digital wallet software;

5 is a schematic diagram of a processing flow of a transaction data receiver in a digital wallet software;

6 is a schematic flowchart of a method for creating a private key;

7 is a schematic flow chart of a private key encryption method;

8 is a schematic structural view of a computer system.

Detailed ways

There is an increasing demand for terminal devices to handle important services. From the ability to pay, download and watch the latest Hollywood blockbusters for a specific time period, to the ability to remotely pay bills and manage bank accounts via mobile phones, these trends have made end devices a key target for viruses such as malware, trojans and rootkits. In order to ensure the security of the terminal device,

The terminal device security framework represented. In existing

Under the framework, system-level security is obtained by dividing the software and hardware resources of system on chips (SoC) into two worlds, namely the normal world and the secure world (also called The security domain and the non-security domain) correspond to the rich execution environment (REE) and the trusted execution environment (TEE). TEE and REE run on the same device. TEE ensures the storage, processing and protection of sensitive data in a trusted environment and provides a secure execution environment for authorized trusted applications (TAs). However, the management and use of the private key by the mobile terminal in the blockchain scenario is based on REE. Since the REE has a large number of attacks, the security is not high, and after the private key management and use is moved to the TEE, it is required. Solve the problem of creating and using private keys in TEE and how the digital signature process interacts between REE and TEE.

FIG. 1 is a schematic diagram of a network architecture of a blockchain scenario applied by the secret key management method according to the embodiment. The blockchain system consists of a plurality of terminal devices forming a peer-to-peer, decentralized network structure. A terminal device can be seen as a node of a blockchain. The car in the figure represents an in-vehicle terminal device.

FIG. 1b is a schematic diagram of a system architecture of any one of the terminal devices in FIG. 1a. The terminal device includes REE and TEE, and REE and TEE respectively run

Operating system and a TEE side operating system (such as the open source OP-TEE operating system).

The operating system and TEE OS are further divided into user state and kernel state. The CA (Client Application) in the REE and the TA in the TEE form a client/server-like architecture. The TA acts as the server, the CA acts as the client, and the CA initiates the access operation. The two exchange data through the message channel of the hardware layer. After the CA sends the request, the system hangs and waits for the TA to return the result. The development of the CA needs to call the TEE client API to communicate with the corresponding TA; the TA needs to call the TEE internal API to implement the related functions using the programming resources provided by the TEE.

The typical CA and TA interaction process is shown in Figure 2:

S201: The CA first performs the necessary context initialization. The specific command implemented is TEEC_InitializeContext.

S202: Specify a specific path (ta_path) where the TA file is located, and open the session. The specific command implemented is TEEC_OpenSession(ta_path).

S203: Returning the session handle (Return SesstionHandle) after the session is successfully established, then the TA has already run in the TEE, waiting to receive the command from the CA.

S204: The CA sends a command, and the bottom interface invokes a SMC (secure monitor call) instruction to trigger the processor to switch to the secure mode, and passes the command to the TA in the TEE for processing (through shared memory mode). The specific command implemented is TEEC_InvokeCommand(cmd).

S205: The TA returns a result (Return result) to the CA after the command is processed, and the processor switches back to the non-secure mode.

It should be noted that the processor still has a monitoring mode between the safe mode and the non-secure mode, and switches from the safe mode to the monitoring mode and then to the non-secure mode during the switching process, and vice versa. For a more specific handover process, reference may be made to the prior art, and details are not described herein again.

In the prior art, a blockchain-based application is implemented on a mobile device, and the private key management module and the data processing module in the application are implemented in the REE. The private key management module is configured to create and store a private key/public key, and the data processing module is configured to perform hashing, digital signature, summary comparison, and the like on the data, thereby identifying whether the data is tampered with and verifying the sender identity information.

Taking the digital wallet software as an example, referring to FIG. 3, it mainly includes five major modules: a user management module 301, an asset management module 302, a secret key management module 305, a transaction data processing module 304, and a network management module 303. The user management module 301 is configured to authenticate the correctness of the user name and password when the user logs in. The asset management module 302 is used to view digital asset information, transfer funds to third parties, and the like. The network management module 303 is configured to connect to the network and send/receive network data packets. The key management module is used to create and store private and public keys. The transaction data processing module 304 is configured to perform hash operation and digital signature processing on the transferred transaction data, and further needs to compare the transaction summary data, identify whether the transaction data has been tampered with, and verify the identity information of the sender. As shown in FIG. 3, in this embodiment, the function of the digital signature in the transaction data processing module (equivalent to the transaction data processing module 304_B) and the key management module 305 are implemented on the TEE side, and other functions (equivalent to the transaction data processing module 304_A) ) and other modules are still placed on the REE side.

In this embodiment, the digital wallet software is completed by being implemented only on the REE side and on the REE and TEE side. The digital wallet software implements the functions of the foregoing key management module and transaction data processing module through one or more TAs on the TEE side, and the functions of other modules can be implemented on one or more CAs on the REE side.

It should be noted that, in this embodiment, four modules on the REE side are implemented by one CA, and two modules on the TEE side are implemented by one TA, and in other embodiments, different functional modules may also be configured by multiple CAs or TAs. achieve. In addition, the division of modules is only an example, and the application is not limited thereto.

FIG. 4 is an example of processing the transaction data by taking the wallet A to pay 100 digital coins to the wallet B as an example. In the embodiment, the process of calling the TEE side module by the REE side module may refer to the process of calling the TA by the CA described above, and the specific calling process is not detailed.

S401: Wallet A (also referred to as terminal device A) performs a hash operation on the REE side using the SHA256 algorithm to generate a 256-bit transaction digest. The transaction data includes the address information of the wallet A, the address information of the wallet B, and the payment amount information. Transaction data can be represented as a string.

S402: The wallet A then sends the transaction digest to the TA on the TEE side through the data channel between the CA and the TA. The specific implementation is as follows: The REE side CA calls the TEEC_InvokeCommand (cmd) function to send transaction summary data, where cmd is: SEND_DIGEST command.

If FIG. 3 is taken as an example, steps S401 and S402 can be performed by the transaction data processing module 304_A.

S403: The TA on the TEE side encrypts the transaction digest using the private key of the wallet A and the Elliptic Curve Digital Signature Algorithm (ECDSA) to generate a digital signature (or called signature data) of less than 320 bits.

S404: The TA on the TEE side returns the signature data and the public key of the wallet A to the REE side CA. The public key and private key of the wallet A are created by the TA on the TEE side. They are created before use, but the specific time is not limited in this embodiment. For example, the public key can be created after the private key is created. It can be created before returning to the REE side. The public key of the wallet A can be obtained according to the private key of the wallet A and the ECDSA algorithm.

If FIG. 3 is taken as an example, steps S403 and S404 can be performed by the transaction data processing module 304_B.

S405: After obtaining the public key and the signature data, the CA on the REE side packages the transaction data, the public key, and the signature data into a network data packet and sends the data packet to the network management module. The network management module broadcasts the network data packet to other blockchain nodes of the entire network.

If FIG. 3 is taken as an example, step S405 can be performed by the transaction data processing module 304_A.

FIG. 5 is a process subsequent to FIG. 4, after the wallet B (also referred to as the terminal device B) receives the network data packet. The processing after the other nodes receive the network data packet is similar to the following, and will not be described in detail.

S501: The CA parses out three pieces of data: transaction data, public key, and signature data.

S502: The CA invokes the SHA256 algorithm to hash the transaction data to obtain 256-bit summary data.

S503: The CA invokes the ECDSA verification signature algorithm to decrypt the signature data to obtain the original transaction summary data.

S504: Compare whether the summary data generated by S502 and S503 are equal. If they are equal, it indicates that the transaction data has not been tampered with, and accepts the transaction data; otherwise, the transaction data is discarded.

In the above transaction data processing flow, the creation and storage of the private key is a key link. If the private key is leaked, the security of the transaction data cannot be guaranteed. FIG. 6 is a schematic flowchart of a private key created by a TA provided by the present application, and can also be understood as a schematic flowchart of a private key management module for creating a private key.

S601: The TA calls a random number generator to generate a 256-bit random number R1. Specifically, the random number generator is a hardware random number generator or a software random number generator. Generally, the hardware random number generator has better randomness and higher security. The implementation of the software random number generator and the hardware random number generator are all prior art in the prior art, wherein the software random number generator is a software functional unit, and the hardware random number generator is a hardware, and the specific implementation is prior art. This embodiment only needs to be called, and will not be described here.

S602: Perform a hash operation on the random number R1 by using a hash algorithm to obtain a 256-bit private key, and the hash algorithm may be a SHA (Secure Hash Algorithm) 256 algorithm.

S603: Encrypt the private key obtained by S602 by using another random number R2 (which may also be understood as a random password, a password, or a key). The specific encryption algorithm may be an AES (Advanced Encryption Standard) 256 algorithm or other encryption algorithm. The embodiment is not limited. Another random number can be generated by calling the aforementioned random number generator or other random number generator.

S603: Store the value of R2 and the encrypted key.

In order to improve further security, the value of R2 in this embodiment can be updated. After R2 is updated, the corresponding decryption algorithm is executed on the encrypted key, and then the private key is re-encrypted with the new value.

Please refer to FIG. 7 , which is a schematic diagram of the process of updating the random number R2.

S701: As shown in FIG. 4, after receiving the transaction digest, the TA decrypts the currently stored secret key by using the currently stored value of R2.

S702: The TA encrypts the transaction digest using the decrypted secret key to obtain signature data.

S703: The trigger random number generator generates a new random number as the value of R2.

S704: Re-encrypt the private key by using the updated R2.

S705: Store the re-encrypted private key and the new R2.

The update of R2 in the implementation shown in Figure 7 is after performing a digital signature (S702). In other embodiments, the update of R2 may also be periodic, such as every 3 seconds, or periodically. Combined with the approach shown in Figure 7, or other update method determined as needed.

The method provided by the foregoing embodiment provides the security of the private key by using the trusted execution environment of the TrustZone architecture, and can solve the security risk problem caused by the creation, storage, and use of the private key in the untrusted environment to some extent, and improve the block. The security of transaction data or other types of data in a chain application scenario.

Please refer to FIG. 8 , which is a schematic structural diagram of a computer system according to an embodiment of the present disclosure. The computer system can be a terminal device. As shown, the computer system includes a communication module 510, a sensor 520, a user input module 530, an output module 540, a processor 550, an audio and video input module 560, a memory 570, and a power source 580.

Communication module 510 can include at least one module that enables communication between the computer system and a communication system or other computer system. For example, the communication module 510 can include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless internet module, a local area communication module, and a location (or positioning) information module. There are many implementations of these various modules in the prior art, and the present application does not describe them one by one.

Sensor 520 can sense the current state of the system, such as an open/closed state, position, contact with the user, direction, and acceleration/deceleration, and sensor 520 can generate a sensing signal for controlling the operation of the system.

The user input module 530 is configured to receive input digital information, character information or contact touch/contactless gestures, and receive signal input related to user settings and function control of the system. User input module 530 includes a touch panel and/or other input device.

The output module 540 includes a display panel for displaying information input by the user, information provided to the user, or various menu interfaces of the system, and the like. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED). In some other embodiments, the touch panel can cover the display panel to form a touch display. In addition, the output module 540 may further include an audio output module, an alarm, a haptic module, and the like.

The audio and video input module 560 is configured to input an audio signal or a video signal. The audio and video input module 560 can include a camera and a microphone.

The power supply 580 can receive external power and internal power under the control of the processor 550 and provide the power required for operation of the various components of the system.

Processor 550 can include one or more processors. For example, processor 150 can include one or more central processors, or can include a central processing unit and a graphics processor. When the processor 150 includes a plurality of processors, the plurality of processors may be integrated on the same chip, or may each be a separate chip. A processor can include one or more physical cores, with the physical core being the smallest processing module.

The memory 570 stores a computer program including an operating system program 572, an application 571, and the like. Typical operating systems such as Microsoft's Windows, Apple's MacOS, etc. for desktop or notebook systems, as developed by Google Inc.

Android

A system such as a system for a mobile terminal. The method provided by the foregoing embodiment may be implemented by means of software, and may be considered as a specific implementation of the application 571.

The memory 570 may be one or more of the following types: flash memory, hard disk type memory, micro multimedia card type memory, card memory (such as SD or XD memory), random access memory (random access memory) , RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable Read-only memory (PROM), magnetic memory, magnetic disk or optical disk. In other embodiments, the memory 570 can also be a network storage device on the Internet, and the system can perform operations such as updating or reading on the memory 570 on the Internet.

The processor 550 is configured to read a computer program in the memory 570 and then execute a computer program defined method, such as the processor 550 reading the operating system program 572 to run an operating system on the system and implementing various functions of the operating system, or reading One or more applications 571 are taken to run the application on the system.

The memory 570 also stores other data 573 than computer programs, such as blocks, private keys, transaction data, and random numbers, etc., as referred to in this application.

The connection relationship of each module in FIG. 8 is only an example, and the method provided by any embodiment of the present application may also be applied to other connection mode terminal devices, for example, all modules are connected through a bus.

It should be noted that the method provided in this embodiment may also be applied to a non-terminal computer device, such as a cloud server.

It should be noted that the division of the modules or the units in the foregoing embodiments is only shown as an example, and the functions of the various modules described are only examples, and the application is not limited thereto. One of ordinary skill in the art can combine the functions of two or more of the modules as needed, or split the functions of one module to obtain more finer-grained modules, as well as other variations.

The same or similar parts between the various embodiments described above may be referred to each other. "Multiple" in the present application means two or more, or "at least two" unless otherwise specified.

The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components displayed as modules may or may not be physical modules, ie may be located A place, or it can be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. In addition, in the drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, and specifically, one or more communication buses or signal lines can be realized. Those of ordinary skill in the art can understand and implement without any creative effort.

The foregoing is only some specific embodiments of the present application, but the scope of protection of the present application is not limited thereto.

Claims

A computer system, characterized in that a rich execution environment REE and a trusted execution environment TEE are deployed on the computer system, and the computer system is further configured with a blockchain functional unit based on blockchain technology, and deployed in the TEE There is a private key management module and a transaction data processing module in the blockchain functional unit, wherein

The private key management module is configured to: create a private key, and store the private key in a TEE;

The transaction data processing module is configured to perform encryption on the digest data related to the blockchain functional unit by using the private key.
The computer system according to claim 1, wherein the private key management module is configured to: perform encryption on the private key before storing the private key, wherein the stored private key is encrypted Private key.
The computer system according to claim 2, wherein the private key management module is configured to: perform encryption on the private key by using a password, and the password is updated or periodically updated when the condition is satisfied, and is used after being updated. The new password re-encrypts the private key and stores the private key encrypted by the new password.
The computer system according to claim 3, wherein the private key management module is specifically configured to: update the password after performing encryption of the summary data once by using the private key.
The computer system according to claim 3 or 4, wherein the password is a random number generated by a hardware random number generator.
A method for managing a private key in a blockchain technology, characterized in that the method is applied to a computer system in which a rich execution environment REE and a trusted execution environment TEE are deployed, and a blockchain function is also deployed on the computer system. a unit, the method comprising: creating a private key involved in the blockchain functional unit at a TEE, and storing the private key on a TEE side; using the private key to the blockchain functional unit on a TEE side The summary data involved performs encryption.
The method according to claim 6, wherein the method further comprises: performing encryption on the private key before storing the private key, and storing the private key as an encrypted private key.
The method according to claim 7, wherein performing encryption on the private key and storing the encrypted private key comprises:

Encryption is performed on the private key by using a password that is updated or periodically updated when the condition is satisfied, and the private key is re-encrypted with the new password after the update, and the private key encrypted by the new password is stored.
The method of claim 8, wherein the updating of the password when the condition is satisfied comprises updating the password after performing encryption of the summary data once with the private key.
A computer system, comprising: a memory for storing a computer program, the processor for reading and executing the computer program to implement any of claims 6-9 One of the methods described.
A blockchain system, characterized in that the blockchain system comprises the computer system of claim 10.