Private key full-life-cycle security management system and method based on mobile terminal anti-quantum cryptography algorithm

Abstract

The invention provides a private key full-life-cycle security management system and method based on a mobile terminal anti-quantum cryptography algorithm. The method comprises the following steps: generating a key pair based on the anti-quantum cryptography algorithm; acquiring a certificate containing a public key in the key pair; calling a mobile terminal key management system to generate a symmetric encryption key, encrypting a private key in the key pair by using the symmetric encryption key, storing the encrypted private key into a sandbox, and storing a certificate into the sandbox; extracting a private key and a certificate in the encrypted key pair from the sandbox, calling the hardware-level key management system, and decrypting the private key by using the symmetric encryption key to obtain a decrypted private key; calling an interface matched with the purpose of the private key through a preset anti-quantum algorithm library, and executing signature, signature verification or key exchange operation by using the decrypted private key; and after the operation is completed, clearing the memory area for storing the private key plaintext. According to the method, the life cycle of the anti-quantum private key can be safely managed on the premise of not depending on the native support of a mobile system.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of anti-quantum cryptography (PQC) technology applied in mobile terminals, and particularly relates to a private key full life cycle security management system and method based on a mobile terminal anti-quantum cryptography algorithm. BACKGROUND

[0002] With the rapid iteration of quantum computing technology, the traditional RSA and ECC public key cryptography system is facing a fundamental security threat. A quantum computer can efficiently crack the mathematical basis of the above-mentioned traditional cryptography, resulting in the failure of the existing key exchange, data encryption, and identity authentication mechanism relying on such algorithms, which poses a major risk to the digital security system. In order to cope with potential quantum attacks in advance, NIST has led the selection of PQC (Post-Quantum Cryptography) standards that resist quantum computing attacks, and has determined algorithms such as Dilithium and Kyber as anti-quantum public key cryptography standards. These algorithms are designed based on lattice cryptography and other anti-quantum mathematical problems, and can resist quantum computing attacks, providing an algorithmic basis for the quantum resistance upgrade of the digital security system.

[0003] However, in mainstream mobile operating systems, the Android platform currently has no native support for the above-mentioned NIST PQC standard algorithms, forming a technical landing bottleneck. The mainstream TEE / Keystore does not support Dilithium or Kyber, making it difficult to securely store anti-quantum keys, especially in scenarios such as finance, government affairs, and vehicle-mounted systems that have extremely high requirements for key security, the deployment of PQC poses serious challenges.

[0004] One of the existing technologies is to use a PQC library (such as PQClean) to generate a private key completely in the application layer and store it in plaintext; however, this technology has the following problems: lack of hardware isolation, the private key may be stolen by a Root application or malicious debugger; no recovery mechanism, the private key is lost after resetting the device; no life cycle management, easy to be intercepted or misused.

[0005] The second existing technology is to compile the PQC algorithm into a TEE (Trusted Execution Environment) system, and the TEE generates the key and encapsulates the use interface; however, this technology has the following problems: the TEE firmware needs to be modified, which is costly and has poor universality; lacks standardized support, making cross-device adaptation difficult; some devices do not support TEE upgrades or open API calls. SUMMARY

[0006] In order to solve the problems raised in the background art, the life cycle of anti-quantum private keys (such as Dilithium private keys) can be managed securely without relying on the native support of the Android system. The present application provides a private key full life cycle security management system and method based on a mobile terminal anti-quantum cryptography algorithm.

[0007] A private key full life cycle security management system based on a mobile terminal anti-quantum cryptographic algorithm, which achieves one of the purposes of the present application, comprises:

[0008] A key and certificate generation module: configured to generate a key pair based on an anti-quantum cryptographic algorithm, and to obtain a certificate containing a public key in the key pair;

[0009] A sandbox storage module: configured to call a hardware-level key management system of the mobile terminal to generate a symmetric encryption key, to encrypt a private key in the key pair using the symmetric encryption key and store the encrypted private key in a sandbox, and to store the certificate in the sandbox; the sandbox provides an isolated secure storage space for a mobile application to which the system belongs and which implements an anti-quantum private key full life cycle security management function, and only allows the mobile application to access the private key and the certificate stored in the sandbox through a secure interface that is pre-set and adapted to a sandbox security access logic; the hardware-level key management system refers to a system component pre-installed in a mobile terminal device at the factory, which implements key security control based on hardware isolation technology, such as the AndroidKeystore system in the Android system;

[0010] A key and certificate usage module: configured to take out the encrypted private key and the certificate in the key pair from the sandbox, to call the hardware-level key management system, to decrypt the private key using the symmetric encryption key to obtain a decrypted private key, to call an interface matched with the purpose of the private key through a pre-set anti-quantum algorithm library, to perform a signature, verification or key exchange operation using the decrypted private key, and to clear a memory area storing the plaintext of the private key after the operation is completed.

[0011] Further, the system further comprises a secure storage module configured to generate an integrity tag for data integrity according to the private key and the certificate in the key pair, to encapsulate the private key, the certificate and the integrity tag into a data packet in a pre-set data format (such as TLV format), and to write the data packet into a special hardware storage unit of the mobile terminal that has anti-replay protection and tamper detection functions; the special hardware storage unit needs to be authorized and verified based on a non-exportable key configured at the factory when it is accessed. The technical effects include: providing persistent hardware backup for the private key and the certificate through anti-replay protection and device factory key authorization verification, solving the problem of loss of sandbox files due to recovery of factory settings and clearing of application data, and realizing data recovery when the sandbox is disabled.

[0012] Further, in the secure storage module, the unencrypted private key and certificate in the key pair are transmitted to the trusted execution environment; a symmetric key is generated in the trusted execution environment, the symmetric key is stored in a non-exportable secure storage area of the trusted execution environment (such as TEE), only command calls for integrity tag calculation are allowed, and the symmetric key cannot be exported through any interface; the private key and the certificate are calculated by a preset security level message authentication code algorithm based on the symmetric key through the trusted execution environment, and an integrity tag for data integrity is generated; the preset security level message authentication code algorithm needs to meet: the digest output length is not less than 256 bits, and has anti-collision property; the preset security level message authentication code algorithm based on the symmetric key can be an HMAC algorithm; the hash function used by the HMAC algorithm is a SHA2 series hash function or a SHA3 series hash function, and the digest output length is 384 bits or 512 bits. The technical effects include: having anti-collision property, resisting data forgery attack caused by tag tampering.

[0013] Further, before calculating the integrity tag, the method further comprises, inside the trusted execution environment, compressing the private key and the certificate by using a preset lightweight data compression algorithm; the preset lightweight data compression algorithm is a compression algorithm based on the LZ77 series, including any one of LZ4 algorithm, LZ4 high compression rate version (LZ4HC) or Snappy algorithm. The technical effects include: saving storage resources.

[0014] Further, in the key and certificate generation module, the method for generating a key pair comprises:

[0015] In a mobile application implementing quantum-resistant private key full-life-cycle security management function, a PQClean open source library and a Bouncy Castle PQC library are integrated; the mobile application obtains a storage permission for temporarily storing a non-sensitive intermediate file in a key generation process in a mobile system;

[0016] The mobile application calls a preset quantum-resistant key generation module in the PQClean open source library to generate a key pair based on a quantum-resistant cryptographic algorithm, the key pair including a private key and a public key; the quantum-resistant cryptographic algorithm is a lattice-based cryptographic algorithm, and the quantum-resistant key generation module in the PQClean open source library includes a function for executing lattice-based cryptographic algorithm key generation logic.

[0017] The technical effects of the above method for generating a key pair include: avoiding invalid keys caused by hardware random number abnormalities; and preventing key generation process from being stolen by memory monitoring tools.

[0018] Further, in the key and certificate generation module, the method for obtaining a certificate comprises:

[0019] In a mobile application implementing an anti-quantum private key full life cycle security management function, the Bouncy Castle PQC library is integrated; the mobile application obtains the request permission for submitting a certificate request to a certificate authority in a mobile system; based on the public key of the key pair, an anti-quantum signature generation component is constructed through the Bouncy Castle PQC library, which is configured to: use a preset anti-quantum cryptographic algorithm to sign the public key of the key pair and the identity information provided by the mobile application, generate an anti-quantum certificate signature request, and submit the certificate signature request to the certificate authority through a preset encrypted channel (such as a TLS1.3 channel); the certificate signature request conforms to a preset certificate signature request format standard, which can be recognized by the target certificate authority, and the preset certificate signature request format standard includes X.509 and other compatible standards;

