Three-dimensional stacked chip, distributed secure boot method and electronic device

Abstract

The application provides a three-dimensional stacked chip, a distributed security starting method and an electronic device. The three-dimensional stacked chip comprises a plurality of stacked units interconnected through a uniform chip particle interconnection interface and a central security controller. A hardware encryption engine and a security engine are configured in each stacked unit. The hardware encryption engine is used to establish an encrypted transmission link between adjacent stacked units by using an independent session key. In a serial security starting mode, the security engine of the upper-level stacked unit passes a hardware trust token to the lower-level stacked unit through the encrypted transmission link after local verification. The security engine of the lower-level stacked unit checks the token, and only after the check succeeds, the local security verification is performed, thereby constructing a hardware trust chain step by step. After all the units are verified, the central security controller starts the chip. The application realizes a cooperative security starting which takes into account high security and flexibility.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a three-dimensional stacked chip, a distributed secure boot method, and an electronic device. Background Technology

[0002] In the field of 3D stacked chips, with the development of heterogeneous integration technology, logic and memory layers typically achieve high-density vertical interconnects through hybrid bonding, and achieve lateral planar interconnects of multiple chips through the Universal Chip Interconnect Express (UCIe). While this architecture significantly improves performance and energy efficiency, it also introduces the complexity of multi-physical node collaborative initialization.

[0003] In multi-stacked interconnect architectures, permission management and trust verification for each chip node during the startup phase are crucial for overall security. However, related technologies lack a mechanism to establish distributed hardware trust among multiple physical nodes, leading to security risks in startup signaling and data interaction between nodes. Summary of the Invention

[0004] This application provides a three-dimensional stacked chip, a distributed secure boot method, and an electronic device, which can build a distributed hardware trust chain in the three-dimensional stacked chip to achieve collaborative secure boot that balances high security and flexibility.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a three-dimensional stacked chip, the three-dimensional stacked chip comprising: Multiple stacked units, which are interconnected via a unified chip interconnect interface; A central security controller is used to determine the secure startup mode of the three-dimensional stacked chip and to start the three-dimensional stacked chip when all of the multiple stacking units have passed local security verification. Multiple hardware encryption engines are configured in each of the stacking units. The hardware encryption engines in any two adjacent stacking units are used to establish an encrypted transmission link between the two adjacent stacking units. Different encrypted transmission links use different session keys for encryption. Multiple security engines are configured in each of the stacking units and are respectively connected to the central security controller and the hardware encryption engine in the stacking unit. When the secure boot mode is serial mode, in two adjacent stacking units, the security engine of the upper-level stacking unit is used to transmit the hardware trust token to the lower-level stacking unit via the encrypted transmission link; the security engine of the lower-level stacking unit is used to verify the hardware trust token and perform local security verification of the stacking unit after successful verification.

[0006] This application provides a distributed secure boot method applied to a three-dimensional stacked chip. The three-dimensional stacked chip includes a central security controller and multiple stacked units interconnected via a unified chip interconnect interface. Each stacked unit is configured with a hardware encryption engine and a security engine. The method includes: The central security controller determines the secure boot mode of the three-dimensional stacked chip. An encrypted transmission link is established between two adjacent stacked units using hardware encryption engines within any two adjacent stacked units, wherein different encrypted transmission links are encrypted using different session keys. When the secure boot mode is serial mode, the hardware trust token is transmitted to the next level stack unit via the encrypted transmission link through the security engine of the upper stack unit in two adjacent stack units. The hardware trust token is verified by the security engine of the next-level stacking unit, and local security verification is performed in the stacking unit after successful verification. With all of the stacked units having passed local security verification, the three-dimensional stacked chip is activated via the central security controller.

[0007] In the above scheme, the step of transmitting the hardware trust token to the next-level stacking unit via the encrypted transmission link includes: generating the hardware trust token through the security engine of the previous-level stacking unit after the local security verification of the stacking unit is passed; encrypting the hardware trust token based on the session key corresponding to the encrypted transmission link between the previous-level stacking unit and the next-level stacking unit through the hardware encryption engine of the previous-level stacking unit, and sending the encrypted hardware trust token via the encrypted transmission link; receiving the encrypted hardware trust token from the encrypted transmission link through the hardware encryption engine of the next-level stacking unit, decrypting the encrypted hardware trust token, and handing the decrypted hardware trust token over to the security engine of the stacking unit for verification.

[0008] In the above scheme, the method further includes: when the upper-level stacking unit is the first stacking unit, the security engine of the first stacking unit performs local security verification of the stacking unit first after the chip is powered on; when the lower-level stacking unit is not the last stacking unit, the security engine of the lower-level stacking unit generates a new hardware trust token after completing the local security verification of the stacking unit and continues to transmit it to the adjacent stacking unit via the encrypted transmission link; when the lower-level stacking unit is the last stacking unit, the security engine of the last stacking unit stops transmitting the hardware trust token after completing the local security verification of the stacking unit and outputs a global trust enable signal to the central security controller; the central security controller responds to the global trust enable signal and starts the three-dimensional stacked chip.

[0009] In the above scheme, the security engine includes a security processor, a physical function circuit, a programmable memory, and a cryptographic acceleration circuit. The step of generating the hardware trust token includes: generating a unique feature tag physically bound to the stack unit when the security engine is powered on using the physical function circuit; permanently storing the unique feature tag using the programmable memory; deriving a token working key based on the unique feature tag using the security processor; and generating the hardware trust token based on the token working key and the unique feature tag of the next-level stack unit using the cryptographic acceleration circuit.

[0010] In the above scheme, the verification of the hardware trust token includes: determining a target trust token based on the unique feature tag embedded in the programmable memory of the next-level stacking unit and the same token working key through the cryptographic acceleration circuit of the next-level stacking unit, and comparing the target trust token with the received hardware trust token; if the target trust token and the received hardware trust token are consistent, the security processor of the next-level stacking unit determines that the hardware trust token verification is successful.

[0011] In the above scheme, each stacked unit further includes a read-only memory that stores local boot code. The programmable memory also has a root public key pre-programmed inside. The local security verification includes: retrieving the root public key stored in the programmable memory through the cryptographic acceleration circuit, and performing hardware signature verification on the local boot code in the read-only memory based on the root public key; deriving a bare-chip level key based on the unique feature tag through the security processor, and scheduling the reading of external firmware after the hardware signature verification is passed; decrypting the external firmware based on the bare-chip level key through the cryptographic acceleration circuit, performing data integrity verification on the decrypted external firmware, and determining that the local security verification is passed after the data integrity verification is passed.

[0012] In the above scheme, the method further includes: when the security startup mode is in parallel mode, the security engines of multiple stacked units independently perform the local security verification and report the verification results to the central security controller; after receiving the results of the local security verification reported by the multiple stacked units, the central security controller starts the three-dimensional stacked chip.

[0013] In the above scheme, the method further includes: when the secure boot mode is a parallel grouping mode, dividing the multiple stacking units into at least two independent groups through the central security controller; within each group, performing local security verification through the security engine of the stacking unit within the group, and transmitting a hardware trust token to the next-level stacking unit within the group after successful verification, so as to complete the serial transmission within the group in sequence; through the security engine of the end stacking unit within the multiple groups, after passing the local security verification of the stacking unit, outputting group trust status signals in parallel to the central security controller respectively; through the central security controller, receiving the group trust status signals output by the multiple groups, and starting the three-dimensional stacking chip when all the group trust status signals are valid.

[0014] In the above scheme, the method further includes: when the secure boot mode is a serial group mode, the central security controller divides the multiple stacking units in normal operation into at least two independent groups and determines the serial transmission path between the groups; the security engine of the end stacking unit of the first group at the preceding position of the serial transmission path generates a group trust token for the first group and transmits the group trust token to the first stacking unit of the second group at the following position via the encrypted transmission link; the security engine of the first stacking unit of the second group verifies the received group trust token, and after the verification is successful, triggers the execution of local security verification of the stacking unit to enable intra-group serial transmission of the second group; after the at least two independent groups have passed the local security verification in sequence, the security engine of the stacking unit at the final end position of the serial transmission path outputs a global trust enable signal to the central security controller to start the three-dimensional stacking chip.

[0015] This application provides an electronic device, which includes a processor, wherein the processor includes the three-dimensional stacked chip described above.

[0016] The embodiments of this application have the following beneficial effects: Hardware encryption engines are configured within each stacking unit, and encrypted transmission links are established between any two adjacent stacking units via a unified chip interconnect interface, with different links using different session keys. This achieves end-to-end hardware encryption for cross-stacking unit communication, ensuring the security of information transmitted over the unified chip interconnect interface. Multiple security engines are configured within each stacking unit. In serial mode for secure boot, the security engine of the previous stacking unit transmits a hardware trust token to the next stacking unit, which then verifies the token. This mechanism constructs a distributed security verification process, ensuring trust transfer during the boot process of the 3D stacked chip. A central security controller is set up to determine the secure boot mode of the 3D stacked chip and boots the chip only after multiple stacking units have passed local security verification. This architecture provides a mechanism for unified scheduling and management of multiple stacking units, achieving flexible and reliable secure boot. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the physical structure of a single stacking unit in a three-dimensional stacked chip provided in the embodiments of this application; Figure 2 This is a functional block diagram of the three-dimensional stacked chip provided in the embodiments of this application; Figure 3This is a flowchart illustrating the distributed secure boot method provided in the embodiments of this application. Figure 1 ; Figure 4 This is a flowchart illustrating the distributed secure boot method provided in the embodiments of this application. Figure 2 ; Figure 5 This is a schematic diagram of the process for selecting the startup mode of the central security controller provided in an embodiment of this application; Figure 6 This is a schematic diagram of the topology of the trust transfer path between four stacked units in the fully serial startup mode provided in this application embodiment; Figure 7 This is a schematic diagram of the trust transfer topology after four stacked units are divided into two independent groups in the grouped serial startup mode provided in this application embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0020] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0021] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0022] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0023] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0024] 1) 3D Stacked Chip: refers to an integrated circuit that is formed by stacking multiple independent semiconductor dies or chips in the vertical direction through a three-dimensional integration process (such as hybrid bonding) and interconnecting them in the horizontal direction through a unified chip interconnect interface.

[0025] 2) Stacked Unit: refers to the basic physical and functional unit that constitutes a three-dimensional stacked chip. It can be formed by vertically stacking at least one logic die and one or more memory dies, and has relatively independent computing, storage or control capabilities.

[0026] 3) Logic Die (LD): A silicon wafer containing the main computing units, processing nodes, and logic control functions.

[0027] 4) Memory Die (MD): A silicon die containing data storage units that is highly sensitive to changes in the external temperature environment.

[0028] 5) Central Security Controller: This refers to the hardware control module configured within the 3D stacked chip, which is responsible for global security policy decisions, such as determining the secure boot mode, scheduling the boot order of each stacked unit, collecting verification results, and finally authorizing the boot of the entire chip.

[0029] 6) Security Engine: This refers to a collection of dedicated hardware modules integrated within each stack unit to perform local security-related tasks. These typically include security processors, physical function circuits, programmable memory, and cryptographic acceleration circuits.

[0030] 7) Hardware encryption engine: refers to the hardware cryptographic acceleration unit integrated inside each stack cell, which is dedicated to performing high-speed, real-time encryption, decryption and authentication operations on a unified core interconnect interface, and is used to establish encrypted transmission links between adjacent stack cells.

[0031] 8) Secure boot mode: refers to the overall process and topology followed by the three-dimensional stacked chips when performing security verification after power-on or reset, as determined by the central security controller, such as serial mode, parallel mode, parallel group mode or serial group mode.

[0032] 9) Local security verification: This refers to a series of hardware-level security verification processes performed by the security engine of each stack unit on the authenticity and integrity of its internal software and firmware. This is a prerequisite for the stack unit to obtain trust qualifications.

[0033] 10) Hardware Trust Token: In serial boot mode, a hardware trust token is an encrypted data credential generated by the previous stacking unit and transmitted to the next stacking unit via an encrypted transmission link. It is used to prove that the previous stacking unit has successfully completed local security verification.

[0034] 11) Encrypted transmission link: refers to an end-to-end logical communication channel established between two adjacent stack units through their respective hardware encryption engines and a unified core interconnect interface, where all transmitted data is encrypted and protected.

[0035] 12) Session key: refers to a one-time or temporary symmetric encryption key generated by the hardware encryption engines at both ends of the link through secure negotiation for a specific encrypted transmission link. Different encrypted transmission links use different session keys.

[0036] 13) Unique Feature Tag: A digital fingerprint generated by the physical function circuit within a stacked cell, uniquely bound to the physical microstructure of that stacked cell, and used as the hardware identity root of that stacked cell.

[0037] As integrated circuit technology advances towards 3D heterogeneous integration, vertically stacking functionally different units such as logic dies and memory dies (e.g., Dynamic Random-Access Memory (DRAM) dies) using hybrid bonding processes, and then horizontally interconnecting multiple such stacked units through a unified die interconnect interface, has become an important way to improve chip performance and integration. However, this complex architecture composed of multiple independent physical units also brings new challenges to chip boot security.

[0038] In related technologies, boot mechanisms are mostly designed for single, integrated chips. When applied to distributed architectures with multiple stacked units, significant technical problems arise: First, the physical interconnect links between units may become attack points. In the early stages of boot, firmware, configuration information, or control signaling transmitted across units in plaintext are easily eavesdropped or tampered with. Second, there is a lack of effective distributed trust establishment mechanisms. A stacked unit cannot effectively verify the legitimacy of the identity and the authenticity of the boot state of adjacent units at the hardware level, making it difficult to build a complete trust chain that starts from the hardware trust root and runs through the entire chip. Finally, the fixed boot process cannot adapt to dynamic working scenarios. For example, when some stacked units go into sleep mode due to power management or are isolated due to faults, the traditional boot process may be interrupted, causing the entire chip to fail to boot, lacking flexibility and robustness.

