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

Zhou, Jie; Bai, Jian; Jiang, Meng Shan

doi:https://doi.org/10.1155/2020/8881116

Security and Communication Networks

On this page

Abstract Introduction Preliminaries Conclusions Appendix Data Availability Conflicts of Interest Acknowledgments References Copyright Related Articles

Research Article | Open Access

Volume 2020 | Article ID 8881116 | https://doi.org/10.1155/2020/8881116

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

Jie Zhou,¹Jian Bai,²and Meng Shan Jiang²

Academic Editor: Fulvio Valenza

Received07 Mar 2020

Revised20 Oct 2020

Accepted29 Oct 2020

Published19 Nov 2020

Abstract

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. The 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. The 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. The efficiency of the proposed scheme is compared with that of the classical ECDSA through experiments.

1. Introduction

1.1. 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. That 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. The 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.(2)Dynamic execution can be observed.(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. Thus, it is urgent to design cryptographic algorithms that can resist white-box attacks [5]. The 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.

1.2. 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 . The 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 . 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 . 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. They 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 . The 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. They 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 white-box 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.

1.3. Our Contributions

In this paper, we focus on a white-box 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. The 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.

The 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. The permutations are used in both the cloud side and the client side. The private key is confused in a series of lookup tables and is thus able to resist the white-box attack. (2) The storage size of the proposed schemes is reduced by the residue number system. The private key is divided into several small parts by the residue number system. The small part of the private key can be hidden by a smaller size of lookup tables. The storage needed by the proposed scheme is feasible. (3) The security of the proposed scheme is analyzed from aspects of an exhaustive search attack, a random number attack, and a code lifting attack. (4) The 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. The operation speed of the proposed scheme is also acceptable.

The 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. The 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.

2. Preliminaries

2.1. Classical ECDSA

ECDSA is a digital signature algorithm over an elliptic curve with the domain parameters , where is the order of field , is the field representation of elements in , and are the two coefficients used in an elliptic curve over (i.e., in the case of a prime field, and in the case of a binary field), has prime order , and is the cofactor. The user randomly selects an integer as the private key, and the corresponding public key is . The signature generation and verification of the classical ECDSA are as follows.(1)ECDSA signature generation Input: Domain parameters , private key , and message . Output: Signature .(1)Randomly select an integer .(2)Compute and convert to an integer .(3)Compute . If then go to (1).(4)Compute , where .(5)Compute , where is the hash value of the message .(6)Compute . If then go to (1).(7)Return the signature .(2)ECDSA signature verification Input: Domain parameters , public key , message , and the signature . Output: “Reject the signature” or “Accept the signature.”(1)Verify that and are integers in the interval . If any verification fails, then return “Reject the signature.”(2)Compute , where is the hash value of the message .(3)Compute , where .(4)Compute and .(5)Compute .(6)If , then return “Reject the signature.” Otherwise, convert to an integer and compute .(7)If then return “Accept the signature”; Else return “Reject the signature.”

2.2. Residue Number System

The 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 . The set is a basis of the RNS, and the elements in are called the RNS moduli. Any integer , , can be uniquely represented as , where is modulo , denoted as . Note that only when is not more than and not less than zero can be uniquely represented by the RNS with the basis . The original value of can be restored from by using the Chinese Remainder Theorem (CRT):where and .

Assume that integers and can be uniquely represented as and under the basis ; thenwhere .

All the operations of ECDSA are performed on the finite field . In the following, we transform the formulas on the finite field into the residue number system.(1)Assume the formulas are computed over the integers, that is, without the mod reduction. Let be the absolute maximum value generated by these operations.(2)Choose a basis of the RNS, where .(3)Represent every integer in RNS format based on the basis .(4)Compute the formula in RNS format, and let be the result.(5)Restore by the Chinese Remainder Theorem:.(6)Compute , and return .

Example. Compute , where and .(1)Since and , the absolute maximum value of .(2)Choose a basis of the RNS, where .(3)Represent as , and represent as .(4)Compute by equation (2).(5)Compute by equation (1).(6)Compute .

3. White-Box Implementation of ECDSA Based on the Residue Number System

3.1. Hide the Private Key

In the white-box attack context, attackers can completely access the implementation of ECDSA and know all the intermediate results of the algorithm. The attacker’s objective is to extract the private key or forge a legitimate signature. From the details of ECDSA above, we know that the user’s private key is used only in step (6) of the process of ECDSA signature generation. Hence, to protect the security of ECDSA under the white-box attack context, we need to protect only the security of private key during the procedure of computing:

Similar to most white-box cryptographic schemes, the private key in our scheme is hidden in lookup tables (see Table 1). Let be a basis of the RNS, let be the prime field with order , and the private key can be represented as , where . Let and be two permutations on ; and are the inverse mappings of and , respectively. An example of the table generation pseudocode is as follows: for to do for to do , end for; end for.

Note that the table hides not only part of the private key but also the permutations and . If the permutations and are unknown, the attackers cannot derive the private key by the input and output of table . Since , the storage space of table is less than bits. Moreover, the whole storage space of is less than bits.

3.2. Protect the Random Number

Attackers can obtain the final signature in the white-box attack context. To protect the private key , we also need to protect the random number used in the process of ECDSA signature generation. Otherwise, according to equation (3), the private key is easy to calculate by attackers. We use the “cloud plus side” mode to protect it. is decomposed into two parts, namely, and , where is generated by the client and is generated by the cloud server. In the step of signature generation, the inverse of needs to be sent to the client. In order to prevent attackers in the client recovering , we use a series of permutations to protect .

3.3. Our Scheme

In the following, we always assume that the cloud server is semihonest [37]. That 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 into a series of lookup tables . A trusted third party (TTP) is needed in the initialization phase (see Figure 1). The initialization phase is performed in a secure environment.

Initialization: Input: Private key . Output: A basis of the RNS {}, the permutations {} and {}, and the lookup tables {}.(1)Client sends the private key to TTP through a secure channel;(2)TTP randomly selects co-prime integers as a basis of the RNS, where ;(3)TTP randomly selects permutations and on , ;(4)TTP represents the private key as according to the basis , where ;(5)TTP constructs table as follows: where and are the inverse mappings of and , respectively, with , ;(6)TTP sends tables to client and sends permutations and to the cloud server through a secure channel. TTP then publishes the basis .

The white-box implementation of ECDSA based on the RNS is as follows (see Figure 2).

Signature generation: Input: Domain parameters , basis , and message . Output: Signature .(1)Client computes , where is the hash value of the message .(2)Client randomly selects an integer .(3)Client computes .(4)Client sends and to the cloud server.(5)Cloud server randomly selects an integer .(6)Cloud server computes and converts to an integer .(7)Cloud server computes the first part of the signature . If , then go to (2).(8)Cloud server computes , where .(9)Cloud server computes .(10)Cloud server represents under the basis as and confuses by permutation , i.e., . Similarly, cloud server represents under the basis as and confuses by permutation , i.e., .(11)Cloud server sends , , , , , , to client.(12)Client computes by looking up table , where the input of table is and the output of table is , where , .(13)Client restores by Chinese Remainder Theorem.(14)Client computes , where .(15)Client computes the second part of the signature . If , then go to (2).(16)Client returns the signature .

From the above steps, the private key does not appear in plaintext. If the basis and permutations and are fixed, then tables correspond to the private key are fixed. Tables are completely presented by the client, so attackers on the cloud server cannot directly obtain any information about the private key .

Let ; then, . 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 . If , then . We claim that . Since , . Note that the basis satisfies . Using RNS theory, we can restore by , where , , , and , with . Sincethen .)

