White-Box Implementation of ECDSA Based on the Cloud Plus Side Mode

White-box attack context assumes that the running environments of algorithms are visible and modifiable. Algorithms that can resist the white-box attack context are called white-box cryptography. ,e elliptic curve digital signature algorithm (ECDSA) is one of the most widely used digital signature algorithms which can provide integrity, authenticity, and nonrepudiation. Since the private key in the classical ECDSA is plaintext, it is easy for attackers to obtain the private key. To increase the security of the private key under the white-box attack context, this article presents an algorithm for the white-box implementation of ECDSA. It uses the lookup table technology and the “cloud plus side” mode to protect the private key. ,e residue number system (RNS) theory is used to reduce the size of storage. Moreover, the article analyzes the security of the proposed algorithm against an exhaustive search attack, a random number attack, a code lifting attack, and so on. ,e efficiency of the proposed scheme is compared with that of the classical ECDSA through experiments.


Background.
With the rapid development of computer and Internet technology, sensitive content containing military, political, economic, and other information is widely transmitted over networks. Because of the openness of the Internet, attackers usually use the Internet to obtain information illegally, which greatly threatens the lives and work of people. Network security has become an important part of network design, construction, and maintenance, and cryptography is the core barrier technology for protecting network information security. Traditional cryptography is based on the black-box model, which assumes that the operating environment of the cryptographic algorithm is safe. at is, the execution of the cryptographic algorithm cannot be observed nor tampered with, and an attacker can only observe and modify the information transmitted in a channel. However, as cryptography is widely used in e-mail, web access, digital rights management, e-government, and so forth, cryptographic algorithms often run in untrusted environments such as mobile phones, flat computers, and wearable electronic devices [1]. Attackers can easily use static analysis or dynamic debugging to obtain the secret key in a cryptographic algorithm, leading to a disclosure of this information. e traditional cryptography model cannot meet the increasingly high-security requirements.
In 2002, Chow et al. [2] proposed the white-box attack context, which assumes the following: (1) A fully privileged attack software shares a host with cryptographic software, having complete access to the implementation of the algorithm.
(3) Internal algorithm details are completely visible and alterable at will.
People always use hardware or software to implement cryptographic algorithms. Regarding hardware, it is costly and has poor universality. Regarding software, the secret key will appear in the memory of the computing platform. It is easy for attackers to obtain this key by injecting malware. At present, there are two ways to prevent secret key leakage during the execution of a cryptographic algorithm. One is cloud collaboration [3], and the other is key decentralized storage [4]. However, cloud collaboration cannot resist local key disclosure, and it also requires solving the problem of identification between the cloud and the terminal. Although key decentralized storage can mitigate the leak risk when the key is in static storage, the key must be composed when the cryptographic algorithm is running. Key decentralized storage will also make the whole key appear in the memory.
When the traditional cryptographic algorithms are implemented in software, the keys are easily leaked under the white-box attack context. us, it is urgent to design cryptographic algorithms that can resist white-box attacks [5]. e field of cryptography that can resist white-box attacks is called white-box cryptography. At present, the research on white-box cryptography has focused on white-box implementations and constructions. In the white-box implementations, the existing cryptographic algorithms are redesigned by using confusion, perturbation, and other methods to ensure the safeness of algorithms under the white-box attack context, with the original algorithm function kept. White-box construction is carried out to design a new cryptographic algorithm that can resist adversaries' attacks under the white-box attack context.

