1 Introduction

1.1 Background and motivation

Blockchain is a shared distributed ledger that records transactions in a public or private peer-to-peer network. The ledger is distributed to all member nodes in the network, and the history of asset transactions occurring between peer nodes in the network is permanently recorded in the block. As the core technology of distributed ledger technology (DLT) system, blockchain is considered to have broad application prospects in many fields such as finance, Internet of Things, commercial trade, credit reporting, and asset management [1].

As a new generation of energy supply mode, distributed energy system is a powerful supplement to centralized energy supply system. A distributed trading system should be designed to adapt multiple energy suppliers and consumers. Blockchain technology can be applied to construct a distributed energy trading system. Actually, there are many researches on blockchain-based energy trading systems [210]. The literature [2] conducted a preliminary economic evaluation of the market mechanism of blockchain application in the local energy market. In [3], the author compares the business model and characteristics of P2P power transaction and emphasizes the sustainable development of P2P ICUE 2018 green energy. In [4], the author demonstrated a blockchain implementation that can be used for energy auctions in the campus environment. The authors discuss the components of the microgrid energy market related to the Brooklyn microgrid project in [5]. The authors discuss business models that ensure transparency for energy consumers in [6]. Blockchain technology has also realized several other energy-related applications, such as the use of blockchain in island microgrids to identify energy losses [7] and the application supporting emissions trading [8]. In [9], the authors review the way blockchain technology works in the context of the Internet of Things (IoT). A secure energy trading system was proposed in [10].

In addition, many enterprise projects are also focused on the application of blockchain technology in the field of energy [1120], such as the PowerLedger project which provides a peer-to-peer marketplace for renewable energy [11]. Its white paper [12] continues to discuss system architecture and ecosystems. The Brooklyn Microgrid Project developed by New York startup LO3 Energy [13] is dedicated to creating a blockchain-based P2P trading system that delivers electricity to hospitals, shelters, and community centers when needed. Dajie project in [14] provides a blockchain-based platform that allows P2P energy exchange, redeems carbon credits for consumers, and pays for energy companies’ energy and services. The Shared Charging Project [15] provides a solution for charging electric vehicles on an open network developed on the Ethereum blockchain [16], which provides seamless access to charging poles in different countries. NRGcoin project [17] provides incentives for the production of green energy. The concept is similar to the solar coin project [18], where one of the solar coins represents 1 MWh of solar power. The solar exchange program [19] allows individuals to purchase or lease solar battery by using bitcoin or local currency. An electronic project initiated by the UK in the literature [20], which runs on Ethereum, provides a flexible block-based trading platform that supports electricity, natural gas, and community energy. Enerchain project [21] focuses on the use of blockchain technology for P2P transactions in the wholesale energy market.

However, many security issues such as identity authentication, the realization of consensus mechanism, and privacy protection are not mentioned in these systems. This paper focus on the identity authentication of users for the blockchain-based energy trading systems.

1.2 Related work

Currently, there are some blockchain-based identity authentication schemes [2227]. These researches can be divided into two categories. One is based on government platforms. The goal is to create a blockchain-based world or national identity registration system and provide some government services [2225]. Another one is for companies; its aim is to complete the identity registration authentication services with blockchain [26, 27]. Moreover, several blockchain-based authentication schemes for smart grid were proposed over the last several years [2831]. A blockchain identity management system based on public identities ledger is discussed in [32]. Unfortunately, among these schemes, the important node is the smart grid. They only considered how to complete the certification for smart grid. In the general energy trading system, there is no smart grid, and more participants are users. We focus on how to implement user identity authentication in such a system.

Edge computing is a way of processing data that is physically close to where the data is generated. Edge computing is relative to cloud computing. There is much literature on the application of edge computing [3347]. In an edge computing-based blockchain system, each device needs to pay a certain amount of deposit. Each device is a node, a witness, a trusted oracle, and a judge with clear rewards and punishments. No one even needs to participate. People just need to enjoy a credible society, and the rest is done by the marginal computing block chain.

1.3 Our contribution

