CN109814934B

CN109814934B - Data processing method, device, readable medium and system

Info

Publication number: CN109814934B
Application number: CN201910100370.5A
Authority: CN
Inventors: 胡远峰; 吕达夫
Original assignee: ARM Technology China Co Ltd
Current assignee: ARM Technology China Co Ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2022-05-06
Anticipated expiration: 2039-01-31
Also published as: CN109814934A

Abstract

The application provides a data processing method, a device, a storage medium and a system, wherein the method comprises the following steps: reading the secure manifest and a public key associated with the secure manifest from the untrusted storage area to the trusted storage area in response to execution of the secure boot process; reading a security list and a public key from the trust storage area, and verifying whether the security list is complete or not by using the public key; if the safety list is verified to be complete, judging whether an updating instruction is included in the safety list, wherein the updating instruction is used for updating a boot code of the safety boot process; if the secure manifest includes an update instruction, the secure boot process is interrupted and the update instruction is executed to update the boot code of the secure boot process. The updating instruction can be conveniently deployed on the equipment through the network, and burning or modification of hardware devices in a factory is not needed, so that the hardware investment cost is reduced.

Description

Data processing method, device, readable medium and system

Technical Field

One or more embodiments of the present application relate generally to semiconductor devices, and more particularly, to a method, apparatus, readable medium, and system for data processing.

Background

Today, security is a necessary consideration for system-on-a-chip (SoC) design, and the basic approach to providing hardware-based platform security includes secure boot services. The system on chip typically starts with internal BOOT ROM code which in turn loads and executes a BOOT loader or system from external memory or storage. However, there is no guarantee that there are no errors in the BOOT ROM code. In the prior art, the BOOT ROM code is patched by burning patch code in the OTP ROM, but there are many limitations to this patching method.

Disclosure of Invention

To solve the above problems. One or more embodiments of the present application provide a data processing method, apparatus, storage medium, and device.

According to some aspects of the present application, a data processing method is disclosed, comprising:

reading the secure manifest and a public key associated with the secure manifest from the untrusted storage area to the trusted storage area in response to execution of the secure boot process;

reading the security list and the public key from the trust storage area, and verifying whether the security list is complete (integrity) by using the public key;

if the safety list is verified to be complete, judging whether an updating instruction is included in the safety list, wherein the updating instruction is used for updating the boot code of the safety boot process;

interrupting the secure boot process if the secure manifest includes the update instruction, and executing the update instruction to update the boot code of the secure boot process.

Further, receiving the security manifest from a server over a network.

Further, the verifying whether the security manifest is complete by using the public key further includes:

verifying whether the public key is matched with the set public key hash;

if the public key hash matches the public key, verifying whether the public key matches a signature of the secure manifest; and

and if the public key is matched with the signature of the safety list, judging that the safety list is complete.

Further, the verifying whether the public key matches the signature of the secure manifest comprises:

and matching the digest of the public key with the signature digest of the safety list.

Further, if the secure manifest is verified to be incomplete, an error message is returned and the secure boot process is ended.

Further, if it is determined that the security manifest does not include the update instruction, continuing to perform the secure boot process.

Further, the secure manifest includes metadata of the secure boot process, the metadata including related information describing software packages and signatures loaded in the secure boot process.

Further, the public key hash is stored in a one-time programmable memory, wherein the one-time programmable memory is distinct from the untrusted store or the trusted store.

Further, the untrusted storage area and the trusted storage area are non-volatile storage media.

Further, the untrusted storage area is a nonvolatile storage medium, and the trusted storage area is a volatile storage medium.

Further, the untrusted memory area and the trusted memory area are on the same storage medium.

Further, the update instruction includes the boot code for replacing a part of the secure boot process, or the boot code for replacing the entire process of the secure boot process.

According to some aspects of the present application, a data processing apparatus is disclosed, comprising:

the reading unit is used for responding to the execution of the safety boot process and reading the safety list and the public key related to the safety list from the non-trusted storage area to the trusted storage area;

the verification unit is used for reading the safety list and the public key from the trust storage area; and, verifying whether the security manifest is complete (integrity) by using the public key;

