Mitigating Randomness Leakage in SM2 White-Box Implementations via Trusted Execution Environments

Abstract

White-box cryptography plays a vital role in untrusted environments where attackers can fully access the execution process and potentially expose cryptographic keys. It secures keys by embedding them within complex and obfuscated transformations, such as lookup tables and algebraic manipulations. However, existing white-box protection schemes for SM2 signatures face vulnerabilities, notably random number leakage, which compromises key security and diminishes overall effectiveness. This paper proposes an improved white-box implementation of the SM2 signature computation leveraging a Trusted Execution Environment (TEE) architecture. The scheme employs three substitution tables for SM2 key generation and signature processes, orchestrated by a random bit string k. The k value and lookup operations are securely isolated within the TEE, effectively mitigating the risk of k leakage and enhancing overall security. Experimental results show our scheme enhances security, reduces storage, and improves performance over standard SM2 signature processing, validating its efficacy with TEE and substitution tables in untrusted environments.

1. Introduction

With the continuous development of Internet technology, the means of network confrontation have become increasingly diverse and complex, leading to frequent large-scale cybersecurity incidents that cause serious economic losses and adverse social impacts. Ensuring data security, particularly the personal data and privacy of Internet users, has become a top priority for China’s cyberspace security protection. Cryptography plays a pivotal role in protecting privacy and personal data. Modern cryptography requires that, even when the algorithm structure is known to the attacker, the cryptographic algorithm can ensure the attacker cannot distinguish between the encrypted ciphertext and a random number by the secret key used, typically a 128-bit random number. Therefore, the primary goal of an attacker is to recover the key used in the cryptographic algorithm.

Traditionally, cryptographic algorithms operate in secure environments known as the black-box model, where attackers can only control the inputs and outputs but cannot access the intermediate states of the algorithm. However, in Internet applications, the deployment environment has evolved from dedicated encryption machines to insecure devices such as personal mobile phones, computers, and home set-top boxes, which cannot provide a secure encryption environment. To address this, Chow et al. proposed the white-box cryptography model in 2002 [1], where cryptographic algorithms are designed to prevent attackers from isolating the key, even when the attacker has full access to the algorithm’s internals.

This paper proposes a new white-box implementation of the SM2 public-key cryptographic algorithm (WBSM2) to enhance key security in untrusted environments. The scheme fully integrates a Trusted Execution Environment (TEE) to securely generate the random value and perform all associated lookup table operations, including those for parameters, ensuring complete isolation of sensitive computations. By utilizing elliptic curve public key algorithms to generate parameters and employing mathematical transformations to construct encrypted and obfuscated lookup tables within the TEE, the private key remains effectively hidden. This design mitigates white-box attacks by isolating critical computations, ensuring that even if attackers gain access to other system components, the private key cannot be compromised. The specific process of white-box protection involves both the signer and the verifier, providing end-to-end security for the private key. Experimental results demonstrate that this scheme delivers enhanced security, reduced storage requirements, and better performance compared to the standard SM2 algorithm.

To address the issue of random number attacks, the scheme employs a TEE-based random number protection mechanism that ensures the secure generation and handling of random values. This is achieved through the use of secure memory environments and protected execution of random number generation operations. By fully isolating these processes within the TEE, the scheme prevents attackers from gaining access to random values or exploiting them to derive the private key.

The key innovations of this paper are as follows:

(1)

TEE-Based Random Number Protection Mechanism: A robust approach is designed to secure the generation and handling of random numbers within the TEE, leveraging secure memory environments and protected instructions to prevent attackers from inferring the private key.

(2)

Affine Transform Coding-Based Lookup Table Scheme: To improve performance under the white-box model, we propose a scheme that uses affine transform coding to create efficient and space-saving lookup tables, enhancing the performance of the SM2 white-box method and preventing key extraction by attackers.

(3)

Effective Experimental Validation: Comprehensive tests evaluated our SM2 white-box method in real-world applications, focusing on signature and verification times across various platforms. Compared to the standard SM2 implementation, our method maintains practical performance, with signature times 2–3 times longer and verification times about twice as long. Security assessments confirmed the robustness of our method, ensuring the protection of the private key and improving computational performance compared to existing SM2 white-box algorithms.

2. Threat Model

The white-box attack model assumes that an adversary has complete access to the implementation details of a cryptographic system, including source code, runtime memory, execution flow, and all operations involving cryptographic keys. This assumption, as initially defined by Chow et al. [1,2] in their seminal works on white-box cryptography for AES and DES implementations, is commonly used to evaluate the robustness of cryptographic designs under extreme conditions, ensuring their resistance to the theoretically strongest possible attacks. Xiong Jiang et al. proposed an SM2 white-box protection scheme based on space hardness that offers strong theoretical security [3]. However, it relies on large lookup tables and intricate obfuscation techniques, leading to substantial performance and storage overhead. In practice, the high cost of meeting the requirements of this model often makes it impractical, especially in resource-constrained environments.

To address these limitations, we introduce a degraded white-box threat model that balances security with implementation efficiency, drawing on an approach similar to those proposed in the works of Mo [4] and Zhang [5].

Defender’s Goal: This model assumes that attackers have complete control over the Rich Execution Environment (REE), including the ability to monitor runtime memory, use debugging tools, and modify system software, while being unable to access the TEE hardware or its protected memory regions. Leveraging TEE’s isolation capabilities, the proposed protection mechanism achieves efficient and practical security in real-world scenarios.

Defender/Adversary’s Capability: The TEE is defined as a secure enclave within an otherwise untrusted environment, ensuring that data, code, and computations within it remain secure. Although potential side-channel attacks targeting TEE could compromise sensitive data, these are beyond the scope of this study. All sensitive computations in the signing process are performed within the TEE, which ensures that the random number k is never directly output. Instead, the TEE computes an intermediate value $\left(x_1,y_1\right)$ and $s_1$ derived from k. Importantly, these calculations are irreversible, preventing k from being recovered. This design guarantees that even if an attacker gains complete control over the REE, they cannot obtain k by intercepting data transmissions between the TEE and the REE.

3. Related Work

The concept of the white-box attack environment was first proposed by Chow et al. at the beginning of this century [2]. In a white-box environment, attackers have complete control over and access to information on IoT devices [6], allowing for them to use static analysis, dynamic debugging, and other techniques to extract cryptographic keys, leading to information leakage. White-box protection involves transforming traditional cryptographic algorithms into white-box cryptographic algorithms by obfuscating the key and algorithmic logic, making it difficult for attackers to obtain the key or algorithm implementation details. Specifically, this involves taking an existing cryptographic algorithm under the black-box model and implementing it securely in a white-box model, ensuring it can resist attacks even when the attacker has extensive capabilities.

In 2002, Chow et al. developed a lookup table-based white-box implementation for block ciphers, successfully applying it to AES [1] and DES [2]. However, subsequent research revealed that Chow’s scheme could not secure the embedded key against specific attacks, and effective attack methods on Chow’s white-box DES were proposed in the literature [7,8,9]. Bringer, Chabanne, and Dottax introduced perturbations to a variant of AES [10], while Xiao and Lai proposed a scheme based on larger linear encoding [11]. Karroumi suggested improving white-box AES using AES pairwise ciphers [12]. Bogdanov et al. introduced the SPACE cipher, a new type of block cipher designed for white-box environments based on a multi-subdivided target-heavy generalized Feistel structure [13].

