MCUs: STM32H723ZG + STM32G474RCTx
Operating Temp: −40 °C to +85 °C

Scope and Philosophy

This Threat Analysis and Risk Assessment (TARA) covers the cybersecurity aspects of an open-source aftermarket electric motorcycle traction inverter and vehicle control unit (VCU). It follows the methodology of ISO/SAE 21434 (Road vehicles - Cybersecurity engineering) but adapts it for the realities of open-source hardware.

The Trust-the-User Model

This project is open source. The end user has full access to source code, schematics, firmware, and build tools. This fundamentally changes the cybersecurity posture compared to a proprietary automotive product:

Table 1: Trust Model: Open Source vs. Proprietary

Design Principle: User Sovereignty Over Anti-User DRM

This project explicitly rejects all anti-user security mechanisms: OTP fuses, write-once flash regions, vendor-signed firmware with unreplaceable keys, encrypted bootloaders that prevent user modification, and any form of DRM that treats the hardware owner as an adversary. These mechanisms are incompatible with the open-source philosophy and provide no meaningful security benefit when the attacker already has physical access and the full source code. If a user wishes to add their own tamper protection (RDP Level 1/2, encrypted external flash, physical tamper switches) for their specific threat model, they are free to do so - the base design imposes no barriers and documents how. The security model is trust the user, protect the bus: the legitimate owner is never the threat; remote CAN bus attacks are.

What We Actually Protect Against

With physical access = game over (acceptable for open source), the meaningful attack surfaces are:

1. CAN bus remote attacks: A malicious or compromised node on the CAN bus (aftermarket accessory, diagnostic tool, charger) should not be able to cause unintended tractive effort, disable safety features, or flash malicious firmware without authorization.
2. Firmware integrity during CAN updates: Bit errors, EMI, or bus faults during a legitimate firmware update should not brick the device or install corrupted safety-critical code.
3. Replay and downgrade: An attacker capturing a valid firmware update should not be able to replay it to install older, potentially vulnerable firmware.
4. Denial of service: CAN bus flooding should not prevent the VCU from receiving critical safety messages (BMS heartbeat, brake input).

What We Explicitly Do Not Claim

Table 2: Out-of-Scope Security Claims

Asset Identification

Table 3: Cybersecurity-Relevant Assets

Attack Surface Map

Table 4: Attack Surfaces and Interfaces

Threat Scenarios

Threat scenarios follow ISO/SAE 21434 threat analysis methodology: identify threat sources, attack vectors, and resulting damage scenarios.

Table 5: Threat Scenarios

Risk Assessment

Risk rating uses ISO/SAE 21434's impact/likelihood framework adapted for the open-source trust model. Impact considers vehicle-level safety consequences. Likelihood considers attack feasibility given the open-source context (physical access already assumed = user).

Table 6: Risk Rating Matrix

Cybersecurity Requirements

These cybersecurity requirements (CSRs) are independent of the HARA's Functional Safety Requirements (FSRs). Where a CSR and FSR overlap (e.g., CAN heartbeat timeout), the CSR references the FSR rather than duplicating it.

Table 7: Cybersecurity Requirements

Why HMAC-SHA256 Over RSA/ECDSA

HMAC-SHA256 is recommended over asymmetric algorithms (RSA, ECDSA, Ed25519) for three reasons: (1) Smaller code size in the bootloader - critical for size-constrained bootloaders; (2) Faster verification - SHA-256 is hardware-accelerated on STM32H7; (3) No PKI complexity - the user generates one key, stores it in their build environment, and signs their own firmware. The threat model does not require protection against key compromise (the user owns the key) so the non-repudiation benefits of asymmetric crypto are irrelevant here.

Test Plan

Nine test cases validate the cybersecurity requirements. CT-01 through CT-06 and CT-09 require a CAN interface and the VCU. CT-07 and CT-08 additionally require SWD/JTAG access to the bootloader flash.

CT-01: Unsigned Firmware Update Rejected

Objective: Verify CSR-01 - Unsigned firmware update via CAN is rejected.

Threat: T-01 (malicious firmware upload)

Setup: VCU with CAN update enabled. Bootloader built with known HMAC key.

Procedure:

1. Enter update mode: key-on, brake applied, speed=0.
2. Send firmware chunks over CAN without HMAC signature.
3. Send commit command.
4. Verify bootloader rejects update. Current firmware remains active.

Pass: Rejected. DTC logged: "signature verification failed." No partial flash write.

CT-02: Signed Firmware Update Accepted

Objective: Verify CSR-01 positive path - Signed update accepted.

Threat: T-01 (legitimate update)

Procedure:

1. Sign firmware with correct HMAC key.
2. Send signed chunks with per-chunk CRC (CSR-02).
3. Send SHA-256 hash of complete image.
4. Verify accepted, flash committed, system boots.
5. Verify POST passes. New version active.

Pass: Full update chain succeeds.

CT-03: Corrupted Chunk Detected

Objective: Verify CSR-02 - Bit flip in CAN chunk aborts update.

Threat: T-02 (firmware corruption)

Procedure:

1. Begin signed firmware update.
2. Flip one bit in a chunk's data payload.
3. Verify chunk CRC detects error. Update aborts.
4. Repeat with corrupted CRC field and corrupted sequence number.

Pass: All corruption detected. Update aborted. Partial image erased.