[0020] Receiving the certificate returned by the certificate authority based on the anti-quantum algorithm, the certificate containing the public key and the anti-quantum signature of the certificate authority.

[0021] The technical effects of the method for obtaining the certificate include: ensuring that the signature process has anti-quantum capability, and using an encrypted channel to avoid eavesdropping of the certificate signature request transmission, while the certificate signature request contains an anti-quantum algorithm identification extension field, ensuring that the certificate authority can correctly identify and issue the certificate.

[0022] Further, in the sandbox storage module, the hardware-level key management interface (such as Android Keystore API) of the mobile terminal is called to generate a symmetric encryption key for encrypting the private key, the symmetric encryption key is configured to be non-exportable and only allowed to be called through the hardware-level key management interface to perform encryption and decryption operations; a preset symmetric encryption algorithm (such as AES-GCM) is used to encrypt the private key using the symmetric encryption key, generating a private key ciphertext and an authentication tag for verifying the integrity of the private key, and the memory area storing the private key plaintext is emptied after encryption; the private key ciphertext, the authentication tag and the certificate are stored in the sandbox, the access permission of the sandbox is configured to only allow the mobile application implementing the anti-quantum private key full life cycle security management function of the system to read or modify the storage content, and the integrity verification information of the private key ciphertext, the authentication tag and the certificate is recorded. The technical effects include: the symmetric encryption algorithm provides encryption and integrity protection, and the authentication tag can verify whether the private key ciphertext has been tampered with during decryption; the sandbox permission avoids illegal access to the private key in the sandbox by other applications.

[0023] Further, a file integrity detection module is further included, configured to, when the mobile application is started, call a preset integrity verification mode, calculate current file feature identifiers of the private key ciphertext, the authentication tag and the certificate stored in the sandbox, compare the current file feature identifiers with historical file feature identifiers recorded in the integrity verification information in the sandbox, if the comparison is consistent, allow the key and certificate using module to perform subsequent operations, and if the comparison is inconsistent, terminate the subsequent operations of the key and certificate using module and trigger a security prompt. The technical effects include: avoiding using a tampered private key to cause invalid signature or using a missing file to cause business interruption, and improving application startup security.

[0024] Further, a key and certificate recovery module is further included, configured to, when the private key and the certificate in the sandbox are missing or invalid, recover the private key and the certificate by using the data packet stored in the special hardware storage unit, and the recovery process includes:

[0025] reading the data packet previously stored in the special hardware storage unit;

[0026] performing integrity verification on the data packet in the trusted execution environment, if the verification is passed, performing decompression on the compressed data in the data packet by using a decompression algorithm matched with the preset lightweight data compression algorithm, and separating the original private key based on the quantum-resistant algorithm and the certificate generated based on the quantum-resistant algorithm in a preset data format (such as TLV format); the integrity verification includes: calling a pre-generated symmetric key used for integrity tag calculation from a non-exportable secure storage area of the trusted execution environment, calculating a new integrity tag for the compressed data segment in the data packet by using a preset security level message authentication code algorithm, comparing the new integrity tag with the integrity tag encapsulated in the data packet, and confirming that the compressed data has not been tampered with;

[0027] The application layer generates a non-exportable symmetric encryption key through a hardware-level key management interface of the mobile terminal, the symmetric encryption key is bound to the mobile application currently implementing the quantum-resistant private key full life cycle security management function and is limited to use for encryption and decryption;

[0028] The symmetric encryption key is used to encrypt the recovered private key based on the quantum-resistant algorithm to generate private key ciphertext and an authentication tag; after the encryption is completed, the memory area storing the private key plaintext is cleared;

[0029] The private key ciphertext, the authentication tag and the recovered certificate generated based on the quantum-resistant algorithm are written into the exclusive sandbox of the mobile application, and the sandbox access permission is configured to be only the mobile application operable.

[0030] The technical effects of the key and certificate recovery module include: avoiding the recovered data from being monitored by a non-secure world; and re-generating a non-derivable key to encrypt the private key, so as to ensure that the recovered private key is still under hardware-level protection.

[0031] Further, before writing the private key ciphertext, the authentication tag, and the recovered certificate generated based on the anti-quantum algorithm into the exclusive sandbox of the mobile application, the method further includes: calculating file feature identifiers of the private key ciphertext, the authentication tag, and the recovered certificate generated based on the anti-quantum algorithm, respectively; associating each file feature identifier with a file unique identifier of the corresponding independent file to form file integrity check information; and recording the file integrity check information to an integrity check record file in the sandbox. The technical effects include: the files are associated by the file unique identifiers, so that the tampered files can be quickly located during subsequent detection.

[0032] Further, in the key and certificate use module, the mobile application reads the stored encrypted private key file, the authentication tag, and the certificate from the exclusive sandbox thereof, extracts the initialization vector and the private key ciphertext in the encrypted private key file; calls a hardware-level key management interface of the mobile terminal, uses the symmetric encryption key to perform decryption on the private key ciphertext, and generates a private key plaintext based on the anti-quantum algorithm; after the decryption is completed, the memory area storing the private key plaintext is cleared; validity check is performed on the certificate, the check content includes certificate validity period, certificate chain integrity, and validity of a signature of an issuing authority, and after the check passes, the certificate is used for identity authentication; a corresponding algorithm interface is called through a preset anti-quantum algorithm library (such as a PQClean open source library or a Bouncy Castle PQC library), and signature, signature verification, or key exchange operations are performed using the private key plaintext. The technical effects include: ensuring that the used certificate is legal and valid, and avoiding identity authentication failure caused by using an expired or fake certificate.

[0033] Further, when the mobile application is started next time, the method further includes: calculating current file feature identifiers of the recovered and stored private key ciphertext, the authentication tag, and the certificate in the sandbox, and calling corresponding historical file feature identifiers associated with the file unique identifiers in the integrity check record file in the sandbox for comparison; if the comparison is consistent, it is confirmed that the recovered files have not been tampered with, and the key and certificate use module is allowed to call the private key ciphertext, the authentication tag, and the certificate; otherwise, the key and certificate recovery module is triggered to re-execute the recovery process. The technical effects include: confirming that the recovered files have not been tampered with a second time, further improving the security of the recovery process, and avoiding the implicit risk that the recovery is successful but the files have been tampered with.

[0034] A private key full life cycle security management method based on a mobile terminal anti-quantum cryptographic algorithm for achieving the second purpose of the application includes:

[0035] Generate a key pair based on an anti-quantum cryptography algorithm; obtain a certificate containing a public key in the key pair;

[0036] Call the mobile key management system to generate a symmetric encryption key, encrypt the private key in the key pair using the symmetric encryption key and store it in the sandbox, and store the certificate in the sandbox;

[0037] Take out the encrypted private key in the key pair and the certificate from the sandbox, call the hardware-level key management system, decrypt the private key using the symmetric encryption key, and obtain the decrypted private key; call the interface matched with the purpose of the private key through a pre-set anti-quantum algorithm library, and use the decrypted private key to perform signature, signature verification or key exchange operation; after the operation is completed, the memory area storing the plaintext of the private key is cleared.

[0038] A non-transitory computer readable storage medium for achieving the third object of the present application, which stores a computer program, and the computer program is executed by a processor to implement the steps of the private key full life cycle security management method based on the mobile anti-quantum cryptography algorithm.

[0039] A computer program product for achieving the fourth object of the present application, comprising a computer program / instruction, which is executed by a processor to implement the steps of the private key full life cycle security management method based on the mobile anti-quantum cryptography algorithm.

[0040] The beneficial effects of the present application include:

[0041] 1. The present application integrates PQClean / Bouncy Castle PQC open source library, without modifying the trusted execution environment (TEE) firmware, reducing the cross-device adaptation cost;

[0042] 2. The present application relies on the technical features of the non-exportable key of Android Keystore, the technical features of the hardware isolated operation of TEE, and the technical features of the anti-replay + authorized access of RPMB, to build a multi-level hardware security system, so that the private key is always in a hardware isolation area and is not stolen by malicious programs;

[0043] 3. The whole process of the technical solution of the present application solves the problems of no recovery mechanism, easy loss and abuse of private keys in the prior art, and ensures the continuity and security of the private key;

[0044] 4. The present application adopts a multiple verification mechanism of data packet format verification, HMAC-SHA3-512 label integrity verification and sandbox file verification, verifies the data integrity from the whole link of data packet encapsulation, RPMB storage to sandbox use, and avoids the private key or certificate from being tampered with for illegal operation;