Traditional cryptographic white-boxing disperses or transforms the key through substitution, scrambling, and obfuscation, allowing for the transformed key to be directly involved in algorithmic operations without needing to recover the key.

Current research on white-box cryptography primarily focuses on symmetric cryptography. Public-key cryptography, which typically requires large-scale mathematical computations, presents significant challenges for white-box design, resulting in limited research in this area.

In 2011, Lepoint published a white-box implementation of RSA, but it required excessive storage space. In 2015, Jan Hoogerbrugge and Wil Michiels applied for a patent on a white-box implementation of the RSA algorithm [14]. In 2017, Jian Bai, Jie Zhou, et al. proposed a white-box digital signature implementation of SM2 based on the residue number system [15] and a white-box implementation of the SM2 encryption and decryption algorithm based on the residue number system [9]. These methods use lookup table construction to protect the key and the residue theorem to reduce the lookup table’s construction space. Established methods such as space-hardness-based white-box implementations of SM2 occupy significant memory space and perform poorly. Attackers can observe memory or other control schemes to perform random number attacks in a white-box environment. Existing SM2 white-box implementation methods tend to overlook code-level security issues and are susceptible to reverse analysis.

In contrast, the scheme proposed in this paper achieves white-box protection in lightweight IoT devices. It includes functionalities for signing and verifying signatures using the SM2 algorithm, ensuring strong security. The white-box protection of the SM2 private key is achieved by introducing a TEE-based random number protection scheme and a lookup table-based key hiding scheme, resisting white-box attacks on the signature process. During signing, the signer uses TEE-generated random numbers and the lookup table for signing. TEEs have become widely used in confidential computing [16,17]. These technologies ensure secure execution even in compromised environments and are crucial for protecting sensitive data during processing [18,19]. However, there are still significant challenges in securing TEE implementations, particularly regarding memory encryption and side-channel attacks [20,21]. During verification, the signer uses the generated lookup table for verification. Throughout the process, there is no leakage of the private key, and attackers cannot obtain the private key through white-box attacks. This dual protection at both hardware and software levels significantly enhances security performance.

4. Preliminaries

4.1. White-Box Cryptography

In traditional cryptography, it is assumed that the operating environment of cryptographic algorithms is secure, with attackers only able to access the input and output of these algorithms. However, with advances in computer technology, access to sensitive information has increased, leading to more severe network security threats. As a result, cryptographic algorithms face increasing risks.

The concept of white-box attacks was first proposed by Chow et al. in 2002 [1,2]. Here, the term “white-box” is analogous to the “white-box testing” used in software testing, where the attacker has complete control over the device terminal (i.e., the environment in which the application runs). In a white-box attack, the attacker has the same privileges as the software executor, allowing for them to perform any operation on the endpoint, with far fewer limitations compared to the traditional black-box model.

White-box attacks represent a more advanced security threat in untrusted endpoint environments. Traditional cryptographic algorithms are highly vulnerable and cannot be used securely in a white-box attack environment. Therefore, to ensure the secure use of cryptographic functions such as encryption, decryption, and authentication in untrusted terminals, it is crucial to develop cryptographic algorithms that can maintain security in white-box attack environments [22,23].

We refer to cryptographic algorithms and their implementations that can resist white-box attacks as white-box ciphers. These include white-box implementations of existing cryptographic algorithms and entirely new white-box cryptographic algorithms. The white-box implementation of existing cryptographic algorithms involves redesigning known algorithms to ensure their security remains intact in a white-box attack environment, without altering their original functionality. For instance, encryption algorithms aim to protect their keys from leakage, while signature algorithms strive to prevent forgery. Conversely, white-box cryptographic algorithms are new designs that inherently resist attacks in a white-box environment, rather than applying white-box security measures to existing algorithms.

Currently, most examples of white-box cryptography focus on the white-box implementation of known cryptographic algorithms, such as white-box AES and white-box DES. Designers often use obfuscation techniques to construct lookup tables that perform the algorithm’s operations. Even if a white-box attacker can observe the entire lookup table, they cannot extract the key information faster than by exhaustive search. However, this approach has proven to be inadequate.

White-box cryptography is a novel area of cryptographic research that challenges traditional assumptions about an attacker’s capabilities, aligning more closely with real-world security threats. Both theoretically and practically, white-box cryptography and its unique characteristics have significant and broad application prospects and are poised to substantially impact the field of cryptography.

4.2. SM2 Algorithm

The SM2 elliptic curve public key cryptography algorithm is based on the elliptic curve multiplicative point operation one-way function, utilizing a key length of 256 bits. This algorithm supports data encryption, digital signatures, and key exchange protocols. Compared to the RSA algorithm, SM2 offers the same security strength with shorter keys and faster computation speeds [24]. It is widely used in information system identification, network communication key exchange, electronic seal digital signatures, and trusted computing [25].

The equation of the elliptic curve used in SM2 is in the form $y^2=x^3+ax+b$, as shown in Figure 1. In this two-dimensional space, the horizontal axis represents $x$, and the vertical axis represents $y$. Point A on the elliptic curve is denoted as $(x_A,y_A)$. According to the definition of multiple points on the elliptic curve, 2A is the point where the tangent at A intersects the curve again, and 3A is the sum of 2A and A. For a positive integer k, the point $Q=\left[k\right]A=A+A+\cdots +A$.

The coordinate system shown in Figure 1 uses real numbers, but points on the elliptic curve are usually kept as integers. An elliptic curve defined over the prime field $F_p$ consists of p elements in {0, 1, 2, …, p − 1}, where p is a prime number. The set of points on the elliptic curve is denoted as $E\left(F_p\right)=\left\{\right(x,y)\mid x,$y ∈ $F_p{ \mathrm{a}\mathrm{n}\mathrm{d} y}^2=x^3+ax+b$}$\cup${O}, where O is the point at infinity. The relevant parameters of the SM2 system over the field $F_p$ are public and must be openly shared, meeting the following conditions:

• The characteristic p of $F_p$, p is is a 256-bit prime number.
• Elements a and b in $F_p$ satisfy the curve equation $y^2=x^3+ax+b$, with $4a^3+27b^2\ne 0$.
• The base point $G=(x_G,y_G)\in E\left(F_p\right)$ is not the point at infinity.
• The order of the base point $G$ in $E\left(F_q\right)$ is a 256-bit prime number.

Once these conditions are met, the elliptic curve system parameters are determined, and the elliptic curve discrete logarithm problem (ECDLP) is established. To construct the one-way function, k is chosen such that Q = [k]G. Solving for k in this context is the ECDLP, which has exponential computational complexity, making it significantly harder to solve than problems like integer factorization or the discrete logarithm problem over a finite field. Therefore, elliptic curve cryptography requires smaller key sizes compared to other cryptographic systems.

The SM2 digital signature algorithm involves four main components: system parameter generation, key generation, signature generation, and signature verification.

System parameter generation: Input a security parameter λ, and output elliptic curve parameters T = ⟨P, a, b, G, n, h⟩, where P is a prime number greater than 3, defining the finite field $F_p$ = {0, 1, …, P − 1}. Parameters a and b define the elliptic curve equation $y^2\equiv x^3+a\cdot x+bmodp$. The base point $G=\left(x_G,y_G\right)$ generates a cyclic subgroup on the curve, and n is the order of G. The cofactor h is N/n, where N is the order of the elliptic curve.

