Management method and device for preventing BMS firmware from being flashed

Abstract

The invention provides a management method and device for preventing BMS firmware from being flashed, and relates to the technical field of asymmetric encryption, and the method comprises the steps: generating a unique response, and reconstructing an equipment root key, so as to establish a trusted firmware execution environment and complete firmware digital signature verification; digital certificate exchange and bidirectional verification of the BMS and the diagnostic instrument are carried out in the trusted firmware execution environment, a dynamic session key is generated, and a challenge response mechanism is executed to ensure that firmware flashing operation is only authorized in the trusted communication environment; performing hash check, control flow monitoring and access auditing by using the security reference data based on the dynamic session key, performing real-time hardware processing when an exception is detected, and recording a security event at the same time; and the BMS uploads the log and attack behavior characteristics corresponding to the security event to a cloud platform, and the cloud platform analyzes and generates a detection rule or certificate revocation list and issues and updates the detection rule or certificate revocation list. Through the dynamic BMS firmware flashing protection method, the safety of the BMS firmware is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of asymmetric encryption, and in particular to a management method and device for preventing BMS firmware from being flashed. BACKGROUND

[0002] With the rapid development of new energy vehicles and energy storage systems, the safety, reliability and reliability of the battery management system (BMS) as the core control unit are crucial. The BMS firmware carries key algorithms such as battery state estimation, thermal management, charge and discharge control, fault diagnosis, etc. Once tampered or flashed illegally, it may cause battery performance to drop sharply, thermal runaway, even fire and explosion, etc. Serious safety accidents, but also cause the leakage of core algorithm intellectual property rights.

[0003] Currently, the industry mainly protects the flashing of BMS firmware based on the security authentication services provided by international standards. This scheme usually uses a simple "seed-key" challenge-response mechanism, the basic principle of which is: the BMS generates a random seed, and the legal diagnostic tool calculates the correct key according to the seed using a pre-set algorithm and returns it to the BMS, and the flashing operation can be performed after verification.

[0004] The existing "seed-key" algorithm is usually static and fixed in the code. Once the attacker cracks the algorithm logic through reverse engineering, etc., it can counterfeit the legal diagnostic tool and illegally access and flash the BMS of the entire vehicle model or even the vehicle fleet, with huge security risks. Therefore, a dynamic BMS firmware flashing protection method is needed to improve the security of the BMS firmware. SUMMARY

[0005] The present application provides a management method and device for preventing BMS firmware from being flashed, which improves the security of the BMS firmware through a dynamic BMS firmware flashing protection method.

[0006] In a first aspect of the present application, a management method for preventing BMS firmware from being flashed is provided, the method comprising: When the BMS master unit is powered on, a unique response is generated and a device root key is re-established to establish a trusted firmware execution environment and complete firmware digital signature verification; When the diagnostic instrument issues a firmware flashing request, the digital certificate exchange and two-way verification of the BMS and the diagnostic instrument are performed in the trusted firmware execution environment, a dynamic session key is generated and a challenge-response mechanism is executed to ensure that the firmware flashing operation is only authorized in a trusted communication environment; During the running of the BMS application, hash verification, control flow monitoring and access audit are performed based on the dynamic session key using security benchmark data, and real-time hardware disposal is performed when an exception is detected, while recording a security event; After the exception disposal is completed, the BMS uploads the log corresponding to the security event and attack behavior characteristics to a cloud platform, and a detection rule or a certificate revocation list is generated by cloud analysis and is issued for updating, so that a dynamic evolution and continuous protection closed loop of the guardian thread and the security module is realized.

[0007] On the basis of the above technical solutions, preferably, when the diagnostic instrument issues a firmware flashing request, the BMS and the diagnostic instrument exchange digital certificates and perform bidirectional verification in the trusted firmware execution environment, a dynamic session key is generated and a challenge-response mechanism is performed to ensure that the firmware flashing operation is only authorized in a trusted communication environment, and specifically includes: During the security authentication process before the BMS performs firmware flashing, when the diagnostic instrument issues a flashing session establishment request to the BMS, the security module in the BMS application first initiates bidirectional identity authentication to establish a trust relationship between the two communication parties; The BMS sends a first device certificate to the diagnostic instrument, the first device certificate is generated by signing the BMS device public key using a private key of a certificate authority, and the BMS requests the diagnostic instrument to send a second diagnostic instrument certificate; After the BMS and the diagnostic instrument receive the opposite certificates, both use the locally preset public key of the certificate authority to verify the authenticity, signature validity, validity period state and revocation state of the opposite certificate, and when any certificate verification fails, the flashing session is immediately terminated and a security event of an illegal device attempting to access is recorded, and when both certificates are verified successfully, the dynamic session key generation and challenge-response stage is entered; In the challenge-response stage, the BMS generates a random number as a challenge seed, combines the challenge seed with a current session identifier and a timestamp to form challenge information, encrypts the challenge information using the public key in the second diagnostic instrument certificate and sends it to the diagnostic instrument, the diagnostic instrument uses a private key to decrypt and calculates a response value according to a preset security algorithm and returns it to the BMS, the BMS calculates an expected response value based on the same dynamic parameters and security algorithm and performs comparison, when the response values are consistent, the firmware flashing permission is unlocked, and when the response values are inconsistent, an authentication failure event is recorded and the flashing function is temporarily locked when the number of consecutive failures exceeds a threshold.

[0008] On the basis of the above technical solutions, preferably, during the running of the BMS application, hash verification, control flow monitoring and access audit are performed based on the dynamic session key using security benchmark data, and real-time hardware disposal is performed when an exception is detected, while recording a security event, and specifically includes: In the BMS running stage, a hybrid monitoring strategy mainly using hardware performance counters and supplemented by software instrumentation is adopted, and the monitoring granularity is dynamically adjusted according to the system running state and threat level, so as to balance the security protection strength and performance overhead. The hardware performance counter automatically counts the number of occurrences of hardware events such as branch instruction misprediction, illegal memory access, and instruction prefetch error through a special register built in the BMS master unit, and is used to continuously perform global monitoring under the normal running state of the vehicle. The software instrumentation inserts monitoring instructions at the entrances and exits of key functions and jump points during the source code compilation stage to generate memory markers and achieve accurate positioning of abnormalities, and when the hardware monitoring detects potential abnormalities, the system enters the security diagnosis mode to enable full instrumentation, and the function modules with the highest security level are always monitored. After the BMS application core is started, the guardian thread is started in an independent core or a high-priority task, and security reference data including reference hash values of key code segments, legal control flow graphs, and security policies are loaded from the protected storage area. The guardian thread performs periodic and triggered monitoring with reference to the security reference data, performs memory integrity verification by calculating the hash values of code segments and data segments, performs control flow monitoring by reading hardware performance counters or verifying the order of guard instructions, and performs security behavior auditing on access behaviors of security-critical resources. When an abnormality is detected, the guardian thread forcibly resets the BMS application core, disconnects the main negative contactor through the hardware security pin, records the non-erasable security event fault code in the non-volatile memory, and uploads it to the cloud platform, and permanently locks the firmware flashing function in the case of a serious abnormal event.

