Cloud-edge-end based key management for decentralized applications

1.1. Background and problem statement

Advances of the blockchain technique promote the development of decentralized applications (DApps), which replace the server of traditional applications with decentralized storage ^[1,2]. A remarkable feature of DApps is that they return the ownership of data produced by end users to themselves, which is controlled by the server in traditional applications. One of the key technologies behind this is digital signature. A user of a DApp possesses a pair of public and private keys, where the public key is published and the private key is known only by the user. The private key is used to issue a signature for every data produced by the user in the DApp system, such that everyone can verify the signature via the public key. A well-known example of DApps is the bitcoin ^[3], where owning the private key is equivalent to owning all the bitcoins under an address derived from the corresponding public key.

Therefore, how to securely manage and use the private key of digital signature schemes is a pivotal problem for DApps. To address this problem, a variety of software- and hardware-based approaches have been proposed, such as crypto wallets installed in users' terminals, online crypto exchanges managing private keys on behalf of users, and so on ^[4]. Among various key management methods, a noteworthy technique is threshold cryptography which distributes the private key into multiple distributed nodes in a way that a threshold of them can collaboratively issue a signature or decrypt a ciphertext without recovering the private key. Threshold-based key management systems can tolerate a certain number of failures and corruptions, leaving the system sufficient time to recover from security instances and thereby reducing users' losses caused by the leakage or tampering of private keys.

1.2. Related work

Motivated by the key management need of DApps, threshold digital signature has attracted widespread attention from both academic and industrial communities. As the most widely adopted signature scheme in blockchain platforms and applications, threshold construction for elliptic curve digital signature algorithm (ECDSA) signature has become a hot topic in recent years. Below we review some milestones and representative constructions.

To secure bitcoin wallets, in 2016, Gennaro et al.^[5] proposed a threshold-optimal (EC)DSA signature scheme that requires the participation of the threshold $$ t $$ nodes to issue a signature. Before that, the best construction ^[6] requires $$ 2t $$ participants in the threshold signing phase. Instead of distributing the private key, Gennaro et al.^[5] encrypted the private key through an additively homomorphic encryption scheme, and distributed the decryption key in $$ (t, n) $$-threshold manner. However, the threshold signing protocol involves six rounds of interactions among at least $$ t $$ nodes, and each round requires multiple broadcasting and peer-to-peer communications. Besides, their scheme does not have a specific share renewal algorithm to update all shares after a leaking or tampering attack.

The first series of efficient threshold ECDSA schemes were proposed concurrently by Lindell and Nof ^[7] and Gennaro and Goldfeder ^[8] in 2018. The former uses ElGamal decryption "in the exponent" to realize multiplicative-to-additive (MtA) share conversion which is a major building block for threshold ECDSA. The latter instantiates the MtA protocol using the additively homomorphic encryption scheme of Paillier. After the two schemes, new constructions of threshold ECDSA have been continuously proposed every year in top journals and leading conferences in the field of information security and cryptography ^[9–12]. Till now, improving the practicability of threshold ECDSA remains a hot topic.

Compared to common $$ (t, n) $$-threshold schemes with large $$ t $$ and $$ n $$, two-party ECDSA is much more practical for real-world deployment, because it only needs two participants for issuing a signature and is thereby easy to implement. In 2017, Lindell ^[13] constructed an efficient $$ (2, 2) $$-threshold ECDSA signature which involves three messages in an offline pre-signing phase before the message arrives and one message in the online signing phase. Although this scheme is much more practical than common $$ (t, n) $$ ones, it can only address the leakage problem of private key shares. Once one of the two shares is tampered with or broken, it will be unable to issue a signature anymore. Doerner et al.^[14] presented a $$ (2, n) $$-threshold ECDSA from ECDSA assumption in 2018. Their $$ 2 $$-out-of-$$ n $$ signing protocol is run with eight messages exchanged among two nodes. This communication cost is too high for common end users of DApps. Tu et al.^[15] proposed a fast two-party signature based on the combinatorial ECDSA. However, the verification operation of their scheme is different from the original ECDSA.