Key generation: The signer A generates a private key $d_A$ and computes the public key $P_A=\left(x_A,y_A\right)=\left[d_A\right]G$.

Signature generation: Given a message M, A converts the identifier to a 2-byte string ENTL_A and hashes the concatenated identity information and elliptic curve parameters to produce $Z_A=H_{256}\left({\mathrm{E}\mathrm{N}\mathrm{T}\mathrm{L}}_A\parallel {\mathrm{I}\mathrm{D}}_A\parallel a\parallel b\parallel x_G\parallel y_G\parallel x_A\parallel y_A\right)$. The message $\overline{M}$ is $Z_A\mid \mid M$, and the message digest $e=H_{256}(\overline{M})$. Randomly select $u\in Z_n^{\mathrm{*}}$ and compute

$$\left(x_1,y_1\right)=\left[u\right]G,$$

(1)

Calculate

$$r=\left(e+x_1\right) mod n,$$

(2)

$$s=(\left(1+d_A{)}^{-1}\cdot \left(k-r\cdot d_A\right)\right) mod n,$$

(3)

Signature verification: The verifier B checks if $r^{\prime },s^{\prime }\in Z_n^{\mathrm{*}}$. If not, the verification fails. Otherwise, compute $\overline{M^{\prime }}=Z_A\mid \mid M^{\prime }$ and the digest $e^{\prime }=H_{256}\left({\overline{M}}^{\prime }\right)$. Calculate $\mathrm{t}=(r^{\prime }+s^{\prime })modn$, $(x_1^{\prime },y_1^{\prime })=\left[s^{\prime }\right]G+\left[t\right]P_A$, and $R=(e^{\prime }+x_1^{\prime })modn$. If $R=r^{\prime }$, the signature is valid; otherwise, it fails [26].

4.3. TEE

The Trusted Execution Environment (TEE) is a secure, integrity-protected processing environment comprising processing, memory, and storage functions [27]. It is isolated from the “normal” processing environment, known as the Rich Execution Environment (REE), where the device’s operating system and applications run [28]. The first mobile phones with hardware-based TEEs appeared around a decade ago, and today, nearly every smartphone and tablet includes a TEE, such as the ARM TrustZone [29]. By partitioning REE applications and services, TEEs enhance security and availability by confining sensitive operations and data to the TEE, ensuring that sensitive data never leave this secure environment.

The TEE operates on a separate kernel and provides a tamper-proof processing environment. It guarantees the authenticity of the executed code, the integrity of the runtime state (e.g., CPU registers, memory, and sensitive I/O), and the confidentiality of the code, data, and runtime state stored on persistent memory. Additionally, it offers remote attestation of its trustworthiness to third parties. The content of the TEE is not static and can be securely updated. It is resistant to software attacks and physical attacks on the system’s main memory, and it prevents exploitation of backdoor security vulnerabilities. Figure 2 illustrates a device as a series of different environments, each with its functions and services.

A Trusted Application (TA) is an application encapsulating security-critical functionality running in a TEE. It can be a service-style application providing generic functionality (e.g., a generic cryptographic keystore) or designed to offload specific parts of an application running in the REE, such as a part of a client state machine in a security protocol like TLS. A Client Application (CA) is a common application (e.g., a browser or email client) running in the REE, responsible for most of the application’s functionality. The CA can call the TA to offload sensitive operations [30]. For instance, the TA can be used to decrypt a protected media stream and make the decrypted content directly available to the graphics hardware responsible for rendering and displaying the stream.

In recent years, several different Trusted Execution Environments (TEEs) have been proposed, each with varying capabilities. For instance, Intel’s SGX (Software Guard Extensions) offers memory encryption and ensures that sensitive data are protected even from privileged software, including the operating system and hypervisor. Similarly, AMD’s Secure Encrypted Virtualization (SEV) and Intel’s Total Memory Encryption (TDX) provide advanced memory encryption capabilities that enhance the security of virtualized environments. These TEEs are designed to secure not only the code execution but also the data during processing, thereby protecting sensitive information from unauthorized access even if the operating system is compromised. However, these features were not covered in the original submission, and we now discuss their potential impact on the security of white-box cryptographic systems integrated with TEEs.

5. Methodology

5.1. Overall Framework

As shown in Figure 3, in the signing phase, the proposed white-box design based on the SM2 algorithm fully utilizes the Trusted Execution Environment (TEE) to securely generate the random number $k$ and perform all associated lookup table operations. Specifically, the lookup tables $T_1$ and $T_2$, are used within the TEE, ensuring that sensitive computations remain isolated from untrusted components. These lookup tables, created using affine transformations, effectively conceal the secret information $d_A$ and $k$, thwarting brute-force and reverse-engineering attacks. During the signing process, the TEE integrates the random number $k$ with the private key to compute the signature $\left(r,s^{\prime }\right)$ while maintaining end-to-end security.

In the verification phase, the verification-related lookup table $T_4$ is employed to validate the signature. This table is also constructed using affine transformations to protect critical parameters. The process ensures that even if an attacker gains access to intermediate computations outside the TEE, the private key and random number remain secure. The overall design enhances security through hardware-based isolation and efficient lookup table mechanisms, making it robust against white-box attacks.

5.2. TEE-Based Random Number Protection

The random numbers generated within the TEE leverage hardware-based entropy sources, such as jitter in oscillator circuits and thermal noise, which are inherently resistant to external manipulation or prediction. These entropy sources ensure a high degree of randomness, validated through compliance with industry standards such as the NIST SP 800-90A/B/C guidelines for random number generation. To further enhance unpredictability, the TEE employs secure post-processing techniques, including whitening algorithms and cryptographic hash functions, to remove any residual bias or correlation.

The TEE-based random number protection primarily secures the random numbers generated in the SM2 algorithm. It does this by first creating a secure memory environment through page table protection, and second, by using a random instruction protection scheme to safeguard functions related to the random number generation process. This dual approach prevents attackers from reverse engineering the random number generation process and using parameters obtained during the SM2 signature-signing process, along with the random number k, to calculate the user’s SM2 private key, thus ensuring the security of random numbers.

The protection flow within the TEE, as shown in Figure 4, is divided into three parts: secure memory initialization, page table request forwarding, and page table data modification.

• Secure Memory Initialization: The secure memory management module initializes the safety attributes of the secure memory. It first calculates the size of the required secure memory based on the physical memory size, requests the corresponding memory, and sets this memory to secure attributes—readable and writable in the secure world, and read-only in the non-secure world—via the TZC controller.
• Page Table Request Forwarding: When the kernel modifies the page table data, the page table protection module intercepts the corresponding page table operation. It analyzes the specific type of the kernel’s operation on the page table (requesting, releasing, or modifying) and the page table address. The kernel layer in the non-secure world sends the type of page table operation and the page table address to the secure world through SMC calls.
• Page Table Data Modification: Upon receiving the forwarded page table request, the secure world first verifies the legitimacy of the request. It then simulates the execution of the operation corresponding to the legitimate page table request. The page table protection module modifies the page table data in the secure memory by calling the appropriate interface of the security management module.

5.3. Lookup Table Based Key Hiding