[0039] To address the aforementioned technical challenges in multi-stacked unit interconnect architectures, such as difficulties in establishing trust chains and rigid boot processes, embodiments of this application provide a three-dimensional stacked chip, a distributed secure boot method, and an electronic device. This enables the construction of a trusted, hierarchically transmitted hardware trust chain among multiple stacked units and supports dynamic reconstruction of the boot path based on the chip's operating state, thereby achieving collaborative secure boot that balances high security with dynamic flexibility.

[0040] Figure 1 This is a schematic diagram of the physical structure of a single stacked unit in a three-dimensional stacked chip provided in an embodiment of this application. For example... Figure 1 As shown, a stacking cell 10 may include at least two dies integrated via a three-dimensional stacking process (such as hybrid bonding). In one example, the stacking cell 10 may include a logic die 110 and at least one memory die 120. The logic die 110 may integrate functions such as a central processing unit, security control logic, and other peripheral interfaces, while the memory die 120 may provide high-bandwidth memory access.

[0041] It is necessary to understand that Figure 1 This is merely a schematic diagram of a single stacking unit 10 that constitutes a complete three-dimensional stacked chip. The three-dimensional stacked chip of this application embodiment can be formed by interconnecting multiple such stacking units on a plane through a unified chip interconnect interface, thus forming a complex, multi-node overall architecture.

[0042] Figure 2 This is a functional block diagram of the three-dimensional stacked chip provided in an embodiment of this application. For example... Figure 2As shown, the overall architecture of the three-dimensional stacked chip 200 includes a central security controller 210 and multiple stacking units 220 (stacking units 220-1 and 220-2 are shown as examples in the figure). The multiple stacking units 220 are physically interconnected via a Universal Chiplet Interconnect Express (UCIe) 230, forming a collaborative whole. Each stacking unit 220 is equipped with a security engine 221 and a hardware encryption engine 222.

[0043] The central security controller 210 is used to determine the secure boot mode of the three-dimensional stacked chip 200 and boot the three-dimensional stacked chip 200 after all multiple stacking units 220 have passed local security verification. Figure 2 As shown, the central security controller 210 is connected to each stack unit 220 (220-1, 220-2) via control links (solid lines with arrows) to implement scheduling and control functions.

[0044] Multiple hardware encryption engines 222 are configured within each stack cell 220. The hardware encryption engines 222 within any two adjacent stack cells (such as 220-1 and 220-2) are used to establish an encrypted transmission link between them. This encrypted transmission link is physically carried through a unified core interconnect interface 230. It should be noted that although only one interconnect link is shown in the figure, in an implementation with more stack cells, different encrypted transmission links will use different session keys for encryption.

[0045] Multiple security engines 221 are also configured in each stack unit 220 and are connected to the central security controller 210 (via an internal control bus not shown in detail in the figure) and the hardware encryption engine 222 in the stack unit respectively.

[0046] exist Figure 2In the serial mode of secure boot shown, in the two adjacent stacking units 220-1 and 220-2, the security engine 221 of the upper-level stacking unit 220-1 generates a hardware trust token after completing local verification. This token is first passed from the security engine 221 to the hardware encryption engine 222 within the unit. Subsequently, the hardware encryption engine 222 encrypts the hardware trust token and transmits it to the lower-level stacking unit 220-2 through the encrypted transmission link formed by the unified chip interconnect interface 230. The hardware encryption engine 222 of the lower-level stacking unit 220-2 receives the encrypted hardware trust token from the link, decrypts it, and hands it over to the security engine 221 of its own unit. The security engine 221 then verifies the received hardware trust token and, upon successful verification, performs local security verification within its own stacking unit 220-2. Through this series of steps, Figure 2 This application demonstrates how, in a three-dimensional stacked chip architecture, a distributed, hierarchical serial secure boot mechanism is achieved through the collaborative work of various functional modules.

[0047] In one embodiment, distributed secure boot of a 3D stacked chip is achieved through a mechanism that progressively transfers trust among multiple stacking units. The core of this mechanism lies in utilizing the security engine and hardware encryption engine configured within each stacking unit to perform sequential verification along an encrypted transmission link established through a unified chip interconnect interface, thereby securely extending boot trust to the entire 3D stacked chip.

[0048] Here, a stacking cell is the basic physical unit that makes up a three-dimensional stacked chip. See also Figure 1 A stacking unit 10 can be integrated from a logic die 110 and at least one memory die 120 using a three-dimensional stacking process (such as hybrid bonding). The logic die 110 typically integrates the main computing and control logic, while the memory die 120 provides storage functionality. In the embodiments of this application, functional modules such as a central security controller, a security engine, and a hardware encryption engine can all be integrated onto the logic die 110.

[0049] The central security controller is a hardware control unit configured within the 3D stacked chip. It determines the secure startup mode of the 3D stacked chip and, based on the verification status of multiple stacking units, ultimately decides whether to start the 3D stacked chip. A hardware trust token is an encrypted data credential passed between two adjacent stacking units to prove that the previous stacking unit has successfully completed local security verification. Hardware trust tokens are generated using cryptographic algorithms to ensure their unforgeability and tamper-proof nature.

[0050] In one embodiment, the central security controller determines the secure boot mode of the 3D stacked chip to be serial mode and specifies a clear boot sequence path. Hardware encryption engines within any two adjacent stacking units independently negotiate and store different session keys, establishing an end-to-end encrypted transmission link over the unified chip interconnect interface between them. The security engine of the preceding stacking unit, positioned before the boot sequence, generates a hardware trust token after completing local security verification. The hardware trust token is then passed to the hardware encryption engine of its respective stacking unit for encryption using the corresponding session key. The encrypted hardware trust token is sent to the next stacking unit via the encrypted transmission link. Upon receiving the encrypted data, the hardware encryption engine of the next stacking unit decrypts it using the same session key and passes the decrypted hardware trust token to its own security engine. The security engine of the next stacking unit verifies the received hardware trust token. If the verification is successful, it triggers the execution of local security verification within its stacking unit. This "generate-transmit-verify" process is repeated level by level along the preset path until the last stacking unit completes verification. Finally, the central security controller, after confirming that multiple stacking units have passed local security verification, starts the 3D stacked chip.

[0051] For example, in a three-dimensional stacked chip 200 comprising four stacking units (220-1 to 220-4), each stacking unit consists of a logic die and a memory die. A central security controller 210, a security engine 221, and a hardware encryption engine 222 are all integrated on the logic die of each stacking unit. The central security controller 210 configures the secure boot mode to serial mode and sets the boot path as: stacking unit 220-1 → stacking unit 220-2 → stacking unit 220-3 → stacking unit 220-4.

[0052] At startup, stack unit 220-1, as the first stack unit, has its security engine 221 perform local security verification first. Upon successful verification, security engine 221 generates a hardware trust token Token_2 for the next level (220-2). Hardware encryption engine 222 (on the logic die of 220-1) encrypts Token_2 using the session key K_12 negotiated with stack unit 220-2 and sends it via the unified chip interconnect interface 230.

[0053] The hardware encryption engine 222 of stacking unit 220-2 receives the encrypted data, decrypts it using K_12 to obtain Token_2, and hands it over to the security engine 221 of this unit. The security engine 221 verifies Token_2, and if the verification is successful, it triggers the local security verification of stacking unit 220-2.

[0054] Afterwards, once the local security verification is successful, the stacking unit 220-2 will generate a hardware trust token Token_3 for the stacking unit 220-3 and transmit it encrypted using an independent session key K_23.

[0055] This process proceeds sequentially until the final stacking unit 220-4 successfully verifies the hardware trust token Token_4 from 220-3 and completes its own local security verification. Upon completion of verification, stacking unit 220-4 reports its completion status to the central security controller 210. After receiving final confirmation, the central security controller 210 initiates the entire 3D stacked chip 200. In this way, hardware trust is securely and progressively transferred along a predetermined path, ensuring the integrity and reliability of the entire chip startup process.

[0056] In one embodiment, when the secure boot mode is serial, the security engine of the upper-level stacking unit generates a hardware trust token after successful local security verification within its stacking unit. The hardware encryption engine of the upper-level stacking unit encrypts the hardware trust token based on the session key corresponding to the encrypted transmission link between the upper-level and lower-level stacking units, and sends the encrypted hardware trust token via the encrypted transmission link. The hardware encryption engine of the lower-level stacking unit receives the encrypted hardware trust token from the encrypted transmission link, decrypts the encrypted hardware trust token, and submits the decrypted hardware trust token to the security engine of its stacking unit for verification.

[0057] Here, the session key is a one-to-one, temporary symmetric encryption key generated by the respective hardware encryption engines of any two adjacent stacked units through a security negotiation protocol (such as a key exchange protocol). This key is used only for the encrypted transmission link between the two units and is independent of other link keys, achieving link-level security isolation.

[0058] In one embodiment, the security engine of the upper-level stack unit generates a hardware trust token after confirming that the local security verification of its stack unit has been successfully passed. Passing the local security verification is a strict prerequisite for generating the hardware trust token, ensuring the validity of the trust chain. The hardware encryption engine of the upper-level stack unit retrieves a pre-stored unique session key corresponding to the encrypted transmission link between the upper-level stack unit and the lower-level stack unit. Subsequently, based on this session key, the hardware encryption engine encrypts the hardware trust token using a symmetric encryption algorithm (such as Advanced Encryption Standard (AES)) to generate an encrypted hardware trust token. The encrypted hardware trust token is encapsulated into a data packet and sent out via the encrypted transmission link formed by the unified chip interconnect interface. The hardware encryption engine of the lower-level stack unit receives this data packet from the encrypted transmission link. The hardware encryption engine uses the same session key stored locally as the upper-level stack unit to decrypt the received encrypted data to restore the original hardware trust token. Finally, the decrypted hardware trust token is directly transferred to the security engine of the stack unit for use in subsequent verification steps.

[0059] In some embodiments, to further enhance security, the hardware encryption engine can employ an encryption mode with associated data authentication, such as Galois / Counter Mode (GCM), when encrypting the hardware trust token. This mode provides confidentiality protection while also generating a message authentication code to verify the integrity and authenticity of the decrypted data, effectively resisting replay attacks and data tampering. After decryption, the hardware encryption engine of the next-level stack unit will first verify the authentication code; only after successful verification will the decrypted hardware trust token be handed over to the security engine.

[0060] Continuing with the example of four stacking units, when the startup process reaches the stage of transferring trust from stacking unit 220-1 to stacking unit 220-2: After local security verification is successful, the security engine 221 of stacking unit 220-1 generates a hardware trust token Token_2. The hardware encryption engine 222 of stacking unit 220-1 reads the session key K_12 corresponding to the encrypted transmission link established with stacking unit 220-2 from its internal secure storage area. The hardware encryption engine 222 calls its internal AES-GCM encryption circuit to encrypt Token_2 using the session key K_12, obtaining the encrypted ciphertext C_2 and a message authentication code Tag_2. The encrypted data packet {C_2, Tag_2} is sent to stacking unit 220-2 through the unified core interconnect interface 230. After receiving the data packet, the hardware encryption engine 222 of stacking unit 220-2 decrypts and authenticates C_2 and Tag_2 using the same locally stored session key K_12. After successful authentication, the hardware encryption engine 222 decrypts the plaintext Token_2 and transfers it to the security engine 221 of the stack unit 220-2 via the internal security bus for further verification. This process ensures that Token_2 remains encrypted throughout its transmission path from 220-1 to 220-2.

[0061] This application embodiment ensures the reliability of the trust chain credential source by limiting the generation of the hardware trust token to local security verification only by the security engine of the upper-level stacking unit. The hardware encryption engine of the upper-level stacking unit encrypts the hardware trust token based on the session key and sends the encrypted hardware trust token via an encrypted transmission link, ensuring the confidentiality of the trust credential during transmission. The hardware encryption engine of the lower-level stacking unit receives and decrypts the encrypted hardware trust token, and then passes the decryption result to the security engine of its own unit for verification. This constitutes a complete hardware-level security processing flow from encryption to decryption verification, ensuring the integrity and security of the entire transmission process.

[0062] In one embodiment, when the preceding stacking unit is the first stacking unit, the security engine of the first stacking unit is used to prioritize performing local security verification of the stacking unit after the chip is powered on; when the next stacking unit is not the last stacking unit, the security engine of the next stacking unit is used to generate a new hardware trust token and continue to transmit it to the adjacent stacking unit via the encrypted transmission link after completing the local security verification of the stacking unit; when the next stacking unit is the last stacking unit, the security engine of the last stacking unit is used to stop transmitting the hardware trust token and output a global trust enable signal to the central security controller after completing the local security verification of the stacking unit; the central security controller is also used to start the three-dimensional stacked chip in response to the global trust enable signal.

[0063] Here, the first stacking unit, in serial boot mode, is the first stacking unit in the boot sequence path designated by the central security controller to perform local security verification, marking the beginning of the entire hardware trust chain. The last stacking unit is the last stacking unit in the boot sequence path to perform local security verification, signifying the end of the trust chain. The global trust enable signal is a hardware status signal sent by the last stacking unit to the central security controller after successfully completing all verifications, indicating that the entire trust chain has been fully established.