In summary, reducing communication rounds and improving practicability are the main challenges in the area of threshold ECDSA. While $$ (2, 2) $$-threshold ECDSA schemes have higher practicability compared to $$ (t, n) $$-threshold ones, the best construction so far still needs eight messages. Besides, $$ (2, 2) $$-threshold schemes only address leakage problem of private key shares. Once one of the two shares is tampered with or broken, the two-party ECDSA will be unable to issue a signature anymore. The minimum threshold setting for addressing both leaking and tampering issues is $$ (2, 3) $$.

1.3. Our work

This paper addresses the key management problem for end users of DApps by combining $$ (2, 3) $$-threshold signature with the cloud-edge-end (CEE) framework. The CEE framework originates from the Internet of Things (IoT), edge computing and cloud computing. It has eventually developed as a widely adopted framework for online computing products and services. Specifically, we present the CEE key management framework consisting of three protocols: the initial splitting protocol which distributes the user's private key via $$ (2, 3) $$-threshold secret sharing into three shares held by the end node, edge node and cloud respectively, the two-party signing protocol which is run by the end and edge nodes to collaboratively generate a signature without recovering the private key, and the update protocol which renews the three shares so that they are incompatible with all previous ones.

Based on the CEE key management framework, we construct a concrete $$ (2, 3) $$-threshold ECDSA scheme with provable security under the ECDSA assumption. To overcome the challenge of distributively computing $$ s=r^{-1}\cdot (e+sk\cdot r_x) \mod q $$, where $$ r $$ is a secure instance from $$ Z_q $$, $$ e=H(m) $$, and $$ r_x=x \mod q $$ is derived from $$ (x, y)=r\cdot P $$, we adopt the following strategies. To generate $$ r_x $$ in a distributed way, we run a key agreement protocol among the end and edge nodes to generate $$ (x, y)=r^{-1}\cdot P={(r_1\cdot r_2)}^{-1}\cdot P $$ by sampling $$ r_1 $$ in the end node and $$ r_2 $$ in the edge node and then exchanging $$ r_1^{-1}\cdot P $$ and $$ r_2^{-1}\cdot P $$. To compute $$ s $$ from partial signatures $$ s_1=r_1\cdot (e+sk_1\cdot r_x) $$ and $$ s_2=r_2\cdot (e+sk_2\cdot r_x) $$, we first convert $$ r_1\cdot r_2=r $$ into $$ \alpha_1+\alpha_2=r $$ via the MtA protocol, and convert the $$ (2, 3) $$-threshold shares $$ sk_1 $$ and $$ sk_2 $$ of $$ sk $$ into $$ (2, 2) $$-additive shares $$ \hat{sk_1} $$ and $$ \hat{sk_2} $$ by multiplying them with the Lagrangian coefficients, so that each party can compute $$ s_i $$ as $$ \alpha_i\cdot e+\alpha_i\cdot sk_i\cdot r_x $$ for $$ i=1, 2 $$. Then, by running the MtA protocol again, we output $$ \beta_1 $$ and $$ \gamma_1 $$ on the end node and $$ \beta_2 $$ and $$ \gamma_2 $$ on the edge node such that $$ \beta_1+\beta_2={\alpha}_1\cdot \hat{sk_2} $$ and $$ \gamma_1+\gamma_2=\alpha_2\cdot \hat{sk_1} $$. Finally, the end node computes $$ s_1=\alpha_1\cdot e+ (\alpha_1\cdot \hat{sk_1}+\beta_1+\gamma_1)\cdot r_x $$, and edge node computes $$ s_2=\alpha_2\cdot e+ (\alpha_2\cdot \hat{sk_2}+\beta_2+\gamma_2)\cdot r_x $$, which are additive shares of $$ s $$. Additionally, we present an update protocol for the $$ (2, 3) $$-threshold ECDSA, which is often missing in related work of threshold ECDSA. This protocol can renew all these three shares even if one of them is tampered with. To recover the tampered share, we construct a share recovery protocol based on secure multi-party computation.

