Prime pool based rsa key generation method, system, medium, and apparatus

Abstract

The application provides a prime number pool-based RSA key generation method, system, medium and device, relates to the technical field of digital keys, and comprises the following steps: obtaining a prime number candidate; performing coarse screening on the prime number candidate in a rich execution environment to obtain a suspected prime number; sending the suspected prime number to a trusted execution environment, performing primality verification on the suspected prime number in the trusted execution environment to obtain a true prime number; performing encryption processing on the true prime number, and writing the encrypted true prime number into a prime number pool; receiving an RSA key generation request, taking out a prime number from the prime number pool, and generating an RSA key based on the prime number. Through coarse screening in the rich execution environment, the application fully utilizes multi-core computing power and idle time, ensures that the true prime number or the private key cannot be obtained even if the rich execution environment is broken, and the security boundary is completely reserved.

Description

Technical Field

[0001] This application relates to the field of digital key technology, and in particular to RSA key generation methods, systems, media and devices based on prime number pools. Background Technology

[0002] In remote communication modules such as vehicle-mounted T-Boxes (Telematics Boxes), to ensure the security of cryptographic operations and key storage, RSA key generation is typically performed in a Trusted Execution Environment (TEE) based on ARM TrustZone. A typical T-Box module uses a hardware architecture of a main control chip and external NAND Flash. The main control chip is usually a quad-core ARM Cortex-A series processor, integrating a Hardware Security Module (HSM) to provide true random number generation and encryption services, and using the open-source OP-TEE as the TEE operating system. The open-source OP-TEE implements RSA key generation based on the libtomcrypt cryptography library. After the client application (CA) initiates a key generation request to the trusted application (TA) through the TEE Client API, the TA calls the rsa_make_key function in the secure world, repeatedly calling rand_prime to generate large prime numbers p and q. Each iteration includes obtaining random candidate numbers, performing trial division with small prime numbers, and performing a Miller-Rabin probabilistic primality test. If the test fails, candidate numbers are obtained again until a suitable prime number is found. Subsequently, the modulus n and Euler's totient function are calculated. The key pair (n) and the private key exponent d are then encapsulated into a secure object and a handle is returned to the CA. This calculation only begins after the CA initiates a request, and within the secure world, it is executed serially on a single core and single thread, constituting the critical path for CA request-response latency. Since RSA (Rivest-Shamir-Adleman, a classic asymmetric encryption algorithm) prime number generation is essentially a probabilistic process involving numerous trials, generating a single large prime number requires testing hundreds to thousands of candidate numbers on average, resulting in significant computational time consumption, especially on resource-constrained module platforms like T-Boxes. Furthermore, T-Box modules experience significant CPU idle periods during scenarios such as vehicle stationary, standby, and low-load communication. Existing solutions do not perform any key preparation during these periods, generating keys only when a request arrives, completely wasting idle computing power and failing to utilize multi-core computing power.

[0003] Therefore, how to accelerate RSA key generation by making full use of system idle time and multi-core computing power without reducing security is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] This application provides an RSA key generation method, system, storage medium, and device based on a prime number pool, which solves the technical problems of significant time consumption in prime number generation, occupation of critical request-response paths, and underutilization of system idle computing power and multi-core computing power in the existing RSA key generation process.

[0005] To address the aforementioned technical problems, this application provides an RSA key generation method based on a prime number pool, comprising: Obtain candidate prime numbers; In a rich execution environment, the candidate prime numbers are coarsely screened to obtain suspected prime numbers; The suspected prime number is sent to a trusted execution environment, where its primality is verified to obtain a true prime number. The true prime number is encrypted, and the encrypted true prime number is written into the prime number pool. Receive an RSA key generation request, retrieve a prime number from the prime number pool, and generate an RSA key based on the prime number.

[0006] Optionally, in a rich execution environment, the candidate prime numbers are coarsely screened to obtain potential prime numbers, including: In the rich execution environment, multiple worker threads are started, and each worker thread is bound to a different CPU core; Each of the aforementioned working threads performs small prime number division on the prime candidate numbers, eliminating prime candidate numbers that fail the small prime number division test. For the prime candidate numbers that can be divided by the small prime number, calculate the Fermat pseudoprime test value of the prime candidate numbers with a set base, and determine whether the prime candidate numbers pass the Fermat test based on the test value. The prime candidate numbers that pass the Fermat test are taken as the suspected prime numbers.

[0007] Optionally, the step of verifying the primality of the suspected prime numbers in a trusted execution environment to obtain true prime numbers includes: In the trusted execution environment, the suspected prime number is decomposed into an odd part and a corresponding exponent after being reduced by one. A random base is selected according to a set number of rounds. The modulo exponentiation result is calculated for each random base and a square iteration is performed. The Miller-Rabin primality test is determined based on the iteration result. The suspected prime numbers that pass the Miller-Rabin primality test are considered true prime numbers.

[0008] Optionally, writing the encrypted true prime numbers into the prime number pool includes: The true prime number is encrypted using a derived key to obtain an encrypted prime number; Calculate the message authentication code based on the encrypted prime number; Write the encrypted prime number and the message authentication code to persistent storage, and update the pool index of the prime number pool.

[0009] Optionally, retrieving prime numbers from the prime number pool includes: Read the encrypted prime number and its corresponding message authentication code from the prime number pool; The message authentication code is verified. After the verification is successful, the encrypted prime number is decrypted to obtain the prime number to be used. The prime numbers to be used are subjected to security constraint verification. The prime numbers that satisfy the security constraints are selected as the prime numbers, and the prime numbers that have been used are removed from the pool index of the prime number pool.

[0010] Optionally, obtain prime candidate numbers, including: A random number is obtained from the hardware security module, and the obtained random number is used as the prime number candidate. Alternatively, in the rich execution environment, a random number is generated based on the system's random source, and the generated random number is used as the prime candidate number.

[0011] Optionally, before retrieving prime numbers from the prime number pool, the method further includes: Determine whether the number of prime numbers in the prime number pool is lower than a set value; When the number of prime numbers in the prime pool is lower than the set value, the prime candidate numbers are coarsely screened in the rich execution environment, and the primality of the suspected prime numbers obtained from the coarse screening is verified in the trusted execution environment. An RSA key is generated based on the verified prime numbers.

[0012] This application also provides an RSA key generation system based on a prime number pool, including: The candidate number acquisition module is used to acquire prime number candidates; The coarse screening module is used to coarsely screen the candidate prime numbers in a rich execution environment to obtain suspected prime numbers. The primality verification module is used to send the suspected prime number to a trusted execution environment, and to perform primality verification on the suspected prime number in the trusted execution environment to obtain the true prime number; The prime number pool management module is used to encrypt the true prime numbers and write the encrypted true prime numbers into the prime number pool. The key generation module is used to receive an RSA key generation request, retrieve a prime number from the prime number pool, and generate an RSA key based on the prime number.