the updating unit is used for judging whether an updating instruction is included in the safety list or not if the safety list is verified to be complete, wherein the updating instruction is used for updating the boot code of the safety boot process; interrupting the secure boot process and executing the update instruction to update the boot code of the secure boot process if it is determined that the secure manifest includes the update instruction.

According to some aspects of the present application, a machine-readable medium is disclosed, having stored thereon instructions, which when executed on a machine, cause the machine to perform the above-described data processing method.

According to some aspects of the present application, a system is disclosed, comprising:

a memory for storing instructions for execution by one or more processors of the system, an

And the processor is one of the processors of the system and is used for executing the data processing method.

The present application, in accordance with aspects of the present application, has effects including, but not limited to:

the pushing of The update instruction may be accomplished using FOTA (Firmware Over-The-Air) technology. Therefore, the updating instruction can be conveniently deployed on the equipment through the network, and the burning or modification of hardware devices in a factory is not needed, so that the hardware investment cost is reduced. Furthermore, since the update instructions are pushed to the accessible untrusted memory area, rather than to the rom or OTP hardware, the secure list can be updated an unlimited number of times as needed by the FOTA.

Further, the updating instruction can update the verification algorithm verified by the original software package.

Further, the update instruction can update/replace the boot code of the entire secure boot process.

Drawings

Fig. 1 shows a block schematic diagram of a data processing apparatus and a server according to an embodiment of the present application.

Fig. 2 is a schematic flow chart illustrating a process of generating a security manifest by a server according to an embodiment of the present application.

Fig. 3 shows a flow diagram of a data processing method according to an embodiment of the application.

Fig. 4 shows a schematic flow diagram of a data processing method according to another embodiment of the present application.

Fig. 5 shows a schematic flow diagram of a data processing method according to another embodiment of the present application.

FIG. 6 shows a block schematic of a system according to an embodiment of the invention.

Detailed Description

In order to make the purpose and technical solutions of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings of the embodiments of the present application. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the described embodiments of the application without any inventive step, are within the scope of protection of the application.

Fig. 1 is a schematic diagram of device modules of a data processing device and a server according to an embodiment of the present application. Such appliances include, but are not limited to, laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network appliances, network hubs, switches, embedded processors, Digital Signal Processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular telephones, portable media players, handheld devices, and other appliances for a variety of other electronic devices. In general, a number of devices and electronic devices capable of containing the processors and/or other execution logic disclosed herein are generally suitable.

As shown in fig. 1, system 10 may include one or more (only one shown) processors 110 (processor 110 may include, but is not limited to, a processing device such as a central processing unit CPU, an image processor GPU, a digital signal processor DSP, a microprocessor MCU, or a programmable logic device FPGA), a BOOT ROM 120, an OTP ROM 130, a memory 140, and a network interface 150. The system 10 further comprises a data processing device 121, wherein the device 121 comprises a reading unit 1211, a verification unit 1212 and an update unit 1213. The server 20 includes a generating unit 210 and a transceiving unit 220. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration and is not intended to limit the structure of the electronic device. For example, system 10 and server 20 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The server 20 is typically set up by the Original Equipment Manufacturer (OEM) of the device. Fig. 2 shows a flow diagram of a server generating a security manifest. As shown in FIG. 2, at block 201, a security manifest, including a software package and signed metadata related to a secure boot process of a data processing apparatus, and a public key associated with the security manifest are generated and cryptographically signed. At block 202, the security manifest is sent to the data processing apparatus over a network.

In one or more embodiments of the present application, the generation unit 210 is configured to encrypt/sign the software package and generate a corresponding security Manifest (Manifest).

The security manifest includes metadata for the secure boot process. These metadata describe the software package (Image) loaded during the boot process and the related information of the cryptographic signature. The security manifest may also include update instructions for updating the secure boot process.

The secure boot process is a trust chain based boot process. Booting starts with an implicit trusted component, each of the other components being verified before execution. The root of the secure BOOT process, called root of trust, is typically, in terms of hardware, a system-on-chip read only memory (SoC ROM), such as a BOOT ROM, an OTP ROM (one-time programmable read only memory), and the like, where the SoC ROM is the only component in the system that cannot be easily modified or replaced by a simple reprogramming attack, and thus, the BOOT ROM is typically the first BOOT node of the secure BOOT.