[0009] On the basis of the above technical solutions, preferably, after the abnormality is handled, the BMS uploads the log corresponding to the security event and the attack behavior characteristics to the cloud platform, and the cloud analysis generates detection rules or certificate revocation list and issues updates, specifically including: The local recorded security audit log and security event record are encrypted and uploaded to the cloud platform through the vehicle-mounted network, the cloud platform performs large-scale data analysis based on the received multi-vehicle security data to identify potential global threats, and when it is detected that multiple vehicles receive illegal access requests from the same certificate, the certificate is marked as having a risk of leakage and is added to the global certificate revocation list. After completing the threat identification, the cloud platform generates new detection rules or updates the challenge-response algorithm parameters according to the analysis results, and issues them to the BMS after encryption and signature through the over-the-air download channel. In the over-the-air download channel establishment process, the BMS and the cloud platform perform four stages of mutual authentication, security key negotiation, secure data transmission and secure installation and feedback in turn, the mutual authentication verifies the legality of each other through device certificate and server certificate, the security key negotiation generates a session key based on asymmetric encryption, the secure data transmission encrypts the update data using the session key and verifies the data integrity through digital signature, and the secure installation and feedback stage verifies and loads the update rules and security policies by the vehicle-mounted end monitoring thread and the security module, and feeds back the installation result to the cloud platform.

[0010] Based on the above technical solutions, preferably, the method further comprises: After successfully decrypting the challenge information, the challenge seed, session identifier and timestamp are extracted and spliced in a fixed order to form a challenge information message body, a one-way hash operation is performed on the challenge information message body to generate a hash digest value, and a derived key is generated by combining and calculating the current session binding key, the challenge seed and the hash digest value; The derived key is used to call a message authentication module to generate a response value by performing a hash-based message authentication code algorithm with the challenge information message body as input, and the response value is signed and encrypted and then returned to the BMS; The BMS calculates an expected response value according to the same security algorithm path and input parameters and compares them, authorizes the firmware flashing operation when the response value and the expected response value are consistent, and triggers the security module to record an authentication failure event and start a flashing lock counting process when they are inconsistent.

[0011] Based on the above technical solutions, preferably, when the BMS master unit is powered on, a unique response is generated and a device root key is reconstructed to establish a trusted firmware execution environment and complete firmware digital signature verification, specifically including: During the process of executing the boot program code by the BMS master unit, the boot program code activates the physically unclonable function circuit and applies an excitation signal, so that the physically unclonable function circuit generates a unique response according to the physical structure difference, the unique response is input into the key derivation function to reconstruct the device root key, and the device root key includes a device root private key and a device root public key, wherein the device root private key only exists temporarily in the register during the current startup period and cannot be read through the external interface, and the device root public key is used for subsequent firmware digital signature verification and communication key derivation, so that the BMS establishes a trusted root in the startup stage and provides an encryption basis for subsequent firmware verification and secure communication.

[0012] Based on the above technical solutions, preferably, when the BMS master unit is powered on, a unique response is generated and a device root key is reconstructed to establish a trusted firmware execution environment and complete firmware digital signature verification, specifically further including: In the BMS master unit startup phase, the boot program code reads the application firmware and the digital signature appended at the end of the firmware from the external memory, and the digital signature is encrypted by the device manufacturer using the master private key before the firmware is published, and the firmware content is hashed to generate the original hash value; According to the boot program code, the manufacturer's master public key preset in the chip one-time programming storage area or the boot program is called to perform decryption operation on the digital signature to obtain the original hash value, and the hash calculation is performed on the application firmware content based on the same hash algorithm to obtain the real-time hash value; When the original hash value is consistent with the real-time hash value, the program execution control is handed over to the application firmware; When the original hash value is inconsistent with the real-time hash value, the startup process is terminated and the BMS master unit is placed in a safe locking state, and an abnormal notification signal is output to the related components through the fault indication interface.

[0013] In the second aspect of the present application, a management device for preventing BMS firmware from being flashed is provided, which is used to execute any one of the management methods for preventing BMS firmware from being flashed as described above, and the device comprises an acquisition module, a processing module and an output module, wherein: The acquisition module is used to generate a unique response and re-establish a device root key when the BMS master unit is powered on, to establish a trusted firmware execution environment and complete firmware digital signature verification; The processing module is used to perform digital certificate exchange and two-way verification between the BMS and the diagnostic instrument in the trusted firmware execution environment when the diagnostic instrument issues a firmware flashing request, to generate a dynamic session key and execute a challenge-response mechanism, so as to ensure that the firmware flashing operation is only authorized in a trusted communication environment; The processing module is used to perform hash verification, control flow monitoring and access audit based on the dynamic session key using secure benchmark data during the running of the BMS application, and to perform real-time hardware disposal when an exception is detected, and to record security events; The output module is used to upload the logs corresponding to the security events and the attack behavior characteristics to the cloud platform after the exception disposal is completed, to generate detection rules or certificate revocation lists by cloud analysis and to issue updates, so as to realize the dynamic evolution and continuous protection closed loop of the guardian thread and the security module.

[0014] In a third aspect of the present application, an electronic device is provided, comprising a processor, a memory, a user interface and a network interface, the memory being configured to store instructions, the user interface and the network interface each being configured to communicate with other devices, and the processor being configured to execute the instructions stored in the memory to cause the electronic device to perform the method according to any one of the preceding aspects.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, which stores instructions that, when executed, perform the method according to any one of the preceding aspects.

[0016] In summary, the one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. The present application realizes dynamic protection by constructing a multi-layer trust chain in the whole cycle process of the battery management system master unit startup, communication interaction, running monitoring and cloud feedback. In the startup stage, a unique response is generated by a physically unclonable function and a device root key is re-established to ensure that the firmware source is trusted. In the flashing stage, a temporary encrypted session is established through a digital certificate bidirectional verification and challenge-response mechanism to prevent illegal device access. In the running stage, a dynamic session key is used to drive hash verification, control flow monitoring and access audit to realize real-time detection and hardware disposal of abnormalities. In the cloud stage, detection rules and certificate revocation lists are generated based on the uploaded security event logs and are securely issued to make the protection strategy continuously evolve, thereby forming a closed-loop and adaptive dynamic flashing protection system, which significantly improves the security of the BMS firmware.

[0017] 2. The digital certificate bidirectional verification and challenge-response mechanism between the diagnostic instrument and the battery management system constructs a dynamic trusted communication environment. This process requires authentication and encryption authorization for each session during firmware flashing operation, thereby preventing attackers from using fake devices or replaying old sessions for illegal firmware updates, ensuring the uniqueness, traceability and tamper resistance of the firmware flashing process.

[0018] 3. The joint monitoring of hardware performance counters and software instrumentation enables the battery management system to have dynamic security perception capability during operation. Hardware monitoring realizes global low-overhead detection, and software instrumentation provides precise positioning. Both of them adjust the monitoring granularity in different threat levels to balance performance and security. When the system detects an anomaly, it can immediately trigger a hardware-level reset and a safe power-off operation to block potential attack links, prevent fault propagation and maintain system integrity.

[0019] 4. The cloud and on-board collaborative analysis and update mechanism forms a sustainable evolution of the safety closed loop. After uploading the security log and attack features to the on-board end, the cloud performs threat aggregation analysis based on multi-vehicle data, automatically generates detection rules and certificate revocation list, and safely issues updates through the encrypted signed over-the-air download channel, so that the security policy can be dynamically upgraded according to the latest threat, ensuring the consistency and real-time of the vehicle fleet security defense.

