• Network segmentation in automotive architectures

    Source: https://storage.googleapis.com

    The concept of network segmentation in automotive architectures is well-established, traditionally using gateways to separate functional domains such as powertrain, telematics, and comfort. However, in an era of Software Defined Vehicles and hyper-connectivity, partial implementation is no longer sufficient. Segmentation must evolve from a architectural preference into a rigorous, industry-wide standard, from the OEM down through the entire Tier-N supply chain.

    Enforcing standards down the supply Chain

    The most critical security gaps often originate not within the OEM’s high-level design, but at the supplier level. A Tier-1 component that unintentionally bridges two segments—for example, a connectivity module with undocumented access to a safety-critical bus—can undermine the entire vehicle’s security posture. This „lateral movement” is exactly what attackers exploit to move from a non-critical breach (like Infotainment) to a safety-critical system.

    Zero Trust at the hardware level

    Segmentation must be treated as a compliance standard. To move forward, OEMs must demand:

    • Verified Isolation: Formal proof of isolation capabilities from every Tier-1 and Tier-2 supplier.
    • Zero Trust Integration: Ensuring that „Zero Trust” principles—where no communication is trusted by default—are embedded into both hardware and software long before components reach the assembly line.
    • Architectural Rigor: Moving beyond simple physical separation to include logical isolation (VLANs) and strict firewall rules within the vehicle’s backbone.

    We can no longer rely on „security by obscurity” or the assumption that sub-components are intrinsicaly isolated. Resilience requires a top-down approach that leaves no room for unintentional bridging.


  • Instrument cluster hijacking via CAN bus

    1–2 minut
    Source: https://recyclebmws.com/products/bmw-e90-e92-3-series-instrument-cluster-62109166858.html

    In 2017 researchers from the University of Malta — Robert Buttigieg, Mario Farrugia, and Clyde Meli — analyzed the security level and resilience of the CAN protocol using a BMW E90 instrument cluster as a testbed.

    The research demonstrated a practical attack using a malicious device built from low-cost, commercially available components, emphasizing the high risk posed by cheap hardware exploits.

    The Experiment Setup

    1. Test Model: a BMW E90 instrument cluster was used as the primary target.
    2. Simulation Environment: the remainder of the vehicle’s network was simulated using a specialized tool. Both the simulator and the malicious device resided on a single Arduino Mega 2560 microcontroller.
    3. Attack Vector: a prototype external device was physically connected to the CAN bus. The system utilized a remote connection architecture, where a wireless module provided a communication channel for an operator to send commands to the physically connected malicious device.

    Attack Scenarios & Findings

    The external device functioned as a Man-in-the-Middle to intercept and modify CAN frames, proving two key attack vectors:

    1. Data Spoofing (False Order)The MITM device successfully modified the data field in incoming CAN frames. As a result, the instrument cluster received fabricated values (e.g., speed, engine RPMs) and displayed them to the driver, successfully executing a visual spoofing attack.
    2. Denial of Service (Timeout) In a second scenario, the device blocked or dropped expected critical messages (e.g., from ABS or airbag modules). This caused the receiving systems to experience Timeouts and transition into a failure mode, effectively triggering a software-level Denial of Service.

    The researchers concluded that the instrument cluster itself lacked built-in mechanisms for verifying the authenticity of the data it received. The failure relies on the CAN protocol’s legacy assumption of internal trust, highlighting a critical vulnerability in ECU endpoints that prioritize speed over cryptographic verification.


  • CAN Bus – a legacy protocol in a connected world

    The CAN protocol was designed for efficiency and reliability in closed, automobile systems, certainly not for security in connected environments. In its classic form, it lacks encryption and authentication. If a malicious actor gains access to the bus (e.g., via a connected ECU), they are implicitly trusted in the network by default.

    Modern security applications (like AUTOSAR SecOC or Secure Gateways) introduce additional defense layers. However, these are not a universal fix that fits perfectly for the car environment. All security implementations add latency and complexity that such legacy architectures cannot handle efficiently.

    The most critical gap pertains to logic, not syntax. An ECU, here understood as a node in a bus, validates a frame’s structure (ID, checksum) perfectly but fails to validate the operational context. So, if the architecture focuses only on the transport layer and ignores contextual validation, the vulnerability remains. This can mean, for example, that the information on your dashboard or IVI screen will be false or suggesting safety issues, while in reality, everything is fine.