Thus, the result of the white-box implementation of ECDSA signature generation is consistent with the result 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 .

4. Security Analysis

4.1. The 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. The goal of attackers is to extract the private key . The security of our scheme is based on the difficulty of the discrete logarithm problem for elliptic curves (ECDLP) and the diversity of permutations.

4.1.1. The Security in the Cloud Server

From the details of our scheme, attackers in the cloud server can obtain the information of , , , , and . Moreover, the following equation holds:

If attackers can obtain the value of , they can extract the private key from equation (6). Fortunately, because of the difficulty of the elliptic curve discrete logarithm, attackers cannot calculate by .

4.1.2. The Security in the Client

From the details of our scheme, attackers in the client can obtain the information of , , , , , , , , , , and . There seem to be two ways for attackers to compute the private key: (i) from tables and (ii) from equation (6).

In case (i), table is constructed bywhere . After the initialization phase, the key and permutations and are hidden in . Since the permutations and are unknown to the client, attackers in the client cannot derive the key from table directly. The diversity of permutation (or ) is . Hence, the complexity of deriving is through an exhaustive search attack. The computational complexity of extracting the private key from case (i) is .

In case (ii), if attackers can obtain the value of , they can extract the private key from equation (6). For the client, the information of is hidden in , , , , , , where and . Since the permutations are unknown to the client, the complexity of deriving is through an exhaustive search attack. The computational complexity of extracting the private key from case (ii) is .

