Apparatus and method for authenticating security state of chiplet

Abstract

An electronic device for authenticating the security status of a chiplet according to embodiments of the present disclosure comprises a first chiplet and one or more second chiplets connected to each other by a first interface, wherein each of the first chiplet and the one or more second chiplets comprises a first bootloader executed when initiating a boot process and an immutable memory programmed once, wherein the immutable memory stores a security key and a second bootloader executed by the first bootloader, and each of the first chiplet and the one or more second chiplets may be configured to authenticate the security status by signing with the security key in response to a request for authentication of the security status from an external device.

Description

Technology Field

[0001] The present disclosure relates to an apparatus and method for authenticating the security status of a chiplet, and specifically to a technology for authenticating the security status during the booting process of a chiplet to enhance the security of a chiplet-based device or system. Background Technology

[0002] With the recent advancement of semiconductor technology and the increasing demand for high performance and high integration, chiplet architecture is garnering attention. Instead of integrating all functions onto a single large die, chiplet architecture integrates functionally separated dies into a single package, enabling inter-die communication via standard interfaces such as silicon interposers or UCIe (Universal Chiplet Interconnect Express). Utilizing chiplet architecture allows for overcoming reticle limitations, improving chiplet yield, and reducing development costs through chiplet reuse.

[0003] However, chiplet-based systems are sometimes composed of heterogeneous chiplets supplied by different vendors, which presents a problem in that it is difficult to fully trust the security of each chiplet in advance. Furthermore, if a specific chiplet is maliciously tampered with or contains unintended security vulnerabilities when integrated into a system, the integrity and reliability of the entire system may be compromised. This can lead to serious security threats, such as user data leakage, system malfunctions, and the execution of malicious code.

[0004] To prevent such security threats, chiplet-based systems require an authentication procedure to verify the integrity and reliability of each chiplet during the boot phase. The problem to be solved

[0005] The objective of the present disclosure is to verify the security status of a chiplet during the booting process of a chiplet-based device or system, thereby ensuring its integrity and reliability.

[0006] The objective of the present disclosure is to verify the security status of each chiplet by introducing the concepts of a verification chiplet and a proof chiplet.

[0007] The objective of the present disclosure is that the verification chiplet also functions as an authenticity chiplet for the chiplet system to verify the security status of the entire chiplet system.

[0008] The technical problems to be solved in this disclosure are not limited to those mentioned above, and various unmentioned technical problems can be inferred by a person skilled in the art from this disclosure. means of solving the problem

[0009] An electronic device for authenticating the security status of a chiplet according to embodiments of the present disclosure comprises a first chiplet and one or more second chiplets connected to each other by a first interface, wherein each of the first chiplet and the one or more second chiplets comprises a first bootloader executed when initiating a boot process and an immutable memory programmed once, wherein the immutable memory stores a security key and a second bootloader executed by the first bootloader, and each of the first chiplet and the one or more second chiplets may be configured to authenticate the security status by signing with the security key in response to a request for authentication of the security status from an external device.

[0010] In one embodiment, each of the first chiplet and the one or more second chiplets may be further configured to execute the first bootloader when initiating the boot process, load the second bootloader by the first bootloader, and perform an integrity verification for the second bootloader.

[0011] In one embodiment, if the integrity verification is successful in each of the first chiplet and the one or more second chiplets, the first chiplet may be further configured to perform a first verification of the first security state of each of the one or more second chiplets.

[0012] In one embodiment, the first verification may be performed in such a manner that the first chiplet requests proof of the first security state from each of the one or more second chiplets, and in response to the request of the first chiplet, each of the one or more second chiplets generates first security state information based on the security key and transmits it to the first chiplet, and the first chiplet verifies the first security state information.

[0013] In one embodiment, the first security status information may include at least one of a chiplet unique identifier, a certificate, firmware information, boot information, version information, or security settings for each of the one or more second chiplets.

[0014] In one embodiment, the first chiplet may be further configured to allow each of the one or more second chiplets to continue the boot process if the first verification is successful, and to disable the first interface, stop the boot process, and transmit log information about the boot failure to a host device if the first verification fails.

[0015] In one embodiment, while the boot process continues, each of the first chiplet and the one or more second chiplets loads boot firmware by the second bootloader, and the first chiplet may be further configured to perform a second verification of the second security state of the boot firmware executed on each of the one or more second chiplets.

[0016] In one embodiment, the second verification may be performed in such a manner that the first chiplet requests proof of the second security state from each of the one or more second chiplets, and in response to the request of the first chiplet, each of the one or more second chiplets generates second security state information based on the security key and transmits it to the first chiplet, and the first chiplet verifies the second security state information.

[0017] In one embodiment, the second security state information may include at least one of runtime information or integrity information of the boot firmware.

[0018] In one embodiment, the first chiplet may be further configured to allow each of the one or more second chiplets to complete the boot process if the second verification is successful, and to disable the first interface, stop the boot process, and transmit log information about the boot failure to the host device if the second verification fails.

[0019] In one embodiment, the first chiplet is connected to the host device by a second interface, and after the boot process is completed, in response to a request for proof of the third security state of the electronic device from the host device, the first chiplet may be further configured to generate third security state information based on the security key and transmit it to the host device.

[0020] A method for authenticating the security state of a chiplet by an electronic device according to embodiments of the present disclosure, wherein the electronic device comprises a first chiplet and one or more second chiplets connected to each other by a first interface, and each of the first chiplet and the one or more second chiplets comprises a first bootloader executed when initiating a boot process and an immutable memory programmed once, wherein the immutable memory stores a security key and a second bootloader executed by the first bootloader, and the method comprises the steps of executing the first bootloader by each of the first chiplet and the one or more second chiplets and performing an integrity verification for the second bootloader; if the integrity verification is successful, performing a first verification of the first security state of each of the one or more second chiplets by the first chiplet; if the first verification is successful, performing a second verification of the second security state of boot firmware executed by each of the one or more second chiplets by the first chiplet; and if the second verification is successful, the first It may include the step of performing a third verification of the third security state of the electronic device by a host device connected by a chiplet and a second interface.

[0021] In one embodiment, the step of performing the first verification may include: requesting proof of the first security state from each of the one or more second chiplets by the first chiplet; generating first security state information based on the security key by each of the one or more second chiplets in response to the request of the first chiplet and transmitting it to the first chiplet; and verifying the first security state information by the first chiplet.

[0022] In one embodiment, after the step of performing the first verification, if the first verification is successful, the method may further include the step of allowing each of the one or more second chiplets to continue the boot process by the first chiplet, and if the first verification fails, the method may further include the step of disabling the first interface by the first chiplet, stopping the boot process, and transmitting log information regarding the boot failure to the host device.

[0023] In one embodiment, the step of performing the second verification may include: requesting proof of the second security state from each of the one or more second chiplets by the first chiplet; generating second security state information based on the security key by each of the one or more second chiplets in response to the request of the first chiplet and transmitting it to the first chiplet; and verifying the second security state information by the first chiplet.