The main contributions of this paper are summarized as follows. First, the proposed CEE key management framework provides a practical pattern for securely managing and using private keys in blockchain-based applications. It addresses key management problems of DApp users and demonstrates a practical deployment and application pattern of threshold signature. Although we only illustrate its implementation in ECDSA key management; it can be applied more easily for other signature schemes, given that constructing threshold ECDSA is more challenging than other signature schemes such as Schnorr and Boneh-Lynn-Shacham (BLS) signatures. Second, the constructed $$ (2, 3) $$-threshold ECDSA has a much lower communication cost than parallel schemes with a $$ (2, n) $$ threshold setting where $$ n\geq 2 $$, as it only requires three messages exchanged between the end and edge node for issuing a signature, while the best result of $$ (2, 2) $$-threshold ECDSA ^[13] is four messages. Moreover, the $$ (2, 3) $$-threshold setting can tolerate tampering on one of the private key shares, which is not achieved by the $$ (2, 2) $$-threshold one.

1.4. Organization

The remaining sections of this paper are organized as follows. Section 2 reviews the ECDSA signature scheme and cryptographic tools used in our design. Section 3 presents the CEE key management framework and its threat and security models. Sections 4, 5, and 6 construct the CEE-based $$ (2, 3) $$-threshold ECDSA scheme, prove its security, and evaluate its performance, respectively. Section 7 discusses the application prospect of the CEE-based key management framework and illustrates a case of its use. Finally, Section 8 concludes this paper and proposes future work.

2.1. ECDSA

2.2. Cryptographic toolbox

Below we review cryptographic tools used in our scheme.

3.1. System overview

As shown in Figure 1, the CEE key management system involves three kinds of nodes: the cloud, edge, and end nodes. Their responsibilities in application scenarios are introduced as follows:

Figure 1. The CEE key management system and its interaction with Blockchain applications. The terminal for splitting $$ sk $$ and for holding $$ sk_1 $$ can be the same one. CEE: cloud-edge-end.

• Cloud node maintains a $$ (2, 3) $$ share of user's private key. It is responsible for recovery or update of the private key in case of security incidents threatening one of the other two shares in the edge and end nodes. In real-world applications, the cloud node can be a semi-trusted service provider that provides private key safeguarding services.

• Edge node also maintains a $$ (2, 3) $$ share of user's private key. It participates in the signing protocol collaboratively with the end node. In the real world, the edge node can be the edge server or gateway of an institute such as a company, a university, etc. Another example is the smart home scenario where the edge node can be a router that connects end devices in the home to the internet. In these cases, the edge node can be regarded as a trusted user-side device.

• End node takes the original private key as input and distributes it into three shares. It also maintains a $$ (2, 3) $$ share of the private key to issue signatures collaboratively with the edge node. It is the user-side terminal interacting with the user and, thereby, is trusted.

The number of each type of node depends on the needs and restrictions of real-world application environments. Each user may have one or more pairs of private and public keys, which again depends on the application scenario. For a pair of private and public keys $$ (sk, pk) $$, a cloud node, an edge node, and an end node will be involved to securely manage the private key. Specifically, there are three protocols for the key management framework:

• Initial Splitting. On input of a private key $$ sk $$ in the end node, this protocol uses $$ (2, 3) $$-threshold secret sharing to split $$ sk $$ into three shares $$ sk_1 $$, $$ sk_2 $$, and $$ sk_3 $$ which will be securely stored in the end node, the edge node, and the cloud, respectively.

• Two-Party Signing. To issue a signature, the end node initiates the two-party signing protocol with the edge node. Specifically, each node will use its private key share to generate a partial signature, and the two partial signatures will be used to construct the signature of $$ sk $$.

• Update. The update protocol can be run periodically or after a recovery from security incidents. Theoretically, it can be run with any two shares, even if the third one is leaked or tampered with. Here we focus on a situation in which the cloud is not compromised, and one of the user-side devices, i.e., the edge node or end node, is compromised. The cloud is normally more powerful in terms of computing and storing capabilities than the edge and end nodes. Moreover, it is maintained by service providers with professional security managers and technicians. Therefore, it is less likely to be compromised by security incidents in practice.

3.2. Threat model and security model

4.1. Initial splitting

