CN118502881A

CN118502881A - Key management method and system on chip

Info

Publication number: CN118502881A
Application number: CN202410685842.9A
Authority: CN
Inventors: 黎奥; 王博; 李�根; 唐遇星
Original assignee: Phytium Technology Co Ltd
Current assignee: Phytium Technology Co Ltd
Priority date: 2024-05-29
Filing date: 2024-05-29
Publication date: 2024-08-16

Abstract

The embodiment of the specification provides a key management method, which communicates the generation and the calling authority of a virtual machine encryption key with a security firmware, so that the security risks such as key leakage or interception and the like possibly caused by the management of the virtual machine encryption key through a virtual machine monitor are avoided. In addition, when the secure virtual machine is activated, the virtual machine encryption key is loaded in the key storage unit and is called by the secure firmware, so that the virtual machine encryption key can be transmitted through a special secure channel in the calling process, the security boundary of the first processor can not be generated, the virtual machine monitor is prevented from accessing the key loaded in the key storage unit, and the security of the virtual machine encryption key in the calling process is improved.

Description

Key management method and system on chip

Technical Field

The present disclosure relates to the field of computer application technologies, and in particular, to a trusted technology in the field of computer application technologies, and more particularly, to a key management method and a system on a chip.

Background

With the continuous development of computer application technology, new types of Software delivery modes such as SaaS (Software AS A SERVICE ) and the like appear, cloud platform manufacturers can provide Software services through the internet, and users do not need to install and maintain Software locally. In this mode, a software provider will develop and maintain a software application that multiple tenants (or users) can share.

Cloud platform vendors can provide software services in the manner of SaaS for multiple users through software of an architecture such as a multi-tenant application (Software Multitenancy) running on a cloud platform. The multi-tenant application is a software architecture, under the multi-tenant application architecture, a plurality of tenants share the same software instance and database, but the data and configuration of each tenant are isolated, so that the security and privacy of the data are ensured. The architecture can improve the utilization rate of resources, reduce maintenance cost and provide better expandability. In the cloud platform, the tenant can use resources provided by the cloud platform, manage private data, and the like by using a virtual machine. In the running process of the virtual machine, the cloud platform may migrate the virtual machine of the tenant from one host machine to another host machine due to the demands of load balancing, hardware maintenance, resource optimization, disaster recovery switching and the like, and the process is called virtual machine migration. In the cloud platform, security of a large amount of data such as private data of a plurality of tenants and private data of a cloud platform manufacturer needs to be guaranteed, so that security of data of the cloud platform in use scenes such as virtual machine migration is guaranteed.

Disclosure of Invention

The embodiment of the specification provides a key management method and a system on a chip so as to achieve the aim of improving the security of a cloud platform.

In order to achieve the technical purpose, the embodiment of the specification provides the following technical scheme:

In a first aspect, an embodiment of the present disclosure provides a key management method applied to a first processor in a system on a chip, where the system on a chip further includes a cryptographic engine, the cryptographic engine includes a key storage unit, the first processor is configured to execute secure firmware, and the system on a chip further includes a second processor, and the second processor is configured to execute a secure virtual machine, where the key management method includes:

Responding to the starting operation of the secure virtual machine, generating a virtual machine encryption key corresponding to the secure virtual machine by the secure firmware, wherein the virtual machine encryption key is used for encrypting data of the secure virtual machine;

And responding to the activation request of the secure virtual machine, loading the virtual machine encryption key in the key storage unit by the secure firmware, wherein the virtual machine encryption key loaded in the key storage unit is used for being called by the secure firmware.

In a second aspect, an embodiment of the present disclosure provides a key management apparatus applied to a first processor in a system on a chip, the system on a chip further including a cryptographic engine, the cryptographic engine including a key storage unit, the first processor being configured to run secure firmware, the system on a chip further including a second processor, the second processor being configured to run a secure virtual machine, the key management apparatus including:

The starting module is used for responding to the starting operation of the secure virtual machine, the secure firmware generates a virtual machine encryption key corresponding to the secure virtual machine, and the virtual machine encryption key is used for encrypting data of the secure virtual machine;

And the activation module is used for responding to the activation request of the secure virtual machine, the secure firmware loads the virtual machine encryption key in the key storage unit, and the virtual machine encryption key loaded in the key storage unit is used for being called by the secure firmware.

In a third aspect, an embodiment of the present specification further provides a system on a chip, including: a first processor, a second processor, and a cryptographic engine; wherein,

The first processor is used for running secure firmware, the cryptographic engine comprises a key storage unit, and the second processor is used for running a secure virtual machine;

The secure firmware is configured to: responding to the starting operation of the secure virtual machine, generating a virtual machine encryption key corresponding to the secure virtual machine by the secure firmware, wherein the virtual machine encryption key is used for encrypting data of the secure virtual machine;

In a fourth aspect, one embodiment of the present specification also provides a computing device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the key management method as described above when executing the computer program.

In a fifth aspect, an embodiment of the present specification further provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the key management method as described above.

In a sixth aspect, the present description provides a computer program product or a computer program, the computer program product comprising a computer program stored in a computer readable storage medium; the processor of the computer device reads the computer program from the computer readable storage medium, and the processor implements the steps of the key management method described above when executing the computer program.

According to the technical scheme, the key management method provided by the embodiment of the specification can be used for communicating the generation and the calling authority of the encryption key of the virtual machine with the security firmware, so that the security risks of key leakage or interception and the like possibly caused by the management of the encryption key of the virtual machine through the virtual machine monitor are avoided. In addition, when the secure virtual machine is activated, the virtual machine encryption key is loaded in the key storage unit and is called by the secure firmware, so that the virtual machine encryption key can be transmitted through a special secure channel in the calling process, the security boundary of the first processor can not be generated, the virtual machine monitor is prevented from accessing the key loaded in the key storage unit, and the security of the virtual machine encryption key in the calling process is improved.

