AP system security protection method based on key injection and virtual machine isolation

Abstract

An AP system security protection method based on key injection and virtual machine isolation includes: obtaining a first device key and a certificate chain; wherein the certificate chain includes a first device certificate; the first device key includes a first private key; verifying the legitimacy of the first device certificate in the certificate chain; deriving a second device key based on the first device key, signing the first private key to obtain a second device certificate, and placing the second device certificate at the end of the certificate chain; wherein the second device key includes a second private key; storing the second private key in a secure virtual machine; and storing the certificate chain including the first device certificate and the second device certificate in non-volatile storage. The present invention can provide a flexible key update and access control mechanism while ensuring key security, thereby resolving problems such as low data transmission security and low injection efficiency in trusted communications.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to an AP system security protection method based on key injection and virtual machine isolation. Background Art

[0002] Regarding protection technologies for system security in trusted communication environments, relevant technologies that have been implemented in the fields of finance, enterprise, medical care, Internet of Things, transportation, and cloud computing include: combining hardware security modules with centralized key management, automated key rotation technology, public key infrastructure technology, and identity-based encryption technology.

[0003] Among them, the technology that combines hardware security modules and centralized key management centrally manages the key life cycle through KMS (key management system) or HSM (hardware security module). Typical applications include bank U-shield authentication, enterprise VPN access, etc.; key rotation automation technology is usually applicable to compliance requirements such as finance and government affairs. Cloud service providers use HSM to implement regular key rotation; public key infrastructure technology adopts CA (certificate authority) and digital certificate system, and is widely used in online banking USB Key, HTTPS / TLS secure communication, VPN authentication and other fields; identity-based encryption technology directly uses identifiers such as user email as public key, and is applied to scenarios such as smart door locks and IoT device authentication.

[0004] Currently, traditional HTTPS handles key negotiation and encryption and decryption in user mode, posing security risks. These processes are vulnerable to malware attacks and memory snooping. The lack of hardware isolation creates the risk of man-in-the-middle attacks, potentially allowing keys to be stolen or inferred. User-mode keys are also susceptible to accidental access by other programs, making confidentiality difficult to ensure. Automated key rotation techniques struggle to ensure the security of the long-term rotation process for security chips. Traditional key injection solutions suffer from significant usability shortcomings. Hardware devices (such as USB Shields and smart cards) require frequent plugging and unplugging, USB keys rely on manual copying, and dynamic tokens require memorizing complex verification codes. These reliance on physical media and manual operations severely impact efficiency in mobile office environments and large-scale deployments. Traditional physical key injection methods are inefficient. USB Shields, smart cards, and USB keys are all limited by physical interface speeds, resulting in slow key transmission. This serial operation creates a significant bottleneck in mass deployments, failing to meet rapid distribution requirements or efficiently configure large-scale device clusters. They also suffer from low security and significant usability shortcomings in trusted communication environments. Summary of the Invention

[0005] The purpose of the present invention is to provide an AP system security protection method based on key injection and virtual machine isolation to solve the problems of low data transmission security and low injection efficiency in existing trusted communications.

[0006] In order to solve the above-mentioned technical problems, the purpose of the present invention is achieved as follows:

[0007] The AP system security protection method based on key injection and virtual machine isolation is characterized by comprising the following steps:

[0008] Obtaining a first device key and a certificate chain; wherein the certificate chain includes a first device certificate; the first device key includes a first private key; and verifying the legitimacy of the first device certificate in the certificate chain;

[0009] deriving a second device key from the first device key, signing the first private key to obtain a second device certificate, and placing the second device certificate at the end of the certificate chain; wherein the second device key includes a second private key;

[0010] Storing the second private key in the secure virtual machine;

[0011] The certificate chain including the first device certificate and the second device certificate is stored in non-volatile storage.

[0012] The beneficial effects of the present invention are as follows:

[0013] By verifying the legitimacy of the certificates in the certificate chain, ensuring the integrity of the certificate chain and the validity of the signature, this ensures that only certificates issued by a trusted CA can be injected into the AP system, enhancing security. Furthermore, by deriving a second device key, the AP system does not directly use the first device key provided by the key injection platform, effectively preventing the theft and misuse of the first private key within the AP system. After derivation, the AP system's second private key is stored in a secure virtual machine, further enhancing system security. Furthermore, by combining the secure virtual machine with the key injection platform, an enhanced security architecture is constructed.