In order to solve the problem of identity authentication in blockchain-based energy trading system, we design an edge computing-based authentication scheme for blockchain-based distributed energy trading systems (ECAS-BDETS), which includes three processes named as journalizing, registration, and identity authentication. Our scheme can ensure unforgeability and privacy. In addition, the correctness and security analysis of the scheme are also given in this paper. The main contributions of this paper include:

  1. 1.

    In the process of journalizing, we use the proof of stake (PoS) plus credit score to complete the bookkeeper selection. To avoid regional managers with more transactions which tend to get higher credit score, we randomly select one of the regional managers with honor values greater than or equal to k each time.

  2. 2.

    In the process of user registration, we ensure that the user’s identity cannot be forged by processing and storing the user identity information in the block chain based on the tag and Merkle tree principle.

  3. 3.

    In the process of identity authentication, the user’s identification is realized by using digital signature technology and time stamp.

1.4 Organization of this paper

The rest of the paper is organized as follows. Preliminaries are given in Section 2. In Section 3, we formally define the framework and security requite for blockchain-based authentication scheme for energy trading system. The proposed scheme is presented in Section 4. An example of our scheme will be presented in Section 5. We analyze the security of the proposed scheme and compare it with other related schemes in Section 6. In Section 7, our scheme is compared with some existing schemes in terms of function. Finally, conclusions and future work are given in Section 8.

2 Preliminaries

In this section, we briefly introduce some knowledge of Merkle tree and signature, which are necessary for the subsequent development.

2.1 Merkle tree

Merkle Tree, also known as a "Hash Tree," as the name implies, is a tree that stores hash values. A leave node of a Merkle tree is attached the hash value for a data block. A non-leaf node is attached the cryptographic hash of its corresponding child nodes.

Figure 1 presents a simple example of a Merkle Tree. Let D={L1,L2,L3,L4} to denote the set of data. In the leaf nodes, Hash(ij)=H(Lk), where i,j∈{0,1},k∈{1,2,3,4}, H is a hash function. In the nodes inside, each of H0 and H1 has a left child denoted by (i,0) and a right child denoted by (i,1). A hash value, which is computed by H(i)=H(Hash(i0),Hash(i1)) is stored by each internal node. Top Hash denotes the root node. It stores a hash value computed by H(H(0),H(1)).

Fig. 1
figure 1

An example of a Merkle Tree. The working mechanism of Merkle tree

2.2 Signature scheme

Digital signature is a digital string that can only be generated by the sender of the information and cannot be forged by others. This digital string is also an effective proof of the authenticity of the information sent by the sender. It is based on public key cryptography and can be used for identification. In general, a digital signature scheme is a tuple of three probabilistic polynomial time (PPT) algorithms Sig=(Sig.Gen,Sig.Sign,Sig.Vrf) such that:

  • SIG.Gen: Sig.Gen(1λ) takes in a security parameter and outputs a verification key vk and a signing key sk.

  • SIG.Sign: Sig.Sign(sk,m) takes in a signing key sk and a message m and outputs a signature σ on message m under signing key sk.

  • SIG.Vrf: Sig.Vrf(vk,m,σ) takes in a verification key vk, a message m, and a signature σ and outputs 1 if the signature is valid and 0 otherwise.

A complete digital signature should include the following three mechanisms:

  • The signer cannot deny his signature after signing.

  • Others cannot forge a signature.

  • If the parties dispute the authenticity of the signature, the validity of signature can be verified by a fair arbitrator.

3 Security model

3.1 The system structure

The system of our scheme consists of two parts, i.e., regional manager and the communities and users. Figure 2 shows the system structure.

Fig. 2
figure 2

The system structure. The system of our scheme consists regional manager, the communities and users

The regional manager, conducted as the energy management center of a certain region, is responsible for the management and transaction information of the blockchain. It completes the registration of new users and the identity authentication of users in the process of transaction and can trade with other regional managers according to the electricity consumption in the region.

Communities and users can send transaction requests to the regional manager, including buy, sell, and so on, depending on their situation. Because the community and the user have the same functional needs, we treat the community as a user in our system.

3.2 Security requirement

In ECAS-BDETS, we assume the user and the regional manager are semi-honest. It means that they will run the protocol honestly, but they will collect information from other users maliciously for forged identity. According to the requirements of the identity authentication scheme, we present security goals for a blockchain-based energy trading system.

  • Correctness. We require that the identity authentication process is correct. Namely, if both of the user and the regional manager follow the proposed protocol, the identity authentication can be verified.

  • Unforgeability. In our scheme, the identity of a legitimate user will not be forged. A forged identity will not pass verification.

  • Privacy. User identity information will be hidden. The identity of the user in our scheme is replaced by the value of the root node of a Merkle tree. Neither the regional manager nor other users will know the true identity of the user.