[0064] In one embodiment, firstly, after the chip powers on and resets, the central security controller determines the startup path and designates the first stacking unit. The security engine of the first stacking unit does not wait for any external trust tokens but directly and preferentially performs its local security verification. Secondly, after the local security verification of the first stacking unit passes, its security engine generates a hardware trust token for the second stacking unit in the path and transmits it encrypted. Next, each non-terminal stacking unit (i.e., intermediate node) in the path, after successfully verifying the hardware trust token from its predecessor and completing its own local security verification, repeats a "bridging" action: generating a new hardware trust token for the next stacking unit and continuing its encrypted transmission. This process ensures that the trust chain continues downstream, hop by hop. Then, when the trust chain reaches the terminal stacking unit, its security engine, after successfully verifying and completing its own local security verification, changes its task: it no longer generates new hardware trust tokens but stops the trust transmission process. Simultaneously, the terminal stacking unit's security engine outputs a high-level signal or a specific hardware interrupt signal to the central security controller—a global trust enable signal. Finally, once the central security controller receives a valid global trust enable signal from the end stacking unit, it determines that the entire serial trust chain has been successfully established, and then triggers the subsequent process to start all functional units of the entire three-dimensional stacked chip.

[0065] In some embodiments, the global trust enable signal can be transmitted via a dedicated hardwired connection from the end stack unit to the central security controller to ensure low latency and high reliability of signal transmission. In some embodiments, the global trust enable signal can also be sent to the central security controller via a unified chip interconnect interface as a high-priority, encrypted message.

[0066] For example, continuing the previous example with four stacked units and a startup path of 220-1→220-2→220-3→220-4: After the chip powers on, the security engine 221 of 220-1, as the first stacked unit, prioritizes performing local security verification. Upon successful verification, it generates Token_2 and sends it to 220-2. 220-2, as a non-end stacked unit, after verifying Token_2 and completing its own local verification, generates a new hardware trust token Token_3 and sends it to 220-3. Similarly, 220-3, as a non-end stacked unit, generates Token_4 and sends it to 220-4 after completing its verification. 220-4, as the end stacked unit, after successfully verifying Token_4 and completing its own local security verification, its security engine 221 no longer generates any new tokens. Instead, the security engine 221 drives a signal pin to send a valid global trust enable signal to the central security controller 210. Upon receiving the signal, the central security controller 210 confirms that a complete trust chain from 220-1 to 220-4 has been established, and then starts the entire three-dimensional stacked chip 200, bringing it into normal operation. This process ensures that the chip can only be finally started after all stacked units on the preset path have passed verification in sequence without omission.

[0067] This application clearly defines the behavior of stacked units at different locations, constructing a complete and logically rigorous serial startup process. By stipulating that when the preceding stacked unit is the first stacked unit, its security engine prioritizes performing local security verification after the chip powers on, providing a reliable starting point for establishing the trust chain. When the next stacked unit is not the last stacked unit, its security engine, after completing local security verification, generates a new hardware trust token and continues to transmit it to adjacent stacked units via an encrypted transmission link, ensuring the continuity of the trust chain. When the next stacked unit is the last stacked unit, its security engine, after completing local security verification, stops transmitting the hardware trust token and outputs a global trust enable signal to the central security controller. Simultaneously, the central security controller responds to the global trust enable signal to start the 3D stacked chip, providing a clear endpoint and a decision basis for global startup for the entire serial verification process.

[0068] In one embodiment, the security engine includes a security processor, a physical function circuit, a programmable memory, and a cryptographic acceleration circuit. The physical function circuit generates a unique feature tag physically bound to the stack unit when the security engine is powered on. The programmable memory permanently stores the unique feature tag. The security processor derives a token working key based on the unique feature tag. The cryptographic acceleration circuit generates a hardware trust token based on the token working key and the unique feature tag of the next-level stack unit.

[0069] Here, the security processor is the core control unit within the security engine, such as a Reduced Instruction Set Computer V (RISC-V) core, used to schedule and manage the workflow of other circuits within the security engine. Physical function circuits are hardware circuits that utilize microscopic physical differences in the semiconductor manufacturing process to generate unique and unpredictable digital fingerprints, i.e., physically unclonable functions (PUFs). Programmable memory is a type of non-volatile memory that can only be programmed once, such as one-time programmable (OTP) memory, used to embed critical security information. Cryptographic acceleration circuits are hardware logic units dedicated to performing cryptographic operations such as symmetric encryption, hash calculations, and message authentication code generation.

[0070] In one embodiment, the hardware trust token generation process may specifically include the following steps: First, when the stack cell containing the security engine is powered on, the physical function circuit utilizes physical characteristics to generate a unique feature tag deeply bound to the hardware of that stack cell. This tag has the characteristics of being uncopyable and unpredictable. Second, during the chip manufacturing or initialization phase, the generated unique feature tag is burned into the programmable memory in a single operation. Due to the characteristics of programmable memory, once stored, the tag is permanently fixed and cannot be modified or erased, thus achieving a permanent binding between the unique feature tag and the stack cell. Next, when a hardware trust token needs to be generated, the security processor reads the unique feature tag fixed in the programmable memory. Based on this unique feature tag, the security processor derives the token working key used to generate the token through a Key Derivation Function (KDF). This derivation process is completed internally by the security processor, and the token working key is not stored or output in plaintext. Finally, the security processor provides the derived token working key, along with the pre-acquired unique feature tag of the target next-level stack unit (this tag can be distributed by the central security controller via a secure channel when configuring the startup path), to the cryptographic acceleration circuit. The cryptographic acceleration circuit invokes an internal message authentication code generation algorithm (such as a cryptographically based message authentication code (CMAC)) to calculate and generate the final hardware trust token based on the input token working key and the unique feature tag of the next-level stack unit.

[0071] In some embodiments, the security processor may also introduce other diversification factors, such as a random seed or salt value stored in programmable memory, when deriving the token working key to further enhance the randomness and security of the derived key. This scheme increases the difficulty of side-channel attacks or differential fault attacks targeting the key derivation process.

[0072] For example, when stacking unit 220-1 is preparing to generate a hardware trust token Token_2 for stacking unit 220-2: When stacking unit 220-1 is powered on, the physical function circuit within security engine 221 generates a unique feature tag, such as PUF_ID_1. PUF_ID_1 has been programmed into the programmable memory at the factory. After 220-1 completes local security verification, the security processor reads the stored PUF_ID_1 and derives the token working key K_Token_1 based on PUF_ID_1. At the same time, the security processor obtains the unique feature tag PUF_ID_2 of the next-level stacking unit 220-2 (this tag is pre-issued by the central security controller 210) from a security configuration register. The security processor passes K_Token_1 and PUF_ID_2 to the cryptographic acceleration circuit. The cryptographic acceleration circuit executes the CMAC algorithm, and the calculation process can satisfy the following formula (1).

[0073] Formula (1); in, It is a generated hardware trust token. This indicates the message authentication code algorithm. It is the input key, i.e., the token working key. It is a unique feature label for the target stacking unit used as message input. After calculation, the generated Token_2 is used in subsequent encryption and transmission processes. This process deeply binds the generation of the token to the hardware identity of the sender and receiver, ensuring the token's exclusivity and unforgeability.

[0074] This application embodiment generates a physically bound unique feature tag when the stacked unit is powered on via a physical function circuit, and permanently stores it in a programmable memory, establishing an unforgeable hardware identity root for each stacked unit. A security processor derives a token working key based on this unique feature tag, achieving secure derivation and management of the critical key and avoiding the risks associated with plaintext storage. A cryptographic acceleration circuit generates a hardware trust token based on the derived token working key and the unique feature tag of the next-level stacked unit, strongly binding the token's generation to the hardware identities of the sender and the intended receiver, ensuring the exclusivity and unforgeability of the hardware trust token.

[0075] In one embodiment, the cryptographic acceleration circuit of the next-level stack unit is used to determine the target trust token based on a unique feature tag embedded in the programmable memory of the next-level stack unit and the same token working key, and compare the target trust token with the received hardware trust token. If the target trust token matches the received hardware trust token, the security processor of the next-level stack unit determines that the hardware trust token verification was successful.

[0076] Here, the target trust token is a predicted token value for comparison, independently calculated and generated within the next-level stack unit by the cryptographic acceleration circuit using the same algorithm and input parameters as the token generated by the previous-level stack unit. The generation of this token depends entirely on the hardware information of the next-level stack unit itself and the key information securely obtained from the previous level.

[0077] In one embodiment, the verification process of the hardware trust token may specifically include the following steps: First, the security engine of the next-level stack unit initiates the verification process after receiving the decrypted hardware trust token from the hardware encryption engine. Second, the security processor of the next-level stack unit needs to obtain two key inputs for recalculating the target trust token: one is its own unique feature tag, which is read from the programmable memory and permanently stored locally; the other is the same token working key used by the previous-level stack unit when generating the token. This same token working key can be securely distributed by the previous-level stack unit to the security processor of the next-level stack unit via an encrypted transmission link through a secure protocol before or during the transmission of the trust token. Next, the security processor provides its own unique feature tag and the obtained token working key to the cryptographic acceleration circuit of its unit. The cryptographic acceleration circuit uses the same message authentication code algorithm (such as CMAC) as the previous-level stack unit to calculate and generate a target trust token locally based on these two input parameters. Subsequently, the cryptographic acceleration circuit or the security processor compares the locally generated target trust token bit by bit with the hardware trust token received from the previous level. Finally, if the comparison results are completely consistent, the security processor of the next-level stack unit determines that the hardware trust token verification was successful and allows the subsequent local security verification process to continue. If the comparison results are inconsistent, the verification is deemed to have failed, the startup process will be immediately aborted, and a corresponding security alarm may be triggered.

[0078] In some embodiments, to simplify key management, the token working key can be securely distributed to all relevant stacking units before startup by a global, trusted key distribution center (e.g., a central security controller), rather than being passed directly from one level to the next. This approach reduces direct key interactions between units, but may increase reliance on the central controller in some scenarios.

[0079] For example, after stacking unit 220-2 receives the hardware trust token Token_2 from 220-1, its verification process is as follows: The security processor of stacking unit 220-2 first reads its own unique feature tag PUF_ID_2 from the programmable memory of this unit. At the same time, the security processor obtains the same token working key K_Token_1 used by 220-1 when generating Token_2 through a secure internal mechanism. The security processor submits the two parameters PUF_ID_2 and K_Token_1 to the cryptographic acceleration circuit of this unit. The cryptographic acceleration circuit executes the same CMAC algorithm as 220-1 to calculate and generate the target trust token Target_Token_2 locally. The calculation process satisfies the following formula (2).

[0080] Formula (2); in, This is a locally generated target trust token. Subsequently, the cryptographic acceleration circuit compares the calculated Target_Token_2 with the received hardware trust token Token_2. Since the previous stage also used K_Token_1 and PUF_ID_2 when generating Token_2, Target_Token_2 should be completely identical to Token_2 if it has not been tampered with. After confirming the consistency of the comparison result, the security processor of stack unit 220-2 determines that the hardware trust token verification was successful.

[0081] This application's embodiments construct a reliable hardware trust token verification mechanism by performing local recalculation and comparison at the receiving end. First, the cryptographic acceleration circuit of the next-level stacking unit determines the target trust token based on a locally fixed unique feature tag and the same token working key, ensuring the independence of the verification process and its dependence on its own hardware identity. Second, by comparing the locally generated target trust token with the received hardware trust token, and with the security processor determining successful verification if both match, a precise cryptographic verification is achieved. This effectively identifies any forged or tampered trust tokens, thereby ensuring the authenticity and integrity of each step in the serial trust chain.

[0082] In one embodiment, each stacked unit further includes a read-only memory (ROM) containing local boot code, and the ROM also has a root public key pre-programmed inside. The cryptographic acceleration circuit is further configured to retrieve the root public key stored in the ROM and, based on the root public key, perform hardware signature verification on the local boot code in the ROM. The security processor is further configured to derive a die-level key based on a unique feature tag and, after successful hardware signature verification, schedule the reading of external firmware. The cryptographic acceleration circuit is further configured to decrypt the external firmware based on the die-level key, perform data integrity verification on the decrypted external firmware, and, after successful data integrity verification, determine that the local security verification has passed.

[0083] Here, Read-Only Memory (ROM) is a type of non-volatile memory where data is written during manufacturing and cannot be modified afterwards. It is used to embed the lowest-level, immutable local boot code. The root public key is an asymmetric encryption public key generated by a trusted manufacturer or licensor and burned into the programmable memory once before the chip leaves the factory. It is the highest trust anchor point in the entire software trust chain. The die-level key is a symmetric key derived by the security processor based on the unique feature tag of this stack unit, used to decrypt and verify external firmware. External firmware is encrypted program code stored in off-chip non-volatile memory (such as flash memory) used to perform higher-level initialization and functions.

[0084] In one embodiment, the detailed process of local security verification may include the following steps: Phase 1: Local Boot Code Verification. When a stacking unit is triggered to perform local security verification (e.g., after the first stacking unit powers on, or after a non-first stacking unit successfully verifies its token), the cryptographic acceleration circuit first reads the immutable root public key from the programmable memory. Simultaneously, the cryptographic acceleration circuit reads the local boot code and its associated digital signature stored in read-only memory. Based on the root public key, the cryptographic acceleration circuit performs hardware signature verification on the local boot code using an asymmetric signature algorithm (such as the Elliptic Curve Digital Signature Algorithm (ECDSA)).