[0014] Furthermore, the obtaining of the first device key and the certificate chain is specifically as follows:

[0015] The first device key and the certificate chain are obtained through software injection, hardware injection, or a hybrid injection method.

[0016] The beneficial effects of adopting the above improvements are as follows:

[0017] Flexible key injection methods improve operational efficiency, transcending the USB interface limitations of traditional USB-shields. Support for multiple key injection methods, including secure chip pre-setting, NFC transmission, and remote distribution, enables efficient batch deployment. Compared to USB-shield operations, this invention can simultaneously and contactlessly inject keys into multiple devices, increasing configuration efficiency severalfold and making it particularly suitable for the secure deployment of large-scale device clusters. By supporting diverse key injection options, security requirements for different scenarios can be met. The actual choice should be balanced based on the security needs and cost budget of the business.

[0018] Further, obtaining HUK, and deriving SSK through the HUK;

[0019] The second private key is encrypted using the SSK through the TEE, and the encrypted second private key is stored in the non-volatile storage.

[0020] Further, the encrypted second private key is read from the non-volatile storage, and the encrypted second private key is decrypted by TEE using the SSK.

[0021] The beneficial effects of adopting the above improvements are as follows:

[0022] The TEE ensures full lifecycle protection of the second private key: Regardless of whether the secure VM is terminated, the AP system's second private key is always encrypted and stored in non-volatile storage by the TEE. While the secure VM is running, the second private key is only dynamically decrypted and used by the TEE. If system resources are insufficient and the secure VM is terminated or needs to be rebuilt, the TEE performs both encryption, storage, and decryption recovery of the second private key, ensuring that the second private key never resides in plaintext in non-volatile storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a logical architecture diagram of the AP system security protection method based on key injection and virtual machine isolation of the present invention;

[0024] Figure 2 A schematic diagram of a terminal system architecture of the AP system security protection method based on key injection and virtual machine isolation of the present invention;

[0025] Figure 3 A schematic diagram of the process of AP system verification certificate in the AP system security protection method based on key injection and virtual machine isolation of the present invention;

[0026] Figure 4 The figure is a schematic diagram of the derivation and protection relationship of the AP-side key system of the AP system security protection method based on key injection and virtual machine isolation of the present invention. DETAILED DESCRIPTION

[0027] In order to have a further understanding of the technical solution and beneficial effects of the present invention, the technical solution and beneficial effects of the present invention are described in detail below with reference to the accompanying drawings.

[0028] Figure 1 This is a logical architecture diagram of the AP system security protection method based on key injection and virtual machine isolation of the present invention, as shown in FIG. Figure 1 As shown, the AP system security protection method based on key injection and virtual machine isolation of the present invention includes:

[0029] Get the first device key and certificate chain (corresponding to Figure 1 "① Obtaining a certificate key" in the certificate chain); wherein the certificate chain includes a first device certificate, and the first device key includes a first private key; verifying the legitimacy of the first device certificate in the certificate chain;