Previous
Work. An important line of research focused on the white-box implementations of AES and DES. In 2002, Chow et al. proposed the first white-box cryptography algorithm-the white-box AES implementation [2]. However, Billet et al. [6] put forward the BGE (BGE stands for the first letter of each of the authors, Billet, Gilbert, and Ech-Chatbi) attack to extract the AES key from the white-box AES implementation of Chow et al., with a computational complexity of 2 30 . e BGE attack motivated the design of a white-box AES implementation that can provide more resistance against key extraction. In 2006, Bringer et al. [7] proposed a new white-box AES implementation that can resist the BGE attack. Mulder et al. [8] attacked the Bringer's implementation with a computational complexity of 2 17 . After that, Xiao and Lai [9] proposed another white-box AES implementation that was cryptanalyzed by Mulder et al. [10] with a computational complexity of 2 32 . Recently, Xu et al. [11] proposed an AES-like cipher by replacing the AES S-boxes and MixColumn matrices with key-dependent components while keeping their good cryptographic properties. ey claimed that the white-box implementation of their AES-like cipher can resist current known attacks. In 2014, Luo et al. proposed a new WBAC-oriented AES implementation [12], but Bai et al. [13] showed that the secret key of Luo's implementation can be recovered with time complexity of approximately 2 44 . e earliest white-box DES implementation was proposed by Chow et al. [14] in 2003. A fault injection attack was used to extract the key from Chow's implementation by Jacob et al. [15]. In 2005, Link and Neumann [16] put forward an improved white-box DES implementation to resist the fault injection attack. However, Goubin et al. [17] and Wyseur et al. [18] both used differential cryptanalysis to extract the key from the implementation in [16]. In 2019, Amadori et al. [19] present a new DFA attack on a class of white-box implementations presented a new DFA attack on a class of white-box implementations of AES. Lin et al. [20] present an overview of the classic methods for constructing white-box solutions.
In terms of new white-box cryptographic algorithms, Biryukov et al. [21] proposed a general method for designing white-box cryptography based on the ASASA (Affine-S-box) structure. ey put forward two strong white-box variants of the ASASA symmetric scheme: one is based on Daemen's quadratic S-boxes and the other is based on random expanding S-boxes. Unfortunately, the ASASA construction was broken in [22,23]. In 2020, Kwon et al. [24] use parallel table lookups to construct a secure white-box block cipher. Alpirez Bock et al. [25] present the security goals of whitebox cryptography. Shi et al. [26] use state-dependent selectable random substitutions (SDSRS) to defeat various related white-box cryptanalytic approaches.
Currently, there are few studies on public-key white-box cryptography in the public literature. In 2018, Zhang et al. [27] proposed the first white-box implementation of the identity-based signature scheme. In 2019, Feng et al. [28] proposed a white-box implementation for the classical Shamir's IBS scheme.

Our Contributions.
In this paper, we focus on a whitebox implementation of the elliptic curve digital signature algorithm (ECDSA) [29]. ECDSA is the elliptic curve analogue of the digital signature algorithm and can provide integrity, authenticity, and nonrepudiation. e details of ECDSA can be found in several approved standards: ISO 14888-3 [30], ANSI X9.62 [31], IEEE Std 1363-2000 [32], and FIPS 186-2 [33]. Since ECDSA has a small key volume, small storage space, and high-security performance, it has become one of the most important digital signature algorithms.
e main contributions of this paper can be summarized as follows: (1) a white-box implementation of ECDSA based on the "cloud plus side" mode is proposed. To protect the security of the private key in ECDSA under the white-box attack context, we use lookup tables and permutations to protect the private key. e permutations are used in both the cloud side and the client side. e private key is confused in a series of lookup tables and is thus able to resist the whitebox attack. (2) e storage size of the proposed schemes is reduced by the residue number system. e private key is divided into several small parts by the residue number system. e small part of the private key can be hidden by a smaller size of lookup tables. e storage needed by the proposed scheme is feasible. (3) e security of the proposed scheme is analyzed from aspects of an exhaustive search attack, a random number attack, and a code lifting attack. (4) e efficiency of the proposed scheme is compared with that of the classical ECDSA through experiments. Because of the improved security, the proposed scheme runs slower than the classical ECDSA. e operation speed of the proposed scheme is also acceptable. e paper is organized as follows: in Section 2, we briefly review the signature and verification of the classical ECDSA and introduce the concept of the residue number system (RNS). In Section 3, we propose a white-box implementation of ECDSA based on the RNS. e security analysis of our scheme is discussed in Section 4. In Section 5, the efficiency of the proposed scheme is compared with that of the classical ECDSA. Finally, we conclude in Section 6.

Preliminaries
2.1. Classical ECDSA. ECDSA is a digital signature algorithm over an elliptic curve with the domain parameters D � (q, FR, a, b, G, n, h), where q is the order of field F q , FR is the field representation of elements in F q , a and b are the two coefficients used in an elliptic curve E over F q (i.e., y 2 � x 3 + ax + b in the case of a prime field, and y 2 + xy � x 3 + ax 2 + b in the case of a binary field), G � (x G , y G ) ∈ E(F q ) has prime order n, and h � #E(F q )/n is the cofactor. e user randomly selects an integer d ∈ [1, n − 1] as the private key, and the corresponding public key is Q � dG. e signature generation and verification of the classical ECDSA are as follows.
(1) ECDSA signature generation Input: Domain parameters D � (q, FR, a, b, G, , n, h), private key d, and message m. Output: Signature (r, s). (2) ECDSA signature verification Input: Domain parameters D � (q, FR, a, b, G, n, h), public key Q, message m, and the signature (r, s). Output: "Reject the signature" or "Accept the signature." (1) Verify that r and s are integers in the interval [1, n − 1]. If any verification fails, then return "Reject the signature." Otherwise, convert x 1 to an integer x 1 and compute v � x 1 (modn). (7) If v � r then return "Accept the signature"; Else return "Reject the signature."

