RU2808198C1 - Method of trusted device boot with ability to certify different boot stages by several independent key owners - Google Patents

Abstract

FIELD: computing.

SUBSTANCE: invention is related to a method, a machine-readable storage medium and a system for trusted device booting with the possibility of certification of different boot stages by several independent key owners. The system contains two isolated program code execution modules located on the processor chip - an isolated security domain and at least one main processor executing boot loader code, OS image, read-only memory (ROM), code in the processor ROM, one-time programmable memory (OPM), non-volatile memory, while the boot contains N stages, in which the first stage, (N-2) intermediate stages and the last stage can be distinguished. Moreover, at each stage, keys belonging to different owners can be used for certification, where the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining type I keys of the first stage, type I keys of the intermediate and last stages can be entered in a certified container, containing an electronic signature, which is verified only upon entry; the isolated security domain and the main processor are configured to exchange data, including for working with key information: the hash sum of the key that forms the root of trust, located in one-time programmable memory (OPM) through the interaction interface. The non-volatile memory is configured to store a hierarchy of loaders, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private key of the pair is used during certification, and the public key is used when verifying certification, where public cryptographic keys can be: located in non-volatile memory (type I) or placed in the form of a digital certificate (type II); the RAM is configured to load at least one bootloader in the hierarchy of bootloaders from non-volatile memory, the isolated security domain contains program code, which is accessed to check this bootloader with hardware, through the interaction interface between the isolated security domain and the processor, determining the validity of the key, which is contained in the bootloader image, while the OPM contains information about the keys, which is intended to determine the validity of the key, the bootloader is configured to transfer control to it if it is successfully verified, during which, in response to the fact that the key is valid, the image signature is verified; the image of at least one next bootloader is configured to be parsed by the previous bootloader by reading its signature and public key, the hash of this key is calculated and the presence of such a hash in the OPM is checked, in response to the fact that the hash is not found, authentication is considered failed, in response to the fact that the hash is found in the OPM, a check of whether the revocation sign of this key is set in the OPM is carried out, in response to the fact that the key is revoked, the authentication is considered failed, in response to the fact that the key is valid, the signature of the image on the public key is verified, in case where the signature verification fails, the authentication is considered failed, the at least the next verified bootloader from the bootloader hierarchy is configured to transfer control to it in response to the fact that the signature verification is completed successful, in response to the authentication failing, the boot process is terminated; the previous bootloader is configured to verify at least each next bootloader in the bootloader hierarchy using the active intermediate stage key; the OS image contains a digital certificate generated signed by the last stage key, where the last stage key is signed by the active key of the intermediate stage; the OS image is verifiable using a digital certificate and an active middle stage key.

EFFECT: provision of secure booting of the device from the boot loader to the operating system (OS), protected from unauthorized actions.

16 cl, 8 dwg

Description

Application area

[1] The group of inventions relates to technologies for providing access to computer resources, and more specifically to technologies for trusted loading of computers with a mechanism for dividing the functions of verifying loading stages between several owners of keys (cryptographic keys). These technologies are intended, among other things, to protect computers from unauthorized loading and from gaining unauthorized access to confidential information stored inside computers.

[2] One of the threats aimed at violating the confidentiality of information stored in a computer is the threat associated with gaining unauthorized access to such machines and to user data inside them. An effective measure to combat this threat is trusted loading of computers, i.e. loading computers after successful computer authentication procedures and monitoring the integrity of computer files.

[3] Trusted device boot is a process that certifies that from the moment power is supplied to the start of the operating system (OS), all program code executed on the device is verified, as a result of which a decision is made about its execution on the device.

[4] The executable program code is divided into several parts, which are stored in images equipped with electronic signatures.

[5] The hardware capabilities of modern systems on a chip (SoC) make it possible to organize a trusted boot, however, software-algorithmic boot schemes do not imply flexibility in the division of powers to manage the composition of executable components at different boot stages in conditions where the supplier of the hardware platform, boot loader, operating system and operator the final software and hardware solution are different organizations. The present invention provides an approach to solve this problem.

[6] The boot process is the sequential execution of software components that initialize the device. Each participant in the process certifies the code in his area of responsibility, for example, the customer of the final solution certifies the primary boot loader code, the motherboard manufacturer certifies the BIOS code, the operating system manufacturer certifies the OS kernel.

[7] The loading stage is the loading of executable code that is in the area of responsibility of the process participant.

State of the art

[8] Technologies for trusted loading of a computer are known from the prior art.

[9] From application US 2017180139 A1, publ. 06/22/2017, technologies that reveal key revocation are known. The key revocation system may comprise a processor, an embedded controller, a non-volatile memory that stores a system instruction signature key authorization data element, the data element including a system instruction signature key, a signature key number, and a signature. The on-chip controller may include a plurality of keys for validating a data element, as well as a one-time programmable (OTP) memory and a key of the multi-keys that can be revoked using the OTP memory, wherein revocation of the key permanently prevents the on-chip memory, controller from using the key.

[10] The main disadvantages of the proposed technology are the lack of flexibility of the system and the impossibility of dividing responsibilities between different key owners.

[11] From application EP 2854066 A1, publ. 04/01/2015, a processing system with the concept of controlling access of the processing unit of the processing system to the software and hardware code is known. It is proposed to identify a valid key stored in a first memory area based on verification data of a second memory area, wherein the verification data indicates whether the key is valid or not. The firmware code is processed according to a specified verification algorithm to calculate a verification value for the firmware code. The verification value and the actual key are analyzed to determine whether the firmware code can be trusted. The processing unit's access to the firmware code is controlled based on whether the firmware code is determined to be trusted or not.

[12] The main disadvantages of the proposed technology are the lack of flexibility of the system and the impossibility of dividing responsibilities between different key owners.

