Apparatus and method for securely managing keys

Abstract

An integrated circuit, system, and method performed by the integrated circuit are provided. The integrated circuit includes a system memory, a secure processor, and a non-secure processor. Attacks on the integrated circuit become more difficult based on use of a key generated by the secure processor. As an example, the secure processor reads a program image from the system memory and generates the key based on the program image. In some cases, a dedicated communication channel is provided for communication between the non-secure processor and the secure processor. The dedicated communication channel can be used to provide the key to the non-secure processor to perform secure operations.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Korean Patent Application No. 10-2020-0002692, filed on January 8, 2020, with the Korean Intellectual Property Office, the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] The embodiments disclosed herein relate to data security, and more specifically, to devices and methods for securely managing keys used for data security. Background Technology

[0004] In data security, both software and hardware can be used together to protect data from advanced external attacks. In data security, keys are used to encrypt or decrypt data; therefore, decrypting data using a different key than the valid key (i.e., a different key than the one used for encryption) can be difficult. Therefore, secure key management is essential in data security to resist external attacks. Summary of the Invention

[0005] This application provides an apparatus and method for securely managing keys used for data security by using a security processor to prevent external attacks.

[0006] This document provides an integrated circuit, comprising: a first processor configured to execute a first program image to perform a security operation, the first program image being stored in a system memory; a second processor configured to read at least a portion of a second program image and generate a key based on at least a portion of the second program image, the second program image being stored in the system memory; and a dedicated communication channel for communication between the first processor and the second processor, wherein the first processor is further configured to receive the key through the dedicated communication channel and perform a security operation based on the key.

[0007] This document also provides a system comprising: an integrated circuit including a first processor and a second processor, wherein the first processor and the second processor are configured to communicate with each other via a dedicated communication channel; a system memory configured to store a program image executable by the first processor; and a non-volatile memory, wherein the non-volatile memory is exclusively accessible by the second processor and is configured to store loading information of the program image, wherein the second processor is further configured to: read at least a portion of the program image from the system memory based on the loading information, generate a key based on at least a portion of the program image, and provide the key to the first processor, and the first processor is further configured to perform a security operation based on the key.

[0008] This document provides a method executed by an integrated circuit including a first processor and a second processor, the method comprising: the second processor reading at least a portion of a program image from system memory, the program image being executed by the first processor; the second processor generating a key based on at least a portion of the program image; and the first processor performing a security operation based on the key. Attached Figure Description

[0009] The embodiments of this disclosure will become clearer from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0010] Figure 1 This is a block diagram illustrating an example of a system according to an example embodiment;

[0011] Figure 2 This is a diagram illustrating an example of a method for securely managing keys according to an example embodiment;

[0012] Figure 3 This is a block diagram illustrating an example of a security processor according to an example embodiment;

[0013] Figure 4 An example of a system memory according to an example embodiment of a stored program image is shown;

[0014] Figure 5A and Figure 5B These are diagrams illustrating examples of information for key generation according to exemplary embodiments;

[0015] Figure 6A and Figure 6B These are flowcharts illustrating examples of methods for securely managing keys according to exemplary embodiments;

[0016] Figure 7A and Figure 7B These are flowcharts illustrating examples of methods for securely managing keys according to exemplary embodiments;

[0017] Figure 8 This is a diagram illustrating an example of a method for securely managing keys according to an example embodiment;

[0018] Figure 9 This is a block diagram illustrating an example of an integrated circuit according to an exemplary embodiment;

[0019] Figure 10 This is a block diagram illustrating an example of an integrated circuit according to an exemplary embodiment;

[0020] Figure 11 This is a flowchart illustrating an example method for securely managing keys according to an example embodiment; and

[0021] Figure 12This is a block diagram illustrating an example of a system according to an example embodiment. Detailed Implementation

[0022] Figure 1 This is a block diagram illustrating an example of a system according to an exemplary embodiment. In some embodiments, system 10 may include, but is not limited to, a fixed computing system or a subsystem thereof, such as a server, desktop computer, or kiosk. In some embodiments, system 10 may include, but is not limited to, a portable computing system or a subsystem thereof, such as a mobile phone, wearable device, or laptop computer. In some embodiments, system 10 may include, but is not limited to, subsystems included in a system different from a standalone computing system, such as home appliances, industrial equipment, or vehicles. Figure 1 As shown, system 10 may include integrated circuit 12, system memory 14, secure non-volatile memory 16, and system storage 18.

[0023] Integrated circuit 12 may include a non-secure processor 12_2 and a secure processor 12_4. Here, the non-secure processor 12_2 may be referred to as a first processor, and the secure processor 12_4 may be referred to as a second processor. Integrated circuit 12 may be manufactured using semiconductor processes, and in some embodiments, the non-secure processor 12_2 and the secure processor 12_4 may be integrated into a single chip or wafer. In some embodiments, integrated circuit 12 may be included in the same package as at least one of the other components of system 10 (i.e., system memory 14, secure non-volatile memory 16, and system memory 18). Additionally, in some embodiments, integrated circuit 12 may be mounted on a board and may communicate with at least one of the other components mounted on the board (i.e., system memory 14, secure non-volatile memory 16, and system memory 18) via patterns formed on the board.