[0045] 5、The application does not rely on the TEE firmware of specific equipment manufacturers, is based on a standardized interface, can be adapted to mainstream mobile devices, and can be fully compatible with existing digital certificate systems. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 is a schematic diagram of the system described in the application;

[0047] Figure 2 is a schematic diagram of the key and certificate generation process;

[0048] Figure 3 is a schematic diagram of the process of storing the private key and certificate to the TEE.

[0049] Figure 4 is a schematic diagram of the process of storing the private key and certificate to the sandbox;

[0050] Figure 5 is a schematic diagram of the process of restoring the private key and certificate. DETAILED DESCRIPTION

[0051] The following detailed description is used to explain the technical solutions of the application, so that those skilled in the art can understand the application. The protection scope of the application is not limited to the following specific implementation structures. The technical solutions of the application contained in the following specific implementation structures, which are different from the following specific implementation structures, are also within the protection scope of the application.

[0052] A private key full life cycle security management method based on a mobile terminal anti-quantum cryptographic algorithm, comprising the following steps:

[0053] Step 1, secret key generation and certificate issuance

[0054] As shown in the flowchart in Figure 1 , secret key generation and certificate issuance include the following steps:

[0055] (1) Application layer environment initialization

[0056] Specifically, the PQClean open source library and the Bouncy Castle PQC library are integrated in a mobile application that implements an anti-quantum private key full life cycle security management function, it is ensured that the mobile application has obtained WRITE_EXTERNAL_STORAGE permission and INTERNET permission of an Android system, and a permission application process meets dynamic permission requirements of an Android version; the WRITE_EXTERNAL_STORAGE permission is used for temporarily storing non-sensitive cache files related to a key pair, including encrypted intermediate files in a key generation process and public key backup files that do not need to be stored for a long time; and the INTERNET permission is used for submitting a CSR (Certificate Signing Request, a signature request generated when a certificate is applied to a CA, including a public key and identity information) to a CA (Certificate Authority); in particular, the mobile application can be a mobile application for a sensitive scenario such as finance and government affairs, and needs to be protected by an anti-quantum password to ensure private key security.

[0057] (2) PQClean generates a key pair: at the application layer, a key pair (such as Dilithium) is generated by calling the PQClean library; specifically, the following steps are included:

[0058] In a secure sub-thread outside the main thread at the application layer, the pqcrystals_dilithium3_ref_keypair function of the PQClean library is called to initialize parameters such as a security level and a key length.

[0059] The generated Dilithium private key (sk) and public key (pk) are only stored in an encrypted cache area in the application layer memory, and are not written into any persistent storage, so as to avoid key leakage. In an embodiment, the encrypted cache area is encrypted based on an AES-256-GCM algorithm, an encryption key is temporarily generated through an Android Keystore, and only the secure sub-thread is allowed to access; the cache area is created in the form of a custom encrypted byte array, and a temporary key is obtained and encryption configuration is completed by calling a Keystore interface during initialization.

[0060] In an embodiment, the pqcrystals_dilithium3_ref_sign_open function of the PQClean library is called to verify a signature of a piece of random test data using the generated public key, if the verification is passed, it is confirmed that the key pair is valid, otherwise the key generation process is triggered again; the key generation process is triggered at most 3 times to avoid key invalidation caused by abnormal hardware random number generation.

[0061] (3) Generating a CSR based on the BC PQC self-defined signer: based on the Dilithium public key and the identity information provided by the application, a certificate signing request (CSR) is generated using the BC PQC library self-defined signer. The anti-quantum security of the CSR application process is ensured, specifically including:

[0062] The DilithiumCSRSigner class is created, which inherits the X509Extension class of the BC PQC library and implements the Singer interface. The createSigner() method is rewritten, which internally binds the generated Dilithium private key through the PQCleanSignature class used for custom packaging of the PQClean signature interface, so that the private key is only used for CSR signature and is not exposed externally. When instantiating the PQCleanSignature class, the Dilithium private key binary data and the Dilithium-III parameter set are passed in. The private key is transmitted through the Keystore temporary key encryption;

[0063] The following identity information is filled in the CSR:

[0064] Subject name (Subject): application package name, such as CN = com.example.pqcfinance; device unique identifier, such as Android ID, obtained through Settings.Secure.ANDROID_ID, which can be hashed to avoid privacy leakage); application subject type, such as O = FinancialApp;

[0065] Add an anti-quantum algorithm identification extension field, such as the field value Dilithium-III, which is used to identify the PQC algorithm type corresponding to the CSR by the CA;

[0066] Call the generate() method of DilithiumCSRSigner, use the SHA-384 hash algorithm matching the Dilithium-III parameter set to hash the CSR information, and then sign it with the Dilithium private key; after signing, convert the CSR to PEM format.

[0067] (4) Apply for a certificate: submit the CSR to the designated certificate authority (CA), and the CA issues a Dilithium certificate based on the CSR, which contains the public key and identity information, and the application layer receives the certificate. Specifically including:

[0068] Submit the PEM format CSR to the certificate application interface of the designated CA through an encrypted channel (such as TLS1.3); in an embodiment, it also includes Base64 encoding the CSR before transmission to avoid character parsing exceptions during transmission;

[0069] The CA side verifies the validity of the CSR signature by the Dilithium public key, confirms the identity information, and generates an X.509 certificate containing the Dilithium public key. The extension field of the certificate needs to contain the anti-quantum algorithm identifier and be consistent with the CSR extension field.

[0070] In an embodiment, after the application layer receives the PEM format certificate returned by the CA, the certificate is verified, and the verification steps include:

[0071] The JcaX509CertificateConverter class of the BC PQC library is called to load the CA root certificate, and it is verified whether the CA signature of the target certificate is valid;

[0072] It is checked whether the issuer field of the certificate matches the subject field of the CA root certificate to ensure that the certificate chain is not broken;

[0073] It is confirmed that the notBefore and notAfter fields of the certificate are within the current time range, and the signatureAlgorithm field is the Dilithium algorithm OID;

[0074] In an embodiment, the certificate that passes the verification is converted into an X509 Certificate object and stored in the application layer memory buffer area, and is associated with the generated Dilithium private key through a unified key ID, which is used for subsequent private key and certificate storage to the TEE (Trusted Execution Environment, a trusted execution environment independent of the Android main system, providing secure key use and isolation); the unified key ID is generated by MessageDigest hashing the private key to generate a 16-byte ID.

[0075] Step two, store the private key and certificate to the TEE

[0076] As shown in the flowchart, storing the private key and certificate to the TEE includes the following steps: Figure 3

[0077] (1) LZ4HC compression: by calling the TEE, the original unencrypted Dilithium private key and certificate are compressed by LZ4HC. This step can compress the size of the private key and certificate by about one time; specifically including:

[0078] ​In the application layer, the Dilithium private key generated in step 1 is spliced with the Dilithium certificate passed by verification in the TLV (Type-Length-Value) format; in an embodiment, the Type field of the private key is 0x01, the Length field is the actual length of the private key, and the Value field is the binary data of the private key; the Type field of the certificate is 0x02, the Length field is the actual length of the certificate, and the Value field is the DER data of the certificate, and the purpose of using the TLV format is to avoid confusion between the decompressed private key and the certificate;

[0079] The application layer initializes the TEE context through the TEEC_InitializeContext function and specifies the TEE vendor ID; establishes a secure session with the PQC security storage service defined in the TEE through the TEEC_OpenSession function, and ensures that the subsequent interaction is isolated from the non-secure world;

[0080] The TEE sends a compression command through the TEEC_InvokeCommand function, encapsulates the input parameters, configures the compression parameters in the TEE, and processes the output parameters; the input parameters adopt the TEE_Param structure, the type is set to TEE_PARAM_TYPE_MEMREF_INPUT, and the private key and certificate data spliced in the TLV format are transmitted; the maximum supported capacity of the data needs to refer to the security memory allocation limit of the target TEE, and the specific limit can be obtained from the device TEE development document to ensure that the storage needs of the Dilithium private key and the certificate can be covered; the LZ4HC algorithm running in the TEE internally uses compression level 9, which can balance the compression rate and speed, and can compress the data volume to 50%±5% of the original size, and the compression window size is set to 64KB; the type of the output parameter is set to TEE_PARAM_TYPE_MEMREF_OUTPUT, which is used to receive the compressed data returned by the TEE; sufficient secure memory needs to be allocated in advance to avoid overflow, and the allocation size of the secure memory needs to be estimated in combination with the maximum supported capacity of the input data and the compression rate, and the actual length of the compressed data needs to be recorded.

[0081] (2) Generate an HMAC-SHA3-512 label: which can guarantee the integrity of the data; specifically including:

[0082] The TEE generates a symmetric key for calculating the HMAC label according to the key management specification, and the specific specification can be obtained from the TEE security architecture document; the key is stored in the non-exportable secure storage area of the TEE and can only be called by the HMAC calculation command, and cannot be exported through any interface;

[0083] The binary data of the private key and the certificate compressed by LZ4HC is packaged as an input parameter identifiable by the TEE, such as a TEE_Param structure, and the type is set as TEE_PARAM_TYPE_MEMREF_INPUT. The HMAC calculation command is sent to the TEE through the TEEC_InvokeCommand function, and the TEE is requested to perform the HMAC-SHA3-512 tag calculation;

[0084] After receiving the calculation command, the TEE calls the HMAC-SHA3-512 algorithm, takes the above-mentioned symmetric key generated by itself as the authentication key, performs a hash operation on the input private key and certificate binary data compressed by LZ4HC, and generates a 512-bit HMAC-SHA3-512 integrity tag inside the TEE; After generation, the TEE associates the integrity tag with the complete compressed data in the internal temporary secure buffer area, preparing for subsequent data packet packaging;

[0085] After the calculation is completed, the TEE sends the HMAC calculation command to the TEE through the output parameter (type set as TEE_PARAM_TYPE_MEMREF_OUTPUT) of the TEEC_InvokeCommand function, returns the generated HMAC-SHA3-512 integrity tag to the secure memory buffer of the application layer, and the application layer binds the tag with the corresponding compressed data through a preset unified identifier after receiving the tag, so that the tag can be accurately matched to the corresponding compressed private key and certificate data when packaging the subsequent data packet, avoiding the misplacement of the tag and the data.

[0086] The technical effects of generating the tag include: although the RPMB itself provides anti-replay and anti-tampering capabilities, it cannot verify data integrity. By introducing the HMAC-SHA3-512 tag, the integrity of the compressed private key and certificate can be verified to ensure that the data is not tampered with or damaged during writing and reading.

[0087] (3) Package data packet: package the compressed private key and certificate data, and the HMAC-SHA3-512 tag into a data packet; the data packet format includes:

[0088] Header field: contains version number, storage packet data type identifier for identifying Dilithium private key or certificate, compressed data length, and timestamp recording UTC time of generating the data packet;

[0089] Compressed data segment: fill in the compressed data generated in step 1;

[0090] HMAC tag segment: tag type identifier and HMAC-SHA3-512 tag;

[0091] CRC32 checksum segment: used to verify the integrity of data packet encapsulation.

[0092] After encapsulation, the TEE returns the complete data packet to the application layer's secure memory buffer through the output parameters of the TEEC_InvokeCommand function.

[0093] (4) Writing to RPMB (Replay Protected Memory Block): The data packet is written to the RPMB for persistent storage; specifically including:

[0094] Based on the RPMB Key burned into the device at the factory, the HMAC-SHA256 algorithm is used to generate a MAC value from the timestamp and compressed data length fields of the data packet, and the MAC value is used as the authorization field for the RPMB write request to prevent unauthorized devices from writing data. The method of obtaining the RPMB Key follows the RPMB access specification of the device manufacturer and can be found in the device hardware security documentation.

[0095] According to the JEDEC eMMC standard in the technical specifications of the device's memory chip, multiple write commands are sent through the RPMB driver module in the TEE to write the encapsulated data packets to the specified address block of the RPMB. The starting address is obtained from the device's RPMB partition planning document.

[0096] In one embodiment, the method further includes: after the data packet is written, the TEE reads the data packet from the same address of the RPMB using a multi-block read command to perform dual authentication.

[0097] In one embodiment, the method further includes: recalculating the CRC32 value of the data packet and comparing it with the CRC32 checksum in the data packet to confirm that there are no data transmission errors;

[0098] In one embodiment, the method further includes: using the HMAC key stored in the TEE to calculate the HMAC-SHA3-512 tag of the compressed data segment in the data packet, comparing it with the HMAC tag segment in the data packet, and confirming that the data has not been tampered with.

[0099] In one embodiment, if the CRC32 does not match or the HMAC check fails, a retry mechanism is triggered; if multiple retries fail (e.g., 3 times), the TEE returns an error code, the application layer records the error log and terminates the storage process to avoid writing invalid data.

[0100] Step 3: Save the private key and certificate to the sandbox.

[0101] like Figure 4 As shown in the flowchart, saving the private key and certificate to the sandbox involves the following steps:

[0102] (1) Call the AndroidKeystore API to randomly generate an AES-GCM symmetric encryption key in the Keystore system, which is configured as follows: use the AES algorithm, the GCM mode, and non-exportable (the key cannot be obtained by the application or system in plaintext form); specifically includes two parts of key generation parameter configuration and key generation; the key generation parameter configuration includes the following configurations: set the AES key length (such as 256 bits), specify the key usage as encryption and decryption, set the key as non-exportable, and bind the application package name used by the key to prevent other applications from using the key; the key generation operation includes: creating a KeyGenerator instance, specifying the encryption algorithm as AES and the Provider as AndroidKeyStore to ensure that the key generation process is managed by AndroidKeystore rather than the application layer; after initializing the key generation parameters, calling the key generation function to generate an AES-GCM symmetric key, which is stored in the Android Keystore, and the application layer can only obtain the key reference and cannot obtain the plaintext key.

[0103] (2) Encrypt the private key using the AES-GCM symmetric key: in the application layer, encrypt the Dilithium private key using the AES-GCM symmetric key to generate ciphertext Ciphertext, and generate an authentication tag Tag for subsequent decryption to verify integrity. The authentication tag Tag includes: the Dilithium private key, the random initial vector used, the AES-GCM symmetric key, and optional additional authentication data such as the application identifier.

[0104] In an embodiment, in the encryption process, AES-GCM performs counter mode encryption on the plaintext data in blocks, and performs GHASH operation on all data blocks and AAD. The final hash result is the Tag. The Tag is output together with the ciphertext Ciphertext to verify whether the data has been tampered with during decryption.

[0105] In an embodiment, encrypting the private key using the AES-GCM symmetric key includes the following steps:

[0106] Obtain the binary format plaintext Dilithium private key from the application layer memory encryption cache area; before obtaining, it needs to be decrypted by the AES-256-GCM decryption logic of the cache area in step (2); that is, call the Android Keystore interface to obtain the temporary key during encryption of the cache area, create a Cipher instance and configure it as DECRYPT_MODE, pass in the cache area encryption data to perform decryption, and obtain the plaintext private key after decryption is completed;

[0107] As a necessary parameter of AES-GCM encryption, a 12-byte random IV is generated by the SecureRandom class; the length meets the GCM mode IV standard recommended by NIST SP 800-38D, which ensures that different ciphertexts are generated when the same plaintext is encrypted with the same key, avoiding attackers from deducing the private key through the regularity of the ciphertext. The IV needs to be generated independently and a new IV is generated each time the private key is encrypted, and the generated IV is stored together with the subsequent ciphertext and authentication tag (Tag);

[0108] The unique identification of the application and the device is added as AAD (Additional Authenticated Data), such as binary data including the application package name and the device Android ID hash value. AAD does not participate in encryption but participates in Tag calculation, which can prevent encrypted data from being tampered with or decrypted on unauthorized devices / applications.

[0109] A Cipher instance for symmetric encryption is created, and the following core parameters of the instance are configured: specify the encryption algorithm as AES / GCM / NoPadding;

[0110] The encryption process is limited to be hosted by the Android Keystore; the initialization operation is performed on the encryption instance, specifically to configure the following necessary parameters: set the operation mode to encryption mode, import the generated AES-GCM symmetric key, and configure the parameter specification specific to the GCM mode, which includes a 128-bit authentication tag (Tag) length and the previously generated IV, where the 128-bit Tag length meets the GCM algorithm standard;

[0111] The previously prepared application and device unique identification data (AAD) is imported into the encryption instance, so that this data participates in the calculation of the subsequent authentication tag (Tag), further ensuring the anti-tampering ability of the encrypted data;

[0112] The final encryption processing is performed on the Dilithium private key in plaintext form, and the following two results are generated through this operation: one is the encrypted private key ciphertext Ciphertext, and the other is a 16-byte authentication tag Tag, which will be used to verify the integrity of the ciphertext during subsequent decryption, ensuring that the private key has not been tampered with during storage and transmission.

[0113] In an embodiment, it also includes: emptying the byte array that stores the plaintext private key and setting the array to null to avoid leaking the plaintext private key due to memory leakage.