In one or more embodiments of the present application, the secure boot process adds cryptographic checks and signature checks to the process of each phase of the secure boot. For example, in the boot process, by performing Encryption check on the software package (Image) by using an Encryption check technology such as aes (advanced Encryption standard), confidentiality of all executed software packages (Image) is ensured, and theft of software is prevented. Furthermore, any unauthorized or malicious modification of the running software is prevented by ensuring the integrity of all executed software packages (images) using signature checking, as will be explained in more detail below.

It will be appreciated that BOOT ROM 120, i.e., BOOT read only memory, may store BOOT code for performing secure BOOT processes for system 10. OTP ROM 130 may store a key file, e.g., a public key hash, of the secure boot process.

Before the device leaves the factory, the generating unit 210 loads the software package required for device boot, the ID of the vendor, and the device class ID or the device ID, and generates a security manifest with an encrypted signature according to a selected encryption protocol by using a private key stored in the secure hardware module or the air-isolated computing device by the manufacturer, wherein a public key of the security manifest and a secret key of each software package are stored. In addition, a public key hash corresponding to the public key is also generated. The security manifest is then written into non-volatile memory of the system 10, typically through a production line, along with the software packages. And the public key hash is burned into the OTP ROM of system 10. Alternatively or additionally, The security manifest and software package may optionally be written to non-volatile memory of The system 10 by way of a network, such as FOTA (Firmware Over-The-Air).

It will be appreciated that the cryptographic protocol to be applied may be various cryptographic protocol algorithms based on public key signatures, such as RSA-PSS (Rivest, Shamir and Adleman-Probabelistic Signature Scheme). In these protocols, trusted vendors (servers) use their private keys to generate signatures of the code they want to deploy and push them to the device along with the software binaries. The device contains the vendor's public key, which can be used to verify whether the binary file has not been modified and whether it is provided by a trusted vendor.

Storing the public key for the root of trust can be problematic, for example, embedding it in system-on-chip rom means that all devices use the same public key, making the device vulnerable if the private key is stolen or reverse engineered successfully. Thus, one-time programmable (OTP) hardware of the system-on-chip, such as polysilicon fuses, OTP ROM, etc., may be used to store a unique public key value for each system during device manufacturing. This allows different public key values to be stored in a single class of device, reducing the risk of attack.

OTP memories typically consume considerable silicon area and therefore the available bits (bits) are typically limited, whereas RSA public keys are more than 1024 bits long, which is typically too large for OTP memory to be available. However, since the public key is not kept secret, it may be stored in a memory of the non-system-on-chip and the cryptographic hash of the public key is stored in the OTP memory. The hash is much smaller in length than the public key itself (256 bits for SHA 256), which can be used to verify the value of the public key at runtime.

When the supplier needs to update the secure boot process of the device, the update instruction needed for updating the secure boot process is loaded into the generating unit 210, and the generating unit 210 generates the security manifest including the update instruction in the same manner as described above. In the system 10, a security manifest including an update command may be pushed through the transceiving unit 220, and the security manifest is stored in an accessible untrusted storage area. As one example, The pushing of The security manifest may be accomplished using FOTA (Firmware Over-The-Air) technology. In this way, the safety manifest can be conveniently deployed on the system 10 through the network without burning or modifying hardware devices in the factory, which reduces the hardware investment cost. Furthermore, since the secure manifest is pushed to an accessible untrusted memory area, rather than to a read-only memory or OTP hardware, the secure manifest can be updated as many times as necessary by the FOTA.

The system 10 receives the security manifest through the network interface 150. The network interface 150 is used to receive and transmit data via a network, which may include various connection types, including but not limited to the Internet, intranets, local area networks, mobile communication networks, and combinations thereof, such as wired, wireless communication links, or fiber optic cables, to name a few.

The memory 140 of the system 10 may be used to store the security manifest sent by the server 20. Memory 140 may include high speed random access memory, such as SRAM, DRAM, and may also include non-volatile memory, such as one or more non-volatile random access memories (NVRAMs), various flash memories, such as SPI flash memory, NAND flash memory, or other non-volatile solid state memory. In some examples, memory 140 may further include memory located remotely from processor 110, which may be connected to device 10 through network interface 150.