[0024] In one embodiment, after the step of performing the second verification, if the second verification is successful, the method may further include the step of allowing each of the one or more second chiplets by the first chiplet to complete the boot process, and if the second verification fails, the method may further include the step of disabling the first interface by the first chiplet, stopping the boot process, and transmitting log information regarding the boot failure to the host device.

[0025] In one embodiment, the step of performing the third verification may include the step of requesting the first chiplet by the host device for proof of the third security state of the electronic device, the step of generating third security state information based on the security key by the first chiplet in response to the request of the host device and transmitting it to the host device, and the step of verifying the third security state information by the host device.

[0026] In one embodiment, after the step of performing the third verification, the method may further include the step of allowing a connection between the electronic device and the host device by the host device if the third verification is successful, and the step of disallowing a connection between the electronic device and the host device by the host device if the third verification fails. Effects of the invention

[0027] According to embodiments of the present disclosure, the security status can be verified during the booting process of a chiplet-based device or system to ensure its integrity and reliability.

[0028] According to embodiments of the present disclosure, the security status of each chiplet can be verified by introducing the concepts of verification chiplets and proof chiplets.

[0029] According to embodiments of the present disclosure, the verification chiplet also functions as an authentication chiplet for the chiplet system, thereby verifying the security status of the entire chiplet system.

[0030] The effects according to the technical concept of the present disclosure are not limited to the effects mentioned above, and various unmentioned effects can be clearly understood by a person skilled in the art from the present disclosure. Brief explanation of the drawing

[0031] FIG. 1 is a drawing for illustrating a system including an electronic device comprising a plurality of chiplets and a host device according to embodiments of the present disclosure. FIG. 2 is a drawing for illustrating a first interface connecting a plurality of chiplets according to embodiments of the present disclosure. FIG. 3 is a drawing for explaining the configuration of a chiplet according to embodiments of the present disclosure. FIG. 4a is a drawing for illustrating the configuration of an immutable memory according to embodiments of the present disclosure. FIG. 4b is a drawing for illustrating the configuration of an immutable memory according to embodiments of the present disclosure. FIG. 5 is a drawing for illustrating a configuration for signing with a certificate according to embodiments of the present disclosure. FIG. 6 is a flowchart illustrating a method for authenticating the security status of a chiplet according to embodiments of the present disclosure. FIG. 7 is a flowchart for explaining the operation of a first bootloader and a second bootloader according to embodiments of the present disclosure. FIG. 8 is a flowchart illustrating a first verification process according to embodiments of the present disclosure. FIG. 9 is a flowchart illustrating a second verification process according to embodiments of the present disclosure. FIG. 10 is a flowchart illustrating a third verification process according to embodiments of the present disclosure. Specific details for implementing the invention

[0032] Hereinafter, specific embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification, specific descriptions of commonly known functions or configurations are omitted where there is a risk of unnecessarily complicating or obscuring the core of the invention.

[0033] The advantages, features, and methods for achieving the disclosed embodiments will be clearly understood by referring to the accompanying drawings and the embodiments described below. However, the present disclosure is not limited to these embodiments and may be implemented in various forms. These embodiments are provided merely as examples to aid in the overall understanding of the invention and do not limit the scope of the invention.

[0034] In the attached drawings, identical or similar components are assigned the same reference numbers. Additionally, when describing embodiments of the present disclosure, descriptions of identical or similar components may be omitted to avoid redundant descriptions. However, such omission of description is not intended to imply that the corresponding component is not included in a particular embodiment.

[0035] The terms used in this specification have been selected to fully reflect the function of the invention and are currently in general use; however, these may change depending on the perspectives of those skilled in the relevant field or new technological advancements. Additionally, in specific cases, terms may be selected at the applicant's discretion, and in such cases, their meanings will be described in detail in this specification. Accordingly, the terms in this specification should be interpreted based on their meanings and the overall content of this disclosure, rather than merely as names.

[0036] In this specification, when expressed in the singular, it may include a plural meaning unless explicitly limited to the singular. Conversely, when expressed in the plural, it may be interpreted as singular in context unless explicitly limited to the plural. Throughout the specification, when a specific part is described as including a certain component, this does not mean that other components are excluded, but rather that additional components may be included.

[0037] In this specification, the expressions “each of a plurality of A” or “each of a plurality of A” may refer to each of all elements included in a plurality of A, or may refer to each of some elements of a plurality of A.

[0038] In this specification, the expression “one or more A” may mean a set of one or more A's unless the context clearly indicates otherwise.

[0039] Expressions used herein such as "may include," "may be equipped," and "may have" imply the presence of the relevant feature (e.g., function, operation, or component, etc.) and do not exclude the presence of other additional features. In other words, these expressions should be understood as open-ended terms that leave open the possibility of including other embodiments.

[0040] As used herein, the expression "configured to..." may have meanings such as "set to...", "capable of...", "modified to...", "made to...", or "capable of..." depending on the context. This expression is not limited to "specifically designed in hardware"; for example, a processor configured to perform a specific operation may refer to a general-purpose processor capable of performing that operation through software execution, or a special-purpose computer structured through programming to perform the said specific operation.

[0041] Expressions such as "connection," "transmission," "sending," and "reception" used in this specification may mean directly connecting, transmitting, sending, or receiving between components, or they may mean indirectly connecting, transmitting, sending, or receiving through the interposition of other components.

[0042] In this disclosure, expressions such as "first," "second," or "first," "second," etc., do not limit the order, importance, etc., of the components they modify unless the context clearly indicates otherwise. These expressions may be used to distinguish one component from another.

[0043] In the present disclosure, expressions such as “A, B, or C”, “A, B, and / or C”, “at least one of A, B, and C”, “at least one of A, B, or C”, “at least one of A, B, and / or C”, “at least one selected from A, B, and C”, “at least one selected from A, B, or C”, and “at least one selected from A, B, and / or C” may mean each or all possible combinations thereof. For example, “at least one of A or B” may refer to at least one A, at least one B, at least one A, and at least one B.

[0044] FIG. 1 is a drawing for illustrating a system including an electronic device comprising a plurality of chiplets and a host device according to embodiments of the present disclosure.

[0045] Referring to FIG. 1, a system (1) according to embodiments of the present disclosure may include an electronic device (10) and a host device (20).

[0046] The electronic device (10) may be an electronic device that communicates with the host device (20) and provides functions according to the commands of the host device (20). For example, the electronic device (10) may be a device specialized in the computation of an artificial neural network model and may be an artificial neural network accelerator. The electronic device (10) may perform parallel processing for at least some functions of the host device (20). The electronic device (10) may be a chiplet system comprising first to fourth chiplets (100_1 to 100_4), and may distribute tasks according to the commands to the first to fourth chiplets (100_1 to 100_4) according to the commands of the host device (20) and process the tasks in parallel.