[0020] 5. The joint calculation of hash and key derivation function generates the response value, so that each challenge response process is based on real-time parameters rather than fixed algorithms, thereby enhancing the anti-replay and anti-forgery of the authentication process. The battery management system and the diagnostic instrument independently calculate the response value according to the same algorithm path and perform consistency comparison, realizing high-strength verification of the authenticity of the communication session and the integrity of the data, thereby effectively preventing man-in-the-middle attacks and fake communications.

[0021] 6. A physically unclonable function is introduced in the starting phase of the battery management system to dynamically generate a unique response and re-establish a root key, ensuring the physical uniqueness of the device identity and the non-replicability of the key. This mechanism re-establishes the trust root every time it starts, ensuring the security foundation of firmware verification and subsequent communication, thereby preventing malicious device cloning and root key leakage. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 is a flowchart of a management method for preventing BMS firmware from being flashed, disclosed by an embodiment of the present application; Figure 2 is a module schematic diagram of a management device for preventing BMS firmware from being flashed, disclosed by an embodiment of the present application; Figure 3 is a structural schematic diagram of an electronic device, disclosed by an embodiment of the present application.

[0023] Marked with 201, an acquisition module; 202, a processing module; 203, an output module; 301, a processor; 302, a communication bus; 303, a user interface; 304, a network interface; 305, a memory. DETAILED DESCRIPTION

[0024] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be described clearly and completely in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only part of the embodiments of the present application, not all embodiments.

[0025] In the description of the embodiments of the present application, the words such as "for example" or "for instance" are used to represent an example, an illustration, or a description. Any embodiment or design scheme described as "for example" or "for instance" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "for example" or "for instance" are intended to present the relevant concept in a specific manner.

[0026] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more features. The terms "include", "contain", "have" and their variants mean "include but are not limited to", unless otherwise specifically emphasized.

[0027] With the rapid development of new energy vehicles and energy storage systems, the safety and reliability of the battery management system as the core control unit directly affect the stable operation of the vehicle and the energy storage device. The BMS firmware carries key algorithms, including battery state estimation, thermal management, charge and discharge control, and fault diagnosis. Once it is illegally tampered with or rewritten, it may cause performance degradation, thermal runaway, or fire accidents, and cause the leakage of algorithm intellectual property rights. At present, the industry generally uses the security authentication method based on the "seed-key" mechanism of the UDS protocol, but this mechanism is a static algorithm. Once it is cracked by the attacker through reverse analysis, it can be copied to perform illegal rewriting, thereby causing the vehicle safety protection to fail. Therefore, it is urgent to build a battery management system firmware rewriting protection method with dynamic authentication and adaptive defense capability to effectively improve the security of the firmware.

[0028] The embodiment discloses a management method for preventing BMS firmware from being rewritten, referring to Figure 1 , comprising the following steps S110-S140: S110, when the BMS master control unit is powered on, a unique response is generated and a device root key is re-established to establish a trusted firmware execution environment and complete firmware digital signature verification.

[0029] This invention discloses a management method for preventing BMS firmware from being flashed, which is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running a management method for preventing BMS firmware from being flashed. The server can be implemented using a standalone server or a server cluster composed of multiple servers.

[0030] In one possible implementation, when the BMS main control unit is powered on, a unique response is generated and the device root key is reconstructed to establish a trusted firmware execution environment and complete firmware digital signature verification. Specifically, during the execution of boot program code by the BMS main control unit, the boot program code activates the physically unclonable function circuit and applies an excitation signal, causing the physically unclonable function circuit to generate a unique response based on the physical structure difference. The unique response is input into the key derivation function to reconstruct the device root key. The device root key includes a device root private key and a device root public key. The device root private key only exists temporarily in the register of the current boot cycle and cannot be read through the external interface. The device root public key is used for subsequent firmware digital signature verification and communication key derivation, thereby enabling the BMS to establish a root of trust during the boot phase and provide an encrypted foundation for subsequent firmware verification and secure communication.

[0031] Specifically, after the battery management system's main control unit is powered on, the bootloader code is first loaded and executed from the read-only memory area inside the chip. This bootloader code is permanently embedded inside the main control unit's chip, possessing the characteristics of being unmodifiable and indelible, and its function is to serve as the root of trust for the entire system's startup. The purpose of executing the bootloader code is to ensure that the system is in a controlled state during the initial startup phase, preventing malicious code from intervening before the system loads, thereby ensuring that subsequent security functions operate in a trusted environment. After startup, the bootloader code automatically calls the physically unclonable function circuit inside the hardware security module and applies an excitation signal to this circuit to trigger a physical response.

[0032] Physically non-cloning function (PTF) circuits are hardware security structures based on random microscopic differences in semiconductor device manufacturing processes. These circuits exhibit unique physical response characteristics across different chips. The excitation signal is typically a fixed set of voltage or current input patterns. Upon receiving these signals, the circuit generates a unique response based on minute differences in physical parameters such as transistor channels, capacitance, resistance, and interconnect paths. Because these physical parameters are uncopyable and unpredictable, PTF circuits can provide chip-level unique identification without storing keys.

[0033] The generated unique response is not directly used as the key; instead, it is passed as an input parameter to the key derivation function module by the bootstrap code. The key derivation function is a deterministic mathematical algorithm used to generate high-entropy key material from the input seed. Its core function is to transform the physical characteristic value of the unique response into a standardized key output through multiple rounds of hashing and nonlinear operations, thereby enhancing randomness and preventing physical side-channel attacks. After computation by the key derivation function, the output is divided into two parts: the device root private key and the device root public key.

[0034] The device root private key is the unique security identifier of the master control unit, existing only temporarily in the register space during the current boot cycle. This register uses a volatile storage structure, and its contents are automatically cleared after power failure, ensuring that the device root private key cannot be read or stored permanently by external devices. This design achieves "no storage existence" of the key, effectively preventing the possibility of obtaining the private key through peripheral debugging interfaces, fault injection, or cold start attacks. After the bootloader code completes the necessary signature verification calculation using the device root private key, it immediately overwrites the register contents, ensuring that it is used only once during its lifecycle.

[0035] The device root public key is derived from the device root private key and serves as the public credential for subsequent firmware verification and communication key derivation. It is recorded by the manufacturer during the system manufacturing phase and bound to the main control unit's hardware identifier, used to verify the legitimacy of the digital signature during the firmware verification phase. When the main control unit loads the firmware image, the bootloader code uses the device root public key and the manufacturer's master public key to jointly perform digital signature verification to confirm the integrity of the certificate chain and the trustworthiness of the firmware source. Furthermore, the device root public key can also serve as an initial parameter for communication key negotiation, used to generate symmetric communication keys during authentication and encrypted session establishment with diagnostic instruments or cloud platforms, thereby achieving encrypted protection for data transmission.

[0036] During the power-on startup phase, the battery management system completes the excitation of the physically unclonable function circuit, unique response generation, key derivation, and dynamic reconstruction of the device root key. The generation and application of the device root private key and the device root public key form a continuous link. The device root private key provides hardware-level identity authenticity assurance for the system, while the device root public key provides the key foundation for firmware verification and communication encryption. This enables the battery management system to have a trusted computing environment before running any upper-layer application code, achieving a closed-loop security chain from the physical layer to the cryptographic layer.