Drawings

In order to more clearly illustrate the embodiments of the present description or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present description, and that other drawings may be obtained according to the drawings provided without inventive effort to a person skilled in the art.

Fig. 1 is a schematic diagram of an application scenario provided in an embodiment of the present disclosure;

FIG. 2 is a flow chart of a key management method according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram illustrating a process for generating and using a virtual machine encryption key according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram illustrating the replacement of a virtual machine encryption key during a virtual machine state switch according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a process for generating and using a channel unique key according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram illustrating a process for generating and using a virtual machine disk encryption key according to an embodiment of the present disclosure;

fig. 7 is a schematic structural diagram of a key management device according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a system-on-chip according to one embodiment of the present disclosure;

Fig. 9 is a schematic structural diagram of a computing device according to an embodiment of the present disclosure.

Detailed Description

Unless defined otherwise, technical or scientific terms used in the embodiments of the present specification should be given the ordinary meaning as understood by one of ordinary skill in the art to which the present specification belongs. The terms "first," "second," and the like, as used in the embodiments of the present disclosure, do not denote any order, quantity, or importance, but rather are used to avoid intermixing of the components.

Throughout the specification, unless the context requires otherwise, the word "plurality" means "at least two", and the word "comprising" is to be construed as open, inclusive meaning, i.e. as "comprising, but not limited to. In the description of the present specification, the terms "one embodiment," "some embodiments," "example embodiments," "examples," "particular examples," or "some examples," etc., are intended to indicate that a particular feature, structure, material, or characteristic associated with the embodiment or example is included in at least one embodiment or example of the present specification. The schematic representations of the above terms do not necessarily refer to the same embodiment or example.

The technical solutions of the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

SUMMARY

Cloud platforms are an infrastructure service capable of providing on-demand allocation of computing resources (e.g., servers, storage, databases, networks, etc.). The method abstracts physical resources and performs dynamic scheduling through a virtualization technology, so that a tenant can acquire required IT (Information Technology ) resources at any time according to requirements and pay according to the use amount.

When a tenant uses a software service provided by a cloud platform, a Virtual Machine (VM) can be created in the cloud platform, and the software service and corresponding resources provided by the cloud platform are used by the Virtual Machine. The method can realize the resource isolation among the tenants, prevent malicious attacks or data leakage among different tenants, is beneficial to guaranteeing the resource safety of the tenants, and simultaneously is beneficial to meeting the flexible expansion and customization demands of the tenants on IT resources by providing software services for the tenants in a mode of creating virtual machines for the tenants. Referring to fig. 1, fig. 1 illustrates a schematic diagram of a relationship between a tenant and a cloud platform, where when a plurality of tenants (e.g., tenants A, B and C in fig. 1) first use the cloud platform, respective corresponding virtual machines 1-3 may be established based on a virtualization technology, and the virtual machines may be managed by a virtual machine monitor (Hypervisor) of the cloud platform, for example, a virtual machine memory control of the virtual machine in a physical memory (e.g., a memory in fig. 1) is managed by the virtual machine monitor. After the tenants establish the corresponding virtual machines, the software services and the corresponding resources provided by the cloud platform can be used based on the corresponding virtual machines. It should be understood that, although 3 tenants and 3 virtual machines corresponding to the 3 tenants are shown in fig. 1, fig. 1 is only for illustrative purposes, and in practical applications, the number of virtual machines and the number of tenants may be more or less, and this description is not exhaustive herein.

As described in the background art, since the cloud platform provides services to tenants by sharing hardware resources and in the form of virtual machines, the virtual machines share the hardware resources, the security of the cloud platform cannot be ignored. In order to improve the security of the cloud platform, an encryption virtualization technology different from a traditional virtualization technology may be used, the encryption virtualization technology may perform encryption protection on the virtual machine, and the virtual machine subjected to the encryption protection may be called a secure virtual machine (Secure Virtual Machine, SVM). The secure virtual machine provides a hardware-level isolation environment. This provides an infrastructure for confidential computations, ensuring that sensitive data is protected during the computation.