[13] In application US 2009259854 A1, publ. 10/15/2009, secure chain of trust technology disclosed. When executing secure boot code in secure boot mode, the less secure boot code can be authenticated using a private key. The security key can also be calculated or generated in secure boot mode. After control is transferred to the authenticated, less secure boot code, at least one application can be authenticated using the secure key. Once authenticated in a less secure boot mode, the application can be executed by the programmable integrated circuit. In this way, a secure chain of trust can be implemented for the programmable integrated circuit.

[14] The main disadvantages of the claimed technology are the lack of flexibility of the system and the impossibility of dividing responsibilities between different key owners.

[15] In application JP 2013524385 A, publ. 06/17/2013, technology for checking the integrity of a network device is disclosed. The network device containing the protected hardware module can obtain the root key. The secure hardware module can also receive the first code dimension. The secure hardware module may provide a first key based on the root key and the first code dimension. The secure hardware module may receive the second code dimension and provide a second key based on the first key and the second code dimension. Issuing keys based on code measurements can provide step-by-step authentication.

[16] The main disadvantages of the claimed technology are the lack of flexibility of the system and the impossibility of dividing responsibilities between different key owners.

[17] The proposed technology is aimed at eliminating the shortcomings of the prior art.

Disclosure of the Invention

[18] The main distinctive features of this technology are:

a. division of responsibility of each manufacturer for the software component released by it (bootloaders of all levels and OS) installed on the device;

b. use of 2 types of cryptographic keys,

c. when a cryptographic key is entered into a stage, it becomes the root of trust for this and subsequent stages,

d. when a cryptographic key is entered, the container is verified either with the active cryptographic key of the current stage, or with the active cryptographic key of the previous stage, if cryptographic keys of the current stage have not yet been entered,

e. Type II cryptographic keys are supplied in a digital certificate, which is certified by a Type I or II cryptographic key of the previous level,

f. The program code of the loaders of each stage is certified by any of the active cryptographic keys of this stage.

[19] The proposed technology is aimed at achieving the following technical results:

[20] Expanding the functionality of implementing trusted device boot from the boot loader to the OS image with a mechanism for dividing the functions of certifying boot stages between several owners of cryptographic keys, ensuring the possibility of dividing responsibilities between different key owners.

[21] Thanks to this mechanism, responsibility is established (absence of flaws/deficiencies/bookmarks/undeclared capabilities) of each manufacturer for the software component released by him, including bootloaders of all levels and OS images installed on the device, and responsibility is removed from participants in the production of the device who do not own relevant components.

[22] Ensuring trusted loading of all used software components (loaders of all levels and OS images), protected from unauthorized actions: downloading, unauthorized access to protected information stored inside the device.

[23] Ensuring the authenticity of the OS image by signing the OS image with a cryptographic security key certified by the active cryptographic key of the intermediate stage of verification, thereby generating a digital certificate that accompanies the image when booted.

[24] The specified technical results are achieved through the proposed method of trusted device loading with a mechanism for dividing the functions of verifying the loading stages between several owners of cryptographic keys,

[25] which includes the following steps: loading an electronic computer (computer) containing at least one processor executing boot loader code and an OS image, read-only memory (ROM), code in the processor ROM, one-time programmable memory (OPM) , immutable memory, and the loading consists of N stages, in which the first, (N-2) intermediate stages and the last stage can be distinguished;

[26] form a hierarchy of loaders that are stored in non-volatile memory, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, while the private key of the pair is used during authentication, and the public key is used during authentication verification, where public cryptographic keys can be: placed in immutable memory (type I) or placed in volatile memory in the form of a digital certificate (type II), and at each stage keys belonging to different owners can be used for certification, the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining keys type I of the first stage, type I keys of the intermediate and last stages can be entered in a certified container containing an electronic signature, which is verified only upon entry;

[27] when a cryptographic key is introduced into a stage, it becomes the root of trust for this and subsequent stages;

[28] load at least one bootloader in the bootloader hierarchy from non-volatile memory into RAM, check this bootloader, determine the validity of the key contained in the bootloader image, and the validity of the key is determined based on the information about the keys contained in the OPP,

[29] in response to the fact that the key is valid, they check the signature of the image; if the verification is successful, control is transferred to such a loader;

[30] parse the image of the next at least one bootloader, using the previous bootloader, by reading its signature and public key, calculate the hash of this key and check the presence of such a hash in the OPP,

[31] in response to the hash not being found, the authentication fails.

[32] in response to the fact that the hash is found in the OPP, they check whether the revocation flag of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered to have failed,

[33] in response to the fact that the key is in circulation, the signature of the image on the public key is verified; if the signature verification fails, the authentication is considered failed,

[34] in response to the fact that signature verification has completed successfully, control is transferred to the verified at least the next loader in the loader hierarchy,

[35] in response to the authentication failure, the boot process is terminated;

[36] verify each at least subsequent loader in the loader hierarchy with the previous loader using the active key of the intermediate stage;

[37] release an OS image signed with the last-stage key, where the last-stage key is signed by the active middle-stage key, generating a digital certificate that accompanies the OS image;

[38] verify the OS image using a digital certificate and an active middleware key.

[39] According to a first embodiment of the invention, the first key of the first stage may be the only root of trust for this and subsequent stages;

[40] each stage can have its own cryptographic key, which is the root of trust for this stage;

[41] verification of the bootloader in the bootloader hierarchy can be carried out by hardware and software;

[42] keys can be written in a compressed or full representation.

[43] In another embodiment, type I cryptographic keys can be in two states: active - active or retired - inactive, while the transition between states is possible only from the active to inactive state.

[44] In yet another embodiment, Type II cryptographic keys are provided in a digital certificate that is authenticated by a Type I or II key of the previous level, but Type II keys do not have the ability to authenticate keys at the same level as themselves.

[45] The specified technical results are also achieved due to the proposed trusted device boot system with the ability to certify different boot stages by several independent key owners,

[46] containing two isolated program code execution modules located on the processor chip - an isolated security domain and at least one main processor executing bootloader code, an OS image, read-only memory (ROM), code in the processor ROM, one-time programmable memory ( OPP), immutable memory, while the loading contains N stages: in which we can distinguish the first, (N-2) intermediate stages and the last stage;