The initial splitting protocol is illustrated in Figure 2. Assume secure channels have been established among the end node, the edge node and the cloud. The user inputs $$ sk $$ in the end device and starts the initial splitting protocol which outputs three shares of $$ sk $$ and a pair of public and private keys for an additively homomorphic encryption scheme as follows:

Figure 2. The initial splitting protocol. The secure channels can be established via public-key encryption or key agreement protocol.

$$ 1. $$ Split $$ sk $$ into $$ sk_1 $$, $$ sk_2 $$, and $$ sk_3 $$ via the $$ \mathbf{Dis}(sk, 2, 3) $$ algorithm of Shamir's threshold secret sharing.

$$ 2. $$ Generate a pair of private and public keys $$ (hsk, hpk) $$ via the $$ \mathbf{KeyGen(1^k)} $$ of an additively homomorphic encryption scheme and publish $$ hpk $$

$$ 3. $$ Securely send $$ sk_2 $$ to the edge node and $$ sk_3 $$ to the cloud.

$$ 3. $$ Keep $$ sk_1, hsk $$ in the end node and erase $$ sk $$, $$ sk_2 $$, $$ sk_3 $$.

In addition to the three private key shares, the above protocol also outputs and publishes a pair of keys $$ (hsk, hpk) $$ which will be used for implementing additively homomorphic encryption in the MtA procedure of the two-party signing protocol. Although it is possible to reuse $$ sk_1 $$ and $$ pk_1=sk_1\cdot P $$ for the homomorphic encryption, here we have two reasons for generating dedicated key pairs. First, the additively homomorphic encryption scheme can be one established on a different mathematical problem rather than the discrete logarithm problem over elliptic curve groups of ECDSA, which means that $$ (sk_1, pk_1) $$ is not a pair of keys for the homomorphic encryption scheme. Secondly, publishing $$ pk_1 $$ in the system will reduce the security of the $$ (2, 3) $$-threshold ECDSA scheme. We will explain this point in detail in Section 5.2 after proving the unforgeability of the scheme.

4.2. Two-party signing

The two-party signing protocol is run jointly by the end and edge nodes to output a signature $$ \sigma=(r_x, s) $$ for a message $$ m $$, where $$ r_x $$ is derived from the $$ x $$ coordinate of $$ R=r\cdot P $$ for some randomly generated $$ r\in Z_q $$, and $$ s=r^{-1}\cdot (e+sk\cdot r_x) $$. In our scheme, $$ R $$ is established as $$ r_1^{-1}\cdot r_2^{-1}\cdot P $$, where $$ r_1 $$ and $$ r_2 $$ are securely generated by the end and edge nodes. Therefore, the end and edge nodes can compute partial signatures as

where $$ r_1 $$ and $$ r_2 $$ are $$ (2, 2) $$-multiplicative shares of $$ r^{-1} $$, and $$ sk_1 $$ and $$ sk_2 $$ are $$ (2, 3) $$-Shamir shares of $$ sk $$. However, we still cannot compute $$ s $$ from $$ s_1 $$ and $$ s_2 $$ as they are neither $$ (2, 2) $$-multiplicative shares nor $$ (2, 3) $$-Shamir shares of $$ s $$. To construct $$ s $$ from $$ s_1 $$ and $$ s_2 $$, we need to convert $$ s_1 $$ and $$ s_2 $$ into additive shares of $$ s $$. Specifically, we address the following three objectives in an offline pre-signing procedure before the input of $$ m $$:

• Converting the multiplicative shares $$ r_1 $$ and $$ r_2 $$ of $$ r^{-1} $$ into additive shares $$ \alpha_1 $$ and $$ \alpha_2 $$, that is, outputting $$ \alpha_1 $$ on the end node and $$ \alpha_2 $$ on the edge node such that $$ \alpha_1+\alpha_2=r_1\cdot r_2=r^{-1} $$. This is addressed via the MtA protocol.

• Converting the $$ (2, 3) $$-threshold shares $$ sk_1 $$ and $$ sk_2 $$ of $$ sk $$ into additive shares $$ \hat{sk_1} $$ and $$ \hat{sk_2} $$, that is, outputting $$ \hat{sk_1} $$ on the end node and $$ \hat{sk_2} $$ on the edge node such that $$ \hat{sk_1}+\hat{sk_2}=sk $$. This is addressed by multiplying $$ sk_i $$ with the Lagrange coefficient $$ \lambda_i $$.