Remark 1

Because the semi-honest model is more common in actual production and life, it is necessary to consider the semi-honest opponent alone, so we choose the semi-honest model.

Remark 2

The participants in the semi-honest model follow the execution of the protocol, but preserve the intermediate computed state of the protocol.

4 Our construction

ECAS-BDETS consists of two parts: one is the regional manager, anthrone is user. Both the regional manager and the user are considered nodes. We assume that every regional manager has a key pair (PkM,SkM) and the user has a key pair (Pki,Ski). Three operating steps namely, process of journalizing, the user registration, and identity authentication are described as follows.

4.1 Process of journalizing

In the accounting process, the consensus mechanism is the most important. In bitcoin, the proof of work (PoW) and the proof of stake (PoS) are used for gaining the right to account. Since our scheme is based on edge calculations, we regard the participants in the blockchain as nodes and use the credit score to obtain the accounting permission. In order to avoid some people have more opportunities to get higher credit score, we randomly select one of the nodes with honor values greater than or equal to k each time.

  1. 1.

    The initial credit score for each transportation is n. In the first round of voting, because the credit score is the same, each node randomly selects a node as the accounting node, and the one with the most votes will be the bookkeeper.

  2. 2.

    If there is a transaction, in the end of every transaction, both parties give each other a score s according to each other’s performance in this activity. The score range is [−β,β].

  3. 3.

    Node generates the signature Sign(s,t) for the credit score and sends the signature to bookkeeper, where t is the current time.

  4. 4.

    Bookholder receives the signature; he first checks if the signature is valid. If it is valid, he broadcasts the credit score computed below in the blockchain.

    $$C=\alpha*n+(1-\alpha)*s {,} $$

    where n is the credit score before this transaction, s is the score in the current accounting period and α is a number with range [0,1], representing a weight value.

Remark 3

This value can be adjusted as needed. If you think the previous credit is more important, you can take a larger value. If you think the current credit score is more important, you can take a smaller value.

4.2 User registration

Firstly, a new user should choose a manager which she belongs to and sends the registration request to the regional manager. The regional manager helps her register with her identification through an interactive protocol. The sketch of the protocol as shown in Fig. 3 and detail described as follows.

  • User

    Fig. 3
    figure 3

    Sketch of the protocol. This is an interactive protocol between the regional manager and the user

    User O does the following:

    1. 1.

      O generates a tag Tag=tag(name,sk) for her name by using her private key.

    2. 2.

      Then, she encrypts the detailed identity information (i.e. tag, address, email address, phone no.) with the manager’s public key, obtained

      $$\phi_{1}=E_{PK_{M}(Tag,address, emaiaddress, phone NO.)} {.} $$
    3. 3.

      Next, O computes the signature Sig(Tag,tr), where tr is the current time.

    4. 4.

      Finally, O sends the ϕ1 and the signature Sig to the manager M.

  • Regional manager

    The regional manager (M) does the flowing while receiving the request:

    1. 1.

      M decrypts the ϕ1 and obtains the user’s information including:

      $$\{ Tag, address, emaiaddress, phone NO.\}. $$
    2. 2.

      Then, M checks if tr and the signature Sig are valid.

    3. 3.

      If all are valid, M generates a Merkle tree for user’s information as shown below

      $$\begin{array}{l} H_{11}=H(tag(name)),\\ H_{12}=H(address),\\ H_{21}=H(emailaddress),\\ H_{22}=H(phone NO.),\\ H_{1}=H(H_{11},H_{12}),\\ H_{2}=H(H_{21},H_{22}),\\ H_{0}=H(H_{1},H_{2}). \end{array} $$
    4. 4.

      Finally, M broadcasts the H0 in the blockchain.

The user’s registration process is shown in Fig. 4.

Fig. 4
figure 4

The registration of user. Generate a value for each user by using Merkle tree

Remark 4

In order to protect the privacy of user, we hide the user’s name by using Tag. The user generates a Tag for her name by using her private key.

Remark 5

There are many details information of the user. For the sake of simplicity, we have only selected four parameters Tag,address,emaiaddress,phoneNO.. The case of multiple parameters can be obtained in the same way.

Remark 6

For the sake of simplicity, we only generated tag for name to hide user’s name information. In fact, one can create tags for any information to be hidden.

4.3 Identity authentication process