In cryptographic virtualization techniques, a variety of keys may be used, which may include HRK (Hardware Root Key, chip vendor root key), HSK (HARDWARE SERIES KEY, chip product key), HEK (Hardware Endorsement Key, chip unique key), CPK (Cloud Provider Key, cloud vendor private key), PUK (Platform Unique Key, cloud platform unique key) and SEK (Session Unique Key, Channel unique key), where HRK is a root key pre-burned in the chip by the hardware manufacturer (i.e., chip vendor), which may be used to verify the identity of the chip or to generate other keys. HSK is a key generated by a hardware manufacturer for a certain family or model of chips, which key may be used to verify the family or model of chips, or to generate other keys. HEK is a unique key for each chip that can be used to verify the unique identity of the chip or to generate other keys. CPK is a private key generated by a cloud service provider (or provider of a cloud platform) that can be used to verify the identity of the cloud service provider or to generate other keys. The PUK is a unique key generated by a cloud service provider for each cloud platform (e.g., a data center or a server group), and this key can be used to verify the unique identity of the cloud platform or to generate other keys, and the presence of the PUK can enable a trust chain to extend from a system on a chip to the whole cloud platform, so as to ensure the uniqueness and reliability of the cloud platform. SEK is a unique key generated for each virtual machine or each communication session that can be used to protect communications between the virtual machine and the host machine from eavesdropping or modification by other virtual machines or by an attacker. The key may be used or generated during the start-up of the cloud platform. in addition to the keys described above, in some embodiments, to ensure isolation and independence of the Secure Virtual machines, keys that may be used include a Secure Virtual machine Encryption Key (Secure Virtual Machine Encryption Key), a Secure Virtual machine disk Encryption Key (Secure Virtual MACHINE DISK Encryption Key), a Secure Virtual machine transfer Key (Secure Virtual Machine Transport Kye), and a Secure Virtual machine shared Key (Secure Virtual MACHINE SHARED KEY), among others, In the encryption virtualization technology, different virtual machines can correspond to different virtual machine encryption keys, the virtual machine encryption keys corresponding to the virtual machines can be generated, distributed and managed by a security coprocessor (Secure Coprocessor, SCP), the virtual machine encryption keys can be stored in a private memory of the security coprocessor, and the virtual machine encryption keys are called by a password engine when in use. The secure virtual machine disk encryption key is used for encrypting and decrypting disk contents of the virtual machine, including virtual hard disk files and mirror image files of the virtual machine. Encrypting the disk contents of the virtual machine may prevent unauthorized access and modification, providing security for the data while static. The secure virtual machine transmission key may be used to encrypt the private data and state of the secure virtual machine during the secure virtual machine migration process, meaning that the private data and state of the secure virtual machine cannot be read or modified even if an attacker is able to monitor the secure virtual machine migration process. The secure virtual machine shared key may be used to share data between different secure virtual machines, and in some embodiments, a secure virtual machine capable of data sharing between different secure virtual machines based on the secure virtual machine shared key is referred to as a Multi-key secure virtual machine (Multi-Key Secure Virtual Machine), while a secure virtual machine incapable of data sharing between different secure virtual machines is referred to as a single-key secure virtual machine. The secure firmware may utilize at least some of the keys described above to enable control and management of the secure virtual machine.

In order to improve security of the cloud platform, referring to fig. 1 in this specification, an application processor (Application Processor, AP) and a security coprocessor are provided in a system on a chip of the cloud platform, and control authority of a virtual machine monitor running in the application processor to a security virtual machine is transferred to security firmware on the security coprocessor, so that the security firmware can be responsible for at least one of life cycle security of the cloud platform, life cycle of the security virtual machine, key scheduling and management, and the like.

The application processor may refer to a processor running a cloud platform Operating System (OS), a software application service provided by the cloud platform, and the like. The security co-processor may refer to a specially configured processor responsible for data security, and the security firmware running on the security co-processor may refer to firmware specially used for data security. In some implementations, the virtual machine monitor may configure an API (Application Programming Interface, application program interface) for communication with the security co-processor to enable interaction of the virtual machine monitor with the security co-processor. In addition to the application processor and the security coprocessor, in some embodiments, a cryptographic engine dedicated to Key management and a Key storage unit (Key Slot) for Key loading and invoking may be provided in the system on chip, in order to improve the independence of the cryptographic engine and the Key storage unit, and ensure the security of the Key, in some embodiments, the cryptographic engine may be hardware independent of the security coprocessor and the application processor, and the Key storage unit may be a hardware storage unit in the cryptographic engine. In order to ensure the safety of the key loaded in the key storage unit, the key storage unit can be set to be in a write-only unreadable state, so that the situation that an attacker reads the key loaded in the key storage unit can be avoided, the safety of the key loaded in the key storage unit can be ensured, and the safety of the key in the use process can be ensured. When the attribute of the key storage unit is in a write-only unreadable state, and the security firmware needs to call the key loaded in the key storage unit, an encryption request or a decryption request can be initiated to the cryptographic engine through a specific interface, and the cryptographic engine finishes the encryption and decryption process based on the loaded key. For example, in some embodiments, the key storage unit may be a register or other hardware with access functionality. In some embodiments, the Key storage unit may include a plurality of slots (Key slots), each Slot may be used to load one Key, so that the Key storage unit may load a plurality of keys, which meets the management and call requirements of the secure firmware for the keys of the plurality of secure virtual machines. In addition, in some embodiments, the secure firmware may hit the key loaded in the key storage unit by setting the flag bit information, so that the key in the key storage unit will not generate plaintext key related information (such as a key name, a key identifier, etc.) during the invoking process, which is beneficial to improving the security in the key use process. The flag bit information may include one or more data bits, for example, in one embodiment, the flag bit information may include two data bits that hit a key loaded in a key storage unit by a combination of values of the two data bits. For example, in order to improve security in a key use process, when a key storage unit is configured, in a cloud platform configuration process, an enabling state of a flag bit such as a secret calculation bit and a sharing bit (the enabling state can be represented by a value of the flag bit) can be set, so that security firmware on a security coprocessor can manage a key generation and a key loaded in the key storage unit according to the enabling state of the flag bit, and subsequent security firmware can encrypt and decrypt virtual machine data and cloud platform data based on the key loaded in the key storage unit. In the whole key generation and use process, virtual machine monitor participation is not needed, and the security of the key is guaranteed. According to different cryptographic algorithms adopted by the cryptographic engines, the cryptographic engines can be divided into an SM2 engine, an SM3 engine, an SM4 engine and the like, wherein the SM2 engine adopts an SM2 algorithm to encrypt and decrypt data, the SM3 engine adopts an SM3 algorithm to encrypt and decrypt data, and the SM4 engine adopts an SM4 algorithm to encrypt and decrypt data. The SM2 algorithm includes 3 sub-algorithms: elliptic curve digital signature algorithm (SM 2-1), elliptic curve key exchange protocol (SM 2-2) and elliptic curve public key encryption algorithm (SM 2-3). The SM4 algorithm may be based on ISO/IEC 18033-3:2010/AMD1:2021 "information technology Security technology encryption Algorithm part 3: block cipher addendum 1: the SM4 standard algorithm is a grouping algorithm, the grouping length is 128 bits, the key length is 128 bits, and the encryption algorithm and the key expansion algorithm both adopt a 32-round nonlinear iteration structure. The SM3 algorithm may be an algorithm based on the GM/T0004-2012 SM3 password hash algorithm standard, which compresses text of indefinite length into a digest value of 32 bytes.