Residue Number
System. e residue number system (RNS) [34] has been widely studied and used in many applications, such as digital signal processing, multiple precision arithmetic, and parallel computing [35,36]. An RNS is defined by a set of pairwise coprime integers β � p 1 , p 2 , . . . , p t . e set β is a basis of the RNS, and the elements in β are called the RNS moduli. Any integer x, Note that only when x is not more than P and not less than zero can x be uniquely represented by the RNS with the basis β. e original value of x can be restored from (x 1 , x 2 , . . . , x t ) by using the Chinese Remainder eorem (CRT): where P i � (P/p i ) and P i · P −1 i � 1(mod p i ). Assume that integers x and y can be uniquely represented as x � (x 1 , x 2 , . . . , x t ) and y � (y 1 , y 2 , . . . , y t ) under the basis β; then where ⊙∈ +, −, × { }. All the operations of ECDSA are performed on the finite field F q . In the following, we transform the formulas on the finite field F q into the residue number system.
(1) Assume the formulas are computed over the integers, that is, without the mod q reduction. Let |ϖ| be the absolute maximum value generated by these operations.

White-Box Implementation of ECDSA Based on the Residue Number System
Similar to most white-box cryptographic schemes, the private key d in our scheme is hidden in lookup tables T 1 , T 2 , . . . , T t (see Table 1). Let β � p 1 , p 2 , . . . , p t be a basis of the RNS, let Z p i be the prime field with order p i , and the private key d can be represented as are the inverse mappings of f i and g i , respectively. An example of the table T i generation pseudocode is as follows: Note that the table T i hides not only part of the private key d i but also the permutations f −1 i and g −1 i . If the permutations f −1 i and g −1 i are unknown, the attackers cannot derive the private key d i by the input and output of table T i . Since 1 ≤ j, k, T i (j, k) ≤ p i , the storage space of table T i is less than p 2 i log 2 p i bits. Moreover, the whole storage space of T 1 , . . . , T t is less than t i�1 p 2 i log 2 p i bits.

Protect the Random Number k.
Attackers can obtain the final signature (r, s) in the white-box attack context. To protect the private key d, we also need to protect the random number k used in the process of ECDSA signature generation. Otherwise, according to equation (3), the private key d � r − 1 (ks − e)(mod n) is easy to calculate by attackers. We use the "cloud plus side" mode to protect it. k is decomposed into two parts, namely, k 1 and k 2 , where k 1 is generated by the client and k 2 is generated by the cloud server. In the step of signature generation, the inverse of k 2 needs to be sent to the client. In order to prevent attackers in the client recovering k � k 1 · k 2 , we use a series of permutations to protect k 2 .

Our Scheme.
In the following, we always assume that the cloud server is semihonest [37]. at is, (1) the cloud server stores the data without tampering with it; (2) the cloud server honestly executes every operation; and (3) the cloud server tries to learn the underlying information of the user data. In addition, the client is in a white-box attack context. Now, we propose a white-box implementation of ECDSA. Before signing a message, we need an initialization phase to convert the private key d into a series of lookup tables T 1 , T 2 , . . . , T t . A trusted third party (TTP) is needed in the initialization phase (see Figure 1). e initialization phase is performed in a secure environment. (1) Client sends the private key d to TTP through a secure channel; (2) TTP randomly selects co-prime integers p 1 , p 2 , . . . , p t as a basis of the RNS, where P � p 1 p 2 . . . p t ≥ n 2 + n; (3) TTP randomly selects permutations f i and g i on e white-box implementation of ECDSA based on the RNS is as follows (see Figure 2). D � (q, FR, a, b, G, n, h), basis β � p 1 , p 2 , . . . , p t , and message m. Output: Signature (r, s).  From the above steps, the private key d does not appear in plaintext. If the basis β and permutations f 1 , . . . , f t and g 1 , . . . , g t are fixed, then tables T 1 , . . . , T t correspond to the private key d are fixed. Tables T 1 , . . . , T t are completely presented by the client, so attackers on the cloud server cannot directly obtain any information about the private key d.