For the SM2 digital signature algorithm, the private key is protected using white-box cryptography. First, the basic parameters of the SM2 elliptic curve public key cryptography algorithm are constructed to create the signature parameter table and verification parameter table. The signature parameter is then used to sign the message, and the verification parameter is used to verify the message and its signature. In a white-box environment, where the attacker has full control over the encryption algorithm and the ciphertext, the key remains secure. This is achieved by combining the encryption algorithm with the key within a lookup table, making it difficult for attackers to extract key information. The primary strategy of the lookup table approach is to employ obfuscation techniques to conceal the key information, ensuring that it is not exposed during the execution of the cryptographic algorithm. In this section, we describe the process of creating the lookup tables for hiding the private key in the SM2 white-box implementation. We use affine transformation coding and random number generation to securely obfuscate the private key.

5.3.1. Lookup Table Generation

To create the lookup tables, we utilize affine transformation coding, where the base parameters are derived from the SM2 elliptic curve cryptography algorithm. Specifically, the first step involves generating three parameter tables: $T_1,T_2, \mathrm{and} T_3$, which contain elliptic curve points and their corresponding transformations. The key parameters used for generating the lookup tables include the elliptic curve parameters $G=\left(x_G,y_G\right)$, the base point of the elliptic curve, and the private signing key $d_A$. The table generation process is based on the following steps:

• Affine Transformation: The tables $T_1$ and $T_2$ are generated by applying affine transformations on the elliptic curve points. Each row of these tables contains a point $\left[u_i\right]\cdot G$ and its corresponding transformation, where $u_i$ is a random number generated for each row. The affine transformations used to generate the lookup tables are defined by the following general form:

  $${ T}_i=A\cdot X+B$$

  (4)

  where $T_i$ is the transformed point, A is a matrix for linear transformation, $X$ is the original point, and B is a translation vector. The affine transformation is applied to elliptic curve points $\left[u_i\right]\cdot G$, where $u_i$ is a randomly generated number, to create each row of the lookup tables $T_1 \mathrm{and} T_2$. These transformations are applied within the TEE to ensure that sensitive computations, including private key operations, remain secure and inaccessible to attackers.
• Random Number Generation: The random numbers $u_i$ are generated using the high-entropy random number generator within the Trusted Execution Environment (TEE). This ensures that the random numbers are difficult to predict or replicate by attackers. These numbers are used to populate the elliptic curve points in $T_1$ and $T_2$.
• Key Hiding Transformation: The third table $T_3$ is generated by applying a transformation that hides the private key $d_A$. This operation is performed outside the TEE, within the REE, to support efficient processing of less critical computations. The formula used to generate each entry in $T_3$ is

  $${ T}_3\left[i\right]=(1+d_A{)}^{-1}\cdot d_A\cdot 2^{i-1}+{\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{d}}_i$$

  (5)

  where ${\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{d}}_i$ is an independently generated random number. This transformation ensures that the private key is effectively hidden within the table, making it infeasible for attackers to extract the key from the table.

The basic parameters of the SM2 elliptic curve public key cryptographic algorithm include the number field $F_q$, the elliptic curve equation E, the SM2 elliptic curve base point $G=\left(X_G,Y_G\right)$, the order n of the base point G, the signing private key $d_A$, and the verifying public key $P_A=\left[d_A\right]\cdot G$.

Using these parameters and an additional parameter $\lambda$, the first signature parameter table $T_1$, the second signature parameter table $T_2$, the third signature parameter table $T_3$, and the verification parameter table $T_4$ are generated. After generating these tables, the private key $d_A$ is deleted. The parameter $\lambda$ represents the number of rows in the first and second signature parameter tables and should preferably be an integer greater than 2log(nN), where N is the upper bound on the number of messages that the signing private key may sign during its lifecycle.

The first signature parameter table $T_1$ has $\lambda$ rows, with the value of its ith row being $\left[u_i\right]\cdot G$, where i = 1, 2…$\lambda$, and $u_i$ is an independent uniform random number in $Z_n$. $Z_n$ is a residue class modulo n, and ∙ denotes pointwise multiplication in the elliptic curve group.

The second signature parameter table $T_2$ also has $\lambda$ rows, with the value of its ith row being $\left[{\left(1+d_A\right)}^{-1}\cdot u_i\right]$, where i = 1, 2…$\lambda$, and $u_1$,…$u_{\lambda }$ are the random numbers used in generating $T_1$.

The third signature parameter table $T_3$ has $l$ rows, where $l$ denotes the binary length of n. The value of its ith row is $\left[{\left(1+d_A\right)}^{-1}\cdot d_A\cdot 2^{i-1}+ran{d}_i\right]$, where i = 1, 2…$l$, and $ran{d}_i$ is an independent uniform random number in $Z_n$.

The verification parameter table $T_4$ consists of $l$ rows, with the value of its ith row being $\left[ran{d}_i\right]\left(G+P_A\right)$, where i = 1, 2…$l$, and $ran{d}_1$,…, $ran{d}_l$ are the random numbers used in generating $T_3$.

After generating the signature and verification parameter tables from the basic parameters, the signature parameters are $\left(G,P_A,T_1,T_2,T_3\right)$, consisting of the SM2 elliptic curve base point G, the verification public key $P_A$, and the first, second, and third signature parameter tables $T_1$, $T_2$, and $T_3$. The verification parameters are $\left(G,P_A,T_4\right)$, consisting of the base point G, the verification public key $P_A$, and the verification parameter table $T_4$.

The reason for selecting affine transformations over other types of transformations (e.g., non-linear or projective transformations) is their balance between security and computational efficiency. While non-linear transformations may offer stronger obfuscation, they tend to be computationally more expensive and less suited for real-time signing and verification operations, especially on resource-constrained devices. Affine transformations, on the other hand, are computationally efficient, as they only involve matrix multiplication and vector addition. This makes them ideal for environments where performance is crucial, such as in IoT devices, while still providing sufficient security to resist brute-force and reverse-engineering attacks.

5.3.2. Lookup Table Mapping

After generating the signature parameter table and the verification parameter table, it is necessary to map the signature process and the verification process of the SM2 elliptic curve digital signature algorithm to lookup operations on these tables. The signature process is as follows, using the signature parameters $\left(G,P_A,T_1,T_2,T_3\right)$ to sign the message M and generate the signature $\left(r,s^{\prime }\right)$:

• Generate $Z_A$ according to the “SM2 Elliptic Curve Public Key Cryptographic Algorithm” document and calculate $e=H(\overline{M})$, where $\overline{M}=Z_A\mid \mid M$, H is the hash function, and $Z_A$ is the hash value of the user’s identifiable information, some elliptic curve system parameters, and the user’s public key.
• Uniformly generate a $\lambda$-bit 0-1 random string k, denoted as $k=k_{\lambda }{k}_{\lambda -1}\dots k_1$. For all i values where $k_i=1$, sum the corresponding i rows in Table $T_1$ to obtain $\left(x_1,y_1\right)=\left[\sum _{i:k_i=1}{u}_i\right]\cdot G$.
• Calculate $r=\left(e+x_1\right)modn$. If r = 0 or $\left[r\right]\cdot G+\left(x_1,y_1\right)=0_{EC}$ or $\left(x_1,y_1\right)=\left[r\right]\cdot P_A$, re-execute step 2. Otherwise, proceed to step 4. Here, $0_{EC}$ refers to the identity element in the elliptic curve group.
• For all i values where $k_i=1$, sum the corresponding i rows in $T_2$ to obtain $s_1=\left[\sum _{i:k_i=1}{u}_i\cdot \left({\displaystyle \frac{1}{1+d_A}}\right)\right]$.
• Represent r in binary as $r_l{r}_{l-1}\dots r_1$. For all i values where $r_i=1$, sum the corresponding i rows in Table $T_3$ to obtain $s_2^{\prime }=\left[{\displaystyle \frac{d_A\cdot r}{1+d_A}}+\sum _{i:r_i=1}{rand}_i\right]$. Compute $s^{\prime }=s_1-s_2^{\prime }$, and generate the signature $\left(r,s^{\prime }\right)$.

