Local Injection Detection
Each legitimate sender can watch for impersonation of its own CAN IDs and can raise an alarm when an unexpected source transmits one of them. The mechanism turns every legitimate sender into a localized intrusion detector and is the lowest, non-cryptographic detective shell in the CAN defense-in-depth model. SR 3.1
How Local Injection Detection Works
The node maintains a list of CAN IDs it "owns" for transmission. Its CAN driver receives all frames on the bus (CAN transceivers see every frame) and checks each one against the owned-ID list. A match without a corresponding self-transmit is flagged as a suspected injection and where possible is forwarded to the Anomaly Event Monitoring for system-level correlation.
What It Detects and What It Misses
It detects: external nodes spoofing the legitimate sender's CAN IDs. It misses: spoofing of CAN IDs owned by another node (the listening node has no a priori knowledge of "who else owns what" beyond its own list); content-only manipulation (legitimate CAN ID, malicious payload, where only the sender knows); fast spoofing followed by quick rollback during a window when the legitimate sender does not happen to transmit.
Driver-Level Throughput Limiting
Pair local injection detection with driver-level transmission rate limiting on the legitimate sender. If a malicious node attempts to flood with the spoofed ID, the legitimate sender's driver can refuse to amplify the issue and the security event is captured cleanly. This is a building block for SL2 against bus-flooding attempts.
IEC 62443 SL2 for Local Node
For inject/replay against a node with local injection detection plus rate limiting, IEC 62443 SL2 is reachable for that node's own messaging. SL3 typically requires Frame Security (cryptographic authentication and confidentiality). SR 3.1 SR 7.x
Integration with Anomaly Event Monitoring
Local injection detection is most useful when its findings
are forwarded to Anomaly Event
Monitoring with an auditable log. Standalone, the
detection lives only in the legitimate sender; integrated, it
becomes part of the system's CRA-relevant
security posture. Although forwarding the information could be
executed via CAN, this might not work if the device detecting
and transmitting the information is already under attack. The
next best solution here is stopping transmission of a secure
heartbeat. The Anomaly Event Monitoring may interpret a lost
secure heartbeat as that device being under attack.
CANcrypt's
(and SPsec's) secure heartbeat implements this concept: sender
liveness with cryptographic protection.
What This Shell Does Not Catch
Local injection detection only detects injection of frames using the listening node's own CAN IDs. It cannot detect spoofing of a different node's IDs, content-only manipulation of legitimate frames, or fast spoof-and-rollback during a window when the legitimate sender is silent. It detects but does not prevent; the injected frame still reached every receiver before the alarm fires. Pair this shell with Anomaly Event Monitoring for cross-node correlation, and with Frame Security for true prevention.
Frequently Asked Questions
Can a CAN node detect when someone else uses its CAN ID?
Yes. A node listening to its own CAN ID can detect frames using that ID that it did not transmit. This is the basis of local injection detection, a non-cryptographic shell at the data-link / network layer. The detection is local and immediate; no central authority is needed.
Does local injection detection prevent or just detect frame injection?
It detects, not prevents. Detected events are surfaced to the security event log and to Anomaly Event Monitoring for correlation. Prevention requires Frame Security (CANcrypt or SPsec).