CT-04: Anti-Rollback Counter

Objective: Verify CSR-03 - Downgrade attack rejected.

Threat: T-03 (replay / downgrade)

Procedure:

1. System running firmware with counter = 5.
2. Attempt flash of older firmware with counter = 4. Verify rejected.
3. Flash newer firmware with counter = 6. Verify accepted. Counter = 6.
4. Attempt reflash with counter = 6. Verify rejected (must be > current).
5. Via debugger, reset counter to 0. Verify older firmware now accepted. (Physical access = user can reset)

Pass: Counter logic correct. User can reset via debugger (documented behavior).

CT-05: Update Preconditions

Objective: Verify CSR-04 - Update only when stationary.

Threat: T-06 (update during motion)

Procedure:

1. All preconditions met. Verify update accepted.
2. Speed > 0. Verify rejected.
3. Brake = off. Verify rejected.
4. During update, release brake. Verify aborts immediately.

Pass: All precondition violations rejected or aborted.

CT-06: CAN Freshness Counter - Replay Detected

Objective: Verify CSR-06 - Stale CAN frames treated as lost.

Threat: T-05 (forged safety frames)

Procedure:

1. Normal operation with freshness counters active.
2. Replay captured BMS heartbeat from 10 s ago. Verify detected as stale.
3. Verify VCU applies safe defaults (treats as heartbeat lost).
4. Verify DTC logged: "stale CAN frame detected."

Pass: Replay detected. Safe defaults applied. No tractive effort from stale frames.

CT-07: Bootloader Mutable (Design Verification)

Objective: Verify CSR-07 - Bootloader can be updated by user.

Threat: T-07 (bootloader replacement - intentional user action)

Procedure:

1. Via SWD/JTAG, read current bootloader flash sector. Verify readable (RDP Level 0).
2. Via SWD/JTAG, write modified bootloader (e.g., change version string). Verify succeeds.
3. Boot system. Verify modified bootloader runs.
4. Restore original bootloader. Verify system returns to original state.

Pass: Bootloader is mutable via SWD. User has full control. Document this as intentional.

CT-08: HMAC Key Rotation

Objective: Verify CSR-01 - user can rotate firmware signing keys.

Threat: T-01 (key compromise recovery)

Procedure:

1. Build bootloader with HMAC key K1. Flash to device.
2. Sign firmware with K1. Verify accepted.
3. Sign firmware with K2 (different key). Verify rejected.
4. Build and flash new bootloader with HMAC key K2 (via SWD).
5. Sign firmware with K2. Verify accepted.
6. Sign firmware with K1. Verify rejected.

Pass: Key rotation works. Old key rejected after rotation. Documented in user manual.

CT-09: CAN DoS / Heartbeat Timeout

Objective: Verify CSR-05 - CAN bus flooding causes heartbeat loss and safe state entry.

Threat: T-04 (CAN bus flooding / DoS)

Procedure:

1. Establish normal operation with valid IO board and BMS heartbeat traffic.
2. Flood CAN2 with high-priority frames at >80 % bus load.
3. Verify IO board heartbeat timeout triggers safe state within 1 s.
4. Repeat on CAN1 with BMS heartbeat and verify safe state within 5 s.
5. Verify normal operation resumes automatically after the bus flood stops and heartbeats return.

Pass: Safe state is entered within the FSR-17 timeout under bus flood, and the system recovers cleanly when flooding stops.

Implementation Guidance

HMAC Key Management

The user manages their own signing key. The project will provide a build script that:

1. Generates a random 256-bit key if none exists (stored in keys/fw_signing_key.bin).
2. Embeds the key into the bootloader binary at build time.
3. Provides a signing tool (sign_firmware.py) that takes a compiled firmware binary and produces a signed update package.

The key is never transmitted over CAN. It never leaves the user's build machine. Key compromise means someone gained access to the user's build environment, at which point they can already build and flash arbitrary firmware (physical access or remote access to build machine).

CAN Update Protocol

Recommended protocol (kept simple for open-source implementability):

Table 8: CAN Update Frame Format

Enabling RDP for Security-Conscious Users

For users who want additional protection, document (but do not mandate) how to enable STM32 Read Protection:

Optional: STM32 RDP Level 1

RDP Level 1 prevents external debuggers from reading flash memory via SWD/JTAG. The bootloader and application remain fully functional. Flash can still be mass-erased (which also erases the key).

To enable: ST-Link Utility → Target → Option Bytes → RDP = Level 1

Warning: RDP Level 2 is irreversible and disables debug permanently. Do not recommend Level 2 in documentation; mention it exists but strongly warn against it for a development-friendly open-source project.

Gap Analysis

Table 9: Cybersecurity Gaps

HARA Cross-Reference

This TARA is a companion document to the HARA. Safety-relevant cybersecurity threats (those that could cause unintended tractive effort or prevent safe state entry) are linked to HARA hazards:

Table 10: TARA-to-HARA Cross-Reference

Note on Separation of Concerns

The HARA addresses random hardware failures and systematic design faults that cause hazardous events. This TARA addresses intentional malicious actions that cause the same hazardous events. The requirements are separate (FSRs vs. CSRs) because they are verified against different fault models (random fault injection vs. adversarial attack simulation), but they share the same safe-state destination: SSO when anything goes wrong.

References

Table 11: Referenced Standards and Documents

Document History

Table 12: Revision History