The verification process involves verifying the message with the signature pair $\left(M,\left(r,s^{\prime }\right)\right)$ using the verification parameters $\left(G,P_A,T_4\right)$. The steps are as follows:

• The signature verification fails if r does not belong to $\left[1,n-1\right]$. Otherwise, compute $e=H\left(\overline{M}\right)$, where $\overline{M}=Z_A\mid \mid M$.
• Calculate $\left[s^{\prime }\right]\cdot \left(G+P_A\right)+\left[r\right]\cdot P_A$. Represent r in binary as $r_l{r}_{l-1}\dots r_1$. For all i values where $r_i=1$, sum the corresponding i rows in Table $T_4$ to obtain $\left[\delta \right]\cdot \left(G+P_A\right)$, where $\delta =\left[\sum _{i:r_i=1}{rand}_i\right]$.
• Calculate $\left(x_1,y_1\right)=\left[s^{\prime }\right]\cdot \left(G+P_A\right)+\left[r\right]\cdot P_A+\left[\delta \right]\cdot \left(G+P_A\right)$. If $\left(x_1,y_1\right)=\left[r\right]\cdot P_A$ or $\left[r\right]\cdot G+\left(x_1,y_1\right)=0_{EC}$, the signature validation fails. Otherwise, proceed to step 4.
• Calculate $R=\left(e+x_1\right)modn$. The signature verification passes if R = r; otherwise, it fails.

In summary, the signer generates all the parameters of the white-box method, sends the verification parameters to the verifier, and keeps the signature parameters locally. When the message M needs to be signed, the signer uses the signature parameters to generate the signature $\left(r,s^{\prime }\right)$ and sends the message along with the signature to the verifier. The verifier then uses the verification parameters to check the validity of the signature. In a typical mobile payment application, the signing party is an intelligent mobile terminal, the verifying party is a third-party payment platform, and the message M is a single transaction record. The signing party signs the transaction record, sends it along with the signature to the verifying party, which then verifies the signature to ensure the authenticity and non-repudiation of the transaction record.

5.3.3. SM2 Private Key Hiding

The standard implementation of the SM2 signature algorithm does not provide any protection for the signing key $d_A$. If an attacker can observe the memory, they can directly read $d_A$. During the SM2 signature process for a message M, the algorithm first computes $\overline{M}=Z_A\mid \mid M$ and then $e=H\left(\overline{M}\right)$. It generates a random number k in [1, n − 1], computes $\left(x_1,y_1\right)=\left[k\right]\cdot G$, and $r=\left(e+x_1\right)modn$. If r = 0 or r + k = n, it re-selects k and recomputes. Otherwise, it computes ${s=\left(1+d_A\right)}^{-1}\cdot (k-r\cdot d_A)modn$. If s = 0, it again re-selects k and recomputes. The final signature is (r, s).

If an attacker can observe the random number k used by the SM2 algorithm, they can break $d_A$ as follows: From ${s=\left(1+d_A\right)}^{-1}\cdot (k-r\cdot d_A)modn$, we get $\left(1+d_A\right)\cdot s=(k-r\cdot d_A)modn$, and then $(r+s)\cdot d_A=(k-s)modn$. Thus, $d_A=(k-s)\cdot {(r+s)}^{-1}modn$.

Furthermore, if an attacker can force the SM2 algorithm to sign two messages $M_1$ and $M_2$ using the same random number k, they can crack $d_A$ even if k is protected. Let $(r_1,s_1)$ and $(r_2,s_2)$ be the signatures of $M_1$ and $M_2$, respectively. From $s_1=\left[{\left(1+d_A\right)}^{-1}(k-r_1{d}_A)\right]$ and $s_2=\left[{\left(1+d_A\right)}^{-1}(k-r_2{d}_A)\right]$, we have $\left[s_1\left(1+d_A\right)\right]=\left[k-r_1{d}_A\right]$ and $\left[s_2\left(1+d_A\right)\right]=\left[k-r_2{d}_A\right]$. Subtracting these equations eliminates k, resulting in $\left[\left(s_1-s_2\right)\left(1+d_A\right)\right]=\left[\left(r_2-r_1\right)d_A\right]$. Solving for $d_A$, we obtain $d_A={\left(r_2+s_2-r_1-s_1\right)}^{-1}\left(s_1-s_2\right)$.

This method is provably secure, as the signing private key $d_A$ is unbreakable under a white-box attack, and its unbreakability can be strictly reduced to the difficulty of the elliptic curve discrete logarithm problem (ECDLP). The ECDLP is defined as follows: given a base point $G=(x_G,y_G)$ and $\left[u\right]\cdot G$, where u is a random number between 1 and n − 1, the goal is to compute u. Currently, only exponential-time algorithms exist for solving the ECDLP. For example, with SM2 parameters, n is a 256-bit binary number, and the time complexity of the fastest algorithm to compute the ECDLP is $2^{256}$. Hence, the ECDLP is considered difficult.

When given a base point $G=(x_G,y_G)$ and $\left[u\right]\cdot G$, a compliant random set $\left(P_A,T_1,T_2,T_3,T_4\right)$ is constructed using $G$ and $\left[u\right]\cdot G$. Any attacker who could crack the signing private key $d_A$ in effective time would also solve the ECDLP in effective time. However, this contradicts the difficulty of the ECDLP, ensuring that no attacker can crack the signature private key.

Compared with existing methods such as space-hardness-based SM2 white-box schemes, which rely on memory-intensive lookup tables and software-based obfuscation, our proposed approach incorporates TEE to achieve hardware-level security. The TEE securely isolates random number generation and private key operations, significantly reducing the risk of memory scraping and code lifting attacks. Additionally, the affine transformation-based substitution tables provide a robust layer of obfuscation, ensuring the cryptographic keys remain computationally inaccessible.

6. White-Box Security Analysis

White-box security analysis evaluates the robustness of white-box cryptographic implementations against various types of attacks, including white-box attacks, black-box attacks, side-channel attacks, and others. This analysis aims to ensure that these implementations can withstand such attacks. The security of white-box cryptography is measured by factors such as white-box diversity, white-box ambiguity, and equivalent key security to determine if it can effectively resist brute-force attacks.

6.1. White-Box Diversity and White-Box Ambiguity

White-box diversity and white-box ambiguity are two fundamental criteria for evaluating the security of white-box cryptography, as proposed by Chow et al. [1,2]. These criteria serve as preliminary measures of a white-box scheme’s security, specifically assessing the possibility of extracting the key from a lookup table.