When a transaction is made between the user and the region manager, the region manager first authenticates the user’s identity. To this end, we construct the following protocol. The main idea is shown in Fig. 5.

  • User

    1. 1.

      O generates the signature Sig(Tag,tr), where tr is the current time.

      Fig. 5
      figure 5

      The authentication of user. The regional manager completes the user’s identity authentication through a series of calculations

    2. 2.

      Then, O computes the ciphertext ϕ2(T,R,Sig,H0) using the public key of the manager in which the transaction is done, where T is the time stamp and R is the current request.

    3. 3.

      Finally, O sends the ϕ2 to M.

  • Manager

    When the manager received the request, M firstly decrypts the ϕ2 and obtains the information:

    $$\{ T, R, Sig, H_{0}\}. $$

    Then,

    1. 1.

      M makes a query for the existence of H0.

    2. 2.

      If H0 exists, M continues to check if T and the Sig are valid.

    3. 3.

      Next, M computes \(H^{\prime }_{11}=H(Tag)\) and checks if the equations hold

      $$\begin{array}{l} H'_{11}=H_{11},\\ H_{1}=H(H_{11},H_{12}),\\ H'_{0}=H(H_{1},H_{2}),\\ H'_{0}=H_{0}. \end{array} $$

    If all valid, user authentication is verified. The transaction can be done with this user.

5 An example

Any secure encryption and signature scheme, such as identity-based, attribute-based, lattice-based, and encoding-based signature schemes, can be used in our authentication scheme. We take the encryption and signature scheme based on elliptic curve based on discrete logarithm as an example to illustrate the workflow of our scheme.

5.1 Key generation algorithm

Let G be the generator of the elliptic curve. The key pairs are generated for users and managers as follows:

  1. 1.

    Randomly selects k∈[1,N].

  2. 2.

    Calculate

    $$K=kG. $$

    The public key is K, and the private key is k.

Assume that user O has the public/private key pair (kO,KO) and manager M has the bookkeeping authority and has the public/private key pair (kM,KM). The details of user registration and identity authentication process are as follows.

5.2 User registration

  • User

    1. 1.

      Compute

      $$Tag=k_{o}H_{1}(name){.} $$
    2. 2.

      Calculate

      $$\phi_{1}=(rG,(Tag, address, emaiaddress, phone NO.)+rK_{M}), $$

      where rZq is random number.

    3. 3.

      Generate

      $$\begin{array}{l} R=r'G,\\ S=r'+H(Tag)k_{O}, \end{array} $$

      where rZq is random number. Then, Sig=(R,S).

    4. 4.

      Finally, O sends the ϕ1 and the signature Sig to the manager M.

  • Regional manager The regional manager (M) does the flowing while receiving the request:

    1. 1.

      M decrypts the ϕ1 and obtains the user’s information through the following algorithm:

      $$(Tag, address, emaiaddress, phone NO.)+rK_{M}-k_{M}rG, $$

      Then, it obtains the user’s information including

      $$\{ Tag, address, emaiaddress, phone NO.\}. $$
    2. 2.

      Then, M checks if tr and the signature Sig are valid through the following equation.

      $$SG=(R+H(Tag))K_{O}. $$
    3. 3.

      If the equation holds, the signature is valid, then M generates a Merkle tree for user’s information as shown below:

      $$\begin{array}{l} H_{11}=H(tag(name)) {,}\\ H_{12}=H(address){,}\\ H_{21}=H(emailaddress),\\ H_{22}=H(phone NO.),\\ H_{1}=H(H_{11},H_{12}),\\ H_{2}=H(H_{21},H_{22}),\\ H_{0}=H(H_{1},H_{2}). \end{array} $$
    4. 4.

      Finally, M broadcasts the H0 in the blockchain.