In addition, the security coprocessor can ensure the security of the security firmware and the like in a mode independent of the application processor, and can also ensure the security of the security firmware and the password engine based on a trusted computing technology. For example, in some embodiments, the security co-processor may construct a TEE (Trusted Execution Environment ) subsystem that provides a secure area for the security firmware and the cryptographic engine to process sensitive data, further securing the security of the security firmware and the cryptographic engine. In contrast, an environment in which an application processor runs may be referred to as a REE (Rich Execution Environment ) subsystem, in which both the operating system and virtual machine of the cloud platform may run.

In addition to the above structure, the cloud platform may further include external devices such as a storage device, an input/output device, a network device, an expansion slot, and an expansion card, which is not exhaustive in this specification, and is specific to the actual situation.

As described above, the virtual machine encryption key, the virtual machine channel unique key, and the virtual machine disk encryption key are several keys that are very important throughout the life of the secure virtual machine.

The virtual machine encryption key can be used for encrypting the memory content of the virtual machine. For example, in some embodiments, each secure virtual machine may have a unique virtual machine encryption key that is used to dynamically encrypt and decrypt the secure virtual machine's memory content. This key may be managed by the security firmware run by the security co-processor and inaccessible to the virtual machine monitor, which may prevent the virtual machine monitor or other virtual machine from accessing or modifying the memory contents of the virtual machine.

The virtual machine channel unique key may be used to secure communications between the virtual machine and the host machine. For example, when a virtual machine needs to communicate with a host's virtual machine monitor (e.g., hypervisor), this communication channel may be encrypted to prevent interception or modification by other virtual machines or by an attacker. This key is typically unique to each virtual machine to ensure isolation between the individual virtual machines.

The virtual machine disk encryption key may be used to encrypt and decrypt disk content of the virtual machine, including virtual hard disk files and image files of the virtual machine. Encrypting the disk contents of the virtual machine may prevent unauthorized access and modification, providing security for the data while static.

In the specification, in order to ensure the security of the key, the generation and the calling authority of the encryption key of the virtual machine are transmitted to the security firmware, so that the security risks such as key leakage or interception and the like possibly caused by the management of the encryption key of the virtual machine through the virtual machine monitor are avoided. In addition, when the secure virtual machine is activated, the virtual machine encryption key is loaded in the key storage unit and is called by the secure firmware, so that the security boundary of the first processor cannot be generated in the calling process of the virtual machine encryption key, the virtual machine monitor is prevented from accessing the key loaded in the key storage unit, and the security of the virtual machine encryption key in the calling process is improved. In addition, the safety firmware can hit the key loaded in the key storage unit through the flag bit information, and the key is not required to be called through a plaintext related to the identity information of the key to be called, so that the safety and the independence of the key loaded in the key storage unit are guaranteed.

Based on the above-described concept, the key management method provided in the embodiment of the present specification is exemplarily described below.

Exemplary method

Taking a first processor applied to the system on chip shown in fig. 1 as an example, the embodiment of the present disclosure provides a key management method, which is applied to the first processor in the system on chip, where the system on chip further includes a cryptographic engine, the cryptographic engine includes a key storage unit, the first processor is used to run secure firmware, and the system on chip further includes a second processor, where the second processor is used to run a secure virtual machine, as shown in fig. 2, and the key management method includes:

S201: responding to the starting operation of the secure virtual machine, generating a virtual machine encryption key corresponding to the secure virtual machine by the secure firmware, wherein the virtual machine encryption key is used for encrypting data of the secure virtual machine;

S202: and responding to the activation request of the secure virtual machine, loading the virtual machine encryption key in the key storage unit by the secure firmware, wherein the virtual machine encryption key loaded in the key storage unit is used for being called by the secure firmware.

The first processor may comprise a security co-processor as shown in fig. 1 and the second processor may comprise an application processor as shown in fig. 1. The number of the first processor and the second processor may be one or more, which is not limited in this specification, and the present invention is particularly limited according to the actual situation. The first processor may be configured to operate the secure firmware, which may mean that the first processor has an operation authority or a function of the secure firmware, and is not limited to the first processor being only used for operating the secure firmware, and in some embodiments, the first processor may be configured to operate or control other software and hardware, which is not limited in this specification. Similarly, the second processor may be configured to run the secure virtual machine, which may mean that the second processor has the running authority or function of the secure virtual machine, rather than limiting the second processor to only run the secure virtual machine, and in some embodiments, the second processor may be configured to run or control other software and hardware, such as, but not limited to, the second processor may also be configured to run system firmware and user applications (Client Application, CA), and the like. The cryptographic engine may be located in a memory controller within the system-on-chip.

As previously mentioned, secure firmware may refer to firmware running on a security co-processor and used to be responsible for data security. The secure firmware is different from the system firmware running on the second processor, for example, the ARM architecture processor, and the system firmware may include trusted firmware (Arm Trusted Firmware, ATF) and an Operating System (OS) of the cloud platform, where the trusted firmware divides privilege levels during the startup and running of the computing device. These privilege levels, in combination with the secure hardware architecture, together ensure the security of the boot process of the computing device. Specifically, trusted firmware technology divides EL0 (Exception Level 0) into four privilege levels, EL 3. From EL0 to EL3, the privilege level increases sequentially. Passing the ERET command from high LE to low EL and from low EL to high EL through exception, the different privilege levels can be strictly distinguished. Wherein EL0, EL1 and EL2 can be divided into NS-ELx (None Secure ELx, x=0, 1,2, i.e. the general world ELx) and S-ELx (Secure ELx, x=0, 1,2, i.e. the secure world ELx), whereas EL3 is only one of the secure worlds EL 3. In some cases, the firmware required to run the boot process of the computing device may include BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