[0114] (3) Private key and certificate writing into sandbox: write the encrypted Ciphertext, Tag, and original certificate into the private file system in the application sandbox, during which the original unencrypted Dilithium private key never leaves the application memory;

[0115] In an embodiment, a private sandbox directory only accessible by the current application is selected, which is obtained through an application private storage interface provided by the Android system, to ensure that the storage content in the directory cannot be directly accessed by other applications and unauthorized processes of the system.

[0116] In an embodiment, the AES-GCM encrypted private key data is stored as an independent file, and the file needs to be associated with a unique identifier corresponding to the current Dilithium private key, such as a private key generation timestamp, a device identifier hash value, etc., to ensure that it can be distinguished from other private key files.

[0117] The verified Dilithium original certificate is stored as an independent file, and the file is associated with the same identifier as the corresponding private key, to ensure that the private key and the certificate can be accurately matched.

[0118] The encrypted private key file and the certificate file in the sandbox are configured to have read and write permissions only for the current application, and through the file permission management mechanism provided by the Android system, access, modification or deletion operations of the files by other applications and unauthorized processes of the system are limited.

[0119] The hash values of the encrypted private key file and the certificate file are calculated, and the hash values, together with the file identifier and the storage timestamp, are recorded in the integrity check record file in the application sandbox. Before reading the file later, the hash value can be recalculated and compared with the record to verify whether the file has been tampered with or damaged.

[0120] Step four, restore private key and certificate

[0121] As shown in Figure 5 , it includes:

[0122] When the application starts, it checks whether there are valid encrypted private key and original certificate files in its sandbox directory. If it is detected that the files are missing or invalid (such as device performing factory reset, clearing application data or decryption failure, etc.), the recovery process is triggered to restore the private key and the certificate from the RPMB (Replay Protection Memory Block), and to complete the secure storage again, to ensure the continuity of the private key throughout its life cycle. As shown in Figure 5 , the steps of restoring the private key and the certificate include:

[0123] (1) Recovery trigger determination when the application starts

[0124] After the mobile application implementing the anti-quantum private key life cycle security management function is started, the sandbox storage validity detection is first performed to determine whether to trigger the recovery process, which specifically includes:

[0125] Detecting whether the encrypted private key file, the authentication tag (Tag) file and the certificate file stored in step three exist in the sandbox designated directory; in the Android system, the designated directory can be obtained through the getNoBackupFilesDir() interface to obtain the sandbox designated directory of the mobile application;

[0126] If the file is missing or the file exists but the validity check fails, further attempt to read the encrypted private key file, call the Android Keystore API to use the historical key (if exists) to perform decryption operation, if the decryption is successful, there is no need to recover, otherwise: if the authentication tag check fails, the initialization vector (IV) does not match, the key is invalid, etc. Abnormal, it is judged that the private key / certificate in the sandbox is unavailable, triggering the recovery process of this step. The validity check failure includes: the file hash value does not match the hash value in the integrity check record file in the sandbox, the file size is 0 or exceeds the preset threshold.

[0127] (2) Read data packet from RPMB: read the data packet encapsulated by the private key and the certificate from the RPMB secure area by calling the TEE API; specifically including:

[0128] The application layer calls the initialization interface (TEEC_InitializeContext) of TEE, inputs the device TEE vendor identifier, and establishes the basic communication context with TEE;

[0129] Call the TEEC_OpenSession function to establish a secure session with the preset PQC security recovery service in TEE. The session is isolated from the non-secure world (such as the Android main system) through a hardware isolation mechanism, ensuring that the data transmission process is not monitored;

[0130] Refer to JEDEC eMMC standard and RPMB access specification of device manufacturer, generate RPMB read authorization information: based on the RPMB Key burned in device factory, calculate the storage address block identifier of the data packet to be read and the read request timestamp using HMAC-SHA256 algorithm, generate MAC value as the authorization field of read request;

[0131] Call the TEEC_InvokeCommand function to send the read command to TEE, input the authorization MAC value, data packet storage address block and other parameters; the RPMB drive module in TEE verifies the validity of the authorization MAC value, and then performs multi-block read operation to read the data packet to the temporary secure memory area of TEE;

[0132] The TEE returns the read data packet to the secure memory buffer of the application layer through the output parameter of TEEC_InvokeCommand, and the application layer temporarily stores the received data and does not write it into any persistent storage.

[0133] (3) Check the HMAC value: check the data packet integrity;

[0134] To ensure that the data packet read from the RPMB is not tampered with or damaged, double-checking is performed inside the TEE, specifically including:

[0135] The TEE calls the CRC32 algorithm to recalculate the check value for the read complete data packet (including the header field, compressed data segment, HMAC tag segment, and CRC32 check code segment), and compares it with the CRC32 check code segment in the data packet:

[0136] If the comparison is inconsistent, it is determined that there is an error in the data packet packaging process, and a retry mechanism is triggered, with a maximum of 3 retries, consistent with the retry logic in step two.

[0137] If the CRC32 check passes, the TEE calls the HMCA symmetric key generated in step two from the non-exportable secure storage area to recalculate the HMAC-SHA3-512 tag for the compressed data segment in the data packet, and compares it with the tag value in the HMCA tag segment in the data packet.

[0138] If the HMAC check passes, it is confirmed that the compressed data has not been tampered with, and the next step of the decompression process is entered; otherwise, it is determined that the data packet has been illegally tampered with, and the TEE returns an error code, the application layer records error logs and terminates the recovery process, and can further prompt the user that the private key recovery has failed, please contact the administrator.

[0139] (4) LZ4 decompression: LZ4 decompression of the data packet in the TEE to obtain the original Dilithium private key and certificate;

[0140] The TEE uses the LZ4HC decompression logic corresponding to the compression algorithm in step two to decompress the compressed data that has passed the check, and separates the original private key and certificate, specifically including:

[0141] The TEE calls the LZ4HC decompression interface and configures the same parameters as in step two (the compression window size is set to 64KB), performs decompression on the compressed data segment, and generates unencrypted private key and certificate splicing data.

[0142] Since the TLV (Type-Length-Value) format is used to splice the private key and certificate in step two, the TEE parses the decompressed data in TLV format:

[0143] Determine whether the data type of the decompressed data is a Dilithium private key or a certificate by reading the value of the type field;

[0144] Obtain the data length of the subsequent Value field by reading the length coding rule corresponding to the Length field;

[0145] Extract the private key binary data or certificate DER format data according to the current data type according to the length specified by the Length field;

[0146] In an embodiment, it also includes checking whether the length of the Dilithium private key meets the preset standard, such as the length of Dilithium-III private key being 2592 bytes, and whether the certificate DER data can pass the basic ASN.1 analysis to avoid data truncation; if the verification fails, the TEE returns an error code (such as TEE_ERROR_BAD_FORMAT) to terminate the recovery process.

[0147] (5) Keystore generates a symmetric key: the application layer calls the Android Keystore API to regenerate a new AES-GCM symmetric key that cannot be derived for encrypting the recovered private key; ensure the storage security of the recovered private key, which specifically includes:

[0148] Create a KeyGenerator instance, specify the encryption algorithm as AES, and the Provider as AndroidKeyStore to ensure that the key generation process is managed by the hardware-level Keystore; set the key length to the number of bits that meet the NIST security standard, and specify the key usage as encryption and decryption;

[0149] Set the key to be non-derivable through a preset function to avoid the key being obtained in plaintext; bind the package name of the current mobile application to prevent other applications from using the key;

[0150] Call the KeyGenerator.generateKey() function to generate an AES-GCM symmetric key, which is automatically stored in the non-derivable secure area of the Android Keystore; the application layer only obtains the reference of the key (such as the Key object), and cannot obtain the key in plaintext; at the same time, associate the key with the recovery identifier, such as generating a 16-byte ID based on the hash value of the recovered private key, which is used for subsequent encryption of the private key.

[0151] (6) Encrypt the private key using the symmetric key: in the application layer, use the AES-GCM symmetric key to encrypt the Dilithium private key to generate ciphertext Ciphertext, and generate an authentication tag Tag for subsequent decryption to verify integrity. Specifically includes:

[0152] The TEE transmits the separated Dilithium private key plaintext to the encryption cache area of the application layer through the secure memory channel, and the encryption cache area is temporarily encrypted based on the AES-256-GCM of step one, and only the secure sub-thread can access it;

