Disclosure of Invention
The application provides a private key management method, a private key management device and a private key management system, which can be particularly applied to application scenarios related to a block chain and used for improving the security of a private key, so that the security of information stored in the block chain is improved.
Several aspects of the present application are described below, and it is to be understood that the same or similar elements may be referred to one another in the following implementations of the several aspects.
In a first aspect, the present application provides a computer system having a rich execution environment REE and a trusted execution environment TEE deployed thereon, and further having a blockchain functional unit based on blockchain technology, such as digital wallet software, deployed thereon. The TEE is provided with a private key management module and a transaction data processing module in the block chain functional unit. The private key management module is used for creating a private key and storing the private key in the TEE. The transaction data processing module is used for encrypting the summary data related to the block chain functional unit by using the private key.
In some implementations, the generation of the summary data is in the TEE; in other implementations, the generation of the summary data is in the REE, and the REE then sends the summary data to the TEE.
In some implementations, the private key management module is specifically configured to encrypt 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 encrypt the private key using a password, where the password is updated or periodically updated when a condition is met, re-encrypt the private key using a new password after the update, and store the private key encrypted with the new password.
In some implementations, the password update condition includes performing encryption of the digest data once.
In some implementations, the cryptogram is a random number generated by a hardware random number generator. In other implementations, the random number may 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 in 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 comprises the following steps: creating a private key related to the block chain functional unit at the TEE, and storing the private key at the TEE side; and encrypting the summary data involved in the block chain functional unit by using the private key at the TEE side.
In some implementations, the summary data is generated on the TEE side; in other implementations, the digest data is generated at the REE side and sent to the TEE to perform encryption of the digest data at the TEE side.
In some implementations, prior to storing the private key, the method further includes: performing encryption on the private key. It will be readily appreciated that after encryption, the original private key is not stored, but rather the encrypted private key, and decryption is required before the next use of the private key.
In some implementations, encrypting the private key and storing the encrypted private key includes: and encrypting the private key by using a password, updating or periodically updating the password when the condition is met, re-encrypting the private key by using a new password after updating, and storing the private key encrypted by using the new password.
In some implementations, the password being updated when the condition is satisfied includes: updating the password after performing encryption of the digest data once with the private key.
In some implementations, the periodically updating the password includes: the password is updated at regular intervals and the private key is re-encrypted and stored.
In some implementations, the cryptogram is a random number generated by a hardware random number generator. In other implementations, the random number may also be generated by a software random number generator.
In a third aspect, the present application provides a computer system, which includes a memory for storing a computer program and a processor for reading and executing the computer program to implement the method provided in any of the foregoing implementation manners.
In a fourth aspect, the present application provides a blockchain system, wherein the computer system provided in any aspect of the present application is included in the blockchain system. The computer system may be a terminal device or other type of computer system.
Therefore, the private key management method, device and system provided by the application can be used for creating, storing and using the private key related in the blockchain scene by placing the private key on the TEE side, and the private key management method, device and system are assisted by
The trusted execution environment of the architecture provides the security of the private key, so that the problem of security risk brought by the private key in an untrusted environment is solved to a certain extent, and the security of the block chain system is improved. Furthermore, the private key is encrypted during storage and execution, and the safety is further ensured. Moreover, the password for encrypting the private key is changed periodically or under condition triggering, so that the security of the password is higher, and the security of the private key is higher.
Detailed Description
There is an increasing demand for terminal devices to handle important services. These trends have made terminal devices a key target for attacks by viruses such as malware, trojans and rootkits, from being able to pay, download and view the latest hollywood docks for a certain period of time, to being able to remotely pay bills and manage bank accounts via cell phones. In order to guarantee the security of the terminal equipment, the method is presented
Is a representative terminal device security framework. In the prior art