5.3 Identity authentication process

  • User

    1. 1.

      Generates the signature

      $$\begin{array}{l} R'=r_{2}G,\\ S'=r_{2}+H(Tag,t)k_{O}, \end{array} $$

      where r2Zq is random number and t is the current time.

    2. 2.

      Computes

      $$\phi_{2}=(r_{3} G, (T, R, Sig, H_{0})+r_{3} K_{M}), $$

      where r3Zq is random number, T is the time stamp, and R is the current request.

    3. 3.

      Finally, O sends the ϕ2 to M.

  • Manager

    When the manager received the request, M firstly decrypts the ϕ2

    $$(T, R, Sig, H_{0})+r_{3} K_{M}-k_{M}r_{3} G, $$

    and obtains the informations:

    $$\{ T, R, Sig, H_{0}\}. $$

    Then,

    1. 1.

      M makes a query for the existence of H0.

    2. 2.

      If H0 exists, M continues to check if T and the Sig are valid through the following equation.

      $$S'G=(R'+H(Tag,t))K_{O}. $$

      If the equation holds, the signature is valid.

    3. 3.

      Next, M computes \(H^{\prime }_{11}=H(Tag)\) and checks if the equations hold

      $$\begin{array}{l} H'_{11}=H_{11},\\ H_{1}=H(H_{11},H_{12}),\\ H'_{0}=H(H_{1},H_{2}),\\ H'_{0}=H_{0}. \end{array} $$

    If all are valid, user authentication is verified. The transaction can be done with this user.

6 Correctness and security analysis

According to the security model introduced in Section 3, correctness and security proofs will be given in this section.

6.1 Correctness analysis

Theorem 1

The identity authentication process is correct. It means that legitimate users must be able to pass the verification, that is, the following equation

$$\begin{array}{l} H'_{11}=H_{11},\\ H_{1}=H(H_{11},H_{12}),\\ H'_{0}=H(H_{1},H_{2}),\\ H'_{0}=H_{0}. \end{array} $$

holds.

Proof

If the user is legitimate, he/she has the correct private key which is used to generate Tag. The tag can be verified.

Then,

$$\begin{array}{l} H'_{11}=H(Tag)=H_{11} \end{array} $$

holds.

So,

$$\begin{array}{l} H_{1}=H(H'_{11},H_{12})=H(H_{11},H_{12}),\\ H'_{0}=H(H_{1},H_{2})=H_{0}. \end{array} $$

6.2 Security analysis

Theorem 2

The proposed scheme is secure against forgery.

Proof

Suppose that an adversary C can attack the proposed scheme with advantage ε; it means that a malicious user can forge a legitimate identity and pass the verify; then, we can construct an algorithm F by C to solve the hard problem in which the signature scheme depends on.

  • User registration process

    • TagQuery

      Assume that C can make query on Tag, F maintains the list LTag to store the answers.

      When C makes a query on Tag, F checks if the query can found in the list LTag; if yes, return the answer to C; otherwise, F returns the random value.

    • SignQuery

      C also makes signature query on Tag. F can simulate the signature.

      Then, the adversary can output a forged signature σ on Tag.

    • Finally, F can solve the hard problem that the signature schemes depend on.

  • Identity authentication process

    We consider it in two cases.

    • The adversary C can forge a signature This is similar to the user registration process. If the adversary can output a forged signature σ on Tag. Then, F can solve the hard problem that the signature schemes depend on.

    • The adversary C can forge a Hash value

      It is well known that hash functions are collision resistant. So, no adversary can forge the H0 unless the hash function can be solved.

Theorem 3

The proposed scheme can realize the privacy protection of user identity.

Proof

In our scheme, the user’s name is hidden in the Tag. Everyone only knows the tag, but they do not know the user’s true identity. If the adversary C can obtain the name of the user, it means that the encryption scheme has been breached. That is impossible since the user generates a Tag for her name by using her private key.

Therefore, our scheme can protect the privacy of our users. □

7 Results and discussion

In terms of function, our scheme is compared with some existing schemes. The authors used a variety of patterns that provide authentication only in a centralized manner in [2831], and third parties are used in a variety of applications. In our scheme, we use blockchain technology to provide authentication and can used for all engine trading systems. Also, our scheme is independent of third party and is a peer-to-peer network. The brief summary of this comparison is given in Table 1.

Table 1 Function compare

Remark 7

In Table 1, tech. and app. mean the technique used and the application scenario of these schemes, respectively.

8 Conclusion and future work

In this paper, we proposed a general authentication scheme to solve the problem of identity authentication in blockchain-based energy trading system. The digital signature technology, time stamp, and Merkle tree are used to ensure that the identity of legitimate users cannot be forged in our scheme. Moreover, to avoid regional managers with more transactions which tend to get higher credit score, we use the proof of stake (PoS) plus credit score to complete the bookkeeper selection and randomly select one of the managers with honor values greater than or equal to k each time in the process of journalizing. In future work, we will continue to study the application of the scheme in other areas.