[0153] Generate a 12-byte initialization vector (IV) through the SecureRandom class, which meets the recommended standard of NIST SP 800-38D for GCM mode IV, to ensure that different ciphertexts are generated when the same key encrypts the same plaintext; Collect additional authentication data (AAD), including the binary data of the current application package name and the SHA-256 hash value of the device Android ID to avoid privacy leakage, AAD does not participate in encryption but participates in authentication tag (Tag) calculation to prevent data tampering or decryption on unauthorized devices;

[0154] Create a Cipher instance and configure the algorithm as AES / GCM / NoPadding, and limit it to be hosted by the Android Keystore; Initialize the Cipher in encryption mode, pass in the AES-GCM key, IV, and AAD; Perform encryption on the plaintext private key to generate private key ciphertext (Ciphertext) and authentication tag (Tag);

[0155] After encryption is completed, immediately clear the plaintext private key through memory overwrite means (such as filling the byte array storing the plaintext private key with 0x00 or 0xff) and set the array to null, completely eliminating the risk of private key leakage caused by memory leakage.

[0156] (7) Private key and certificate writing into sandbox: write the encrypted private key ciphertext Ciphertext, authentication tag Tag, and original certificate into the private file system in the mobile application sandbox, during which the plaintext private key never leaves the application memory; Specifically including:

[0157] Get the exclusive sandbox directory of the mobile application through the preset interface of the Android system, which is only accessible to the current mobile application, and the system and other applications have no permission to operate, avoiding the use of external storage to prevent data exposure;

[0158] Storage file naming and format includes: 1. The private key ciphertext file is named recovery_private key ID_ciphertext, and the storage content is IV+ciphertext+Tag, concatenated in order; 2. The certificate file is named recovery_private key ID_cert, and the storage content is the certificate DER format data; Through the preset function, the permissions of the above files are configured to be readable and writable only for the current application, and other applications or processes are prohibited from accessing and modifying them;

[0159] The SHA-256 hash value of the private key ciphertext file and the certificate file is calculated, and the file name, hash value, recovery timestamp, and private key ID are written into the integrity check file in the sandbox for subsequent effectiveness detection when the application is started.

[0160] In an embodiment, after writing is completed, it is checked whether the file is successfully created and whether the file size is consistent with the expected value; if storage fails, reattempt writing (up to 3 times), and if still fails, return an error prompt.

[0161] Step five, use the private key and the certificate

[0162] When the application needs to perform signature and verification by Dilithium using the private key, or complete identity authentication by the certificate, the specific process includes:

[0163] (1) The application reads the encrypted data containing the Dilithium private key and the corresponding original certificate file stored in the private storage of the sandbox of the application; after reading the encrypted private key file, the key data segments are extracted in the storage order at the time of encryption, including: IV (initialization vector), authentication tag (Tag), and private key ciphertext required for AES-GCM encryption, to ensure that each field is not confused or lost; the Dilithium original certificate file is read, and the public key, validity period, CA signature, and other core information in the certificate are extracted through the certificate parsing interface;

[0164] (2) Call the Android Keystore API to decrypt the original private key using the AES-GCM symmetric key; specifically including:

[0165] Create a symmetric encryption instance, specify the algorithm as AES / GCM / NoPadding, and limit it to be managed by the Android Keystore; configure the core parameters required for decryption to be consistent with the parameters at the time of encryption;

[0166] Pass the private key ciphertext into the decryption instance, call the Keystore decryption interface to complete decryption, and generate the Dilithium private key in plaintext form; during decryption, if the Tag verification fails, the IV does not match, or other exceptions occur, terminate the process and record error logs to prevent invalid private keys from entering subsequent links;

[0167] The decrypted Dilithium private key in plaintext form is only stored in the application layer temporary secure memory area, the memory_dump permission is disabled, and the plaintext private key is not allowed to be transmitted to the non-secure memory area through any interface.

[0168] (3) The certificate contains a public key, holder information, CA signature, etc., which is public information or information that can be publicly verified. The application can directly read the original certificate from the sandbox for TLS identity authentication, and send the certificate directly to the communication peer to prove its identity;

[0169] In an embodiment, the certificate is verified before use, including whether the certificate is within the valid period, whether the certificate chain is complete, and whether the CA signature is valid, to avoid using invalid or tampered certificates; whether the certificate chain is complete includes tracing from the current certificate to the CA root certificate; the method for verifying whether the CA signature is valid includes verifying the quantum-resistant signature of the CA through the BC PQC library or the PQClean library;

[0170] In an embodiment, the certificate that passes the verification is transmitted to the TLS protocol stack through the TLS communication interface of the application and sent to the communication peer as an identity credential; it is ensured that the certificate is encrypted during transmission in the TLS handshake phase relying on the encryption mechanism of the TLS protocol itself, to avoid interception or forgery of the certificate during transmission.

[0171] (4) Perform quantum-resistant algorithm operations, including:

[0172] 1) Pass the original data or hash that needs to be signed to the signature interface of the PQClean or Bouncy Castle PQC library, and use the Dilithium private key in plaintext form to perform the signature algorithm to generate a digital signature; in an embodiment, after signing is completed, a signature timestamp and signature data identifier are recorded for subsequent auditing;

[0173] 2) After the application receives the data and the digital signature, the PQClean or Bouncy Castle PQC library is used to verify the signature using the corresponding Dilithium public key; in an embodiment, if the signature verification fails, the result of data tampering or invalid signature is fed back, and subsequent processing of the data is terminated;

[0174] 3) In an embodiment, when data encryption operations or key exchange need to be performed, including:

[0175] Use the KEM (Key Encapsulation Mechanism) algorithm (such as CRYSTALS-Kyber) of the PQClean or Bouncy Castle PQC library to generate a pair of associated Kyber key pairs, including a publicly transmissible Kyber public key and a Kyber private key corresponding to the Kyber public key, wherein the Kyber private key needs to be stored in the secure memory area of the application, such as TEE or application layer temporary encrypted cache, and is not transmitted externally;

[0176] The Kyber public key in the Kyber key pair is sent to a communication peer that interacts with the local terminal through an encrypted channel, and the communication peer generates a temporary symmetric session key for subsequent data encryption after receiving the Kyber public key, and the symmetric session key adopts an AES-256-GCM algorithm; and the received Kyber public key is used to encrypt the symmetric session key to generate an encrypted data, that is, an encrypted key material;

[0177] The communication peer returns the generated encrypted key material to the local terminal through an encrypted channel, and the local terminal decrypts the encrypted key material using the previously generated Kyber private key in the Kyber key pair to restore the symmetric session key generated by the communication peer;

[0178] Finally, the local terminal and the communication peer both hold the same symmetric session key, which can be used for subsequent data encryption transmission, and the secure key agreement based on the quantum-resistant algorithm is realized.

[0179] (5) Result return and plaintext private key cleaning

[0180] The certificate, signature, signature verification result or encrypted ciphertext is returned to the application layer for subsequent business processing.

[0181] In an embodiment, after all quantum-resistant algorithm operations are completed, a memory area storing the plaintext private key is immediately emptied by a memory overwrite method, such as overwriting the original private key data with data 0x00 or 0xff, and the temporary secure memory is released, thereby completely eliminating the risk of plaintext private key leakage.

[0182] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0183] The embodiment of the present application also provides a private key full life cycle security management system based on a mobile terminal quantum-resistant cryptographic algorithm, comprising:

[0184] A key and certificate generation module is configured to generate a key pair based on a quantum-resistant cryptographic algorithm, and obtain a certificate containing a public key in the key pair;

[0185] A sandbox storage module is configured to call a hardware-level key management system of the mobile terminal to generate a symmetric encryption key, encrypt a private key in the key pair using the symmetric encryption key and store the encrypted private key in a sandbox, and store the certificate in the sandbox;

[0186] The key and certificate using module is used for taking out the private key and the certificate of the encrypted key pair from the sandbox, calling the hardware-level key management system, decrypting the private key using the symmetric encryption key, obtaining a decrypted private key, calling an interface matched with the use of the private key through a preset quantum-resistant algorithm library, and performing a signature, verification or key exchange operation using the decrypted private key; and after the operation is completed, a memory area storing the private key plaintext is cleared.

[0187] In an embodiment, the security storage module is further configured to generate an integrity tag for data integrity according to the private key and the certificate in the key pair, and to write the private key, the certificate and the integrity tag into the RPMB in a TLV format.

[0188] In an embodiment, the security storage module is further configured to transmit the unencrypted private key and the certificate in the key pair into a trusted execution environment, to generate a symmetric key in the trusted execution environment, to store the symmetric key in a non-exportable secure storage area of the TEE, and to allow only a command call for integrity tag calculation and to prevent the symmetric key from being exported through any interface, and to generate an integrity tag for data integrity by calling an HMAC algorithm based on the symmetric key to calculate the private key and the certificate in the trusted execution environment.