[0013] Optionally, the coarse screening module includes: A thread startup unit is used to start multiple worker threads in the rich execution environment and bind each worker thread to a different CPU core; The trial division unit is used to perform small prime number trial division on the prime number candidate through each of the working threads, and to eliminate prime number candidate that fails the small prime number trial division; The Fermat test unit is used to calculate the Fermat pseudoprime test value of the prime candidate numbers that have been tried to divide by the small prime number, with a set base, and determine whether the prime candidate number passes the Fermat test based on the test value. The prime candidate number that passes the Fermat test is taken as the suspected prime number.

[0014] Optionally, the primality verification module is specifically used for: In the trusted execution environment, the suspected prime number is decomposed into an odd part and a corresponding exponent after being reduced by one. A random base is selected according to a set number of rounds. The modulo exponentiation result is calculated for each random base and a square iteration is performed. The Miller-Rabin primality test is determined based on the iteration result. The suspected prime numbers that pass the Miller-Rabin primality test are considered true prime numbers.

[0015] Optionally, the prime number pool management module includes: An encryption unit is used to encrypt the true prime number using a derived key to obtain an encrypted prime number; The MAC calculation unit is used to calculate the message authentication code based on the cryptographic prime number; The writing unit is used to write the encrypted prime number and the message authentication code into persistent storage and update the pool index of the prime number pool.

[0016] Optionally, the system further includes: The pool level judgment module is used to determine whether the number of prime numbers in the prime number pool is lower than a set value before taking prime numbers from the prime number pool. The downgrade generation module is used to perform coarse screening of the prime candidate numbers in the rich execution environment when the number of prime numbers in the prime pool is lower than the set value, to perform primality verification on the suspected prime numbers obtained from the coarse screening in the trusted execution environment, and to generate an RSA key based on the verified prime numbers.

[0017] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0018] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method described above when it invokes the computer program in the memory.

[0019] This application provides an RSA key generation method based on a prime number pool, comprising: obtaining candidate prime numbers; performing a coarse sieve on the candidate prime numbers in a rich execution environment to obtain suspected prime numbers; sending the suspected prime numbers to a trusted execution environment, performing primality verification on the suspected prime numbers in the trusted execution environment to obtain true prime numbers; encrypting the true prime numbers and writing the encrypted true prime numbers into a prime number pool; receiving an RSA key generation request, retrieving prime numbers from the prime number pool, and generating an RSA key based on the prime numbers.

[0020] The RSA key generation method based on a prime number pool provided in this application obtains candidate prime numbers, performs a coarse sieve of these candidates in a rich execution environment to obtain potential prime numbers, sends these potential prime numbers to a trusted execution environment for primality verification to obtain true prime numbers, encrypts the true prime numbers, and writes them into a prime number pool. Upon receiving an RSA key generation request, the method retrieves prime numbers from the prime number pool and generates an RSA key. This method removes the main time-consuming steps of prime number generation from the key request response path, allowing ready prime numbers to be directly retrieved from the prime number pool when a key request arrives, significantly reducing request response latency. By performing a computationally intensive but security-insensitive coarse sieve operation in a rich execution environment, it fully utilizes the multi-core computing power of the rich execution environment and system idle periods, avoiding the waste of idle computing power. The prime numbers undergo final primality verification and are encrypted and stored in the trusted execution environment, ensuring that even if the rich execution environment is compromised, the true prime numbers or the RSA private key cannot be obtained, thus preserving the security boundary intact.

[0021] This application also provides an RSA key generation system based on a prime number pool, a computer-readable storage medium, and an electronic device, which have the aforementioned beneficial effects, and will not be elaborated here. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 A flowchart illustrating an RSA key generation method based on a prime number pool, provided as an embodiment of this application; Figure 2 A schematic diagram of the overall architecture of the RSA key generation system based on prime number pool provided in the embodiments of this application; Figure 3 A schematic diagram of the structure of an RSA key generation system based on a prime number pool provided in an embodiment of this application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] This application provides an RSA key generation method based on a prime number pool, which can be applied to embedded devices such as in-vehicle T-Box modules, industrial IoT terminals, smart home gateways, medical IoT devices, and smart meters. The following detailed description uses an in-vehicle T-Box module as an example. The hardware environment of this in-vehicle T-Box module includes: a main controller using an MTK quad-core ARM Cortex series in-vehicle module, an integrated hardware security module (HSM) for providing true random numbers, and external NAND Flash storage. The software environment includes: an open-source OP-TEE for the TEE OS, Linux for the REE OS, and OP-TEE REE-FS mode for Secure Storage (encrypted files are stored in NAND Flash). In this application embodiment, the TA (Trusted Application) can be named Prime_Pool_TA.

[0026] The following is in conjunction with the appendix Figure 1 The RSA key generation method based on prime number pools provided in the embodiments of this application will be described in detail. Figure 1 A flowchart of an RSA key generation method based on a prime number pool provided in this application embodiment includes the following steps: S101: Obtain prime candidate numbers.

[0027] In this step, candidate prime numbers are obtained for subsequent prime number generation. The candidate prime numbers can be sourced from several possible sources.

[0028] In one feasible implementation, the prime number candidates can be derived from a hardware security module. Specifically, the TEE requests a batch of random numbers from the HSM via the HSM driver at appropriate times (e.g., when the prime number pool replenishment cycle starts or during system idle batch acquisition), and uses the obtained random numbers as prime number candidates. This implementation provides the highest quality candidate numbers (true hardware randomness) and is suitable for scenarios with stringent randomness requirements. The batch size of random numbers that the HSM can generate each time can be set by those skilled in the art based on the system memory capacity and prime number pool replenishment strategy, for example, generating 32 or 64 candidate numbers per request.

[0029] In another feasible implementation, prime candidate numbers are generated locally by the REE. Specifically, REE-side worker threads generate random numbers locally as prime candidate numbers through a Linux system random source (e.g., / dev / urandom) or an HSM interface accessible by the REE. This approach reduces the interaction overhead between the TEE and the HSM, resulting in higher throughput on the REE side.

[0030] In another feasible implementation, a hybrid mode of the two methods described above can be adopted. Specifically, the HSM source method is used during the initial system startup or in scenarios with high security requirements, while the REE local generation method is used when the system is in steady-state operation and requires a high-throughput replenishment pool. The two modes can be dynamically switched according to the pool level and security policy.

[0031] It should be noted that the specific timing for obtaining prime candidate numbers can be flexibly determined based on the system state.

[0032] In one feasible implementation, prime candidate number acquisition is performed during system idle periods. Specifically, the idle detection service on the REE side continuously monitors the system load status. When it detects that the system is idle, it sends an "idle and available" signal to the TEE via SMC (Secure Monitor Call). Upon receiving this signal, the TA's scheduling management module initiates the prime pool pre-generation process, which includes the candidate number acquisition operation in step S101. This fully utilizes system idle periods and does not infringe on the computing resources of the business execution path.

[0033] In another feasible implementation, the acquisition of prime candidate numbers is triggered when the prime number pool level is lower than a low water level threshold. Specifically, after each prime number is retrieved from the pool, the TA checks whether the current pool level is lower than a preset low water level threshold. If so, the pool replenishment process is triggered asynchronously, which includes the acquisition of candidate numbers, ensuring that the prime number pool can be continuously maintained at a reasonable water level.