In one or more embodiments of the present application, memory 140 may include untrusted memory areas and trusted memory areas. Where the untrusted memory area and the trusted memory area may be different partitions within the same memory, for example, one or more partitions of one memory may be set as untrusted memory areas and one or more other partitions may be set as trusted memory areas. As another example, the untrusted memory area and the trusted memory area may be located in or may be separate memories, respectively, e.g., the trusted memory area may be located in a memory located on the system-on-chip, or the memory of the system-on-chip may be considered to be a trusted memory area, while the untrusted memory area may be located in a memory external to the system-on-chip, or the memory external to the system-on-chip may be considered to be an untrusted memory area. Generally, the untrusted memory area and the trusted memory area are isolated from each other, the contents of the untrusted memory area are modifiable or accessible to a user, no software stored in the untrusted memory area can directly see the address in the trusted memory area, the untrusted memory area is a non-volatile memory area, and the trusted memory area may be a non-volatile memory area but may also be a volatile memory area. For an understanding of untrusted and trusted, reference may be made to prior art trusted zone technology, and related descriptions of the secure world and the general world.

When the system 10 is powered on and started, the reading unit 1211 of the data processing apparatus 121 is configured to, in response to the starting execution of the secure boot process, read the secure manifest and the public key associated with the secure manifest from the untrusted memory area to the trusted memory area;

a verification unit 1212, configured to read the security manifest and the public key from the trusted storage area; and, utilize the public key to verify whether the safety list is complete (integrity);

an updating unit 1213, configured to determine whether an update instruction is included in the security manifest if the security manifest is verified to be complete, where the update instruction is used to update the boot code of the secure boot process; if the determined security manifest includes an update instruction, the secure boot process is interrupted and the update instruction is executed to update the boot code of the secure boot process.

It is understood that integrity (integrity), as referred to herein, is one of the fundamental elements in the field of information security. The principle of integrity is that a user, process or hardware component has the ability to verify the accuracy of what is being sent or transferred, and the process or hardware component is not altered in any way. Generally, data has integrity meaning that the data is not subject to unauthorized modification, including unauthorized creation, insertion, playback, and deletion of the data.

One or more embodiments of a data processing method according to the present application are described below. The method may be implemented using the data processing apparatus described previously.

FIG. 3 illustrates one embodiment of a data processing method according to the present application. As shown in the data processing method 300 of FIG. 3, at block 301, a secure manifest is read from an untrusted memory area to a trusted memory area in response to execution of a secure boot process. After the system 10 is powered on, the data processing device 121 executes the secure BOOT code of the BOOT ROM 120 and the system starts the secure BOOT process. According to the instructions of the boot code, the data processing device 121 reads the security manifest from the untrusted memory area to the trusted memory area.

At block 302, the security manifest and the public key are read from the trusted memory area and a verification is made as to whether the security manifest is complete (integrity) using the public key. The data processing apparatus 121 reads the public key of the secure manifest and calculates a Digest (Digest) of the public key, and then the data processing apparatus 121 reads the public key hash from the OTP ROM 130 and compares the Digest of the public key with the Digest of the public key hash, and if the two digests are matched, the public key is legitimate. And then, verifying the encrypted signature of the safety list by using the public key, wherein if the public key and the signature are matched, the encrypted signature of the safety list is legal, and the binary file of the safety list is not modified. Alternatively or additionally, the data processing device 121 may also verify the integrity of the secure manifest before reading the secure manifest from the untrusted memory area to the trusted memory area.

The security list is put into the trust storage area and then verified, so that higher security is achieved. For example, for a security manifest that is verified on an untrusted memory area, an attacker may modify the security manifest for a very brief window period between the completion of the verification and the beginning of the reading of the security manifest onto the trusted memory area.

If the secure manifest is verified to be complete, at block 303, it is determined whether an update instruction is included in the secure manifest, where the update instruction is used to update the boot code of the secure boot process. And setting a flag bit of the updating instruction in the safety list, wherein the flag bit indicates whether the safety list contains the updating instruction or not. If the value of the flag bit of the update instruction is not null or 0, the safety list contains the update instruction.