[0085] Phase Two: External Firmware Loading and Verification. After successful hardware signature verification, the security processor is certain that the local boot code is authentic and has not been tampered with. At this point, the security processor derives a die-level key specific to this stack unit based on the unique identifier embedded in the programmable memory. Subsequently, the security processor schedules the off-chip memory controller to read the encrypted external firmware from the external storage medium. The cryptographic acceleration circuit obtains the derived die-level key and the read encrypted external firmware. Based on the die-level key, the cryptographic acceleration circuit performs a decryption operation on the external firmware. Simultaneously, the cryptographic acceleration circuit performs data integrity verification on the decrypted external firmware (e.g., by calculating a hash value or verifying the message authentication code). After the data integrity verification also passes, the security processor finally determines that this local security verification has passed.

[0086] In some embodiments, data integrity verification can be combined with the decryption process. For example, if the external firmware uses AES-GCM encryption, the cryptographic acceleration circuit can complete integrity and authenticity authentication simultaneously with decryption, improving verification efficiency.

[0087] For example, after stacking unit 220-2 verifies the hardware trust token Token_2 from 220-1, it begins local security verification: First, the cryptographic acceleration circuit of stacking unit 220-2 reads the root public key Root_PK from the programmable memory and performs hardware signature verification on the local boot code in the read-only memory. After the hardware signature verification is successful, the security processor reads the unique feature tag PUF_ID_2 of this unit and derives the die-level key K_Die_2. The security processor schedules the storage interface to read the encrypted external firmware Enc_FW_2 from the off-chip flash memory. The cryptographic acceleration circuit uses K_Die_2 to decrypt Enc_FW_2, obtaining the plaintext firmware FW_2. Simultaneously with decryption, the cryptographic acceleration circuit performs data integrity verification on FW_2. After the data integrity verification is successful, the security processor determines that the local security verification of stacking unit 220-2 is successful. At this point, stacking unit 220-2 is qualified to generate and pass trust tokens to the next node (220-3).

[0088] This application embodiment constructs a complete and robust local trust chain for each stacking unit, extending from the hardware root of trust to the external firmware, through a two-stage verification process. First, a cryptographic acceleration circuit performs hardware signature verification on the local boot code in read-only memory based on the fixed root public key, establishing an immutable software execution starting point. Second, after successful signature verification, the security processor derives a die-level key based on a unique feature tag and schedules the reading of the external firmware, ensuring controlled permissions and hardware binding of the key during subsequent firmware loading. Finally, the cryptographic acceleration circuit decrypts and verifies the data integrity of the external firmware based on the die-level key, and upon successful verification, determines that the local security verification is successful, securely extending trust from the underlying boot code to the higher-level application firmware.

[0089] In one embodiment, when the secure boot mode is in parallel mode, the security engines of multiple stacked units are used to independently perform local security verification and report the verification results to the central security controller. The central security controller, upon receiving reports of successful local security verification from the multiple stacked units, initiates the 3D stacked chip.

[0090] Here, the parallel mode is a secure boot mode determined by the central security controller. In this mode, all stacked units participating in the boot process no longer follow the sequential dependency of serially passing trust tokens, but instead concurrently and independently execute their respective local security verification processes within the same time window.

[0091] In one embodiment, the secure boot process in parallel mode may include the following steps: First, after the chip powers on and resets, the central security controller determines the secure boot mode as parallel mode and broadcasts a boot command to all designated stacking cells. Upon receiving the boot command, the security engines of multiple stacking cells independently and simultaneously begin performing local security verification. The specific content of the local security verification can be the same as the process in the serial mode described above, including hardware signature verification of the local boot code, as well as decryption and integrity verification of the external firmware. After each stacking cell completes its local security verification, regardless of success or failure, the security engine reports the verification result to the central security controller via the internal bus or unified chip interconnect interface. The verification result can be a simple status signal (e.g., high level for success, low level for failure) or a status word containing more detailed diagnostic information. The central security controller continuously collects verification results from all stacking cells. Finally, the central security controller only starts the 3D stacked chip after confirming that it has received the results of successful local security verification reported by all participating stacking cells. If any stacking unit reports a verification failure, or fails to report a result within the preset timeout period, the central safety controller will abort the startup process and may enter a safety lockout or fault handling state.

[0092] In some embodiments, to manage the reported verification results, the central security controller may have an internal status register, which assigns a status bit to each stack unit. After each stack unit completes verification, it updates the corresponding status bit through a write operation. The central security controller determines whether all stack units have successfully reported by periodically checking the value of this register.

[0093] For example, in a three-dimensional stacked chip 200 containing four stacked units (220-1 to 220-4), the central security controller 210 determines the secure boot mode as a parallel mode. After the chip powers on, the central security controller 210 simultaneously sends boot commands to the security engines of stacked units 220-1, 220-2, 220-3, and 220-4. Upon receiving the commands, each of the four security engines independently performs local security verification. For example, the security engine 220-1 begins verifying its own boot code and firmware, while the security engine 220-2 is doing the same thing, with no dependency between them. Suppose that at some point, 220-1, 220-3, and 220-4 have all completed their local security verification and reported the verification results (successfully) to the central security controller 210. At this time, the central security controller 210 is still in a waiting state because it has not yet received the result from 220-2. Later, after stacking unit 220-2 completes its local security verification and reports its successful result, the central security controller 210 confirms that it has received the local security verification results reported by multiple stacking units (i.e., all four). At this point, the central security controller 210 will activate the three-dimensional stacking chip 200 and put it into normal working condition.

[0094] This application provides an efficient parallel secure boot mechanism. By having the security engines of multiple stacked units independently perform local security verification, the waiting and dependencies between units in serial mode are eliminated, enabling the security verification process of all stacked units to be executed concurrently, thereby significantly shortening the overall chip boot time. Simultaneously, by reporting the verification results to a central security controller, which then starts the three-dimensional stacked chip after receiving the locally verified results from multiple stacked units, a centralized verification result aggregation and decision point is established. This mechanism ensures that the entire chip can only be booted after all participating stacked units have independently proven their security, thus maintaining the integrity and security of the boot process while ensuring high efficiency.

[0095] In one embodiment, when the secure boot mode is a parallel grouping mode, the central security controller is further configured to divide the multiple stacked units into at least two independent groups. Within each group, the security engine of the stacked unit within the group performs local security verification and, upon successful verification, passes a hardware trust token to the next-level stacked unit within the group, thereby completing the serial transmission within the group. The security engines of the end stacked units within the multiple groups, after passing the local security verification of their respective stacked units, output group trust status signals in parallel to the central security controller. The central security controller is further configured to receive the group trust status signals output by the multiple groups and, if all group trust status signals are valid, initiate the three-dimensional stacked chip.

[0096] Here, the parallel grouping mode is a hybrid secure boot mode determined by the central security controller. This mode divides the entire stacked cell set of the chip into several subsets (i.e., groups). Groups are started in parallel, while each group uses a serial trust chain transmission method. The group trust status signal is a status signal sent by the last stacked cell in each group to the central security controller after completing the verification of all nodes in the group, indicating that the group has successfully established a complete trust chain.

[0097] In one embodiment, the secure boot process in parallel grouping mode may include the following steps: First, when the chip powers on or needs to boot, the central security controller divides multiple stacked units into at least two independent groups according to a preset topology or real-time operating conditions, and assigns a serial transmission path within each group. Second, the central security controller simultaneously issues a boot command to the first stacked unit in each group. Next, within each group, the boot process is similar to the serial mode: the security engine of the stacked unit within the group sequentially performs local security verification, and after successful verification, transmits a hardware trust token to the next-level stacked unit within the group to complete the serial transmission within the group. Then, when the last stacked unit in each group successfully passes the local security verification of its stacked unit, the security engine of that last stacked unit outputs a valid group trust status signal to the central security controller in parallel. The central security controller is responsible for receiving and latching the group trust status signals output from multiple groups. Finally, after confirming that it has received all valid group trust status signals output from all groups, the central security controller starts the three-dimensional stacked chip.

[0098] In another embodiment, the central security controller can divide the groups based on physical location, functional correlation, or power consumption domain. For example, stacked units located in the same power supply area can be grouped together, allowing for rapid verification within the group after the entire area is powered on.

[0099] For example, in a three-dimensional stacked chip 200 containing four stacked cells (220-1 to 220-4), the central security controller 210 determines the secure boot mode as a parallel grouping mode. The central security controller divides the four cells into two independent groups: Group 1 contains 220-1 and 220-2, with an intra-group pass-through path of 220-1→220-2; Group 2 contains 220-3 and 220-4, with an intra-group pass-through path of 220-3→220-4. Upon boot, the central security controller 210 simultaneously issues boot commands to the first cell 220-1 of Group 1 and the first cell 220-3 of Group 2. Within each group, intra-group serial pass-through begins: In group 1, the security engine of 220-1 performs local security verification, and after successful verification, passes the hardware trust token to 220-2. 220-2 verifies the token and passes the local verification.

[0100] Meanwhile, in Group 2, the security engine of 220-3 performs local security verification, and upon successful verification, transmits the hardware trust token to 220-4. 220-4 verifies the token and passes the local verification. When the end stacking unit 220-2 of Group 1 completes its local security verification, its security engine outputs a valid Group 1 trust status signal in parallel to the central security controller 210. When the end stacking unit 220-4 of Group 2 completes its local security verification, its security engine also outputs a valid Group 2 trust status signal in parallel to the central security controller 210. The central security controller 210 receives these two group trust status signals and, upon confirming that both signals are valid, activates the three-dimensional stacked chip 200.

[0101] This application's embodiments achieve an effective balance between startup efficiency and security depth through a hybrid mode combining parallel and serial processing. First, by dividing multiple stacked units into at least two independent groups using a central security controller, these groups can be started in parallel, reducing overall startup latency. Second, by stipulating that each stacked unit within a group performs local security verification before passing a hardware trust token to the next-level stacked unit within the group, serial transmission within the group is completed, preserving the strict security of step-by-step verification in serial mode and ensuring the integrity of the trust chain within each group. Finally, by having the end stacked units within multiple groups output group trust status signals to the central security controller in parallel, and the central security controller starting the three-dimensional stacked chip upon receiving multiple valid group trust status signals, a distributed verification and centralized decision-making mechanism is established. This mechanism leverages the advantages of parallel processing while ensuring that the entire chip can only be started after all independent security domains (groups) have been confirmed secure.

[0102] In one embodiment, when the secure boot mode is serial packet mode, the central security controller is further configured to divide the multiple stacking units in normal operation into at least two independent packets and determine the serial transmission path between the packets. The security engine of the end stacking unit of the first packet, located at the beginning of the serial transmission path, generates a packet trust token for the first packet and transmits the packet trust token via an encrypted transmission link to the first stacking unit of the second packet, located at the end of the serial transmission path. The security engine of the first stacking unit of the second packet verifies the received packet trust token and, upon successful verification, triggers the execution of local security verification within its stacking unit to initiate intra-group serial transmission of the second packet. After at least two independent packets have sequentially passed local security verification, the security engine of the final stacking unit in the serial transmission path outputs a global trust enable signal to the central security controller to activate the three-dimensional stacked chip.

[0103] Here, the serial packet mode is a secure startup mode determined by the central security controller and specifically designed for dynamic reconfiguration. This mode divides active stack cells into packets and establishes a macroscopic serial trust chain between these packets. A packet trust token is a special hardware trust token generated by the end stack cell of a packet, used to prove to the first stack cell of the next packet that the previous packet as a whole has successfully completed the internal trust chain verification.

[0104] In one embodiment, the secure boot process in serial packet mode may specifically include the following steps: First, the central security controller identifies all stacking units in normal operating condition and divides them into at least two independent groups. Simultaneously, the central security controller determines a defined serial transmission path connecting these groups. Second, the startup process begins with the first group in the serial transmission path. Within this group, hardware trust tokens are transmitted serially according to standard intra-group serial methods. When the end stacking unit of the first group (i.e., the first group) successfully completes local security verification, its security engine generates a group trust token representing the trust state of the entire first group. This group trust token is then transmitted via an encrypted transmission link to the first stacking unit of the next group in the serial path (i.e., the second group). The security engine of the first stacking unit of the second group verifies the received group trust token.

[0105] Upon successful verification, the unit is triggered to perform local security verification, thereby initiating the intra-group serial transmission process within the second group. This "inter-group transmission - intra-group transmission" process proceeds sequentially along the preset group serial path. Finally, when the stacking unit at the final end of the serial transmission path (i.e., the end unit of the last group) also successfully completes its local security verification, its security engine outputs a global trust enable signal to the central security controller. The central security controller responds to this signal and activates the 3D stacked chip.

[0106] In another embodiment, when dividing the group, the central security controller can dynamically skip stacked cells that are detected as being in a dormant or faulty state, and only include normally operating cells in the group and serial transmission path, thereby achieving adaptation to the chip hardware state.

[0107] For example, in a three-dimensional stacked chip 200 containing four stacking units (220-1 to 220-4), the central security controller 210 detects that 220-3 is in a sleep state. The central security controller divides 220-1, 220-2, and 220-4, which are in normal operation, into two independent groups: Group 1 contains 220-1 and 220-2; Group 2 contains only 220-4. The serial transmission path between the groups is determined to be: Group 1 → Group 2. Upon startup, Group 1 first performs intra-group serial transmission: after 220-1 verifies successfully, it transmits a hardware trust token to 220-2. When 220-2, as the end stacking unit of the first group, completes local security verification, its security engine generates a group trust token representing Group 1. This group trust token is then transmitted to 220-4, the first stacking unit of the second group. The security engine of 220-4 verifies the received group trust token. After successful verification, 220-4 triggers the execution of local security verification within its stacking unit. Since Group 2 has only one unit, the intra-group serial transmission is completed immediately. After at least two independent groups (i.e., Group 1 and Group 2) have passed local security verification in sequence, the security engine of stacking unit 220-4, which is at the final end of the serial transmission path, outputs a global trust enable signal to the central security controller. Upon receiving the signal, the central security controller 210 activates the three-dimensional stacked chip.