Under the framework, system-level security is obtained by dividing software and hardware resources of a system on chip (SoC) into two worlds, namely a normal world and a secure world (also called a secure domain and a non-secure domain), which respectively correspond to a Rich Execution Environment (REE) and a Trusted Execution Environment (TEE). The TEE and the REE run on the same device, and the TEE can ensure storage, processing and protection of sensitive data in a trusted environment and provide 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 are based on the REE, and the security is not high because the REE has a problem of multiple attack surfaces, and after the private key management and use is moved to the TEE, the problems of creation and use of the private key in the TEE and how the digital signature flow interacts between the REE and the TEE need to be solved.
Fig. 1a is a schematic diagram of a network architecture of a block chain scenario in which the key management method provided in this embodiment is applied. The block chain system is composed of a plurality of terminal devices to form a point-to-point (peer-to-peer) decentralized network structure. A terminal device may be considered a node of a blockchain. The automobile 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. 1 a. The terminal equipment comprises REE and TEE, wherein REE and TEE are respectively operated with
An operating system and a TEE-side operating system (e.g., an open-source OP-TEE operating system).
The operating system and the TEE OS are divided into two states, a user state and a kernel state. CA (client application) in REE and TA in TEE form a framework similar to client/server, TA is used as a server, CA is used as a client, CA initiates access operation, the CA and the TA exchange data through a message channel of a hardware layer, and the CA suspends the system after initiating a request and waits for the TA to return a result. The development of the CA needs to call a TEE client (client) API (application program interface) to realize communication with a corresponding TA; the TA needs to call the TEE internal (internal) API to implement the relevant functionality using the programming resources provided by the TEE.
A typical CA and TA interaction flow is shown in fig. 2:
s201: the CA first makes the necessary context initialization. The specific command implemented is TEEC _ InitializeContext.
S202: specifying the specific path (TA _ path) where the TA file is located, and opening the session. The specific command implemented is TEEC _ OpenSession (ta _ path).
S203: after session establishment is successful, a session handle (Return sessionhandle) is returned, at which time the TA has run in the TEE, waiting to receive commands from the CA.
S204: the CA sends a command, and the underlying interface calls an 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 (by way of shared memory). The specific command implemented is TEEC _ InvokeCommand (cmd).
S205: after the TA has processed the command, it returns a result (Return result) to the CA and the processor switches back to the non-secure mode.
It should be noted that, the processor also has a monitoring mode between the secure mode and the non-secure mode, and during the switching process, the processor switches from the secure mode to the monitoring mode first, then switches to the non-secure mode, and vice versa. For a more detailed handover process, reference may be made to the prior art, which is not described herein again.
In the prior art, a block chain-based application is implemented on a mobile device, and a private key management module and a data processing module in the application are implemented in an REE. The data processing module is used for performing hash operation, digital signature, abstract comparison and other processing on the data so as to identify whether the data is tampered and verify identity information of a sender.
Taking digital wallet software as an example, referring to fig. 3, it mainly includes five modules: a user management module 301, an asset management module 302, a 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 correctness of a user name and a 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 used for connecting to a network and transmitting/receiving network data packets. The key management module is used for creating and storing a private key and a public key. The transaction data processing module 304 is configured to perform hash operation and digital signature processing on outgoing transaction data, perform transaction summary data comparison on incoming transaction data, identify whether the transaction data is tampered with, and verify identity information of a sender. As shown in fig. 3, the present embodiment places the function of digital signature in the transaction data processing module (equivalent to the transaction data processing module 304_ B) and the key management module 305 on the TEE side for implementation, and still places the other functions (equivalent to the transaction data processing module 304_ a) and the other modules on the REE side for implementation.
The embodiment changes the digital wallet software from being implemented only on the REE side to being implemented on the REE and TEE sides together. The digital wallet software implements the functions of the aforementioned key management module and transaction data processing module through one or more TAs on the TEE side, and the functions of the other modules may be implemented through one or more CAs on the REE side.
It should be noted that, in this embodiment, 4 modules on the REE side are implemented by one CA, and 2 modules on the TEE side are implemented by one TA, while in other embodiments, different functional modules may also be implemented by multiple CAs or TAs. In addition, the division of the modules is also only an example, and the present application is not limited thereto.
Fig. 4 illustrates the processing flow of transaction data by taking wallet a paying 100 digital coins to wallet B as an example. In the embodiment, the procedure for calling the TEE side module by the REE side module is referred to the procedure for calling the TA by the CA described above, and the specific calling procedure is not described in detail.
S401: wallet a (also understood as terminal device a) hashes the transaction data using SHA256 algorithm on the REE side, generating a 256-bit transaction digest. The transaction data includes address information of wallet a, address information of wallet B, and payment amount information. The transaction data may be embodied as a string of characters.
S402: wallet a then sends the transaction digest to the TA on the TEE side over a data channel between the CA and TA. The concrete implementation is as follows: the CA on the REE side calls a TEEC _ InvokeCommand (cmd) function to send transaction summary data, wherein cmd is as follows: SEND _ DIGEST command.
If fig. 3 is taken as an example, steps S401 and S402 may be performed by the transaction data processing module 304_ a.
S403: the TA on the TEE side encrypts the transaction digest by using a private key of the wallet a and an Elliptic Curve Digital Signature Algorithm (ECDSA), and generates a Digital Signature (or called Signature data) smaller than 320 bit.
S404: the TA on the TEE side returns the signature data and the public key of wallet a to the re side CA. The wallet a public key and private key are created by TA on the TEE side, and they are created before use, but the specific time is not limited in this embodiment, for example, the public key may be created after the private key is created, or may be created before returning to the REE side. The public key of wallet a may be specifically obtained from the private key of wallet a and the ECDSA algorithm.
If fig. 3 is taken as an example, steps S403 and S404 may be performed by the transaction data processing module 304_ B.
S405: after the CA on the REE side obtains the public key and the signature data, the transaction data, the public key and the signature data are packaged into a network data packet together and sent to the network management module. The network management module broadcasts the network data packet to other blockchain nodes of the whole network.
If fig. 3 is taken as an example, step S405 may be executed by the transaction data processing module 304_ a.
Fig. 5, which is continued from fig. 4, is a processing procedure after wallet B (also understood as terminal device B) receives the network data packet. The processing procedure after the other nodes receive the network data packet is similar to that described below and will not be described in detail.
S501: CA analyzes three parts of data: transaction data, public key, and signature data.
S502: and the CA calls an SHA256 algorithm to carry out hash operation on the transaction data to obtain 256-bit abstract data.
S503: and the CA calls an ECDSA signature verification algorithm to decrypt the signature data to obtain the original transaction summary data.
S504: comparing whether the summary data generated in S502 and S503 are equal, if so, indicating that the transaction data is not tampered, and receiving 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 critical link, and if the private key is leaked, the security of the transaction data cannot be guaranteed. Fig. 6 is a schematic flowchart of a process for creating a private key by a TA provided in the present application, which can also be understood as a schematic flowchart of a process for creating a private key by a private key management module.
S601: TA invokes a random number generator to generate a256 bit random number R1. Specifically, the random number generator is a hardware random number generator or a software random number generator, and generally, the hardware random number generator has better randomness and higher safety. The implementation of the software random number generator and the hardware random number generator is prior art in the field, where 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, and this embodiment only needs to be called, which is not described herein.
S602: the random number R1 is hashed to obtain a 256-bit private key using a Hash algorithm, which may be sha (secure Hash algorithm) 256.
S603: the private key obtained in S602 is encrypted by using another random number R2 (which may also be understood as a random password, a cipher, or a key), and the specific Encryption algorithm may be an aes (advanced Encryption standard)256 algorithm or other Encryption algorithms, which is not limited in this embodiment. The other random number may be generated by invoking the random number generator described above or another random number generator.
S603: the value of R2 and the encrypted key are stored.
To improve further security, the value of R2 in this embodiment may be updated. R2 is updated by performing the corresponding decryption algorithm on the encrypted key and then re-encrypting the private key with the new value.
Please refer to fig. 7, which is a flowchart illustrating a process of updating the random number R2.
S701: as shown in connection with fig. 4, the TA, after receiving the transaction digest, decrypts the currently stored key using the currently stored value of R2.
S702: the TA encrypts the transaction digest using the decrypted key to obtain signature data.
S703: the random number generator is triggered to generate a new random number as the value of R2.
S704: the private key is re-encrypted using the updated R2.
S705: the re-encrypted private key and the new R2 are stored.
While the update of R2 in the implementation shown in fig. 7 is performed after the digital signature (S702) is executed, in other embodiments, the update of R2 may be performed periodically, for example, every 3 seconds, or periodically in combination with the manner shown in fig. 7, or other update methods determined by the need.
The method provided by the embodiment uses the trusted execution environment of the TrustZone architecture to provide the security of the private key, can solve the problem of security risk brought by the creation, storage and use of the private key in the untrusted environment to a certain extent, and improves the security of transaction data or other types of data in a block chain application scene.
Fig. 8 is a schematic structural diagram of a computer system according to this embodiment. The computer system may 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-visual input module 560, a memory 570, and a power supply 580.
The communication module 510 may 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 may 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 position) information module, etc. The various modules are implemented in various ways in the prior art, and are not described in the application.
The sensor 520 may sense a current state of the system, such as an open/close state, a position, whether there is contact with a user, a direction, and acceleration/deceleration, and the sensor 520 may generate a sensing signal for controlling the operation of the system.
A user input module 530 for receiving input digital information, character information, or contact touch operation/non-contact gesture, and receiving signal input related to user setting and function control of the system, etc. The user input module 530 includes a touch panel and/or other input devices.
The output module 540 includes a display panel for displaying information input by a user, information provided to the user or various menu interfaces of the system, and the like. Alternatively, the display panel may be configured in the form of a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), or the like. In other embodiments, the touch panel can be overlaid on the display panel to form a touch display screen. In addition, the output module 540 may further include an audio output module, an alarm, a haptic module, and the like.
And an audio/video input module 560 for inputting an audio signal or a video signal. The audio/video input module 560 may include a camera and a microphone.
The power supply 580 may receive external power and internal power under the control of the processor 550 and provide power required for the operation of the various components of the system.
Processor 550 may include one or more processors, for example, processor 150 may include one or more central processors, or one central processor and one graphics processor. When the processor 150 includes multiple processors, the multiple processors may be integrated on the same chip or may be separate chips. A processor may include one or more physical cores, where a physical core is the smallest processing module.
The
memory 570 stores computer programs including an
operating system program 572,
application programs 571, and the like. Typical operating systems are those for desktop or notebook computers such as Windows from Microsoft corporation, MacOS from apple Inc., and others such as those developed by Google Inc
Android of
System, etc. for a mobile terminal. The method provided by the foregoing embodiments can be implemented by software, and can be considered as a specific implementation of the
application 571.
The memory 570 may be one or more of the following types: flash (flash) memory, hard disk type memory, micro multimedia card type memory, card type memory (e.g., SD or XD 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 may be a network storage device on the internet, and the system may perform an update or read operation on the memory 570 on the internet.
The processor 550 is used to read the computer program in the memory 570 and then execute a method defined by the computer program, such as the processor 550 reading the operating system program 572 to run the operating system on the system and implement various functions of the operating system, or reading the one or more application programs 571 to run an application on the system.
The memory 570 also stores other data 573 in addition to computer programs, such as blocks, private keys, transaction data, and random numbers, etc., referred to in this application.
The connection relationship of each module in fig. 8 is only an example, and the method provided in any embodiment of the present application may also be applied to terminal devices in other connection manners, 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 units in the foregoing embodiments is only provided as an exemplary illustration, the functions of the described modules are only exemplary, and the application is not limited thereto. Those skilled in the art may combine the functions of two or more modules, or split the functions of one module to obtain more modules with finer granularity, and other variations, as required.
The same or similar parts between the various embodiments described above may be referred to one another. In the present application, "a plurality" means two or more, or "at least two" unless otherwise specified.
The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. In addition, in the drawings of the embodiment of the apparatus provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, and may be specifically implemented as one or more communication buses or signal lines. One of ordinary skill in the art can understand and implement it without inventive effort.
The above description is only some specific embodiments of the present application, but the scope of the present application is not limited thereto.