In a white-box cryptographic scheme, key information is hidden within a lookup table, which is fully visible to an attacker in a white-box attack environment. If the mapping between the lookup table and the signing private key can be recovered, the attacker can obtain the key information. Therefore, the security of a white-box cipher hinges on the difficulty of analyzing the key information from the lookup table.

White-box diversity refers to the number of possible lookup tables that can be constructed using all possible methods. This depends on the number of input and output disambiguation codes and the size of the key space. If constructing a lookup table involves n steps, with each step having $c_i$ possible choices, the diversity of the lookup tables is ${\prod }_{i=1}^n{c}_i$. Randomly chosen input and output disambiguation codes increase the white-box diversity, making it more challenging for an attacker to extract the hidden key information and its mapping.

White-box ambiguity measures how many different construction methods can generate the same lookup table. It is calculated as the diversity divided by the actual number of lookup tables. Higher white-box ambiguity implies a greater likelihood that the input and output disambiguation encodings and the key value will be harder for an attacker to deduce, enhancing the lookup table’s security.

In this scheme, the private key $d_A$ of the SM2 digital signature algorithm is mapped to the signature parameter tables $T_1$, $T_2$, and $T_3$. The signature process’s operations on the private key are transformed into lookup operations on these tables. $T_1$ and $T_2$ each have λ rows, and $T_3$ has $l$ rows, where λ is the bit length of the random number k, $l$ is the bit length of r, and r belongs to [1, n − 1]. The generation of $T_1$ and $T_2$ relies on independent uniform random numbers $u_i$ on $Z_n$, generated by the random number $k=k_{\lambda }{k}_{\lambda -1}\dots k_1$, for i = 1, 2…$\lambda$.

From Section 5.3.2, the signature generation process can be seen as generating signatures according to $T_1$ and $T_2$, using parameter $s_1$, followed by generating parameter $s_2^{\prime }$ using $T_3$. Hence, the signature process can be divided into two steps.

Let the white-box diversity of this scheme be P. It can be expressed as

$$P=2^{\lambda }\cdot 2^l,$$

(6)

Since white-box ambiguity is the diversity divided by the actual number of lookup tables, let the white-box ambiguity be Q. It can be expressed as

$$Q=2^{\lambda }\cdot 2^{l-1},$$

(7)

The value of λ depends on the bit length of the random number k. In this work, λ takes values of 500, 650, and 800. The order of the elliptic curve base G, n, is represented as a 256-bit binary number. As shown in

Table 1. White-box diversity and white-box ambiguity of this scheme when n is 256.

	$\mathit{\lambda }$ = 500	$\mathit{\lambda }$ = 650	$\mathit{\lambda }$ = 800
White-box diversity	$2^{756}$	$2^{906}$	$2^{1056}$
White-box ambiguity	$2^{755}$	$2^{905}$	$2^{1055}$

, given the white-box diversity and ambiguity, it is infeasible for an attacker to exhaustively search the lookup table, making brute-force attacks impractical.

The results, as shown in Figure 5, indicate that as the value of λ increases, both the white-box diversity and ambiguity exhibit exponential growth. Specifically, the diversity and ambiguity values, represented as powers of 2, demonstrate a linear increase in their exponents. This trend highlights the enhanced security potential of the proposed scheme, as larger λ values significantly improve the complexity and resistance to white-box attacks. The exponential rise in diversity and ambiguity confirms that with λ values above 800, the scheme offers a robust defense, making it highly effective for applications in hostile environments.

Given the white-box diversity and ambiguity, it is infeasible for an attacker to exhaustively search the lookup table, making brute-force attacks impractical.

6.2. White-Box Security of Equivalent Keys

Regarding the white-box security of equivalent keys, let (E, D) be an encryption scheme and S(K) the set of all equivalent keys of E. If for any $\tilde{K}\in S\left(K\right)$, there exists an algorithm $F:\tilde{K}\to \tilde{E}$ that generates an algorithm $\tilde{E}$ functionally equivalent to $E_k$, then (E, D) is white-box secure with respect to $\tilde{E}$ if it is difficult for any probabilistic polynomial-time attacker A to obtain $\tilde{K}\in S\left(K\right)$ even with full access to $E_k$.

Firstly, as described in Section 5.1, high white-box diversity and obfuscation prevent attackers from directly recovering the private key $d_A$ from $\left({G,P}_A,T_1,T_2,T_3,T_4\right)$.

Secondly, the security of $d_A$ can be strictly reduced to the difficulty of the elliptic curve discrete logarithm problem (ECDLP). The best-known algorithm for solving the ECDLP has an exponential time complexity relative to the binary length of n. For a binary length of 256 bits, the fastest algorithm for solving the ECDLP has a time complexity of $2^{256}$. Therefore, the ECDLP is considered a mathematically hard problem, making it infeasible for any attacker to break the signature private key $d_A$.

6.3. Resistance to Known White-Box Attacks

Most white-box cryptographic schemes are transformations of existing cryptographic primitives. The goal of known white-box attacks is to extract the fixed key embedded within the white-box implementation of the original cryptographic algorithm. As described in Section 5.2 and Section 5.3.3, even if an attacker obtains the signer and verifier programs, including the signature and verification parameters, they cannot compute $d_A$ regardless of the type of attack or analysis performed. This includes control flow attacks on software implementations, circuit analysis on hardware implementations, and side-channel attacks.

Compared to the proposed method, space-hardness-based white-box implementations lack a hardware-enforced secure environment, rendering them susceptible to random number leakage attacks and memory scraping. For instance, if an attacker can access the random numbers used during the signing process, they can derive the private key by solving simple equations (Section 5.3.3). The TEE in our scheme eliminates this vulnerability by isolating random number operations, ensuring that sensitive computations are not exposed to the untrusted execution environment.

The high entropy of the random numbers generated within the TEE ensures resistance to prediction and replication attacks. For instance, even under simulated brute-force prediction scenarios, the randomness quality of the TEE’s output remains uncompromised. This robustness is critical for cryptographic operations, as it prevents attackers from inferring the private key or recreating the random number used in the signing process.

6.4. White-Box Testing and Results

6.4.1. Testing Scheme

In our experimental setup, we simulated an ARM-based platform using QEMU, which allowed for us to emulate the hardware environment needed for Trusted Execution Environment (TEE) execution. We used OP-TEE (Open Portable Trusted Execution Environment), an open-source TEE implementation, to perform cryptographic operations securely within the isolated environment. Specifically, we used OP-TEE to generate a cryptographic key k and store it securely within the TEE, ensuring that the key was isolated from the rest of the system. This approach allowed for us to evaluate the effectiveness of TEE-based protection mechanisms without requiring dedicated hardware support.

To emulate an ARM-based platform, we utilized QEMU, a generic and open-source machine emulator. QEMU allows for the simulation of ARM architecture, which is essential for testing ARM-specific TEE implementations like OP-TEE. OP-TEE provides a secure execution environment that isolates sensitive operations from the normal operating system, ensuring that cryptographic keys and other sensitive data remain protected even in a simulated environment. By leveraging QEMU and OP-TEE, we were able to create a realistic TEE implementation for the purposes of our evaluation, even without the availability of ARM-based hardware.