[0034] In another feasible implementation, the acquisition of prime candidate numbers is performed during system startup. Specifically, after the module's cold start, during TA initialization, the system checks whether the prime number pool in persistent storage exists and is valid. If the pool is empty or the verification fails, the candidate number acquisition and prime number generation process is immediately initiated to quickly establish a usable prime number pool.

[0035] S102: In a rich execution environment, the prime candidate numbers are coarsely screened to obtain suspected prime numbers.

[0036] In this step, the prime candidate numbers obtained in step S101 are coarsely screened in a Rich Execution Environment (REE) to quickly eliminate candidates that are obviously composite, reducing the number of candidate numbers that need to be verified for primality in the trusted execution environment later. A Rich Execution Environment refers to an open runtime environment built on a feature-rich general-purpose operating system.

[0037] In one possible implementation of this step, step S102 specifically includes the following sub-steps.

[0038] First, multiple worker threads are launched in the rich execution environment (REE), and each worker thread is bound to a different CPU core. Specifically, the REE maintains a pool of coarse-screening worker threads, the number of which can be configured based on the number of CPU cores in the system. For example, for a quad-core Cortex-A processor, four worker threads can be launched, each bound to a different CPU core, to achieve parallel coarse-screening. The main loop of the worker threads is as follows: when there are candidate tasks to be processed, a task is retrieved from the task queue and the coarse-screening operation is performed; when the system becomes busy or there are no tasks to be processed, the worker threads can enter a sleep state to save resources.

[0039] Secondly, each worker thread performs small prime number division tests on the prime candidate numbers, eliminating those that fail the small prime number division test. Specifically, after obtaining a candidate number, each worker thread uses a pre-computed small prime number table to perform small prime number division tests on the candidate number in turn. The small prime number table contains a series of smaller prime numbers, such as the first few prime numbers starting from 2 (e.g., 2, 3, 5, 7, 11, 13, 17, 19, 23, 29... up to a certain threshold, such as all prime numbers within 1000). If a candidate number is divisible by any of the small prime numbers in the table, it is a composite number and is discarded directly; if a candidate number is not divisible by any of the small prime numbers in the table, it proceeds to the next screening stage. The range of the small prime number table can be set by those skilled in the art according to actual performance and security requirements, for example, it can be set to the first 200 prime numbers or the first 500 prime numbers.

[0040] Finally, for prime candidate numbers that pass the trial division with small primes, the Fermat pseudoprime test value is calculated using a set base. The test value determines whether the prime candidate number passes the Fermat test. Prime candidate numbers that pass the Fermat test are considered potential primes. Specifically, the Fermat test is based on Fermat's Little Theorem: if n is a prime number and a is coprime to n, then a^(n-1) ≡ 1 (mod n). For a candidate number n, a base a is chosen (e.g., a=2), and the value of a^(n-1) mod n is calculated. If this value is not equal to 1, then n must be a composite number; if it is equal to 1, then n passes the Fermat test and can be considered a potential prime. It should be noted that numbers that pass the Fermat test are not necessarily true primes (pseudoprimes exist). Therefore, the Fermat test is only used as a quick screening method in the initial screening stage; further rigorous primality verification is required in the TEE (Technical Evaluation Environment). The selected base number can be set by those skilled in the art based on their implementation experience. For example, 2 can be used as the fixed base number, or multiple base numbers can be used to perform multiple Fermat tests to improve the screening accuracy.

[0041] S103: Send the suspected prime number to a trusted execution environment, and verify the primality of the suspected prime number in the trusted execution environment to obtain a true prime number.

[0042] In this step, the suspected prime numbers that passed the coarse screening in step S102 are sent from the REE to the TEE via shared memory or other secure communication methods. The suspected prime numbers undergo rigorous primality verification within the Trusted Execution Environment (TEE). Only candidate numbers that pass the verification are confirmed as true prime numbers. The TEE is an isolated and secure physical region (or logical subspace) located within the device's main processor. It can run in parallel with the device's main operating system (i.e., the rich execution environment), but they are logically isolated from each other.

[0043] The core principle of TEE is to provide an "absolutely trusted" closed container for the loading, storage, and execution of sensitive data and critical code through hardware-level encryption and access control mechanisms. Even if the device's main operating system is completely compromised by malware or subjected to privilege escalation hijacking, attackers cannot directly penetrate the hardware barrier to access the data and function logic inside the TEE.

[0044] In one feasible implementation, step S103 specifically includes the following sub-steps.

[0045] In a trusted execution environment, a suspected prime number minus one is decomposed into its odd part and its corresponding exponent. Specifically, for a suspected prime number n, n-1 is calculated, and then n-1 is decomposed into the form d×2^r, where d is an odd number and r is an integer greater than or equal to 1.

[0046] Select random bases according to the set number of rounds, calculate the modular exponentiation result for each random base and perform square iteration, and judge whether the suspected prime number passes the Miller-Rabin primality test according to the iteration result. The Miller-Rabin primality test is a probabilistic primality test algorithm, and its test principle is as follows: For a candidate number n, a base a (1<a<n-1) is randomly selected, and x=a^d mod n is calculated. If x is equal to 1 or x is equal to n-1, this round of test is passed; otherwise, r-1 square iterations are performed, and x=x^2 mod n is calculated each time. If x is equal to n-1 after a certain iteration, this round of test is passed; if n-1 is not obtained after all iterations, n is a composite number. The above process is repeated for multiple rounds, and different random bases are selected in each round.

[0047] The number of rounds of the Miller-Rabin test directly affects the accuracy and calculation time consumption of the test. The more rounds there are, the lower the probability of misjudgment (judging a composite number as a prime number). In the embodiments of the present application, the number of rounds of the Miller-Rabin test may be set according to the recommended values in the FIPS186-5 standard. For example, for RSA-2048 key generation (the prime number has a bit length of 1024 bits), the number of test rounds may be set to 4 or more; for higher security level requirements, more test rounds may be set. The specific value of the number of test rounds may be configured by those skilled in the art according to actual security requirements and application scenarios.

[0048] In a feasible implementation, the number of rounds of the Miller-Rabin test may be dynamically adjusted according to the bit length of the candidate number. For candidate numbers with shorter bit lengths (for example, 512 bits), fewer test rounds may be set; for candidate numbers with longer bit lengths (for example, 2048 bits), more test rounds may be set. The corresponding relationship between the number of rounds and the bit length may be set with reference to the recommended values in relevant standards (for example, FIPS 186-5).

[0049] The suspected prime number that has passed the Miller-Rabin primality test is regarded as a true prime number. A suspected prime number is confirmed as a true prime number and enters the subsequent pooling process only after passing all rounds of the Miller-Rabin test. If a certain suspected prime number fails to pass the Miller-Rabin test, the candidate number is determined to be a composite number and discarded.

[0050] No matter the candidate number is generated from HSM or locally in REE, and no matter where the rough screening is performed, the final primality verification is always completed in the Secure World, and any non-true prime number will be rejected. Even if the REE is compromised and malicious candidate numbers are injected, the final Miller-Rabin verification of the TEE will reject any non-true prime numbers. The worst result is only denial of service, which will not lead to private key leakage.

[0051] S104: Encrypt the true prime number and write the encrypted true prime number into the prime number pool.