The BL1 firmware may be called Trusted Boot ROM (Trusted Boot ROM), which is the firmware that runs earliest in the Boot process, and is also the firmware stored in the processor ROM (Read-Only Memory), and the BL1 firmware is not together with the BIOS of the computing device, and in some types of Trusted firmware technologies, the BL1 firmware is a root of trust. BL1 firmware can be used to initialize core hardware (e.g., trusted SRAM, serial port, etc.) of a computing device and find BL2 firmware, which in some cases can be signed by BL1 firmware. BL1 firmware runs on the EL3 privilege level.

BL2 firmware may be referred to as Trusted Boot Firmware (trusted boot firmware), BL2 firmware also operates on the EL3 privilege level, with the notable difference that BL2 firmware and BL1 firmware may be stored on an external trusted storage device, and its trust base may be established on the verification of it by BL1 firmware. The BL2 firmware initializes some critical security hardware and software frameworks, and after initialization is completed, the BL2 firmware finds BL31.

BL31 Firmware may be referred to as EL3 run Firmware, BL31 Firmware also runs on the EL3 privilege level, BL31 Firmware is not run once like BL1 Firmware and BL2 Firmware, it continuously provides security related services to the general world (Non-Security) through SMC (Secure Monitor Call, security monitoring call).

BL32 firmware may include OPTEE OS (Open Portable Tee Operate System, open portable Tee operating system) and trusted applications, OPTEE OS may refer to the operating system of trusted execution environment Tee. BL32 firmware runs on S-EL1, and trusted applications on BL32 firmware run on S-EL0. In some cases, OPTEE OS is run, and then the BL31 firmware of EL3 is returned, BL33 firmware is found by BL31 firmware, and BL33 firmware can be checked by BL31 firmware.

BL33 Firmware may include Firmware (Non-Trusted Firmware) running in the general world, BL33 Firmware may include UEFI (Unified Extensible FIRMWARE INTERFACE, extensible Firmware interface) Firmware or U-boot (boot loader for embedded domain) Firmware, linux Kernel, basic input output system (basic input output system, BIOS) Firmware for desktop, server, etc. In the general world, the execution authority of EL0, EL1, EL2, EL3 increases in order. Wherein the UEFI firmware is configured to run at the EL2 level of the general world and the OP-TEE is configured to run at the EL1 level of the secure world. The OP-TEE has completed startup upon entering the UEFI (BL 33) startup, and communication between the UEFI and the OP-TEE may be through a security monitoring call (secure monitor call, SMC) interface. Therefore, when the UEFI is started, when the integrity and the security of the image file are verified, certain functions can be realized by calling the OP-TEE corresponding interface of the security world in a mode of triggering the SMC by the common world, so that the verification process related to the image file can be transferred to the security world for verification, and a verification result is returned to the common world.

Of course, the foregoing describes, by way of example only, the types of firmware that may be included with the trusted firmware, which may include a greater or lesser number of firmware in some embodiments, e.g., in some embodiments, the trusted firmware may also include firmware such as a stand-alone management module (Standalone MM, STMM). The STMM may provide related security applications including secure variable handling, secure firmware upgrades, secure and non-secure world interactions, and the like. The STMM can help a system administrator to process application requests of the non-secure world to the secure world, and improves the security of the system. Also, for example, in some embodiments, the trusted firmware may not include BL32 firmware, and the specification does not limit the specific type and amount of firmware that may be included in the trusted firmware, which may be the case.

Regarding virtual machine encryption keys, the entire lifecycle may refer to fig. 3, and a tenant may configure the secure virtual machine before the secure virtual machine is started, e.g., configure resources of the secure virtual machine, whether data is shareable, etc. The starting operation of the secure virtual machine may refer to an operation of starting the secure virtual machine in the cloud platform by the cloud platform tenant, and the secure firmware may respond to the starting operation of the secure virtual machine to generate a virtual machine encryption key corresponding to the secure virtual machine. In some embodiments, a virtual machine monitor running on the second processor assigns an unused Virtual Machine Identity (VMID) from the pool of identities to the secure virtual machine that needs to be booted, and uses the virtual machine identity as the identity of the secure virtual machine. The identity pool can be used for storing the virtual machine identity and the use state of the virtual machine identity. For example, in some embodiments, the identity pool may include an unused identity pool and a used identity pool, where an unused virtual machine identity is stored in the unused identity pool, and an unused virtual machine identity is stored in the used identity pool, where the identity of the used virtual machine is not limited in the specific use state, and the specific manner of identifying the specific use state is specific to the actual situation.

When the secure firmware receives an activation request that the secure virtual machine requests to enter an activated state, the activation request may carry a virtual machine identity corresponding to the secure virtual machine, and the activation request may be sent to the secure firmware by the virtual machine monitor. The secure firmware loads a key to be loaded in a key storage unit of the cryptographic engine, wherein the key to be loaded can be a virtual machine encryption key corresponding to a secure virtual machine which needs to enter an activated state, and then the secure firmware can encrypt and decrypt private memory data of the secure virtual machine based on the virtual machine encryption key stored in the key storage unit. In some embodiments, the number of keys that can be loaded in the key storage unit may be multiple, i.e. the slots in the key storage unit may be multiple, so as to meet the loading requirements of different types of keys or multiple keys of the same type. In addition, to further secure the key loaded in the key storage unit, in some embodiments, the method for calling the key loaded in the key storage unit by the secure firmware includes:

And the security firmware sets flag bit information corresponding to the type of the target key according to the type of the target key, and determines the target key from the key storage unit by utilizing the flag bit information, wherein the target key is a key which needs to be called by the security firmware.

The security firmware can hit the key loaded in the key storage unit by setting the flag bit information, so that the key in the key storage unit cannot generate plaintext key related information (such as key name, key identification and the like) in the calling process, and the security in the key use process is improved.

In some embodiments, to ensure the security of the image of the secure virtual machine, the key management method further includes:

and encrypting the mirror image of the secure virtual machine by using the virtual machine encryption key in the starting process of the secure virtual machine.

Virtual machine image (Virtual MACHINE IMAGE) is a file containing Virtual hard disk content that contains an operating system, pre-installed applications, and configuration information for these programs. This image may be used by the virtual machine monitor to boot a secure virtual machine. Encrypting the secure virtual machine image with the virtual machine encryption key may prevent unauthorized access and modification to the secure virtual machine image.

Some embodiments below describe the use of a virtual machine encryption key in a state switching and migration process, and in one embodiment, the key management method further includes:

In response to a state switching request for a target secure virtual machine and a current secure virtual machine, replacing a first virtual machine encryption key loaded in the key storage unit with a second virtual machine encryption key, the first virtual machine encryption key comprising: a virtual machine encryption key corresponding to the current secure virtual machine, the second virtual machine encryption key comprising: a virtual machine encryption key corresponding to the target secure virtual machine;

The state switching request is used for requesting to switch the state of the current secure virtual machine to an inactive state.

Referring to fig. 4, in this embodiment, when the current secure virtual machine needs to be switched from an active state to an inactive state due to some situations (for example, when the current secure virtual machine runs in error or encounters an issue that cannot be handled), the virtual machine monitor may send a state switching request carrying a virtual machine identity identifier of a next secure virtual machine (i.e., a target secure virtual machine) that needs to enter the active state and a virtual machine identity identifier of the secure virtual machine (i.e., the current secure virtual machine) that needs to be switched to the inactive state to the secure firmware, and the secure firmware responds to the request to replace the first virtual machine encryption key loaded in the key storage unit (for example, the key storage unit 1 in fig. 4) with the second virtual machine encryption key (i.e., to cover the first virtual machine encryption key with the second virtual machine encryption key), so as to avoid resource waste caused by the first virtual machine encryption key corresponding to the current secure virtual machine that is switched to the inactive state, and avoid the first virtual machine encryption key from being invoked by an error or illegally when the current secure virtual machine is in the inactive state. The number of key storage units may be plural, for example, key storage units 1, 2 … … N shown in fig. 4.

To meet the migration requirement of the secure virtual machine, in one embodiment, the key management method further includes:

in response to a migration request for a secure virtual machine to be migrated, decrypting private memory data of the secure virtual machine to be migrated by using a virtual machine encryption key corresponding to the secure virtual machine to be migrated, which is loaded in the key storage unit;

Sending the decrypted private memory data to a target first processor, wherein the target first processor and the first processor are positioned in different systems on chip;

the decrypted private memory data is used for requesting the secure firmware operated by the target first processor to encrypt the decrypted private memory data by using a new virtual machine encryption key, and the new virtual machine encryption key is generated by the secure firmware operated by the target first processor.

The method for decrypting the private memory data of the secure virtual machine to be migrated further comprises the steps of:

And if the virtual machine encryption key corresponding to the secure virtual machine to be migrated is not loaded in the key storage unit, loading the virtual machine encryption key corresponding to the secure virtual machine to be migrated in the key storage unit.

When a secure virtual machine needs to be migrated between different physical machines, after the secure firmware on a transmitting end (i.e. a host machine before migration of the secure virtual machine to be migrated) confirms the platform security (for example, the platform security can be verified by a cloud Platform Unique Key (PUK), a cloud platform security certificate and other modes) of a receiving end (i.e. a target host machine to be migrated of the secure virtual machine to be migrated), if a virtual machine encryption key corresponding to the secure virtual machine to be migrated is not loaded in a key storage unit, the virtual machine encryption key corresponding to the secure virtual machine to be migrated is loaded in the key storage unit, the private memory data of the secure virtual machine to be migrated is decrypted by using the virtual machine encryption key loaded in the key storage unit, the decrypted private memory data is transmitted to the receiving end, the secure firmware operated by the target first processor of the receiving end encrypts the decrypted memory data by using a new virtual machine encryption key, and the new virtual machine encryption key is generated by the secure firmware operated by the target first processor of the receiving end. After the migration of the virtual machine to be migrated is completed, the secure firmware of the receiving end deletes the virtual machine encryption key corresponding to the secure virtual machine to be migrated.

In the destroying stage of the safe virtual machine, the virtual machine monitor sends a destroying request for the safe virtual machine to be destroyed to the safe firmware on the first processor, and the safe firmware deletes the virtual machine encryption key corresponding to the safe virtual machine to be destroyed.

Besides the encryption key of the virtual machine, the communication security between the secure virtual machine and the secure firmware and the like can be ensured by using the unique channel key. Reference is made to fig. 5 for the entire lifecycle of the channel unique key.

In one embodiment, before the responding to the activation request of the secure virtual machine, the key management method further includes:

the secure firmware establishes a secure channel with the secure virtual machine based on the channel unique key loaded in the key storage unit;

the security firmware carries out security measurement on the security virtual machine and transmits measurement information to the security virtual machine through the security channel; the metric information is used for indicating the secure virtual machine to request the virtual machine monitor to send the activation request to the secure firmware when the metric information meets configuration requirements.