[0037] In one possible implementation, when the BMS main control unit is powered on, a unique response is generated and the device root key is rebuilt to establish a trusted firmware execution environment and complete firmware digital signature verification. Specifically, during the BMS main control unit startup phase, the bootloader code reads the application firmware and the digital signature appended to the end of the firmware from external memory. The digital signature is generated by the device manufacturer using the master private key to hash the firmware content before firmware release and then encrypting it. According to the bootloader code, the manufacturer's master public key, which is pre-placed in the chip's one-time programming storage area or inside the bootloader, is called to decrypt the digital signature to obtain the original hash value, and the application firmware content is hashed using the same hash algorithm to obtain the real-time hash value. When the original hash value matches the real-time hash value, the program execution control is transferred to the application firmware. When the original hash value does not match the real-time hash value, the startup process is terminated and the BMS main control unit is placed in a secure locked state, while triggering the fault indication interface to output an abnormal notification signal to the relevant components.

[0038] Specifically, during the startup phase of the battery management system's main control unit, after the bootloader code completes the reconstruction of the device's root key, it immediately reads the application firmware to be loaded and its appended digital signature from external storage. External storage is typically off-chip flash memory used to store the main program image and related verification data. This digital signature is generated by the device manufacturer during the firmware release phase. The generation process involves two steps: First, the device manufacturer performs a one-way hash calculation on the entire content of the firmware file using a hash algorithm, such as the secure hash algorithm SHA-256. Then, the manufacturer uses its master private key to perform an encryption operation on the firmware hash digest, generating a unique digital signature file corresponding to that firmware version. This digital signature is appended to the end of the firmware image file before leaving the factory and is stored along with the firmware in external storage for subsequent verification by the main control unit. This step ensures that the firmware file is not tampered with during transmission and storage from the factory until it is loaded and run, guaranteeing the trustworthiness of the firmware's origin.

[0039] After the firmware and digital signature are loaded into the main control unit's internal cache by the bootloader code, the bootloader invokes the manufacturer's master public key, which is pre-stored in the chip's one-time programming storage area or within the bootloader itself. The one-time programming storage area is a permanent, non-erasable storage area within the chip, used to store security constants burned during the manufacturing phase, such as the manufacturer's master public key, device unique identifier, or security configuration parameters. The bootloader uses this master public key to perform a decryption operation on the digital signature; the decryption result is the original hash value. Simultaneously, the bootloader performs an independent hash operation on the just-read firmware content using the same hash algorithm as the manufacturer, generating a real-time hash value. The original hash value represents the signature base digest at the time of firmware release, while the real-time hash value represents the actual digest of the firmware content currently in memory. Comparing these two hash values ​​verifies the integrity of the firmware content. If they match, it indicates that the firmware content has not undergone any changes from generation to loading, and the private key corresponding to the signature belongs to a trusted manufacturer.

[0040] When the original hash value matches the real-time hash value, the bootloader determines that the verification result is successful and transfers program execution control from the boot phase to the application firmware. This transfer process is achieved by modifying the program counter of the main control unit; that is, the bootloader ends its own execution and jumps the processor instruction stream to the entry address of the application firmware. After gaining control, the application firmware takes over the resources of the main control unit and begins to execute battery management functions, including battery status monitoring, energy balancing control, and charge / discharge strategy management. At this point, the system is in a trusted execution environment, and all subsequent operations are based on the verified firmware.

[0041] If the original hash value is inconsistent with the real-time hash value, the bootloader immediately determines that the firmware integrity verification has failed, indicating that the firmware file may have been maliciously tampered with or that an anomaly occurred during transmission. At this point, the bootloader will abort the boot process and place the main control unit in a secure lock state. The secure lock state is a hardware-level security protection mechanism that prohibits the execution of any unauthorized code and restricts access to external communication interfaces. Simultaneously, the bootloader triggers an anomaly signal output from the fault indication interface, which can be a general-purpose input / output port, a control area network bus signal, or a system diagnostic communication channel. The anomaly signal is used to notify the vehicle controller, diagnostic equipment, or safety management module that the current firmware verification has failed, preventing the system from continuing to run potentially risky firmware. This anomaly notification mechanism forms a hardware security closed loop, ensuring that firmware verification failure does not lead to an uncertain or dangerous system state.

[0042] The bootloader code, vendor master key, digital signature, and hash algorithm together constitute the firmware verification chain. The vendor master key and digital signature correspond to the source of trust, the hash algorithm provides the basis for integrity verification, and the security locking mechanism forms an anomaly protection path. The steps are interconnected: firmware reading provides data input for verification, hash comparison provides integrity criteria, and the verification result directly affects the transfer or locking status of system control, thus achieving a continuous security closed loop from startup detection and result judgment to security handling.

[0043] When the diagnostic instrument issues a firmware flashing request, S120 performs digital certificate exchange and two-way verification between the BMS and the diagnostic instrument in the trusted firmware execution environment, generates a dynamic session key and executes a challenge-response mechanism to ensure that the firmware flashing operation is only authorized in the trusted communication environment.

[0044] In one possible implementation, when the diagnostic instrument issues a firmware flashing request, digital certificate exchange and two-way verification between the BMS and the diagnostic instrument are performed in a trusted firmware execution environment. A dynamic session key is generated, and a challenge-response mechanism is executed to ensure that the firmware flashing operation is only authorized within the trusted communication environment. Specifically, this includes: during the security authentication process before firmware flashing performed by the BMS, when the diagnostic instrument sends a request to the BMS to establish a flashing session, the security module within the BMS application first initiates two-way authentication to establish a trust relationship between the two communicating parties; the BMS sends a first device certificate to the diagnostic instrument, which is generated by a trusted certificate authority signing the BMS device's public key with its private key; simultaneously, the BMS requests the diagnostic instrument to send a second diagnostic instrument certificate; after receiving each other's certificates, both the BMS and the diagnostic instrument use their locally pre-installed trusted certificate authority public keys to verify the identity. The system verifies the authenticity, signature validity, validity period, and revocation status of the certificates. If any certificate verification fails, the flashing session is immediately terminated, and a security event of an unauthorized device attempting to access the site is recorded. When both certificates are successfully verified, the system enters the dynamic session key generation and challenge response phase. In the challenge response phase, the BMS generates a random number as a challenge seed and combines the challenge seed with the current session identifier and timestamp to form challenge information. The challenge information is encrypted using the public key in the second diagnostic instrument's certificate and sent to the diagnostic instrument. The diagnostic instrument decrypts the challenge information using its private key and calculates the response value according to a preset security algorithm before returning it to the BMS. The BMS calculates the expected response value based on the same dynamic parameters and security algorithm and compares the results. If the response values ​​match, the firmware flashing permission is unlocked. If the response values ​​do not match, an authentication failure event is recorded, and the flashing function is temporarily locked if the number of consecutive failures exceeds a threshold.