[0030] The AP system derives the second device key (corresponding to Figure 1 The second device certificate (corresponding to Figure 1 "③ Generate Certificate"); place the second device certificate at the end of the certificate chain; wherein the second device key includes the second private key;

[0031] Store the second private key in the secure virtual machine (corresponding to Figure 1 "④Store private key" in the above code);

[0032] Store the certificate chain containing the first device certificate and the second device certificate into non-volatile storage (corresponding to Figure 1 ⑤Store certificates and public keys).

[0033] The beneficial effects of the present invention are as follows:

[0034] By verifying the legitimacy of the certificates in the certificate chain, ensuring the integrity of the certificate chain and the validity of the signature, this ensures that only certificates issued by a trusted CA can be injected into the AP system, enhancing security. Furthermore, by deriving a second device key, the AP system does not directly use the first device key provided by the key injection platform, effectively preventing the theft and misuse of the first private key within the AP system. After derivation, the AP system's second private key is stored in a secure virtual machine, further enhancing system security. Furthermore, by combining the secure virtual machine with the key injection platform, an enhanced security architecture is constructed.

[0035] like Figure 2, is a schematic diagram of the terminal system architecture in this embodiment. The terminal generally consists of two parts: the AP system and the key injection platform. The AP system's function is to interact with users, run applications, and process user data, while integrating the secure virtual machine service and the certificate key system. The secure virtual machine service supports multi-instance operation to ensure secure isolation and data protection; the certificate key system manages keys and certificates, providing security functions such as authentication, data encryption, and integrity protection. The core functions of the key injection platform include key management and key injection. The AP system obtains the required keys and certificates from the key injection platform.

[0036] In this embodiment, the key injection platform can be implemented through a variety of technical means. These can be based on hardware such as security chips and USB shields, software mechanisms (such as software encryption modules), or hybrid injection methods such as calling TEE APIs. This design allows the system to be flexibly applied to a variety of scenarios while ensuring the security of data transmission and processing. Specifically, in this embodiment, the various components of the terminal system architecture are described and introduced in detail using a security chip as the key injection platform.

[0037] In actual work and security use scenarios, to better protect the device and thus improve security, the injection timing of keys and certificates generally includes: when the terminal leaves the factory, during non-first startup, and during system operation. The terminal in this embodiment supports the above-mentioned multiple key and certificate injection timings. Among them, injection at the factory is completed in a closed factory environment, which is the most secure. This stage is suitable for scenarios where keys are pre-configured, ensuring that the terminal has strong security capabilities when it is delivered. Injection during non-first startup is performed during the terminal initialization phase, which takes into account both security and flexibility. At this stage, keys can be dynamically injected according to demand, which is suitable for situations where keys need to be dynamically configured according to user or scenario requirements. Injection during system runtime is completed when the terminal is running, which is the most flexible. This stage is suitable for scenarios where keys need to be updated regularly, which can solve the problem of key leakage or expiration. Therefore, different injection timings can be selected according to security requirements and usage scenarios, which can further improve work efficiency in terms of flexible adaptation and efficient usability.

[0038] The terminal system in this embodiment supports key certificate injection in different ways at different times. Keys can be pre-set in batches at the factory, remote injection is supported for non-initial activation, and updates can be made on demand during runtime. This flexible design allows users in fields such as finance, healthcare, and the Internet of Things to flexibly choose the most suitable key configuration method, meeting the efficiency requirements of large-scale deployment while taking into account the flexibility of business operations, significantly reducing usage complexity. This feature significantly enhances the security and flexibility of the system, enabling it to select the most appropriate key certificate injection strategy based on different application scenarios and security requirements, thereby effectively ensuring the security of communications and data.

[0039] In the present invention, the key injection platform injects the first device key and the certificate chain into the AP system in a manner including software injection, hardware injection and hybrid injection.

[0040] Software injection refers to loading key certificates into the system through pure software methods (such as configuration files, API interfaces, or network transmission). It is suitable for scenarios such as development and testing, cloud services, and IoT device OTA updates that require high deployment efficiency and relatively controllable security requirements. Its advantage lies in its flexibility and convenience, but it also has lower security.

[0041] The hardware injection method refers to the secure writing and storage of key certificates through a security chip or dedicated device (such as a USB shield, NFC card, or USB key). It is suitable for scenarios with high security requirements, such as financial payments and digital identity authentication. It provides physical-level security protection and can effectively resist software attacks, but the cost is relatively high.

[0042] The hybrid injection method refers to the generation and storage of keys in a hardware-isolated environment, which are used by calling secure APIs. It is used in scenarios such as mobile payments and adopts hardware-level protection, but is more dependent on specific hardware.

[0043] The beneficial effects of adopting the above improvements in this embodiment are as follows:

[0044] Flexible key injection methods improve operational efficiency, transcending the USB interface limitations of traditional USB-shields. Support for multiple key injection methods, including secure chip pre-setting, NFC transmission, and remote distribution, enables efficient batch deployment. Compared to USB-shield operations, this invention can simultaneously and contactlessly inject keys into multiple devices, increasing configuration efficiency severalfold and making it particularly suitable for the secure deployment of large-scale device clusters. By supporting diverse key injection options, security requirements for different scenarios can be met. The actual choice should be balanced based on the security needs and cost budget of the business.

[0045] Figure 3 This is a schematic diagram of the process of AP system certificate verification in the AP system security protection method based on key injection and virtual machine isolation of the present invention. Taking the security chip as the key injection platform as an example, the complete certificate and key system of the present invention is introduced.

[0046] It should be noted that each key (such as Figure 3 The device key in the certificate and the AP device key) include a public key and a private key, which appear in pairs. Figure 3 The communication certificate, device certificate, and AP device certificate in the .

[0047] The security chip key system includes three types of keys: authority key, communication key and device key (i.e. first device key).

[0048] The authority key is a pair of public and private keys. The private key is kept by the CA (certification authority, a trusted organization responsible for issuing and managing digital certificates. The organization protects the private key through secure hardware and strict access control mechanisms to prevent unauthorized use) and is not disclosed to the public. The public key is included in the root certificate, which is open to the entire network and pre-installed in the AP system. The AP system uses it to verify the legitimacy of the certificate and is the root of the entire certificate chain.

[0049] The device key is what is referred to as the first device key injected into the AP system by the key injection platform in this invention. It is derived from the communication key and is transmitted to the AP system by the security chip when the system is first started. The communication key is pre-installed in the security chip of each terminal.

[0050] The certificate system of the security chip includes two types of certificates: communication certificate and device certificate (i.e., first device certificate). The communication certificate is signed by the private key of the authority key and is placed in the security chip during production. Figure 3 The first device certificate is signed by the private key of the communication key and is generated when the first device key is derived from the communication key. More specifically, the second device key is derived from the first device key, and the second device certificate is signed by the first private key of the first device key. The second device certificate is attached to the end of the certificate chain, i.e., the second device certificate becomes the end certificate in the certificate chain.

[0051] The terminal system proposed in this embodiment supports injecting key certificates (i.e., the first device key and certificate chain) at any time. However, it is unsafe to directly use the private key of the first device key of the key injection platform in the AP system. In order to protect the first private key from being stolen and abused in the AP system and enhance the security of key usage in the AP system, this embodiment ultimately uses the second device key in the AP system (i.e., Figure 3The AP device key in the key injection platform is derived from the first device key pair. After derivation, the second private key of the second device key in the AP system is stored in a secure virtual machine, providing a double layer of security.

[0052] Therefore, in this disclosure, the so-called second device key refers to the AP-side device key derived by the AP system from the first device key. This is because transferring the first private key out of the security chip violates fundamental security design principles, even if the private key is not the core communication key but rather the first device key derived from the communication key. To enhance security, the AP system does not directly use the first device key obtained from the security chip, but instead derives a second device key.

[0053] Figure 4 Schematic diagram of the derivation and protection relationship of the AP system key system of the AP system security protection method based on key injection and virtual machine isolation of the present invention, as shown Figure 4 Specifically, in this embodiment, the AP system key system is responsible for local AP system security, namely, the confidentiality and integrity of the hardware, firmware, block devices, and file systems within the AP system. It includes the SSK (Secure Storage Key) and the second device key. The SSK is derived from the HUK (Hardware Unique Key) and is a symmetric key used to encrypt sensitive data stored locally on the device. The HUK is a unique key generated during chip manufacturing and permanently stored in the device's secure storage area. It cannot be altered or copied, and even devices of the same model have completely different HUKs. Because the HUK is unique to each device, the SSK derived from the HUK is also unique. The second device key is derived from the first device key in the security chip, which in turn is derived from the communication key. To protect the security of the second private key in the AP system, it must be encrypted and stored in non-volatile storage via the TEE. The stored content is encrypted by the SSK. A Rich Execution Environment (REE) refers to an operating environment primarily used in mobile devices.

[0054] Please continue reading Figure 3As shown, the AP system certificate includes a communication certificate, a primary device certificate, and an AP-side device certificate (also known as a secondary device certificate). The AP system verifies certificates through a chain of certificates, as follows: Each certificate contains a public key as part of its content. The legitimacy of the next-level certificate is verified using the public key in the previous-level certificate. Therefore, the legitimacy of the final certificate in the chain (including the public key) is verified using the penultimate certificate. This continues in this order, ultimately using the root certificate to verify the legitimacy of the first-level certificate. The root certificate is pre-installed on the machine or in the code and does not require verification.

[0055] The second device certificate is signed by the first private key of the first device key to ensure legitimacy. After the signature is completed, the AP system releases the memory occupied by the first device key of the security chip and only retains the second device certificate of the AP system. This process ensures that the security chip only briefly transmits a private key (the first private key of the first device key) and releases the memory immediately after completing the signing task. Finally, the AP system retains three certificates and one private key (i.e. Figure 3 The communication certificate, device certificate, AP device certificate, and AP device key contain the private key of the AP device key. Since the previous section mentioned that the certificate contains the public key, it is not emphasized here that the AP device key of the AP system is a key pair).

[0056] A secure virtual machine (VM) is a virtual machine that can run in a relatively secure environment. In this embodiment, the secure VM provides services for secure use and protection of the second private key, and can also support multi-instance operation, ensuring secure isolation and data protection. However, for secure VMs, there may be issues such as memory or resource shortages leading to the destruction of the secure VM, or other unexpected circumstances leading to the termination of the secure VM, which cannot guarantee the persistence of the secure VM. Therefore, this embodiment also proposes to implement full lifecycle protection of the second private key through TEE, as follows.

[0057] TEE, or Trusted Execution Environment (TEE), is a relatively secure and effective method for protecting operational security. Through a secure enclave on the processor, TEE provides a computing environment isolated from the regular operating system. This ensures that computations within the TEE are not affected by the regular operating system, thereby guaranteeing the confidentiality and integrity of the code and data loaded into the TEE.

[0058] Non-volatile storage refers to data that can be retained even after a power outage. Compared to volatile storage, non-volatile storage is immune to data loss caused by unexpected terminations. Therefore, storing data in non-volatile storage ensures data persistence. Generally speaking, non-volatile storage devices include read-only memory, programmable read-only memory, and erasable programmable read-only memory. The appropriate choice can be made based on actual needs.

[0059] The system uses TEE to implement full lifecycle protection of the second private key. Regardless of whether the secure virtual machine is terminated, the second private key of the AP system is always encrypted and stored in non-volatile storage by the TEE. When the secure virtual machine is running, the second private key is only dynamically decrypted and used in the TEE. When the secure virtual machine is terminated or needs to be rebuilt due to system resource constraints, the encryption, storage, and decryption recovery of the second private key are all completed by the TEE, ensuring that the second private key never resides in non-volatile storage in plain text. The second private key is plain text in the memory of the secure virtual machine. When the second private key needs to be saved to non-volatile storage, the secure virtual machine requests TEE encryption, and then stores it in non-volatile storage after encryption. When the secure virtual machine needs to load the second key from non-volatile storage, the secure virtual machine extracts the ciphertext, requests TEE decryption, and obtains the plain text second key.

[0060] Specifically, when the secure virtual machine is operating normally, if the second private key of the AP system is not used, the secure virtual machine will encrypt the private key through TEE and store it in non-volatile storage. When the second private key is used, the encrypted second private key will be read and the TEE will be requested for decryption. However, the system cannot guarantee the persistence of the secure virtual machine. When memory or resources are tight, the virtual machine may be destroyed and recreated when needed. When the virtual machine is destroyed, the virtual machine needs to first store the second private key of the second device key of the AP system in non-volatile storage to ensure data persistence. In order to ensure the confidentiality of information, the secure virtual machine completes the encryption and decryption storage of the second private key through TEE throughout the entire process: when the secure virtual machine is destroyed, the secure virtual machine requests TEE to encrypt the second private key, and after obtaining the encryption result, the encryption result is stored in non-volatile storage; when the secure virtual machine is started, the encrypted key is read and sent to TEE for decryption, thereby ensuring the security and availability of the key.

[0061] The benefit of adopting this approach is that it comprehensively safeguards the second private key through a triple-layered protection mechanism. The first layer of protection is: TEE-based private key encryption ensures that the second private key remains encrypted, preventing direct use even if illegally obtained. The second layer of protection requires that all access operations to the second private key be performed through a secure virtual machine, with strict access control. The third layer of protection is that the system runs critical security processes in a virtualized, isolated environment, achieving runtime protection through independent security domains. This multi-dimensional protection system creates a complete security closed loop, encompassing three key aspects: key storage and use, access control, and the execution environment.

[0062] After that, the security status of the key injection platform is verified. Specifically, by verifying the security status of the key injection platform, the security of the first device key and certificate chain obtained in the AP system is ensured, thereby ensuring the security and reliability of the entire terminal.

[0063] The solution proposed in this paper builds a secure key management architecture to enable dynamic key injection and lifecycle management. Combining the key storage protection mechanisms of a hardware-level security chip with virtual machine isolation technology, it establishes a trusted execution area within the application processor's operating environment. This addresses issues such as the vulnerability of static key storage to extraction and the lack of dynamic protection for key usage in traditional AP systems. This solution is particularly suitable for applications requiring a high level of security, such as mobile payments and IoT terminals. It ensures key security while providing flexible key updates and access control mechanisms.

[0064] It should be noted that the certificate chain mechanism in this embodiment, whether it is the certificate chain injected into the AP system by the security chip or the update of the certificate chain based on the signature of the second device certificate, can serve as a key component of trusted verification and provide strong core support for the overall solution. After the key certificate is injected into the AP system, the system ensures the validity of the certificate chain through self-signature verification and adopts a multi-level security protection mechanism: encryption keys are generated based on the key derivation algorithm, and hardware-level encryption storage of keys is implemented through TEE to ensure that the keys are leak-proof throughout their lifecycle; the use of protected private keys must be completed through a secure virtual machine, which provides strict process isolation and access control, and collaborates with the TEE to build a complete trust chain from certificate verification and key protection to secure use, effectively defending against man-in-the-middle attacks. Through the deep integration of a systematic certificate chain verification mechanism, the certificate chain is upgraded from an independent module to a core security link throughout the entire life cycle of the key. The credibility of the certificate chain is ensured by the CA root certificate during the key injection phase, encryption protection is achieved through TEE during the storage phase, and access control is performed through a secure virtual machine during the use phase, forming a closed-loop protection system covering the entire process of "verification-storage-use", making the certificate chain a key technical support for achieving "trusted injection + secure storage".

[0065] It should be noted that the terms "first," "second," and the like in the description of this application are used to distinguish similar objects and do not imply a specific order or precedence. The order used for similar objects may be interchanged where appropriate, such that the embodiments of the present application described herein can be implemented in an order other than the order shown or described.

[0066] Although the present invention has been described using the above preferred embodiments, they are not intended to limit the scope of protection of the present invention. Any person skilled in the art may make various changes and modifications to the above embodiments without departing from the spirit and scope of the present invention. These changes and modifications are still within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be based on the definition of the claims.

Claims

1. AP system security protection method based on key injection and virtual machine isolation, characterized in that: include: Obtaining a first device key and a certificate chain; wherein the certificate chain includes a first device certificate; the first device key includes a first private key; and verifying the legitimacy of the first device certificate in the certificate chain; deriving a second device key from the first device key, signing the first private key to obtain a second device certificate, and placing the second device certificate at the end of the certificate chain; wherein the second device key includes the second private key; Storing the second private key in the secure virtual machine; storing the certificate chain including the first device certificate and the second device certificate in non-volatile storage; Obtain HUK and derive SSK from the HUK; Encrypting the second private key using the SSK through the TEE, and storing the encrypted second private key in non-volatile storage; The encrypted second private key is read from the non-volatile storage, and the encrypted second private key is decrypted by the TEE using the SSK.

2. The AP system security protection method based on key injection and virtual machine isolation according to claim 1, characterized in that: The obtaining of the first device key and the certificate chain is specifically as follows: The first device key and the certificate chain are obtained through software injection, hardware injection, or a hybrid injection method.

Images