[0024] The non-secure processor 12_2 can communicate with system memory 14 and execute a program image, that is, it can execute a series of instructions included in the program image stored in system memory 14. For example, integrated circuit 12 may include components for providing access to system memory 14 (e.g., Figure 12 The insecure processor 12_2 may include at least one core capable of executing instructions (122_5 and / or 122_4 in the program image), and the insecure processor 12_2 may include at least one core capable of executing instructions. Here, the statement that the insecure processor 12_2 performs an operation by executing instructions included in the program image can be simply expressed as: the insecure processor 12_2 or the program image performs the operation. Secure operations may be, for example, data encryption for confidentiality or the generation of signatures for data integrity.

[0025] For data security, the secure processor 12_4 may be included together with the non-secure processor 12_2 in the integrated circuit 12. System 10 can process data requiring security for various purposes. For example, system 10 can securely process unique information relating to the user of system 10, and can securely process unique information relating to the manufacturer or legitimate supplier of system 10. Data requiring security can be encrypted using a key, and encrypted data can be decrypted and used using the same key, and then encrypted again. Data can be encrypted and decrypted based on any cryptographic algorithm. In some embodiments, data can be encrypted and decrypted using symmetric-key cryptographic algorithms such as Data Encryption Standard (DES) or Advanced Encryption Standard (AES), or public-key cryptographic algorithms such as Rivest-Shamir-Adleman (RSA) or elliptic curve cryptography.

[0026] To enhance the security of data requiring security and / or keys (or secret keys) used for cryptographic algorithms, the security processor 12_4 may be formed in an area physically isolated from other components of the integrated circuit 12 (e.g., the non-security processor 12_2). The security processor 12_4 may include components inaccessible to other components of the integrated circuit 12 and can operate independently. For example, a security program (or security software) executed by the non-security processor 12_2 may also be restricted in its access to components included in the security processor 12_4. Therefore, the security processor 12_4 can significantly improve the security level of the system 10. Figure 1 As shown, the secure processor 12_4 can communicate with the non-secure processor 12_2 via a dedicated physical bus 12_6, which serves as a dedicated communication channel, and can exclusively access the secure non-volatile memory 16. In some embodiments, exclusive access means that the non-secure processor 12_2 cannot directly access the data in the secure non-volatile memory 16. Furthermore, as... Figure 1 As shown, the security processor 12_4 can read data stored in system memory 14, such as a program image. In some embodiments, similar to the non-security processor 12_2, the security processor 12_4 may include at least one kernel capable of executing a series of instructions. Reference will be made below. Figure 3 An example describing security processor 12_4.

[0027] The security processor 12_4 can generate keys used by the program image executed by the non-security processor 12_2, and can provide the keys to the non-security processor 12_2. For example, the security processor 12_4 can generate keys for encrypting or decrypting user identification information used to identify users of system 10, and can provide these keys to the non-security processor 12_2. Additionally, the security processor 12_4 can generate keys for encrypting or decrypting user identification information used for software updates of system 10, and can provide these keys to the non-security processor 12_2. Here, the operation of using keys for data security can be referred to as a security operation, and the program image executed by the non-security processor 12_2 to perform the security operation can be referred to as a security program, security application, or security software.

[0028] The security processor 12_4 can perform binding of the key provided to the non-security processor 12_2. The term "binding" as used herein refers to a key that depends on specific conditions (i.e., binding information), and keys generated based on different binding information can be different from each other. Therefore, keys generated that depend on unique binding information enhance data security. When based on information unique to system 10 or integrated circuit 12 as binding information (e.g., ... Figure 9 KEY in HW While generating the key prevents data encrypted by System 10 from being decrypted by another system, there is a risk that the bound key could be reused by a hacking program running on System 10. Therefore, the binding information may need to include information unique to the secure program, executed by the entity using the key (i.e., by the non-secure processor 12_2).

[0029] As described below with reference to the accompanying drawings, the security processor 12_4 can read at least a portion of the program image from the system memory 14 and can generate a key based on at least the read portion of the program image. That is, the security processor 12_4 can directly generate binding information based on at least a portion of the program image stored in the system memory 14. Therefore, the risk of exposing binding information can be eliminated when the non-security processor 12_2 obtains or generates binding information, or when the non-security processor 12_2 provides binding information to the security processor 12_4. Furthermore, when at least a portion of the program image is altered due to improper attempts such as hacking, the security processor 12_4 can generate modified binding information, thus generating different keys and maintaining data security.

[0030] System memory 14 may store at least one program image executable by the non-secure processor 12_2. In some embodiments, system memory 14 may include, but is not limited to, volatile memory devices such as dynamic random access memory (DRAM) or static random access memory (SRAM). In some embodiments, system memory 14 may include, but is not limited to, non-volatile memory devices such as flash memory, electrically erasable programmable read-only memory (EEPROM), silicon oxynitride-silicon oxide (SONOS) memory, polymer memory, magnetic random access memory (MRAM), phase-change random access memory (PRAM), or resistive random access memory (RRAM).

[0031] The program image may include a set of instructions executable by the non-secure processor 12_2. For example, such as Figure 1 As shown, system memory 14 can store a bootloader BL, an operating system OS, and applications APP1 and APP2 as a program image. The bootloader BL can be executed by the insecure processor 12_2, thereby loading the program image (e.g., the OS) to be executed subsequently into system memory 14. The operating system OS provides drivers for the hardware included in system 10 and can perform management of applications APP1 and APP2, such as installation, deletion, or scheduling. The program image can also be referred to as a software image, a binary image, or a binary program image, and will be described below with reference to... Figure 4 An example structure describing a program image.

[0032] The secure non-volatile memory 16 can be exclusively accessed by the secure processor 12_4, and the secure non-volatile memory 16 and the secure processor 12_4 can communicate with each other through a secure channel. In some embodiments, the secure processor 12_4 can write data encrypted therein to the secure non-volatile memory 16 and can decrypt data read from the secure non-volatile memory 16. In some embodiments, the secure non-volatile memory 16 can store a program image executed by the secure processor 12_4. In some embodiments, the secure non-volatile memory 16 can store information required by the secure processor 12_4 to generate keys. The secure non-volatile memory 16 may include at least one non-volatile memory device, and references will be made below. Figure 5A An example describing a secure non-volatile memory 16.

[0033] Even when the power supply to system storage 18 is interrupted, system storage 18 will not lose the data stored therein. For example, system storage 18 may include a non-volatile memory device and may also include storage media such as magnetic tape, disk, or optical disk. System storage 18 may communicate with non-secure processor 12_2, and integrated circuit 12 may include components that provide access to system storage 18 (e.g., Figure 12 (122_6 in the example). For example, the non-secure processor 12_2 can process data stored in system memory 18, store data in system memory 18, and load program images stored in system memory 18 into system memory 14.

[0034] Figure 2 This is a diagram illustrating an example of a method for securely managing keys according to an example embodiment. Specifically, Figure 2 The operation of both the non-secure processor 22 and the secure processor 24 over time is shown.

[0035] In operation S10, the non-secure processor 22 can access the first program image. For example, the non-secure processor 22 can access the system memory 26 storing the first program image and can copy at least some instructions included in the first program image to memory included in the non-secure processor 22, such as a cache. The first program image may be a program image executed by the non-secure processor 22 and thus performing secure operations using a key for data security, and may be referred to as a secure program, secure application, or secure software.

[0036] In operation S20, the non-secure processor 22 can execute the first program image. For example, the non-secure processor 22 can execute a series of instructions to copy to the cache, thus initiating the execution of the first program image.

[0037] In operation S30, the insecure processor 22 may request a key from the secure processor 24. For example, the insecure processor 22 may request a key for encrypting, decrypting, etc., data during the execution of the first program image, and thus this can be done via a dedicated physical bus or mailbox (e.g., Figure 1 In step 12_6), a request for a key is made to the security processor 24. The mailbox may be implemented as a shared register with a first control flag set by a first chip or logic indicating that the first chip has written new data to be read by a second chip or logic. The second chip may periodically poll the first control flag, find that the control flag has been claimed, read the register, and clear the control flag. A second register may be provided in another direction to allow the second chip to act as a writer and to allow the first chip to poll the second control flag, and so on. In some embodiments, a request provided from the non-security processor 22 to the security processor 24 may include an identifier of a second program image, which will be read by the security processor 24 from the system memory 26 in subsequent operation S40, and based on the identifier of the second program image, the security processor 24 may obtain loading information related to the region of the system memory 26 in which the second program image is loaded. Additionally, in some embodiments, a request provided from the non-security processor 22 to the security processor 24 may include a key identifier (e.g., ...). Figure 9 ID in KEY For example, the first program image may use multiple keys, so in order to distinguish between the multiple keys, the non-secure processor 22 may include the key identifier in the request, and the secure processor 24 may generate a key that depends on the key identifier.

[0038] In operation S40, the security processor 24 may read at least a portion of the second program image from the system memory 26. For example, the security processor 24 may obtain loading information of the second program image in response to a request from the non-security processor 22, and may read at least a portion of the second program image by accessing the system memory 26 based on the loading information. In some embodiments, the second program image may be the same as the program image for which the key has been requested (i.e., the first program image), and in some embodiments, the second program image may also be different from the first program image. Reference will be made below. Figure 6A and Figure 6B Describe an example of operation S40.

[0039] In operation S50, the security processor 24 may generate a key. For example, the security processor 24 may generate a key based on at least a portion of a second program image read from system memory 26. In some embodiments, the security processor 24 may implement a key derivation function (KDF) and may generate a key by inputting binding information generated according to said at least a portion of the second program image into the KDF. In some embodiments, the security processor 24 may input additional information and binding information generated based on said at least a portion of the second program image into the KDF. For example, the security processor 24 may input a hardware key unique to the security processor 24 (e.g., Figure 9 KEY in HW ), key identifier (e.g., Figure 9 ID in KEY At least one of the identifiers of the first and second program images is input into the KDF. In some embodiments, the security processor 24 can also generate a key by encrypting the key output by the KDF. The following will refer to... Figure 7A and Figure 7B Describe an example of operation S50.

[0040] In operation S60, the security processor 24 can provide a key to the non-security processor 22. For example, the security processor 24 can do so via a dedicated physical bus or mailbox (e.g., Figure 1 In step 12_6), the key is provided to the insecure processor 22. Next, in operation S70, the insecure processor 22 can perform secure operations using the key. For example, the insecure processor 22 can encrypt or decrypt data using the key.

[0041] As described above, the security processor 24 can generate a key that depends on at least a portion of the second program image, which is read directly from the system memory 26 by the security processor 24. Therefore, when at least a portion of the second program image is modified, a different key can be generated than the key generated based on the original second program image, and data encrypted with the original key cannot be decrypted correctly using the key generated based on the modified second program image.

[0042] Figure 3 This is a block diagram illustrating an example of a security processor according to an example embodiment. Specifically, Figure 3 The block diagram shows system memory 34, secure non-volatile memory 36, non-secure processor 38, and secure processor 32. (Refer to the above...) Figure 1 The security processor 32 and the non-security processor 38 can be included in a single integrated circuit. (The following is about...) Figure 3 The description will omit the reference. Figure 1 The given description is repetitive.

[0043] Reference Figure 3 The security processor 32 may include at least one register 32_1, at least one core 32_2, a direct memory access (DMA) controller 32_3, a hardware (HW) accelerator 32_4, internal memory 32_5, and a non-volatile memory (NVM) controller 32_6. In some embodiments, the security processor 32 may include a bus connected to at least one register 32_1, at least one core 32_2, the DMA controller 32_3, the hardware accelerator 32_4, the internal memory 32_5, and the non-volatile memory controller 32_6. In some embodiments, the security processor 32 may also include a random number generator for generating key pairs, providing hardware keys (e.g., ...). Figure 9 KEY in HW Components, etc. Figure 3 As shown, the security processor 32 may include dedicated components for performing operations independently of other components of the integrated circuit (e.g., non-security processor 38). Here, the operations performed by each component included in the security processor 32 may be referred to as being performed by the security processor 32.

[0044] The insecure processor 38 can access at least one register 32_1. For example, the secure processor 32 can receive a request for a key from the insecure processor 38 via at least one register 32_1. Additionally, the secure processor 32 can store a generated key in at least one register 32_1, thereby providing the key to the insecure processor 38. In some embodiments, the at least one register 32_1 may be referred to as a mailbox or mailbox hardware. Furthermore, the at least one register 32_1 may also be referred to as being included in a dedicated physical bus for communicating with the insecure processor 38.

[0045] At least one kernel 32_2 can refer to any processing element configured to execute instructions. For example, at least one kernel 32_2 can perform at least a portion of the key generation operation by executing a series of instructions stored in internal memory 32_5. Here, a program image including instructions executed by at least one kernel 32_2 included in the security processor 32 can be referred to as security firmware or security firmware image.

[0046] The DMA controller 32_3 provides direct memory access (DMA) to the system memory 34. The DMA controller 32_3 can read program images stored in the system memory 34 (e.g., ...). Figure 2 At least a portion of the second program image in the integrated circuit. In some embodiments, the DMA controller 32_3 may be via a system memory controller (e.g., included in the integrated circuit) Figure 12 (122_5) Read the program image. In some embodiments, the DMA controller 32_3 may be configured to only perform operations to read the system memory 34 and may not support operations to write data to the system memory 34.

[0047] Hardware accelerator 32_4 can refer to hardware designed to perform predetermined operations at high speed and capable of performing at least a portion of the operations that generate a key. In some embodiments, hardware accelerator 32_4 may include a cryptographic engine. For example, the cryptographic engine may implement a hash function for generating a hash for at least a portion of a program image read from system memory 34, perform encryption and / or decryption of data, and verify a digital signature of the program image, as described below.

[0048] Internal memory 32_5 may store data required for the operation of security processor 32. In some embodiments, internal memory 32_5 may include ROM storing instructions executable by at least one core 32_2. Additionally, in some embodiments, internal memory 32_5 may include RAM having a security firmware image loaded therein or storing data processed by at least one core 32_2. Furthermore, internal memory 32_5 may store at least a portion of a program image read by DMA controller 32_3, and may also store data provided to or processed by hardware accelerator 32_4.

[0049] The non-volatile memory controller 32_6 provides access to the secure non-volatile memory 36. For example, the secure non-volatile memory 36 may include a flash memory device, and the non-volatile memory controller 32_6 may include a flash memory controller that provides a flash memory interface. Additionally, the secure non-volatile memory 36 may support a serial interface, and the non-volatile memory controller 32_6 may include a controller that provides, for example, a Universal Serial Interface (USI) such as Inter-Integrated Circuit (I2C) or Serial Peripheral Interface (SPI). (Refer to the above...) Figure 1 The non-volatile memory controller 32_6 and the secure non-volatile memory 36 can communicate with each other through a secure channel.

[0050] Figure 4 An example of system memory according to an example embodiment of a stored program image is shown. Figure 4 As shown, the system memory 40 can store a first program image IMG1, a second program image IMG2, and a third program image IMG3. In some embodiments, Figure 4 System memory 40 is Figure 1 An example of system memory 14. In some embodiments, a program image is a plurality of information bits located at a specific portion of the memory. For example, in some embodiments, a program image is a plurality of consecutive bytes or words in system memory 40. The program image stored in system memory 40 can change dynamically, and Figure 4 The state of system memory 40 at a specific point in time is shown. For example, system memory 40 can store three or more program images simultaneously, and at least some of the first program image IMG1, the second program image IMG2, and the third program image IMG3 can be invalidated from system memory 40 by loading a new program image. Referring below... Figure 1 Conduct on Figure 4 The description.

[0051] A program image can include binary data. For example, such as Figure 4As shown, the first program image IMG1 and the second program image IMG2 may each include binary data 41 and 43, respectively, and the third program image IMG3 may include only binary data 45. The binary data may include instructions executed by the non-secure processor 12_2, and may be generated, for example, by compiling source code written in a programming language. In some embodiments, the binary data may also include data referenced by the instructions and the instructions themselves. The binary data may also be referred to as a binary image, binary code, or binary code image.

[0052] In some embodiments, the program image may include a digital signature. For example, such as Figure 4 As shown, the first program image IMG1 and the second program image IMG2 may each include digital signatures 42 and 44. The digital signature (or electronic signature) can be used to determine the authenticity of the program image, that is, whether the program image was generated by an authenticated entity. For example, digital signature 42 can be used to determine the authenticity of the first program image IMG1, and digital signature 44 can be used to determine the authenticity of the second program image IMG2. The digital signature and verification information can be generated as a digest from a public source, and the digital signature can be verified using the verification information. For example, a key pair including a private key and a public key can be generated, and the digital signature can be generated from the private key, and the digital signature can be verified using the public key as verification information based on a mathematical algorithm.

[0053] The security processor 12_4 can determine the authentication of a program image by verifying a digital signature. To this end, the security processor 12_4 can obtain verification information and can verify the digital signature based on the verification information. In some embodiments, during the manufacturing of the integrated circuit 12 and / or system 10, a public key and / or a public key digest may be provided to the security processor 12_4 as verification information, and the security processor 12_4 can verify the digital signature based on the provided public key and / or the provided public key digest. Additionally, in some embodiments, the security processor 12_4 can also verify the digital signature based on a public key and / or a public key digest included in a software image that includes at least one key and is loaded into the system memory 40, such as a keychain image disclosed by the same applicant in Korean Patent Application No. 10-2020-0002691 entitled "Apparatus and Method for Software Authentication," filed with the Korean Intellectual Property Office on the same date as this application, the entire disclosure of which is incorporated herein by reference. A program image that has been verified with a digital signature (i.e., an authenticated program image) can be reliable, and the insecure processor 12_2 can execute the authenticated program image.

[0054] In some embodiments, as shown below Figure 8As described above, the security processor 12_4 can read digital signatures from the system memory 40 and can generate keys based on the digital signatures. For example, the security processor 12_4 can generate keys based on digital signatures included in a program image for which a key has been requested, and can also generate keys based on digital signatures included in a program image different from the program image for which a key has been requested.

[0055] In some embodiments, the program image may include a digital signature and key information as information relating to verification information used for verifying the digital signature. For example, as disclosed in Korean Patent Application No. 10-2020-0002691 entitled "Apparatus and Method for Software Authentication," the digital signature of the program image can be verified by a public key included in a software image loaded into system memory 40 and a public key included in a security processor 12_4, and the key information may include information relating to a public key used for verifying the digital signature included in the program image, which includes both the digital signature and key information.

[0056] Figure 5A and Figure 5B These are illustrations showing examples of information for key generation according to example embodiments. Specifically, Figure 5A and Figure 5B Examples of both program image loading information and digital signature verification information are shown below. Figure 5A and Figure 5B The description will refer to Figure 1 And repeated descriptions will be omitted.

[0057] Reference Figure 5A The secure non-volatile memory 50a can store loading information 52a of the program image and verification information 54a of the digital signature (the verification information may include a public key). In some embodiments, with Figure 5A Unlike the example shown, the security non-volatile memory 50a may store only one of the loading information 52a and the verification information 54a.

[0058] Load information 52a may include an identifier for the program image, along with its corresponding address and size. For example, such as... Figure 5AAs shown, load information 52a may include an identifier ID1 of a first program image and its corresponding first address ADDR1 and first size SIZE1, and the first program image may be stored in a region of system memory 14 starting from the first address ADDR1 and corresponding to the first size SIZE1. In some embodiments, ID1 is an example of an identifier for a program image. In some embodiments, the first size SIZE1 may be an address offset from the first address ADDR1 to the end address of the first program image. In some embodiments, load information 52a may include the end address of the first program image instead of the first size SIZE1. Similarly, load information 52a may include an identifier ID2 of a second program image and its corresponding second address ADDR2 and second size SIZE2. The security processor 12_4 may obtain from the security non-volatile memory 50a the address and size, both corresponding to the identifiers of the program images provided from the non-security processor 12_2.

[0059] Verification information 54a may include an identifier for the program image and its corresponding public key. For example, such as... Figure 5A As shown, the verification information 54a may include the identifier ID1 of the first program image and the corresponding first public key KEY1. pub And it can be accessed via the first public key KEY1 pub This is used to verify the digital signature included in the first program image. Similarly, verification information 54a may include the identifier ID2 of the second program image and the corresponding second public key KEY2. pub And it can be accessed via the second public key KEY2 pub To verify the digital signature included in the second program image. The secure processor 12_4 may be provided with an identifier of the program image from the insecure processor 12_2, and may obtain the public key corresponding to the provided identifier from the secure non-volatile memory 50a.

[0060] In some embodiments, the security processor 12_4 may obtain loading information 52a and / or verification information 54a from the non-security processor 12_2, and may write the loading information 52a and / or verification information 54a into the security non-volatile memory 50a. For example, the security processor 12_4 may write the loading information 52a and / or verification information 54a into the security non-volatile memory 50a in response to initial settings included in the system 10 during the manufacturing process of the system 10. As another example, the security processor 12_4 may write the loading information 52a and / or verification information 54a into the security non-volatile memory 50a in response to a master reset (or factory reset) of the system 10. As another example, in response to installing an application on the operating system, the security processor 12_4 may write both the loading information 52a and / or verification information 54a corresponding to the program image of the application into the security non-volatile memory 50a. Therefore, the security non-volatile memory 50a can store a security firmware image 50b, including loading information 52b of the program image and verification information 54b of the digital signature.

[0061] Reference Figure 5B The loading information 52b of the program image and the verification information 54b of the digital signature can be included in the security firmware image 50b executed by the security processor 12_4. The security firmware image 50b can be loaded from the security non-volatile memory 50a into the internal memory (e.g., Figure 3 (32_5 in some embodiments). Figure 5B Unlike the example shown, the security firmware image 50b may include only one of the loading information 52b and the verification information 54b. The security processor 12_4 may be provided with an identifier from the program image of the non-security processor 12_2, and may obtain the address and size corresponding to the provided identifier from the security firmware image 50b. Additionally, the security processor 12_4 may be provided with an identifier from the program image of the non-security processor 12_2, and may obtain the public key corresponding to the provided identifier from the security firmware image 50b.

[0062] Figure 6A and Figure 6B These are flowcharts illustrating examples of methods for securely managing keys according to exemplary embodiments. Specifically, Figure 6A and Figure 6B The flowcharts show respectively Figure 2 Example of operation S40. See above for reference. Figure 2 As mentioned above, in Figure 6A Operation S40a and Figure 6B In operation S40b, the security processor may perform the operation of reading at least a portion of the program image from system memory. In some embodiments, Figure 6A Operation S40a and Figure 6B The operation of S40b can be performed by Figure 1 The security processor 12_4 executes, and in the following about Figure 6A and Figure 6B The description will refer to Figure 1 And omit repeated descriptions.

[0063] Reference Figure 6A Operation S40a may include operations S42a and S44a. In operation S42a, an operation to obtain loading information of the program image may be performed. For example, the security processor 12_4 may obtain an identifier of the program image to be read from the system memory 14, and may obtain loading information corresponding to the obtained identifier from the security non-volatile memory 16 and / or the security firmware image.

[0064] In operation S44a, at least a portion of the program image can be read from system memory 14. For example, security processor 12_4 can read at least a portion of the program image from system memory 14 based on loading information obtained in operation S42a. In some embodiments, security processor 12_4 can read the entire program image or a portion of the program image. Additionally, security processor 12_4 can read digital signatures included in the program image.

[0065] Reference Figure 6B Similar to Figure 6A Operation S40a, operation S40b may include operations S42b and S44b, and operation S40b may also include operations S43b and S45b, which are executed before and after operation S44b, respectively. In some embodiments, operation S43b may be executed before operation S42b.

[0066] In operation S42b, the operation of obtaining loading information for the program image can be performed. Next, in operation S43b, the operation of locking access to the program image can be performed. For example, the security processor 12_4 can perform the operation of locking access to the program image so that the program image is not altered when it is read from system memory 14. In some embodiments, the security processor 12_4 can prevent access to system memory 14 by the non-security processor 12_2. Access to system memory 14 by the security processor 12_4 and the non-security processor 12_2 can be coordinated by a memory access controller. In some embodiments, Figure 12 The DRAM access controller 122_4 is an example of a memory access controller.

[0067] The blocking of memory access can be achieved by the security processor 12_4 cooperating with the memory access controller. In some embodiments, the security processor 12_4 can block access to the program image to be read by the non-security processor 12_2. For example, the security processor 12_4 can block access by setting a flag in the memory access controller or by providing an instruction to the memory access controller. Next, in operation S45b, the operation of reading at least a portion of the program image from the system memory 14 can be performed.

[0068] In operation S45b, operations that allow access to the program image can be performed. In some embodiments, the security processor 12_4 can unlock the non-security processor 12_2's access to the system memory 14. In some embodiments, the security processor 12_4 can unlock access to the program image made by the non-security processor 12_2.

[0069] Figure 7A and Figure 7B These are flowcharts illustrating examples of methods for securely managing keys according to exemplary embodiments. Specifically, Figure 7A and Figure 7B The flowcharts show respectively Figure 2 An example of operation S50. In some embodiments, Figure 2 Operation S50 may include Figure 7A Operation of S50a and Figure 7B The operation of S50b is the same for both. See above for reference. Figure 2 As mentioned above, in Figure 7A Operation of S50a and Figure 7B In operation S50b, a key generation operation can be performed. In some embodiments, Figure 7A Operation of S50a and Figure 7B The operation of S50b can be performed by Figure 1 The security processor 12_4 executes, and in the following about Figure 7A and Figure 7B The description will refer to Figure 1 And omit repeated descriptions.

[0070] Reference Figure 7A Operation S50a may include operations S51 and S52. In operation S51, an operation to generate a hash for at least a portion of the program image may be performed. The hash is the result of a hash function and may be referred to as a hash value, hash code, hash checksum, etc. A hash function may refer to a function used to map data of any length to data of a fixed length. The security processor 12_4 may implement the hash function and may generate a hash for at least a portion of the program image read from system memory 14. Therefore, the hash of the modified program image may be different from the hash of the original program image.

[0071] In operation S52, an operation to generate a key based on a hash can be performed. For example, the security processor 12_4 can input a hash into the KDF. That is, a hash of at least a portion of the program image can be used as binding information.

[0072] Reference Figure 7B Operation S50b may include multiple operations S53 to S55. In operation S53, an operation to obtain verification information for the digital signature may be performed. For example, the security processor 12_4 may obtain the information from the above reference... Figure 5A The security non-volatile memory 50a obtains verification information, which can also be obtained from the above reference. Figure 5B The security firmware image 50b obtained verification information.

[0073] In operation S54, the operation to verify the digital signature can be performed. For example, the security processor 12_4 can obtain the public key as the verification information in operation S53, and can verify the digital signature by using the public key. Therefore, the verification of the digital signature can succeed or fail depending on the authentication of the program image.

[0074] In operation S55, an operation to generate a key based on the verification result can be performed. For example, the security processor 12_4 can input the verification result from operation S54 into the KDF. Therefore, the key generated in the case of successful verification may be different from the key generated in the case of verification failure.

[0075] Figure 8 This is a diagram illustrating an example of a method for securely managing keys according to an example embodiment. Specifically, Figure 8 The operation of the insecure processor 82 and the secure processor 84 over time is illustrated. In some embodiments, the secure processor 84 may use the verification result of the program image when generating a key requested by another program image (i.e., a secure program). (The following is about...) Figure 8 In the description, repeated descriptions given with reference to the above-mentioned figures will be omitted.

[0076] In operation S81, the non-secure processor 82 can execute a boot program. The boot program can be executed during system initialization, for example, when the system, including the non-secure processor 82, the secure processor 84, and the system memory 86, is powered on or reset. In some embodiments, the boot program can be stored in a ROM included in the non-secure processor 82 (e.g., ...). Figure 12In operation S82, the insecure processor 82 can control the loading of the program image. For example, the insecure processor 82 can execute a bootloader to load at least one program image (e.g., an operating system, kernel, etc.) into the system memory 86. In operation S83, the insecure processor 82 can request the secure processor 84 to verify the digital signature. The at least one program image loaded by the bootloader may include a digital signature, and the insecure processor 82 can execute the bootloader to request verification of the digital signature included in the at least one program image loaded into the system memory 86.

[0077] In operation S84, the security processor 84 can read at least a portion of the program image from the system memory 86. For example, the security processor 84 can read a digital signature from the program image stored in the system memory 86. In operation S85, the security processor 84 can verify the digital signature and store the verification result. For example, the security processor 84 can store the verification result of the digital signature in internal memory (e.g., Figure 3 In step 32_5), during operation S86, the security processor 84 can provide the verification result to the non-security processor 82.

[0078] In operation S87, the security processor 84 can execute a security program. For example, a program image of the security program can be loaded into system memory 86, and the non-security processor 82 can begin executing the loaded program image. In operation S88, the non-security processor 82 can request a key from the security processor 84. For example, the non-security processor 82 can execute the security program, thereby requesting a key from the security processor 84.

[0079] In operation S89, the security processor 84 may generate a key based on the verification result of the digital signature. For example, the security processor 84 may input the verification result generated in operation S85 into the KDF. Therefore, the key may depend on the verification result of the digital signature requested for verification by the bootstrap. In some embodiments, the security processor 84 may also generate a key based on at least a portion of the program image of the security program read from system memory 86 and based on the verification result. In operation S90, the security processor 84 may provide the key to the non-security processor 82.

[0080] Figure 9 This is a block diagram illustrating an example of an integrated circuit according to an exemplary embodiment. Specifically, Figure 9 The block diagram illustrates an example of the key generation operation performed by the security processor 94. (Example...) Figure 9As shown, the integrated circuit 90 may include a non-secure processor 92 and a secure processor 94, and the secure processor 94 may include a key derivation function (KDF) module 94_2 and an encryption module 94_4.

[0081] KDF module 94_2 can receive image information INFO IMG Key Identifier ID KEY and hardware key HW It can also generate INFO files that depend on image information. IMG Key Identifier ID KEY and hardware key HW Internal key INT In some embodiments, the internal key is key material not provided outside the security processor 94. In some embodiments, at least a portion of the KDF module 94_2 may be derived from at least one core included in the security processor 94 (e.g., Figure 3 The KDF module 94_2 is implemented by a series of instructions executed by the at least one kernel (32_2). Additionally, in some embodiments, at least a portion of the KDF module 94_2 may be implemented by a hardware accelerator (e.g., ) included in the security processor 94. Figure 3 Implemented in 32_4).

[0082] Image Information INFO IMG It can refer to the system memory (e.g., from the secure processor 94) Figure 1 14) Binding information generated from at least a portion of the program image read. For example, image information INFO. IMG This may include the hash of the program image, a digital signature (or its hash) included in the program image, or a verification result of the digital signature. As described above with reference to the accompanying figures, the image information INFO... IMG It can be generated internally within the security processor 94 based on a program image directly read by the security processor 94, and therefore is not exposed outside the security processor 94. Thus, key binding that provides improved security can be implemented.

[0083] Key identifier ID can be provided from the non-secure processor 92 KEY ,like Figure 9 As shown. For example, a secure program executed by a non-secure processor 92 can use multiple keys, and can be configured using a key identifier ID. KEY Identify and manage keys. This can be done via a dedicated physical bus (e.g., Figure 1 In section 12_6), the key identifier ID will be... KEYData is transferred from the insecure processor 92 to the secure processor 94. In some embodiments, the dedicated physical bus includes a set of data and control lines that the insecure processor 92 does not use to communicate with any other chip or logic. In some embodiments, the key identifier ID... KEY This can be included in a request for a key, which is provided from the non-secure processor 92 to the secure processor 94.

[0084] Hardware key HW It can have a unique value for the security processor 94 (or integrated circuit 90) and can be called the root key. Hardware key KEY HW It may not be exposed outside the security processor 94. In some embodiments, the security processor 94 may include one-time programmable (OTP) memory, such as an antifuse array, and the hardware key KEY may be stored during the fabrication of the integrated circuit 90. HW The program is written into the OTP memory. In some embodiments, the security processor 94 may include a physically unclonable function (PUF) block and a hardware key KEY. HW The output of the PUF block can be used. A PUF can refer to a function that provides a unique value corresponding to a hardware based on the inherent characteristics of the hardware. For example, even when multiple pieces of hardware, such as semiconductor chips, are manufactured using the same process, they may not be physically identical to each other, and there may be minute variations between them, i.e., minute process variations. Based on these variations, a unique value of the hardware can be extracted, and the extracted value can be used for operations requiring security, such as secure communication, secure data processing, user identification, firmware updates, etc. A PUF block may have, but is not limited to, at least one of the following: an SRAM structure based on values ​​stored in SRAM cells, a ring oscillator structure based on frequency variations, a leakage-based structure based on leakage current, an arbiter structure in which signal paths are arbitrarily determined, and a structure based on the difference in threshold levels of logic gates.

[0085] Encryption module 94_4 can receive the internal key KEY from KDF module 94_2 INT And it can be based on the internal key KEY INT Perform encryption and / or decryption. For example, such as Figure 9 As shown, the encryption module 94_4 can receive decrypted data DEC from the insecure processor 92, and can also decrypt it using the internal key KEY. INT The decrypted data DEC is then encrypted to provide the encrypted data ENC to the insecure processor 92. Additionally, as... Figure 9 As shown, the encryption module 94_4 can receive encrypted data ENC from the insecure processor 92, and can also use the internal key KEY. INTThe encrypted data ENC is decrypted to provide the decrypted data DEC to the insecure processor 92. Therefore, the insecure processor 92 allows the secure processor 94 to encrypt data requiring security. For example, to maintain the security of the data encryption key (DEK) generated or used by the insecure processor 92 itself, the insecure processor 92 can provide the DEK to the secure processor 94, which can then receive the data using an internal key KEY. INT An encrypted DEK, and the encrypted DEK can be stored in system storage (e.g., Figure 1 In section 18), that is, the non-secure processor 92 can receive the encrypted DEK as a key provided by the secure processor 94, and the encrypted DEK can also be used with the internal key KEY. INT And thus, it is bound. Additionally, for DEK-based secure operations, the non-secure processor 92 can read the encrypted DEK from system memory, provide the encrypted DEK to the secure processor 94, and receive it from the secure processor 94 using an internal key KEY. INT Decrypted DEK. In some embodiments, such as Figure 9 As shown by the dashed line, in response to a request from the non-secure processor 92, the internal key KEY generated by the KDF module 94_2 can be transferred. INT Provided to non-secure processors 92.

[0086] Figure 10 This is a block diagram illustrating an example of an integrated circuit according to an example embodiment. Figure 10 As shown, integrated circuit 100 may include a non-secure processor 102 and a secure processor 104, and may also include a sensor 106 for sensing attacks originating from outside the integrated circuit 100. Regarding Figure 10 In the following description, repeated descriptions given with reference to the above figures will be omitted.

[0087] Sensor 106 can detect attacks on security processor 104 from outside integrated circuit 100. An attacker can physically attack integrated circuit 100 to extract information from security processor 104. For example, an attacker can disassemble integrated circuit 100, power the disassembled integrated circuit 100, and attempt to extract information by probing. Integrated circuit 100 may include sensor 106 for detecting such intrusive attacks.

[0088] Sensor 106 may have any structure for detecting invasive attacks on security processor 104. In some embodiments, sensor 106 may include a photosensitizing device, such as a photodiode, and may sense the inflow of light caused by the removal of integrated circuit 100. Additionally, in some embodiments, sensor 106 may include a shield comprising a plurality of conductive patterns and covering security processor 104, and may sense changes in the characteristics of the shield (e.g., capacitance or resistance) or changes in the signal transmitted through the shield caused by the removal of integrated circuit 100. In some embodiments, with Figure 10 Unlike the example shown, sensor 106 can also detect invasive attacks on the non-secure processor 102 and invasive attacks on the secure processor 104. See below for further details. Figure 11 Describe an example of performing an operation in response to an attack detected by sensor 106.

[0089] Figure 11 This is a flowchart illustrating an example of a method for securely managing keys according to an example embodiment. Specifically, Figure 11 The flowchart shows when by Figure 10 An example of the operations performed by the security processor 104 when the sensor 106 detects an intrusive attack on the security processor 104. (See also...) Figure 10 Conduct on Figure 11 The following description.

[0090] In operation S120, it can be determined whether an attack has occurred. For example, the security processor 104 can receive the output signal from the sensor 106 and determine whether an attack has occurred based on that output signal. Figure 11 As shown, when an attack occurs, operations for protection against the attack can be performed in operation S140. In some embodiments, operation S140 may include multiple operations S142, S144, and S146, such as... Figure 11 As shown, and in some embodiments, with Figure 11 Different from the example shown, operation S140 may also include only some of the multiple operations S142, S144, and S146. In some embodiments, at least two of the multiple operations S142, S144, and S146 may be executed in parallel. It should be noted that the operations performed by the security processor 104 in response to the occurrence of an attack are not limited to... Figure 11 Examples are shown in the text.

[0091] In operation S142, the ongoing operation can be terminated. For example, the security processor 104 can terminate the operation of securely managing keys as described with reference to the above figures, thereby preventing the operation of the security processor 104 from being estimated by probing. In operation S144, an operation to transform at least one element into an irreversible state can be performed. For example, the security processor 104 can open the fine pattern by applying a strong electrical signal to the fine pattern and can prevent the signal from being transmitted through the open pattern. In addition, the security processor 104 can transform a cell not programmed in the OTP memory into an irreversible state by programming the cell. In operation S146, an operation to clean up data can be performed. For example, the security processor 104 can rewrite any data (e.g., all-zero data) to the internal memory (e.g., Figure 3 32_5) and / or secure memory (e.g., Figure 3 (36) is used to purify the data.

[0092] Figure 12 This is a block diagram illustrating an example of a system according to an example embodiment. Figure 12 As shown, system 120 may include system-on-chip 122, DRAM 124, memory 128, and secure non-volatile memory 126. Figure 12 In system 120, DRAM 124 can be used as system memory, and memory 128 can be used as system storage. (The following text is incomplete and requires further context.) Figure 12 The description will omit the reference. Figure 1 The given description is repetitive.

[0093] System-on-a-chip 122 can refer to an integrated circuit manufactured using semiconductor technology that integrates various hardware blocks. For example... Figure 12 As shown, the system-on-chip 122 may include at least one core 122_1, ROM 122_2, peripheral device 122_3, DRAM access controller 122_4, memory controller 122_6, and security processor 122_7. The non-security processor described above with reference to the accompanying drawings may include at least one core 122_1, and in some embodiments, the non-security processor may also include other components besides the security processor 122_7. In some embodiments, the system-on-chip 122 may also include a bus to which at least one core 122_1, ROM 122_2, peripheral device 122_3, DRAM access controller 122_4, and memory controller 122_6 are connected. Not all bus connections are... Figure 12 As shown in the image.

[0094] At least one core 122_1 can execute instructions stored in ROM 122_2 and / or instructions stored in DRAM 124. For example, at least one core 122_1 may include a cache that can copy instructions included in ROM 122_2 and / or DRAM 124 to the cache and execute instructions stored in the cache. In some embodiments, at least one core 122_1 may include a plurality of symmetric or asymmetric cores.

[0095] ROM 122_2 may store instructions executed by at least one kernel 122_1. For example, ROM 122_2 may store a bootloader, and at least one kernel 122_1 may first execute the instructions stored in ROM 122_2, i.e., the bootloader, at the start of the initialization process of system 120. For this purpose, in some embodiments, at least a portion of the bootloader may be loaded into DRAM 124. Additionally, in some embodiments, ROM 122_2 may store immutable data in addition to storing instructions, which is referenced by at least one kernel 122_1 when the instructions are executed.

[0096] Peripheral device 122_3 may include hardware blocks with various functions. For example, peripheral device 122_3 may include an input / output (I / O) interface block that provides a communication channel for communicating with devices outside the system-on-chip 122, and peripheral device 122_3 may also include a hardware accelerator designed to perform operations such as data encoding / decoding at high speed.

[0097] DRAM access controller 122_4 can control access to DRAM 124 via DRAM controller 122_5. For example, DRAM 124, which serves as system memory, can be divided into secure and insecure regions, and DRAM access controller 122_4 can restrict access to the secure regions of DRAM 124. In some embodiments, while reading at least a portion of a program image for key generation stored in DRAM 124, security processor 122_7 can lock access to the program image by other components of on-chip system 122 via DRAM access controller 122_4, and after completing the reading of at least a portion of the program image, security processor 122_7 can unlock access to the program image via DRAM access controller 122_4.

[0098] DRAM controller 122_5 provides an interface for accessing DRAM 124. Additionally, storage controller 122_6 provides an interface for accessing storage 128. For example, storage 128 may include a flash memory device, and storage controller 122_6 provides an interface for the flash memory.

[0099] The secure processor 122_7 can communicate with a non-secure processor (e.g., at least one core 122_1) via a dedicated physical bus, and for this purpose, it may include at least one register (e.g., Figure 3 (32_1 in the original text). Additionally, the security processor 122_7 can exclusively access the security non-volatile memory 126, and for this purpose, a non-volatile memory controller (e.g., ...) may be included. Figure 3 (32_6 in the original text). The security processor 122_7 can directly read at least a portion of the program image stored in the DRAM 124 via the DRAM controller 122_5, and can generate binding information based on the at least read portion of the program image. The security processor 122_7 can generate a key based on the binding information generated internally therein, thus preventing the leakage of the binding information used for key generation.

[0100] Although embodiments have been specifically shown and described with reference to examples herein, it should be understood that various changes in form and detail may be made without departing from the spirit and scope of the appended claims.

Claims

1. An integrated circuit, comprising: A first processor is configured to execute a first program image to perform security operations, the first program image being stored in system memory; The second processor is configured as follows: At least a portion of the second program image, which is stored in the system memory, is read. Generate a key based on at least a portion of the second program image; and A dedicated communication channel is used for communication between the first processor and the second processor. The first processor is further configured as follows: Receive the key through the dedicated communication channel, and The security operation is performed based on the key.

2. The integrated circuit according to claim 1, wherein, The second processor is also configured to: Generate a hash for at least a portion of the second program image, and The key is generated based on the hash.

3. The integrated circuit according to claim 1, wherein, The second program image includes at least a digital signature, and The second processor is also configured to generate the key based on the digital signature.

4. The integrated circuit according to claim 3, wherein, The second processor is also configured to: The digital signature is verified based on the verification information used to verify the digital signature, and The key is generated based on the verification results.

5. The integrated circuit according to claim 4, wherein, The second processor is also configured to obtain the verification information from at least one of a non-volatile memory that can be exclusively accessed and a program image executed by the second processor.

6. The integrated circuit according to claim 1, wherein, The first processor, the second processor, and the system memory are configured such that when the second processor reads at least a portion of the second program image, access to the second program image by the first processor is blocked.

7. The integrated circuit according to claim 1, wherein, The second processor is also configured to generate the key in response to a request from the first processor, and The first processor is also configured to transmit the request from the first processor to the second processor via the dedicated communication channel.

8. The integrated circuit according to claim 7, wherein, The request includes an identifier for the second program image, and The second processor is also configured to: Based on the identifier of the second program image, the loading information of the second program image is obtained from non-volatile memory that can be exclusively accessed, and Based on the loading information, at least a portion of the second program image is read from the system memory.

9. The integrated circuit according to claim 7, wherein, The request includes a key identifier, and The second processor is also configured to generate the key based on the key identifier.

10. The integrated circuit according to claim 1, wherein, The first processor is also configured to provide data to the second processor via the dedicated communication channel, and The second processor is also configured to: An internal key is generated based on at least a portion of the second program image, and The key is generated by decrypting or encrypting the data based on the internal key.

11. The integrated circuit according to claim 1, wherein, The first program image is the same as the second program image.

12. The integrated circuit according to claim 1, wherein, The second processor is also configured to: The identifier and loading information of the second program image are received from the first processor through the dedicated communication channel, and The identifier and the loading information are written to a non-volatile memory that can be exclusively accessed.

13. The integrated circuit according to claim 1, wherein, The second processor is also configured to: Obtain the hardware key from within the second processor, and The key is generated based on the hardware key.

14. The integrated circuit according to claim 1, wherein, The second processor includes a direct memory access controller configured to read at least a portion of the second program image from the system memory.

15. The integrated circuit according to claim 1, further comprising: A sensor configured to sense physical attacks on the second processor.

16. A key management system, comprising: An integrated circuit includes a first processor and a second processor, wherein the first processor and the second processor are configured to communicate with each other via a dedicated communication channel; System memory, configured to store program images executable by the first processor; and Non-volatile memory, configured to be exclusively accessed by the second processor, and storing loading information of the program image. The second processor is further configured as follows: Based on the loading information, at least a portion of the program image is read from the system memory; Generate a key based on at least a portion of the program image, and Provide the key to the first processor, and The first processor is also configured to perform secure operations based on the key.

17. The system according to claim 16, wherein, The program image includes at least a digital signature, and The second processor is also configured to generate the key based on the digital signature.

18. The system according to claim 17, wherein, The non-volatile memory is also configured to store verification information used to verify the digital signature, and The second processor is also configured to: Verify the digital signature based on the verification information, and The key is generated based on the verification results.

19. The system according to claim 16, wherein, The second processor is also configured to write the load information into the non-volatile memory in response to at least one of the following: initial setup of the system during the manufacturing process of the system; or a master reset of the system. The first processor then installs the application corresponding to the program image onto the operating system.

20. A method executed by an integrated circuit, the integrated circuit including a first processor and a second processor, the method comprising: The second processor reads at least a portion of a program image from system memory, the program image being executable by the first processor; The second processor generates a key based on at least a portion of the program image; and The first processor performs a security operation based on the key.

Images