[0108] This application embodiment provides powerful dynamic adaptability and startup path reconfiguration capabilities through a hierarchical serial startup mechanism. By dividing multiple stacked units in normal operation into at least two independent groups by a central security controller and determining the serial transmission path between groups, the startup process can dynamically adapt to scenarios where some stacked units are dormant or malfunctioning, ensuring chip availability. A group trust token is generated by the security engine of the last stacked unit in the first group and transmitted to the first stacked unit in the second group. The security engine of the first stacked unit in the second group then verifies the group trust token and initiates intra-group serial transmission within the second group. This model encapsulates and transmits intra-group trust states, simplifying the complexity of cross-group trust verification. Finally, after at least two independent groups have passed local security verification sequentially, the security engine of the final stacked unit outputs a global trust enable signal to the central security controller to start the 3D stacked chip. This ensures that even under dynamically reconfigured paths, the entire startup process still follows a complete, orderly, and ultimately convergent verification closed loop to the central controller, guaranteeing the integrity and security of the startup process.

[0109] In one embodiment, the security engine includes a security processor, a programmable memory, and a cryptographic acceleration circuit. The programmable memory internally stores a unique feature tag bound to the physical characteristics of its stacking unit. Specifically, the security processor of the end stacking unit of the first group is used to derive a group root key representing the first group. The cryptographic acceleration circuit of the end stacking unit of the first group is used to generate a group trust token based on the group root key and the unique feature tag of the first stacking unit of the second group. The cryptographic acceleration circuit of the first stacking unit of the second group is used to generate a target group trust token based on the unique feature tag of the first stacking unit and the group root key, and compare the target group trust token with the received group trust token to complete the verification.

[0110] Here, the group root key is a symmetric key derived from the secure processor of the end stacking unit of a packet, representing the overall trust state of that packet. The generation of this group root key can be based on the unique feature tag of the end unit itself, or by combining the identity information of all units within the packet, to ensure its strong association with the packet. The target packet trust token is an expected value, independently computed by the cryptographic acceleration circuitry within the first stacking unit of the second packet, used for comparison with the received packet trust token.

[0111] In one embodiment, the generation and verification process of the group trust token may specifically include the following steps: First, after the end stacking unit of the first packet completes local security verification, its security processor, based on the unique feature tag embedded in the programmable memory within the end stacking unit, derives a group root key representing the first packet using a specific key derivation algorithm. Second, the security processor provides the derived group root key, along with the pre-acquired unique feature tag of the first stacking unit of the second packet, to the cryptographic acceleration circuit of this unit. The cryptographic acceleration circuit of the end stacking unit of the first packet, based on the input group root key and the unique feature tag of the first unit of the second packet, generates a packet trust token using a message authentication code algorithm (such as CMAC). This packet trust token is then encrypted and transmitted to the first stacking unit of the second packet. After receiving and decrypting the packet trust token, the security processor of the first stacking unit of the second packet needs to obtain the group root key used to recalculate the target token. This group root key can be securely distributed by the end stacking unit of the first packet via an encrypted transmission link through a secure protocol.

[0112] Next, the security processor of the first unit of the second block provides the acquired group root key and its locally stored unique identifier to the cryptographic acceleration circuit of this unit. Based on these two inputs, the cryptographic acceleration circuit of the first unit of the second block uses the same algorithm as the end unit of the first block to locally calculate and generate a target block trust token. Finally, the cryptographic acceleration circuit or security processor compares the locally generated target block trust token with the received block trust token to complete the verification.

[0113] For example, continuing the aforementioned dormancy of 220-3, an example of group 1 (220-1, 220-2) transferring trust to group 2 (220-4): After 220-2, as the end stacking unit of the first group, completes local security verification, its security processor derives a group root key K_Group_1 representing group 1 based on its own unique feature tag PUF_ID_2. The cryptographic acceleration circuit of 220-2 generates a group trust token Token_G2 based on the derived K_Group_1 and the pre-acquired unique feature tag PUF_ID_4 of the first stacking unit of the second group (i.e., 220-4). The calculation can satisfy the following formula (3).

[0114] Formula (3); Token_G2 is encrypted and sent to 220-4. After receiving and decrypting it, 220-4's security processor securely obtains the group root key K_Group_1. 220-4's cryptographic acceleration circuit, based on the locally fixed unique feature tag PUF_ID_4 and the obtained K_Group_1, generates a target group trust token Target_Token_G2 locally. The calculation can satisfy the following formula (4).

[0115] Formula (4); Subsequently, the cryptographic acceleration circuit compares the target block trust token Target_Token_G2 with the received block trust token Token_G2 to complete the verification. If they match, the verification is successful.

[0116] This application provides a specific, cryptographically-based secure implementation mechanism for cross-group trust transfer in a serial packet mode. First, a group root key representing the first packet is derived from the secure processor of the end stacking unit of the first packet, creating a unified, cryptographically transmittable cryptographic credential root for the trust state of the entire packet. Second, a packet trust token is generated by the cryptographic acceleration circuit of the end stacking unit of the first packet based on the group root key and the unique feature tag of the first stacking unit of the second packet. This strongly binds the overall trust state of the packet to the hardware identity of the next packet, ensuring the exclusivity and directionality of the packet trust token. Finally, a target packet trust token is generated by the cryptographic acceleration circuit of the first stacking unit of the second packet based on the unique feature tag of the first stacking unit and the group root key. The target packet trust token is compared with the received packet trust token to complete the verification, establishing a reliable cross-group verification method. This method effectively prevents forgery and redirection attacks on packet trust tokens, ensuring that each step of the macro-trust chain is secure and trustworthy in the dynamic reconstruction startup path.

[0117] In one embodiment, the central security controller is further configured to acquire power supply status signals, clock status signals, and reset status signals of multiple stacked cells. The central security controller is also configured to perform periodic heartbeat detection on the multiple stacked cells through a unified chip interconnect interface to obtain periodic heartbeat signals. The central security controller is further configured to determine that a stacked cell is in a sleep-down or fault state if the power supply status signal, clock status signal, or reset status signal indicates an anomaly, or if a periodic heartbeat signal is missing. The central security controller is further configured to determine the secure boot mode as serial grouping mode if it is determined that some stacked cells are in a sleep-down or fault state.

[0118] Here, the power supply status signal, clock status signal, and reset status signal are hardware signals generated by the Power Management Unit (PMU), clock control unit, and reset control unit within each stacking cell, directly reflecting the basic hardware operating status of that cell. Periodic heartbeat detection is an online status detection mechanism proactively initiated by the central security controller. The central security controller sends a specific query request message to one or more target stacking cells at a preset fixed time period through the unified chip interconnect interface. If the target stacking cell's communication interface and internal logic are both in normal working order, it will generate and return a corresponding response message upon receiving the query request. The periodic heartbeat signal refers to the response message successfully received by the central security controller within the expected timeout window and returned by the target stacking cell.

[0119] In one embodiment, the process by which the central security controller dynamically determines the secure boot mode may specifically include the following steps: First, before the startup process begins, the central safety controller uses dedicated hardware detection circuitry to collect power supply status signals, clock status signals, and reset status signals from multiple stacking units in real time. Simultaneously, the central safety controller initiates periodic heartbeat detection to all stacking units that should theoretically be active through a unified chip interconnect interface, and detects the return of the periodic heartbeat signals. The central safety controller performs comprehensive analysis of the collected signals. If any of the power supply status signals, clock status signals, or reset status signals indicates an abnormal state (e.g., low power supply voltage, clock loss, or continuous reset), or if a periodic heartbeat signal from a stacking unit is missing within a preset timeout window, the central safety controller determines that the stacking unit is in a dormant, power-off state or a fault state.

[0120] After determining the status of all stacked cells, the central safety controller makes a decision. If some (but not all) of the stacked cells are determined to be in a dormant, power-off, or faulty state, the central safety controller will automatically determine the safe startup mode as serial grouping mode. Subsequently, based on the set of stacked cells determined to be in normal operating condition, the central safety controller will perform the grouping and serial path determination as described in the above embodiments and initiate the corresponding safe startup process.

[0121] In another embodiment, if the central security controller determines that all stacked units are in normal operation, it can determine the security startup mode as either a fully serial mode (pursuing the highest security) or a fully parallel mode (pursuing the highest efficiency) according to a preset default strategy.

[0122] For example, in a three-dimensional stacked chip 200 containing four stacked cells (220-1 to 220-4), before startup, the central safety controller acquires normal power supply status signals, clock status signals, and reset status signals for cells 220-1, 220-2, and 220-4. However, the power supply status signal for cell 220-3 is characterized as "deep sleep". Simultaneously, the central safety controller performs periodic heartbeat detection on the four cells via a unified chip interconnect interface. It receives valid periodic heartbeat signals from cells 220-1, 220-2, and 220-4, but lacks a periodic heartbeat signal from cell 220-3. Based on the abnormal power supply status signal characterization (deep sleep) and the missing periodic heartbeat signal, the central safety controller determines that stacked cell 220-3 is in a sleep-down or fault state. Since only some stacked cells (220-3) are in a sleep-down or fault state, the central safety controller automatically determines the safe startup mode as serial grouping mode. Subsequently, the central security controller will plan the grouping and startup paths based on the remaining normal units (220-1, 220-2, 220-4).

[0123] This application provides a three-dimensional stacked chip with environmental awareness and adaptive startup strategy capabilities, significantly enhancing the robustness and flexibility of the startup process. A comprehensive, multi-dimensional hardware status monitoring mechanism is established by having a central security controller collect power supply status signals, clock status signals, and reset status signals from multiple stacked units, and by performing periodic heartbeat detection on multiple stacked units through a unified chip interconnect interface. By identifying anomalies in power supply status signals, clock status signals, and reset status signals, or by detecting missing periodic heartbeat signals, the mechanism determines whether a stacked unit is in a dormant, power-off, or faulty state, providing the central security controller with accurate and reliable decision-making support. By determining that some stacked units are in a dormant, power-off, or faulty state, the security startup mode is set to a serial grouping mode, achieving an intelligent startup strategy selection. This mechanism enables the three-dimensional stacked chip to automatically bypass inactive units, establishing an effective trust chain only among the remaining normal units, thereby avoiding the problem of the entire chip failing to start due to local faults or dormancy, improving chip availability and adaptability to dynamic operating environments.

[0124] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating the distributed secure boot method provided in the embodiments of this application. Figure 1The distributed secure boot method provided in this application embodiment is applied to the three-dimensional stacked chip 200 in the above embodiment. The three-dimensional stacked chip 200 includes a central security controller 210 and multiple stacked units 220 interconnected through a unified chip interconnect interface 230. Each stacked unit 220 is configured with a hardware encryption engine 222 and a security engine 221.

[0125] In step 301, the safe boot mode of the three-dimensional stacked chip is determined by the central security controller.

[0126] In step 302, an encrypted transmission link is established between two adjacent stacking units using the hardware encryption engine within any two adjacent stacking units.

[0127] Different encrypted transmission links use different session keys for encryption.

[0128] In step 303, when the secure boot mode is serial mode, the hardware trust token is transmitted to the next level stack unit via an encrypted transmission link through the security engine of the upper level stack unit in the two adjacent stack units.

[0129] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating the distributed secure boot method provided in the embodiments of this application. Figure 2 In step 303, the hardware trust token is transmitted to the next level stack unit via an encrypted transmission link through the security engine of the upper level stack unit in two adjacent stack units, which may include the following steps 3031 to 3033.

[0130] In step 3031, a hardware trust token is generated after the local security verification of the stack unit is passed through the security engine of the previous stack unit.

[0131] In some embodiments, the security engine includes a security processor, physical function circuitry, programmable memory, and cryptographic acceleration circuitry. In step 3031, generating a hardware trust token can also be achieved in the following ways: the physical function circuitry generates a unique feature tag physically bound to the stacking unit when the security engine is powered on; the programmable memory permanently stores the unique feature tag; the security processor derives a token working key based on the unique feature tag; and the cryptographic acceleration circuitry generates a hardware trust token based on the token working key and the unique feature tag of the next-level stacking unit.

[0132] In step 3032, the hardware trust token is encrypted using the hardware encryption engine of the previous stacking unit, based on the session key corresponding to the encrypted transmission link between the previous and next stacking units, and the encrypted hardware trust token is sent via the encrypted transmission link.

[0133] In step 3033, the hardware encryption engine of the next-level stacking unit receives the encrypted hardware trust token from the encrypted transmission link, decrypts the encrypted hardware trust token, and submits the decrypted hardware trust token to the security engine of the stacking unit for verification.

[0134] In some embodiments, the distributed secure boot method provided in this application can also be implemented in the following ways: when the upper-level stacking unit is the first stacking unit, the security engine of the first stacking unit performs local security verification of the stacking unit first after the chip is powered on; when the lower-level stacking unit is not the end stacking unit, the security engine of the lower-level stacking unit generates a new hardware trust token after completing the local security verification of the stacking unit and continues to transmit it to the adjacent stacking unit via the encrypted transmission link; when the lower-level stacking unit is the end stacking unit, the security engine of the end stacking unit stops transmitting the hardware trust token after completing the local security verification of the stacking unit and outputs a global trust enable signal to the central security controller; the central security controller responds to the global trust enable signal and starts the three-dimensional stacked chip.

