A universal battery BMU two-way authentication method with dynamic protection and full-scenario adaptability

Abstract

This invention discloses a universal battery BMU two-way authentication method with dynamic protection and full-scenario adaptability, comprising the following steps: two-stage two-way authentication of dynamic key cluster generation and secure writing; intelligent attack-fluctuation identification; and full-scenario authentication triggering. This invention achieves end-to-end security authentication of the battery swapping station-vehicle-battery chain through a dynamic key cluster generation mechanism, a two-stage two-way authentication architecture, an intelligent attack-fluctuation identification module, and a full-scenario authentication triggering mechanism. The dynamic key cluster generates an iterable key set based on multi-dimensional parameters; the two-stage authentication balances security and resource consumption; attack-fluctuation identification avoids false positives; and the full-scenario triggering covers scenarios such as power-on, operation, and vehicle access. The method is more than 10 times more difficult to crack than traditional single encryption, achieving an authentication success rate of 99.5%. It is compatible with existing BMU hardware architectures and can effectively prevent risks such as battery theft and authentication cracking. It is applicable to scenarios such as commercial vehicle battery swapping systems and power battery management.

Description

Technical Field

[0001] This invention belongs to the technical field of battery management system (BMS) for new energy vehicles, and specifically relates to a universal battery BMU bidirectional authentication method with dynamic protection and full-scenario adaptability. Background Technology

[0002] With the increasing popularity of battery swapping in new energy vehicles, the Battery Management Unit (BMU), as the core unit for battery safety management, directly determines the safety of batteries connected to battery swapping stations / vehicles through its certification function. Existing BMU certification technologies suffer from the following key challenges:

[0003] (1) Single fixed key: Most algorithms use a single 8-byte or 16-byte fixed key. Once the key is cracked, all batteries of the same type face security risks and lack dynamic protection capabilities.

[0004] (2) Authentication scenario limitations: It only covers power-on authentication of battery swapping stations, and does not involve continuous protection during operation and dynamic authentication on the vehicle side, which has the vulnerability of "replacing the battery after authentication is passed";

[0005] (3) Misjudgment of attacks and fluctuations: Treating authentication failures caused by network fluctuations and malicious attacks as "count failures" in the same way can easily trigger misjudgments (such as misjudging as offline status under power failure conditions), which affects user experience;

[0006] (4) Resource imbalance: Although some strong authentication algorithms are highly secure, they require a large amount of computing power from the BMU (≥20%), resulting in delays in monitoring core parameters such as battery voltage and temperature.

[0007] Therefore, there is an urgent need for a BMU authentication algorithm that balances security, adaptability to all scenarios, and resource friendliness to address the aforementioned technical pain points. Summary of the Invention

[0008] To address the shortcomings and deficiencies of existing technologies, this invention provides a method for achieving end-to-end security authentication of battery swapping stations, vehicles, and batteries. This method utilizes a dynamic key cluster generation mechanism, a two-stage bidirectional authentication architecture, an attack-fluctuation intelligent identification module, and a full-scenario authentication triggering mechanism. The dynamic key cluster generates an iterable key set based on multi-dimensional parameters; the two-stage authentication balances security and resource consumption; the attack-fluctuation identification avoids misjudgments; and the full-scenario triggering covers scenarios such as power-on, operation, and vehicle access. This method is more than 10 times more difficult to crack than traditional single encryption, achieving a 99.5% authentication success rate. It is compatible with existing BMU hardware architectures and effectively prevents risks such as battery theft and authentication cracking. This universal battery BMU bidirectional authentication method, with dynamic protection and full-scenario adaptability, is suitable for commercial vehicle battery swapping systems, power battery management, and other scenarios.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a universal battery BMU bidirectional authentication method with dynamic protection and full-scenario adaptability, comprising the following steps:

[0010] S1. Dynamic Key Cluster Generation and Secure Writing: Collect the 24-bit national standard number, the battery's unique hardware SN code, the production timestamp, and the master control device ID as seeds. Generate a key cluster of "master key K0 + stage sub-keys K1 / K2 / K3" using SHA-512 and HMAC-SHA256 algorithms. Write the key cluster to the BMU hardware security area through the TLS1.3 encryption channel. K0 is fixed and cannot be rewritten, while K1 / K2 / K3 are protected against read and write.

[0011] S2, two-stage two-way authentication, initial strong authentication and continuous lightweight authentication;