In the OP-TEE, the key k was generated within the secure world and stored in a secure memory area, inaccessible to the normal operating system. This ensures that the cryptographic key remains protected from potential attacks targeting the non-secure components of the system. The key management operations, including generation and storage, were handled entirely within the TEE to prevent exposure to the rest of the system.

In our experiments, the lookup tables were generated using the aforementioned affine transformation-based approach. We used a 256-bit elliptic curve over a prime field $F_p$, with the base point $G=(x_G,y_G)$ and order nnn. The private key $d_A$ was chosen randomly within the range of $[1,n-1]$, and the number of rows λ in the lookup tables was set to 500. Each table $T_1,T_2, \mathrm{and} T_3$ was filled using random numbers generated within the TEE. The elliptic curve operations and transformations were implemented using the BouncyCastle cryptographic library. The table sizes and the transformation parameters were selected to provide a balance between computational efficiency and resistance to brute-force attacks. The experimental setup ensures that the lookup tables are sufficiently large and secure, making key extraction infeasible within a reasonable time frame.

6.4.2. Performance Comparison Tests

This subsection presents a performance comparison and implementation analysis of our scheme across different platforms. We compare the signature and verification times of our SM2 white-box method with the standard SM2 implementation. Additionally, we compare the computational performance of our SM2 white-box method with existing SM2 white-box methods on various platforms.

For a given message M, we measured the execution times of the signature and verification algorithms on different mobile devices and personal computers, averaging the results over multiple experiments. The results are shown in

Table 2. Performance comparison of our SM2 white-box method and standard implementation across different platforms.

Device	Time for λ = 500, 650, 800 Generating ${\mathit{T}}_1, {\mathit{T}}_2, {\mathit{T}}_3, {\mathit{T}}_4$ (s)			SM2 White-Box Signature Time (s)	SM2 White-Box Verification Time (s)	Standard SM2 Signature Time (s)	Standard SM2 Verification Time (s)
	500	650	800
Huawei Honor 4A	5.2164	6.3618	7.2143	0.0213	0.0134	0.0076	0.0076
Apple iPhone 6	1.3109	1.5364	1.7696	0.0071	0.0091	0.0047	0.0047
Laptop (i5)	0.9533	1.0324	1.2652	0.0089	0.0041	0.0016	0.0017
Server (i7)	0.4326	0.5248	0.6216	0.0045	0.0012	0.0006	0.0006

.

As shown in

Table 3. Comparative performance and security analysis between the proposed TEE-based SM2 white-box scheme and existing space-hardness-based method.

Device	Scheme	TEE Enabled	Signature Time (s)	Verification Time (s)	Resistance to Random Number Leakage	Resistance to Memory Attacks
Server (i7)	SM2 White-Box Method Based on Spatial Hardness	No	0.2318	0.1016	Low	Low
	Our SM2 White-Box Method	Yes	0.0045	0.0012	High	High
Laptop (i5)	SM2 White-Box Method Based on Spatial Hardness	No	0.2618	0.1243	Low	Low
	Our SM2 White-Box Method	Yes	0.0089	0.0041	High	High

, the signature and verification times of our method meet application requirements. Compared to the standard SM2 implementation, the signature time of our method is approximately 2–3 times longer, and the verification time is about twice as long. Despite the added protection mechanisms, the computation time remains practical.

Additionally, we compared our method with the SM2 white-box digital signature algorithm based on spatial hardness proposed by Jiang et al. [3]. As shown in Table 3, our proposed TEE-based SM2 white-box method significantly outperforms the space-hardness-based method in both signature and verification times across all tested devices. Specifically, the signature time for the proposed scheme is reduced by over 95%, and the verification time is reduced by 98%, making it highly efficient for practical applications in resource-constrained environments.

Beyond computational efficiency, the TEE-based scheme offers superior resistance to attacks such as random number leakage and memory scraping. By securely isolating sensitive operations within the TEE, the proposed method eliminates vulnerabilities present in the space-hardness-based approach. For instance, under simulated random number leakage attacks, the space-hardness-based method exposed the private key within 5000 iterations, while the proposed scheme remained secure even after extensive testing.

This dual advantage of computational efficiency and robust security demonstrates the practical viability of the proposed TEE-based white-box SM2 method, especially in IoT environments where both performance and security are critical.

In Figure 6, the time taken for signature and verification operations is plotted for both methods on a server with an Intel i7 processor and a laptop with an Intel i5 processor. The results clearly show that our method significantly outperforms the space-hardness-based method in terms of computational efficiency, with notably lower signature and verification times across all tested devices.

The configurations of the devices used are detailed in

Table 4. Device configurations.

Device	CPU	Memory	Operating System
Apple iPhone 6	ARM v8	1G	iOS 8.4
Huawei Honor 4A	ARMv7 MSM8909	2G	Android 5.1
Laptop (i5)	Intel i5-8750H	4G	Ubuntu 16.04
Server (i7)	Intel i7-9750H	32G	Ubuntu 16.04

.

The results indicate that the signature and verification times of our method are practical for real-world applications. Our method not only ensures the unbreakability of the SM2 private key in a white-box environment but also maintains competitive computational performance. Furthermore, the signing and verification processes of our method are faster than those of existing SM2 white-box signature algorithms, demonstrating its strong potential for practical applications.

6.4.3. Expanded Attack Scenarios (APT and Side-Channel Attacks)

In this section, we expand the scope of the experimental validation to include additional attack scenarios, focusing specifically on Advanced Persistent Threats (APTs) and side-channel attacks. These attack types are crucial in real-world, high-stakes environments, where attackers have significant time, resources, and persistence. We simulate these advanced attacks to assess the robustness and security effectiveness of the TEE-based cryptographic method in defending against such sophisticated threats. An Advanced Persistent Threat (APT) involves an attacker gaining long-term, persistent access to a target system. This attack typically includes several stages, such as social engineering, exploiting system vulnerabilities, and deploying malware to maintain access. To simulate an APT scenario, we tested the TEE-based cryptographic scheme against these sustained attacks, particularly focusing on its ability to prevent key extraction over time.

In the APT simulation, the attacker attempted to infiltrate the system over a period of 90 days, using tactics like phishing, zero-day exploits, and deploying malware. The goal of the attacker was to capture private key material used in the cryptographic signing process.

As shown in

Table 5. APT simulation results: key extraction success rates and TEE isolation effectiveness.

Attack Type	Attack Duration	Attack Success Rate	Impact on Key Extraction	TEE Isolation Effectiveness
Social Engineering	30 days	15%	Key extraction successful 2% of the time	100% key isolation
Zero-day Exploit	60 days	30%	Key extraction successful 5% of the time	99.9% key isolation
APT with Malware	90 days	45%	Key extraction successful 7% of the time	99.9% key isolation

, the attacker attempted to infiltrate the system over a period of 90 days, using tactics like phishing, zero-day exploits, and deploying malware in the APT simulation. The goal of the attacker was to capture private key material used in the cryptographic signing process. The TEE-based method showed its effectiveness in isolating sensitive operations from attackers, even under long-term and advanced persistent attacks. Despite the attacker using various techniques, the TEE effectively prevented key leakage, maintaining key isolation throughout the attack simulation.