[0135] In step 304, the hardware trust token is verified by the security engine of the next-level stacking unit, and local security verification of the stacking unit is performed after successful verification.

[0136] In some embodiments, in step 304, the hardware trust token is verified by the security engine of the next-level stacking unit. This can be achieved by: using the cryptographic acceleration circuit of the next-level stacking unit, determining the target trust token based on the unique feature tag embedded in the programmable memory of the next-level stacking unit and the same token working key, and comparing the target trust token with the received hardware trust token; if the target trust token matches the received hardware trust token, the security processor of the next-level stacking unit determines that the hardware trust token verification is successful.

[0137] In some embodiments, each stack unit also includes a read-only memory that stores local boot code. The programmable memory also has a root public key pre-programmed inside. In step 304, after successful verification, the local security verification of the stack unit is performed, which can be achieved in the following ways: the root public key stored in the programmable memory is retrieved through a cryptographic acceleration circuit, and hardware signature verification is performed on the local boot code in the read-only memory based on the root public key; a bare-chip level key is derived based on a unique feature tag through a security processor, and after the hardware signature verification is passed, the external firmware is scheduled to be read; the external firmware is decrypted based on the bare-chip level key through a cryptographic acceleration circuit, the data integrity of the decrypted external firmware is verified, and after the data integrity verification is passed, the local security verification is determined to be successful.

[0138] In step 305, the three-dimensional stacked chip is started via the central security controller after all multiple stacked cells have passed local security verification.

[0139] In some embodiments, the distributed secure boot method provided in this application can also be implemented in the following way: when the secure boot mode is in parallel mode, the security engines of multiple stacking units perform local security verification independently and report the verification results to the central security controller; after receiving the results of the local security verification reported by multiple stacking units, the central security controller starts the three-dimensional stacked chip.

[0140] In some embodiments, the distributed secure boot method provided in this application can also be implemented in the following ways: when the secure boot mode is a parallel grouping mode, the central security controller divides multiple stacking units into at least two independent groups; within each group, the security engine of the stacking unit within the group performs local security verification, and after successful verification, transmits a hardware trust token to the next-level stacking unit within the group to complete the serial transmission within the group in sequence; the security engine of the end stacking unit within the multiple groups outputs group trust status signals in parallel to the central security controller after passing the local security verification of the stacking unit; the central security controller receives the group trust status signals output by the multiple groups, and starts the three-dimensional stacking chip when the multiple group trust status signals are all valid.

[0141] In some embodiments, the distributed secure boot method provided in this application can also be implemented in the following way: when the secure boot mode is serial group mode, the central security controller divides multiple stacking units in normal operation into at least two independent groups and determines the serial transmission path between the groups; the security engine of the end stacking unit of the first group in the preceding position of the serial transmission path generates a group trust token for the first group and transmits the group trust token to the first stacking unit of the second group in the following position via an encrypted transmission link; the security engine of the first stacking unit of the second group verifies the received group trust token, and after successful verification, triggers the execution of local security verification of the stacking unit to enable intra-group serial transmission of the second group; after at least two independent groups have passed local security verification in sequence, the security engine of the stacking unit at the final end position in the serial transmission path outputs a global trust enable signal to the central security controller to start the three-dimensional stacked chip.

[0142] This application provides an electronic device, which includes a processor, wherein the processor includes: a three-dimensional stacked chip 200 of any of the foregoing embodiments.

[0143] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0144] In the field of 3D Stacked DRAM System-on-Chip (3D Stacked DRAM SoC) chips, with the development of heterogeneous integration technology, the logic layer and DRAM layer achieve high-density vertical interconnection through hybrid bonding technology. Furthermore, through the Universal Chip Interconnect Express (UCIe) (corresponding to the unified chip interconnect interface in the above embodiments), lateral planar interconnection between multiple hybrid-bonded logic-memory stacked cells can be achieved. While this architecture improves performance and energy efficiency, it also introduces new security challenges. Secure boot technology for 3D stacked DRAM SoC chips typically employs an independent chip boot process, lacks a distributed security trust mechanism, cannot support a secure boot mechanism for multiple dies or chips working together, and cannot simultaneously achieve the dynamic flexibility of efficient cross-chip collaborative secure boot.

[0145] To address the aforementioned shortcomings, this application proposes a secure boot method for 3D stacked DRAM SoCs, resolving the trust chain construction issue during parallel or serial secure boot processes involving multiple chips (referring to logic dies or memory dies within a chip). This application supports a collaborative secure boot mechanism comprised of underlying dies (including logic dies or DRAM dies) or stacked sub-dies (including complete stacked units formed by hybrid bonding of logic dies and DRAM dies (corresponding to the stacked units in the above embodiments)), balancing the dynamic flexibility of efficient cross-chip collaborative secure boot.

[0146] like Figure 1 As shown, this application provides an architecture for a three-dimensional stacked chip (corresponding to the three-dimensional stacked chip in the above embodiments). The physical basis of this architecture is a stacking cell 10, which is formed by stacking a logic die 110 and at least one memory die 120 vertically using a 3D hybrid bonding process. A complete three-dimensional stacked chip is composed of multiple such stacking cells 10 interconnected in a horizontal plane via a UCIe interface. Each stacking cell 10, composed of logic dies and memory dies, has an independent secure boot mechanism.

[0147] The three-dimensional stacked chip can support multiple secure boot modes (corresponding to the secure boot modes in the above embodiments): In parallel mode, multiple stacked units 10 independently complete local security verification. In serial mode, a secure trust chain is passed step-by-step between stacked units 10 through a signed token, i.e., a hardware trust token. This trust chain can be dynamically reconstructed as needed and permissions can be unlocked step-by-step, thereby achieving a balance between efficient boot and flexible security policies.

[0148] In some embodiments, the security features of the 3D stacked chip are implemented by integrating a series of dedicated hardware modules on the logic die of each stacked cell. These modules work together to provide basic security for various secure boot modes. This will be explained in detail below.

[0149] 1) The composition of the security engine.

[0150] Each stack unit integrates a security engine. This security engine consists of multiple hardware circuits, specifically including: Security processor: As the core control unit of the security engine, it can be a security master control core based on the Reduced Instruction Set Computer V (RISC-V) architecture, responsible for scheduling and control.

[0151] Physical function circuit: This is a type of Physically Unclonable Function (PUF) circuit. This circuit can generate a unique hardware-level fingerprint for each stacked cell, which serves as the native key root.

[0152] Programmable memory: A type of one-time programmable (OTP) memory used to securely store read-only information, such as security configurations and root certificates, which cannot be tampered with once written.

[0153] Cryptographic acceleration circuit: This is a dedicated hardware cryptographic algorithm acceleration circuit used to perform high-speed operations such as signature verification, data encryption, and generation of cryptographic-based Message Authentication Code (CMAC) tokens, providing hardware computing power support for the construction of parallel or serial trust chains.

[0154] 2) Unified encryption mechanism for the core interconnect interface.

[0155] In the 3D stacked DRAM SoC architecture of this application embodiment, high-speed inter-chip interconnection is achieved between logic dies and memory dies, as well as between multiple stacking units, via the UCIe interface. To ensure communication security, this application embodiment integrates a dedicated hardware encryption engine above the UCIe physical link layer to achieve end-to-end encryption throughout the UCIe communication path, eliminating plaintext transmission between stacking units. This mechanism provides a hardware-level secure transmission channel for the transmission of hardware trust tokens, firmware images, and boot control signaling.

[0156] In terms of hardware architecture, the UCIe physical interface serves as the standard high-speed interconnect physical channel between stack units, responsible for carrying the transmission of raw data, control commands, and security trust tokens. Each stack unit's UCIe port is configured with an independent hardware encryption engine. This deployment method is per stack unit and per UCIe link, rather than globally shared.

[0157] The core encryption mechanism is designed as follows: Encryption Algorithm and Operating Mode: The hardware encryption engine consistently employs the Advanced Encryption Standard-Galois / Counter Mode (AES-GCM) algorithm. AES is used for symmetric encryption and decryption, while GCM mode includes integrity verification to defend against tampering and replay attacks, thus achieving a three-pronged protection of confidentiality, integrity, and tamper resistance.

[0158] Hop-by-hop independent key mechanism: The UCIe path between two adjacent stack units, i.e., the encrypted transmission link, adopts a hop-by-hop independent key mechanism. This means that each pair of adjacent stack units negotiates and stores an independent set of link keys, i.e., session keys, separately. Different stack unit pairs do not share keys, ensuring that security issues on a single link do not affect the overall network communication security. This session key is derived from the physical function circuitry and programmable memory of this stack unit, and does not leave the chip or leak from the outside.

[0159] Full-path encryption coverage: All data interconnected via UCIe is prohibited from being transmitted in plaintext. Encryption comprehensively covers the secure boot trust chain (e.g., identity and authentication tokens generated by CMAC), boot control commands across stack units, trust flags, global enable signals, cryptographic firmware loaded across stack units, boot-related image data, and packet trust merging signaling and sleep control commands in serial packet mode. From the hardware encryption engine at the sending end encapsulating ciphertext, to transmission via the UCIe physical link, and then to the hardware encryption engine at the receiving end decrypting and verifying, no plaintext is exposed throughout the entire intermediate link.

[0160] The complete interactive process of encrypted transmission is as follows: Link initialization: After the chip powers on, each stack unit derives the UCIe link session key through its local physical function circuits and programmable memory. Secure key negotiation is completed between adjacent stack units, and the key circulates only within the hardware security domain.

[0161] Sending-end encryption: The security processor sends tokens, instructions, or firmware data that need to be transmitted across stack units to the local hardware encryption engine. The hardware encryption engine uses the AES-GCM algorithm to encrypt the data and attach a checksum before encapsulating it into a UCIe transaction packet.

[0162] UCIe transparent transmission: Ciphertext data packets are transmitted at high speed via the UCIe physical interface. Only ciphertext is transmitted throughout the entire link, making it impossible to eavesdrop or intercept the parsing of plaintext.

[0163] Receiver Decryption and Verification: Upon receiving a data packet, the peer's hardware encryption engine first performs GCM integrity verification. If the verification fails, the data packet is discarded, thus blocking the startup link. If the verification passes, AES decryption is performed, and the valid plaintext data is handed over to the security engine of this stack unit for subsequent trust verification and startup logic processing.

[0164] Through the above mechanism, the embodiments of this application provide a unified and secure inter-chip communication base for various secure boot modes (including parallel, serial, and group serial), which can support the dynamic reconstruction of the trust chain and adapt to the hierarchical permission unlocking requirements in scenarios such as partial hibernation.

[0165] In some embodiments, there is a clear subordinate and cooperative relationship between the hardware encryption engine and the security engine, which work together to achieve secure communication and trust transfer across stacked units.

[0166] The hardware encryption engine is a dedicated hardware cryptographic accelerator with embedded AES-GCM hardware processing circuitry. It is integrated within each stack unit, physically located between the UCIe controller and the physical transmission link, and is specifically responsible for real-time encryption, decryption, and integrity verification of data packets sent and received by UCIe.

[0167] The collaborative relationship between the security engine and the hardware encryption engine is reflected in the following aspects: Key Source: The session key used for UCIe link encryption is provided by the security engine. Specifically, the session key is derived from the physical function circuitry and programmable memory within the security engine.

[0168] Policy configuration: The security processor within the security engine (such as the RISC-V security core) is responsible for configuring the operating mode, encryption enable status, and algorithm parameters of the hardware encryption engine.

[0169] Collaborative Secure Boot Completion: In serial mode, the security engine performs local security verification and generates a CMAC-based hardware trust token. The security engine then passes this hardware trust token to the hardware encryption engine for encryption and transmits it across stack units via the UCIe link.

[0170] Generation of unique feature tags and identity binding: In some embodiments, to assign an unforgeable hardware identity to each stack unit, the security engine embeds physical function circuits to generate physically unclonable tags, i.e., unique feature tags. This is a hardware circuit-level embedding, directly integrating the physical function circuits into the physical circuitry of each stack unit as a natural, unclonable identity tag.

[0171] The steps for identity binding are as follows: Step 1: Power on to generate a unique hardware identity.

[0172] When each stack cell is powered on, its built-in physical function circuitry generates a fixed, unique feature code, or unique feature tag. This tag serves as the native hardware identifier (ID) of this stack cell, is determined at the factory, remains unchanged throughout its lifespan, and cannot be replicated.

[0173] Step 2: Solidifying and binding unique feature tags.

[0174] During the chip manufacturing or initialization phase, a unique identifier output by the physical function circuit is programmed into the programmable memory of the current stack cell. Because programmable memory can only be programmed once, is unrewritable, and cannot be erased, the hardware identity represented by the unique identifier is permanently locked within the stack cell. This step establishes a deep hardware bond between the physical function circuit, the identity stored in the programmable memory, and the current stack cell, making it impossible to separate or replace.

[0175] Step 3: Linking identity binding with the trust chain.

[0176] The unique feature tag of this stack cell serves as the unique hardware identity ID for the stack cell. This identity information is used for cryptographic calculations when generating hardware trust tokens in serial mode. For example, when a higher-level stack cell (denoted as level n) generates a hardware trust token to be passed to the next-level stack cell (denoted as level n+1), its cryptographic acceleration circuitry performs the following calculations: ,in, It is a generated hardware trust token. It is a message authentication code algorithm. It is the token working key derived from the nth level stacking unit. It is the unique feature label of the (n+1)th stacking unit.

[0177] At the receiving end, the (n+1)th stack unit compares its identity with a unique tag stored in its local programmable memory. If the tag matches, the identity is proven legitimate, allowing access to the trust chain and unlocking boot permissions level by level. If the tag does not match (e.g., the stack unit has been replaced or counterfeited), the verification will fail, and the secure boot process will be directly blocked.