[0012] S3. Attack-Fluctuation Intelligent Identification: Collect authentication request interval Δt, random number repetition rate Rr, and response delay ΔT. If "Δt≤1s∨Rr≥30%∨ΔT≥500ms" is met, it is marked as a suspected attack. If two or more conditions are met, it is determined to be a malicious attack, and the protection strategy is dynamically adjusted.

[0013] S4. Full-scenario authentication trigger: Power-on authentication, in-operation authentication, and post-plug-out authentication are triggered in the battery swapping station scenario; authentication is triggered when the battery is connected, the vehicle starts, or the vehicle speed is ≥30km / h. The vehicle side uses K3 encryption (random number + VIN + SOC) to achieve dynamic verification.

[0014] Preferably, the multi-dimensional seed standardization process in step S1 is as follows: S1 padding with zeros to expand to 16 bytes, S2 retaining the original 16-byte format, S3 converting to an 8-byte binary timestamp, S4 retaining the 8-byte master control ID, concatenating them into 48-byte data, and then using SHA-512 hashing to take the first 16 bytes as the master key K0.

[0015] Preferably, the key cluster writing verification process in step S1 is as follows: After receiving the key cluster, the BMU verifies the legitimacy of K0 using the built-in factory root key. After successful verification, K0 is stored in the hardware encryption area, and K1 / K2 / K3 are stored in the read-write protection area. The SHA-256 hash value of K0 is returned to the host computer. If the comparison is consistent, the writing is successful. If it fails, a maximum of 3 retries are triggered.

[0016] Preferably, the initial strong authentication steps in step S2 are as follows: Upon power-up, the main control unit of the battery swapping station sends a 16-byte random number R1 containing a timestamp. After verifying the main control unit ID, the BMU generates R2 and encrypts (R1+R2+timestamp) with K1 to obtain ciphertext C1. The main control unit decrypts and compares C1 and returns the ciphertext C2 that encrypted R2. If the BMU verifies that C2 matches, the authentication is successful.

[0017] Preferably, the specific steps of continuous lightweight authentication in step S2 are as follows: After initial authentication, the cycle is dynamically adjusted according to the working conditions (5 minutes under normal conditions / 1 minute under high load). The main controller sends an 8-byte random number R3. The BMU encrypts (R3 + current voltage) with K2 to obtain a 6-byte ciphertext C3. If the main controller compares C3 and they match, the verification is successful.

[0018] Preferably, the failure handling rule for continuous lightweight authentication in step S2 is as follows: when continuous authentication fails a total of 3 times, the initial strong authentication is re-executed; if the re-execution fails, the BMU network entry status is updated to "offline delay status", the main positive relay is disconnected and the authentication cycle is extended to twice the original cycle.

[0019] Preferably, the adaptive protection strategy in step S3 includes: extending the authentication period and expanding the random number length to 12 bytes when an attack is suspected; generating a new key cluster based on K0, locking the authentication function for 10 minutes and sending an alarm signal when a malicious attack occurs; allowing 3 additional retries when the network fluctuates, and restoring the normal cycle after a successful retry.

[0020] Preferably, the vehicle-side authentication process in step S4 is as follows: the vehicle VCU sends a 12-byte random number R4 containing the VIN code, the BMU uses K3 to encrypt (R4+VIN+current SOC) using AES-128-CFB, and returns the last 10 bytes of ciphertext C4. If the VCU decrypts and compares the data, the authentication is successful; otherwise, the battery output power is limited to ≤20% of the rated power.

[0021] Preferably, the system also includes a key cluster update step: every 30 days of operation or after a malicious attack / battery repair is detected, the BMU generates a new master key K0' based on K0, the latest timestamp Tnew, and the battery cycle count N, and then generates a new subkey cluster {K1', K2', K3'}. After synchronization with the master control device, the old key cluster immediately becomes invalid.

[0022] Compared with the prior art, the beneficial effects of the present invention are:

[0023] (1) Significantly improved security: Dynamic key clusters eliminate the risk of single-key cracking, and two-stage authentication prevents "post-authentication replacement" attacks, making it more than 10 times more difficult to crack than traditional algorithms;