[0189] In an embodiment, the security storage module is further configured to compress the private key and the certificate using an LZ4HC compression algorithm inside the TEE before calculating the integrity tag.

[0190] In an embodiment, the key and certificate generating module is configured to generate the key pair by:

[0191] In a mobile application implementing quantum-resistant private key full-life cycle security management, a PQClean open source library and a Bouncy Castle PQC library are integrated; the mobile application is enabled to obtain a storage permission for temporarily storing a non-sensitive intermediate file in a key generation process in a mobile system (such as Android);

[0192] The mobile application calls a preset quantum-resistant key generation module in the PQClean open source library to generate a key pair based on a quantum-resistant cryptographic algorithm, the key pair including a private key and a public key; the quantum-resistant cryptographic algorithm is a lattice-based cryptographic algorithm, and the quantum-resistant key generation module in the PQClean open source library includes a function executing lattice-based cryptographic algorithm key generation logic.

[0193] In an embodiment, the key and certificate generating module is configured to obtain the certificate by:

[0194] In a mobile application implementing an anti-quantum private key full life cycle security management function, the Bouncy Castle PQC library is integrated; the mobile application obtains a request permission for submitting a certificate request to a certificate authority in a mobile system; based on the public key of the key pair, an anti-quantum signature generation component is constructed through the Bouncy Castle PQC library, and the anti-quantum signature generation component is configured to: use a preset anti-quantum cryptographic algorithm to sign the public key of the key pair and identity information provided by the mobile application, generate an anti-quantum certificate signature request, and submit the certificate signature request to the certificate authority through a TLS 1.3 channel; the certificate signature request conforms to X.509 and other compatible standards;

[0195] Receiving the certificate returned by the certificate authority based on the anti-quantum algorithm, the certificate containing the public key and the anti-quantum signature of the certificate authority.

[0196] In an embodiment, in the sandbox storage module, the Android Keystore API of the mobile terminal is called to generate a symmetric encryption key for encrypting the private key, the symmetric encryption key being configured to be non-exportable and only allowing encryption and decryption operations to be performed through the Android Keystore API call; the symmetric encryption key is used to encrypt the private key using the AES-GCM symmetric encryption algorithm to generate private key ciphertext and an authentication tag for verifying the integrity of the private key, and the memory area storing the private key plaintext is emptied after encryption is completed; the private key ciphertext, the authentication tag, and the certificate are stored in the sandbox, the access permission of the sandbox is configured to only allow the mobile application implementing the anti-quantum private key full life cycle security management function to read or modify the storage content, and the integrity verification information of the private key ciphertext, the authentication tag, and the certificate is recorded.

[0197] In an embodiment, the file integrity detection module is further included for calling a file feature identification comparison method based on a hash algorithm when the mobile application is started, calculating the current file feature identification (hash value) of the private key ciphertext, the authentication tag, and the certificate stored in the sandbox, and comparing the current file feature identification with the historical file feature identification recorded in the integrity verification information in the sandbox; if the comparison is consistent, the key and certificate use module is allowed to perform subsequent operations; if the comparison is inconsistent, the subsequent operation of the key and certificate use module is terminated and a security prompt is triggered.

[0198] In an embodiment, the key and certificate recovery module is further included for recovering the private key and the certificate using the data packet stored in the special hardware storage unit when the private key and the certificate in the sandbox are missing or invalid, and the recovery process includes:

[0199] reading the data packet previously stored in the special hardware storage unit;

[0200] performing integrity check on the data packet inside the TEE, if the check passes, decompressing the compressed data in the data packet with a decompression algorithm matching the preset lightweight data compression algorithm (such as LZ4HC), separating the original private key based on the quantum-resistant algorithm and the certificate generated based on the quantum-resistant algorithm in the TLV format; the integrity check includes: calling the pre-generated symmetric key for integrity tag calculation from the non-derivable secure storage area of the TEE, using the HMAC-SHA3-512 algorithm to calculate a new integrity tag for the compressed data segment in the data packet, comparing the new integrity tag with the integrity tag encapsulated in the data packet, and confirming that the compressed data has not been tampered with;

[0201] The application layer generates a non-derivable symmetric encryption key through the hardware-level key management interface of the mobile terminal, and the symmetric encryption key is bound to the mobile application currently implementing the anti-quantum private key full life cycle security management function and is limited in use for encryption and decryption.

[0202] The symmetric encryption key is used to encrypt the restored private key based on the quantum-resistant algorithm to generate private key ciphertext and an authentication tag; after encryption is completed, the memory area storing the private key plaintext is cleared;

[0203] The private key ciphertext, the authentication tag, and the restored certificate generated based on the quantum-resistant algorithm are written into the exclusive sandbox of the mobile application, and the sandbox access permission is configured to be only the mobile application can operate.

[0204] In an embodiment, before writing the private key ciphertext, the authentication tag, and the restored certificate generated based on the quantum-resistant algorithm into the exclusive sandbox of the mobile application, it further includes: calculating the file feature identifier of each of the private key ciphertext, the authentication tag, and the restored certificate generated based on the quantum-resistant algorithm, and associating each file feature identifier with the file unique identifier of the corresponding independent file to form file integrity check information, and recording the file integrity check information to the integrity check record file in the sandbox.

[0205] In an embodiment, in the key and certificate use module, the mobile application reads the stored encrypted private key file, authentication tag and certificate from its exclusive sandbox, extracts the initialization vector and private key ciphertext in the encrypted private key file; calls the hardware-level key management interface of the mobile terminal, uses the symmetric encryption key to perform decryption on the private key ciphertext, generates a private key plaintext based on an anti-quantum algorithm; after decryption, the memory area storing the private key plaintext is cleared; the certificate is subjected to validity verification, the verification content includes certificate validity period, certificate chain integrity and validity of the signature of the issuing authority, and after the verification passes, the certificate is used for identity authentication; the corresponding algorithm interface is called through a preset anti-quantum algorithm library (such as the PQClean open source library, the BouncyCastle PQC library), and the private key plaintext is used to perform signature, signature verification or key exchange operation.

[0206] In an embodiment, when the mobile application is started next time, the current file feature identifier of the restored private key ciphertext, authentication tag and certificate in the sandbox is calculated, the corresponding historical file feature identifier associated with the unique identifier of each file in the integrity verification record file in the sandbox is called for comparison; if the comparison is consistent, it is confirmed that the restored file has not been tampered with, and the key and certificate use module is allowed to call the private key ciphertext, authentication tag and certificate; otherwise, the key and certificate recovery module is triggered to re-execute the recovery process.

[0207] The embodiment of the application also provides a private key full life cycle security management method based on a mobile terminal anti-quantum cryptographic algorithm, comprising:

[0208] generating a key pair based on an anti-quantum cryptographic algorithm; obtaining a certificate containing a public key in the key pair;

[0209] calling a mobile terminal key management system to generate a symmetric encryption key, encrypting a private key in the key pair by using the symmetric encryption key and storing the encrypted private key in a sandbox, and storing the certificate in the sandbox;

[0210] taking out the encrypted private key in the key pair and the certificate from the sandbox, calling the hardware-level key management system, using the symmetric encryption key to decrypt the private key, obtaining a decrypted private key; calling an interface matched with the use of the private key through a preset anti-quantum algorithm library, using the decrypted private key to perform signature, signature verification or key exchange operation; after the operation is completed, the memory area storing the private key plaintext is cleared.

[0211] The embodiment of the application also provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, realizes the steps of the private key full life cycle security management method based on a mobile terminal anti-quantum cryptographic algorithm.

[0212] The embodiment of the present application also provides a non-transitory computer readable storage medium, which stores a computer program, and the computer program comprises program instructions, and the program instructions are executed by a processor to implement each step of the method of the present application, which will not be repeated here.

[0213] The computer readable storage medium can be an internal storage unit of the data transmission device or the computer device, such as a hard disk or a memory of the computer device. The computer readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc.

[0214] Further, the computer readable storage medium can include both the internal storage unit and the external storage device of the computer device. The computer readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer readable storage medium can also be used to temporarily store data to be output or data that has been output.

[0215] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can be in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to a magnetic disk memory, a CD-ROM, an optical memory, etc.) containing computer usable program code.

[0216] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The device that implements the functions specified in one flow or multiple flows and / or blocks. Figure 1 The device that implements the functions specified in one flow or multiple flows and / or blocks.