[47] in this case, at each stage, keys belonging to different owners can be used for certification,

[48] where the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining type I keys of the first stage, the type I keys of the intermediate and last stages can be entered in a certified container containing an electronic signature that is verified only when inserted;

[49] the isolated security domain and the main processor are configured to exchange data, including for working with key information: the hash sum of the key that forms the root of trust, located in once-programmable memory (OPM), through an interaction interface;

[50] the non-volatile memory is configured to store a hierarchy of loaders, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private key of the pair is used during certification, and the public key is used during verification verification, where public cryptographic keys can be: placed in immutable memory (type I) or hosted in the form of a digital certificate (type II);

[51] the RAM is configured to load at least one bootloader in the hierarchy of bootloaders from non-volatile memory, the isolated security domain contains program code, which is accessed to check this bootloader with hardware, through the interaction interface between the isolated security domain and the processor, determining the validity of the key contained in the bootloader image, while the OPP contains information about the keys, which is intended to determine the validity of the key,

[52] the bootloader is configured to transfer control to it in case of successful verification, during which, in response to the fact that the key is valid, the image signature is checked;

[53] the image of the next at least one loader is configured to be parsed using the previous loader by reading its signature and public key, the hash of this key is calculated and the presence of such a hash in the OPP is checked,

[54] in response to the hash not being found, the authentication fails.

[55] in response to the fact that the hash is found in the OPP, they check whether the revocation flag of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered to have failed,

[56] in response to the fact that the key is in circulation, the image signature on the public key is verified; if the signature verification fails, the authentication is considered failed,

[57] the verified at least the next bootloader from the bootloader hierarchy is configured to transfer control to it in response to the fact that the signature verification has completed successfully,

[58] in response to the authentication failure, the boot process is terminated;

[59] the previous bootloader is configured to verify each at least the next bootloader in the bootloader hierarchy using the active intermediate stage key;

[60] the OS image contains a digital certificate generated signed by the last stage key, where the last stage key is signed by the active intermediate stage key;

[61] The OS image is verifiable using a digital certificate and an active middle stage key.

[62] In accordance with another embodiment of the invention, verification of the bootloader in the bootloader hierarchy may be performed by hardware and software;

[63] keys can be written in compressed or full representation

[64] In another embodiment, type I cryptographic keys can be in two states: active - active or retired - inactive, while the transition between states is possible only from the active to inactive state.

[65] In yet another embodiment, Type II cryptographic keys are provided in a digital certificate that is certified by a Type I or II key of the previous level, but Type II keys do not have the ability to validate keys at the same level as themselves.

[66] The specified technical results are also achieved through a permanent machine-readable storage medium containing machine-readable instructions executed by a computer processor and intended for executing a method of trusted booting of a device with a mechanism for dividing the functions of certifying boot stages between several key owners,

[67] in which two isolated program code execution modules are located on the processor chip, an isolated security domain and a main processor executing bootloader code, an OS image, one-time programmable memory (OPM), non-volatile memory, and the boot contains N stages, containing stages on of which:

[68] we can distinguish the first, (N-2) - intermediate stages and the last stage;

[69] at each stage, keys belonging to different owners can be used for authentication,

[70] where the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining type I keys of the first stage, the type I keys of the intermediate and last stages can be entered in a certified container containing an electronic signature that is verified only when inserted;

[71] use the main processor to access an isolated security domain through an interaction interface to work with key information: the hash sum of the key, which forms the root of trust, located in once-programmable memory (OPM);

[72] form a hierarchy of loaders that are stored in non-volatile memory, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private key of the pair is used during authentication, and the public key is used during authentication verification, where public cryptographic keys can be: placed in immutable memory (Type I) or hosted in the form of a digital certificate (Type II);

[73] load at least one bootloader in the hierarchy of bootloaders from non-volatile memory into RAM, check this bootloader with hardware, accessing the program code of the isolated security domain through the interaction interface between the isolated security domain and the processor, determining the validity of the key that is contained in the bootloader image, while the validity of the key is determined based on information about the keys contained in the OPP,

[74] in response to the fact that the key is valid, the image signature is checked; if the verification is successful, control is transferred to such a loader;

[75] parse the image of the next at least one bootloader, using the previous bootloader, by reading its signature and public key, calculate the hash of this key and check the presence of such a hash in the OPP,

[76] in response to the hash not being found, the authentication fails.

[77] in response to the fact that the hash is found in the OPP, they check whether the revocation flag of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered to have failed,

[78] in response to the fact that the key is in circulation, the image signature on the public key is verified; if the signature verification fails, the authentication is considered failed,

[79] in response to the fact that signature verification is successful, control is transferred to the verified at least the next loader in the loader hierarchy,

[80] in response to the authentication failure, the boot process is terminated;

[81] verify each at least subsequent bootloader in the bootloader hierarchy with the previous bootloader using the active key of the intermediate stage;

[82] release an OS image signed with a last-stage key, where the last-stage key is signed by an active mid-stage key, generating a digital certificate that accompanies the OS image;

[83] verify the OS image using a digital certificate and an active middleware key.

[84] In accordance with yet another embodiment of the invention, cryptographic keys may be recorded in a compressed or full representation.

[85] In another embodiment, type I cryptographic keys can be in two states: active active or retired inactive, and the transition between states is possible only from the active to inactive state.

[86] In yet another embodiment, Type II cryptographic keys are provided in a digital certificate that is authenticated by a Type I or II key of the previous level, but Type II keys do not have the ability to authenticate keys at the same level as themselves.

Brief description of drawings

[87] In FIG. Figure 1 shows a diagram of the organization of a method for trusted loading of a device with a mechanism for dividing the functions of verifying the loading stages between several owners of cryptographic keys.

[88] In FIG. Figure 2 shows an example implementation of a system for trusted device booting with a mechanism for dividing the functions of verifying boot stages between several owners of cryptographic keys.

[89] In FIG. Figure 3 shows an example implementation of the OS image authentication procedure.