• Converting $$ \alpha_1\cdot \hat{sk_2} $$ into $$ \beta_1+\beta_2 $$ and $$ \alpha_2\cdot \hat{sk_1} $$ into $$ \gamma_1+\gamma_2 $$, where $$ \beta_1 $$ and $$ \gamma_1 $$ are output on the end node, and $$ \beta_2 $$ and $$ \gamma_2 $$ on the edge node. This is again realized via the MtA protocol.

By addressing the three objectives above, the end node will be able to compute $$ s_1=\alpha_1\cdot e +(\alpha_1\cdot \hat{sk_1}+\beta_1+\gamma_1)\cdot r_x \mod q $$, and the edge node can compute $$ s_2=\alpha_2\cdot e +(\alpha_2\cdot \hat{sk_2}+\beta_2+\gamma_2)\cdot r_x \mod q $$. Now, $$ s_1 $$ and $$ s_2 $$ are additive shares of $$ s $$, since

The above method requires running a key agreement instance to output $$ R $$ and three MtA instances to output $$ (\alpha_1, \alpha_2) $$, $$ (\beta_1, \beta_2) $$ and $$ (\gamma_1, \gamma_2) $$ among the end and edge nodes. This involves eight messages. To reduce the round of interactions, we integrate them together in the pre-signing protocol and reduce the total number of messages to three.

The two-party singing protocol is illustrated in Figure 3. It consists of an offline pre-signing protocol and an online singing protocol. Below we introduce the two protocols in detail.

Figure 3. The two-party signing protocol.

4.3. Update

The update protocol is initiated by the user via the end device, either periodically or after recovery from security incidents. We consider the following two cases. If a share is leaked but not tampered with, then the three parties can run the share renewal protocol in Section 2.2.3 to update all three shares. If a share $$ sk_k $$ ($$ k\in\{1, 2\} $$ according to our system model) is tampered with, then before the share renewal protocol, the update protocol needs to recover it via the other two shares $$ sk_i $$ and $$ sk_j $$ as follows:

where $$ i, j, k\in\{1, 2, 3\} $$ and $$ i\neq j\neq k $$ for a $$ (2, 3) $$ setting.

Theoretically, the update protocol can securely update all three shares as long as at least two of them are not tampered with and at most one of them is leaked. In our scenario, we assume the share $$ sk_3 $$ in the cloud is secure. In the recover procedure, to guarantee that only the party $$ \mathcal{P}_k $$ can compute $$ sk_k $$ without knowing $$ sk_i $$ and $$ sk_j $$, we use secure multi-party computation as follows:

• [Optional] Share recovery:

$$ 1. $$$$ \mathcal{P}_i $$ generates a random $$ n_i $$, computes

and sends $$ n_i $$ to $$ \mathcal{P}_j $$ via public channel.

$$ 2. $$$$ \mathcal{P}_j $$ generates a random $$ n_j $$, computes

and sends $$ A_j $$ to $$ \mathcal{P}_j $$ via public channel.

$$ 3. $$$$ \mathcal{P}_i $$ computes

and send $$ A $$ to $$ \mathcal{P}_k $$ via the secure channel.

$$ 4. $$$$ \mathcal{P}_j $$ computes

and sends $$ B $$ to $$ \mathcal{P}_k $$ via secure channel.

$$ 4. $$$$ \mathcal{P}_k $$ computes

• Share renewal: The three participants run the share renewal protocol in Section 2.2.3 to refresh their private key shares.

The update protocol is illustrated in Figure 4, which assumes that $$ sk_1 $$ in the end node is tampered with.

Figure 4. The update protocol, assuming $$ sk_1 $$ in the end node is tampered with.

5.1. Unforgeability

We first claim the unforgeability of our $$ (2, 3) $$-threshold ECDSA in the following theorem and then prove it.