[0178] In some embodiments, the local security verification of each stack unit is an independent and complete secure boot process. This process begins with an immutable hardware root of trust and verifies higher-level software firmware layer by layer, ensuring that the stack unit's own software stack is complete and trustworthy before being added to the global trust chain. This process generally consists of three stages: verifying the local boot code, loading the encrypted firmware, and releasing the trust chain flag.

[0179] 1) Verify the local startup code.

[0180] Each stack unit also includes a read-only memory (ROM) containing local boot code. Upon power-on reset, the hardware design forces the security processor to begin execution from this ROM. This boot path is fixed and cannot be changed or tampered with by software. A cryptographic acceleration circuit reads a pre-set root public key from the programmable memory. This root public key is burned into the memory at the factory and cannot be altered. The cryptographic acceleration circuit uses an algorithm such as the Elliptic Curve Digital Signature Algorithm - P384 (ECDSA-P384) to perform integrity hash verification and digital signature verification on the local boot code in the ROM. The security processor determines the validity of the verification result: if the verification passes, the local boot code is considered legitimate and unaltered, and the process proceeds to the next step; if the verification fails, the boot process is locked, prohibiting subsequent loading operations and keeping the stack unit in a secure locked state.

[0181] 2) Load the encrypted firmware.

[0182] After the local boot code is verified as legitimate, the security processor schedules an off-chip interface to read the encrypted external firmware stored in an external non-volatile memory (such as flash memory).

[0183] The security processor derives a unique die-level key based on the physical function circuitry and unique feature tags embedded in the programmable memory of this stacked cell. The derivation and use of this key are completed entirely within the hardware security domain of the security engine and cannot be read externally.

[0184] The cryptographic acceleration circuit uses the AES-GCM algorithm and, based on a derived die-level key, performs decryption operations on encrypted external firmware to restore the plaintext firmware. Simultaneously, the characteristics of GCM mode enable the cryptographic acceleration circuit to perform integrity and tamper-proof verification on the decrypted data.

[0185] After successful decryption and verification, the legitimate firmware is loaded into the designated runtime storage space within this stack unit, ready to await global scheduling by the central security controller.

[0186] 3) Release the trust chain flag.

[0187] After the signature verification of the local boot code and the decryption verification of the encrypted firmware have both passed, the security engine sets a local hardware register state as a sign that the local trust chain is valid. This trust sign is reported to the central security controller through the secure path within the stacking unit. Subsequent actions differ depending on the secure boot mode determined by the central security controller: In parallel mode, each stack unit completes the above process and releases its local trust flag. After collecting valid flags from all stack units, the central security controller directly issues a global enable, starting the entire system. In serial mode, after releasing its local trust flag, the current stack unit continues the hardware trust token generation process. The security engine uses the current level's token working key and the unique feature tag of the next-level stack unit to generate a hardware trust token using the CMAC algorithm, and transmits it to the next-level stack unit via a UCIe encrypted link, thus initiating a step-by-step trust transfer.

[0188] In some embodiments, when the secure boot mode is serial, the 3D stacked chips construct global trust through a chain-of-trust release model. The hardware root of trust in this model is built upon the physical function circuitry (PUF) and programmable memory (OTP) integrated within each stack cell, which together generate a unique identity and key for each stack cell.

[0189] The rules for trust release are as follows: When a higher-level stack unit (denoted as level n) successfully completes local security verification, the security engine unlocks or derives a token working key (denoted as...). ).Should It is the working key derived from the hardware root of trust and used for operations at this level. Subsequently, the cryptographic acceleration circuitry will be based on... The unique feature label of the next stacking unit (denoted as the n+1th level) (denoted as...) This process generates a hardware trust token for transmission. The generation process can be represented as follows: .in, It is a message authentication code algorithm based on cryptography. The selection of the next stacking unit is not temporary or random, but determined by the central security controller according to a pre-set and dynamically reconfigurable startup topology path.

[0190] Hardware trust token verification and transmission process: After receiving the hardware trust token from the previous stack unit, a lower-level stack unit will perform a series of strict verification and processing steps.

[0191] Step 1: Decryption and Integrity Verification of the Encrypted Link: The hardware trust token is transmitted via a UCIe encrypted transmission link using AES-GCM encryption. Upon receiving data, the hardware encryption engine of this stack unit first performs a GCM integrity verification. If the verification fails, the token is discarded, the startup process terminates, and the trust chain is locked. If the verification passes, the hardware encryption engine continues decryption and delivers the decrypted plaintext token to the security engine of this stack unit.

[0192] Step 2: Extract information and prepare for verification: The security engine obtains the hardware trust token sent by the previous stacking unit ( Simultaneously, the security processor reads its own unique identifier (i.e., ...) from the programmable memory of this stack unit. ), and securely obtain the key parameters used for verification (and correspond).

[0193] Step 3: Local Recalculation and Comparison: The cryptographic acceleration circuit uses the same CMAC algorithm as the previous stacking unit. Based on the obtained key parameters and its own unique feature tag, it recalculates a target trust token locally. The calculation process is as follows: The security processor compares the recalculated value with the received hardware trust token. If they match perfectly, the identity is proven legitimate and the trust chain is valid, and the process proceeds to the next step. If they do not match, it is determined that there is impersonation or chain tampering, and the process is directly rejected.

[0194] Step 4: Perform Local Security Verification: Only after the hardware trust token verification is successful is the security engine authorized to initiate the local security verification process for this stack unit. This process includes verifying the signature of the boot code in the local read-only memory (e.g., using the ECDSA-P384 algorithm), and decrypting and loading the encrypted external firmware using the die-level key of this stack unit.

[0195] Step 5: Determine Location and Continue Transmission or Complete Startup: After all local verifications pass and the local trust flag is set, the security processor determines whether it is the final stack unit in the startup path. If it is not the final stack unit, the security engine unlocks or derives its own local token working key (…). ), read the identity ID of the next stacking unit (n+2th level) ), and generate a new hardware trust token ( The new token is then passed down the chain via the UCIe encrypted transmission link. If it is an end-stack unit, the security engine will not generate a hardware trust token for the next level. Instead, the security engine broadcasts a global trust enable signal (corresponding to the global trust enable signal in the above embodiment). This signal is a hardware-level global control status signal, directly driven by the security engine, and broadcast to all stacking units and the main control module of the entire 3D stacked chip via the on-chip security bus or UCIe interconnect link. This signal is a hardware flag dedicated to the security domain and cannot be tampered with or forcibly pulled high by ordinary central processing units (CPUs) or business software. Upon responding to this signal, the central security controller will officially unlock and start the entire 3D stacked chip.

[0196] In some embodiments, the secure boot mode of the 3D stacked chips is not static but can be reconfigured based on different triggering conditions to achieve dynamic trust chain configuration. This function is selected, configured, and switched uniformly by a central security controller.

[0197] Figure 5 This is a schematic diagram illustrating the process of selecting the startup mode for the central security controller provided in an embodiment of this application. Figure 5 As shown, the central security controller makes a decision on the boot mode selection. Based on the decision, the boot process will branch in different directions, such as entering parallel mode to perform independent trust chain boot, or entering serial mode to perform hierarchical trust chain boot.

[0198] The central safety controller determines the specific triggering methods for the safe startup mode in the following ways: 1) Factory static default configuration.

[0199] When the chip leaves the factory, a default secure boot mode can be pre-programmed into the programmable memory. For example, it can be programmed into a parallel mode to suit regular high-performance scenarios, or into a fully serial mode to suit high-security, confidential scenarios. After the chip is powered on, if there are no other dynamic instructions, it will directly boot into the preset mode in the programmable memory.

[0200] 2) Automatically select based on security level.

[0201] The central security controller can read the security level setting in a configuration register and automatically select the secure boot mode accordingly. For example, when the security level is configured as HIGH, the central security controller automatically selects the fully serial boot mode for the highest security, in which the trust chain is passed step by step. When the security level is configured as NORMAL, the central security controller automatically selects the parallel mode, in which each stack unit starts synchronously and independently for the fastest boot speed.

[0202] 3) Dynamically and adaptively select based on hardware operating conditions.

[0203] The central security controller can sense the hardware operating status of the chip in real time and automatically reconfigure and switch the secure boot mode according to dynamic scenarios. A typical scenario is switching to serial packet mode (corresponding to the serial packet mode in the above embodiments).

[0204] Triggering scenarios: Some stacked cells enter deep sleep or power-down state. Some stacked cells are isolated due to fault. There is a need for low-power, energy-saving operation.

[0205] Dynamic reconfiguration: In the above scenario, the central security controller will automatically reclassify the stacked units in normal operation into different groups and regenerate trust transfer paths between these groups.

[0206] Table 1 below shows examples of two reconfigurable serial boot mechanisms, illustrating the configuration of dynamic trust chains: Table 1

[0207] For example, when stack cell 3 is detected to have entered a sleep state, the central safety controller will automatically reconfigure the startup topology, dividing the active cells into group 1 (containing stack cell 1 and stack cell 2) and group 2 (containing only stack cell 4), and starting them in a grouped serial manner. This method balances power consumption and fault tolerance without affecting the safe startup of normal stack cells.

[0208] 4) External configuration or software controllable selection.

[0209] In some embodiments, the security firmware can also send configuration instructions to the central security controller to actively specify the current security boot mode through software, thereby switching between parallel mode, fully serial mode or various group modes as needed.

[0210] The following are examples of workflows under different secure boot modes.

[0211] Parallel Boot (High-Performance Mode): In a 3D stacked chip containing four stacked cells, when rapid boot is required, the central security controller configures the secure boot mode to parallel mode. Upon chip power-up, the central security controller simultaneously sends boot commands to all four stacked cells. The security engines of the four stacked cells synchronously and independently perform their respective local security verifications. This process includes: verifying the boot code signature in local read-only memory (e.g., using the ECDSA-P384 algorithm); decrypting and verifying the external firmware using their respective die-level keys; and releasing a local trust flag to the central security controller upon successful verification. After receiving valid trust flags from all four stacked cells, the central security controller activates the entire 3D stacked chip.

[0212] Serial Boot (High-Security Mode): Within the same 3D stacked chip, when the highest level of security is required, the central security controller configures the secure boot mode to a fully serial mode. The central security controller configures a complete serial path, for example: Stack Unit 1 → Stack Unit 2 → Stack Unit 3 → Stack Unit 4.