[90] In FIG. Figure 4 shows an example implementation of the procedure for verifying the authenticity of an OS image with three owners of cryptographic keys.

[91] In FIG. Figure 5 shows an example implementation of the stage of entering the hash amount of the primary cryptographic key of the root of trust for the program code of the main processor.

[92] In FIG. 6 shows an example implementation of the stage of entering hash sums of additional cryptographic keys of the root of trust for the program code of the main processor.

[93] In FIG. 7 shows an example implementation of the stage of removing the hash sum of the cryptographic key of the root of trust for the program code of the main processor from circulation.

[94] In FIG. 8 illustrates an exemplary implementation of a computer system in accordance with some embodiments of the present invention.

Carrying out the invention

[95] Next, the proposed technologies for trusted device loading with a mechanism for dividing the functions of verifying loading stages between several owners of cryptographic keys will be described, with examples of implementation of the proposed technology.

[96] The proposed trusted boot technology is suitable for any devices that are computers, for example, based on processors with ARMv8 architecture, and operating systems based on the Linux kernel.

[97] The proposed technology is designed to ensure safe booting of the device by verifying the sequence of loaded components, starting from the moment power is supplied to the processor. The secure boot process is ensured, among other things, by code in the processor ROM.

[98] In FIG. 1 presents the main stages of a method 200 for trusted device boot with a mechanism for dividing the functions of verifying the boot stages between several owners of the cryptographic key.

[99] This method is implemented using a trusted device boot system 100 with a mechanism for dividing the functions of verifying boot steps between multiple cryptographic key owners, shown in FIG. 2, which in turn is part of the computer system shown in FIG. 8. Moreover, this trusted boot method can also be implemented using a non-transitory computer readable storage medium 410, also shown in FIG. 8.

[100] To implement the method of trusted booting of a device, it is sufficient to have a one-time programmable memory (OPM). This memory (One-Time Programmable ROM - OTPROM) is user-programmable and in its initial state contains cells with one bits. Only those memory cells whose contents should take on the value 0 can be programmed. To do this, a sequence of high-voltage pulses is applied to the memory cell.

[101] The voltage level, the number of pulses and their timing parameters must strictly comply with the technical specifications. Once a zero is written, it is impossible to restore the single value. For this reason, the memory is called one-time programmable ROM. However, it should be pointed out that it is possible to program (untouched) cells with one bits before programming them.

[102] The essence of the proposed technology is to organize a key trusted download scheme with independent change of cryptographic keys without the need to certify the chain of trust with cryptographic keys of previous download stages, which provides the ability to share responsibility for certifying download stages between several owners of cryptographic keys, which is ensured by the following algorithm.

[103] The trusted boot method 200 comprises major steps 201-208 shown in the flowchart of FIG. 1.

[104] At step 201, the main processor accesses the isolated security domain through an interaction interface for working with key information: a hash of the cryptographic key that forms the root of trust, located in the CPR.

[105] At step 202, a hierarchy of loaders is formed, which are stored in non-volatile memory, where each load stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private cryptographic key of the pair is used during authentication, and the public one is used during authentication verification, where the public cryptographic keys can be: located in non-volatile memory (type I) or located in the form of a digital certificate (type II).

[106] In some embodiments, an example of a non-volatile memory component may be one-time programmable memory (OPM).

[107] The loading process is divided into N stages, among which we can distinguish the first, (N-2) intermediate and last stages. To describe the details of the circuit mechanisms, it is enough to consider a circuit with one intermediate stage.

[108] Each boot step is associated with one or more cryptographic keys.

[109] Cryptographic keys can be of two types:

i. (type I) located in immutable memory (including in the form of a hash) and

ii. (type II) located in variable memory, distributed in the form of a digital certificate along with a certified image of the executable code.

[110] Type I cryptographic keys can be in two states: valid (active) or retired (inactive). Transition between states is only possible from active to inactive states.

[111] The first cryptographic key of the first stage is stored exclusively in a trusted manner in immutable memory.

[112] At the same time, the remaining cryptographic keys of type I of the first stage, cryptographic keys of type I of the intermediate and last stages can be entered similarly to the introduction of the first cryptographic key, or in a certified container.

[113] In the case of using cryptographic keys with type I and type II: the chain of verification of cryptographic keys will be lengthened: type I is certified by type II, then type II is certified by the loader.

[114] At step 203, at least one bootloader in the hierarchy of bootloaders is loaded from non-volatile memory into RAM, this bootloader is verified by accessing the isolated security domain program code through the interface between the isolated security domain and the processor, determining the validity of the cryptographic key, which is contained in the bootloader image, and the validity of the key is determined based on information about the cryptographic keys contained in the OPP.

[115] A block diagram of an embodiment of an OS image authentication procedure is shown in FIG. 3.

[116] To enter a cryptographic key, the container is certified either with the active cryptographic key of the current stage, or with the active cryptographic key of the previous stage, if the cryptographic keys of the current stage have not yet been entered. The first cryptographic key of each stage entered is the root of trust for that stage (this feature of the design allows the creation of local roots of trust, ensuring the independence of the owners of cryptographic keys of different stages).

[117] The transfer of a cryptographic key to an inactive state is performed upon certification by any of the active cryptographic keys of the same stage.

[118] A special feature of the scheme is the mechanism for entering cryptographic keys using a container containing an electronic signature, which is verified only when entered, which allows saving space in immutable memory (in a particular case, in the OPP) and computing resource for verification.

[119] This feature allows you to save memory space, as well as independently enter the cryptographic keys of each stage, and also allows you to create an independent root of trust at each stage.

[120] Cryptographic keys can be written in a compressed or full form. If the amount of memory allows, then the cryptographic keys are written in a full representation, and if there is not enough memory, then in a compressed form, for example, in the form of a hash sum. This feature applies to public cryptographic keys.

[121] Type II cryptographic keys are supplied in a digital certificate that is certified by a previous level Type I or II cryptographic key.

[122] Type II cryptographic keys do not have the ability to authenticate cryptographic keys at the same level as themselves.