Since the secure manifest is protected by an encryption scheme such as an asymmetric cryptographic signature scheme, as described above, the private key of the cryptographic signature is stored in the secure hardware module of the manufacturer, and the public key hash is stored in the OTP ROM 130, the secure manifest has a considerably high security, and thus, the update instruction as a part contained in the secure manifest is also secure.

If the verified security manifest is incomplete, an error message is returned and the secure boot process is ended.

Finally, at block 304, if the secure manifest includes an update instruction, the secure boot process is interrupted and the update instruction is executed to update the boot code of the secure boot process. If the data processing apparatus 121 determines that the security list includes the update instruction, the data processing apparatus 121 interrupts the currently executed secure boot process, and executes the update instruction, when executing the update instruction, the data processing apparatus 121 first reads a header block of the update instruction, where an address of a boot code of the boot process that needs to be updated may be stored in the header block, and the data processing apparatus 121 executes the update instruction according to the address in the header block to perform a new boot process to replace the boot process that needs to be updated.

If the security list does not include the update command, the data processing apparatus 121 continues to execute the original security booting process. The original secure boot process is briefly described below. After the verification of the security manifest is completed, the data processing apparatus 121 verifies the software package, which is an indispensable process in the secure boot process. The data processing means 121 reads the key stored in the secure manifest and uses the key to decrypt the software package, after which the data processing means 121 calculates a digest of the software package and compares the digest with a corresponding digest stored in the secure manifest, and if the two digests match, the software package is authenticated. If not, an error message is returned and the boot process is ended. And after the software package verification is completed, loading the software package to complete the guidance of the current guidance node.

In a typical secure BOOT process, before a second BOOT node starts booting, the first BOOT node, such as the BOOT ROM 120, is required to verify the second BOOT node, so as to ensure that the next level BOOT node is secure, and thus a new trust link can be established at the next level BOOT node.

In the embodiment of the present application, since the metadata stored in the security manifest includes verification data of all software packages that need to be loaded during the secure boot process, alternatively or additionally, the data processing apparatus 121 may execute the boot code to verify all software packages during the boot process of the first boot node, so that in the subsequent boot sequence, the verification of the software packages may not be needed any more.

Fig. 4 shows another embodiment of a data processing method according to the present application. In the data processing method 400 shown in fig. 4, the method 400 is substantially similar to the method 300 shown in fig. 3, and therefore, descriptions of similar parts are not repeated herein. The distinctive parts of the digital processing method 400 will be specifically described below.

At block 401, a security manifest is read. At block 402, the integrity of the security manifest is verified. If the security manifest is complete, at block 403, a determination is made as to whether an update instruction is included in the security manifest. If an update instruction is included, at block 404, the secure boot process is interrupted and the update instruction is executed. The update instruction includes a new software package validation process.

At block 405, a new software package validation process is performed. For both cases, the major bug fixing and the algorithm upgrading may not be realized by simply fixing several instructions, and the instructions in the original software package verification process may need to be rewritten, so that if the number of instructions involved in the new software package verification process is large, the on-chip read-only memory such as the OTP ROM 130 is difficult to meet the requirement of storing the update instructions basically.

In addition, if the update instruction is stored in the OTP ROM, the instruction in the OTP ROM is executed by the processor after the software package verification is completed in the existing boot process, and therefore, it is impossible to update the original software package verification process.

Since the security manifest and the software package may be pushed into the system 10 via FOTA, it is possible to upgrade the verification algorithm for the original software package validation, for example. When the verification algorithm of the original software package cannot meet higher security requirements, the software package may need to be verified again by using a new encryption signature or other cryptographic verification algorithms. As an example, referring to the related description of fig. 1, a new security manifest containing a corresponding update instruction may be pushed to the system 10 by FOTA, thereby enabling the software package to be verified using a new verification algorithm.

Fig. 5 shows another embodiment of a data processing method according to an embodiment of the application. The method 500 shown in fig. 5 is another variation of the

methods

300 and 400 described above. Therefore, descriptions of similar parts are not repeated herein. The distinctive parts of the data processing method 500 will be specifically described below.