[0047] The host device (20) is a general-purpose computing processor and may be, for example, a CPU (Central Processing Unit). Accordingly, the host device (20) may request neural network computation from an electronic device (10) that includes a neural network computing processor such as an NPU (Neural Processing Unit). That is, the host device (20) may be a host that sends commands to the electronic device (10). The host device (20) may transmit a command stream to the electronic device (10) to instruct neural network computation. The host device (20) may receive the result of the neural network computation from the electronic device (10).

[0048] Referring to FIG. 1, a system (1) according to embodiments of the present disclosure may further include a mutable memory (30). Although FIG. 1 is illustrated as the mutable memory (30) being connected to an electronic device (10), depending on the configuration of the system (1), the mutable memory (30) may be directly connected to a specific chiplet, such as a first chiplet (100_1).

[0049] The changeable memory (30) may be implemented, for example, as flash memory. The changeable memory (30) may store application firmware or operating system software as a bootloader following the boot firmware. The first bootloader (1200) and / or the second bootloader (1320) described below may load the firmware or operating system software during the boot phase. Depending on the design choice, the application firmware or operating system software may be stored in the changeable memory (30) or in the memory inside the first to fourth chiplets (100_1 to 100_4).

[0050] Referring to FIG. 1, an electronic device (10) according to embodiments of the present disclosure may include a plurality of chiplets. A chiplet is an individual integrated circuit and may be a semiconductor device in the form of a package formed by combining or connecting with external chiplets. That is, the electronic device (10) may be packaged in a form including a plurality of chiplets. For example, the electronic device (10) may include a first chiplet (100_1), a second chiplet (100_2), a third chiplet (100_3), and a fourth chiplet (100_4) as a plurality of chiplets. However, this is exemplary, and the electronic device (10) may include any number of chiplets. In the present disclosure, the first chiplet (100_1) is referred to as the "first chiplet," and the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may be referred to as "one or more second chiplets."

[0051] Referring to FIG. 1, the first to fourth chiplets (100_1 to 100_4) may be arranged in a square array within the electronic device (10), and the first to fourth chiplets (100_1 to 100_4) may each be connected to adjacent chiplets to communicate. However, this is exemplary, and the chiplets including the first to fourth chiplets (100_1 to 100_4) within the electronic device (10) may be arranged in various shapes such as a straight line, a rectangle, or a grid and connected to each other.

[0052] The first to fourth chiplets (100_1 to 100_4) within the electronic device (10) can be connected to each other via a silicon interposer using methods such as wire bonding or TSV (Through Silicon Via). The configuration in which the first to fourth chiplets (100_1 to 100_4) are connected to each other is specifically explained through FIG. 2.

[0053] FIG. 2 is a drawing for illustrating a first interface connecting a plurality of chiplets according to embodiments of the present disclosure.

[0054] Referring to FIG. 1, the first to fourth chiplets (100_1 to 100_4) can be connected to each other by a first interface (40). Referring to FIG. 2, the first interface (40) may include a main interface (41) and a backup interface (42). The main interface (41) and the backup interface (42) may provide a dual path structure for communication between chiplets and support for a boot sequence.

[0055] Specifically, the main interface (41) is a die-to-die interface and can be implemented, for example, as a UCIe (Universal Chiplet Interconnect Express) interface. The UCIe interface can perform high-speed and bandwidth-extended communication between multiple chiplets. Since the UCIe interface is activated only after initialization by the firmware is performed during initial boot, it may not be available for direct use prior to initialization. To address this, the backup interface (42) is a die-to-die backup interface and can be implemented, for example, as a SPIe (Serial Peripheral Interface Express) interface. The SPIe interface can provide a low-speed and low-bandwidth communication path that is immediately available without a separate initialization process.

[0056] For example, the system (1) may have a configuration in which the changeable memory (30) is directly connected only to the first chiplet (100_1). In this case, only the first chiplet (100_1) may be able to directly access the application firmware stored in the changeable memory (30) at the time of initial boot. And, the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may not be able to initialize the main interface (41) including the UCIe interface on their own. In this situation, a backup interface (42) including the SPIe interface may be activated to transfer the application firmware read from the changeable memory (30) by the first chiplet (100_1) to the other chiplets, namely the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). The second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) execute application firmware received through the backup interface (42) to complete the initialization of the main interface (41), and thereafter, high-speed data communication and operation synchronization can be performed through the main interface (41).

[0057] Although it has been described that the main interface (41) and the backup interface (42) each include a UCIe interface and a SPIe interface, the present disclosure is not limited thereto and may include various interfaces such as MIPI (Mobile Industry Processor Interface), I2C (Inter-Integrated Circuit), UART (Universal Asynchronous Receiver / Transmitter), USART (Universal Synchronous Receiver / Transmitter), CAN (Controller Area Network), LIN (Local Interconnect Network), and SSI (Synchronous Serial Interface). Additionally, although it has been described that the first interface (40) is divided into the main interface (41) and the backup interface (42), it is not limited thereto and may be configured in various ways within the scope of the problem to be solved by the present disclosure.

[0058] Referring again to FIG. 1, a first chiplet (100_1) of an electronic device (10) and a host device (20) can be connected by a second interface (50). The second interface (50) can provide an external communication path for data transmission and reception and control signal exchange between the first chiplet (100_1) and the host device (20). The second interface (50) can be implemented as one or more of various interfaces depending on the configuration of the system (1). The second interface (50) may include various interfaces, such as PCIe (Peripheral Component Interconnect Express), I2C (Inter-Integrated Circuit), or SMBus (System Management Bus). Preferably, the second interface (50) can be implemented as a PCIe interface, which offers high speed and excellent bandwidth scalability.

[0059] Specifically, the second interface (50) can support the first chiplet (100_1) receiving boot control commands, security verification requests, firmware, configuration data, etc. from the host device (20). Additionally, the second interface (50) can support the first chiplet (100_1) transmitting status information, security status attestation results, operation logs, etc. of the first chiplet (100_1) to the host device (20). Furthermore, the second interface (50) can receive necessary configuration data from the host device (20) during initial booting to set the operating environment of the first chiplet (100_1), or support real-time status synchronization with the host device (20) during the operation of the system (1).

[0060] The first interface (40) and the second interface (50) can each be implemented as a circuit or a circuitry.

[0061] Each of the first to fourth chiplets (100_1 to 100_4) according to the embodiments of the present disclosure may be an artificial neural network accelerator that performs operations on an artificial neural network model. However, this is exemplary, and each of the first to fourth chiplets (100_1 to 100_4) may be a chiplet that performs various functions, such as an artificial neural network accelerator, a CPU, an interface chip, or a memory chip. The configuration of the first to fourth chiplets (100_1 to 100_4) is described in detail through FIG. 3.

[0062] FIG. 3 is a drawing for explaining the configuration of a chiplet according to embodiments of the present disclosure.