[0052] In this step, the true prime numbers verified in step S103 are encrypted and protected, and then persistently written into the prime number pool for use in subsequent key generation requests.

[0053] In one feasible implementation, step S104 specifically includes the following sub-steps.

[0054] First, the true prime number is encrypted using a derived key to obtain the encrypted prime number. Specifically, the TA (Technical Controller) uses its own derived encryption key to perform symmetric encryption on the true prime number. This derived key is managed by the TA, bound to the device's unique identifier, and does not appear in plaintext on the REE (Reverse Equipment) side or in the NAND Flash. The encryption algorithm can employ a symmetric encryption algorithm such as AES, for example, using AES-256-GCM mode to ensure both confidentiality and authentication capabilities. Before encryption, the true prime number can be organized according to a preset data structure, such as adding bit length, timestamp, and other metadata before the prime number data.

[0055] Next, the Message Authentication Code (MAC) is calculated based on the encrypted prime number. Specifically, the MAC value is calculated on the encrypted prime number data using a MAC key derived from the TA, and is used for integrity verification when subsequently read from the pool. The MAC calculation can employ algorithms such as HMAC-SHA256. The MAC key can be the same as or different from the encryption key. In one optional implementation, the encryption key and the MAC key use different derived keys to provide better key isolation security.

[0056] Finally, the encrypted prime numbers and their corresponding message authentication codes are written to persistent storage, and the pool index of the prime number pool is updated. Specifically, the TA accesses the pool index file through the REE-FS mode of OP-TEE Secure Storage, calling the TEE_OpenPersistentObject interface to persistently store the encrypted prime number entries in NAND Flash. The pool index records the metadata of each prime number entry, including the entry's unique ID, bit length, generation timestamp, and location in storage. The pool index itself is also encrypted and protected by Secure Storage.

[0057] In one feasible implementation, each prime number entry in the prime number pool can be organized using the following data structure: Each prime number entry contains: a unique entry ID (used to uniquely identify the prime number in the pool), a bit length (recording the number of binary digits of the prime number), a generation timestamp (recording the generation time of the prime number), encrypted prime number data (ciphertext encrypted using a TA-derived key), and a message authentication code (used for integrity verification). The length of each field in this data structure can be set according to actual needs. For example, the unique entry ID can be a 32-bit unsigned integer, the timestamp can be a 64-bit unsigned integer, and the message authentication code can be 32 bytes (corresponding to HMAC-SHA256).

[0058] S105: Receive an RSA key generation request, retrieve a prime number from the prime number pool, and generate an RSA key based on the prime number.

[0059] In this step, when the CA (Client Application) initiates an RSA key generation request, the TA directly retrieves ready prime numbers from the prime number pool to assemble and generate the RSA key, thereby achieving a fast response of delivery upon request.

[0060] In one feasible implementation, step S105 specifically includes the following sub-steps.

[0061] First, the CA initiates an RSA key generation request to the TA through the TEE Client API, which includes a key length parameter (e.g., 2048 bits, 3072 bits, or 4096 bits).

[0062] Upon receiving a request, the pool manager of the TA queries the prime number pool at the corresponding bit length level to determine if there are enough prime numbers available for use. For RSA key generation, two large prime numbers p and q are required, with a bit length approximately half that of the target key (e.g., RSA-2048 requires two 1024-bit prime numbers).

[0063] When there are enough prime numbers in the pool, the TA (Key Agent) retrieves two prime numbers, p and q, from the pool. The specific retrieval process is as follows: The encrypted prime number and its corresponding message authentication code are read from the prime number pool; the message authentication code is verified, and if the verification passes, the encrypted prime number is decrypted to obtain the prime number to be used; the prime number to be used is subjected to security constraint verification, and the prime number that satisfies the security constraints is taken as the prime number to be retrieved. Security constraint verification may include: verifying the lower bound of |pq| (ensuring that the two prime numbers are not too close to avoid Fermat factorization attacks), verifying that p and q are coprime with the public key exponent e, and verifying that the bit lengths of p and q exactly match the target bit length, etc. If the retrieved prime number pair does not satisfy the security constraints, the prime number pair is discarded and a new pair is retrieved. After retrieving a prime number from the pool, the retrieved prime number needs to be removed from the pool index of the prime number pool to avoid the same prime number being reused for multiple keys.

[0064] After retrieving p and q that satisfy the constraints, TA calculates the modulus n = p × q, the Euler's totient function Φ(n) = (p-1) × (q-1), and the private key exponent d = e within the Secure World. - ¹ mod (n), along with the Chinese Remainder Theorem (CRT) parameters dp, dq, and qinv, are used to accelerate subsequent RSA private key operations. The public key exponent e can use the standard value 65537, which conforms to the NIST SP800-56B standard recommendation.

[0065] Finally, the TA encapsulates the generated RSA key pair into a TEE_TYPE_RSA_KEYPAIR secure object and returns a handle to the CA. Simultaneously, the TA can asynchronously trigger the prime number pool replenishment mechanism, replenishing the used prime numbers in the background in a non-blocking manner.

[0066] When there are insufficient prime numbers in the pool (e.g., the number of prime numbers in the pool is lower than a set value), TA can trigger a degradation path. Specifically, TA immediately triggers a synchronous coarse screening and verification process, degrading to the traditional synchronous key generation mode to ensure the scheme is functionally available in the worst case. This set value can be set by those skilled in the art based on experience; for example, it can be set to 2 (i.e., ensuring at least one pair of prime numbers is available), or it can be set to a larger value to provide higher security redundancy.

[0067] The RSA key generation method based on a prime number pool provided in this application obtains candidate prime numbers, performs a coarse sieve of these candidates in a rich execution environment to obtain potential prime numbers, sends these potential prime numbers to a trusted execution environment for primality verification to obtain true prime numbers, encrypts the true prime numbers, and writes them into a prime number pool. Upon receiving an RSA key generation request, the method retrieves prime numbers from the prime number pool and generates an RSA key. This method removes the main time-consuming steps of prime number generation from the key request response path, allowing ready prime numbers to be directly retrieved from the prime number pool when a key request arrives, significantly reducing request response latency. By performing a computationally intensive but security-insensitive coarse sieve operation in a rich execution environment, it fully utilizes the multi-core computing power of the rich execution environment and system idle periods, avoiding the waste of idle computing power. The prime numbers undergo final primality verification and are encrypted and stored in the trusted execution environment, ensuring that even if the rich execution environment is compromised, the true prime numbers or the RSA private key cannot be obtained, thus preserving the security boundary intact.

[0068] See Figure 2 , Figure 2 This is a schematic diagram of the overall architecture of the RSA key generation system based on a prime number pool, provided in an embodiment of this application. Figure 2As shown, the system architecture of this application is divided into a rich execution environment (REE, i.e., Normal World) side and a trusted execution environment (TEE, i.e., Secure World) side, and the two sides communicate through shared memory and SMC (Security Monitoring Call).

[0069] The rich execution environment runs a Linux operating system and mainly includes the following functional modules: The CA (Client Application) runs in user space on the REE side and is responsible for initiating RSA key generation requests to the Prime_Pool_TA on the TEE side. The CA establishes a session with the TA through the TEE Client API, calls TEEC_InvokeCommand to send the CMD_GENERATE_RSA_KEY command, and receives the key handle returned by the TA.