As a possible scenario, for some systems 10, especially for some systems 10 applied in the field of internet of things, there may be a case that the life cycle of the system 10 is particularly long, for example, more than 5 years or 10 years, and the hardware of these systems 10 cannot be easily replaced, so that after several years, the secure BOOT process of the system 10 cannot meet the basic security requirement, in which case, the BOOT code of the whole secure BOOT process needs to be updated/replaced, but the BOOT ROM 120 is hard-soldered on the system on chip, so the secure BOOT process cannot be updated. Data processing method 500 is one exemplary method to address the above-described problems.

At block 501, a security manifest is read. At block 502, the integrity of the security manifest is verified. If the security manifest is complete, at block 503, a determination is made as to whether an update instruction is included in the security manifest. If an update instruction is included, the secure boot process is interrupted and the update instruction is executed at block 504. The update instruction includes a new secure boot process.

As above, as an example of a secure BOOT process having failed to meet security requirements, BOOT code in the BOOT ROM 120, for example, may not be able to decrypt software packages that are pushed into the system 10 that employ a new encryption algorithm. For this case, the security manifest includes not only the key corresponding to the new encryption algorithm of the software package, but also an update instruction to perform a new decryption process. The new secure boot process is specifically as follows:

at block 505, the new key for the software package is read from the secure manifest. The software package is then decrypted at block 506. At block 507, it is determined whether the decryption was successful, and if so, at block 508, a software package validation process is performed; if the decryption fails, an error is returned and the boot process is ended.

The software package validation process of block 508 may be performed in accordance with an original secure boot process, alternatively or additionally, the software package validation process of block 508 may also be, for example, as described above in block 405. In this case, the secure BOOT process of the BOOT ROM 120 is entirely replaced by the update instruction contained in the secure manifest.

In accordance with one or more embodiments of The present application, The pushing of update instructions may be accomplished using FOTA (Firmware Over-The-Air) technology. Therefore, the updating instruction can be conveniently deployed on the equipment through the network, and the burning or modification of hardware devices in a factory is not needed, so that the hardware investment cost is reduced. In addition, since the update command is pushed to the accessible untrusted memory area, rather than to the rom or OTP hardware, the secure manifest can be updated as many times as needed by the FOTA. Further, the updating instruction can update the verification algorithm verified by the original software package. Further, the update instruction can update/replace the boot code of the entire secure boot process.

FIG. 6 is a block diagram of a system according to an embodiment of the present application. The system includes, but is not limited to, laptop devices, desktop machines, handheld PCs, personal digital assistants, engineering workstations, servers, network appliances, network hubs, switches, embedded processors, Digital Signal Processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular telephones, portable media players, handheld devices, and other systems of various other electronic devices. In general, it is generally suitable to be able to incorporate the systems and electronic devices disclosed herein.

Referring now to FIG. 6, shown is a block diagram of a system 60 in accordance with one embodiment of the present application. The system 60 may include one or more processors 601 coupled to a controller hub 603. In one embodiment, the controller hub 603 includes, but is not limited to, a Graphics Memory Controller Hub (GMCH) (not shown) and an input/output hub (IOH) (not shown) (which may be on separate chips), where the GMCH includes memory and graphics controllers and is coupled with the IOH. The system 60 may also include a firmware module 602 and a memory 604 coupled to the controller hub 603. Alternatively, one or both of the memory and GMCH may be integrated within the processor (as described herein), with the memory 604 and firmware module 602 coupled directly to the processor 601 and to the controller hub 603, with the controller hub 603 and IOH in a single chip.

Firmware module 602 is used for secure boot startup of system 60.

The memory 604 may be, for example, Dynamic Random Access Memory (DRAM), Phase Change Memory (PCM), or a combination of the two. For at least one embodiment, controller hub 603 communicates with processor 601 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a quick channel interconnect (QPI), or similar connection 606.

In one embodiment, processor 601 executes instructions that control data processing operations of the secure world. Firmware module instructions may be embedded in these instructions.

According to one or more embodiments of the present application, there is also disclosed a machine-readable medium having stored thereon instructions which, when executed on a machine, cause the machine to perform any one of the data processing methods described above.