[0063] Each of the first to fourth chiplets (100_1 to 100_4) may be composed of the chiplet (100) illustrated in FIG. 3. The description of the chiplet (100) below may be applied to each of the first to fourth chiplets (100_1 to 100_4) in the same or similar manner. However, the first to fourth chiplets (100_1 to 100_4) may be the same chiplet or different chiplets. For example, among the first to fourth chiplets (100_1 to 100_4), the first chiplet (100_1) which communicates directly with the host device (20) essentially includes a PCIe subsystem (2100), but the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) which do not communicate directly with the host device (20) may optionally include a PCIe subsystem (2100). In addition, at least one of the first to fourth chiplets (100_1 to 100_4) may be a chiplet manufactured by a different manufacturer than the remaining chiplets.

[0064] Referring to FIG. 3, the chiplet (100) may include a secure domain (1000) and a normal domain (2000). Within the chiplet (100), the secure domain (1000) may be implemented as a separate security chip or security processor, and the normal domain (2000) may be implemented as a main chip or main processor. Alternatively, the secure domain (1000) and the normal domain (2000) may be implemented in a manner that is hardware-separated within a single chiplet (100) or SoC.

[0065] The security area (1000) is a core block that forms the Root of Trust of the chiplet (100) and can perform tasks requiring a high level of security, such as system booting, authentication, cryptographic operations, and key management. The security area (1000) can perform security status attestation and firmware integrity verification through the security core (1100), immutable memory (1300), etc. The security area (1000) is basically restricted from external access, so security-related resources can be safely managed. However, an interface that enables limited data exchange between the security area (1000) and the general area (2000) may be provided.

[0066] The general area (2000) is a block that performs functions of relatively low security importance, such as application execution, data processing, and peripheral device control, and may include a high-performance computing core, general memory, and an input / output interface. The general area (2000) may exchange data with the security area (1000) or request security services from the security area (1000) when necessary.

[0067] Referring to FIG. 3, the security area (1000) may include a security core (1100), a first bootloader (1200), immutable memory (1300), security hardware engines (1400), and memory (1500).

[0068] The security core (1100) may be a processing unit configured to execute security-related firmware or software. The security core (1100) may ensure that integrity is maintained by verifying the security state during the boot process of the chiplet (100) or by verifying the security state of the running firmware (including boot firmware) or software.

[0069] Specifically, the security core (1100) may include a CPU. This CPU may, for example, execute a first bootloader (1200) during the initial booting phase to set the security state of the chiplet (100) and respond to security requests requested from external devices such as a host device (20) and a general area (2000).

[0070] The first bootloader (1200) is a bootloader that is executed when the boot process is initiated. The first bootloader (1200) is immutable firmware fixed to the hardware and may be composed of ROM code.

[0071] Specifically, when power is applied to the chiplet (100), the first bootloader (1200) can be automatically executed first by the security core (1100). After the first bootloader (1200) is executed, a hardware initialization process including clock and power settings, interface initialization, etc., can be performed. Subsequently, loading of the second bootloader (1320) and integrity verification of the second bootloader (1320) can be performed. If the integrity verification is successful, the first bootloader (1200) loads and executes the second bootloader (1320), and if the integrity verification fails, the boot process can be stopped to block security threats.

[0072] The immutable memory (1300) is a one-time programmable memory, which can be implemented, for example, as a One-Time Programmable (OTP) memory. Data is written to the immutable memory (1300) only once during the manufacturing phase or initial provisioning process, and cannot be modified or deleted thereafter, thereby ensuring the immutability and integrity of the stored information.

[0073] Specifically, the immutable memory (1300) is placed within the security area (1000) and configured to be accessible only from the security core (1100), thereby preventing unauthorized tampering from the outside. In the boot sequence, the security core (1100) can refer to the data stored in the immutable memory (1300) to initialize the security settings (1330) and perform an integrity verification procedure to proceed to the next boot step.

[0074] The security hardware engine (1400) is configured to accelerate various security operations within the chiplet (100) using dedicated hardware, and can efficiently process security operations such as hash operations, digital signature generation and verification, and symmetric key encryption and decryption (AES, etc.).

[0075] Specifically, hash operations can be used to verify the integrity of data by generating a hash value of a specific length from input data. For example, in the case of a SHA-384 hash operation, the output length is 384 bits, and it can be used to sign and verify certificates in the X.509 format. A digital signature is a data result generated or verified using a pair of public and private keys, and it can be used to verify and authenticate the integrity of a system. The Advanced Encryption Standard (AES) algorithm is a symmetric key method that encrypts and decrypts data using the same key.

[0076] The memory (1500) is a space for storing data for a security core (1100) or other security-related circuits to perform operations within a security area (1000), and can be implemented, for example, as SRAM (Static Random Access Memory). Specifically, to perform security operations within the security area (1000), security-related data can be stored in the memory (1500), and operations can be performed by referencing or updating the data.

[0077] Referring to FIG. 3, the general area (2000) may include at least one of a PCIe subsystem (2100), a UCIe subsystem (2200), a normal core (2300), neural network hardware engines (2400), a mailbox (2500), or memory (2600). In other words, the PCIe subsystem (2100), the UCIe subsystem (2200), the normal core (2300), the neural network hardware engines (2400), the mailbox (2500), and the memory (2600) are exemplary configurations, and each configuration may be optionally included in the general area (2000). For example, the PCIe subsystem (2100) may be included only in the first chiplet (100_1) that communicates directly with the host device (20), and may not be included in the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4).

[0078] The PCIe subsystem (2100) may be a module specifically designed to enable the electronic device (10) to perform high-speed data communication with the host device (20) through a second interface (50) that includes a PCIe interface. The PCIe subsystem (2100) may be installed, for example, on a first chiplet (100_1) to perform the role of main interfacing with the host device (20).

[0079] The UCIe subsystem (2200) may be a module designed specifically to implement a first interface (40) that includes a UCIe interface for connecting the first to fourth chiplets (100_1 to 100_4) to each other, that is, an interface between the chiplets (100). The UCIe subsystem (2200) may be installed on all of the first to fourth chiplets (100_1 to 100_4) to implement the interface between the chiplets (100).

[0080] The general core (2300) is a general-purpose computing processor configured to provide intermediate control between the host device (20) and the neural network hardware engine (2400), and may be, for example, a CPU. When the host device (20) requests a processing job through the second interface (50), the general core (2300) can receive and interpret the request and convert it into a form of commands and data that the neural network hardware engine (2400) or other hardware accelerator can directly understand. Specifically, the general core (2300) executes firmware to manage the initialization, job scheduling, data transmission control, result collection, etc. of the neural network hardware engine (2400), and can perform status reporting to the host device (20) when necessary.

[0081] The neural network hardware engine (2400) is a module that accelerates the computation of an artificial neural network model using dedicated hardware, and may be, for example, an NPU. The neural network hardware engine (2400) can perform computations that are frequently performed during the inference and learning process of deep learning, such as large-scale matrix operations, tensor operations, and vector operations, at high speed through a parallel processing structure. Specifically, the neural network hardware engine (2400) can receive computation commands and input data from a general core (2300) and perform parallel computations by utilizing a mailbox (2500) and memory (2600). Additionally, the neural network hardware engine (2400) can transmit the computation results to the general core (2300) or another module after performing parallel computations.