[0070] The idle detection service runs on the REE side to periodically sample system load status. This service can run in Linux user space or as a kernel module, calculating the idle rate of each CPU core by reading system files such as / proc / loadavg or / proc / stat. When the system is detected to meet the idle condition, the TEEC_InvokeCommand sends the CMD_NOTIFY_IDLE command to the TEE, notifying the TEE that the system is in an idle state and prime number pool pre-generation can begin; when the system load is detected to increase, the CMD_NOTIFY_BUSY command is sent, notifying the TEE to pause pre-generation.

[0071] The coarse-sieving worker thread pool runs on the REE side and contains multiple worker threads, each bound to a different CPU core, for parallel execution of the coarse-sieving operation of prime candidate numbers. Each worker thread performs small prime division and Fermat test on the assigned candidate number in sequence, marks the candidate number that passes the coarse-sieving as a "suspected prime number", and sends it back to the TEE through the shared memory uplink buffer.

[0072] The TEE side runs the OP-TEE operating system, which mainly includes Prime_Pool_TA and related security service components.

[0073] Prime_Pool_TA is the core trusted application of this application, running in the Secure World, and includes the following sub-modules: The scheduling management module is responsible for receiving system status signals sent by the idle detection service on the REE side and controlling the start, pause, and stop of the prime number pool pre-generation process. When the CMD_NOTIFY_IDLE command is received, the scheduling management module wakes up the pre-generation process, queries the pool level, and starts pre-generation when it is below the high level threshold; when the CMD_NOTIFY_BUSY command is received, the pre-generation process is paused, and the coarse screening worker thread on the REE side is notified to enter a sleep state.

[0074] The final verification module is responsible for performing the Miller-Rabin strong primality test on the "suspected prime numbers" returned from the REE side. This module decomposes the suspected prime number by subtracting one into its odd part and corresponding exponent. It selects a random base according to the number of rounds recommended by the FIPS 186-5 standard, calculates the modular exponentiation result for each random base, and performs a square iteration. Based on the iteration result, it determines whether the suspected prime number passes the test, and confirms the candidate number that passes the test as a true prime number.

[0075] The pool manager is responsible for managing the inflow and outflow of prime numbers and monitoring the pool level. Upon inflow, the pool manager assigns a unique ID and generation timestamp to the finally verified true prime number, calls the encrypted storage module to encrypt the true prime number and perform MAC calculation, writes it to NAND Flash via OP-TEE Secure Storage, and updates the pool index. Upon outflow, the pool manager retrieves a prime number from the corresponding pool level based on the key length requested by the CA, verifies the MAC, decrypts it, and performs security constraint verification. If the verification passes, the retrieved prime number is removed from the pool index. Simultaneously, the pool level is checked to see if it falls below the low-level threshold; if so, asynchronous replenishment is triggered.

[0076] The RSA key assembly module runs on the TEE side and is responsible for obtaining the ready prime numbers p and q from the pool manager when the CA initiates a key request. Within the Secure World, it calculates the modulus n = p × q, the Euler's totient function Φ(n) = (p-1) × (q-1), and the private key exponent d = e^(-p / q). - ¹ mod The generated RSA key pair is encapsulated into a TEE_TYPE_RSA_KEYPAIR security object using the (n) and CRT parameters, and a handle is returned to the CA.

[0077] OP-TEE Secure Storage (REE-FS mode) provides encrypted persistent storage services. Encrypted prime number pool entries are written to the REE-side file system via tee-supplicant and ultimately persisted to NAND Flash. The encryption key for the stored content is managed by OP-TEE and does not appear in plaintext in the NAND Flash.

[0078] The Hardware Security Module (HSM), acting as a true random source, connects to the TEE and provides hardware-based true random numbers to the TEE in candidate number source method A. At the appropriate time, the TEE requests a batch of random numbers from the HSM via the HSM driver and sends the obtained random numbers as prime candidate numbers to the REE for coarse screening.

[0079] exist Figure 2 In the diagram, solid arrows indicate the direction of control or data flow transmission. Double arrows between the REE and TEE sides indicate bidirectional data transmission of candidate numbers and coarse screening results via shared memory, and transmission of control commands via SMC calls. The arrow between the HSM and TEE indicates the path for obtaining true random numbers.

[0080] This application separates computationally intensive but security-sensitive operations from security-sensitive operations by splitting prime number generation into two stages: coarse sieving on the REE side and final verification on the TEE side. This approach fully utilizes the multi-core computing power and idle time periods of the REE side while ensuring security. The architecture is based on the standard open-source OP-TEE implementation, requiring no modification to the underlying TEE scheduling framework, and possesses good engineering feasibility and platform portability.

[0081] Based on the above embodiments, in one feasible implementation, a lightweight idle detection service is set up on the REE side to trigger the pre-generation of the prime number pool when the system is idle. This idle detection service runs in Linux user space or a kernel module, periodically reading system files such as / proc / loadavg or / proc / stat to calculate the idle rate of each CPU core. When the idle condition is met for N consecutive seconds (e.g., 5 consecutive seconds) (e.g., all core idle rates are continuously higher than a set threshold, which can be set to 80%), the TEE system is notified of being idle via TEEC_InvokeCommand(CMD_NOTIFY_IDLE); when a system load increase is detected, CMD_NOTIFY_BUSY is immediately sent to notify the TEE system that it is busy. The threshold for determining the idle condition and the duration of continuous determination can be configured by those skilled in the art according to the actual application scenario and business characteristics.

[0082] The TA's scheduling and management module is awakened upon receiving an REE idle signal. It queries the current level of the prime number pool. If it is below the high-level threshold, the pre-generation process is initiated. The high-level threshold can be set by those skilled in the art based on system storage capacity and business requirements. For example, for each bit length level, the high-level threshold can be set to 16 prime numbers (i.e., 8 pairs) or 32 prime numbers (i.e., 16 pairs). During the pre-generation process, the TA continuously executes a loop of candidate number acquisition, REE coarse screening triggering, TEE final verification, and prime number pool entry until the pool level reaches the high-level threshold or a system busy signal is received. When a system busy signal is received, the TA pauses the pre-generation process, and the REE-side worker threads enter a sleep state to ensure that prime number pre-generation does not encroach on the computing resources of the business execution path.

[0083] Based on the above embodiments, in one feasible implementation, the prime number pool supports hierarchical management by bit length. Specifically, the pool is hierarchically managed by bit length, for example, Level-1024 (for RSA-2048), Level-1536 (for RSA-3072), and Level-2048 (for RSA-4096). Each level independently maintains a water level threshold, including a low water level threshold and a high water level threshold. For example, the low water level threshold can be set to 4 prime numbers (2 pairs), and the high water level threshold can be set to 32 prime numbers (16 pairs). The thresholds for each level can be adaptively adjusted based on the request frequency of the corresponding key for that level; for example, levels with higher request frequencies can have higher water level thresholds. REE coarse screening tasks can be sorted by hunger level, prioritizing the replenishment of the most scarce levels. Hunger level can be defined as (high water level threshold - current water level) / high water level threshold, with a larger value indicating greater scarcity.