Remark. The proposed scheme is a kind of cloud collaboration. The secret key is stored completely in the client in a form of lookup table. The attackers in the client cannot get the plaintext information of the key from the lookup table. 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.

4.2. Random Number Attack

In the classical ECDSA, the random integer must be different for different messages. Assume that, for different messages and , we select the same random integer to sign. Then, we have

Thus, . Usually, the information of , , , and is public; thus, attackers can easily obtain the information of the private key .

In the white-box implementation of ECDSA, the random integers and are generated by the client and cloud server, respectively. For two messages and , assume that and are used to compute the signature of and that and are used to compute the signature of . Then, we have

Under the white-box attack context, the attackers in the client can obtain the information of , , , , , and , and the attackers in the cloud server can obtain the information of , , , , , and . We analyze the security of private key in the following four cases:(i), : From equation (9), we have . Thus, attackers in the client or the cloud server can derive the private key under the white-box attack context.(ii), : From equation (9), we have . Thus, attackers in the cloud server can derive the private key under the white-box attack context.(iii), : From equation (9), we have . Thus, attackers in the client can derive the private key under the white-box attack context.(iv), :Regardless of whether the attackers are in the client or the cloud server, they cannot simultaneously obtain the information of , , , and . Thus, attackers cannot obtain the information of private key from equation (9) under the white-box attack context.

In summary, the random integers and used in our scheme must be different for different messages.

4.3. 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. The 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 in the initialization phase and (ii) step (13) in the signature generation phase.(i)The new lookup tables contain not only the private key but also the unique identification information of the device , where . The new lookup table is constructed as follows: where , , and .(ii)The new step (13) is as follows: client restores by Chinese Remainder Theorem and computes .

It is easy to check the correctness of the new scheme. The HI is hidden in lookup tables . For each signature, the HI must be correctly extracted from the device. Through the hardware binding method, the code lifting attack can be mitigated in the white-box implementation of ECDSA.

5. Performance Evaluation

In this section, we analyze the performance of our proposed scheme and compare it with the classical ECDSA [31]. The 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.

The domain parameters on the elliptic curve , and the basis of RNS are shown in Table 2. The 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. The 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. The user’s private key is not often replaced in the actual application scenario, so the time of initialization is acceptable. The 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. The 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.

6. 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. The proposed techniques can be extended to Schnorr signatures [38] or other ElGamal-based schemes [39]. The 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.

Appendix

The following Table 5 lists the symbols used in this article.

Data Availability

The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported in part by the National Key Research and Development Program under China Grant 2017YFC0801004.

References