In accordance with one or more embodiments of the present application, there is also disclosed a system comprising:

A processor, being one of the processors of the system, for use in any of the data processing methods described above. The method embodiments of the present application may be implemented in software, magnetic, firmware, etc.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. These representations, known as "IP cores" may be stored on a tangible, machine-readable medium and provided to a number of customers or manufacturing facilities to load into the manufacturing machines that actually make the logic or processor.

Such machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles of manufacture or formation by machines or devices that include storage media such as: hard disk any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks; semiconductor devices such as Read Only Memory (ROM), Random Access Memory (RAM) such as Dynamic Random Access Memory (DRAM) and Static Random Access Memory (SRAM), Erasable Programmable Read Only Memory (EPROM), flash memory, Electrically Erasable Programmable Read Only Memory (EEPROM); phase Change Memory (PCM); magnetic or optical cards; or any other type of media suitable for storing electronic instructions.

Accordingly, embodiments of the present application also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuits, devices, processors, and/or system features described herein. These embodiments are also referred to as program products.

In some cases, an instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may transform (e.g., using a static binary transform, a dynamic binary transform including dynamic compilation), morph, emulate, or otherwise convert the instruction into one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on the processor, off-processor, or partially on and partially off-processor.

The following paragraphs provide examples of the various embodiments disclosed herein.

Embodiment 1, a data processing method, comprising:

reading the safety list and the public key from the trust storage area, and verifying whether the safety list is complete (integrity) by using the public key;

Embodiment 2, the data processing method of embodiment 1, further comprising receiving the security manifest from a server over a network.

Embodiment 3, according to the data processing method of embodiment 1, the verifying whether the security manifest is complete by using the public key further includes:

verifying whether the public key is matched with the set public key hash;

Embodiment 4, according to the data processing method of embodiment 3, the verifying whether the public key matches the signature of the security manifest includes:

Embodiment 5 according to the data processing method of embodiment 1, if it is verified that the secure manifest is incomplete, an error message is returned and the secure boot process is ended.

Embodiment 6, according to the data processing method of embodiment 1, if it is determined that the security manifest does not include the update instruction, the secure boot process is continuously performed.

Embodiment 7, the data processing method according to embodiment 1, wherein the security manifest includes metadata of the secure boot process, the metadata including related information describing a software package and a signature loaded in the secure boot process.

Embodiment 8, according to the data processing method of embodiment 3, the public key hash is stored in a one-time programmable memory, wherein the one-time programmable memory is different from the untrusted memory area or the trusted memory area.

Embodiment 9 and the data processing method according to embodiment 1, wherein the untrusted storage area and the trusted storage area are nonvolatile storage media.

Embodiment 10 and the data processing method according to embodiment 1, wherein the untrusted storage area is a nonvolatile storage medium, and the trusted storage area is a volatile storage medium.

Embodiment 11 and the data processing method according to embodiment 1, wherein the untrusted memory area and the trusted memory area are on a same storage medium.

Embodiment 12, according to the data processing method of any one of embodiments 1 to 11, the update instruction includes the boot code for replacing a part of the secure boot process, or the boot code for replacing the whole of the secure boot process.

Embodiment 13, a data processing apparatus, comprising:

Embodiment 14, the data processing apparatus of embodiment 13, further comprising receiving the security manifest from a server over a network.

Embodiment 15, the data processing apparatus according to embodiment 13, wherein the verifying whether the security manifest is complete using the public key further includes:

verifying whether the public key is matched with the set public key hash;

Embodiment 16, according to the data processing apparatus of embodiment 15, wherein the verifying whether the public key matches the signature of the security manifest comprises:

Embodiment 17, the data processing device of embodiment 13, if the secure manifest is verified to be incomplete, returning an error message and ending the secure boot process.

Embodiment 18, the data processing apparatus according to embodiment 13, wherein if it is determined that the security manifest does not include the update instruction, the secure boot process is continued.

Embodiment 19, the data processing apparatus of embodiment 13, wherein the secure manifest includes metadata of the secure boot process, the metadata including relevant information describing software packages and signatures loaded in the secure boot process.

