BMS-18 — Cybersecurity

1. Why Functional Safety Isn’t Enough

Functional safety, as covered in BMS-17, protects against random hardware faults and systematic software bugs. But a malicious, deliberate intrusion — like sending a fake “charge authorized” message over CAN — isn’t a fault at all; it’s abusing the system doing exactly what it was designed to do. That calls for a completely different threat model, and a different discipline: cybersecurity.

A BMS is connected to the vehicle network and manages HV energy; unauthorized access or manipulation can lead to risks like incorrect contactor control, an incorrect charge limit, or safety functions being disabled.

2. What Do the Threats Look Like?

CAN manipulation (sending fake/corrupted messages), unauthorized diagnostics (UDS access), and firmware integrity violations (tampering with firmware) — the three main threat categories.

ASSUMPTION — The scenario below exists only to illustrate the concept; it doesn’t target a specific attack technique, vehicle, or system, and it isn’t guidance for amateur/unauthorized security testing.

A conceptual example: if someone with CAN bus access impersonates the real BMS and sends a fake “SOP = high” message, the VCU could request power that’s unsafe for the battery based on that false information. This shows exactly why message authentication is necessary.

3. Four Layers of Defense

Measure	When it’s active	What it does
Secure boot	Boot-up	Guarantees the running software hasn’t been tampered with
Secure flashing	Update	Only allows authorized/signed software to be installed
Authentication	Runtime	Confirms an incoming message really came from the source it claims
Access control	Authorization	Restricts even an authenticated user to only the operations they’re authorized for

Together, these four form a chain of defense covering different stages of the lifecycle.

4. ISO/SAE 21434 and TARA

ISO/SAE 21434 is the standard for automotive cybersecurity engineering; TARA (Threat Analysis and Risk Assessment) is its core. TARA is conceptually similar to HARA (BMS-17) — both are systematic risk assessments — but where HARA evaluates random/systematic faults, TARA evaluates deliberate attack scenarios (threat actor, attack surface, feasibility).

5. When a Breach Is Detected

When a firmware update fails signature verification, or an invalid diagnostic session is detected, the system should reject the update/access and log the event. The logic resembles the DTC logging on the functional-safety side (BMS-13) — except here the source isn’t a hardware/software fault, it’s a security event.

6. How It’s Verified in Production

Cybersecurity measures are verified before production through penetration-test-style assessments (by authorized security teams, in a controlled environment); secure boot and secure flashing are tested to confirm they actually reject fake/unsigned software. This kind of testing only happens through authorized, professional processes — this lesson does not encourage amateur or unauthorized security testing.

7. How It Connects to Other Systems

Cybersecurity directly protects CAN communication (BMS-15) and the software-update process (BMS-16, BMS-20); it’s tightly linked to functional safety (BMS-17), since a breach can disable safety mechanisms and thereby put functional safety at risk as well.

Summary

• Because the BMS is networked, cybersecurity is mandatory — a different threat model from functional safety (deliberate vs. random).
• Secure boot/flashing, authentication, and access control cover different stages of the lifecycle.
• TARA is cybersecurity’s counterpart to HARA; the two work together as complements.

Sources

• ISO/SAE 21434 — cybersecurity engineering.