Y. Shi, X. Wang, and H. Fan, “Light-weight white-box encryption scheme with random padding for wearable consumer electronic devices,” IEEE Transactions on Consumer Electronics, vol. 63, no. 1, pp. 44–52, 2017.
View at: Publisher Site | Google Scholar
S. Chow, P. Eisen, H. Johnson, and P. C. Van Oorschot, “White-box cryptography and an AES implementation,” in SAC 2002, Lecture Notes in Computer Science, vol. 2595, pp. 250–270, Springer, Berlin, Germany, 2002.
View at: Google Scholar
Z. Xiao and Y. Xiao, “Security and privacy in cloud computing,” IEEE Communications Surveys & Tutorials, vol. 15, no. 2, pp. 843–859, 2013.
View at: Publisher Site | Google Scholar
Y. Law, R. Corin, S. Etalle, and P. Hartel, “A formally verified decentralized key management architecture for wireless sensor networks,” in PWC 2003, Lecture Notes in Computer Science, vol. 2775, pp. 27–39, Springer, Berlin, Germany, 2003.
View at: Google Scholar
M. Beunardeau, A. Connolly, R. Géraud, and D. Naccache, “White-box cryptography: security in an insecure environment,” IEEE Security & Privacy, vol. 14, no. 5, pp. 88–92, 2016.
View at: Publisher Site | Google Scholar
O. Billet, H. Gilbert, and C. Ech-Chatbi, “Cryptanalysis of a white box AES implementation,” in SAC 2004, Lecture Notes in Computer Science, vol. 3357, pp. 227–240, Springer, Berlin, Germany, 2004.
View at: Google Scholar
J. Bringer, H. Chabanne, and E. Dottax, “White box cryptography: another attempt,” Cryptology ePrint Archive, Report 2006/468, 2006, http://eprint.iacr.org/2006/468.
View at: Google Scholar
Y. D. Mulder, B. Wyseur, and B. Preneel, “Cryptanalysis of a perturbated white-box AES implementation,” in INDOCRYPT 2010, Lecture Notes in Computer Science, vol. 6498, pp. 292–310, Springer, Berlin, Germany, 2010.
View at: Google Scholar
Y. Xiao and X. Lai, “A secure implementation of white-box AES,” in Proceedings of the 2nd International Conference on Computer Science and its Applications, pp. 1–6, Jeju, South Korea, December 2009.
View at: Publisher Site | Google Scholar
Y. D. Mulder, P. Roelse, and B. Preneel, “Cryptanalysis of the Xiao-Lai white-box AES implementation,” in SAC 2012, Lecture Notes in Computer Science, vol. 7707, pp. 34–49, Springer, Berlin, Germany, 2012.
View at: Google Scholar
T. Xu, F. Liu, and C. Wu, “A white-box AES-like implementation based on key-dependent substitution-linear transformations,” Multimedia Tools and Applications, vol. 77, no. 14, pp. 18117–18137, 2017.
View at: Publisher Site | Google Scholar
R. Luo, X. Lai, and R. You, “A new attempt of white-box AES implementation,” in Proceedings of the International Conference on Security, Pattern Analysis, and Cybernetics, pp. 423–429, Wuhan, China, October 2014.
View at: Google Scholar
K. Bai, C. K. Wu, and Z. Zhang, “Protect white-box AES to resist table composition attacks,” IET Information Security, vol. 12, no. 4, pp. 305–313, 2018.
View at: Publisher Site | Google Scholar
S. Chow, P. Eisen, H. Johnson, and P. C. Van Oorschot, “A white-box DES implementation for DRM applications,” in DRM 2002, Lecture Notes in Computer Science, vol. 2696, pp. 1–15, Springer, Berlin, Germany, 2002.
View at: Google Scholar
M. Jacob, D. Boneh, and E. W. Felten, “Attacking an obfuscated cipher by injecting faults,” in DRM 2002, Lecture Notes in Computer Science, vol. 2696, pp. 16–31, Springer, Berlin, Germany, 2002.
View at: Google Scholar
H. Link and W. Neumann, “Clarifying obfuscation: improving the Security of White-Box DES,” in Proceedings of the ITCC’05, pp. 679–684, Las Vegas, NV, USA, April 2005.
View at: Google Scholar
L. Goubin, J.-M. Masereel, and M. Quisquater, “Cryptanalysis of white box DES implementations,” in SAC 2007, Lecture Notes in Computer Science, vol. 4876, pp. 278–295, Springer, Berlin, Germany, 2007.
View at: Google Scholar
B. Wyseur, W. Michiels, P. Gorissen, and B. Preneel, “Cryptanalysis of white-box DES implementations with arbitrary external encodings,” in SAC 2007, Lecture Notes in Computer Science, vol. 4876, pp. 264–277, Springer, Berlin, Germany, 2007.
View at: Google Scholar
A. Amadori, W. Michiels, and P. Roelse, “A DFA attack on white-box implementations of AES with external encodings,” in SAC 2019, Lecture Notes in Computer Science, vol. 11959, pp. 591–617, Springer, Berlin, Germany, 2020.
View at: Google Scholar
T. Lin, H. Yan, X. Lai, and W. Qiu, “Several methods for constructing white-box solutions,” Journal of Physics: Conference Series, vol. 1288, Article ID 012005, 2019.
View at: Publisher Site | Google Scholar
A. Biryukov, C. Bouillaguet, and D. Khovratovich, “Cryptographic schemes based on the ASASA structure: block-box, white-box, and public-key (extended abstract),” in ASIACRYPT 2014, Lecture Notes in Computer Science, vol. 8873, pp. 63–84, Springer, Berlin, Germany, 2014.
View at: Google Scholar
H. Gilbert, J. Plüt, and J. Treger, “Key-Recovery attack on the ASASA cryptosystem with expanding S-boxes,” in CRYPTO 2015, Lecture Notes in Computer Science, vol. 9215, pp. 475–490, Springer, Berlin, Germany, 2015.
View at: Google Scholar
B. Minaud, P. Derbez, P.-A. Fouque, and P. Karpman, “Key-recovery attacks on ASASA,” Journal of Cryptology, vol. 31, no. 3, pp. 845–884, 2018.
View at: Publisher Site | Google Scholar
J. Kwon, B. Lee, J. Lee, and D. Moon, “FPL: White-box secure block cipher using parallel table look-ups,” in CT-RSA 2020, Lecture Notes in Computer Science, vol. 12006, pp. 106–128, Springer, Berlin, Germany, 2020.
View at: Google Scholar
E. Alpirez Bock, A. Amadori, C. Brzuska, and W. Michiels, “On the security goals of white-box cryptography,” IACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2020, no. 2, pp. 327–357, 2020.
View at: Google Scholar
Y. Shi, W. Wei, F. Zhang et al., “SDSRS: a novel white-box cryptography scheme for securing embedded devices in IIoT,” IEEE Transactions on Industrial Informatics, vol. 16, no. 3, pp. 1602–1616, 2019.
View at: Google Scholar
Y. Zhang, D. He, X. Huang, D. Wang, and k. R. Choo, “White-box implementation of the identity-based signature scheme in the IEEE P1363 standard for public key cryptography,” 2018, Cryptology ePrint Archive: Report 2018/814.
View at: Google Scholar
Q. Feng, D. He, H. Wang, N. Kumar, and K.-K. R. Choo, “White-box implementation of Shamir’s identity-based signature scheme,” IEEE Systems Journal, vol. 14, no. 2, p. 1820, 2020.
View at: Publisher Site | Google Scholar
D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature algorithm (ECDSA),” International Journal of Information Security, vol. 1, no. 1, pp. 36–63, 2001.
View at: Publisher Site | Google Scholar
ISO, Information Technology-Security Techniques-Digital Sigantures with Appendix-Part 3: Certificate Based Mechanisms, ISO/IEC 14888-3, 1998, ISO–International Organization of Standards, Geneva, Switzerland.
American National Standards Institute, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), ANSI X9.62, American National Standards Institute, New York, NY, USA, 1999.
Institute of Electrical and Electronics Engineers, Standard Specifications for Public Key Cryptography, IEEE Std 1363-2000, Institute of Electrical and Electronics Engineers, Piscataway, NJ, USA, 2000.
National Institute of Standards and Technology, Digital Signature Standard, FIPS 186-2, National Institute of Standards and Technology, Gaithersburg, MD, USA, 2000.
H. L. Garner, “The residue number system,” in Proceedings of the IRE-AIEE-ACM’59, pp. 146–153, San Francisco, CA, USA, March 1959.
View at: Google Scholar
W. Jenkins and B. Leon, “The use of residue number systems in the design of finite impulse response digital filters,” IEEE Transactions on Circuits and Systems, vol. 24, no. 4, pp. 191–201, 1977.
View at: Publisher Site | Google Scholar
K. B. Sudeepa and G. Aithal, “Generation of maximum length non-binary key sequence and its application for stream cipher based on residue number system,” Journal of Computational Science, vol. 21, pp. 379–386, 2017.
View at: Publisher Site | Google Scholar
Q. Chai and G. Gong, “Verifiable symmetric searchable encryption for semi-honest-but-curious cloud servers,” in Proceedings of the ICC 2012, vol. 922, p. 917–, Ottawa, Canada, June 2012.
View at: Google Scholar
C. P. Schnorr, “Efficient signature generation by smart cards,” Journal of Cryptology, vol. 4, no. 3, pp. 161–174, 1991.
View at: Publisher Site | Google Scholar
T. Elgamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” IEEE Transactions on Information Theory, vol. 31, no. 4, pp. 469–472, 1985.
View at: Publisher Site | Google Scholar

Copyright

Copyright © 2020 Jie Zhou et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Views

1187

Downloads

845

Citations