[123] The program code of the loaders of each stage is certified by any of the active cryptographic keys of this stage.

[124] At step 204, in response to the fact that the cryptographic key is valid, the image signature is verified; if the verification is successful, control is transferred to such a bootloader.

[125] At step 205, the next at least one bootloader image is parsed by the previous bootloader by reading its signature and public key, the hash sum of this cryptographic key is calculated, and the presence of such a hash sum in the OPP is checked.

[126] In this case, in response to the fact that the hash sum is not found, the authentication is considered to be failed, and in response to the fact that the hash sum is found in the CPP, it is checked whether the cryptographic key has been revoked. Such verification may include checking whether the cryptographic key has been revoked in the CPP. In response to the fact that the cryptographic key is revoked, the authentication is considered to have failed.

[127] In response to the fact that the cryptographic key is in circulation, the signature of the image on the public cryptographic key is verified; if the signature verification fails, the authentication is considered to have failed.

[128] In response to the signature verification being successful, control is transferred to the verified at least the next bootloader in the bootloader hierarchy, in response to the authentication being failed, the boot process is terminated.

[129] If the bootloader signature check fails, the entire boot process stops and you must start booting from the very first bootloader.

[130] In this case, an error message is displayed, the device is stopped loading, and a new boot requires pressing “reset” or turning the power on/off.

[131] At step 206, each at least the next loader in the loader hierarchy is verified against the previous loader using the middle stage's active cryptographic key.

[132] At step 207, an OS image signed with the last stage cryptographic key is released, where the last stage cryptographic key is signed by the active cryptographic key of the intermediate stage, generating a digital certificate that accompanies the OS image.

[133] At step 208, the OS image is verified using the digital certificate and the active cryptographic middle stage key.

[134] In this case, the OS image is certified in the form of a signature with a cryptographic key, which is type II and is supplied along with the OS image, the owner of which is the owner (manufacturer/supplier) of the OS.

[135] In FIG. 2 shows the main elements included in the trusted device boot system 100.

[136] The main blocks that make up the trusted device boot system: an isolated security domain, a main processor, an interaction interface through which the isolated security domain and the main processor exchange data, including for working with key information: the hash sum of the cryptographic key , forming the root of trust, located in once-programmable memory (OPM), through an interaction interface.

[137] The trusted boot process begins on an isolated security domain that implements a root of trust consisting of:

[138] - OPP block containing the cryptographic key for verifying the program code of the isolated security domain and

[139] - code in ROM memory of an isolated security domain that checks program code.

[140] If the program code is successfully verified, control is transferred to it.

[141] The security domain software code implements the function of managing type I cryptographic keys, which are also located in the OPP block.

[142] The security domain code is located in non-volatile memory and is the first in the boot loader hierarchy.

[143] The security domain code loads the next boot loader from the hierarchy into RAM and verifies it using image service information containing cryptographic keys and a signature.

[144] The validity of a cryptographic key is determined based on the cryptographic key information contained in the RPP.

[145] If the check is successful, control is transferred to the main processor of this bootloader.

[146] Bootloader 0 loads the next bootloader in the hierarchy from non-volatile memory into RAM, and then accesses the security domain code through the interaction interface to determine the validity of the cryptographic key contained in the bootloader image.

[147] If the cryptographic key is valid, then the image signature is verified. If the check is successful, control is transferred to the next Loader.

Examples of implementation

[148] Below we provide specific examples of the functioning of the trusted device boot procedure.

[149] In FIG. Figure 4 presents an implementation option for verifying the authenticity of an OS image with three owners of cryptographic keys.

[150] Vendor SVT - releases a device with a root of trust, generates a root cryptographic key (also known as the first stage cryptographic key, SCP key) and signs the security domain program code image (SCP_Loader) with it.

[151] The code in the isolated security domain ROM area verifies the security domain program code using the root cryptographic key.

[152] SDZ vendor releases a set of loaders (AP_Blxx), generates one or more intermediate stage cryptographic keys (vendor key 0 - vendor key 2) and signs the set of loaders with it.

[153] The first cryptographic key of the intermediate stage (vendor key 0) is signed by the root cryptographic key (SCP key) when entered into immutable memory (in a particular case, into the OPP).

[154] Subsequently, the entry of subsequent cryptographic keys (vendor key 1, vendor key 2) of the intermediate stage is certified by the active cryptographic key of the intermediate stage (vendor key 0 and/or vendor key 1). The removal of a cryptographic key from circulation is similarly verified.

[155] The security domain code verifies the first bootloader in the hierarchy using the active middleware cryptographic key (vendor key x).

[156] Similarly, each subsequent loader in the hierarchy is verified by the previous loader using the active cryptographic key of the intermediate stage (vendor key x).

[157] OS vendor - releases an OS image, generates a last-stage cryptographic key (Image0 key) and signs the OS image with it.

[158] The last-stage cryptographic key is signed by the active intermediate-stage cryptographic key (vendor key x), generating a digital certificate that accompanies the OS image.

[159] The last boot loader in the hierarchy (AP_BL33) verifies the OS image using a digital certificate and an active middle stage cryptographic key.

[160] Each participant can combine several or even all roles: SVT vendor, SDZ and OS.

[161] In a particular case, the hardware-software verification tool verifies the first bootloader in the hierarchy using the active cryptographic key of the intermediate stage (vendor key x).

[162] In FIG. Figure 5 presents an implementation option for the stage of entering the hash amount of the primary cryptographic key of the root of trust for the program code of the main processor.

[163] Adding a hash of the primary cryptographic key of the root of trust for the main processor code consists of at least the following steps:

[164] First, the cryptographic key of the primary key of the root of trust of the program code of the main processor (Vendor-root key) is generated;

[165] Next, the owner of the cryptographic key of the root of trust of the isolated security domain (SecurityDomain cryptographic key): certifies the hash sum of the public part of the Vendor-root with an electronic signature of the SecurityDomain cryptographic key;