Theorem 1The $$ (2, 3) $$-threshold ECDSA in Section 4 is $$ (\tau, q_s, q_c, \epsilon) $$-secure in the $$ (2, 3) $$-TEU-CMA model, given that the standard ECDSA signature scheme is EU-CMA secure. Specifically, the advantage of any PPT adversary $$ \mathcal{A} $$ winning the $$ (2, 3) $$-TEU-CMA experiment is

where $$ Adv_{ECDSA}^{EU-CMA}(\mathcal{B}) $$ is the advantage of $$ \mathcal{B} $$ winning the EU-CMA game.

Let $$ \mathcal{A} $$ be an adversary against the $$ (2, 3) $$-threshold ECDSA, and $$ \mathcal{B} $$ be the challenger running the $$ (2, 3) $$-TEU-CMA experiments with $$ \mathcal{A} $$. Meanwhile, $$ \mathcal{B} $$, as an adversary, runs the EU-CMA experiment with an ECDSA challenger $$ \mathcal{C} $$. Therefore, $$ \mathcal{B} $$ works as a connector between the $$ (2, 3) $$-TEU-CMA experiment and the EU-CMA experiment. Below we illustrate how to embed the EU-CMA experiment into the $$ (2, 3) $$-TEU-CMA experiment and reduce the $$ (2, 3) $$-TEU-CMA security of the $$ (2, 3) $$-threshold ECDSA to the EU-CMA security of ECDSA.

In the $$ (2, 3) $$-TEU-CMA experiment, $$ \mathcal{B} $$ initializes system public parameters and keys and interacts with $$ \mathcal{A} $$. Meanwhile, in the EU-CMA experiment, $$ \mathcal{B} $$ interacts with $$ \mathcal{C} $$ who initializes the system parameters and keys of ECDSA. Specifically,

• Initialization.

- Initialization of ECDSA. $$ \mathcal{C} $$ initializes the system public parameters $$ \mathbf{pp}=\{G, P, q, Z_q\} $$ and a pair of public and private keys $$ (pk, sk) $$ of ECDSA. The system public parameters $$ \mathbf{pp} $$ and public key $$ pk $$ are given to $$ \mathcal{B} $$.

- Initialization of $$ (2, 3) $$-threshold ECDSA. $$ \mathcal{B} $$ initializes the three shares of $$ sk $$ and keys of additively homomorphic encryption scheme as follows:

$$ 1. $$ Generate random $$ sk_1, sk_2, sk_3\in Z_q $$.

$$ 2. $$ Generate $$ (hsk, hpk) $$ as specified in the initial splitting protocol.

$$ 3. $$ Provide system public parameters and public keys $$ (pk, hpk) $$ to $$ \mathcal{A} $$.

• Queries.

- Signature queries. $$ \mathcal{A} $$ submits a message $$ m $$ chosen at will to $$ \mathcal{B} $$ and queries the signature. $$ \mathcal{B} $$ queries $$ \mathcal{C} $$ the signature on $$ m $$. $$ \mathcal{C} $$ runs the $$ \mathbf{Signing} $$ algorithm of ECDSA and returns the signature $$ \sigma $$ to $$ \mathcal{B} $$. Finally, $$ \mathcal{B} $$ forwards $$ \sigma $$ to $$ \mathcal{A} $$.

- Corruption queries. $$ \mathcal{A} $$ submits an index $$ i\in \{1, 2, 3\} $$ to $$ \mathcal{B} $$ to make a corruption query. $$ \mathcal{B} $$ replies with $$ (sk_1, hsk) $$ if $$ i=1 $$ and $$ sk_i $$ otherwise. $$ \mathcal{B} $$ also replies $$ s_i $$ to $$ \mathcal{A} $$ if $$ i\neq 3 $$.

• Forgery. $$ \mathcal{A} $$ returns a forged signature $$ \sigma^* $$ on some new message $$ m^* $$ that has never been queried in the query phase. $$ \mathcal{B} $$ returns $$ m^* $$ and $$ \sigma^* $$ to $$ \mathcal{C} $$.