[0082] The mailbox (2500) may be a shared memory-based module that supports asynchronous data exchange between chiplets (100) or between a chiplet (100) and a host device (20). If the transmitting module records specific data in the mailbox (2500), the receiving module can read and process the data from the mailbox (2500) when necessary.

[0083] The memory (2600) may be volatile memory used by a general core (2300), a neural network hardware engine (2400), etc., to store or retrieve data required for the operation. For example, the memory (2600) may be implemented as DRAM, SRAM, or a combination thereof, and may store intermediate data, instructions, parameters, and buffer data generated during the computation process. The immutable memory (1300) illustrated in FIG. 3 is described in detail through FIG. 4a and 4b.

[0084] FIGS. 4a and 4b are drawings for illustrating the configuration of an immutable memory according to embodiments of the present disclosure.

[0085] Referring to FIG. 4a, the immutable memory (1300) may store at least one of a security key (1310), a second bootloader (1320), a security setting (1330), or a security lifecycle (1340). In other words, the security key (1310), the second bootloader (1320), the security setting (1330), and the security lifecycle (1340) are exemplary configurations, and each configuration may be optionally included in the immutable memory (1300). However, each of the first to fourth chiplets (100_1 to 100_4) may necessarily include the security key (1310) and the second bootloader (1320) to execute boot firmware and to prove the security status of each of the first to fourth chiplets (100_1 to 100_4) or the security status of the boot firmware.

[0086] The security key (1310) may include not only a private key unique to the corresponding chiplet (e.g., the first chiplet (100_1)), but also a public key corresponding to other chiplets (the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4)) within the electronic device (10). This public key is stored in an immutable memory (1300), and when the verification chiplet (e.g., the first chiplet (100_1)) receives data from the proof chiplets (the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4)) to be verified by the verification chiplet, the integrity and reliability of the electronic device (10) can be guaranteed by performing verification using the public key corresponding to each of the proof chiplets.

[0087] The second bootloader (1320) may be programmable firmware that is executed for the first time after the execution of the first bootloader (1200). The second bootloader (1320) is executed after its integrity is verified by the first bootloader (1200) and may load and execute application firmware or operating system software. Although FIGS. 4a and 4b illustrate that the second bootloader (1320) is stored in immutable memory (1300), it may also be stored in changeable memory (30) outside the electronic device (10) of FIG. 1.

[0088] A security setting (1330) is a configuration that sets or defines the state of security policies and security functions related to the operation of the chiplet (100), and can be recorded during the manufacturing stage or initial setup stage of the chiplet (100). Since the security setting (1330) is stored in immutable memory (1300), it cannot be changed once recorded, thus protecting it from forgery or tampering attacks. As a security setting (1330), an enabled security mode, such as whether to enable FIPS (Federal Information Processing Standards) mode or whether to disable the debugging interface, can be set or defined. Additionally, as a security setting (1330), the setting state of a security function, such as whether to enable PCIe IDE (Integrity and Data Encryption) or whether to encrypt memory, can be set or defined. Additionally, as a security setting (1330), for example, a register and memory access policy of the chiplet (100) may be set or defined.

[0089] The security lifecycle (1340) defines security policies and permission levels applied at each stage of the chiplet (100), such as manufacturing, authentication, initialization, and operation, and can control the chiplet (100) to perform specific functions only at allowed stages. For example, access for testing and debugging the chiplet (100) may be allowed during the manufacturing stage, and access related to the boot process may be allowed during the operation stage.

[0090] Referring to FIG. 4b, the immutable memory (1300) may further include a certificate (1350). The certificate (1350) is electronic proof data for verifying the identity and security status of the chiplet (100), and may include, for example, a digital certificate in the X.509 format. The certificate (1350) includes information such as the chiplet unique identifier (Chiplet Unique ID) and public key of the chiplet (100), and may be stored and managed in the immutable memory (1300) within the security area (1000) of the chiplet (100). The configuration of the certificate (1350) is described in detail through FIG. 5.

[0091] FIG. 5 is a drawing for illustrating a configuration for signing with a certificate according to embodiments of the present disclosure.

[0092] Referring to FIG. 5, a certificate (1350) can be used to verify the identity and security status of a chiplet (100). For example, a certificate (1350) in the X.509 format may include a chiplet unique identifier, an algorithm used when signing the certificate (1350) (e.g., SHA-384), the public key of the certificate (1350) owner, a value (or data) signed with the private key of the certificate (1350) owner, etc. Here, the public key and the private key may be configured as a corresponding key pair.

[0093] Additionally, referring to FIG. 5, there may be a verification chiplet (or verification device) ("Verifier" in FIG. 5) configured to verify, for example, the security status of a chiplet (100), and an attestation chiplet (or attestation device) ("Attester" in FIG. 5) configured to attest the security status upon the request of the verification chiplet. To explain the method of authentication by certificate (1350) through FIG. 5, first, the verification chiplet may request attestation of the security status from the attestation chiplet ("Request attestation" in FIG. 5). In response to the request of the verification chiplet, the attestation chiplet may generate a certificate (1350) including a chiplet unique identifier and a public key, and encrypt or sign it with a private key ("Sign certificate with private key" in FIG. 5). When the proof chiplet transmits a signed certificate (1350) to the verification chiplet ("Transfer signed certificate" in FIG. 5), the verification chiplet can decrypt or verify the signed certificate using a public key corresponding to the private key used for encryption or signing ("Verify certificate with public key" in FIG. 5). If verification is successful, the certificate (1350) can be certified as being incorruptible. The above-described requests for proof of security status by the verification chiplet, certificate signing by the proof chiplet, certificate verification by the verification chiplet, etc., may be performed by the security core (1100), security hardware engine (1400), general core (2300), neural network hardware engine (2400), etc. of each chiplet (100), but the present disclosure is not limited thereto.

[0094] According to embodiments of the present disclosure, each of the first to fourth chiplets (100_1 to 100_4) can prove their security status by signing with a security key including a private key in response to a request for proof of security status from an external device. In relation to the authentication of the chiplets (100), the first chiplet (100_1) may operate as a verification chiplet to request proof of security status from each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4), and each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may operate as a proof chiplet to prove their own security status. In addition, regarding the authentication of an electronic device (10) including first to fourth chiplets (100_1 to 100_4), a host device (20) may operate as a verification device to request the first chiplet (100_1) to prove the security status, and the first chiplet (100_1) may operate as a proof chiplet to prove the security status of the entire electronic device (10), including itself. In other words, the first chiplet (100_1) may operate as a verification chiplet or as a proof chiplet. A specific method for verifying (authenticating) the security status will be described below.

[0095] FIG. 6 is a flowchart illustrating a method for authenticating the security status of a chiplet according to embodiments of the present disclosure.