[166] A command is given to enter the cryptographic trust key of the program code of the main processor, the public part of Vendor-root;

[167] The electronic signature hash sum of Vendor-root is checked based on the SecurityDomain cryptographic key previously entered into the one-time programmable memory;

[168] Upon successful verification, the Vendor-root hash sum is entered into immutable memory (in a particular case, into the OPP).

[169] In the case when a computer with two or more processors is loaded, cryptographic keys are generated for each of the processors, verification occurs directly on each of the processors, and the loading process is successful if each of the processors successfully passes the electronic signature verification.

[170] In FIG. Figure 6 shows an implementation option for the stage of entering hash sums of additional cryptographic keys of the root of trust for the program code of the main processor.

[171] The step of adding hashes of additional cryptographic root of trust keys for the main processor code consists of at least the following:

[172] A cryptographic key of the root of trust of the program code of the main processor is generated (cryptographic key Vendor-key-N);

[173] The owner of the cryptographic key of the root Vendor-X-Y, which is in circulation: certifies the hash sum of the public part of Vendor-key-N with an electronic signature with the cryptographic key Vendor-X-Y;

[174] A command is given to enter the cryptographic key of the root of trust of the program code of the main processor - the public part of Vendor-key-N;

[175] The electronic signature of the hash sum Vendor-key-N is checked based on the cryptographic key Vendor-X-Y previously entered into immutable memory (in a particular case, in the OPP), and not taken out of circulation;

[176] If the check is successful, the Vendor-key-N hash sum is entered into immutable memory (in a particular case, into the OPP).

[177] In FIG. 7 presents an implementation option for the stage of removing the hash sum of the cryptographic key of the root of trust for the program code of the main processor from circulation.

[178] The step of retiring the hash of the cryptographic root of trust key for the host processor code consists of at least the following:

[179] Outside the device:

[180] A request is generated to withdraw from circulation the cryptographic key of the root of trust of the program code of the main processor (cryptographic key Vendor-key-M);

[181] The owner of the cryptographic key of the root Vendor-X-Y, which is in circulation: certifies the set of hash sums [of the public part of Vendor-X-Y, Vendor-key-M] with an electronic signature with the cryptographic key Vendor-X-Y;

[182] On the device:

[183] A command is given to remove from circulation the cryptographic key of the root of trust of the program code of the main processor - the public part of Vendor-key-M;

[184] The electronic signature of the request is checked based on the Vendor-X-Y cryptographic key previously entered into immutable memory (in a particular case, in the OPP), and not taken out of circulation;

[185] If the check is successful, the Vendor-key-M hash sum is marked in non-volatile memory (in a particular case, in the OPP) as invalid by burning the control bit.

[186] In FIG. 8 illustrates an exemplary implementation of a computer system in accordance with some embodiments of the present invention.

[187] A computer system may be connected (eg, via a network) to other computer systems on a local area network, intranet, extranet, or the Internet. A computer system can operate as a server in a client-server network environment. The computer system may be a personal computer (PC), tablet computer, set-top box (STB), personal digital assistant (PDA), mobile phone, or any device capable of executing a set of instructions (sequential or otherwise) specifying actions to be performed by it. device. In addition, although only one computer system is illustrated, the term “computer” should also be understood to mean any collection of computers that individually or collectively execute a set (or more sets) of instructions to perform any one or more of the methods described herein.

[188] An exemplary computer system 400 consists of a data processing device 402, a random access memory 404 (e.g., read-only memory (ROM), dynamic random access memory (DRAM), such as synchronous dynamic random access memory (SDRAM)), and storage devices 408 that communicate with each other via bus 422.

[189] Processing device 402 is one or more general purpose processing devices such as a microprocessor, central processing unit, or the like. Processing device 402 may be a full instruction set microprocessor (CISC), a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets.

[190] Processing device 402 may also be one or more special purpose processing devices, such as an application specific integrated circuit (ASIC), field programmable gate array (FPGA), digital signal processor (DSP), network processor, etc. The data processing apparatus 402 is configured to execute instructions 430 to carry out steps of method 200 and system 100 for performing trusted booting of a device with a mechanism for sharing the functions of authenticating boot steps among multiple cryptographic key owners, as well as for performing any of the operations described above.

[191] The computer system 400 may further include a network interface 406, a visual display device 412 (eg, a liquid crystal display), an alphanumeric input device 414 (eg, a keyboard), a cursor control device 416, and an input device 418. In one embodiment In an implementation, the visual display device 412, the alphanumeric input device 414, and the cursor control device 416 may be combined into a single component or device (eg, a touchscreen liquid crystal display).

[192] The external input device 418 is one or more devices or sensors for receiving external input. The device for receiving external influence can be, for example, a video camera, microphone, touch sensor, etc.

[193] The storage device 408 may include a computer-readable storage medium 410 storing instructions 430 embodying any one or more of the techniques or functions described herein (method 200). Instructions 430 may also reside entirely or at least partially in main memory 404 and/or processing device 402 while they are executed by computer system 400. Main memory 404 and processing device 402 are also computer-readable storage media. In some implementations, instructions 430 may optionally be sent or received over network 420 via network interface device 406.

[194] Although computer readable media 410 is referred to in the singular in illustrative examples, the term “computer readable media” should be understood to include one or more media (e.g., a centralized or distributed database and/or associated caches and servers) that store one or more sets of instructions. The term “machine-readable medium” should also be understood to include any medium capable of storing, encoding, or carrying a set of instructions for execution by a machine and causing the machine to perform any one or more of the techniques of the present invention. Therefore, the term "computer readable medium" shall include, but is not limited to, solid state storage devices, optical storage media, and magnetic storage media.

[195] Although the operations of the methods described herein are shown and described in a particular order, the order of the operations of each method may be reversed so that certain operations can be performed in reverse order or so that certain operations can be performed at least partially simultaneously with other operations. In some implementations, instructions or sub-operations of individual operations may be intermittent and/or interleaved.