Signature generation: Input: Domain parameters
Let k � k 1 k 2 ; then, R � k 2 P � k 2 (k 1 G) � kG. It is obvious that the first part of the signature is the same in the classical ECDSA and in our scheme.
In the classical ECDSA signature generation algorithm, the second part of the signature is Let w � u + v d(modn). If w � w, then s � s. We claim that w � w. Since u, v, d ≤ n, |u + v d| ≤ n 2 + n. Note that the basis β � p 1 , . . . , p t satisfies P � p 1 . . . p t ≥ n 2 + n. Using RNS theory, we can restore w by (w 1 , . . . , w t us, the result (r, s) of the white-box implementation of ECDSA signature generation is consistent with the result (r, s) of the classical ECDSA signature generation. One advantage of our scheme is that we can directly use the classical ECDSA signature verification algorithm to verify the signature (r, s).

4.1.
e Security in the Cloud Server and the Client. Firstly, we analyze the security of our scheme from the aspects of the cloud server and the client. We assume that the client is in a white-box attack context and that the cloud server is semihonest. e goal of attackers is to extract the private key d. e security of our scheme is based on the difficulty of the discrete logarithm problem for elliptic curves (ECDLP) and the diversity of permutations.

e Security in the Cloud Server.
From the details of our scheme, attackers in the cloud server can obtain the information of e, P, k 2 , r, and s. Moreover, the following equation holds:

Security and Communication Networks
If attackers can obtain the value of k 1 , they can extract the private key d � r − 1 (k 1 k 2 s − e)(modn) from equation (6). Fortunately, because of the difficulty of the elliptic curve discrete logarithm, attackers cannot calculate k 1 by P � k 1 G.

e Security in the Client.
From the details of our scheme, attackers in the client can obtain the information of T 1 , . . . , T t , e, k 1 , f 1 (u 1 ), . . ., f t (u t ), g 1 (v 1 ), . . ., g t (v t ), r, and s. ere seem to be two ways for attackers to compute the private key: (i) from tables T 1 , . . . , T t and (ii) from equation (6).
In case (i), table T i is constructed by where i � 1, . . . , t, j � 1, . . . , p i , k � 1, . . . , p i . After the initialization phase, the key d i and permutations f i and g i are hidden in T i . Since the permutations f i and g i are unknown to the client, attackers in the client cannot derive the key d i from table T i directly. e diversity of permutation f i (or g i ) is p i !. Hence, the complexity of deriving d i is (p i !) 2 through an exhaustive search attack. e computational complexity of extracting the private key d from case (i) is t i�1 (p i !) 2 . In case (ii), if attackers can obtain the value of k 2 , they can extract the private key d from equation (6). For the client, the information of k 2 is hidden in f 1 (u 1 ), . . ., f t (u t ), Since the permutations are unknown to the client, the complexity of deriving k 2 is t i�1 p i ! through an exhaustive search attack. e computational complexity of extracting the private key d from case (ii) is t i�1 p i !.
Remark. e proposed scheme is a kind of cloud collaboration. e secret key is stored completely in the client in a form of lookup table. e attackers in the client cannot get the plaintext information of the key from the lookup table.

Client
Cloud server (4) e and P.
(11) r, f 1 (u 1 ),..., f 1 (u t ), g 1 (u 1 ),..., g t (u t ). At the same time, even if the cloud is untrusted, the attacker in the cloud cannot obtain any information about the key. So, the proposed scheme alleviates the problems of local key disclosure and identity authentication in general cloud collaboration.

Random Number Attack.
In the classical ECDSA, the random integer k must be different for different messages. Assume that, for different messages m′ and m ″ , we select the same random integer k to sign. en, we have Usually, the information of e ′ , e ″ , (r, s ′ ), and (r, s ″ ) is public; thus, attackers can easily obtain the information of the private key d.
In the white-box implementation of ECDSA, the random integers k 1 and k 2 are generated by the client and cloud server, respectively. For two messages m ′ and m ″ , assume that k 1 ′ and k 2 ′ are used to compute the signature (r ′ , s ′ ) of m ′ and that k 1 ″ and k 2 ″ are used to compute the signature (r ″ , s ″ ) of m ″ . en, we have Under the white-box attack context, the attackers in the client can obtain the information of k 1 ′ , k ′ ′ 1 , e ′ , e ″ , (r ′ , s ′ ), and (r ″ , s ″ ), and the attackers in the cloud server can obtain the information of k 2 ′ , k ′ ′ 2 , e ′ , e ″ , (r ′ , s ′ ), and (r ″ , s ″ ). We analyze the security of private key d in the following four cases: From equation (9), we have d � (s ′ r ″ − s ″ r ′ ) − 1 (s ″ e ′ − s ′ e ″ )modn. us, attackers in the client or the cloud server can derive the private key d under the white-box attack context.
us, attackers in the cloud server can derive the private key d under the whitebox attack context.
Regardless of whether the attackers are in the client or the cloud server, they cannot simultaneously obtain the information of k 1 ′ , k 1 ″ , k 2 ′ , and k 2 ″ . us, attackers cannot obtain the information of private key d from equation (9) under the white-box attack context.
In summary, the random integers k 1 and k 2 used in our scheme must be different for different messages.

Code Lifting Attack.
One of the main purposes of the white-box cryptography is to protect the security of the algorithm implemented in the software used. It is well known that the algorithm implemented in the software is at risk of a code lifting attack (i.e., the entire code will be extracted and used as an equivalent secret key). To resist the code lifting attack, one common method is to bind the hardware information to the code. e method can also be used in the white-box implementation of ECDSA. Only two steps of our scheme proposed in Section 3 need to be modified: (i) the construction of table T 1 , . . . , T t in the initialization phase and (ii) step (13) in the signature generation phase.
It is easy to check the correctness of the new scheme. e HI is hidden in lookup tables T 1 ′ , . . . , T t ′ . For each signature, the HI must be correctly extracted from the device.
rough the hardware binding method, the code lifting

Performance Evaluation
In this section, we analyze the performance of our proposed scheme and compare it with the classical ECDSA [31]. e simulation is programmed by C language. Visual Studio 2015 is administered on a PC with an Intel Core i7-6700 3.40 GHz CPU and Windows 10 operating system using the MIRACL library. SM3 algorithm is used to calculate the hash values of the messages. e domain parameters D � (q, FR, a, b, G, n, h) on the elliptic curve y 2 � x 3 + ax + b, and the basis β of RNS are shown in Table 2.
e size of the lookup table is about 35.4 MB. We run each experiment 100 times and calculate the average. All the times reported in Tables 3 and 4 are averages.
In Table 3, we compare the computation cost of our scheme with the classical ECDSA, where the size of the message is 100 KB. e classic ECDSA includes two stages: signature generation and signature verification. Compared with the classical ECDSA, our scheme proposed in Section 3 has one more stage: initialization. As shown in Table 3, the time of initialization of our scheme is 4881.18 milliseconds, which is the main cost of our scheme. Fortunately, this stage is usually executed by a TTP who possesses strong processing capability, so the time will be shorten. What is more, the initialization stage needs to be executed again only when the user needs to change the key. e user's private key is not often replaced in the actual application scenario, so the time of initialization is acceptable. e times of signature generation in classical ECDSA and our scheme are 5.11 milliseconds and 1749.61 milliseconds, respectively. Although the calculation time of our scheme is more, the security of the proposed scheme is higher. Note that the signature verification is the same in two schemes, so the times of signature verification are essentially equal.
In Table 4, we analyze the signature generation time of the message with different sizes, that is, 1 kB, 10 kB, 100 kB, 1 M, 10 M, 100 M, and 1 GB. e longer the size of the message is, the longer it takes to compute the hash value of the message. So, the time of signature generation is increasing when the size of the message is increasing in two schemes. Generally, our scheme takes an extra 1.7 to 1.9 seconds in the phase of signature generation.

Conclusions
A white-box implementation of ECDSA based on the RNS in the "cloud plus side" mode is proposed. Not only it can protect the security of the private key under the white-box attack context, but also it has good compatibility, has a low communication cost, and requires a small storage space. e proposed techniques can be extended to Schnorr signatures [38] or other ElGamal-based schemes [39].
e study of the white-box implementation of ECDSA can provide powerful theoretical support for the software implementation of the digital signature algorithm and expand the applied scenario of ECDSA. However, the white-box implementation of public-key cryptography is still in the preliminary stage, and its security analysis method is not complete. Our future work will focus on the definition and the security analysis of white-box public-key cryptography.
e inverse mappings of f i and g i , respectively T i (·, ·) Lookup tables constructed as in Table 1, 1 ≤ i ≤ t

Security and Communication Networks
Data Availability e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.