A dynamic identity mutual trust starting method and system
By employing a dynamic identity mutual trust startup method, a stable seed is restored using a physically non-clonable function, identity key pairs are generated, and a shared key is negotiated. This solves the security problem during the startup phase of the vehicle terminal, achieves coordinated blocking of anti-tampering and anti-rollback measures, and improves the system's security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN STREAMING VIDEO TECH
- Filing Date
- 2026-05-25
- Publication Date
- 2026-07-31
AI Technical Summary
In existing technologies, the system-on-chip (SoC) of vehicle terminals cannot simultaneously cover firmware integrity and identity trust during the startup phase, which may allow attackers to implant backdoors or roll back to older versions, creating a system security vulnerability. Furthermore, the lack of security hardware in the MCU makes the identity system susceptible to tampering.
The dynamic identity mutual trust startup method is adopted. A stable seed is restored through a physical non-cloning function, a root device synthetic identifier is generated and identity key pairs are derived level by level. The shared key is negotiated and the public key proof is verified. Pre-set checks are performed to prevent tampering and rollback.
It reduces the lifecycle risks caused by static key leakage, achieves linked blocking of tamper-proofing and rollback prevention, and improves system security.
Smart Images
Figure CN122490500A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of information security and trusted startup technology for vehicle-mounted terminals, and in particular to a dynamic identity mutual trust startup method and system. Background Technology
[0002] Vehicle terminals commonly employ a heterogeneous architecture of System-on-Chip (SOC) and Microcontroller Unit (MCU). The SOC handles complex operating systems, network communication, and applications. The MCU handles power management, CAN communication, and real-time control. If the firmware integrity and identity trust of both the SOC and MCU cannot be simultaneously guaranteed during the startup phase, attackers may implant backdoors on the MCU side or roll back to a vulnerable older version, creating a security vulnerability in the system.
[0003] Currently, collaborative secure boot typically uses the System-on-a-Chip (SoC) as the root of trust, embedding the root key or public key hash in the SoC's eFuse or OTP, and then establishing a trust chain based on hierarchical signature verification or digest comparison. This type of solution permanently embeds the root trust anchor on the chip. If key leaks occur at the manufacturing end or in the supply chain, or if static root information is obtained by physical means, the risks throughout the device's lifecycle are difficult to mitigate. Furthermore, on the MCU side, MCUs typically lack secure hardware such as eFuse, HSM, or TPM, making it difficult to securely store long-term private keys. This causes the MCU's identity system to rely on software protection, making it vulnerable to offline reading or bypassing via firmware tampering.
[0004] Therefore, how to solve the above-mentioned technical defects has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] The purpose of this application is to provide a dynamic identity mutual trust initiation method and system, which can reduce the risk of static key leakage and achieve linkage blocking of anti-tampering and anti-rollback.
[0006] To address the aforementioned technical problems, this application provides a dynamic identity mutual trust startup method, applied to an on-chip system, comprising: Recover the on-chip system-side stable seed using a physically non-clonable function; The system-on-chip root device composite identifier is generated based on the system-on-chip stable seed, and the identity key pair is derived level by level based on the system-on-chip root device composite identifier and the firmware metric value to obtain the identity key pair used for this startup on the system-on-chip side. Send the first public key certificate to the controller; the first public key certificate is obtained based on the public key of the identity key pair used by the on-chip system for this startup; The second public key proof is verified, and if the second public key proof is verified successfully, a shared key is negotiated with the controller, and a local authentication tag is determined based on the shared key; the second public key proof is returned by the controller after verifying the first public key proof. When the local authentication tag is equal to the authentication tag sent by the controller, a preset check is performed on the target parameters sent by the controller; If the check passes, a startup license tag and a token authentication tag are sent to the controller.
[0007] In some embodiments, determining the local authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The local authentication tag is determined based on the session key and controller metric statement.
[0008] In some embodiments, verifying the second public key proof includes: The second public key is verified using the controller-side stable root reference public key; the controller-side stable root reference public key is pre-registered in the on-chip system security domain.
[0009] In some embodiments, performing a preset check on the target parameters sent by the controller includes: Perform validity and rollback prevention checks on the controller firmware version count and controller-side firmware metric values sent by the controller.
[0010] In some embodiments, it also includes: Write the target phase identity public key, firmware metric, and public key proof to the metric log area.
[0011] To address the aforementioned technical problems, this application also provides a dynamic identity mutual trust initiation method, applied to a controller, comprising: The stable seed on the controller side is recovered using a physically non-clonable function; The root synthesizer identifier on the controller side is determined based on the stable seed on the controller side, and the identity key pair used for this startup on the controller side is determined based on the root synthesizer identifier on the controller side. Receive and verify the first public key certificate sent by the on-chip system; If the first public key proof passes verification, a second public key proof is returned to the on-chip system; the second public key proof is obtained based on the identity public key in the identity key pair used by the controller side for this startup. After the on-chip system verifies the second public key proof, it negotiates a shared key with the on-chip system, determines an authentication tag based on the shared key, and sends the authentication tag to the on-chip system. When the local authentication tag is equal to the authentication tag sent by the controller, the on-chip system performs a preset check on the target parameters sent by the controller, and sends a start-up permission tag and a token authentication tag to the controller when the check passes. Receive and verify the contents of the startup license tag and token authentication tag. If the verification is successful, proceed to the business firmware.
[0012] In some embodiments, recovering the controller-side stable seed via a physically non-clonable function includes: The stable seed on the controller side is recovered by a physically unclonable function in the startup state of the static random access memory.
[0013] In some embodiments, verifying the first public key proof includes: The first public key proof is verified using the on-chip system-side stable root reference public key; the on-chip system-side stable root reference public key is pre-installed on the controller side.
[0014] In some embodiments, determining the authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The authentication tag is determined based on the session key and the controller metric statement.
[0015] To address the aforementioned technical problems, this application also provides a dynamic identity mutual trust startup system, including a system-on-a-chip (SoC) and a controller; the SoC is used to implement the steps of the dynamic identity mutual trust startup method applied to the SoC as described above, and the controller is used to implement the steps of the dynamic identity mutual trust startup method applied to the controller as described above.
[0016] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the dynamic identity mutual trust startup method applied to a system-on-a-chip as described above, or implements the steps of the dynamic identity mutual trust startup method applied to a controller as described above.
[0017] As can be seen, the dynamic identity mutual trust boot method provided in this application utilizes a physically non-clonable function to recover a stable seed and does not persistently store the private key in Flash or eFuse, thereby reducing the lifecycle risk caused by static key leakage. Furthermore, this application incorporates firmware metrics into key derivation, enabling a strong binding between the derived identity key and the current firmware version. The on-chip system performs checks; firmware tampering or rollback will cause the metric or version check to fail, thus preventing the issuance of a boot license token, achieving coordinated blocking against tampering and rollback.
[0018] The dynamic identity mutual trust initiation system provided in this application also has the above-mentioned technical effects. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 A flowchart illustrating a dynamic identity mutual trust initiation method provided in an embodiment of this application; Figure 2 A flowchart illustrating a dynamic identity mutual trust initiation method provided in an embodiment of this application; Figure 3 A PUF-DICE derivation and public key proof framework diagram provided for embodiments of this application; Figure 4 This is a timing diagram of collaborative mutual verification provided in an embodiment of this application. Detailed Implementation
[0021] The core of this application is to provide a dynamic identity mutual trust initiation method and system, which can reduce the risk of static key leakage and achieve linkage blocking of anti-tampering and anti-rollback.
[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0023] Please refer to Figure 1 , Figure 1This is a flowchart illustrating a dynamic identity mutual trust initiation method provided in an embodiment of this application. The method is applied to a system-on-a-chip (SoC). (Refer to...) Figure 1 As shown, the method includes: S101: Recover the on-chip system-side stable seed using a physically non-clonable function.
[0024] After the system-on-chip (SoC) powers on, it performs PUF (Physically Unclonable Function) extraction and error correction in the security domain to restore the stable seed. The stable seed restored by the SoC is called the SoC-side stable seed. The stable seed, i.e., the root seed, is not written to Flash or stored in eFuse.
[0025] S102: Generate a root device composite identifier on the system-on-chip side based on the stable seed on the system-on-chip side, and derive identity key pairs step by step based on the root device composite identifier on the system-on-chip side and the firmware metric value to obtain the identity key pair used for this startup on the system-on-chip side.
[0026] Based on the on-chip system-side stable seed generation root device synthesis identifier: .
[0027] This is the identifier for the SOC-side root synthesis device; the bit length is determined by the HKDF output configuration. This is a function derived from the key. This is a stable seed (bit string, length defined by PUF and extractor) for the SOC side. This is an encoded byte string containing context information from the SOC side. The content may include device model, batch, and policy version, and the length is determined by the context encoding rules.
[0028] Derive stable root identity key pairs based on the root device synthesized identifier: .
[0029] This is a stable root identity key pair on the SOC side, used to prove the origin of the public key for this startup. The key length is determined by the selected elliptic curve parameters. This is the key generation function.
[0030] Firmware for each level of the boot chain Calculate the metric and derive it level by level.
[0031] .
[0032] .
[0033] .
[0034] The SOC startup chain contains n metric stages, where i is the index (positive integer) of the startup chain metric stage. n is the total number of measurement stages on the SOC side (a positive integer).
[0035] To facilitate mutual authentication and session binding, the metrics from each stage on the SOC side are aggregated into a summary: .
[0036] The identity key pair used for mutual authentication on the SOC side during this startup is taken as the final stage key pair: .
[0037] This is the firmware metric for level i, and the bit length is determined by the digest algorithm output. This is a summary function. This is the byte sequence of the i-th level boot firmware image, and its length is determined by the size of the corresponding boot image. The SOC-side metric is a pooled digest, and the bit length is determined by the digest algorithm output. This is the identifier for the synthesizing device derived from the i-th level, and its bit length is determined by the HKDF output configuration. For the i-th level identity key pair, the key length is determined by the selected elliptic curve parameters. This is a one-time identity key pair used for mutual authentication and session negotiation on the SOC side during this startup. The key length is determined by the selected elliptic curve parameter.
[0038] In some embodiments, it also includes: Write the target phase identity public key, firmware metric, and public key proof to the metric log area.
[0039] The target phase is the selected critical phase. The on-chip system writes the public key, firmware metric, and public key proof of the critical phase to the metric log area for subsequent auditing and remote verification.
[0040] S103: Send the first public key certificate to the controller; the first public key certificate is obtained based on the identity public key in the identity key pair used by the on-chip system for this startup.
[0041] During startup, the on-chip system sends a message to the controller (which can be an MCU). , and And include public key proofs for these fields: .
[0042] .
[0043] The first public key proof is the public key certificate generated by the SOC side for the identity public key used in this startup. The data length is determined by the output of the signature algorithm. This is the stable root identity private key for the SOC side. This is the public key for the identity of the SOC side during this startup. The random number generated for the SOC has a bit length determined by the random number design and is unique in each startup session. This is for splicing operations. This is the signature generation function. This is the signature verification function. This is the SOC stable root identity reference public key, or the verification public key that can be parsed from its certificate.
[0044] S104: Verify the second public key proof, and after the second public key proof is verified, negotiate a shared key with the controller, and determine the local authentication tag based on the shared key; the second public key proof is returned by the controller after verifying the first public key proof.
[0045] Controller during verification Once approved, a metric statement and a public key certificate (i.e., a second public key certificate) are generated and returned to the on-chip system.
[0046] .
[0047] .
[0048] .
[0049] The data structure for the controller's metrics is declared, and the encoding length is determined by the number of fields and the encoding rules. This is a firmware metric on the controller side; the bit length is determined by the digest algorithm output. Counts the controller firmware version (dimensionless integer, monotonically increasing, with a range defined by the version management policy). The second public key proof is the public key certificate generated by the controller side for the identity public key of this startup. The data length is determined by the output of the signature algorithm. Provide a stable root identity private key for the controller side. This is the public key for the identity of the MCU side during this startup. The random number generated for the MCU has a bit length determined by the random number design and is unique in each startup session. Provides a stable root identity reference public key for the controller.
[0050] The controller powers on and runs BootStub, restores the stable seed and generates a stable root identity key pair, calculates the metric value of the service firmware or key code segment, and then obtains the one-time identity key pair used for this startup on the controller side.
[0051] .
[0052] .
[0053] .
[0054] .
[0055] .
[0056] The stable seed (bit string) is obtained by recovering the PUF on the controller side. This is an encoded byte string containing context information for the controller side. The content may include chip model, device number field, etc., and the length is determined by the context encoding rules. This is the identifier for the controller-side root synthesizer, derived from the stable seed and context, with its bit length determined by the HKDF output configuration. A stable root identity key pair is provided on the controller side to prove the origin of the public key for this startup. The key length is determined by the selected elliptic curve parameter. This is a byte sequence of the controller-side business firmware or key code segments, the length of which is determined by the size of the corresponding firmware image. This is a firmware metric on the controller side; the bit length is determined by the digest algorithm output. The bit length is determined by the HKDF output configuration and serves as a derived identifier for the bound firmware version. This is a one-time identity key pair used by the controller for this startup. The key length is determined by the selected elliptic curve parameter.
[0057] Through the above derivation method, the controller-side identity for this startup is simultaneously bound to the hardware root secret and the current business firmware state, providing verifiable input for subsequent mutual authentication.
[0058] In some embodiments, verifying the second public key proof includes: The second public key is verified using the controller-side stable root reference public key; the controller-side stable root reference public key is pre-registered in the on-chip system security domain.
[0059] To prevent man-in-the-middle attacks from replacing the public key during the initial setup, a stable root identity reference public key is established on the controller side during the manufacturing or initial trusted pairing phase. Pre-registered in the SOC security domain, the SOC-side stable root identity reference public key Or its certificate is pre-installed on the controller side. The on-chip system uses... check .
[0060] Controller during verification After passing the verification, the on-chip system performs the following checks. After the agreement is reached, both parties will negotiate and share a secret based on a one-time identity key: .
[0061] Z represents the shared secret, and the bit length is determined by the selected elliptic curve parameters.
[0062] The system-on-chip determines the local authentication tag based on the shared key.
[0063] In some embodiments, determining the local authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The local authentication tag is determined based on the session key and controller metric statement.
[0064] The session key will be bound to a shared secret, firmware metrics from both the system-on-chip (SoC) and the controller, and random numbers from both the SoC and the controller. .
[0065] This is the session key for the startup phase; its bit length is determined by the HKDF output configuration.
[0066] System-on-a-chip use check From the received Extract and , combined Z and Calculate session key .
[0067] Calculate the local authentication tag based on the session key. : .
[0068] S105: Compare the local authentication tag with the authentication tag sent by the controller, and if the local authentication tag is equal to the authentication tag sent by the controller, perform a preset check on the target parameter sent by the controller.
[0069] if If the verification is successful, it proves that the metric claim has not been tampered with and originates from a controller possessing the corresponding one-time identity private key and having passed stable root identity verification. The controller uses the session key to calculate the authentication tag from the metric claim. The SOC performs pre-defined checks on the target parameters sent by the controller based on the policy.
[0070] In some embodiments, performing a preset check on the target parameters sent by the controller includes: Perform validity and rollback prevention checks on the controller firmware version count and controller-side firmware metric values sent by the controller.
[0071] SOC is based on policy pairs and Perform legality and rollback prevention checks (SOC should be verified) and The mapping relationship is used to prevent version cheating.
[0072] S106: If the check passes, send the startup license tag and token authentication tag to the controller.
[0073] Once public key verification, authentication, and policy checks all pass, the SOC issues a launch permission token or unlocks critical resources. The token contains... To prevent replay issues. If the check fails, the startup license tag and token authentication tag are not sent to the controller.
[0074] .
[0075] .
[0076] Ticket is a startup permission token data structure issued by SOC, used to carry session binding information and policy information. The encoding length is determined by the number of fields and the encoding rules. A random number generated for the MCU. PolicyId is the policy identifier, which can be an integer or bit-field encoded, and its value range is defined by the policy library. For token authentication tags, the bit length is determined by the HMAC output configuration.
[0077] Controller side verification After passing, further inspection is required. It is consistent with the locally generated one; at the same time, it selects the corresponding policy constraint based on the PolicyId and decides whether to allow entry into the business firmware; otherwise, it stays in BootStub and maintains the minimum security state.
[0078] In summary, the dynamic identity mutual trust boot method provided in this application utilizes a physically unclonable function to recover a stable seed and does not persistently store the private key in Flash or eFuse, thereby reducing the lifecycle risk caused by static key leakage. Furthermore, this application incorporates firmware metrics into key derivation, enabling a strong binding between the derived identity key and the current firmware version. The on-chip system performs checks; firmware tampering or rollback will cause the metric or version check to fail, thus preventing the issuance of a boot license token, achieving coordinated blocking against tampering and rollback.
[0079] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a dynamic identity mutual trust initiation method provided in an embodiment of this application. The method is applied to a controller. (Refer to...) Figure 2 As shown, the method includes: S201: Recover the stable seed on the controller side using a physically non-clonable function.
[0080] The controller powers on and runs BootStub to restore the stable seed. The stable seed restored on the controller side is called the controller-side stable seed.
[0081] In some embodiments, recovering the controller-side stable seed via a physically non-clonable function includes: The stable seed on the controller side is recovered by a physically unclonable function in the startup state of the static random access memory.
[0082] The controller-side stable seed is recovered using a static random access memory boot-state physically unclonable function or other lightweight PUF.
[0083] Using SRAM boot state or lightweight PUF to restore stable seed can provide a reliable source of trust for low-cost MCUs that lack secure storage hardware, reducing reliance on external security chips.
[0084] S202: Determine the identity key pair to be used for this startup on the controller side based on the controller-side stable seed.
[0085] The controller generates a stable root identity key pair, calculates the metric value of the business firmware or key code segment, and then obtains the one-time identity key pair used by the controller for this startup.
[0086] .
[0087] .
[0088] .
[0089] .
[0090] .
[0091] The stable seed (bit string) is obtained by recovering the PUF on the controller side. This is an encoded byte string containing context information for the controller side. The content may include chip model, device number field, etc., and the length is determined by the context encoding rules. This is the identifier for the controller-side root synthesizer, derived from the stable seed and context, with its bit length determined by the HKDF output configuration. A stable root identity key pair is provided on the controller side to prove the origin of the public key for this startup. The key length is determined by the selected elliptic curve parameter. This is a byte sequence of the controller-side business firmware or key code segments, the length of which is determined by the size of the corresponding firmware image. This is a firmware metric on the controller side; the bit length is determined by the digest algorithm output. The bit length is determined by the HKDF output configuration and serves as a derived identifier for the bound firmware version. This is a one-time identity key pair used by the controller for this startup. The key length is determined by the selected elliptic curve parameter.
[0092] S203: Receive and verify the first public key certificate sent by the system-on-chip.
[0093] After power-on, the on-chip system performs PUF (Physically Unclonable Function) extraction and error correction in the security domain to restore the stable seed. The stable seed restored by the on-chip system is called the on-chip side stable seed. The root device synthesis identifier is generated based on the on-chip side stable seed. .
[0094] This is the identifier for the SOC-side root synthesis device; the bit length is determined by the HKDF output configuration. This is a function derived from the key. This is a stable seed (bit string, length defined by PUF and extractor) for the SOC side. This is an encoded byte string containing context information from the SOC side. The content may include device model, batch, and policy version, and the length is determined by the context encoding rules.
[0095] The system-on-chip derives a stable root identity key pair based on the root device synthesized identifier: .
[0096] This is a stable root identity key pair on the SOC side, used to prove the origin of the public key for this startup. The key length is determined by the selected elliptic curve parameters. This is the key generation function.
[0097] Firmware for each level of the boot chain Calculate the metric and derive it level by level.
[0098] .
[0099] .
[0100] .
[0101] The SOC startup chain contains n metric stages, where i is the index (positive integer) of the startup chain metric stage. n is the total number of measurement stages on the SOC side (a positive integer).
[0102] To facilitate mutual authentication and session binding, the metrics from each stage on the SOC side are aggregated into a summary: .
[0103] The identity key pair used for mutual authentication on the SOC side during this startup is taken as the final stage key pair: .
[0104] This is the firmware metric for level i, and the bit length is determined by the digest algorithm output. This is a summary function. This is the byte sequence of the i-th level boot firmware image, and its length is determined by the size of the corresponding boot image. The SOC-side metric is a pooled digest, and the bit length is determined by the digest algorithm output. This is the identifier for the synthesizing device derived from the i-th level, and its bit length is determined by the HKDF output configuration. For the i-th level identity key pair, the key length is determined by the selected elliptic curve parameters. This is a one-time identity key pair used for mutual authentication and session negotiation on the SOC side during this startup. The key length is determined by the selected elliptic curve parameter.
[0105] During startup, the on-chip system sends a message to the controller (which can be an MCU). , and And include public key proofs for these fields: .
[0106] .
[0107] The first public key proof is the public key certificate generated by the SOC side for the identity public key used in this startup. The data length is determined by the output of the signature algorithm. This is the stable root identity private key for the SOC side. This is the public key for the identity of the SOC side during this startup. The random number generated for the SOC has a bit length determined by the random number design and is unique in each startup session. This is for splicing operations. This is the signature generation function. This is the signature verification function. This is the SOC stable root identity reference public key, or the verification public key that can be parsed from its certificate.
[0108] The controller receives the first public key certificate and verifies it.
[0109] In some embodiments, verifying the first public key proof includes: The first public key proof is verified using the on-chip system-side stable root reference public key; the on-chip system-side stable root reference public key is pre-installed on the controller side.
[0110] To prevent man-in-the-middle attacks from replacing the public key during the initial setup, a stable root identity reference public key is established on the controller side during the manufacturing or initial trusted pairing phase. Pre-registered in the SOC security domain, the SOC-side stable root identity reference public key Or its certificate is pre-installed on the controller side. The controller uses... check .
[0111] S204: If the first public key proof passes the verification, a second public key proof is returned to the on-chip system; the second public key proof is obtained based on the identity public key in the identity key pair used by the controller side for this startup.
[0112] Controller during verification Once approved, a metric statement and a public key certificate (i.e., a second public key certificate) are generated and returned to the on-chip system.
[0113] .
[0114] .
[0115] .
[0116] The data structure for the controller's metrics is declared, and the encoding length is determined by the number of fields and the encoding rules. This is a firmware metric on the controller side; the bit length is determined by the digest algorithm output. Counts the controller firmware version (dimensionless integer, monotonically increasing, with a range defined by the version management policy). The second public key proof is the public key certificate generated by the controller side for the identity public key of this startup. The data length is determined by the output of the signature algorithm. Provide a stable root identity private key for the controller side. This is the public key for the identity of the MCU side during this startup. The random number generated for the MCU has a bit length determined by the random number design and is unique in each startup session. Provides a stable root identity reference public key for the controller.
[0117] S205: After the on-chip system verifies the second public key proof, it negotiates a shared key with the on-chip system, determines an authentication tag based on the shared key, and sends the authentication tag to the on-chip system. When the local authentication tag is equal to the authentication tag sent by the controller, the on-chip system performs a preset check on the target parameters sent by the controller, and sends a start-up permission tag and a token authentication tag to the controller when the check passes.
[0118] Controller during verification After passing the verification, the on-chip system performs the following checks. After the agreement is reached, both parties will negotiate and share a secret based on a one-time identity key: .
[0119] Z represents the shared secret, and the bit length is determined by the selected elliptic curve parameters.
[0120] In some embodiments, determining the authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The authentication tag is determined based on the session key and the controller metric statement.
[0121] The session key will be bound to a shared secret, firmware metrics from both the system-on-chip (SoC) and the controller, and random numbers from both the SoC and the controller. .
[0122] This is the session key for the startup phase; its bit length is determined by the HKDF output configuration.
[0123] The controller uses the session key to calculate the authentication tag from the metric claim: .
[0124] if If the verification is successful, it proves that the metric claim has not been tampered with and originates from a controller that possesses the corresponding one-time identity private key and has passed stable root identity verification. The SOC performs a pre-defined check on the target parameters sent by the controller based on the policy.
[0125] SOC issues launch license tokens or unlocks critical resources. Tokens contain... To resist replay.
[0126] .
[0127] .
[0128] Ticket is a startup permission token data structure issued by SOC, used to carry session binding information and policy information. The encoding length is determined by the number of fields and the encoding rules. A random number generated for the MCU. PolicyId is the policy identifier, which can be an integer or bit-field encoded, and its value range is defined by the policy library. For token authentication tags, the bit length is determined by the HMAC output configuration.
[0129] S206: Receive and verify the contents of the startup license tag and the token authentication tag. If the verification is successful, proceed to the business firmware.
[0130] Controller during verification After passing, further inspection is required. It is consistent with the locally generated one; at the same time, it selects the corresponding policy constraint based on the PolicyId and decides whether to allow entry into the business firmware; otherwise, it stays in BootStub and maintains the minimum security state.
[0131] In summary, the dynamic identity mutual trust boot method provided in this application utilizes a physically unclonable function to recover a stable seed and does not persistently store the private key in Flash or eFuse, thereby reducing the lifecycle risk caused by static key leakage. Furthermore, this application incorporates firmware metrics into key derivation, enabling a strong binding between the derived identity key and the current firmware version. The on-chip system performs checks; firmware tampering or rollback will cause the metric or version check to fail, thus preventing the issuance of a boot license token, achieving coordinated blocking against tampering and rollback.
[0132] This application also provides a dynamic identity mutual trust startup system, including a system-on-a-chip (SoC) and a controller; the SoC is used to implement the steps of the dynamic identity mutual trust startup method applied to the SoC as described in any of the above embodiments, and the controller is used to implement the steps of the dynamic identity mutual trust startup method applied to the controller as described in any of the above embodiments.
[0133] The system uses a PUF to restore a stable seed early in the boot process. This stable seed is neither written to Flash nor permanently stored in the eFuse. Each firmware metric is incorporated into the derivation process, forming a hierarchical identity bound to the firmware version. A stable root identity key derived from the root synthesized device identifier (CDI) is used to verify the one-time public key for this boot, preventing public key replacement and man-in-the-middle attacks. During the boot phase, the SOC and controller exchange verified one-time public keys and perform ECDH negotiation for a session key. This session key is bound to both the metrics and a random number. The controller sends a declaration of the bound metrics and generates an authentication tag using the session key. Upon successful verification by the SOC, a boot license token is issued or critical resources are unlocked.
[0134] The system includes a security domain on the SOC side and a startup domain on the controller side, and achieves mutual authentication and session negotiation through a communication link.
[0135] SOC-side security domains include: The PUF extraction and error correction module is used to recover the PUF response into a stable seed. .
[0136] The DICE derivation engine is used to derive CDI, stable root identity key, and session identity key step by step based on metric values.
[0137] The metrics log area is used to store metrics values for each stage. Derived public key Audit information such as public key proofs and policy versions.
[0138] The device registration reference library is used to store the controller stable root identity reference public key registered during the manufacturing stage or the initial trusted pairing stage. and strategy mapping.
[0139] The session management module is used for verifying public key credentials and negotiating. Issue start-up permission tokens and manage random numbers and session state.
[0140] The controller-side startup domain includes: SRAM boot-state extraction or lightweight PUF module for restoring stable seeds .
[0141] The reference public key area is used to store the SOC stable root identity reference public key. Or its certificate.
[0142] BootStub is the minimal boot code used to perform PUF recovery, metric calculation, stable root identity certificate generation, key derivation, and mutual authentication message sending and receiving.
[0143] Service firmware or service loader, used to enter normal operation after obtaining startup permission.
[0144] Communication link: SPI or UART is used for mutual authentication protocol messages and token transmission; an independent hardware reset or gating signal can be used to block startup in case of authentication failure.
[0145] The system's data flow and collaborative workflow includes: Power-on recovery of the root secret and establishment of the metric chain on the SOC side: The SOC performs PUF extraction and error correction in the security domain to restore the stable seed. ; then based on Derived stable root identity key pair Then calculate the metrics for each firmware level in the boot chain. The measurement values are then incorporated into the DICE derivation step by step to form a staged synthetic equipment identifier. Generate the identity key pair for this startup, used for mutual authentication and session negotiation. At the same time, key metrics, public key proofs, and public keys are written to the metrics log area for auditing purposes.
[0146] Controller side power-on restores root secret and binds business firmware: The controller runs BootStub and performs SRAM boot state / lightweight PUF extraction. ,based on Derived stable root identity key pair Calculate metrics for business firmware or critical code segments. and incorporate it into the derived Generate a one-time identity key pair for this startup. .
[0147] Mutual verification handshake and secret sharing negotiation: The SOC and controller exchange a one-time public key and a random number, both verified by a stable root identity, via SPI / UART. The SOC first sends... , , With public key proof ;Generate after controller verification passes With public key proof Then return to SOC and The controller is performing verification. After passing this step, the shared secret Z is calculated using Elliptic Curve Diffie-Hellman Key Negotiation (ECDH), and the session key is derived. SOC receives and verifies Shared secret Z and session key are recalculated afterward. What both parties received Simultaneously binding the SOC / controller metric digest and a bidirectional random number, thereby strongly binding the session to the "current firmware state".
[0148] The controller generates a metric claim and authenticates and sends it: The controller will declare its own metrics. (Include Version count and (Session binding fields, etc.) along with public key proof Send to SOC, using session key The authentication tag is calculated and sent along with the message.
[0149] SOC-side verification of claims, execution policies, and issuance of launch licenses: The SOC first verifies the security domain based on the registered reference public key. The session key is then recalculated and the tag verified to confirm that the claim has not been tampered with and originates from the controller holding the corresponding private key. Subsequently, a legality and rollback prevention check is performed on the whitelist / version watermark in conjunction with the policy. Only when the public key proof, authentication, and policy checks all pass, the SOC issues a launch permission token (Ticket) and calculates the token authentication tag. Return to the controller.
[0150] The controller verifies the token and allows access to the service firmware: Controller verification in BootStub Check the Ticket contents. Once the session binding fields are consistent, allow access to the business firmware; if any step fails, remain in the BootStub secure state and trigger the gating / alarm policy.
[0151] The PUF-DICE derivation and public key proof architecture in the system is as follows: Figure 3 As shown, the timing of collaborative verification is as follows: Figure 4 As shown. Figure 3 and Figure 4 S_soc refers to CDI0_soc refers to Context_soc refers to M_i refers to FW_i refers to CDI-i_soc refers to PK0_soc refers to SK0_soc refers to Proof_soc refers to S_mcu refers to CDI0_mcu refers to Context_soc refers to M_mcu refers to Firmware_app refers to CDI_app_mcu refers to PK0_mcu refers to SK0_mcu refers to PK_mcu refers to SK_mcu refers to Proof_mcu refers to K_sess refers to . Figure 4 Nonce_soc refers to Attest_mcu refers to Nonce_mcu refers to Tag_t refers to .
[0152] This system utilizes a PUF to restore the root seed upon each power-on and avoids persistently storing the private key in Flash or eFuse, reducing the lifecycle risk of static key leakage. Firmware metrics are used in key derivation, strongly binding the derived identity to the current firmware version. After verifying the metric claim, the SOC checks the whitelist / version level using a policy. Firmware tampering or rollback will cause the metric or version to fail to meet the policy, thus preventing the issuance of a boot license token, achieving coordinated blocking against tampering and rollback. The root seed is restored using SRAM boot state or other lightweight PUFs, providing a reliable source of trust for low-cost MCUs lacking secure storage hardware, reducing reliance on external security chips. A stable root identity is used to prove the public key for this boot, and a session key is used to authenticate the metric claim and boot token. Both parties' nonces are incorporated into the message structure and key derivation, achieving anti-replay and proactive man-in-the-middle defense without requiring the MCU to maintain timestamps or monotonic counters. Metric logs are retained in the SOC security domain, and auditable boot proofs are output, facilitating fleet-level compliance checks, issue tracing, and remote maintenance policy linkage.
[0153] For a description of the system provided in this application, please refer to the above method embodiments; further details will not be repeated here.
[0154] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps of a dynamic identity mutual trust startup method applied to a system-on-a-chip or the steps of a dynamic identity mutual trust startup method applied to a controller.
[0155] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0156] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.
[0157] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, devices, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant details can be found in the method section.
[0158] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0159] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0160] The dynamic identity mutual trust initiation method and system provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.
Claims
1. A dynamic identity mutual trust initiation method, characterized in that, Applications in on-chip systems include: Recover the on-chip system-side stable seed using a physically non-clonable function; The system-on-chip root device composite identifier is generated based on the system-on-chip stable seed, and the identity key pair is derived level by level based on the system-on-chip root device composite identifier and the firmware metric value to obtain the identity key pair used for this startup on the system-on-chip side. Send the first public key certificate to the controller; the first public key certificate is obtained based on the public key of the identity key pair used by the on-chip system for this startup; The second public key proof is verified, and if the second public key proof is verified successfully, a shared key is negotiated with the controller, and a local authentication tag is determined based on the shared key; the second public key proof is returned by the controller after verifying the first public key proof. When the local authentication tag is equal to the authentication tag sent by the controller, a preset check is performed on the target parameters sent by the controller; If the check passes, a startup license tag and a token authentication tag are sent to the controller.
2. The dynamic identity mutual trust initiation method according to claim 1, characterized in that, Determining the local authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The local authentication tag is determined based on the session key and controller metric statement.
3. The dynamic identity mutual trust initiation method according to claim 1, characterized in that, Verification of the second public key proof includes: The second public key is verified using the controller-side stable root reference public key; the controller-side stable root reference public key is pre-registered in the on-chip system security domain.
4. The dynamic identity mutual trust initiation method according to claim 1, characterized in that, Performing preset checks on the target parameters sent by the controller includes: Perform validity and rollback prevention checks on the controller firmware version count and controller-side firmware metric values sent by the controller.
5. The dynamic identity mutual trust initiation method according to claim 1, characterized in that, Also includes: Write the target phase identity public key, firmware metric, and public key proof to the metric log area.
6. A method for initiating dynamic identity mutual trust, characterized in that, Applied to controllers, including: The stable seed on the controller side is recovered using a physically non-clonable function; The root synthesizer identifier on the controller side is determined based on the stable seed on the controller side, and the identity key pair used for this startup on the controller side is determined based on the root synthesizer identifier on the controller side. Receive and verify the first public key certificate sent by the on-chip system; If the first public key proof passes verification, a second public key proof is returned to the on-chip system; the second public key proof is obtained based on the identity public key in the identity key pair used by the controller side for this startup. After the on-chip system verifies the second public key proof, it negotiates a shared key with the on-chip system, determines an authentication tag based on the shared key, and sends the authentication tag to the on-chip system. When the local authentication tag is equal to the authentication tag sent by the controller, the on-chip system performs a preset check on the target parameters sent by the controller, and sends a start-up permission tag and a token authentication tag to the controller when the check passes. Receive and verify the contents of the startup license tag and token authentication tag. If the verification is successful, proceed to the business firmware.
7. The dynamic identity mutual trust initiation method according to claim 6, characterized in that, Recovering the controller-side stable seed using a physically non-clonable function includes: The stable seed on the controller side is recovered by a physically unclonable function in the startup state of the static random access memory.
8. The dynamic identity mutual trust initiation method according to claim 6, characterized in that, Verification of the first public key proof includes: The first public key proof is verified using the on-chip system-side stable root reference public key; the on-chip system-side stable root reference public key is pre-installed on the controller side.
9. The dynamic identity mutual trust initiation method according to claim 6, characterized in that, Determining the authentication tag based on the shared key includes: The session key is determined based on the shared key, the on-chip system-side firmware metric aggregation digest, the controller-side firmware metric value, the on-chip system-side random number, and the controller-side random number. The authentication tag is determined based on the session key and the controller metric statement.
10. A dynamic identity mutual trust initiation system, characterized in that, It includes an on-chip system and a controller; the on-chip system is used to implement the steps of the dynamic identity mutual trust startup method as described in any one of claims 1 to 5, and the controller is used to implement the steps of the dynamic identity mutual trust startup method as described in any one of claims 6 to 9.