[196] It should be understood that the above description is illustrative and not restrictive. Many other embodiments will become apparent to those skilled in the art after reading and understanding the foregoing description. Therefore, the scope of the invention is determined by reference to the appended claims, as well as to the full scope of equivalents to which such claims are entitled to make claims.

[197] The above description sets forth numerous details. However, it will be apparent to one skilled in the art that aspects of the present invention may be practiced without these specific details. In some cases, to avoid making the present invention difficult to understand, well-known structures and devices are presented in block diagram form rather than in detail.

[198] It should be noted that, in the absence of other specific indications, as will be apparent from the following discussion, throughout the specification, terms in discussion such as “acquisition,” “determination,” “selection,” “storage,” “analysis,” and etc., refer to the actions and processes of a computer system or similar electronic computing device that manipulates data and converts data represented as physical (electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory or registers of a computer system or other such devices for storing, transmitting or displaying information.

[199] The present invention also relates to an apparatus for performing the operations described herein. The device may be specifically designed for the required purpose or may comprise a general purpose computer that is selectively activated or reconfigurable by a computer program stored in the computer. Such a computer program may be stored on a computer-readable storage medium, such as any type of disk, including floppy disks, optical disks, compact disks and magnetic-optical disks, read-only memory (ROM), random access memory (RAM), programmable read-only memory (ROM). EPROM), electronically reprogrammable read-only memory (EEPROM), magnetic or optical cards, or any type of media suitable for storing electronic instructions, each connected to a computer system bus.

[200] The algorithms presented herein are not inherently associated with a specific computer or other device. Various general purpose systems may be used with programs in accordance with the provisions herein, or it may be more convenient to create a more specialized device to perform the required method steps. The required structure for a variety of such systems will look like the description. Moreover, aspects of the present invention are not described with reference to a specific programming language. It should be understood that various programming languages may be used to implement the teachings of the present invention, as described herein.

[201] Embodiments of the present invention may be in the form of a software product or software including a computer-readable medium having instructions stored thereon that can be used to program a computer system (or other electronic devices) to perform a process in accordance with the present invention. Machine-readable media includes any mechanism for storing or transmitting information in a machine-readable form (such as a computer). For example, machine-readable (e.g., computer-readable) media includes machine-readable (e.g., computer-readable) storage media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash devices memory).

[202] The words “example” or “exemplified” as used herein mean example, instance, or illustration. Any aspect or solution described herein as an “example” or “given by way of example” should not necessarily be construed as preferable or superior to other aspects or solutions. Rather, the use of the words "example" or "exemplified" is intended to present concepts from a practical perspective. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. Additionally, use of the term “implementation,” “one embodiment,” “example implementation,” or “one example implementation” throughout the text does not imply the same embodiment or example implementation unless described as such. In addition, the terms “first”, “second”, “third”, “fourth” and the like as used herein are intended to designate different elements and do not necessarily have an ordinal meaning in accordance with their numerical designation.

[203] While many changes and modifications of the invention will no doubt become apparent to one of ordinary skill in the art, it should be understood from reading the foregoing description that any particular embodiment shown and described by way of illustration is in no way should not be seen as limiting.

[204] Therefore, references to details of various embodiments are not intended to limit the scope of the claims, which themselves contain only features considered to be the disclosure of the invention.

Claims (60)