[0096] Referring to FIG. 6, each of the first to fourth chiplets (100_1 to 100_4) executes a first bootloader (1200) and performs an integrity verification for a second bootloader (1320) (S100). If the integrity verification is successful, the first chiplet (100_1) performs a first verification for a first security state of each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S200). If the first verification is successful, the first chiplet (100_1) performs a second verification for a second security state of the boot firmware executed on each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S300). If the second verification is successful, a host connected to the first chiplet (100_1) by the second interface (50) By the device (20), a third verification of the third security state of the electronic device (10) can be performed (S400).

[0097] FIG. 7 is a flowchart for explaining the operation of a first bootloader and a second bootloader according to embodiments of the present disclosure. FIG. 7 is a flowchart specifically explaining step S100 of FIG. 6.

[0098] Referring to FIG. 7, each of the first to fourth chiplets (100_1 to 100_4) can execute a first bootloader (1200) when initiating a boot process (S110). When power is applied to the chiplet (100), the first bootloader (1200) can be automatically executed first by the security core (1100).

[0099] After step S110, each of the first to fourth chiplets (100_1 to 100_4) can load the second bootloader (1320) by the first bootloader (1200) and perform an integrity verification on the second bootloader (1320) (S120). If the integrity verification is successful, the first bootloader (1200) loads and executes the second bootloader (1320), and if the integrity verification fails, the boot process can be stopped. Steps S110 and S120 can be performed in the same manner on each of the first to fourth chiplets (100_1 to 100_4).

[0100] FIG. 8 is a flowchart illustrating a first verification process according to embodiments of the present disclosure. FIG. 8 is a flowchart specifically illustrating step S200 of FIG. 6.

[0101] If the integrity verification for the second bootloader (1320) in step S120 of FIG. 7 is successful, the first chiplet (100_1) can perform a first verification of the first security state of each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). The first security state may include the integrity state of each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). By performing the first verification of the first security state, it is possible to prevent each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) from malfunctioning or being maliciously tampered with, and to ensure the reliability of each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4).

[0102] Referring to FIG. 8, the operation of the first verification is described in detail. First, the first chiplet (100_1) may request proof of the first security state from each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S210). In other words, the first chiplet (100_1) may request proof of the first security state of the second chiplet (100_2) from the second chiplet (100_2), request proof of the first security state of the third chiplet (100_3) from the third chiplet (100_3), and request proof of the first security state of the fourth chiplet (100_4) from the fourth chiplet (100_4). The first chiplet (100_1) can request proof of the first security state from each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) simultaneously or sequentially.

[0103] For example, step S210 may be performed simultaneously when the integrity verification for each of the first to fourth chiplets (100_1 to 100_4) is successful, or step S210 may be performed in the order in which the integrity verification for each of the first to fourth chiplets (100_1 to 100_4) is successful. Additionally, for example, the first chiplet (100_1) may perform step S210 for any one chiplet that has successfully verified integrity, and then, after the first verification is successful (Yes in step S240), perform step S210 for another chiplet that has successfully verified integrity.

[0104] In response to a request from the first chiplet (100_1) in step S210, each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may generate first security status information based on a security key (1310) and transmit it to the first chiplet (100_1) (S220). Here, the first security status information may include at least one of the chiplet unique identifier, certificate (1350), firmware information, boot information, version information, or security setting (1330) of each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). Generating the first security state information based on the security key (1310) can be performed, for example, as described in FIG. 5, by each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) encrypting or signing their own certificate (1350) with their private key. A description of a configuration identical to that described in FIG. 5 is omitted.

[0105] To specifically describe the first security state information, the firmware information may include information about the firmware running inside each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4), the hash value of the firmware, etc.

[0106] Boot information may include, for example, the execution order of the bootloader for each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4), whether integrity is verified during booting, whether integrity is verified during booting, and the loaded state during booting.

[0107] Version information may include, for example, the version of the firmware running on each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4), chiplet silicon revision information, and a security patch level indicating the time of the latest security update.

[0108] The description of the chiplet unique identifier, security settings (1330), and certificate (1350) is omitted as it overlaps with the relevant descriptions in FIGS. 4a, 4b, and 5.

[0109] Referring again to FIG. 8, when the first security state information is received at step S220, the first chiplet (100_1) can verify the first security state information for each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S230). Verifying the first security state information can be performed by decrypting or verifying a signed certificate (1350) with a public key corresponding to the private key used for encryption or signing, for example, as described in FIG. 5. A description of a configuration identical to that described in FIG. 5 is omitted. This allows for checking whether the first security state information has been tampered with.

[0110] As a result of the first verification of the first security status information in step S230, if the first verification is successful (Yes in S240), the first chiplet (100_1) may allow the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) to continue the boot process (S251). Meanwhile, if the first verification fails (No in S240), the first chiplet (100_1) may disable at least one of the plurality of first interfaces (40), stop the boot process, and transmit log information regarding the boot failure to the host device (20) (S252). By doing so, security threats can be prevented and the integrity of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) can be maintained. In addition, by transmitting log information about the boot failure to the host device (20), it is possible to perform security analysis and identify the cause of the failure.

[0111] Steps S210, S220, S230, S240, and S251 or S252 of FIG. 8 may be performed in the same manner for each of the first to fourth chiplets (100_1 to 100_4). In the case of the first chiplet (100_1), a first verification of the first security state of the first chiplet (100_1) may be performed by a host device (20) or another external device. In this case, the description above for the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may be applied in the same way to the first chiplet (100_1). The first verification of the first security state of the first chiplet (100_1) may be performed in any one of steps S200 to S400 of FIG. 6, but the present disclosure is not limited thereto.

[0112] FIG. 9 is a flowchart illustrating a second verification process according to embodiments of the present disclosure. FIG. 9 is a flowchart specifically illustrating step S300 of FIG. 6.

[0113] While the boot process continues by step S251 of FIG. 8 (e.g., at the last step of the boot sequence), each of the first to fourth chiplets (100_1 to 100_4) can load boot firmware by the second bootloader (1320) (S310). Here, step S310 may be performed after all of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) have reached step S251, or after all of the first to fourth chiplets (100_1 to 100_4) have reached step S251. The boot firmware may be firmware or software that initializes the operating environment of the corresponding chiplet and enables a higher-level application or operating system to be executed.

[0114] After step S310, the first chiplet (100_1) may perform a second verification of the second security state of the boot firmware running on each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). The second security state may include the integrity state of the boot firmware running on each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). By performing the second verification of the second security state, the integrity of the boot firmware can be verified and security can be improved.

[0115] Referring to FIG. 9, the operation of the second verification is described in detail. First, the first chiplet (100_1) may request proof of the second security state from each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S320). In other words, the first chiplet (100_1) may request proof of the second security state of the boot firmware running in the second chiplet (100_2) from the second chiplet (100_2), request proof of the second security state of the boot firmware running in the third chiplet (100_3) from the third chiplet (100_3), and request proof of the second security state of the boot firmware running in the fourth chiplet (100_4) from the fourth chiplet (100_4). The first chiplet (100_1) can request proof of the second security state from each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) simultaneously or sequentially.