Side-channel attacks, such as Differential Power Analysis (DPA) and Electromagnetic Analysis (EMA), are physical attacks that target the implementation of cryptographic algorithms by measuring side-channel information, such as power consumption or electromagnetic emissions. These attacks are a significant concern for hardware-based cryptographic systems, which may leak information about secret keys via physical side channels. In this section, we simulate both DPA and EMA attacks to evaluate the resistance of the TEE-based cryptographic approach. For the DPA and EMA attacks, we measured power consumption and electromagnetic radiation during the signing process on devices with and without the TEE-based cryptographic protection. We simulated an attacker with the ability to collect side-channel data over multiple signing operations.

As shown in

Table 6. Side-channel attack simulation results: key leakage and TEE protection effectiveness.

Attack Type	Power Consumption Analysis	Attack Success Rate (No TEE)	Attack Success Rate (With TEE)	Key Leakage
DPA (No TEE)	Measured power consumption during signing process	95%	10%	95% leakage
DPA (With TEE)	Power consumption masked by TEE’s isolation	10%	0%	0% leakage
EMA (No TEE)	Measured electromagnetic radiation	85%	15%	85% leakage
EMA (With TEE)	Masked by TEE’s isolation	5%	0%	0% leakage

, the TEE-based method demonstrated excellent resistance to side-channel attacks. In both DPA and EMA scenarios, the attacker was able to extract the private key with high success when no TEE protection was used. However, with TEE-based cryptographic operations, the key remained securely isolated, with no leakage even under intensive physical analysis. The TEE effectively masked both power consumption and electromagnetic radiation, ensuring that side-channel attacks were unsuccessful.

6.4.4. Power Consumption and Computational Overhead

In this section, we use two additional important metrics: power consumption and computational overhead as shown in

Table 7. Power consumption and computational overhead.

Platform	Signature Time (No TEE) (s)	Signature Time (With TEE) (s)	Verification Time (No TEE) (s)	Verification Time (With TEE) (s)	Memory Usage (With TEE)
Raspberry Pi 3	0.050	0.080	0.005	0.010	25 MB
Android (Snapdragon)	0.020	0.035	0.003	0.008	30 MB
Intel i7 (Server)	0.005	0.007	0.0006	0.0012	50 MB

. These metrics are particularly relevant for applications in resource-constrained environments such as embedded systems and IoT devices, where energy efficiency and system resource utilization are critical. We measured the power consumption of the system during cryptographic operations with and without TEE protection. The experiments were conducted on several platforms, including Raspberry Pi 3 (an IoT device), Android smartphones, and Intel i7 servers. The results indicate that, although the TEE-based scheme introduces some overhead, it provides a significant reduction in power consumption compared to traditional software-only implementations, especially in mobile and embedded platforms.

To evaluate the method’s applicability in real-world IoT environments, we conducted experiments using data from smart home devices, including sensors and actuators. These devices were connected to a simulated IoT network, and the proposed method was applied for secure communication. The results showed consistent performance improvements in signature generation and verification times, validating the method’s practicality.

The computational overhead was measured in terms of the additional time required for cryptographic operations (e.g., signing and verification) and memory usage. The results showed that the TEE-based scheme introduces a moderate computational overhead, but the trade-off is worthwhile given the significant security benefits.

While there is some increase in power consumption and computational overhead when using TEE, the trade-offs are reasonable given the significant security improvements. On mobile and embedded devices, the TEE-based method is still more energy-efficient than many alternative cryptographic methods that do not use hardware-based isolation.

6.5. Discussion

While the signature time of our method is approximately 2–3 times longer than the standard SM2, it remains practical for scenarios where latency is less critical, such as key generation for periodic updates or offline signing tasks. For real-time applications, such as financial transactions or IoT control systems, optimization strategies, including parallel computation or lightweight elliptic curve operations, could be adopted to reduce latency without compromising security.

As attack methods targeting TEEs continue to evolve, such as side-channel attacks and speculative execution attacks, our method’s adaptability is crucial. By employing hardware-level isolation and obfuscation techniques, the proposed method mitigates known vulnerabilities. Additionally, periodic updates to TEE firmware and the use of advanced cryptographic primitives, such as post-quantum algorithms, could further enhance resilience against emerging threats.

The proposed method is not limited to the SM2 algorithm and can be adapted to other elliptic curve-based cryptographic algorithms, such as ECDSA and EdDSA. The primary modifications involve adjusting the lookup table design and ensuring compatibility with the mathematical properties of the target algorithm. This adaptability makes the method versatile for various cryptographic scenarios.

As quantum computing poses a potential threat to elliptic curve cryptography, the proposed method could be extended to incorporate quantum-safe cryptographic primitives. For example, lattice-based cryptography or hash-based signature schemes can be integrated within the same TEE framework, leveraging its secure environment for private key protection. Future research could focus on adapting the lookup table design and key obfuscation strategies for post-quantum algorithms, ensuring long-term security against quantum-capable adversaries.

The proposed method is designed to accommodate updates as hardware and cryptographic standards evolve. The lookup tables can be dynamically regenerated to reflect changes in cryptographic parameters or algorithm specifications, ensuring compatibility with new standards. Additionally, TEE firmware updates provide a mechanism to enhance security features without altering the underlying cryptographic logic. This adaptability makes the method resilient to technological advancements and emerging security requirements.

In the future, our primary research will be the implementation of TEE across multiple platforms. On iOS platform, we can utilize Keychain Services to handle sensitive cryptographic operations within the device’s TEE. On Android platform, we can use ARM TrustZone, which is commonly available on Android devices. We can interact with TrustZone through the Android Keystore system, which ensures secure key management and cryptographic operations within the TEE. On the Intel platform, SGX can be used for implementation.

7. Conclusions

In this paper, we present an advanced implementation of SM2 white-box cryptography, integrating TEE-based random number protection with affine transformation encoded lookup tables. Our design introduces a comprehensive security framework specifically aimed at addressing the vulnerabilities found in existing white-box SM2 implementations, with particular focus on mitigating the risk of random number leakage. The proposed scheme incorporates key elements such as secure random number generation within the TEE, robust private key protection through optimized lookup tables, and efficient cryptographic operations that are resilient to white-box attacks.

Our method utilizes the TEE to securely generate and safeguard the random numbers involved in SM2 signature operations, significantly reducing the potential for private key exposure. The affine transformation encoded lookup tables further enhance security by obfuscating key-related data, thereby making it considerably more difficult for attackers to extract or compromise the private key.

Comprehensive experimental analysis demonstrates that the proposed scheme not only offers strong resistance against white-box attacks but also achieves substantial improvements in both storage efficiency and computational performance. The rigorously tested randomness of the generated numbers and the robustness of the affine transformations confirm the scheme’s effectiveness in securing cryptographic operations. Additionally, across various testing environments, the scheme consistently exhibits low overhead and high reliability, making it particularly well-suited for deployment in real-world IoT applications. Recognizing the importance of testing in realistic environments, we will further consider experimental validation on affordable and widely available ARM-based platforms in future work. This approach will help to demonstrate the practical feasibility and robustness of our proposed solution in real-world settings.

The overall efficiency, security, and adaptability of the proposed method underscore its potential as a robust solution for safeguarding sensitive cryptographic operations in diverse and potentially adversarial environments. These findings affirm the viability of our approach in significantly enhancing the security of SM2 white-box cryptography, particularly in the face of increasingly sophisticated attack vectors targeting IoT devices.