1. A method for trusted device booting with the ability to certify different boot stages by several independent key owners includes the following steps: loading an electronic computer (computer) containing at least one processor executing bootloader code and an OS image, read-only memory (ROM), code in the processor ROM, one-time programmable memory (OPM), non-volatile memory, Moreover, the loading consists of N stages, in which we can distinguish the first, (N-2) intermediate stages and the last stage; form a hierarchy of loaders that are stored in non-volatile memory, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private key of the pair is used during certification, and the public key is used when verifying certification, where public cryptographic keys can be: located in non-volatile memory (type I) or placed in volatile memory in the form of a digital certificate (type II), and at each stage keys belonging to different owners can be used for certification, the first key of the first stage is entered in an exclusively trusted way into immutable memory, and the remaining keys of type I of the first stage, type I keys of the intermediate and final stages can be entered in a certified container containing an electronic signature, which is verified only upon entry; when a cryptographic key is entered into a stage, it becomes the root of trust for this and subsequent stages; at least one bootloader in the bootloader hierarchy is loaded from non-volatile memory into RAM, this bootloader is checked, the validity of the key contained in the bootloader image is determined, and the validity of the key is determined based on the information about the keys contained in the OPP, in response to the fact that the key is valid, the image signature is checked; if the verification is successful, control is transferred to such a bootloader; parsing the image of the next at least one loader, using the previous loader, by reading its signature and public key, calculating the hash of this key and checking the presence of such a hash in the OPP, in response to the hash not being found, the authentication fails, in response to the fact that the hash is found in the OPP, they check whether the revocation sign of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered failed, in response to the fact that the key is in circulation, the image signature on the public key is verified; if the signature verification fails, the authentication is considered failed, in response to the fact that the signature verification was completed successfully, control is transferred to the verified at least the next loader in the loader hierarchy, in response to the authentication failure, the download process is terminated; verifying each at least the next loader in the hierarchy of loaders with the help of the previous loader using the active key of the intermediate stage; releasing an OS image signed with the final stage key, wherein the final stage key is signed by the active intermediate stage key, generating a digital certificate that accompanies the OS image; Verify the OS image using a digital certificate and an active staging key. 2. The method according to claim 1, characterized in that the first key of the first stage can be the only root of trust for this and subsequent stages. 3. The method according to claim 1, characterized in that each stage can have its own cryptographic key, which is the root of trust for this stage. 4. The method according to claim 1, characterized in that checking the bootloader in the bootloader hierarchy can be carried out by hardware and software. 5. The method according to claim 1, characterized in that the keys can be recorded in a compressed or full representation. 6. The method according to claim 5, characterized in that type I keys can be in two states: active - active or retired - inactive, while the transition between states is possible only from the active to inactive state. 7. The method according to claim 6, characterized in that type II keys are supplied in a digital certificate, which is certified by a type I or II key of the previous level, while type II keys do not have the ability to certify keys of the same level at which they themselves are located. 8. A trusted device boot system with the ability to certify different boot stages by several independent key owners, containing two isolated modules for executing program code located on a processor chip - an isolated security domain and at least one main processor executing boot loader code, an OS image, and permanent storage device (ROM), code in the processor ROM, one-time programmable memory (OPM), non-volatile memory, while the boot contains N stages: in which the first can be distinguished, (N-2) - intermediate stages and the last stage, and at each stage for certification, keys belonging to different owners can be used, where the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining type I keys of the first stage, type I keys of the intermediate and last stages can be entered in a certified container containing an electronic signature, which checked only when deposited; the isolated security domain and the main processor are configured to exchange data, including for working with key information: the hash sum of the key that forms the root of trust, located in once-programmable memory (OPM) through the interaction interface; non-volatile memory is configured to store a hierarchy of loaders, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, wherein the private key of the pair is used during certification, and the public key is used when verifying certification, where public cryptographic keys can be located in non-volatile memory (type I) or placed in the form of a digital certificate (type II); the RAM is configured to load at least one bootloader in the hierarchy of bootloaders from non-volatile memory, the isolated security domain contains program code, which is accessed to check this bootloader with hardware through the interaction interface between the isolated security domain and the processor, determining the validity of the key, which is contained in the bootloader image, while the OPP contains information about the keys, which is intended to determine the validity of the key, the bootloader is configured to transfer control to it if it is successfully verified, during which, in response to the fact that the key is valid, the image signature is verified; the image of the next at least one loader is configured to be parsed by the previous loader by reading its signature and public key, the hash of this key is calculated and the presence of such a hash in the OPP is checked, in response to the hash not being found, the authentication fails, in response to the fact that the hash is found in the OPP, they check whether the revocation sign of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered failed, in response to the fact that the key is in circulation, the image signature on the public key is verified; if the signature verification fails, the authentication is considered failed, the verified at least next loader from the loader hierarchy is configured to transfer control to it in response to the fact that the signature verification has completed successfully, in response to the authentication failure, the download process is terminated; the previous bootloader is configured to verify each at least the next bootloader in the bootloader hierarchy using the active intermediate stage key; the OS image contains a digital certificate generated and signed by the last stage key, where the last stage key is signed by the active key of the intermediate stage; The OS image is verifiable using a digital certificate and an active middle stage key. 9. The system according to claim 8, characterized in that checking the bootloader in the bootloader hierarchy can be carried out by hardware and software. 10. The system according to claim 8, characterized in that the keys can be recorded in a compressed or full representation. 11. The system according to claim 10, characterized in that type I keys can be in two states: active - active or retired - inactive, while the transition between states is possible only from the active to inactive state. 12. The system according to claim 11, characterized in that type II keys are supplied in a digital certificate, which is certified by a type I or II key of the previous level, while type II keys do not have the ability to certify keys of the same level at which they themselves are located. 13. A permanent machine-readable storage medium containing machine-readable instructions executed by a computer processor and intended for executing a method of trusted device booting with a mechanism for dividing the functions of certifying boot stages between several key owners, in which two isolated program code execution modules are located on the processor chip - an isolated security domain and the main processor executing bootloader code, an OS image, one-time programmable memory (OPM), non-volatile memory, while the boot contains N stages, containing stages in which: we can distinguish the first, (N-2) – intermediate stages and the last stage; at each stage, keys belonging to different owners can be used for authentication, where the first key of the first stage is entered in an exclusively trusted manner into immutable memory, and the remaining type I keys of the first stage, keys of type I of the intermediate and last stages can be entered in a certified container containing an electronic signature, which is verified only upon entry; using the main processor, they access the isolated security domain through an interaction interface for working with key information: the hash sum of the key that forms the root of trust, located in once-programmable memory (OPM); form a hierarchy of loaders that are stored in non-volatile memory, where each loading stage corresponds to one or more pairs of asymmetric cryptographic keys, where the private key of the pair is used during certification, and the public key is used when verifying certification, where public cryptographic keys can be: located in non-volatile memory (Type I) or posted as a digital certificate (Type II); loading at least one bootloader in the hierarchy of bootloaders from non-volatile memory into RAM, checking this bootloader with hardware, accessing the program code of the isolated security domain through the interaction interface between the isolated security domain and the processor, determining the validity of the key contained in the bootloader image , while the validity of the key is determined based on the information about the keys contained in the OPP, in response to the fact that the key is valid, the image signature is checked; if the verification is successful, control is transferred to such a bootloader; parsing the image of the next at least one loader using the previous loader by reading its signature and public key, calculating the hash of this key and checking the presence of such a hash in the OPP, in response to the fact that the hash is not found, the authentication is considered to be failed, in response to the fact that the hash is found in the OPP, they check whether the revocation sign of this key is set in the OPP; in response to the fact that the key is revoked, the authentication is considered to have failed, in response to the fact that the key is in circulation, the image signature on the public key is verified; if the signature verification fails, the authentication is considered failed, in response to the fact that the signature verification was completed successfully, control is transferred to the verified at least the next loader in the loader hierarchy, in response to the authentication failure, the download process is terminated; verifying each at least the next loader in the hierarchy of loaders with the help of the previous loader using the active key of the intermediate stage; releasing an OS image signed with the final stage key, wherein the final stage key is signed by the active intermediate stage key, generating a digital certificate that accompanies the OS image; Verify the OS image using a digital certificate and an active staging key. 14. A permanent machine-readable medium according to claim 13, characterized in that the keys can be recorded in a compressed or full representation. 15. A permanent machine-readable medium according to claim 14, characterized in that type I keys can be in two states: active - active or retired - inactive, while the transition between states is possible only from the active to inactive state. 16. A permanent machine-readable medium according to claim 15, characterized in that type II keys are supplied in a digital certificate, which is certified by a type I or II key of the previous level, while type II keys do not have the ability to certify keys of the same level at which they themselves are located .