[0084] Based on the above embodiments, in one feasible implementation, the prime number pool supports an expiration and refresh mechanism for entries within the pool. Specifically, each prime number entry in the pool carries a generation timestamp. Entries exceeding a set lifespan (e.g., 24 hours) are automatically expired and removed, avoiding the security risks associated with storing the same prime number for an extended period. The specific value of this lifespan can be set by those skilled in the art according to security policies, for example, it can be set to 12 hours, 24 hours, or 48 hours. When the module starts, it loads the persistent pool index and performs integrity verification (MAC verification) on each pool entry. Entries with abnormal verification are isolated and trigger replenishment. The prime number pool file in the NAND Flash is periodically scanned to verify its integrity. When a critical event is detected (e.g., cold start completion, OTA upgrade completion, key rotation cycle), an active refresh is triggered to update the prime numbers in the pool.

[0085] Based on the above embodiments, in one feasible implementation, the module supports rapid initialization during cold starts. Before the module is powered off, a persistent prime pool index is retained in Secure Storage. Upon power-on, during TA initialization, the pool index is loaded and integrity verification (MAC verification) is performed on each entry. Entries that pass the verification are directly restored to a usable state; corrupted entries are isolated and a replacement is triggered. Even if NAND storage failure leads to the complete loss of the pool, TA will automatically switch to the initial initialization process, quickly establishing a minimum usable pool using a lower number of Miller-Rabin tests (e.g., quickly generating a pair of prime numbers using 2 rounds of Miller-Rabin tests), and then refreshing with the full number of rounds during subsequent idle periods. This mechanism ensures that the module can quickly complete initialization and possess key generation capabilities under any extreme conditions.

[0086] Based on the above embodiments, in one feasible implementation, this application can also perform security hardening. For ASIL-B and higher levels of automotive functional safety requirements, the pool encryption key is bound to the device's unique identifier, preventing the pool content from being migrated across devices and preventing key leakage due to physical attacks. Pool access operations are audited throughout, recording each pool entry and exit event to a security log for easy security auditing and post-event traceability. When expired prime numbers are destroyed, the Secure Storage erase interface is called to securely erase the storage area, preventing key recovery attacks caused by NAND remnant recovery. Pool operation anomalies (e.g., consecutive MAC verification failures) trigger security event reporting to the system security monitoring module. Combined with a watchdog mechanism, the time constraints of the degradation path are guaranteed to be predictable, meeting the deterministic response time requirements of functional safety.

[0087] Based on the above embodiments, in one feasible implementation, this application also supports intelligent extensions for request prediction and proactive replenishment. In scenarios with known business timing (e.g., a few seconds before entering the TLS handshake phase in a vehicle startup process), the business layer sends a prompt message to the TEE via a specific command before initiating a key request. Based on this prompt message, the TA prioritizes replenishing the prime number pool at the corresponding bit length, preparing for key generation in advance. For example, in the vehicle startup process, 2 seconds before entering the TLS handshake phase, the business layer proactively triggers the TEE to prepare prime numbers, thereby further minimizing perceived latency.

[0088] In step S102, the coarse screening operation in the rich execution environment can further optimize its execution efficiency.

[0089] In one feasible implementation, the worker thread pool on the REE side employs a dynamic adjustment strategy. Specifically, the number of worker threads can be dynamically adjusted based on the current system load. When the system is highly idle, all available core worker threads are activated to maximize coarse screening throughput; as the system load increases, the number of active worker threads is gradually reduced until all are paused. The adjustment of the thread count can be achieved through coordination between idle detection and the worker thread pool management module.

[0090] In another feasible implementation, small prime number division can be performed in batches to improve efficiency. Specifically, for a batch of candidate numbers, worker threads can simultaneously perform small prime number division on that batch of candidate numbers, using SIMD (Single Instruction Multiple Data) or vectorized instruction sets to accelerate the division operation. The small prime number table can be pre-computed and stored in a cache to reduce the overhead of repeated calculations.

[0091] For the prime number pool in the above embodiments, its pre-generation process can run continuously during system idle periods. The specific process is as follows: The REE idle detection service periodically samples the idle rate of each CPU core. When the idle condition is met (e.g., all cores have an idle rate that is continuously higher than 80% for 5 seconds), an idle availability signal is sent to the TEE via an SMC call.

[0092] After the TA's scheduling and management module is awakened, it queries the current level of the prime number pool. If the current level is lower than the high level value (e.g., 32 prime numbers), the pre-generation process is initiated.

[0093] The pre-generation process first obtains candidate numbers. If method A (HSM source) is used, the TEE obtains a batch of random numbers (e.g., 32 candidate numbers) from the HSM, processes them, writes them to shared memory, and then sends them to the REE. If method B (REE local generation) is used, the TA sends a start coarse screening command to the REE worker thread pool, and the REE worker threads generate candidate numbers locally from / dev / urandom.

[0094] After receiving candidate numbers, the REE coarse-screening worker thread pool executes the coarse-screening operation in parallel. Each worker thread sequentially performs small prime number trial division (using a pre-computed small prime number table, such as the first 200 prime numbers) and Fermat test (base 2) on the candidate numbers assigned to it. Candidate numbers that pass the coarse-screening are marked as suspected prime numbers and sent back to the TEE through the shared memory uplink buffer.

[0095] The final verification module of TEE performs a Miller-Rabin strong primality test on each suspected prime number (the number of rounds is set according to the FIPS 186-5 recommendation, for example, 4 rounds for a 1024-bit prime number). Candidate numbers that pass the Miller-Rabin test are confirmed as true prime numbers and enter the pooling process: a unique ID is assigned and a timestamp is generated, the prime number is encrypted using a TA-derived key, a MAC is calculated for integrity verification, and the data is encrypted and persisted to NAND Flash via OP-TEE Secure Storage (REE-FS mode), and the pool index is updated.

[0096] The pre-generation process continues until any of the following interruption conditions are met: REE idle state changes (system becomes busy), at which point the coarse screening thread is paused; pool water level reaches the high water level threshold, at which point pre-generation stops; the time taken for this round of pre-generation reaches the preset quota (e.g., 30 seconds), at which point it actively exits and waits for the next idle signal to continue. The value of the preset quota can be set by those skilled in the art according to the system scheduling strategy to avoid the pre-generation process occupying CPU resources for a long time.

[0097] This application supports three methods for obtaining candidate numbers, which are further explained below: Method A uses candidate numbers sourced from the HSM. In this method, the TEE requests a batch of random numbers from the HSM via the HSM driver at appropriate times (e.g., during pool replenishment cycles or system idle batch acquisition). These obtained random numbers are used as candidate numbers, which are then distributed to the REE via shared memory for coarse screening. The advantage of Method A is that it provides the highest quality candidate numbers (true hardware randomness), making it suitable for scenarios with stringent randomness requirements. While the rate at which the HSM generates random numbers may be limited, the quality of the candidate numbers is guaranteed.

