A certificate and key management method and terminal based on a honeycomb operating system

Abstract

This application relates to the field of information security and discloses a certificate and key management method and terminal based on the HarmonyOS operating system. The method includes: generating and storing key pairs by calling the HUKS interface of the HarmonyOS system; binding a key alias used to uniquely identify the key pair to the corresponding certificate chain, and synchronizing the binding relationship between the key alias and the certificate chain and the certificate status across multiple devices; encapsulating a unified signature interface using Signer; performing bidirectional conversion between the public key of the key pair and SPKI using SpkiUtils to ensure the public key is compatible with external standard PKI systems; and executing the target application operation. This application's embodiment implements complete certificate and key management capabilities under the HarmonyOS system environment, ensures the compatibility of signature results with standard certificate chains, achieves interoperability between public keys and external standard PKI systems, guarantees the compatibility of public key exchange, and possesses cross-device and multi-scenario universality.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a certificate and key management method and terminal based on the HarmonyOS operating system. Background Technology

[0002] With the development of smart devices and the Internet of Vehicles, the secure management of certificates and keys has become an important foundation for ensuring communication security.

[0003] In the Android system, the Keystore API provides secure key generation and storage capabilities. However, the HarmonyOS operating system lacks an equivalent Keystore capability, making secure certificate and key management impossible.

[0004] Therefore, improvements to existing technologies are necessary.

[0005] The above information is provided as background information only to aid in understanding this application and does not constitute an assertion or admission that any of the above content can be used as prior art relative to this application. Summary of the Invention

[0006] This application provides a certificate and key management method and terminal based on the HarmonyOS operating system, so as to realize secure certificate and key management in the HarmonyOS operating system.

[0007] To achieve the above objectives, this application provides the following technical solution:

[0008] Firstly, embodiments of this application provide a certificate and key management method based on the HarmonyOS operating system, including:

[0009] The HarmonyOS Universal Keystore Service (HUKS) interface of the HarmonyOS system is called to generate and store key pairs.

[0010] Bind the key alias used to uniquely identify the key pair to the corresponding certificate chain, and synchronize the binding relationship between the key alias and the certificate chain and the certificate status across multiple devices;

[0011] The unified signature interface is encapsulated using the unified signature tool Signer of the HarmonyOS system. The unified signature interface is used to call the corresponding interface according to the input type to achieve signing and verification.

[0012] The public key format conversion tool SpkiUtils of the HarmonyOS system is used to perform bidirectional conversion between the public key of the key pair and the subject public key information SPKI, so that the public key can be compatible with external standard public key infrastructure (PKI) systems.

[0013] Based on the key pair, the certificate chain, and the unified signature interface, the target application operation is executed.

[0014] Optionally, the target application operations include digital key generation, public key exchange, and / or fast authentication.

[0015] Optional, also includes:

[0016] The private key is stored and managed through HUKS, and the public key and the certificate chain are stored in a distributed file system.

[0017] Optionally, the step of calling the corresponding interface according to the input type to implement signature and verification includes:

[0018] If the input is the original private key, the native cryptographic operation interface cryptoFramework of the HarmonyOS system is called to generate a signature result; if the input is a key alias, the HUKS interface is called to generate a signature result.

[0019] The signature result is verified using the public key and the certificate chain.

[0020] Optionally, it also includes: using the ByteUtils tool to automatically convert the signature result from r||s format to DER encoding format so that the signature result is compatible with the certificate chain.

[0021] Optionally, it also includes: providing a unified management interface for the key pair and the certificate chain, wherein the unified management interface supports query, deletion and update functions for the key pair and the certificate chain.

[0022] Secondly, embodiments of this application provide a certificate and key management device based on the HarmonyOS operating system, used to implement the certificate and key management method based on the HarmonyOS operating system described in any of the above claims; the certificate and key management device includes:

[0023] The HUKS service layer provides a HUKS interface to generate key pairs and binds a key alias used to uniquely identify the key pair to the corresponding certificate chain.

[0024] The file storage layer is used to store the key pairs and corresponding certificate chains, and to synchronize the binding relationship between the key aliases and certificate chains and the certificate status across multiple devices.

