Research on Blockchain Anonymous Communication Based on Key Derivation

The hierarchical key system in the HD wallet provides a key derivation strategy to achieve one key at a time, however, it has some limitations in the communication scheme. This system is based on the key derivation algorithm of the HD wallet technology, and the key derivation algorithm that implements a one-at-a-time account, “use-it-or-lose-it”, private key opacity, and public key translucency is studied and applied to communication.

According to the key mapping principle in ECC finite cyclic group, it is easy to map from the private key to the public key, but it is impossible to push out the private key from the public key. On this basis, the existing public key K is used as the base point of the elliptic curve, and given a new random number x as the seed, a dot product operation on the elliptic curve is done to map to the new public key K'. By the same token, as long as the “new private key” x is large enough, it is impossible to push out x from K'. The specific design of the non-negotiable one-at-a-time key is as follows.

Firstly, given an elliptic curve Ep(A, b) and its upper base point G, the order is n, and provide the private key k ∈ [0, n − 1], the formula can be obtained as follows: (1) K=kG K = kG

Then do the product operation of integer x for the public key K in equation (1), and since the group is cyclic, the new public key K' is obtained, which can be transformed into equation (2). (2) K′=xK=xkG=(kx mod n)G K^\prime = xK = xkG = \left( {kx\;{\rm{mod}}\;n} \right)G

Finally, from Equation (2), the new public key K' can also be obtained by mapping the new private key k' = kx mod n, and k' is derived by multiplying x with the integer cyclic group of k in [0, n−1]. That is, the user can derive his own new legal key pair (k', K') by x for the old key pair (k, K). As shown in Fig. 4 under this rule, k → K, k → K', k' → K' are one-way mappings.

Figure 4.

In addition to keeping their private keys secret, the two communicating parties need to share and keep secret the “seed key” x in some way, so that they can each derive their own new key pair and can derive each other's new public key K', and then use the time stamp t as the variable parameter to let x change without After that, using the timestamp t as the variable parameter and letting x change without rules, we can derive a session public key that is transparent and irreversible to both parties, achieving a pseudo-random one-at-a-time effect, and not requiring a separate secure channel for key distribution negotiation, etc. The specific process is as follows.

The purpose of introducing the timestamp parameter t and doing the hash operation is twofold: one is to generate different x' for each communication to achieve one-at-a-time encryption; the other is to make use of the one-way nature of the hash operation, even if the attacker obtains the derived public key of the target in some way, it cannot reverse the resolution of the corresponding seed key x, which ensures the security of key derivation. This can further increase the discrete degree of communication address and avoid insecurity in communication to a greater extent on the basis of achieving one-at-a-time encryption to enhance message opacity. The specific generation and transparency characteristics of key and address derivation are shown in Table 1.

The encrypted communication logic based on the key derivation algorithm is the core of this secure communication system. To ensure the confidentiality of all kinds of messages and anonymity during transmission, the following design scheme is mainly followed.

The communication message transmission flow is designed as follows

Step 1: User A sends a message to friend B and sends the message to the server.

Select the message type, if it is text then edit the text message, if it is a file it will be encrypted and uploaded to the file system to get the link when sending, the link will be sent as a text message;

Generate the B-derived public key KBt and session key Kst at the current timestamp t by using the seed key shared with B. Encrypt the edited message (message type and message) with the session key to get the ciphertext m;

Package the ciphertext m, communication timestamp t, and derived public key KBt into a JSON file and send it to the chain server, and the sending message is finished.

Step 2: User B receives the message sent by A. The message is forwarded locally by the chain and then decrypted.

B gets the message JSON file and verifies that the message is sent by A. Extract the seed key x shared with A and generate the session key Kst under timestamp t to decrypt the message to get the plaintext M;

Get the message type of M, if it is a file type then extract the file from the file system to decrypt it, and then render the received content to the message page. Message reception is completed.

Step 3: The JSON message uploaded to the chain contains only ciphertext and derived information, so the third party cannot restore the plaintext and the initial public key information of both parties, thus achieving the effect of anonymity. The service of parsing session parameters deployed on the chain can parse the JSON messages to know the addresses of both parties and realize automatic forwarding.

Alliance chain communication guide nodes get the derived session parameter information under the corresponding timestamp through the heartbeat messages sent by all users, and store it to the cache map with the user key as the key; the messages are uploaded to the blockchain and completed consistency synchronization will be sent to the message queue for processing through asynchronous mode; the key derivation algorithm is used for efficient comparison and screening to determine the initial public key of the message recipient and map it to the specific IP address, and then forwarding can be done.

The communication function of the federated chain mainly includes establishing and maintaining connections for online users, receiving various types of messages and automatically parsing and forwarding messages, and other processing of messages.

The message types parsed by the application layer of the federation chain mainly include heartbeat messages, request connection messages, session messages, etc. Among them, heartbeat messages are mainly used for updating user session parameters, request connection messages are used for establishing long connections with the chain and releasing key and other information, and session messages are used for formal communication, which can be used to resolve the identity and automatically forward to the target user, and to synchronize the relevant data to generate blocks that can be verified by both sides of the communication, etc. The specific process is shown in Fig. 5.

Figure 5.

The initialization of the federation chain bootstrap node starts the Netty service, which is shown in Fig. 6. First, the WebSocket server is initialized, i.e., the server is started to create an instance of SeverBootstrap object, after which the bound Reactor thread pool is set, i.e., the main thread pool and the worker thread pool, next, the Channel of the bound bootstrap node server is set, the ChannelPipeline is initialized, and then the Channel initializer to specify the ChanelHandler and set the business processing logic for the messages received by the channel.

Figure 6.

In the channel initializer, the following ChannelHandler function options have been added:

Step 1: Added HTTP codecs to specify the routing format for incoming requests, allowing messages to be transmitted between users using the same protocol and format;

After the bootstrap node receives the message and determines it to be a session type, it calls the relevant function to process it. The main elements of the process are.

Step 1: Message data synchronization: message data will be synchronized by a consensus algorithm to achieve forwarding between nodes and generate a unique hash, together with a summary call to the relevant function for uplinking processing.