[0098] Method B involves candidate numbers being generated locally on the REE. In this method, REE-side worker threads generate candidate numbers locally via a Linux system random source (e.g., / dev / urandom) or an HSM interface accessible to the REE. The generated candidate numbers undergo coarse screening directly on the REE side, and those passing the coarse screening are sent to the TEE for final verification. The advantage of Method B is reduced interaction overhead between the TEE and HSM, resulting in higher throughput on the REE side. However, the randomness of the candidate numbers depends on the quality of the random source on the REE side. In terms of security, even if the REE is compromised and malicious candidate numbers are injected, the TEE's Miller-Rabin final verification will reject any non-true prime numbers; the worst-case scenario is only a denial of service, without revealing the private key.

[0099] Mode C is a hybrid mode. In Mode C, Mode A (HSM source) is used during the initial system startup or in scenarios with high security requirements, while Mode B (REE local generation) is used during steady-state operation when high throughput replenishment of the pool is needed. The two modes can be dynamically switched based on the pool level and security policies. For example, a time threshold can be set; when the last generation time of prime numbers in the pool exceeds this threshold, Mode A is switched for a deep refresh; when there are sufficient prime numbers in the pool and they are all recently generated, Mode B is used for regular replenishment. This hybrid mode balances security and performance and is the recommended solution for most T-Box deployments.

[0100] It should be noted that this application is not only applicable to automotive T-Box modules, but can also be extended to various other embedded scenarios, such as: In industrial IoT terminal scenarios, devices such as PLCs (Programmable Logic Controllers), industrial gateways, and remote monitoring terminals are also based on a TEE plus external storage architecture, have system idle periods, and require fast key generation response times. This application can be directly applied to these devices, utilizing their idle periods to pre-generate prime numbers, thereby accelerating the acquisition of RSA keys.

[0101] In smart home gateway scenarios, devices such as routers and home gateways need to establish secure encrypted communication channels, which also faces the challenge of time-consuming RSA key generation. This application can help these devices pre-generate prime numbers at night or during low-load periods, enabling a rapid response when a secure connection needs to be established.

[0102] In medical IoT device scenarios, remote medical terminals and wearable medical devices require protection of the confidentiality and integrity of patient data, placing high demands on both security and response speed. This application can improve key acquisition speed while ensuring security.

[0103] In smart metering scenarios, metering devices such as smart electricity meters, water meters, and gas meters need to securely communicate with the cloud and periodically report metering data. These devices are typically resource-constrained and have limited computing power. This application addresses this by offloading computationally intensive coarse screening operations to the REE (Electronic Receptacle Equipment) side for multi-core parallel execution, effectively reducing the computational burden on the TEE side and improving overall efficiency. These scenarios share common characteristics: they are all resource-constrained embedded platforms, use TEE as a security boundary, have system idle periods, and require fast key generation response times.

[0104] In one feasible implementation, each prime number entry in the prime number pool has full lifecycle management.

[0105] The lifecycle of a prime number entry includes the following stages: generation (generated through a pre-generation process), pooling (written to persistent storage via S104), residence (waiting to be retrieved in the pool), retrieval (retrieved from the pool via S105), expiration (removed after exceeding the set lifespan), and destruction (deleted from persistent storage).

[0106] During the residency phase, prime number entries are protected by multiple layers of security: encrypted storage ensures confidentiality, MAC guarantees integrity, and a pool index ensures traceability. Periodic scanning tasks (e.g., every 6 hours) check the integrity and validity of all entries in the pool, and any abnormal entries are immediately isolated.

[0107] For expiration handling, the TA maintains a scheduled task that periodically checks the generation timestamps of entries in the pool, marking entries that have exceeded their lifespan (e.g., 24 hours) as expired and removing them from the pool. Upon removal, the TA calls the delete interface to remove the corresponding persistent object from the NAND Flash and update the pool index. The specific lifespan value can be set by those skilled in the art according to security policies; for example, it can be set to 12 hours, 24 hours, or 48 hours. A shorter lifespan can improve security (reducing the risk of long-term exposure) but increases the computational overhead of pre-generation; a longer lifespan can reduce computational overhead but decrease security. The choice of specific value needs to strike a balance between security and performance.

[0108] In one feasible implementation, when the prime pool is empty or there are insufficient primes to meet the key generation request, TA automatically triggers a degradation path to ensure that the scheme can complete key generation under any circumstances.

[0109] The specific process of the degradation path is as follows: After receiving the RSA key generation request from the CA, the TA queries the prime number pool at the corresponding bit length level and finds that the number of prime numbers in the pool is insufficient (e.g., less than 2, i.e., less than a pair). The TA immediately starts the synchronous generation mode: within the Secure World, it calls the standard RSA key generation process (the same as the existing OP-TEE scheme), including candidate number generation, small prime number trial division, Miller-Rabin test, key assembly, etc., and returns the completed key generation to the CA. The only difference between this degradation path and the existing scheme is that after the degradation path is completed, the TA will asynchronously trigger the pool replenishment process to restore the prime number pool level as soon as possible.

[0110] The degradation path ensures the functional availability of the proposed solution under worst-case conditions, meeting the functional safety requirements of the vehicle system. During the execution of the degradation path, the request response latency of CA is the same as that of the traditional solution, but this only occurs in extreme cases (when the pool is completely empty). Under normal operating conditions, the pool usually maintains a sufficient number of prime numbers, and CA requests can obtain a response with near-zero latency.

[0111] See Figure 3 , Figure 3 This is a schematic diagram of an RSA key generation system based on a prime number pool, provided in an embodiment of this application. This application also provides an RSA key generation system based on a prime number pool, which is used to execute the steps in the above method embodiments. The system includes: a candidate number acquisition module, a coarse screening module, a primality verification module, a prime number pool management module, and a key generation module.

[0112] The candidate number acquisition module is used to obtain prime number candidates. This module supports multiple candidate number sources, including obtaining random numbers from a hardware security module as prime number candidates, and generating random numbers from a system random source in a rich execution environment. The two methods can be used individually or in combination depending on security policies and performance requirements.

[0113] The coarse sieving module is used to coarsely sieve candidate prime numbers in a rich execution environment to obtain potential prime numbers. The coarse sieving module includes: a thread startup unit, used to start multiple worker threads in the rich execution environment and bind each worker thread to a different CPU core; a trial division unit, used by each worker thread to perform small prime division on the candidate prime numbers, eliminating those that fail the small prime division test; and a Fermat test unit, used to calculate the Fermat pseudoprime test value of the candidate prime numbers that pass the small prime division test with a set base, and determine whether the candidate prime number passes the Fermat test based on the test value, identifying those that pass as potential prime numbers.

[0114] The primality verification module sends suspected prime numbers to a trusted execution environment (TEX). Within the TEX, the suspected prime numbers are verified for primality to determine true prime numbers. Specifically, in the TEX, the module subtracts one from the suspected prime number and decomposes it into its odd-numbered portion and corresponding exponent. It then selects a random base based on a set number of rounds, calculates the modulo exponentiation for each random base, and performs a square iteration. Based on the iteration results, it determines whether the suspected prime number passes the Miller-Rabin primality test. Suspected prime numbers that pass the Miller-Rabin primality test are designated as true prime numbers.