After $$ q_s $$ signature queries and $$ q_c $$ corruption queries, if $$ \mathcal{A} $$ wins the $$ (2, 3) $$-TEU-CMA experiment, then $$ \sigma^* $$ is a valid signature on $$ m^* $$ and $$ \mathcal{B} $$ wins the TEU-CMA security experiment. Therefore, the advantage of $$ \mathcal{A} $$ winning the $$ (2, 3) $$-TEU-CMA experiment no more than the advantage of $$ \mathcal{B} $$ winning the EU-CMA experiment, that is,

Since ECDSA is EU-CMA secure, $$ Adv_{ECDSA}^{EU-CMA}(\mathcal{B}) $$ is negligible. Therefore, $$ Adv_{(2, 3)-threshold ECDSA}^{(2, 3)-TEU-CMA}(\mathcal{A}) $$ is negligible. According to Definition 2, the $$ (2, 3) $$-threshold ECDSA scheme is secure under the $$ (2, 3) $$-TEU-CMA model.

5.2. Discussion

The initial splitting protocol in Section 4.1 generates dedicated private and public keys for the additively homomorphic encryption, rather than reusing $$ (sk_1, pk_1) $$. Now we explain why reusing $$ (sk_1, pk_1) $$ can negatively influence the security of the scheme.

If $$ (sk_1, pk_1) $$ is used for the additively homomorphic encryption scheme, then the adversary $$ \mathcal{A} $$ will be given $$ pk_1 $$ in addition to $$ pk $$ in the $$ (2, 3) $$-TEU-CMA security experiment. With $$ pk_1 $$ and $$ pk $$, $$ \mathcal{A} $$ can derive the other two public keys $$ pk_2=sk_2\cdot P $$ and $$ pk_3=sk_3\cdot P $$ as follows:

as

Note that $$ \mathcal{B} $$ does not have $$ sk $$ and the discrete logarithms of $$ pk_2 $$ and $$ pk_3 $$. By submitting an index $$ 2 $$ or $$ 3 $$ in the corruption query, $$ \mathcal{A} $$ can distinguish the experiment from a real execution of the $$ (2, 3) $$-threshold ECDSA, which will result in failure of the $$ (2, 3) $$-TEU-CMA security experiment.

6.1. Communication cost

The communication cost is estimated by the number of messages transmitted among secure and public peer-to-peer channels and broadcasting channels in each protocol. Let $$ \mathbf{spc} $$ denote secure peer-to-peer channel, $$ \mathbf{ppc} $$ denote public peer-to-peer channel, and $$ \mathbf{bc} $$ denote broadcasting channel. The estimated communication cost is listed in Table 2.

The initial splitting protocol involves two messages over secure channels from the end node to the edge and the cloud and one broadcasting channel to publish the homomorphic encryption key. Notably, the two-party signing protocol uses merely two messages in an offline phase and one message in the online phase, and all are over public channels among the end and edge nodes in the local area. This brings very light communication costs for the application scenario. The update protocol involves two messages for an optional share recovery phase and six for the share renewable phase, and all of them are over public peer-to-peer channels.

To study the reduction in communication complexity achieved by the proposed $$ (2, 3) $$-threshold ECDSA scheme, the number of messages involved in the threshold issuance of an ECDSA signature was compared with those of representative schemes, as shown in Table 3. The results indicate that this scheme significantly reduces communication complexity.

6.2. Computing cost

The computing cost is evaluated via the number of exponentiation (i.e., scalar multiplication over elliptic curve group $$ G $$), and the key generation, encryption and decryption algorithms of additively homomorphic encryption scheme. The additively homomorphic encryption scheme is instantiated as the elliptic curve ElGamal encryption "in-the-exponent". The estimated computing cost is summarized in Table 4, where $$ \mathbf{exp} $$ denotes exponentiation.

In Table 4, the estimated computing cost for most cells is 0. This does not mean the corresponding protocols bring no computing task to the node. There are still some lightweight operations such as integer addition, integer multiplication, random number generation, etc. Their costs are ignored compared to time-consuming operations such as exponentiation, encryption, etc.

Notably, in Table 4, most computing costs are from the pre-signing phase. In practice, this phase can be executed offline before the application's message is generated. Therefore, the scheme will not influence user experience of DApps given that the online signing phase introduces very low computing costs.