[0217] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0218] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0219] The embodiments of the present application also provide a computer program product, comprising computer programs / instructions, which, when executed by a processor, implement the steps of the method for private key full life cycle security management based on mobile terminal anti-quantum cryptography algorithm.

[0220] The contents of the specification not described in detail are the prior art known to those skilled in the art.

Claims

1. A private key lifecycle security management system based on mobile quantum-resistant cryptographic algorithms, characterized in that, include: Key and certificate generation module: used to generate key pairs based on quantum-resistant cryptographic algorithms; Obtain a certificate containing the public key from the key pair; Sandbox storage module: used to call the hardware-level key management system of the mobile terminal to generate a symmetric encryption key, encrypt the private key in the key pair with the symmetric encryption key and store it in the sandbox, and store the certificate in the sandbox; Key and Certificate Usage Module: Used to retrieve the private key and certificate from the encrypted key pair in the sandbox, call the hardware-level key management system, decrypt the private key using the symmetric encryption key to obtain the decrypted private key; call a function matching the purpose of the private key through a preset quantum-resistant algorithm library, and use the decrypted private key to perform signing, verification, or key exchange operations in the function matching the purpose of the private key.

2. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 1, characterized in that, It also includes a secure storage module, which generates an integrity tag for data integrity based on the private key and certificate in the key pair, and encapsulates the private key, certificate and integrity tag into a data packet according to a preset data format and writes it into a dedicated hardware storage unit on the mobile device with anti-replay protection and tamper detection functions.

3. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 2, characterized in that, In the secure storage module, the private key and certificate from the unencrypted key pair are passed to the trusted execution environment; a symmetric key is generated in the trusted execution environment. The trusted execution environment invokes a preset security level message authentication code algorithm based on symmetric keys to calculate the private key and certificate, generating an integrity tag for data integrity.

4. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 3, characterized in that, Before calculating the integrity tag, the private key and certificate are compressed using a preset lightweight data compression algorithm within the trusted execution environment.

5. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 1, characterized in that, The key and certificate generation module includes the following methods for generating key pairs: In mobile applications that implement quantum-resistant private key lifecycle security management, the PQClean open-source library is integrated, enabling the mobile application to obtain storage permissions for non-sensitive intermediate files in the temporary storage key generation process within the mobile system. The mobile application calls the pre-defined quantum-resistant key generation module in the PQClean open-source library to generate key pairs based on quantum-resistant cryptographic algorithms.

6. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 5, characterized in that, The method for obtaining a certificate in the key and certificate generation module includes: The Bouncy Castle PQC library is integrated into a mobile application that implements quantum-resistant private key lifecycle security management, enabling the mobile application to obtain the permission to submit certificate requests to the certificate authority within the mobile system. Based on the public key of the key pair, a quantum-resistant signature generation component is constructed using the Bouncy Castle PQC library. The quantum-resistant signature generation component is configured to: use a preset quantum-resistant cryptographic algorithm to sign the public key of the key pair and the identity information provided by the mobile application, generate a quantum-resistant certificate signature request, and submit the certificate signature request to the certificate authority through a preset encrypted channel. Receive the certificate generated based on the quantum-resistant algorithm returned by the certificate authority.

7. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 1, characterized in that, In the sandbox storage module, the hardware-level key management interface of the mobile terminal is called to generate a symmetric encryption key for encrypting the private key; a preset symmetric encryption algorithm is used to encrypt the private key with the symmetric encryption key to generate ciphertext of the private key and an authentication tag for verifying the integrity of the private key; after encryption, the memory area storing the plaintext of the private key is cleared; the ciphertext of the private key, the authentication tag and the certificate are stored in the sandbox, and the access permissions of the sandbox are configured to allow only mobile applications belonging to the system that implement quantum-resistant private key lifecycle security management functions to read or modify the stored content, and the integrity verification information of the ciphertext of the private key, the authentication tag and the certificate is recorded.

8. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptography algorithm as described in claim 7, characterized in that, It also includes a file integrity detection module, which, when the mobile application starts, calls a preset integrity verification method to calculate the current file feature identifier of the private key ciphertext, authentication tag and certificate stored in the sandbox, and compares the current file feature identifier with the historical file feature identifier recorded in the integrity verification information in the sandbox; if the comparison is consistent, the key and certificate usage module is allowed to perform subsequent operations.

9. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 4, characterized in that, It also includes a key and certificate recovery module, which is used to recover the private key and certificate using the data packets stored in the dedicated hardware storage unit when the private key and certificate in the sandbox are missing or invalid.

10. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 9, characterized in that, The recovery process includes: Read the data packet previously stored in the dedicated hardware storage unit; Within the Trusted Execution Environment (TEE), integrity verification is performed on the data packet. If the verification passes, a decompression algorithm matching the preset lightweight data compression algorithm is used to decompress the compressed data within the data packet, separating the original quantum-resistant private key and the certificate generated based on the quantum-resistant algorithm according to a preset data format. The integrity verification includes: retrieving a pre-generated symmetric key for integrity tag calculation from the non-exportable secure storage area of ​​the TEE; using a preset security level message authentication code algorithm to calculate a new integrity tag for the compressed data segment within the data packet; and comparing the new integrity tag with the integrity tag encapsulated within the data packet. The application layer generates a non-derivative symmetric encryption key through the hardware-level key management interface of the mobile terminal. The symmetric encryption key is bound to the mobile application that currently implements the full lifecycle security management function of quantum-resistant private key and its use is limited to encryption and decryption. The recovered quantum-resistant private key is encrypted using the symmetric encryption key to generate the private key ciphertext and the authentication tag; after encryption, the memory area storing the private key plaintext is cleared. Write the private key ciphertext, authentication tag, and the recovered certificate generated based on the quantum-resistant algorithm into the mobile application's dedicated sandbox, and configure the sandbox access permissions so that only the mobile application can operate on it.

11. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 10, characterized in that, Before writing the private key ciphertext, authentication tag, and recovered certificate generated based on the quantum-resistant algorithm into the mobile application's dedicated sandbox, the method further includes: calculating the file feature identifiers of the three independent files—the private key ciphertext, authentication tag, and recovered certificate generated based on the quantum-resistant algorithm—and associating each file feature identifier with the unique file identifier of the corresponding independent file to form file integrity verification information, and recording the file integrity verification information into an integrity verification record file within the sandbox.

12. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 9, characterized in that, In the key and certificate usage module, the mobile application reads the stored encrypted private key file, authentication tag and certificate from its dedicated sandbox, extracts the initialization vector and private key ciphertext from the encrypted private key file, calls the hardware-level key management interface of the mobile terminal, and uses the symmetric encryption key to decrypt the private key ciphertext to generate a private key plaintext based on a quantum-resistant algorithm. After decryption, clear the memory area storing the plaintext of the private key; perform validity verification on the certificate, and if the verification passes, use the certificate for identity authentication; call the corresponding algorithm interface through the preset quantum-resistant algorithm library, and use the plaintext of the private key to perform signing, verification, or key exchange operations.

13. The private key lifecycle security management system based on mobile terminal quantum-resistant cryptographic algorithms as described in any one of claims 11-12, characterized in that, When the mobile application is launched again, the method further includes: calculating the current file feature identifiers of the private key ciphertext, authentication tag, and certificate stored in the sandbox for recovery; retrieving the corresponding historical file feature identifiers associated with the unique identifiers of each file in the integrity verification record file in the sandbox for comparison; if the comparison is consistent, allowing the key and certificate usage module to call the private key ciphertext, authentication tag, and certificate; otherwise, triggering the key and certificate recovery module to re-execute the recovery process.

14. A method for full lifecycle security management of private keys based on mobile terminal quantum-resistant cryptographic algorithms as described in claim 1, characterized in that, include: Generate key pairs based on quantum-resistant cryptographic algorithms; Obtain a certificate containing the public key from the key pair; The mobile key management system is called to generate a symmetric encryption key. The private key in the key pair is encrypted using the symmetric encryption key and then stored in a sandbox. The certificate is also stored in the sandbox. The private key and certificate from the encrypted key pair are retrieved from the sandbox. The hardware-level key management system is invoked, and the private key is decrypted using the symmetric encryption key to obtain the decrypted private key. An interface matching the purpose of the private key is invoked through a preset quantum-resistant algorithm library, and the decrypted private key is used to perform signing, verification, or key exchange operations. After the operation is completed, the memory area storing the plaintext of the private key is cleared.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the private key lifecycle security management method based on mobile terminal quantum-resistant cryptographic algorithm as described in claim 14.

16. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the private key lifecycle security management method based on mobile terminal quantum-resistant cryptographic algorithm as described in claim 14.

Images