After the cloud platform completes the secure boot, the secure firmware may generate a channel unique key. In the configuration stage of the secure virtual machine, the secure firmware sends the secure certificate and the channel unique key of the cloud platform to the virtual machine tenant, and after the configuration file of the secure virtual machine is completed, the virtual machine tenant generates a user channel key and sends the user channel key to the secure firmware to realize key exchange, so that the secure channel construction is completed. In the measurement stage of the secure virtual machine, the secure firmware sends measurement information to the tenant of the secure virtual machine through a secure channel, and the transmitted measurement information (or measurement result) can be encrypted by adopting a channel unique key. And in the virtual machine activation stage, after confirming that the measurement information meets the configuration requirement, the tenant of the secure virtual machine informs the virtual machine monitor to activate the secure virtual machine.

To ensure freshness and security of the channel unique key, in some embodiments, the key management method further includes:

and in response to completion of the secure virtual machine startup, the secure firmware regenerates the channel unique key and replaces the channel unique key generated after completion of cloud platform startup with the newly generated channel unique key.

In this embodiment, after the secure boot of the cloud platform is completed, the secure firmware may generate the channel unique key. After the user completes configuration and measurement of the virtual machine, the user notifies the virtual machine monitor to start the safe virtual machine when confirming that the measurement information meets the configuration requirement, and after the safe virtual machine is started, the safe firmware regenerates a new channel unique key corresponding to the safe virtual machine, replaces the channel unique key generated after the cloud platform is started by the newly generated channel unique key, and guarantees the freshness and safety of the channel unique key.

In the migration stage of the secure virtual machine, the key management method further comprises:

Responding to a migration request for a secure virtual machine to be migrated, constructing a secure channel between a target first processor and a first processor based on a channel unique key loaded by the key storage unit, and transmitting data based on the constructed secure channel;

and after the secure virtual machine to be migrated is migrated, deleting the channel unique key by the target first processor and the first processor.

Before the virtual machine is migrated, a secure channel is constructed between a sending end and a receiving end through a channel unique key construction, and a transmission content is encrypted by utilizing a virtual machine transmission key (or a migration key, which can be generated by secure firmware after the cloud platform is started), so that the safety of communication between the secure virtual machine and the secure firmware and the like can be ensured, and the management and calling authority of the channel unique key are transmitted to the secure firmware, thereby reducing the risk that a virtual machine monitor or an attacker intercepts the channel unique key.

In addition to the channel unique key and the virtual machine encryption key, the disk encryption key of the virtual machine may be used to ensure the security of the disk content of the secure virtual machine, and referring to fig. 6, in one embodiment, the key management method further includes:

the secure firmware receives a virtual machine disk encryption key corresponding to the secure virtual machine;

the security firmware encrypts private data on a disk of the security virtual machine by using the disk encryption key of the virtual machine;

After the secure virtual machine migration is completed, the secure firmware sends the virtual machine disk encryption key to a target first processor, and the stored virtual machine disk encryption key is deleted.

In the virtual machine measurement stage, after the tenant of the secure virtual machine confirms that the secure virtual machine starts up according to the requirement (measurement result confirmation), the tenant of the secure virtual machine generates a virtual machine disk encryption key and transmits the virtual machine disk encryption key to the secure firmware on the first processor through a secure channel. The secure firmware encrypts private data on the secure virtual machine disk with the disk encryption key. In the virtual machine migration stage, the secure firmware on the first processor at the transmitting end transmits the disk encryption key to the secure firmware on the first processor at the receiving end after the virtual machine migration is completed, and the secure firmware on the first processor at the transmitting end deletes the disk encryption key at the same time. In the virtual machine destruction stage, the security firmware on the first processor deletes the virtual machine disk encryption key of the current security virtual machine.

In order to timely delete the key of the destroyed or migrated secure virtual machine, in one embodiment, the attribute of the key storage unit is configured to be write-only unreadable; the key management method further includes:

and replacing the key to be replaced loaded in the key storage unit with a default key in response to the destruction request of the secure virtual machine or the completion of the migration of the secure virtual machine, and deleting the key to be replaced, wherein the key to be replaced comprises a key corresponding to the secure virtual machine, and the default key is used for data sharing between the secure virtual machine and a virtual machine monitor.

Since the attribute of the key storage unit is configured to be write-only and unreadable, the purpose of replacing the key corresponding to the secure virtual machine in the key storage unit by the default key is to: unloading a secret key corresponding to the secure virtual machine from a secret key storage unit in an overlaying mode; after uninstallation, the keys corresponding to the secure virtual machine are deleted because the secure virtual machine needs to be destroyed or has been migrated, and the keys do not need to be stored. In this embodiment, when the secure virtual machine is destroyed or migrated, the storage unit such as a register may be used as the key storage unit, and when the secure virtual machine is destroyed or migrated, the key corresponding to the secure virtual machine loaded in the key storage unit is replaced by the default key in time, and the key corresponding to the secure virtual machine (for example, the virtual machine encryption key, the channel unique key, the virtual machine disk encryption key, etc.) is deleted, so as to release the corresponding storage space, and avoid misuse of the destroyed or migrated key of the secure virtual machine.

Exemplary related devices

In an exemplary embodiment of the present specification, there is also provided a key management apparatus applied to a first processor in a system on a chip, the system on a chip further including a cryptographic engine including a key storage unit, the first processor for running secure firmware, the system on a chip further including a second processor for running a secure virtual machine, as shown in fig. 7, the key management apparatus including:

the starting module 601 is configured to respond to a starting operation of the secure virtual machine, where the secure firmware generates a virtual machine encryption key corresponding to the secure virtual machine, and the virtual machine encryption key is used to encrypt data of the secure virtual machine;

