ISO 21434 Example:Tire Pressure Monitoring System(TPMS)

A TPMS consists of sensors inside the tires that measure pressure and temperature and wirelessly transmit this data to a receiver ECU in the vehicle, which then displays the information to the driver. From a cybersecurity perspective, its wireless communication and safety function make it a critical item to analyze. 

The first step is to define the scope of the "item" we're analyzing—the TPMS.

• Objective: To understand the TPMS's functionality, interfaces, and dependencies to establish the analysis boundary.
• Key Elements Defined:
  
  • Function: To monitor tire pressure/temperature and warn the driver of under-inflation.
  • Components: Tire sensors (with RF transmitter, battery), receiver ECU, dashboard display.
  • Interfaces:
    
    • Wireless: RF communication (e.g., 433 MHz) from sensor to receiver.
    • Wired: CAN or LIN bus communication from the receiver ECU to the cluster/display.
  • Dependencies: Relies on other vehicle systems (gateway, cluster) to relay and display warnings.

Output: A detailed Item Definition document that scopes all elements of the TPMS.

Step 1: Asset Identification
What valuable things need protection?

• TPMS Data: Integrity and authenticity of the pressure/temperature messages.
• TPMS Function: Availability of the warning system.
• Vehicle System Access: The TPMS receiver ECU as a potential entry point to the internal vehicle network (CAN bus).

Step 2: Threat Scenario Identification
Using the assets, we brainstorm attack scenarios. For example:

• "An attacker spoofs malicious TPMS messages to the receiver."
• "An attacker jams RF signals to cause a Denial-of-Service (DoS), disabling the warning function."
• "An attacker reverse engineers the sensor to extract cryptographic keys (if present)."

Step 3: Impact Rating
We evaluate the impact if the attack succeeds. For the spoofing scenario:

• Safety Impact (High): Spoofing a "low pressure" warning could cause the driver to stop unnecessarily on a highway. Spoofing "normal pressure" when a tire is actually flat could lead to a crash.
• Operational Impact (Medium): Erroneous warnings impact driver confidence and lead to unnecessary service visits.

Step 4: Attack Path Analysis
We detail the steps an attacker would take:

1. Acquire a TPMS sensor and receiver.
2. Reverse engineer the RF protocol (message structure, frequency).
3. Identify any lack of message authentication.
4. Use a software-defined radio (SDR) to spoof a message.

Step 5: Attack Feasibility Rating
We rate how easy this is. Given the public knowledge of TPMS protocols and cheap availability of SDR tools, the feasibility is High.

Step 6: Risk Determination
Combining the High Impact (Safety) and High Feasibility results in a Unacceptable Risk.

Step 7: Risk Treatment Decision
The risk must be reduced. We decide to mitigate it by implementing security controls.

Output: A TARA Report documenting all threat scenarios and their risk levels. For the spoofing scenario, the result is: "Unacceptable Risk - Must be mitigated."

The TARA results are translated into actionable specifications.

• Cybersecurity Goal (High-Level): "Prevent spoofed messages from being accepted by the TPMS receiver."
• Cybersecurity Requirement (Technical):
  
  • CR-1: "The TPMS receiver shall verify the authenticity of all messages using a cryptographic Message Authentication Code (MAC)."
  • CR-2: "The cryptographic keys shall be unique per vehicle/sensor pair and securely stored in the sensor and receiver."

Output: A Cybersecurity Specification with verifiable requirements.

Engineering teams design and test to the requirements.

• Implementation:
  
  • The sensor hardware is designed to include a lightweight cryptographic engine.
  • The receiver ECU's software is developed to validate the MAC of each incoming message. Invalid messages are discarded.
  • A secure process is defined for provisioning unique keys during manufacturing.
• Verification:
  
  • Test Case: A test tool spoofs a message without a valid MAC.
  • Expected Result: The receiver ECU ignores the message, and no warning is displayed on the dashboard.
  • Test Case: A test tool sends a valid message with a correct MAC.
  • Expected Result: The receiver ECU processes the message, and the dashboard display updates correctly.

Output: Test reports proving the security controls work as intended.

Security doesn't end at production. ISO 21434 requires ongoing vigilance.

• Monitoring: The security team monitors public vulnerability databases and security research for new attacks against TPMS systems or the cryptographic algorithms used.
• Incident Response: If a vulnerability is found in the cryptographic implementation on the receiver ECU, the defined process is triggered. The fix might be deployed via a software update (OTA or dealer), following a secure update process (as defined in ISO 24089).