[0025] The core functionality layer provides various tools to encapsulate a unified signature interface and public key format conversion;

[0026] The application module is used to bind the key alias used to uniquely identify the key pair to the corresponding certificate chain, and to call the tool to complete the target application logic.

[0027] Optionally, the core functional layer includes:

[0028] The byte encoding tool ByteUtils is used to automatically convert the signing result from r||s format to DER encoding so that the signing result is compatible with the certificate chain;

[0029] The unified signature tool Signer provides a unified signature interface that is compatible with both raw private key and key alias input modes.

[0030] The public key format conversion tool SpkiUtils is used to perform bidirectional conversion between the public key of the key pair and SPKI, so that the public key can be compatible with external standard PKI systems;

[0031] The KeyOperation cryptographic operation tool is used to implement Elliptic Curve Diffie-Hellman Key Negotiation (ECDH), Hash-based Key Derivation (HKDF), and AES-based Message Authentication Code (AES-CMAC) generation to support rapid authentication scenarios.

[0032] Thirdly, embodiments of this application provide a certificate and key management device based on the HarmonyOS operating system, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the certificate and key management method based on the HarmonyOS operating system described above.

[0033] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions thereon, which are executed by a computer processor to implement the certificate and key management method based on the HarmonyOS operating system described above.

[0034] Compared with the prior art, this application has the following beneficial effects:

[0035] It has achieved complete certificate and key management capabilities in the HarmonyOS system environment: by calling the HUKS interface to generate and store key pairs, and combining the unified signature tool Signer and the public key format conversion tool SpkiUtils, it has built a full-process management capability in the HarmonyOS system from key generation, certificate binding to signature verification and public key interoperability, making up for the lack of a unified key management service in the native HarmonyOS.

[0036] It enables cross-device binding and synchronization of certificate chains and key pairs: By binding key aliases to certificate chains and synchronizing binding relationships and certificate status across multiple devices, it solves the problem of inconsistent certificate and key status in multi-device scenarios, and supports seamless collaboration of digital key services across devices such as mobile phones, watches, and in-vehicle systems.

[0037] It ensures the compatibility of the signature result with the standard certificate chain: the unified signature interface is encapsulated by the unified signature tool Signer, and the corresponding underlying interface is called according to the input type to realize signing and verification, ensuring that the signature result can be verified normally by the standard certificate chain, and solving the interoperability problem with external PKI systems.

[0038] It enables interoperability between public keys and external standard PKI systems: Through the public key format conversion tool SpkiUtils, the public key of the key pair is bidirectionally converted between raw point and SPKI, so that the public key generated by HarmonyOS device can be recognized and used by external standard PKI systems, ensuring the compatibility of public key exchange.

[0039] It has cross-device and multi-scenario versatility: This solution can be widely used in scenarios that require digital certificate and key management, such as vehicle networking, smart home, and mobile payment, and is especially suitable for multi-device collaboration scenarios under the HarmonyOS distributed architecture.

[0040] This application has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of this application. Attached Figure Description

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

[0042] Figure 1 This is a system architecture diagram of the certificate and key management device provided in the embodiments of this application;

[0043] Figure 2 This is a flowchart of the certificate and key management method provided in the embodiments of this application;

[0044] Figure 3 This is a flowchart of the key generation and storage process provided in the embodiments of this application;

[0045] Figure 4 This is a flowchart of the certificate binding and synchronization process provided in the embodiments of this application;

[0046] Figure 5 This is a flowchart of the signature and verification process provided in an embodiment of this application;

[0047] Figure 6 This is a flowchart of the car key fast authentication process provided in the embodiments of this application. Detailed Implementation

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

[0049] The inventors discovered that the lack of a Keystore capability equivalent to that of the Android system in the HarmonyOS operating system leads to the following problems in application certificate and key management:

[0050] It cannot securely generate and store keys, and lacks a unified interface.

[0051] The inability to bind and synchronize certificates and keys results in insufficient security in cross-device scenarios.

[0052] The signature result cannot be guaranteed to be compatible with the standard certificate chain, which affects interoperability.

[0053] In the context of connected vehicles and IoT (Internet of Things) scenarios, rapid authentication across devices is not possible.