[0024] (2) Full-scenario adaptation: For the first time, it covers the entire link from battery swapping station to vehicle, solving the limitation of existing algorithms in various scenarios (corresponding to Figure 4 (Multi-scenario triggering)

[0025] (3) Fault tolerance optimization: Intelligent differentiation between attack and fluctuation (corresponding to) Figure 3 (Through improved judgment logic), the false positive rate was reduced to below 0.5%, and the authentication success rate reached 99.5%.

[0026] (4) Resource-friendly: Continuous authentication only consumes ≤5% of BMU computing power (corresponding to Figure 2 The lightweighting process does not affect the monitoring of core parameters such as voltage and temperature.

[0027] (5) Strong compatibility: No need to modify the existing BMU hardware, it can be directly integrated into the battery swapping system and is compatible with multiple models. Attached Figure Description

[0028] Figure 1 This is a flowchart of the dynamic key cluster generation and secure writing process in this invention;

[0029] Figure 2 This is a flowchart of the two-stage bidirectional authentication process in this invention (swapping station scenario);

[0030] Figure 3 This is a flowchart of the attack-fluctuation intelligent identification process in this invention;

[0031] Figure 4 This is a timing diagram for triggering authentication across all scenarios in this invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Example 1: A universal battery BMU bidirectional authentication method with dynamic protection and full-scenario adaptability, comprising the following steps:

[0034] S1, Dynamic Key Cluster Generation and Secure Writing Algorithm (e.g.) Figure 1 (As shown)

[0035] S1.1 Multi-dimensional Seed Acquisition: Acquire four types of tamper-proof parameters as key seeds—24-bit national standard number (S1, such as “3301002025030300000123”), battery hardware SN code (S2, 16 bytes, such as “SN202503030001A001”), production timestamp (S3, millisecond level, such as “20250303143025123”), and master control device ID (S4, 8 bytes, such as “STN202503”).

[0036] S1.2 Key Cluster Generation:

[0037] Master key K0: The standardized seed (S1'→16 bytes, S2→16 bytes, S3→8 bytes, S4→8 bytes) is concatenated into 48 bytes of data, and the first 16 bytes are hashed using SHA-512 as K0 (e.g., "K0=0x1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D").

[0038] Subkeys K1 / K2 / K3: Based on K0, using the HMAC-SHA256 algorithm, and combining "Initial Authentication Identifier T1=0x01", "Continuous Authentication Identifier T2=0x02", and "Vehicle Authentication Identifier T3=0x03" respectively, 8-byte K1, 6-byte K2, and 7-byte K3 are generated (e.g., "K1=0x2C3D4E5F6A7B8C9D", "K2=0x3E4F5A6B7C8D", "K3=0x4F5A6B7C8D9E0F").

[0039] S1.3 Secure Write: The key cluster is transmitted to the BMU via the TLS1.3 encrypted channel. After the BMU verifies the legitimacy of K0 with the factory root key, it stores K0 in the hardware encrypted area (unchangeable). K1 / K2 / K3 are stored in the Flash partition with read and write protection. After writing, the SHA-256 hash value of K0 is returned to the host computer for verification (if the verification fails, it will be retried, up to 3 times).

[0040] S2, Two-stage bidirectional authentication algorithm (for battery swapping station scenarios, such as...) Figure 2 (As shown)

[0041] S2.1 Phase 1: Initial Strong Authentication (Power-On Triggered):

[0042] a. The master controller sends an authentication command, which includes S4 and a 16-byte random number R1 (e.g., "R1=0x0123456789ABCDEF0123456789ABCDEF") and a timestamp Tstamp (e.g., "20250303143025").

[0043] b. After BMU verifies that S4 matches S4 in the key cluster, it generates a 16-byte R2 (e.g., "R2=0xFEDCBA9876543210FEDCBA9876543210"). It then uses K1 to encrypt (R1+R2+Tstamp) using AES-128-CBC, and takes the last 16 bytes as C1 (e.g., "C1=0x11223344556677889900AABBCCDDEEFF").

[0044] c. The BMU sends {R2,C1} to the master controller. The master controller performs the same encryption using the pre-stored K1. After comparing C1 and finding that it matches, it encrypts R2 with K1 to obtain C2 (e.g., "C2=0x223344556677889900AABBCCDDEEFF11") and sends C2 to the BMU.

[0045] d. BMU decrypts C2 to obtain R2'. If R2'=R2, the authentication is successful, the network access status is updated to "1 (authenticated)", and the main positive relay is closed; otherwise, one failure is recorded (three failures will lock the connection).

[0046] Phase 2 of S2.2: Continuous Lightweight Authentication (Triggered During Run):

[0047] a. Adaptive cycle: 5 minutes when voltage / temperature is stable, 1 minute when current > 80% of rated current;

[0048] b. The master controller sends 8 bytes of R3 (e.g., "R3=0x0A0B0C0D0E0F1A1B");

[0049] c. The BMU uses K2 to perform AES-128-ECB encryption on (R3 + current voltage Vb, such as "Vb=3.3V→0x0330"), and takes the last 6 bytes as C3 (such as "C3=0x334455667788").

[0050] d. If the main controller matches C3, the verification passes; if they do not match, one failure is recorded. Three failures in total trigger the initial strong authentication to be re-executed.

[0051] S3, Attack-Volatility Intelligent Recognition Algorithm (such as...) Figure 3 (As shown)

[0052] S3.1 Feature Acquisition: Real-time acquisition of 3 types of parameters—authentication request interval Δt (time difference between two consecutive requests), random number repetition rate Rr (the repetition ratio of the current random number to the last 10 historical random numbers), and response delay ΔT (the time from when the BMU receives the request to when it returns a response).

[0053] S3.2 Judgment Rule:

[0054] a. Suspected attack: Meets any of the following conditions (Δt≤1s / high frequency request, Rr≥30% / repeated random number, ΔT≥500ms / abnormal delay);

[0055] b. Malicious attack: Meeting two or more of the above conditions (e.g., Δt=0.5s and Rr=40%).

[0056] c. Network fluctuations: Δt is randomly distributed, Rr=0, ΔT=100-500ms (e.g., ΔT=300ms±50ms);

[0057] S3.3 Protection Strategy:

[0058] a. Suspected attack: The authentication period is extended to twice the original period, and the random number R3 is expanded from 8 bytes to 12 bytes;

[0059] b. Malicious attack: Generate a new key cluster (K0'→K1' / K2' / K3') based on K0, lock the BMU authentication function for 10 minutes, and send an alarm signal (including attack type identifier) ​​to the main control of the swapping station.

[0060] c. Network fluctuations: Allow 3 additional authentication retries. If the retries are successful, the original authentication cycle will be restored. If the retries fail, they will be treated as suspected attacks.

[0061] S4: Full-scenario authentication triggering mechanism (such as...) Figure 4 (As shown)

[0062] S4.1 Battery Swap Station Scenario Triggering Logic:

[0063] a. Power-on start: Trigger module 2's "initial strong authentication"; the main positive relay can only be closed after the authentication is successful.

[0064] b. During operation: Dynamically triggered according to the "Continuous Lightweight Authentication" cycle of Module 2, covering the entire process of normal battery power supply;

[0065] c. After battery insertion or removal: Re-trigger "Initial Strong Authentication" to prevent unauthorized access of unauthenticated batteries;

[0066] d. Suspected attack: Trigger the re-execution of "Initial Strong Authentication" and execute the protection strategy of Module 3 at the same time;

[0067] S4.2 Vehicle Scenario Trigger Logic:

[0068] a. After the battery is connected: The vehicle VCU sends an authentication request, triggering vehicle-side authentication in module 1 K3;

[0069] b. When the vehicle starts: After the VCU detects the ignition signal, it triggers the K3 authentication a second time to prevent battery replacement after starting;

[0070] c. Vehicle speed ≥ 30km / h: Triggers lightweight K3 certification (cycle 2 minutes), adapting to safety protection while driving;

[0071] d. When the vehicle is charging: K3 authentication is triggered after the charging gun is inserted to prevent battery tampering during the charging process;

[0072] S4.3 Vehicle-side Authentication Example: The VCU sends R4=0x123456789ABC (12 bytes) + VIN="LZWADAGA254000123". The BMU encrypts it with K3 (R4+VIN+SOC=50%→0x0050) to obtain C4=0x44556677889900AABBCC (10 bytes). If C4 matches, the authentication is successful. If they do not match, the battery output power is limited to ≤20% of the rated power and an "Authentication error" message is displayed.

[0073] Example 2: Application of a universal battery BMU two-way authentication method with dynamic protection and full-scenario adaptability. The implementation environment is as follows:

[0074] Hardware: BMU (model LP-HDBMU010-AA, including hardware encryption area and Flash read / write protection area), battery swapping station main control (model A700, supporting TLS1.3 communication), vehicle VCU (model HV3E, with VIN code storage and power limiting functions).

[0075] Software: Encryption algorithm library (supports AES-128-CBC / ECB / CFB, SHA-256 / SHA-512, HMAC-SHA256), real-time operating system (RT-Thread, ensuring authentication step response latency ≤10ms).

[0076] The implementation steps are as follows:

[0077] Step 1: Key cluster generation and writing (corresponding to) Figure 1 step)

[0078] a. Seed parameters: S1="XXXXXXXXXXXXXXXXXXXXXX", S2="SNXXXXXXXXXXXXA001", S3="20250303143025123", S4="STN202503";

[0079] b. Standardized seed: S1'="330100202503030000012300000000" (16 bytes), S2="SN202503030001A001" (16 bytes), S3="0x5E5E8F2D00000000" (8 bytes, timestamp converted to binary), S4="0x53544E3230323530" (8 bytes, ASCII code conversion);

[0080] c. Key cluster generation: K0=SHA-512(S1'+S2+S3+S4) first 16 bytes = "0x1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D", K1=HMAC-SHA256(K0,T1) first 8 bytes = "0x2C3D4E5F6A7B8C9D", K2=HMAC-SHA256(K0,T2) first 6 bytes = "0x3E4F5A6B7C8D", K3=HMAC-SHA256(K0,T3) first 7 bytes = "0x4F5A6B7C8D9E0F";

[0081] d. Secure Write: The host computer sends the key cluster to the BMU via TLS 1.3. The BMU verifies the legitimacy of K0 using the factory root key (0x00112233445566778899AABBCCDDEEFF), stores it, and returns the SHA-256 of K0 as "0x7A8B9C0D1E2F3A4B5C6D7E8F9A0B1C2D". If the host computer's comparison matches, the write is successful.

[0082] Step 2: Initial Strong Authentication of the Battery Swap Station (corresponding to) Figure 2 Phase 1)

[0083] a. Master control sends: S4="STN202503", R1="0x0123456789ABCDEF0123456789ABCDEF", Tstamp="20250303143025";

[0084] b. BMU response: Generate R2="0xFEDCBA9876543210FEDCBA9876543210", encrypt it with K1 (R1+R2+Tstamp) → after AES-128-CBC encryption, take the last 16 bytes C1="0x11223344556677889900AABBCCDDEEFF", and send {R2,C1};

[0085] c. Master control verification: Encrypt (R1+R2+Tstamp) with K1 to get C1'=C1. After verification, encrypt R2 with K1 to get C2="0x223344556677889900AABBCCDDEEFF11", and send C2.

[0086] d.BMU verification: Decrypt C2 to obtain R2'=R2, authentication successful, update network access status=1, close the main positive relay.

[0087] Step 3: Attack-Volatility Identification and Processing (corresponding to...) Figure 3 logic)

[0088] a. Simulated scenario: Due to network congestion, the battery swapping station experiences ΔT=600ms (>500ms), Rr=0, and Δt=3s (random distribution);

[0089] b. Feature acquisition: BMU acquired ΔT=600ms, Rr=0%, Δt=3s;

[0090] c. Judgment result: If only "ΔT≥500ms" is met, it is judged as "suspected attack";

[0091] d. Protection execution: The authentication cycle is extended from 5 minutes to 10 minutes, and R3 is extended from 8 bytes to 12 bytes. During the next authentication, the master controller sends 12 bytes R3="0x0A0B0C0D0E0F1A1B2C2D2E2F". The BMU encrypts it with K2 and returns 6 bytes C3. After the verification is successful, the normal cycle is restored.

[0092] The results are verified as follows:

[0093] Security verification: Through brute-force attack tests, the cracking time of a single subkey is extended from 2 hours for existing algorithms to more than 20 hours for this algorithm;

[0094] Fault tolerance verification: Simulating network fluctuations (ΔT=300ms±50ms), the authentication success rate reached 99.8%, with no false positives for being offline;

[0095] Resource usage verification: During continuous authentication, the BMU computing power utilization rate is stable at 3%-5%, and the voltage monitoring delay is ≤10ms, which meets the requirements of GB / T38031-2025 standard.

[0096] This invention is particularly applicable to scenarios such as universal battery swapping platforms for medium and light vehicles, safe access of power batteries for passenger vehicles, and energy storage battery certification, aiming to improve the safety, all-scenario adaptability, and fault tolerance of battery certification.

[0097] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A universal battery BMU bidirectional authentication method with dynamic protection and full-scenario adaptability, characterized in that: Includes the following steps: S1. Dynamic Key Cluster Generation and Secure Writing: Collect the 24-bit national standard number, the battery's unique hardware SN code, the production timestamp, and the master control device ID as seeds. Generate the master key K0 using the SHA-512 algorithm. Based on the master key K0, generate the stage sub-keys K1 / K2 / K3 by combining "initial authentication identifier T1=0x01", "continuous authentication identifier T2=0x02", and "vehicle authentication identifier T3=0x03" using the HMAC-SHA256 algorithm. Write these sub-keys to the BMU hardware security area via the TLS1.3 encryption channel. K0 is fixed and cannot be rewritten, while K1 / K2 / K3 are protected against read and write. S2, two-stage two-way authentication, initial strong authentication and continuous lightweight authentication; S3. Attack-Fluctuation Intelligent Identification: Collect authentication request interval Δt, random number repetition rate Rr, and response delay ΔT. If "Δt≤1s∨Rr≥30%∨ΔT≥500ms" is met, it is marked as a suspected attack. If two or more conditions are met, it is determined to be a malicious attack, and the protection strategy is dynamically adjusted. S4. Full-scenario authentication triggering: Power-on authentication, in-operation authentication, and post-plug-out authentication are triggered in the battery swapping station scenario. Authentication is triggered when the vehicle scenario includes battery access, vehicle startup, or vehicle speed ≥ 30km / h. The vehicle side uses K3 encryption to achieve dynamic verification. The specific steps of the initial strong authentication in step S2 are as follows: When powered on, the main control of the battery swapping station sends a 16-byte random number R1 containing a timestamp. After the BMU verifies the main control ID, it generates R2 and encrypts it with K1 to obtain ciphertext C1. The main control performs the same encryption with the pre-stored K1. After comparing C1, it encrypts R2 with K1 to obtain C2 and sends C2 to the BMU. If the BMU verifies that C2 is consistent, the authentication is successful. The specific steps of continuous lightweight authentication in step S2 are as follows: After initial authentication, the cycle is dynamically adjusted according to the working conditions. The main controller sends an 8-byte random number R3, which is encrypted by the BMU using K2 to obtain a 6-byte ciphertext C3. If the main controller compares C3 and they match, the verification is successful.

2. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability as described in claim 1, characterized in that, The multi-dimensional seed standardization process in step S1 is as follows: S1 pads with zeros to expand to 16 bytes, S2 retains the original 16-byte format, S3 converts to an 8-byte binary timestamp, S4 retains the 8-byte master control ID, and after concatenating into 48-byte data, the first 16 bytes are obtained by SHA-512 hashing as the master key K0.

3. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability according to claim 1, characterized in that, The key cluster writing verification process in step S1 is as follows: After receiving the key cluster, the BMU verifies the legitimacy of K0 using the built-in factory root key. If the verification is successful, K0 is stored in the hardware encryption area, and K1 / K2 / K3 are stored in the read-write protection area. The SHA-256 hash value of K0 is returned to the host computer. If the comparison is consistent, the writing is successful. If it fails, a maximum of 3 retries are triggered.

4. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability as described in claim 1, characterized in that, The failure handling rules for continuous lightweight authentication in step S2 are as follows: when continuous authentication fails a total of 3 times, the initial strong authentication is re-executed; if the re-execution fails, the BMU network entry status is updated to "offline delay status", the main positive relay is disconnected and the authentication cycle is extended to twice the original cycle.

5. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability according to claim 1, characterized in that, The adaptive protection strategy in step S3 includes: extending the authentication period and expanding the random number length to 12 bytes when an attack is suspected; generating a new key cluster based on K0, locking the authentication function for 10 minutes and sending an alarm signal when a malicious attack occurs; allowing 3 additional retries when the network fluctuates, and restoring the normal cycle after a successful retry.

6. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability according to claim 1, characterized in that, The vehicle authentication process in step S4 is as follows: The vehicle VCU sends a 12-byte random number R4 containing the VIN code. The BMU uses K3 to encrypt the R4 with AES-128-CFB and returns the last 10 bytes of ciphertext C4. If the VCU decrypts and compares the data, the authentication is successful. If they do not match, the battery output power is limited to ≤20% of the rated power.

7. The universal battery BMU bidirectional authentication method with dynamic protection and all-scenario adaptability according to claim 1, characterized in that, It also includes a key cluster update step: every 30 days of operation or after a malicious attack / battery repair is detected, the BMU generates a new master key K0' based on K0, the latest timestamp Tnew, and the number of battery cycles N, and then generates a new sub-key cluster {K1',K2',K3'}. After being synchronized to the master control device, the old key cluster immediately becomes invalid.

Images