[0116] For example, the first chiplet (100_1) may perform step S320 simultaneously when step S310 is completed for each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4), or may perform step S320 in the order in which step S310 is completed for each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). Additionally, for example, the first chiplet (100_1) may perform step S320 for any one chiplet that has completed step S310, and then, after the second verification is successful (Yes in step S350), perform step S320 for another chiplet that has completed step S310.

[0117] In response to a request from the first chiplet (100_1) in step S320, each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may generate second security state information based on a security key (1310) and transmit it to the first chiplet (100_1) (S330). Here, the second security state information may include at least one of runtime information or integrity information of boot firmware executed in each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4). Generating the second security state information based on the security key (1310) may be performed by each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) encrypting or signing their own certificate (1350) with a private key, for example, as described in FIG. 5. A description of the same configuration as that described in Fig. 5 is omitted.

[0118] To specifically describe the second security state information, the runtime information of the boot firmware may include the operating status of the general core (2300), neural network hardware engine (2400), etc., and clock and voltage setting information while the boot firmware is running. Additionally, the runtime information of the boot firmware may include security-related state information during actual operation after booting, such as the boot firmware execution environment, processes active during execution, execution memory status, and operation logs.

[0119] Integrity information may include hash values ​​for the code and data areas of the boot firmware, signature verification results, or verification result values ​​obtained during the boot process.

[0120] Referring again to FIG. 9, when the second security state information is received at step S330, the first chiplet (100_1) can verify the second security state information for each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) (S340). Verifying the second security state information can be performed by decrypting or verifying a signed certificate (1350) with a public key corresponding to the private key used for encryption or signing, for example, as described in FIG. 5. A description of a configuration identical to that described in FIG. 5 is omitted. This allows for checking whether the second security state information has been tampered with.

[0121] As a result of the second verification of the second security status information in step S340, if the second verification is successful (Yes in S350), the first chiplet (100_1) may allow the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) to continue the boot process (S361). In other words, normal operation of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may be allowed. Meanwhile, if the second verification fails (No in S350), the first chiplet (100_1) may disable at least one of the plurality of first interfaces (40), stop the boot process, and transmit log information regarding the boot failure to the host device (20) (S362). Thus, the integrity of the boot firmware running on each of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) can be maintained. Additionally, by transmitting log information regarding boot failures to the host device (20), security analysis and identification of the cause of the failure can be made possible.

[0122] Steps S310, S320, S330, S340, S350, and S361 or S362 of FIG. 9 may be performed in the same manner on each of the first to fourth chiplets (100_1 to 100_4). In the case of the first chiplet (100_1), a second verification of the second security state of the boot firmware running on the first chiplet (100_1) may be performed by the host device (20) or another external device. In this case, the description above for the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) may be applied in the same way to the first chiplet (100_1). The second verification of the second security state of the boot firmware running on the first chiplet (100_1) may be performed in either step S300 or S400 of FIG. 6, but the present disclosure is not limited thereto.

[0123] FIG. 10 is a flowchart illustrating a third verification process according to embodiments of the present disclosure. FIG. 10 is a flowchart specifically illustrating step S400 of FIG. 6.

[0124] After the boot process is successfully completed by step S361 of FIG. 9, a third verification of the third security state of the electronic device (10) can be performed by the host device (20). Here, step S410 may be performed after all of the second chiplet (100_2), the third chiplet (100_3), and the fourth chiplet (100_4) have reached step S361, or after all of the first to fourth chiplets (100_1 to 100_4) have reached step S361.

[0125] Referring to FIG. 10, the operation of the third verification is described in detail. First, the host device (20) may request proof of the third security state from the first chiplet (100_1) (S410). The host device (20) may request proof of the third security state, for example, by transmitting a command stream to the first chiplet (100_1).

[0126] In response to a request from the host device (20) in step S410, the first chiplet (100_1) may generate third security state information based on the security key (1310) and transmit it to the host device (20) (S420). Here, the third security state information may include at least one of the first verification result or the second verification result of each of the first to fourth chiplets (100_1 to 100_4). Generating the third security state information based on the security key (1310) may be performed by the first chiplet (100_1) encrypting or signing its certificate (1350) with its private key, for example, as described in FIG. 5. A description of a configuration identical to the one described in FIG. 5 is omitted.

[0127] When the third security state information is received at step S420, the host device (20) can verify the third security state information for each of the first to fourth chiplets (100_1 to 100_4) (S430). In other words, the third security state information for the entire electronic device (10) including the first to fourth chiplets (100_1 to 100_4) can be verified. Verifying the third security state information can be performed by decrypting or verifying a signed certificate (1350) with a public key corresponding to the private key used for encryption or signing, for example, as described in FIG. 5. A description of a configuration identical to that described in FIG. 5 is omitted. This allows for checking whether the third security state information has been tampered with.

[0128] As a result of the third verification of the third security status information in step S430, if the third verification is successful (Yes in S440), the host device (20) may allow a connection with the electronic device (10) (S451). Meanwhile, if the third verification fails (No in S440), the host device (20) may disallow a connection with the electronic device (10) (S452). Disallowing a connection between the electronic device (10) and the host device (20) may include restricting or blocking the connection between the electronic device (10) and the host device (20). By doing so, security attacks on the entire electronic device (10) can be blocked and integrity maintained.

[0129] Although steps S410, S420, S430, S440, and S451 or S452 are illustrated in FIG. 10 as being performed between the host device (20) and the first to fourth chiplets (100_1 to 100_4), the present disclosure is not limited thereto. For example, if the third verification is successful (Yes at S440), the host device (20) may instruct only the first chiplet (100_1) to connect the electronic device (10) and the host device (20), and subsequently allow the electronic device (10) and the host device (20) to be connected. Additionally, if the third verification fails (No at S440), the host device (20) may instruct only the first chiplet (100_1) to restrict or block the connection between the electronic device (10) and the host device (20), and subsequently allow the connection between the electronic device (10) and the host device (20) to be restricted or blocked.

[0130] An embodiment in which a first verification of the first security state of the first chiplet (100_1) and a second verification of the second security state of the boot firmware executed on the first chiplet (100_1) are performed in step S400 may be performed after receiving a request for verification of the third security state information from the host device (20) in step S410, and before transmitting the third security state information to the host device (20) in step S420. However, the present disclosure is not limited thereto and may be configured in various ways within the scope of the problem to be solved by the present disclosure.

[0131] In the embodiments of the present disclosure, components expressed as 'part', 'unit', 'block', 'module', 'component', etc., may be implemented as hardware that performs a specific function. Such hardware may include, for example, a circuit that performs operations or a circuitry which is a set of interconnected circuits to perform complex functions. Here, 'part', 'unit', 'block', 'module', 'component', etc., perform a specific role and are not limited to software or hardware, but may be used to encompass components of software or hardware, data, or combinations thereof. Furthermore, structures, methods, operations, processes, algorithms, etc., according to the embodiments of the present disclosure may be implemented through various means such as hardware, firmware, software, or combinations thereof.