[0054] For this purpose, please refer to Figure 1 This application provides a certificate and key management device based on the HarmonyOS operating system, including:

[0055] The HUKS service layer provides the HUKS interface to generate key pairs and binds the key alias used to uniquely identify the key pair to the corresponding certificate chain.

[0056] The file storage layer is used to store key pairs and corresponding certificate chains, and to synchronize the binding relationship between key aliases and certificate chains and the certificate status across multiple devices.

[0057] The core functionality layer provides various tools to encapsulate a unified signature interface and public key format conversion;

[0058] The application module is used to bind key aliases used to uniquely identify key pairs to the corresponding certificate chains, and to call tools to complete the target application logic.

[0059] Accordingly, please refer to Figure 2 This application provides a certificate and key management method based on the HarmonyOS operating system, including:

[0060] S1. Call the HUKS (HarmonyOS Universal Keystore Service) interface of the HarmonyOS system to generate and store key pairs.

[0061] S2. Bind the key alias used to uniquely identify the key pair to the corresponding certificate chain, and synchronize the binding relationship between the key alias and the certificate chain and the certificate status across multiple devices.

[0062] S3. The unified signature tool Signer of HarmonyOS is used to encapsulate the unified signature interface. The unified signature interface is used to call the corresponding interface according to the input type to achieve signing and verification.

[0063] S4. The public key format conversion tool SpkiUtils of the HarmonyOS system performs bidirectional conversion between the public key of the key pair and SPKI, so that the public key can be compatible with external standard PKI (Public Key Infrastructure) systems.

[0064] S5 executes target application operations based on key pairs, certificate chains, and unified signature interfaces.

[0065] In summary, the certificate and key management method and apparatus based on the HarmonyOS operating system provided in this application have the following characteristics compared with the prior art:

[0066] It provides complete certificate and key management capabilities in the HarmonyOS environment: by calling the HUKS interface to generate and store key pairs, and combining the unified signature tool Signer and the public key format conversion tool SpkiUtils, it builds a full-process management capability in the HarmonyOS system from key generation, certificate binding to signature verification and public key interoperability, making up for the lack of a unified key management service in HarmonyOS natively.

[0067] It enables cross-device binding and synchronization of certificates and keys: By binding key aliases to the certificate chain and synchronizing the binding relationship and certificate status across multiple devices, it solves the problem of inconsistent certificate and key status in multi-device scenarios and supports seamless collaboration of digital key services across devices such as mobile phones, watches, and in-vehicle systems.

[0068] It ensures the compatibility of the signature result with the standard certificate chain: the unified signature interface is encapsulated by the unified signature tool Signer, and the corresponding underlying interface is called according to the input type to realize signing and verification, ensuring that the signature result can be verified normally by the standard certificate chain, and solving the interoperability problem with external PKI systems.

[0069] It enables interoperability between public keys and external standard PKI systems: Through the public key format conversion tool SpkiUtils, the public key of the key pair is bidirectionally converted between raw point and SPKI, so that the public key generated by HarmonyOS device can be recognized and used by external standard PKI systems, ensuring the compatibility of public key exchange.

[0070] It has cross-device and multi-scenario versatility: This solution can be widely used in scenarios that require digital certificate and key management, such as vehicle networking, smart home, and mobile payment, and is especially suitable for multi-device collaboration scenarios under the HarmonyOS distributed architecture.

[0071] In one alternative implementation, such as Figure 2 As shown, the core functional layer mentioned above specifically includes: ByteUtils, Signer, SpkiUtils, and KeyOperation.

[0072] ByteUtils, a byte encoding tool, provides low-level data encoding and format conversion capabilities, resolving compatibility issues between signature results and standard certificate chains. The core functions of ByteUtils include: concatenation and parsing of TLV (Tag-Length-Value) format; encoding and decoding of ASN.1 abstract syntax tags; and conversion of raw ECDSA signatures (r||s format) to DER encoded format, ensuring compatibility between signature results and certificate chains.

[0073] Signer, a unified signature tool, provides a single entry point for signing, shielding users from underlying implementation differences and simplifying applications' calls. The core functionalities of Signer include:

[0074] Input adaptation: It is compatible with both the original private key (PriKey) and the HUKS key alias (alias) input modes, and automatically selects to call the HarmonyOS native cryptoFramework or HUKS service to complete the signing based on the input type;

[0075] Algorithm support: Supports both RSA and ECDSA asymmetric signature algorithms;

[0076] Output compatibility: When the algorithm is ECDSA, ByteUtils is automatically called to convert the signature result from the raw format (r||s, i.e., two large integers directly concatenated) to the DER encoded format to ensure compatibility with the standard certificate chain; RSA signatures do not require conversion.

[0077] The public key format conversion tool SpkiUtils is used to bidirectionally convert the public key of a key pair between RawPoint and SPKI (Subject Public Key Info) to ensure compatibility with external standard PKI systems. RawPoint refers to the original coordinate byte representation (x, y) of the elliptic curve public key; SPKI refers to the standard structure for storing the public key in an X.509 certificate; bidirectional conversion supports both RawPoint to SPKI and SPKI to RawPoint conversions. SPKI is the standard format for storing public keys in X.509 certificates. After conversion, the public key can be exchanged seamlessly between HarmonyOS devices and external systems (such as vehicle networking platforms and other PKI systems).

[0078] The cryptographic operation tool KeyOperation is used to implement ECDH (Elliptic Curve Diffie-Hellman Key Negotiation), HKDF (Hash-based Key Derivation Function) key derivation, and AES-CMAC (AES-based Message Authentication Code) message authentication code generation to support fast authentication scenarios.

[0079] In an optional implementation, the method further includes: storing and managing the private key via HUKS, and storing the public key and certificate chain in a distributed file system. Based on this, the private key is hosted by HUKS in a secure environment (TEE), ensuring a high level of security; the public key and certificate chain are stored in the distributed file system, automatically synchronized across multiple devices, guaranteeing consistent certificate status for digital key services on mobile phones, watches, and in-vehicle systems; that is, sensitive private keys receive the highest level of protection, and public information is shared across devices, simultaneously meeting both security requirements and distributed scenario needs.

[0080] For example, please refer to Figure 3 The key generation and storage process in this application embodiment includes: the application calling the Keystore interface to request key generation; the Keystore calling the HUKS service to generate an ECC256 key pair (referring to a key pair based on elliptic curve cryptography with a key length of 256 bits); the public key being exported and saved to the file system; the private key being managed by HUKS and not directly exposed; and the application accessing the key through an alias.

[0081] For example, please refer to Figure 4 The certificate binding and synchronization process in this application embodiment includes: the application calls the certificate management tool CertificateManager to save the certificate; the certificate is bound to the key alias; the certificate is stored in a distributed file system; multiple devices share the certificate status through a synchronization mechanism; and the application can query, update, or delete the certificate.

[0082] For example, please refer to Figure 5The signing and verification process in this embodiment includes: the application calls the Signer to request a signature; the Signer determines whether the input is PriKey (original private key) or alias (key alias); if it is PriKey, it calls the native cryptographic operation interface cryptoFramework provided by the HarmonyOS system; if it is alias, it calls the HUKS interface; if the signature result is in r||s format, ByteUtils converts it to DER encoding format (which can identify encoding rules and is the standard binary encoding format used by X.509 certificates and signatures); the verification end uses the public key and certificate chain to complete the verification.

[0083] It should be noted that in step S5, the target application operations include digital key generation, public key exchange, and / or fast authentication.

[0084] For example, please refer to Figure 6 The fast car key authentication process in this application embodiment includes:

[0085] The terminal generates a long-term key pair and saves the vehicle certificate;

[0086] The terminal generates a temporary ECC256 key pair and saves the private key to the Keystore;

[0087] Both parties exchange public keys and derive session keys using HKDF (hash-based key derivation function);

[0088] Use AES-CMAC to generate an authentication code and complete the fast authentication;

[0089] Standard authentication is performed using long-term key pairs, combined with a certificate chain to verify legitimacy.

[0090] Thirdly, embodiments of this application provide a certificate and key management device based on the HarmonyOS operating system, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the certificate and key management method based on the HarmonyOS operating system as described in any of the above embodiments.

[0091] The above-described device can execute the methods provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the methods, which will not be described in detail here.