[0213] The startup process begins by passing through each level: Stack unit 1 first performs local security verification. Upon successful verification, the security engine uses the token working key (…). ) and the unique feature label of stacked unit 2 ( Generate hardware trust token ( The encrypted data is then sent to stacking unit 2. Stacking unit 2 receives and verifies the data. The verification process is as follows: using the same... and its own unique feature label ( The token is recalculated and compared locally. Upon successful verification, stacking unit 2 performs local security verification, and then generates and passes the next-level token. This process continues sequentially until stacking unit 4, acting as the final stacking unit, completes the final token verification and local security authentication. Upon successful authentication, stacking unit 4 triggers and broadcasts a global trust enable signal.

[0214] Dynamic switching of the trust chain (serial grouping mode): The dynamic reconstruction or switching of the trust chain occurs before the entire group security startup process begins, that is, before any stacking unit begins local security verification or generates any tokens.

[0215] Scenario: The central security controller detects that stack unit 3 has entered a dormant state before startup.

[0216] Status awareness: The central security controller acquires the status of the stacked units in real time through two sources: Power management status reporting: Each stack cell has a power sleep status signal (e.g., normal operation, shallow sleep, deep sleep / power-down isolation) that is reported to the central safety controller in real time. The central safety controller collects the power supply, clock, and reset status of all stack cells, thereby instantly knowing which cells are online and which are in sleep mode.

[0217] UCIe Link Status and Heartbeat Online Awareness: UCIe links have clearly defined states, such as Link Up or Link Down. The central security controller can also proactively sense these states by sending periodic heartbeat requests to the stacking units. For example, if a link interruption is detected with stacking unit 3 and there is no heartbeat response, it can be determined that stacking unit 3 has entered a sleep or unavailable state.

[0218] Switch to serial packet mode: Based on the above status awareness results, the central security controller switches the secure startup mode to serial packet mode.

[0219] New Path Generation and Trust Merging: The central security controller generates a new startup path that skips the dormant stack unit 3. For example, the new path is: Group 1 (Stack Unit 1 → Stack Unit 2) → Group 2 (Stack Unit 4). After Group 1 completes its internal serial transmission, Stack Unit 2, as the end unit of Group 1, generates a group trust token. The generation of this token introduces the concept of a group key. For example, the group trust token representing the trust status of Group 2 is calculated as follows: ,in, It is the group root key derived from stacking unit 2, representing the first group. It is the unique feature tag of the first unit of group 2 (i.e., stacking unit 4). This formula is a new layer of group key mechanism added in serial group mode, which is different from the one used in ordinary serial mode. The formulas exist in parallel and are applicable to different levels of trust transfer.

[0220] Figure 6 This is a schematic diagram of the topology of the trust transfer path between four stacked units in the fully serial boot mode provided in this application embodiment. For example... Figure 6 As shown, it contains four stacking units, labeled stacking unit (chip) 0, stacking unit 1, stacking unit 2, and stacking unit 3. When the three-dimensional stacked chip is configured in a fully serial boot mode to handle high-security scenarios, the central security controller will preset a complete, unidirectional token passing chain that runs through all stacking units participating in the boot process.

[0221] The central security controller designates chip3 as the first stacking unit. After the chip powers on, chip3's security engine prioritizes performing local security verification. Upon successful verification, chip3's security engine generates a hardware trust token for the next level (chip0) and sends it to chip0 via an encrypted transmission link. Figure 6 The arrow pointing from chip3 to chip0 indicates the direction of this trust transfer. After successfully verifying the token from chip3 and completing its own local security verification, chip0 generates a new hardware trust token and passes it to the next stacking unit in the path, namely chip1. Figure 6 The arrow pointing from chip0 to chip1 indicates this step. The process continues, and after successful verification, chip1 sends a token to chip2 (e.g., ...). Figure 6 (As shown by the arrow pointing from chip1 to chip2), after chip2 passes verification, if the path is closed, it may send a final completion signal or token to chip3 (e.g., ...). Figure 6(As indicated by the arrow pointing from chip2 to chip3), or if chip2 is the end stacking unit, a global trust enable signal is sent directly to the central security controller.

[0222] Figure 7 This is a schematic diagram of the trust transfer topology in the grouped serial startup mode provided in this application, where four stacked units are divided into two independent groups. This mode corresponds to scenarios requiring dynamic adaptation, such as when some stacked units are in a dormant or faulty state. Figure 7 As shown, the four stacking units (stacking unit 0, stacking unit 1, stacking unit 2, and stacking unit 3) are divided into two independent groups by the central security controller. Group 1: consists of stacking unit 0 and stacking unit 1. Group 2: consists of stacking unit 3 and stacking unit 2.

[0223] In some embodiments, when the central security controller determines the secure boot mode to be serial grouping mode, it first groups the stacked units that are in normal operating state, and then establishes a macroscopic serial trust transfer path between these groups. Figure 7 This demonstrates the state after the grouping is completed. Within each of the two groups, the serial trust chain will be started independently and in parallel.

[0224] Reference Figure 7 The startup process is as follows: The central security controller simultaneously issues startup commands to the first unit of Group 1 (e.g., stacking unit 0) and the first unit of Group 2 (e.g., stacking unit 3). Two independent trust chains are started in parallel: Within Group 1, after performing local security verification, stacking unit 0 transmits a hardware trust token to stacking unit 1. The bidirectional arrow between stacking unit 0 and stacking unit 1 in the diagram indicates that there is an encrypted transmission link between them for the transmission of the trust token. Simultaneously, within Group 2, after performing local security verification, stacking unit 3 transmits a hardware trust token to stacking unit 2. The bidirectional arrow between stacking unit 3 and stacking unit 2 in the diagram also indicates the encrypted transmission link between them.

[0225] Trust credential aggregation: When the end unit of Packet 1 (e.g., stack unit 1) completes local security verification, it outputs a packet trust status signal representing the trust status of Packet 1 to the central security controller. When the end unit of Packet 2 (e.g., stack unit 2) completes local security verification, it also outputs a packet trust status signal representing the trust status of Packet 2 to the central security controller.

[0226] The central security controller will only start the entire 3D stacked chip after receiving and confirming that the trust credentials (i.e., group trust status signals) reported by all groups (group 1 and group 2 in this example) are valid.

[0227] This application provides a secure boot method and chip architecture suitable for 3D Stacked DRAM SoC. This application aims to solve the trust chain construction problem in the parallel or serial secure boot process of multiple chips (including multiple dies or multiple dies), supports a multi-node collaborative secure boot mechanism, and takes into account the dynamic flexibility of efficient cross-chip collaborative secure boot.

[0228] This application proposes a flexible secure boot framework that enables multiple boot modes based on different security or performance requirements within a three-dimensional stacked chip structure constructed using hybrid bonding processes. On one hand, this application provides a parallel and independent secure boot scheme, allowing each stacked cell to concurrently and independently complete local security verification for high-performance, rapid boot. On the other hand, this application also provides a secure boot scheme with serial dynamic trust chain transmission, constructing a complete and dynamically reconfigurable hardware trust chain by progressively transmitting hardware trust tokens between stacked cells to meet the needs of high-security scenarios.

[0229] This application proposes a secure initiation method for hierarchical trust chain transmission by encrypting and decrypting data on a UCIe link. Specifically, by integrating a dedicated hardware encryption engine at the UCIe interface of each stack unit and establishing encrypted transmission links using independent session keys between adjacent stack units, the confidentiality and integrity of all information transmitted across units (including hardware trust tokens) are ensured. This mechanism provides hardware-level security for hierarchical trust chain transmission in serial mode, enabling secure transmission, verification, and handover of trust credentials over untrusted physical links.

[0230] In summary, this application provides a distributed secure boot architecture suitable for 3D stacked chips, offering high security, high efficiency, and dynamic adaptability. This architecture ensures the confidentiality and integrity of all cross-cell communications at both the physical and link layers by deploying independent security and hardware encryption engines within each stacking cell and establishing encrypted transmission links between cells using hop-by-hop independent keys. Furthermore, this application proposes a flexible and configurable secure boot mode: for scenarios requiring ultimate security, a non-forgeable hardware trust chain can be constructed in serial mode, starting from the hardware identity root and progressively passing hardware trust tokens; for scenarios prioritizing boot efficiency, concurrent independent verification of all cells can be achieved in parallel mode; and in dynamic operating scenarios requiring adaptation to partial cell hibernation or failure, the boot path can be intelligently reconstructed through parallel or serial grouping modes to dynamically establish an effective trust transmission topology. Through this multimodal and reconfigurable boot mechanism, this application addresses the technical challenges of traditional boot schemes in complex heterogeneous integrated chips, including security, flexibility, and robustness, ensuring a reliable, efficient, and secure boot process for 3D stacked chips across various application scenarios.

[0231] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A three-dimensional stacked chip, characterized in that, The three-dimensional stacked chip includes: Multiple stacked units, which are interconnected via a unified chip interconnect interface; A central security controller is used to determine the secure startup mode of the three-dimensional stacked chip and to start the three-dimensional stacked chip when all of the multiple stacking units have passed local security verification. Multiple hardware encryption engines are configured in each of the stacking units. The hardware encryption engines in any two adjacent stacking units are used to establish an encrypted transmission link between the two adjacent stacking units. Different encrypted transmission links use different session keys for encryption. Multiple security engines are configured in each of the stacking units and are respectively connected to the central security controller and the hardware encryption engine in the stacking unit. When the secure boot mode is serial mode, in two adjacent stacking units, the security engine of the upper-level stacking unit is used to transmit the hardware trust token to the lower-level stacking unit via the encrypted transmission link; the security engine of the lower-level stacking unit is used to verify the hardware trust token and perform local security verification of the stacking unit after successful verification.

2. The three-dimensional stacked chip according to claim 1, characterized in that, When the secure boot mode is serial mode, The security engine of the upper-level stacking unit is used to generate the hardware trust token after the local security verification of the stacking unit is passed. The hardware encryption engine of the upper-level stacking unit is used to encrypt the hardware trust token based on the session key corresponding to the encrypted transmission link between the upper-level stacking unit and the lower-level stacking unit, and send the encrypted hardware trust token through the encrypted transmission link. The hardware encryption engine of the next-level stack unit is used to receive the encrypted hardware trust token from the encrypted transmission link, decrypt the encrypted hardware trust token, and hand over the decrypted hardware trust token to the security engine of the stack unit for verification.

3. The three-dimensional stacked chip according to claim 2, characterized in that, When the preceding stacking unit is the first stacking unit, the security engine of the first stacking unit is used to perform local security verification of the stacking unit first after the chip is powered on; When the next-level stacking unit is a non-terminal stacking unit, the security engine of the next-level stacking unit is used to generate a new hardware trust token after completing the local security verification of the stacking unit and continue to transmit it to the adjacent stacking unit via the encrypted transmission link. When the next level stacking unit is an end stacking unit, the security engine of the end stacking unit is used to stop transmitting the hardware trust token after completing the local security verification of the stacking unit and output a global trust enable signal to the central security controller. The central security controller is also used to activate the three-dimensional stacked chip in response to the global trust enable signal.

4. The three-dimensional stacked chip according to claim 1, characterized in that, The security engine includes a security processor, physical function circuitry, programmable memory, and cryptographic acceleration circuitry, wherein... The physical function circuit is used to generate a unique feature tag that is physically bound to the stack unit when the security engine is powered on. The programmable memory is used to permanently store the unique feature tag; The security processor is used to derive a token working key based on the unique feature tag; The cryptographic acceleration circuit is used to generate the hardware trust token based on the token working key and the unique feature tag of the next-level stacking unit.

5. The three-dimensional stacked chip according to claim 4, characterized in that, The cryptographic acceleration circuit of the next-level stack unit is used to determine the target trust token based on the unique feature tag embedded in the programmable memory of the next-level stack unit and the same token working key, and compare the target trust token with the received hardware trust token. If the target trust token matches the received hardware trust token, the security processor of the next-level stacking unit determines that the hardware trust token verification was successful.

6. The three-dimensional stacked chip according to claim 4, characterized in that, Each of the stacked units also includes a read-only memory that stores local boot code, and the programmable memory also contains a root public key pre-programmed into it. The cryptographic acceleration circuit is also used to retrieve the root public key stored in the programmable memory, and perform hardware signature verification on the local boot code in the read-only memory based on the root public key. The security processor is also used to derive a bare-chip level key based on the unique feature tag, and to schedule the reading of external firmware after the hardware signature verification is passed; The cryptographic acceleration circuit is also used to decrypt the external firmware based on the bare chip level key, perform data integrity verification on the decrypted external firmware, and determine that the local security verification is successful after the data integrity verification is passed.

7. The three-dimensional stacked chip according to claim 1, characterized in that, When the secure boot mode is in parallel mode, The security engines of the multiple stacked units are used to independently perform the local security verification and report the verification results to the central security controller; The central security controller is used to activate the three-dimensional stacked chip after receiving the results of local security verification reported by the plurality of stacking units.

8. The three-dimensional stacked chip according to claim 1, characterized in that, When the secure boot mode is in parallel grouping mode, The central security controller is also used to divide the plurality of stacked units into at least two independent groups; Within each group, the security engine of the stacking unit within the group performs local security verification and, upon successful verification, passes a hardware trust token to the next-level stacking unit within the group to complete the serial transmission within the group. The security engine of the end stacking unit within the multiple groups is used to output group trust status signals in parallel to the central security controller after passing the local security verification of the stacking unit. The central security controller is also configured to receive the packet trust status signals output by the multiple packets, and to activate the three-dimensional stacked chip when all the multiple packet trust status signals are valid.

9. The three-dimensional stacked chip according to claim 1, characterized in that, When the secure boot mode is serial packet mode, The central security controller is also configured to divide the multiple stacked units in normal operation into at least two independent groups and determine the serial transmission path between the groups; The security engine of the end stacking unit of the first packet at the preceding position of the serial transmission path is used to generate a packet trust token for the first packet and transmit the packet trust token to the first stacking unit of the second packet at the following position via the encrypted transmission link. The security engine of the first stacking unit of the second group is used to verify the received group trust token, and after the verification is successful, trigger the execution of local security verification of the stacking unit to enable intra-group serial transmission of the second group. After at least two independent groups have passed local security verification in sequence, the security engine of the stacked unit at the final end of the serial transmission path outputs a global trust enable signal to the central security controller to start the three-dimensional stacked chip.

10. The three-dimensional stacked chip according to claim 9, characterized in that, The security engine includes a security processor, a programmable memory, and cryptographic acceleration circuitry. The programmable memory contains a unique feature tag embedded within it, which is bound to the physical characteristics of its stacking cell. The security processor of the end stack unit of the first packet is used to derive a group root key representing the first packet; The cryptographic acceleration circuit of the end stacking unit of the first group is used to generate the group trust token based on the group root key and the unique feature tag of the first stacking unit of the second group; The cryptographic acceleration circuit of the first stacking unit of the second group is used to generate a target group trust token based on the unique feature tag of the first stacking unit and the group root key, and compare the target group trust token with the received group trust token to complete the verification.

11. The three-dimensional stacked chip according to claim 9, characterized in that, The central security controller is also used to collect power supply status signals, clock status signals and reset status signals of multiple stacked units; The central security controller is also used to perform periodic heartbeat detection on multiple stacked units through the unified chip interconnect interface to obtain periodic heartbeat signals; The central safety controller is also used to determine that the stacking unit is in a sleep-down or fault state when the power supply status signal, the clock status signal, the reset status signal indicate an abnormality, or the periodic heartbeat signal is missing. The central safety controller is also used to determine the safe startup mode as the serial grouping mode when it is determined that some of the stacked units are in a dormant, power-off, or faulty state.

12. A distributed secure boot method, characterized in that, The method, applied to a three-dimensional stacked chip, includes a central security controller and multiple stacked units interconnected via a unified chip interconnect interface. Each stacked unit is configured with a hardware encryption engine and a security engine. The central security controller determines the secure boot mode of the three-dimensional stacked chip. An encrypted transmission link is established between two adjacent stacked units using hardware encryption engines within any two adjacent stacked units, wherein different encrypted transmission links are encrypted using different session keys. When the secure boot mode is serial mode, the hardware trust token is transmitted to the next level stack unit via the encrypted transmission link through the security engine of the upper stack unit in two adjacent stack units. The hardware trust token is verified by the security engine of the next-level stacking unit, and local security verification is performed in the stacking unit after successful verification. With all of the stacked units having passed local security verification, the three-dimensional stacked chip is activated via the central security controller.

13. An electronic device, characterized in that, The electronic device includes a processor, wherein the processor comprises: a three-dimensional stacked chip according to any one of claims 1 to 11.

Images