[0045] Specifically, after the diagnostic tool sends a firmware flashing session request to the battery management system (BMS), the security module within the BMS application first initiates a two-way authentication process. The BMS sends a first device certificate to the diagnostic tool. This device certificate is generated by a trusted certificate authority (CCA) using its private key to sign the BMS device's public key, proving the legitimacy and uniqueness of the device's identity. Simultaneously, the BMS requests a second diagnostic tool certificate from the diagnostic tool to ensure that both parties' identities are bound by the same trust chain. After receiving each other's certificates, both parties use their locally pre-installed CCA public keys to verify the integrity and validity of the certificates. This verification includes checking the validity of the digital signature, whether the certificate is valid, and whether it exists on the certificate revocation list. If either party's certificate verification fails, the BMS immediately terminates the flashing session, records the security event of an unauthorized device attempting to access the system, and locks the communication channel. When both parties successfully verify the certificate, the dynamic session key generation and challenge-response phase begins.

[0046] During the dynamic session key generation phase, the battery management system (BMS) calls the true random number generation module to generate a high-entropy random number as the challenge seed. This random number is then combined with the current flashing session identifier and timestamp to form a challenge information structure. This challenge information structure is unique in each session to prevent replay attacks and forged responses. Subsequently, the BMS uses the public key extracted from the diagnostic tool's certificate to perform asymmetric encryption on the challenge information, generating encrypted data which is then sent to the diagnostic tool. Upon receiving the encrypted data, the diagnostic tool decrypts it using its own private key to recover the original challenge information. After decryption, the diagnostic tool performs a joint operation on the challenge seed, session identifier, and timestamp using the same security algorithm as the BMS to generate a response value. This response value is determined by the diagnostic tool's private key and the session dynamic parameters, ensuring uniqueness and resistance to replay attacks.

[0047] After calculating the response value, the diagnostic tool sends it to the battery management system. Upon receiving the response value, the battery management system independently calculates the expected response value locally using the same dynamic parameters and security algorithms, and compares the two results. When the response value matches the expected response value, it indicates that the diagnostic tool is authentic and the communication link has not been tampered with, and the system unlocks firmware flashing permissions, allowing erasure and programming operations. When the response value does not match, the security module records the authentication failure event and increments the authentication failure count. When the count exceeds a preset threshold, the system automatically enters a temporary lock state, rejecting subsequent flashing requests and triggering a security alarm mechanism.

[0048] The entire process establishes a trust chain through certificate verification, generates a unique session identifier through random number generation, ensures the security of challenge information through asymmetric encryption, and ensures that response data cannot be forged through hash algorithms, forming a closed-loop security system that links identity authentication to authorization decisions. This ensures that firmware flashing operations can only be authorized to be executed in a trusted communication environment.

[0049] In one possible implementation, after successfully decrypting the challenge information, the challenge seed, session identifier, and timestamp are extracted and concatenated in a fixed order to form the challenge information message body. A one-way hash operation is performed on the challenge information message body to generate a hash digest value. Then, the current session binding key, challenge seed, and hash digest value are combined to generate a derived key. The derived key is used to call the message authentication module to execute a hash-based message authentication code algorithm to generate a response value with the challenge information message body as input. The response value is then signed, encrypted, and returned to the BMS. The BMS calculates the expected response value based on the same security algorithm path and input parameters and compares it. When the response value matches the expected response value, the firmware flashing operation is authorized. When they do not match, the security module is triggered to record the authentication failure event and start the flashing lock counting process.

[0050] Specifically, the challenge seed, session identifier, and timestamp are first sequentially concatenated using a fixed encoding method to form the challenge information message body. Then, a one-way hash operation is performed on the challenge information message body to obtain a hash digest value. Subsequently, the session binding key, challenge seed, and hash digest value are combined to generate a derived key. To ensure consistency and replay resistance, the field length, encoding method, and concatenation order of the challenge information message body are consistent on both the battery management system and the diagnostic instrument sides. The parameters of the hash function and key derivation function are also consistent, and the calculation relationship is as follows:

[0051]

[0052]

[0053] Among them, the challenge seed is a unique high-entropy random number for this writing session, the session identifier is a unique number for this writing session, the timestamp is the current time record generated by the security clock, the challenge information message body is a message concatenated by the three in a predetermined order and encoding rules, the hash digest value is a fixed-length output obtained by performing a one-way hash operation on the challenge information message body, the session binding key is the key material generated during the session establishment phase and bound to the current session state, and the derived key is the symmetric key used for subsequent authentication calculated by the key derivation function with the session binding key, the challenge seed, and the hash digest value as input; the one-way hash operation provides collision resistance and irreversibility, and the key derivation function provides key isolation and forward secrecy between different sessions.

[0054] Using the derived key as the key and the challenge message body as input, a hash-based message authentication code algorithm is executed to generate a response value. Then, the response value is digitally signed using the diagnostic tool's private key. Finally, the authentication payload containing the response value and digital signature is encrypted using a dynamic session key before being sent. The calculation and packaging relationship is as follows:

[0055]

[0056]

[0057] Among them, the challenge seed is a unique high-entropy random number for this writing session, the session identifier is a unique number for this writing session, the timestamp is the current time record generated by the security clock, the challenge information message body is a message concatenated by the three in a predetermined order and encoding rules, the hash digest value is a fixed-length output obtained by performing a one-way hash operation on the challenge information message body, the session binding key is the key material generated during the session establishment phase and bound to the current session state, and the derived key is the symmetric key used for subsequent authentication calculated by the key derivation function with the session binding key, the challenge seed, and the hash digest value as input; the one-way hash operation provides collision resistance and irreversibility, and the key derivation function provides key isolation and forward secrecy between different sessions.

[0058] Using the derived key as the key and the challenge message body as input, a hash-based message authentication code algorithm is executed to generate a response value. Then, the response value is digitally signed using the diagnostic tool's private key. Finally, the authentication payload containing the response value and digital signature is encrypted using a dynamic session key before being sent. The calculation and packaging relationship is as follows:

[0059] Among them, the expected response value is the local authentication result calculated by the battery management system based on the same derived key and challenge information message body; the consistency judgment is the logical process of comparing the received response value with the expected response value; the authorized flashing is the permission to execute the erase and programming operations; and the failure count is the status of the number of consecutive failures maintained by the security module. When the failure count has not reached the threshold, retry is still allowed. When the failure count reaches the threshold, the flashing lock count process is entered to reject new flashing requests within a set time. This makes the hash operation, key derivation, message authentication, signature encryption and comparison decision connected and form a closed-loop control for firmware flashing authorization.

[0060] During the operation of the BMS application, the S130 performs hash verification, control flow monitoring and access auditing based on the dynamic session key and security baseline data, and performs real-time hardware handling when an anomaly is detected, while recording security events.