To further estimate the computing cost for real-world applications, we test the running time of exponentiation in common end and edge devices (a smartphone and a laptop). Details of the hardware and software environment are explained in Table 5. The average time for computing one exponentiation is 0.0273 seconds on the smartphone and 0.0116 seconds on the laptop. Based on the results, we evaluate the running time for initial splitting as 0.0273 seconds on the end node, and for pre-signing as 0.2998 seconds on the end node and 0.1280 seconds on the edge node. The results are acceptable for real-world applications.

7.1. Background and key management challenges of DePIN

DePIN refers to decentralized physical infrastructure networks utilizing blockchain technology to return the ownership and commercial rights of data back to the users, allowing everyone to benefit from their own digital footprint. As a promising sector, DePIN has been attracting growing interest and investment recently. The leading credit ratings agency, Moody's Ratings, has highlighted the potential of DePIN to transform physical infrastructure networks ^[24]. Individuals holding physical devices (e.g., mobile phones, personal computers, smart cars, etc.) can participate in DePIN and get cryptocurrency rewards by providing data or services via their devices, such as providing real-time noise pollution information through a smartphone, supporting navigation services by uploading real-time traffic information through an intelligent vehicle while driving, etc. In these cases, the ownership of data is enforced by signatures issued by the private key of the device. The rewards are paid to an address derived from the corresponding public key.

Considering the scenario of real-time noise pollution monitoring for a residential community through DePIN. To monitor noise pollution in the community, the related department can collect noise data via DePIN instead of deploying physical equipment itself. An individual user can participate in the DePIN network by installing some DApps for noise pollution monitoring and registering the public key to DePIN. Then, he or she can use the sound recorder of his or her smartphone to collect noise data and submit them to the data requester (e.g., server of the noise pollution monitoring DApps). The noise data are signed by the private key of the user or the smartphone, so that a reward can be paid to the cryptocurrency address derived from the corresponding public key.

However, managing the private keys of physical devices is challenging for common users in DePIN. Existing solutions store and use the private key in the physical device. If the physical device is lost, broken, or attacked, the private key will be leaked or unavailable anymore, leading to two serious consequences:

• the reward under the cryptocurrency address will be lost, and

• a new pair of private and public keys need to be generated, and the user has to register the new public key to DePIN.

7.2. Application of CEE key management in DePIN

Now we show how to use the proposed CEE key management to address the key management problem for DePIN users.

As shown in Figure 5, the CEE key management service can be provided by a professional security company, a smartphone manufacturer, etc. To use this service, the DePIN users install client software on their smartphones. By running the software of the CEE key management system in the smartphone, the private key is distributed into three shares kept in the smartphone, the router in the home, and the cloud server of the service provider. When uploading noise pollution data, the smartphone and router run the two-party signing protocol to issue a signature and attach it to the data. The key management cloud is only involved in the key distribution and update phase.

Figure 5. CEE key management for DePIN. CEE: cloud-edge-end.

With the CEE key management service, when the physical device (e.g., the smartphone) is lost, broken, or attacked, the private key share stored in it is leaked or unavailable anymore. However, the private key remains secure and available as long as the other two shares in the router and cloud server are secure; therefore, the first consequence in Section 7.1 will not happen. Further, by running the update protocol, the three shares are refreshed while the public key remains unchanged, which means the second consequence will not occur.

Authors' contributions

Made substantial contributions to conception and design of the study: Zhang J, Zhang F

Performed security proof and evaluation: Zhang J

Provided administrative and technical support: Zhang F

Availability of data and materials

The supporting data for this article is available upon request directly from the authors.

Financial support and sponsorship

This work was partially supported by the National Natural Science Foundation of China under Grant No. 62172096; the XJTLU Research Development Fund under Grant No. RDF-21-02-014; the XJTLU Teaching Development Fund under Grant No. TDF2223-R25-207; and the Suzhou Municipal Key Laboratory for Intelligent Virtual Engineering (SZS2022004).

Conflicts of interest

All authors declared that there are no conflicts of interest.

Ethical approval and consent to participate

Not applicable.

Consent for publication

Not applicable.

Copyright

© The Author(s) 2024.