[0092] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions thereon, which, when executed by a processor, implement the certificate and key management method based on the HarmonyOS operating system as provided in all embodiments of this application.

[0093] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0094] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0095] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0096] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0097] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A certificate and key management method based on the HarmonyOS operating system, characterized in that, include: The HarmonyOS Universal Keystore Service (HUKS) interface of the HarmonyOS system is called to generate and store key pairs. Bind the key alias used to uniquely identify the key pair to the corresponding certificate chain, and synchronize the binding relationship between the key alias and the certificate chain and the certificate status across multiple devices; The unified signature interface is encapsulated using the unified signature tool Signer of the HarmonyOS system. The unified signature interface is used to call the corresponding interface according to the input type to achieve signing and verification. The public key format conversion tool SpkiUtils of the HarmonyOS system is used to perform bidirectional conversion between the public key of the key pair and the subject public key information SPKI, so that the public key can be compatible with external standard public key infrastructure (PKI) systems. Based on the key pair, the certificate chain, and the unified signature interface, the target application operation is executed.

2. The certificate and key management method based on the HarmonyOS operating system according to claim 1, characterized in that, The target application operations include digital key generation, public key exchange, and / or fast authentication.

3. The certificate and key management method based on the HarmonyOS operating system according to claim 1, characterized in that, Also includes: The private key is stored and managed through HUKS, and the public key and the certificate chain are stored in a distributed file system.

4. The certificate and key management method based on the HarmonyOS operating system according to claim 1, characterized in that, The step of calling the corresponding interface based on the input type to achieve signature and verification includes: If the input is the original private key, the native cryptographic operation interface cryptoFramework of the HarmonyOS system is called to generate a signature result; if the input is a key alias, the HUKS interface is called to generate a signature result. The signature result is verified using the public key and the certificate chain.

5. The certificate and key management method based on the HarmonyOS operating system according to claim 4, characterized in that, Also includes: The application ByteUtils tool automatically converts the signature result from r||s format to DER encoding format, so that the signature result is compatible with the certificate chain.

6. The certificate and key management method based on the HarmonyOS operating system according to claim 1, characterized in that, Also includes: A unified management interface is provided for the key pair and the certificate chain, which supports querying, deleting and updating functions for the key pair and the certificate chain.

7. A certificate and key management device based on the HarmonyOS operating system, characterized in that, Used to implement the certificate and key management method based on the HarmonyOS operating system as described in any one of claims 1 to 6; The certificate and key management device includes: The HUKS service layer provides a HUKS interface to generate key pairs and binds a key alias used to uniquely identify the key pair to the corresponding certificate chain. The file storage layer is used to store the key pairs and corresponding certificate chains, and to synchronize the binding relationship between the key aliases and certificate chains and the certificate status across multiple devices. The core functionality layer provides various tools to at least implement a unified signature interface encapsulation and public key format conversion; The application module is used to bind the key alias used to uniquely identify the key pair to the corresponding certificate chain, and to call the tool to complete the target application logic.

8. The certificate and key management device based on the HarmonyOS operating system according to claim 7, characterized in that, The core functional layer includes: The byte encoding tool ByteUtils is used to automatically convert the signing result from r||s format to DER encoding so that the signing result is compatible with the certificate chain; The unified signature tool Signer provides a unified signature interface that is compatible with both raw private key and key alias input modes. The public key format conversion tool SpkiUtils is used to perform bidirectional conversion between the public key of the key pair and SPKI, so that the public key can be compatible with external standard PKI systems; The KeyOperation cryptographic operation tool is used to implement Elliptic Curve Diffie-Hellman Key Negotiation (ECDH), Hash-based Key Derivation (HKDF), and AES-based Message Authentication Code (AES-CMAC) generation to support rapid authentication scenarios.

9. A certificate and key management device based on the HarmonyOS operating system, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the certificate and key management method based on the HarmonyOS operating system as described in any one of claims 1-6.

10. A computer-readable storage medium having computer-executable instructions stored thereon, characterized in that, The computer-executable instructions are executed by a computer processor to implement the certificate and key management method based on the HarmonyOS operating system as described in any one of claims 1-6.

Images