[0061] In one possible implementation, during the operation of the BMS application, hash verification, control flow monitoring, and access auditing are performed using security baseline data based on dynamic session keys. Real-time hardware intervention is implemented when anomalies are detected, and security events are recorded. Specifically, during the BMS operation phase, a hybrid monitoring strategy is adopted, primarily using hardware performance counters and secondarily using software instrumentation. The monitoring granularity is dynamically adjusted according to the system's operating status and threat level to achieve a balance between security protection strength and performance overhead. The hardware performance counter automatically counts the occurrence of hardware events such as branch instruction misprediction, illegal memory access, and instruction prefetching errors through a dedicated register built into the BMS main control unit, used for continuous global monitoring during normal vehicle operation. Software instrumentation inserts monitoring instructions at the entry, exit, and jump points of critical functions during the source code compilation phase to generate memory markers and achieve precise anomaly location. When hardware monitoring detects a potential anomaly, it triggers... The system enters security diagnostic mode to enable full instrumentation, continuously monitoring the instrumentation of the highest security-level functional modules. After the BMS application core starts, the monitoring thread starts in an independent core or high-priority task and loads security baseline data from the protected storage area. The security baseline data includes the baseline hash value of critical code segments, legal control flow graphs, and security policies. The monitoring thread performs periodic and trigger-based monitoring with reference to the security baseline data. It performs memory integrity verification by calculating the hash values ​​of code segments and data segments, reads hardware performance counters or verifies the order of watchdog instructions for control flow monitoring, and performs security behavior auditing on access to security-critical resources. When an anomaly is detected, the monitoring thread immediately forces a reset of the BMS application core, disconnects the main negative contactor through the hardware security pin, records an indelible security event fault code in non-volatile memory and uploads it to the cloud platform. In the event of a severe anomaly, the firmware flashing function is permanently locked.

[0062] Specifically, during the battery management system's operation, the safety protection mechanism employs a hardware and software collaborative monitoring approach to balance real-time performance and accuracy. Hardware performance counters and software instrumentation form a hybrid monitoring system. The hardware performance counters, implemented using dedicated registers within the main control unit, automatically collect statistics on low-level events related to program execution without interfering with the main program's execution. These events include branch instruction misprediction, illegal memory access, and instruction prefetching errors. By analyzing the statistical results of these events, it's possible to determine if abnormal jumps or illegal access behaviors have occurred in the control flow. The advantage of hardware performance counters lies in their extremely low monitoring overhead, typically consuming less than one percent of processor resources. They can operate continuously during normal vehicle operation without affecting task real-time performance. To avoid inaccurate localization due to the coarse granularity of hardware monitoring, the system activates a software instrumentation monitoring strategy when the threat level increases or anomalies occur.

[0063] Software instrumentation technology intervenes during the firmware compilation phase, inserting monitoring instructions at critical function entry and exit points and program jump points to achieve precise recording of control flow. Instrumentation instructions write marker values ​​to specific memory addresses at runtime, identifying the current function execution state and code path. The monitoring thread compares these markers in the order they appear with the preset control flow logic to determine if program execution meets expectations. When hardware performance counters detect potential anomalies, such as the number of branch prediction anomalies exceeding a threshold, the system automatically enters a safety diagnostic mode, temporarily enabling full instrumentation to achieve precise fault location without stopping program execution. For the highest safety-level functional modules, such as contactor drivers and state-of-charge estimation algorithms, the system maintains software instrumentation monitoring at all times, even during normal operation, ensuring that critical safety logic is continuously monitored at all times.

[0064] After the main control unit completes application loading and enters the running state, the monitoring thread will start on a separate core or run as a high-priority task in the main core, ensuring that the monitoring task is not interfered with by application scheduling. The monitoring thread first loads security baseline data from the protected storage area. This data is generated during system initialization and stored in the secure area after being verified by the vendor's signature. The security baseline data includes baseline hash values ​​of critical code segments, legal control flow graphs, and a set of security policies. Baseline hash values ​​are used to verify that the program code has not been tampered with at runtime; legal control flow graphs describe the allowed call relationships between functions; and security policies define constraints on executable operations, such as prohibiting direct writing to contactor control registers and requiring indirect operations through secure interface functions. These data collectively constitute a security reference template for the system's runtime phase.

[0065] The monitoring thread performs both periodic and triggered monitoring based on security baseline data. Periodic monitoring calculates the hash values ​​of the monitored code and data segments at fixed time intervals and compares them with the baseline hash value to determine code integrity. Triggered monitoring starts immediately upon detecting abnormal behavior or hardware events, performing real-time verification and control flow verification. Control flow monitoring employs two methods: a hardware method checks whether the program counter is executing within the expected address range by reading performance counters, and a software method confirms whether the control path conforms to a valid control flow graph by comparing the order of instrumentation marker values. The security behavior audit section monitors all operations related to safety-critical resources, including contactor disconnect commands, modification of charge state parameters, and communication interface access. Each monitored operation generates a security log entry containing a timestamp, operator identifier, operation target, and operation parameters for subsequent auditing or cloud-based analysis.

[0066] When the monitoring thread detects an abnormal event, it immediately executes hardware-level handling operations. First, it forcibly resets the application core via the reset control interface or watchdog signal, stopping the abnormal code from running. Simultaneously, it triggers the contactor control circuit by writing a hardware safety pin signal, causing the main negative contactor to disconnect, powering down the high-voltage system, and preventing further escalation of the fault. While executing these actions, the monitoring thread records an indelible safety event fault code in non-volatile memory, ensuring traceability even after power loss. The fault record is then encrypted and uploaded to the cloud security platform via the communication module for risk aggregation analysis by the cloud analysis system. If the monitoring thread identifies an anomaly as severe, such as forced control flow tampering or security policy corruption, the system performs a permanent lock operation, disabling firmware flashing until authorized by the manufacturer. Through this process, hardware detection, software instrumentation, benchmark comparison, and anomaly handling form a coherent security chain, achieving closed-loop control from anomaly detection and risk localization to protective response.

[0067] S140 After the anomaly handling is completed, the BMS uploads the logs and attack behavior characteristics corresponding to the security event to the cloud platform. The cloud analyzes and generates detection rules or certificate revocation lists and issues updates, thereby realizing the dynamic evolution and continuous protection closed loop of the monitoring thread and security module.

[0068] In one possible implementation, after anomaly handling is completed, the BMS uploads the logs and attack behavior characteristics corresponding to the security event to the cloud platform. The cloud platform then analyzes the data, generates detection rules or certificate revocation lists, and issues updates, specifically including: The security audit logs and security event records recorded locally are encrypted and uploaded to the cloud platform through the vehicle network. The cloud platform performs large-scale data analysis based on the received multi-vehicle security data to identify potential global threats. When multiple vehicles receive illegal access requests from the same certificate, the certificate is marked as having a risk of leakage and added to the global certificate revocation list. After completing threat identification, the cloud platform generates new detection rules or updates challenge response algorithm parameters based on the analysis results, and sends them to BMS after encryption and signing via over-the-air download channel; During the establishment of the over-the-air download channel, the BMS and the cloud platform sequentially perform four stages: two-way authentication, security key negotiation, secure data transmission, and secure installation and feedback. Two-way authentication verifies the legitimacy of the device certificate and the server certificate. Security key negotiation generates a session key based on asymmetric encryption. Secure data transmission uses the session key to encrypt and update data and verifies data integrity through digital signature. In the secure installation and feedback stage, the vehicle-mounted monitoring thread and security module verify and load update rules and security policies, and encrypt the installation results and send them back to the cloud platform.

[0069] Specifically, after the battery management system completes anomaly handling, the security module initiates a data reporting process. The vehicle-mounted system first encrypts locally stored security audit logs and security event records via the vehicle communication network. The encryption process uses a symmetric encryption key negotiated between the battery management system and the cloud platform to ensure the logs are protected from eavesdropping and tampering during transmission. After encryption, the system uploads the encrypted log data packets to the cloud security platform using a secure communication protocol. Upon receiving security data from multiple vehicles, the cloud platform performs aggregation calculations and anomaly pattern recognition using big data analytics models and threat intelligence algorithms. If the system identifies that multiple vehicles have received unauthorized access requests from the same certificate, the cloud will determine that the certificate is at risk of being leaked and add it to the global certificate revocation list, thereby preventing the leaked certificate from being misused in other devices.