[0132] As explained above, a person skilled in the art of the present disclosure will recognize that the present disclosure may be implemented in various forms without altering its technical principles or core features. Accordingly, it should be understood that the above embodiments are merely illustrative and do not limit the scope of the present disclosure. The scope of the present disclosure is defined by the claims below rather than the detailed description, and all variations or modifications based on the meaning and scope of the claims and equivalent concepts should be interpreted as being included within the scope of the present disclosure.

[0133] The features and advantages described in this disclosure are only partial, and more additional features and advantages will become apparent to those skilled in the art upon reference to the drawings, specification, and claims. Furthermore, it should be noted that the language used in this disclosure has been chosen for readability and illustrative purposes and is not necessarily chosen to limit or describe the subject matter of this disclosure.

[0134] The description of the above embodiments is provided for illustrative purposes only and is not intended to limit the scope of the disclosure in its exact form. A person skilled in the art will understand that various modifications and variations are possible from the content of the disclosure.

[0135] Therefore, the scope of the present disclosure is not limited by the detailed description but is defined by the claims of the present disclosure. Accordingly, the embodiments of the present disclosure are exemplary and do not limit the scope of the present disclosure as set forth in the claims below.

Claims

Claim 1 An electronic device for authenticating the security status of a chiplet comprises a first chiplet and one or more second chiplets connected to each other by a first interface, wherein each of the first chiplet and the one or more second chiplets comprises a first bootloader that is executed when a boot process is initiated and an immutable memory that is programmed once, wherein the immutable memory stores a security key and a second bootloader that is executed by the first bootloader, wherein each of the first chiplet and the one or more second chiplets is configured to execute the first bootloader when the boot process is initiated, load the second bootloader by the first bootloader, perform an integrity verification for the second bootloader, and if the integrity verification is successful, execute the second bootloader, wherein if the integrity verification is successful in each of the first chiplet and the one or more second chiplets, the first chiplet is configured to perform a first verification for the first security status of each of the one or more second chiplets. An electronic device further configured. Claim 2 delete Claim 3 delete Claim 4 An electronic device according to claim 1, wherein the first verification is performed in such a manner that the first chiplet requests proof of the first security state from each of the one or more second chiplets, and in response to the request of the first chiplet, each of the one or more second chiplets generates first security state information based on the security key and transmits it to the first chiplet, and the first chiplet verifies the first security state information. Claim 5 An electronic device according to claim 4, wherein the first security status information comprises at least one of a chiplet unique identifier, a certificate, firmware information, boot information, version information, or security setting for each of the one or more second chiplets. Claim 6 An electronic device according to claim 1, wherein the first chiplet is further configured to allow each of the one or more second chiplets to continue the boot process if the first verification is successful, and to disable the first interface, stop the boot process, and transmit log information regarding the boot failure to a host device if the first verification fails. Claim 7 An electronic device according to claim 6, wherein, while the boot process continues, each of the first chiplet and each of the one or more second chiplets loads boot firmware by the second bootloader, and the first chiplet is further configured to perform a second verification of a second security state of the boot firmware executed on each of the one or more second chiplets. Claim 8 An electronic device according to claim 7, wherein the second verification is performed in such a manner that the first chiplet requests proof of the second security state from each of the one or more second chiplets, and in response to the request of the first chiplet, each of the one or more second chiplets generates second security state information based on the security key and transmits it to the first chiplet, and the first chiplet verifies the second security state information. Claim 9 An electronic device according to claim 8, wherein the second security status information comprises at least one of runtime information or integrity information of the boot firmware. Claim 10 An electronic device according to claim 7, wherein the first chiplet is further configured to allow each of the one or more second chiplets to complete the boot process if the second verification is successful, and to disable the first interface, stop the boot process, and transmit log information regarding the boot failure to the host device if the second verification fails. Claim 11 An electronic device according to claim 10, wherein the first chiplet is connected to the host device by a second interface, and after the boot process is completed, in response to a request for proof of the third security state of the electronic device from the host device, the first chiplet is further configured to generate third security state information based on the security key and transmit it to the host device. Claim 12 A method for authenticating the security status of a chiplet by an electronic device, wherein the electronic device comprises a first chiplet and one or more second chiplets connected to each other by a first interface, and each of the first chiplet and the one or more second chiplets comprises a first bootloader that is executed when a boot process is initiated and an immutable memory that is programmed once, wherein the immutable memory stores a security key and a second bootloader that is executed by the first bootloader, and the method comprises the steps of: executing the first bootloader when the boot process is initiated by each of the first chiplet and the one or more second chiplets, loading the second bootloader by the first bootloader, performing an integrity verification for the second bootloader, and if the integrity verification is successful, executing the second bootloader; and if the integrity verification is successful in each of the first chiplet and the one or more second chiplets, performing a first verification of the first security status of each of the one or more second chiplets by the first chiplet. A method comprising: a step of performing a second verification of a second security state of boot firmware executed on each of the one or more second chiplets by the first chiplet if the first verification is successful; and a step of performing a third verification of a third security state of the electronic device by a host device connected to the first chiplet by a second interface if the second verification is successful. Claim 13 A method according to claim 12, wherein the step of performing the first verification comprises: requesting proof of the first security state from each of the one or more second chiplets by the first chiplet; generating first security state information based on the security key by each of the one or more second chiplets in response to the request of the first chiplet and transmitting it to the first chiplet; and verifying the first security state information by the first chiplet. Claim 14 A method according to claim 12, further comprising: a step of, after the step of performing the first verification, if the first verification is successful, allowing each of the one or more second chiplets by the first chiplet to continue the boot process; and if the first verification fails, disabling the first interface by the first chiplet, stopping the boot process, and transmitting log information about the boot failure to the host device. Claim 15 A method according to claim 12, wherein the step of performing the second verification comprises: requesting proof of the second security state from each of the one or more second chiplets by the first chiplet; generating second security state information based on the security key by each of the one or more second chiplets in response to the request of the first chiplet and transmitting it to the first chiplet; and verifying the second security state information by the first chiplet. Claim 16 A method according to claim 12, further comprising: a step of, after the step of performing the second verification, if the second verification is successful, allowing each of the one or more second chiplets by the first chiplet to complete the boot process; and if the second verification fails, disabling the first interface by the first chiplet, stopping the boot process, and transmitting log information regarding the boot failure to the host device. Claim 17 In claim 12, the step of performing the third verification comprises: requesting the first chiplet by the host device for proof of the third security state of the electronic device; generating third security state information based on the security key by the first chiplet in response to the request of the host device and transmitting it to the host device; and verifying the third security state information by the host device. Claim 18 A method according to claim 12, further comprising: a step of allowing a connection between the electronic device and the host device by the host device if the third verification is successful, after the step of performing the third verification; and a step of disallowing a connection between the electronic device and the host device by the host device if the third verification fails.

Images