[0115] The prime number pool management module is used to encrypt true prime numbers and write the encrypted true prime numbers into the prime number pool. The prime number pool management module includes: an encryption unit, used to encrypt true prime numbers using a derived key to obtain encrypted prime numbers; a MAC calculation unit, used to calculate the message authentication code based on the encrypted prime numbers; and a writing unit, used to write the encrypted prime numbers and the message authentication code to persistent storage and update the pool index of the prime number pool.

[0116] The key generation module receives RSA key generation requests, retrieves prime numbers from the prime number pool, and generates RSA keys based on these prime numbers. The process of retrieving prime numbers from the prime number pool includes: reading encrypted prime numbers and their corresponding message authentication codes from the pool; verifying the message authentication codes; decrypting the encrypted prime numbers to obtain the prime numbers to be used after successful verification; performing security constraint verification on the prime numbers to be used; selecting the prime numbers that satisfy the security constraints as the retrieved prime numbers; and removing the retrieved prime numbers from the pool index of the prime number pool.

[0117] The system also includes a pool level determination module and a degradation generation module. The pool level determination module determines whether the number of prime numbers in the pool is below a set value before retrieving prime numbers from the pool. The degradation generation module performs a coarse screening of candidate prime numbers in a rich execution environment when the number of prime numbers in the pool is below the set value, verifies the primality of the suspected prime numbers obtained from the coarse screening in a trusted execution environment, and generates an RSA key based on the verified prime numbers.

[0118] The specific implementation methods of each module of the above system can be referred to the corresponding descriptions in the foregoing method embodiments, and will not be repeated here.

[0119] This application also provides an embodiment of a computer-readable storage medium and a computer program product. Both the computer-readable storage medium and the computer program product may store a computer program that, when executed by a processor, implements the steps of the method described in the above method embodiments.

[0120] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0121] The computer-readable storage medium provided in this embodiment includes computer programs that implement the corresponding embodiments of the above methods, and the effects are the same as above.

[0122] This application also provides an electronic device, see [link to document]. Figure 4 The present application provides a structural diagram of an electronic device, such as... Figure 4As shown, it may include a processor 1410 and a memory 1420.

[0123] The processor 1410 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 1410 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1410 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1410 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 1410 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0124] The memory 1420 may include one or more computer-readable storage media, which may be non-transitory. The memory 1420 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 1420 is used to store at least the following computer program 1421, which, after being loaded and executed by the processor 1410, is capable of implementing the relevant steps in the methods executed by the electronic device side as disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 1420 may also include an operating system 1422 and data 1423, etc., and the storage method may be temporary storage or permanent storage. The operating system 1422 may include Windows, Linux, Android, etc.

[0125] In some embodiments, the electronic device may further include a display screen 1430, an input / output interface 1440, a communication interface 1450, a sensor 1460, a power supply 1470, and a communication bus 1480.

[0126] certainly, Figure 4 The structure of the electronic device shown does not constitute a limitation on the electronic device in the embodiments of this application. In practical applications, the electronic device may include more than [other components]. Figure 4 More or fewer components as shown, or combinations of certain components.

[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. As the system provided in the embodiments corresponds to the method provided in the embodiments, the description is relatively simple; relevant parts can be found in the method section.

[0128] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand this application and its core ideas. It should be noted that for those skilled in the art, several improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0129] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for generating RSA keys based on a prime number pool, characterized in that, include: Obtain candidate prime numbers; In a rich execution environment, the candidate prime numbers are coarsely screened to obtain suspected prime numbers; The suspected prime number is sent to a trusted execution environment, where its primality is verified to obtain a true prime number. The true prime number is encrypted, and the encrypted true prime number is written into the prime number pool. Receive an RSA key generation request, retrieve a prime number from the prime number pool, and generate an RSA key based on the prime number.

2. The RSA key generation method based on prime number pooling according to claim 1, characterized in that, In a rich execution environment, the candidate prime numbers are coarsely screened to obtain the following potential prime numbers: In the rich execution environment, multiple worker threads are started, and each worker thread is bound to a different CPU core; Each of the aforementioned working threads performs small prime number division on the prime candidate numbers, eliminating prime candidate numbers that fail the small prime number division test. For the prime candidate numbers that can be divided by the small prime number, calculate the Fermat pseudoprime test value of the prime candidate numbers with a set base, and determine whether the prime candidate numbers pass the Fermat test based on the test value. The prime candidate numbers that pass the Fermat test are taken as the suspected prime numbers.

3. The RSA key generation method based on prime number pooling according to claim 1, characterized in that, The step of verifying the primality of the suspected prime numbers in a trusted execution environment to obtain true prime numbers includes: In the trusted execution environment, the suspected prime number is decomposed into an odd part and a corresponding exponent after being reduced by one. A random base is selected according to a set number of rounds. The modulo exponentiation result is calculated for each random base and a square iteration is performed. The Miller-Rabin primality test is determined based on the iteration result. The suspected prime numbers that pass the Miller-Rabin primality test are considered true prime numbers.

4. The RSA key generation method based on prime number pooling according to claim 2, characterized in that, Writing the encrypted true prime numbers into the prime number pool includes: The true prime number is encrypted using a derived key to obtain an encrypted prime number; Calculate the message authentication code based on the encrypted prime number; Write the encrypted prime number and the message authentication code to persistent storage, and update the pool index of the prime number pool.

5. The RSA key generation method based on prime number pooling according to claim 3, characterized in that, Retrieving prime numbers from the prime number pool includes: Read the encrypted prime number and its corresponding message authentication code from the prime number pool; The message authentication code is verified. After the verification is successful, the encrypted prime number is decrypted to obtain the prime number to be used. The prime numbers to be used are subjected to security constraint verification. The prime numbers that satisfy the security constraints are selected as the prime numbers, and the prime numbers that have been used are removed from the pool index of the prime number pool.

6. The RSA key generation method based on prime number pooling according to claim 4, characterized in that, Obtain candidate prime numbers, including: A random number is obtained from the hardware security module, and the obtained random number is used as the prime number candidate. Alternatively, in the rich execution environment, a random number is generated based on the system's random source, and the generated random number is used as the prime candidate number.

7. The RSA key generation method based on prime number pooling according to claim 5, characterized in that, Before retrieving prime numbers from the prime number pool, the process also includes: Determine whether the number of prime numbers in the prime number pool is lower than a set value; When the number of prime numbers in the prime pool is lower than the set value, the prime candidate numbers are coarsely screened in the rich execution environment, and the primality of the suspected prime numbers obtained from the coarse screening is verified in the trusted execution environment. An RSA key is generated based on the verified prime numbers.

8. An RSA key generation system based on a prime number pool, characterized in that, include: The candidate number acquisition module is used to acquire prime number candidates; The coarse screening module is used to coarsely screen the candidate prime numbers in a rich execution environment to obtain suspected prime numbers. The primality verification module is used to send the suspected prime number to a trusted execution environment, and to perform primality verification on the suspected prime number in the trusted execution environment to obtain the true prime number; The prime number pool management module is used to encrypt the true prime numbers and write the encrypted true prime numbers into the prime number pool. The key generation module is used to receive an RSA key generation request, retrieve a prime number from the prime number pool, and generate an RSA key based on the prime number.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the method as described in any one of claims 1 to 7.

Images