[0070] After completing threat identification, the cloud platform automatically generates new detection rules or adjusts existing challenge-response algorithm parameters based on the analysis results to address newly discovered attack methods. The detection rules include illegal function call addresses, suspicious access behavior patterns, and abnormal communication characteristics. The generated update data undergoes encrypted signing, with the signature generated by the cloud platform using its master private key to ensure the credibility and integrity of the data source. The update package is transmitted to the battery management system via an over-the-air download channel. The entire process relies on two-way authentication and encrypted session mechanisms to prevent the update content from being forged or tampered with.

[0071] During the establishment of the over-the-air download channel, the battery management system and the cloud platform sequentially execute four phases: two-way authentication, secure key negotiation, secure data transmission, and secure installation and feedback. In the two-way authentication phase, the cloud platform first sends its server certificate. The battery management system verifies its authenticity and validity using its built-in trusted root certificate, and simultaneously sends its own device certificate to the cloud. After verification by the cloud, a mutual trust relationship is established. The secure key negotiation phase employs asymmetric encryption, with both parties generating a unique session key for encrypted communication. In the secure data transmission phase, the cloud uses the negotiated session key to encrypt updated data and attaches a digital signature for verification by the battery management system. After receiving the data, the battery management system decrypts it using the session key and verifies the digital signature to ensure the data has not been tampered with and its source is trustworthy.

[0072] During the safety installation and feedback phase, the battery management system's monitoring thread and safety module collaborate to perform integrity verification and signature verification on the downloaded update package. Upon successful verification, new detection rules and safety policies are loaded, and the local safety database is updated. After installation, the battery management system generates update feedback information, including installation status, version number, and a summary of the loading result, which is then encrypted using a negotiated key and uploaded to the cloud. The cloud platform updates the vehicle's safety status profile based on the feedback results and incorporates statistical information into subsequent threat modeling and policy optimization. Through continuous interaction of log uploads, cloud analysis, rule generation, and policy distribution, the battery management system achieves dynamic evolution of safety policies, creating a traceable and verifiable closed-loop update mechanism for the safety protection system between the vehicle and the cloud.

[0073] This embodiment also discloses a management device for preventing BMS firmware from being flashed, see reference. Figure 2 The device includes an acquisition module 201, a processing module 202, and an output module 203. It is used to execute any of the above-described management methods for preventing BMS firmware from being flashed, wherein: The acquisition module 201 is used to generate a unique response and rebuild the device root key when the BMS main control unit is powered on, so as to establish a trusted firmware execution environment and complete firmware digital signature verification.

[0074] The processing module 202 is used to perform digital certificate exchange and two-way verification between the BMS and the diagnostic instrument in the trusted firmware execution environment when the diagnostic instrument issues a firmware flashing request, generate a dynamic session key and execute a challenge-response mechanism to ensure that the firmware flashing operation is only authorized in the trusted communication environment.

[0075] The processing module 202 is used to perform hash verification, control flow monitoring and access auditing based on the dynamic session key and security baseline data during the operation of the BMS application, and to perform real-time hardware handling when an anomaly is detected, while recording security events.

[0076] The output module 203 is used to upload the logs and attack behavior characteristics corresponding to the security event to the cloud platform after the exception handling is completed. The cloud analyzes and generates detection rules or certificate revocation lists and issues updates, thereby realizing the dynamic evolution and continuous protection closed loop between the monitoring thread and the security module.

[0077] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0078] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0079] The communication bus 302 is used to enable communication between these components.

[0080] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0081] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0082] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications. The GPU is responsible for rendering and drawing the content required for display. The modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0083] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. As a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface 303 module, and an application program for a management method to prevent BMS firmware from being flashed.

[0084] exist Figure 3 In the illustrated electronic device, the user interface 303 is primarily used to provide an input interface for the user and to acquire user input data. The processor 301 can be used to call an application stored in the memory 305 that stores a management method for preventing BMS firmware from being flashed. When executed by one or more processors 301, this causes the electronic device to perform one or more methods as described in the above embodiments.

[0085] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to the present invention. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0086] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0087] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0088] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0090] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0091] The present invention also discloses a computer-readable storage medium storing instructions. When executed by one or more processors 301, these instructions cause an electronic device to perform one or more methods as described in the above embodiments.

[0092] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A management method for preventing BMS firmware from being flashed, characterized in that, The method includes: When the BMS main control unit is powered on, a unique response is generated and the device root key is rebuilt to establish a trusted firmware execution environment and complete firmware digital signature verification. When the diagnostic tool issues a firmware flashing request, the BMS and the diagnostic tool exchange and verify digital certificates in the trusted firmware execution environment, generate a dynamic session key and execute a challenge-response mechanism to ensure that the firmware flashing operation is only authorized in the trusted communication environment. During the operation of the BMS application, hash verification, control flow monitoring and access auditing are performed based on the dynamic session key using security benchmark data, and real-time hardware handling is performed when an anomaly is detected, while security events are recorded. After the anomaly is handled, the BMS uploads the logs and attack behavior characteristics corresponding to the security event to the cloud platform. The cloud platform analyzes and generates detection rules or certificate revocation lists and issues updates, thereby realizing the dynamic evolution and continuous protection closed loop of the monitoring thread and security module.

2. The management method for preventing BMS firmware from being flashed according to claim 1, characterized in that, When the diagnostic instrument issues a firmware flashing request, the BMS and the diagnostic instrument exchange and verify digital certificates in the trusted firmware execution environment, generate a dynamic session key, and execute a challenge-response mechanism to ensure that the firmware flashing operation is only authorized in the trusted communication environment. Specifically, this includes: During the security authentication process before firmware flashing in BMS, when the diagnostic tool sends a request to BMS to establish a flashing session, the security module in the BMS application first initiates two-way authentication to establish a trust relationship between the two communicating parties. BMS sends the first device certificate to the diagnostic instrument. The first device certificate is generated by a certificate authority using a private key to sign the public key of the BMS device. At the same time, BMS requests the diagnostic instrument to send the second diagnostic instrument certificate. After receiving each other's certificates, BMS and the diagnostic instrument both use the locally pre-installed public key of the certificate authority to verify the authenticity, signature validity, validity period and revocation status of the other party's certificate. If either certificate fails to be verified, the flashing session is immediately terminated and the security event of an unauthorized device attempting to access the site is recorded. When both certificates are successfully verified, the dynamic session key generation and challenge response phase begins. During the challenge response phase, the BMS generates a random number as a challenge seed and combines the challenge seed with the current session identifier and timestamp to form challenge information. The challenge information is encrypted using the public key in the second diagnostic instrument certificate and sent to the diagnostic instrument. The diagnostic instrument decrypts the challenge information using its private key and calculates the response value according to a preset security algorithm before returning it to the BMS. The BMS calculates the expected response value based on the same dynamic parameters and security algorithm and compares it. When the response values ​​match, the firmware flashing permission is unlocked. When the response values ​​do not match, an authentication failure event is recorded, and the flashing function is temporarily locked when the number of consecutive failures exceeds a threshold.