Embodiment 20, the data processing apparatus of embodiment 15, wherein the public key hash is stored in a one-time programmable memory, wherein the one-time programmable memory is distinct from the untrusted memory bank or the trusted memory bank.

Embodiment 21 and the data processing apparatus according to embodiment 13, wherein the untrusted storage area and the trusted storage area are non-volatile storage media.

Embodiment 22 and the data processing apparatus according to embodiment 13, wherein the untrusted storage area is a non-volatile storage medium and the trusted storage area is a volatile storage medium.

Embodiment 23 and the data processing apparatus according to embodiment 13, wherein the untrusted memory area and the trusted memory area are on the same storage medium.

Embodiment 24, the data processing apparatus as in any of embodiments 13 to 23, wherein the update instruction includes the boot code to replace a part of the secure boot process, or replace the entire process of the secure boot process.

Embodiment 25 is a machine-readable medium having stored thereon instructions which, when executed on a machine, cause the machine to perform the data processing method of any one of embodiments 1 to 12.

Embodiment 26, a system, comprising:

A processor, which is one of processors of the system, configured to perform the data processing method according to any one of embodiments 1 to 12.

Embodiment 27, a server, comprising:

the generating unit is used for generating a safety list and a public key related to the safety list, and carrying out encryption signature on the safety list, wherein the safety list comprises a software package related to a safety boot process of the data processing device and signed metadata;

and the transceiving unit is used for sending the safety list to the data processing device through a network.

Embodiment 28 the server of embodiment 27, wherein the security manifest comprises an update instruction, wherein the update instruction is to update boot code of the secure boot process.

Embodiment 29, the server of embodiment 27, the server signing the secure manifest with a private key stored in a secure hardware module or an air-isolated computing device according to a cryptographic protocol, and generating the corresponding public key.

Embodiment 30, a data generation method, comprising:

generating a security manifest and a public key related to the security manifest, and performing encryption signature on the security manifest, wherein the security manifest comprises a software package related to a security boot process of a data processing apparatus and signed metadata;

and sending the safety list to the data processing device through a network.

Embodiment 31 the data generating method of embodiment 30, wherein the security manifest includes an update instruction, wherein the update instruction is used to update boot code of the secure boot process.

Embodiment 32, the data generation method of embodiment 30, signing the secure manifest with a private key stored in a secure hardware module or an air-isolated computing device according to an encryption protocol, and generating the corresponding public key.

Claims

1. A data processing method, comprising:

2. The data processing method of claim 1, further comprising receiving the security manifest from a server over a network.

3. The data processing method of claim 1, wherein the verifying whether the security manifest is complete using the public key further comprises:

verifying whether the public key is matched with the set public key hash;

4. The data processing method of claim 3, wherein the verifying whether the public key matches the signature of the secure manifest comprises:

and matching the digest of the public key with the signature digest of the safety manifest.

5. The data processing method of claim 1, wherein if the secure manifest is verified to be incomplete, returning an error message and ending the secure boot process.

6. The data processing method according to claim 1, wherein if it is determined that the security manifest does not include the update instruction, the secure boot process is continued.

7. The data processing method of claim 1, wherein the secure manifest comprises metadata of the secure boot process, the metadata comprising related information describing software packages and signatures loaded in the secure boot process.

8. The data processing method of claim 3, wherein the public key hash is stored in a one-time programmable memory, wherein the one-time programmable memory is distinct from the untrusted memory area or the trusted memory area.

9. The data processing method of claim 1, wherein the untrusted storage area and the trusted storage area are non-volatile storage media.

10. The data processing method of claim 1, wherein the untrusted storage area is a non-volatile storage medium and the trusted storage area is a volatile storage medium.

11. The data processing method of claim 1, wherein the untrusted memory area and the trusted memory area are on the same storage medium.

12. The data processing method according to any one of claims 1 to 11, wherein the update instruction includes the boot code for replacing a partial process of the secure boot process, or the boot code for replacing an entire process of the secure boot process.

13. A data processing apparatus, comprising:

14. A machine-readable medium having stored thereon instructions which, when executed on a machine, cause the machine to perform the data processing method of any one of claims 1 to 12.

15. A system, comprising:

A processor, being one of the processors of the system, for performing the data processing method of any one of claims 1 to 12.