and the activation module 602 is configured to respond to an activation request of the secure virtual machine, where the secure firmware loads the virtual machine encryption key in the key storage unit, and the virtual machine encryption key loaded in the key storage unit is used for the secure firmware to call.

For specific limitations on the key management device, reference may be made to the above limitations on the key management method, and no further description is given here. The respective modules in the above-described key management apparatus may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In an exemplary embodiment of the present specification, there is also provided a system on a chip, as shown in fig. 8, including: a first processor, a second processor, and a cryptographic engine; wherein,

Another embodiment of the present specification further provides a computing device, referring to fig. 9, and an exemplary embodiment of the present specification further provides a computing device including: a memory storing a computer program, and a processor that when executed performs the steps in the key management method according to various embodiments of the present specification described in the above embodiments of the present specification.

The internal architecture of the computing device may be as shown in fig. 9, including a processor, memory, network interfaces, and input devices connected by a system bus. Wherein the processor of the computing device is configured to provide computing and control capabilities. The memory of the computing device includes a non-volatile storage medium, an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computing device is for communicating with an external terminal through a network connection. The computer program, when executed by a processor, performs the steps in the key management method according to various embodiments of the present specification described in the above embodiments of the present specification.

The processor may include a host processor, and may also include a baseband chip, modem, and the like.

The memory stores programs for executing the technical scheme of the invention, and can also store an operating system and other key services. In particular, the program may comprise program code comprising computer operation commands. More specifically, the memory may include read-only memory (ROM), other types of static storage devices that may store static information and commands, random access memory (random access memory, RAM), other types of dynamic storage devices that may store information and commands, disk storage, flash, and the like.

The processor may be a general-purpose processor, such as a general-purpose Central Processing Unit (CPU), microprocessor, or the like, or may be an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs in accordance with aspects of the present invention. But may also be a Digital Signal Processor (DSP), application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components.

The input device may include means for receiving data and information entered by a user, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer or gravity sensor, etc.

The output device may include means, such as a display screen, printer, speakers, etc., that allow information to be output to the user.

The communication interface may include means, such as any transceiver, for communicating with other devices or communication networks, such as ethernet, radio Access Network (RAN), wireless Local Area Network (WLAN), etc.

The processor executes the program stored in the memory and invokes other devices, which may be used to implement the steps of any of the key management methods provided in the above embodiments of the present disclosure.

The computing device can also comprise a display component and a voice component, wherein the display component can be a liquid crystal display screen or an electronic ink display screen, and an input device of the computing device can be a touch layer covered on the display component, can also be a key, a track ball or a touch pad arranged on a shell of the computing device, and can also be an external keyboard, a touch pad or a mouse and the like.

Those skilled in the art will appreciate that the architecture shown in fig. 9 is merely a block diagram of some of the architecture associated with the present description and is not limiting of the computing devices to which the present description may be applied, and that a particular computing device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

Exemplary computer program product and storage Medium

In addition to the methods and apparatus described above, the key management methods provided by the embodiments of the present description may also be a computer program product comprising computer program instructions which, when executed by a processor, cause the processor to perform the steps in the key management methods according to the various embodiments of the present description described in the "exemplary methods" section of the present description.

The computer program product may write program code for performing the operations of embodiments of the present description in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server.

Furthermore, the present specification embodiment also provides a computer-readable storage medium having stored thereon a computer program that is executed by a processor to perform the steps in the key management method according to the various embodiments of the present specification described in the above-described "exemplary method" section of the present specification.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (SYNCHLINK) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples merely represent a few implementations of the present description, which are described in more detail and are not to be construed as limiting the scope of the solutions provided by the examples of the present description. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the present description, which is within the scope of the present description. Accordingly, the protection scope of the patent should be determined by the appended claims.

Claims

1. A key management method, applied to a first processor in a system-on-chip, the system-on-chip further comprising a cryptographic engine, the cryptographic engine comprising a key storage unit, the first processor being configured to run secure firmware, the system-on-chip further comprising a second processor configured to run a secure virtual machine, the key management method comprising:

2. The method as recited in claim 1, further comprising:

3. The method as recited in claim 1, further comprising:

4. The method according to claim 3, wherein the decrypting the private memory data of the secure virtual machine to be migrated using the virtual machine encryption key corresponding to the secure virtual machine to be migrated loaded in the key storage unit further comprises:

5. The method of claim 1, wherein the second processor is further configured to run a virtual machine monitor;

before the response to the activation request of the secure virtual machine, the key management method further includes:

6. The method as recited in claim 5, further comprising:

7. The method as recited in claim 5, further comprising:

8. The method as recited in claim 1, further comprising:

9. The method according to any one of claims 1 to 8, wherein the method for the secure firmware to invoke the key loaded in the key storage unit comprises:

10. The method according to any of claims 1-8, wherein the properties of the key storage unit are configured to be write-only unreadable; the key management method further includes:

11. The method of any one of claims 1-8, wherein the second processor is further configured to run a virtual machine monitor;

The activation request carries a virtual machine identity identifier corresponding to the secure virtual machine, a virtual machine encryption key of the secure virtual machine corresponds to the virtual machine identity identifier, and the virtual machine identity identifier is an unused virtual machine identity identifier determined from an identity identifier pool in the starting process of the secure virtual machine by the virtual machine monitor; the identity identification pool is used for storing the virtual machine identity identification and the use state of the virtual machine identity identification.

12. The method according to any one of claims 1 to 8, further comprising:

13. A system on a chip, comprising: a first processor, a second processor, and a cryptographic engine; wherein,

14. A computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the key management method of any one of claims 1 to 12 when the computer program is executed.

15. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the key management method of any of claims 1 to 12.