3. The management method for preventing BMS firmware from being flashed according to claim 1, characterized in that, During the operation of the BMS application, based on the dynamic session key, hash verification, control flow monitoring, and access auditing are performed using security baseline data. Real-time hardware intervention is implemented when an anomaly is detected, and security events are recorded. Specifically, this includes: During the BMS operation phase, a hybrid monitoring strategy is adopted, which mainly uses hardware performance counters and supplements them with software instrumentation. The monitoring granularity is dynamically adjusted according to the system operation status and threat level to achieve a balance between security protection strength and performance overhead. The hardware performance counter automatically counts the number of hardware events such as branch instruction misprediction, illegal memory access, and instruction prefetching errors through the dedicated register built into the BMS main control unit, and is used to continuously perform global monitoring under normal vehicle operation. The software instrumentation inserts monitoring instructions at the entry, exit, and jump points of critical functions during the source code compilation stage to generate memory markers and achieve precise anomaly location. When hardware monitoring detects a potential anomaly, it triggers the system to enter the security diagnostic mode to enable full instrumentation, and instrumentation monitoring is always maintained for the highest security level functional modules. After the BMS application core starts, the monitoring thread starts in a separate core or high-priority task and loads security baseline data from the protected storage area. The security baseline data includes the baseline hash value of the critical code segment, the legal control flow graph and the security policy. The monitoring thread performs periodic and trigger-based monitoring with reference to the security baseline data, performs memory integrity verification by calculating the hash values ​​of code segments and data segments, monitors the control flow by reading hardware performance counters or verifying the order of guard instructions, and performs security behavior auditing on access behavior to security-critical resources. When an anomaly is detected, the monitoring thread immediately forces a reset of the BMS application core, disconnects the main negative contactor via a hardware safety pin, records an indelible security event fault code in non-volatile memory and uploads it to the cloud platform, and permanently locks the firmware flashing function in the event of a serious anomaly.

4. The management method for preventing BMS firmware from being flashed according to claim 1, characterized in that, After the anomaly handling is completed, the BMS uploads the logs and attack behavior characteristics corresponding to the security event to the cloud platform. The cloud platform then analyzes the data, generates detection rules or a certificate revocation list, and issues updates accordingly. Specifically, this includes: The security audit logs and security event records recorded locally are encrypted and uploaded to the cloud platform via the vehicle network. The cloud platform performs large-scale data analysis based on the received multi-vehicle security data to identify potential global threats. When multiple vehicles receive illegal access requests from the same certificate, the certificate is marked as having a risk of leakage and added to the global certificate revocation list. After completing threat identification, the cloud platform generates new detection rules or updates challenge response algorithm parameters based on the analysis results, and sends them to the BMS after encryption and signing via the over-the-air download channel; During the establishment of the over-the-air download channel, the BMS and the cloud platform sequentially perform four stages: two-way authentication, security key negotiation, secure data transmission, and secure installation and feedback. The two-way authentication verifies the legitimacy of the device certificate and the server certificate. The security key negotiation generates a session key based on asymmetric encryption. The secure data transmission uses the session key to encrypt and update data and verifies data integrity through digital signature. In the secure installation and feedback stage, the vehicle-mounted monitoring thread and security module verify and load update rules and security policies, and encrypt the installation results and feed them back to the cloud platform.

5. The management method for preventing BMS firmware from being flashed according to claim 2, characterized in that, The method further includes: After successfully decrypting the challenge information, the challenge seed, session identifier, and timestamp are extracted and concatenated in a fixed order to form the challenge information message body. A one-way hash operation is performed on the challenge information message body to generate a hash digest value. Then, the current session binding key, the challenge seed, and the hash digest value are combined to calculate and generate a derived key. Using the derived key, the message authentication module is invoked to execute a hash-based message authentication code algorithm to generate a response value with the challenge information message body as input, and the response value is signed, encrypted, and returned to the BMS; BMS calculates the expected response value based on the same security algorithm path and input parameters and compares them. When the response value matches the expected response value, the firmware flashing operation is authorized. When they do not match, the security module is triggered to record the authentication failure event and start the flashing lock counting process.

6. The management method for preventing BMS firmware from being flashed according to claim 1, characterized in that, When the BMS main control unit is powered on, a unique response is generated and the device root key is rebuilt to establish a trusted firmware execution environment and complete firmware digital signature verification. Specifically, this includes: During the execution of the bootloader code by the BMS main control unit, the bootloader code activates the physically unclonable function circuit and applies an excitation signal, causing the physically unclonable function circuit to generate a unique response based on the physical structure difference. The unique response is input into the key derivation function to reconstruct the device root key. The device root key includes a device root private key and a device root public key. The device root private key only exists temporarily in the register of the current boot cycle and cannot be read through the external interface. The device root public key is used for subsequent firmware digital signature verification and communication key derivation, thereby enabling the BMS to establish a root of trust during the boot phase and provide an encrypted foundation for subsequent firmware verification and secure communication.

7. The management method for preventing BMS firmware from being flashed according to claim 6, characterized in that, The process of generating a unique response and reconstructing the device root key upon power-up of the BMS main control unit, in order to establish a trusted firmware execution environment and complete firmware digital signature verification, specifically includes: During the startup phase of the BMS main control unit, the bootloader code reads the application firmware and the digital signature appended to the end of the firmware from the external memory. The digital signature is generated by the device manufacturer using the master private key to hash the firmware content before the firmware is released. The bootloader code calls the manufacturer's master public key, which is pre-stored in the chip's one-time programming storage area or inside the bootloader, to decrypt the digital signature to obtain the original hash value. Then, based on the same hash algorithm, the application firmware content is hashed to obtain the real-time hash value. When the original hash value matches the real-time hash value, the program execution control is transferred to the application firmware; When the original hash value is inconsistent with the real-time hash value, the startup process is terminated and the BMS main control unit is placed in a secure locked state. At the same time, the fault indication interface is triggered to output an abnormal notification signal to the relevant components.

8. A management device for preventing BMS firmware from being flashed, characterized in that, The device is used to perform a management method for preventing BMS firmware from being flashed as described in any one of claims 1-7. The device includes an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to generate a unique response and reconstruct the device root key when the BMS main control unit is powered on, so as to establish a trusted firmware execution environment and complete firmware digital signature verification. The processing module is used to perform digital certificate exchange and two-way verification between the BMS and the diagnostic instrument in the trusted firmware execution environment when the diagnostic instrument issues a firmware flashing request, generate a dynamic session key and execute a challenge-response mechanism to ensure that the firmware flashing operation is only authorized in the trusted communication environment. The processing module is used to perform hash verification, control flow monitoring and access auditing based on the dynamic session key and security benchmark data during the operation of the BMS application, and to perform real-time hardware handling when an anomaly is detected, while recording security events. The output module is used to upload the logs and attack behavior characteristics corresponding to the security event to the cloud platform after the exception handling is completed. The cloud platform analyzes and generates detection rules or certificate revocation lists and issues updates, thereby realizing the dynamic evolution and continuous protection closed loop of the monitoring thread and security module.

9. An electronic device, characterized in that, The device includes a processor, a communication bus, a user interface, a network interface, and a memory. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The communication bus is used to enable communication between the components within the electronic device. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

Images