PaperlayerView exact revision on arXiv

Source-linked AI summary

Janus Vehicles: Entity-Centric Threat Modelling of Protocol-Conformant Vehicles under a Malicious-Manufacturer Assumption

Jaeung Franciskus Yoo, Huy Kang Kim

arXiv:2610.37059v1cs.CR

TL;DR

Automotive security often assumes benign design, leaving hidden purpose-violating functionality in authentic, protocol-conformant vehicles outside existing threat characterisations. The paper proposes an Entity-Centric Threat Model with archetypes, a behaviour–locus matrix, and an interaction model. It concludes that authenticity and protocol conformance alone do not establish trustworthy operational purpose, while the model remains conceptual rather than an investigation method.

  • Problem

    The paper addresses how to characterise hidden, purpose-violating functionality in cyber-physical entities that remain conformant at legitimate protocol interfaces.

    Source: §I · p. 2, A. Current Practice in Automotive… · p. 3

  • Method

    The Entity-Centric Threat Model combines malign entity archetypes, a matrix of actions across hardware, software, and network loci, and an interaction model linking capabilities, triggers, actions, and evidence.

    Source: §I · p. 2, D. Conclusion · p. 9

  • Results

    The model characterises how functionality may be contextually activated and concealed, showing that authenticity, component genuineness, and protocol conformance alone do not establish trustworthy operational purpose.

    Source: D. Conclusion · pp. 9–10

  • Takeaways & Limitations

    Automotive assurance must account for the possibility that the design authority itself lies within the threat boundary.

    Source: D. Conclusion · p. 10

    The paper presents a conceptual threat model, not an operational investigation or detection method, and it cannot by itself establish manufacturer intent or the prevalence of such functionality.

    Source: B. Limitations · p. 9

Abstract

from arXiv · show

Automotive cybersecurity commonly assumes benign end-product manufacturers and design authorities, focusing on supply-chain threats, external attacks, and compromised network participants observable through misbehaviour. This assumption overlooks malicious-by-design vehicles that remain authentic and protocol-conformant while performing undeclared sensing, communication, or context-triggered actuation. We formulate an Entity-Centric Threat Model spanning three subcomponents. The first, Malign Entity Archetypes, describes four types of malign entity: peer-benign, purpose-malicious vehicles; compromised vehicles; reappropriated genuine components; and imitated vehicles or components. The model exposes two assurance gaps: authenticity does not establish declared-purpose conformance, while malicious functionality can evade detection based on behavioural history or peer-visible evidence. Reappropriated components can remain genuine and retain usable identities or capabilities outside authorised contexts, reducing the effectiveness of signal fingerprinting and certificate-based authentication. To structure this threat space, we introduce a Behaviour-Locus Matrix that maps covert, overt, and concealment actions across hardware, software, and network loci. For peer-benign, purpose-malicious vehicles, we further present a Behavioural Interaction Model that represents how hidden capabilities are contextually activated, realised through actions, manifested within the vehicle and its environment, and potentially observed or concealed.

I. INTRODUCTION

Automotive security commonly assumes vehicles were benignly designed, leaving purpose-violating functionality in authentic, protocol-conformant vehicles underexamined. The paper frames this threat and proposes three complementary components for characterising it.

I. INTRODUCTION

  • 22. Malicious-by-design vehicles may authenticate correctly and remain indistinguishable from benign peers while conducting undeclared sensing, communication, or actuation.Purpose violations may use physical sensing or actuation, undisclosed channels, or otherwise legitimate connected-car functionality.Source: §I · pp. 1–2
  • Protocol conformance is necessary for interoperability but does not establish that a vehicle’s operation is trustworthy or purpose-conformant.Dormant functionality may evade dynamic testing, and investigation-aware systems may conceal or overwrite evidence.Source: §I · p. 2
  • The paper asks how investigators can characterise and seek evidence of hidden, purpose-violating functionality in entities that remain conformant at legitimate protocol interfaces.The proposed work addresses the conceptual prerequisite for investigation, not an investigation procedure; evidence acquisition and empirical validation remain out of scope.Source: §I · p. 2
  • The paper formulates Malign Entity Archetypes covering malicious-by-design vehicles, conventionally compromised vehicles, reappropriated genuine components, and imitated vehicles or components.These categories distinguish purpose-malicious entities from compromise, component reappropriation, and imitation.Source: §I · p. 2
  • The Behaviour–Locus Matrix maps covert, overt, and concealment actions across hardware, software, and network loci.It provides a systematic way to map how malign functionality manifests and what peers or investigators may observe.Source: §I · p. 2
  • The Behavioural Interaction Model relates capabilities and contextual triggers to realised actions, operational loci, artefacts, investigation, concealment, and declared purpose.It is presented for peer-benign, purpose-malicious vehicles and complements the matrix.Source: §I · p. 2

II. BACKGROUND

Existing automotive security and governance address risk management, supply chains, observable participant behaviour, and regulatory obligations. The reviewed approaches do not explicitly establish assurance when the design authority itself may be adversarial.

A. Current Practice in Automotive Security

  • Automotive risk-management methods identify assets, damage scenarios, threats, attack paths, impacts, and feasibility, but primarily support prospective lifecycle assessment rather than behavioural investigation of deployed entities.They principally treat the vehicle as a system to protect from adversaries, not as a system that may threaten the public.Source: A. Current Practice in Automotive… · p. 2
  • Supply-chain frameworks recognise malicious functionality in acquired products, yet generally position the acquiring organisation as well-intentioned and do not directly address an adversarial manufacturer or design authority.This leaves the operational purpose of a finished entity as a downstream assurance question for users, regulators, and other participants.Source: A. Current Practice in Automotive… · p. 2
  • Behaviour-based detectors seek observable indicators such as implausible messages, identity inconsistencies, protocol violations, or deviations from expected behaviour, but clandestine actions may produce none of their assumed evidence.Examples include promiscuous sensing, out-of-band exfiltration, and dormant local actuation; such systems are also reactive and may fail to prevent a one-time attack.Source: A. Current Practice in Automotive… · p. 3
  • Automotive governance spans cybersecurity engineering, vehicle and software-update management, and broader lifecycle obligations, but does not explicitly require assurance that all functionality is declared and serves an authorised purpose.Figure 1 depicts the gap: existing governance and research do not explicitly establish what must be assured when the design authority may be adversarial.Source: A. Current Practice in Automotive… · p. 3, Figure 1 · p. 3

B. Behaviour-Centric Malware Characterisation

Malware analysis offers a behaviour-centric precedent for investigating malicious-by-design entities, but vehicle complexity requires adapting that approach to distributed cyber-physical behaviour and context.

  • Malware analysis treats artefacts as potentially adversarial and seeks concealed capabilities and behaviours, offering a conceptual precedent for malicious-by-design cyber-physical entities.Source: B. Behaviour-Centric Malware… · p. 3
  • Signature-based detection relies on known patterns, but representative vehicle samples may be unavailable and vehicle behaviours can span vendor-specific components and contexts.Exact pattern matching alone is therefore unlikely to provide sufficient investigative coverage; behaviour-centric analysis is more transferable.Source: B. Behaviour-Centric Malware… · pp. 3–4
  • MBC and MAEC organise malware objectives, capabilities, behaviours, actions, affected objects, observables, and relationships beyond known-signature matching.They shift investigation toward what an artefact can do and what evidence supports that assessment.Source: B. Behaviour-Centric Malware… · p. 4
  • Vehicle behaviour depends on distributed cyber-physical interactions, so software restoration may not reproduce vehicle state or prevent investigation-aware concealment.Adapting malware analysis requires contextual stimulation, observation across cyber-physical loci, and evidence independent of potentially adversarial internal mechanisms.Source: B. Behaviour-Centric Malware… · p. 4

III. ENTITY-CENTRIC THREAT MODEL

The Entity-Centric Threat Model includes Malign Entity Archetypes, which distinguish adversaries by the origin of malicious functionality, entity authenticity, and adversarial control. The four configurations expose different assumptions behind existing legitimacy checks.

A. Malign Entity Archetypes

  • Type I vehicles are genuine products whose manufacturers or design authorities intentionally incorporate hidden malicious functionality, potentially coordinated across components and operational layers.Manufacturer control can also support monitoring and concealment mechanisms that recognise investigative conditions and hide functionality.Source: A. Malign Entity Archetypes · p. 4
  • Types II–IV differ by whether adversaries control a compromised vehicle, reappropriate a genuine component, or imitate a vehicle or component.Type II begins as a benign product later compromised; Type III can retain valid identity material outside its assigned system, while Type IV attempts to imitate identity or behaviour.Source: A. Malign Entity Archetypes · pp. 4–5
  • A Tesla Model X attack used a modified genuine Body Control Module outside the affected vehicle, illustrating why component authenticity alone does not establish authorised use.The authors state that detecting this configuration requires checking component-to-system binding, operational context, or behaviour in addition to authenticity.Source: A. Malign Entity Archetypes · pp. 4–5
  • The four illustrative configurations are malicious-by-design vehicles, benign vehicles under conventional attack, reappropriated genuine components, and imitated vehicles or components.They are organised by entity level and how far each configuration is addressed in existing automotive security research.Source: A. Malign Entity Archetypes · p. 4, Figure 2 · p. 5
  • Unlike Types II–IV, Type I removes the assumption that an independent manufacturer, component, credential, or reference behaviour can establish legitimacy.Authenticity checks may verify approved hardware and software while behavioural monitoring sees no cooperative-interface violation, leaving no evidence until hidden functionality activates.Source: A. Malign Entity Archetypes · p. 5

B. Behaviour–Locus Matrix

The Behaviour–Locus Matrix provides a coverage scaffold for examining where malign actions may be implemented or manifested and what role they perform.

B. Behaviour–Locus Matrix

  • The matrix structures investigation across operational loci and behavioural roles because malicious functionality may be distributed across cooperating vehicle elements that appear benign in isolation.It is intended to guide systematic coverage rather than ad-hoc inspection of a single apparently relevant component or interface.Source: B. Behaviour–Locus Matrix · p. 5
  • Operational locus distinguishes hardware, software, and network, while behavioural role distinguishes covert, overt, and concealment actions.Together, the two dimensions form a three-by-three classification framework.Source: B. Behaviour–Locus Matrix · p. 5

1) Operational Locus:

Operational locus identifies where an action is implemented or observed in a vehicle’s distributed cyber-physical system. The matrix distinguishes hardware, software, and network loci, which can overlap in one capability.

2) Operational Locus:

  • Hardware locus covers computational and physical vehicle elements, including ECUs, sensors, actuators, storage, communication modules, and mechanical assemblies.A design authority may add resources such as extra flash storage, an undocumented communication module, or an undeclared connectivity profile; these matter when they support hidden functionality.Source: 1) Operational Locus · pp. 5–6
  • Software locus includes bootloaders, firmware, operating systems, applications, services, learned models, configuration data, stored data, and runtime state.Hidden behaviour may be distributed across software layers and emerge only when combined with particular data, messages, vehicle states, or actions by other components.Source: 1) Operational Locus · p. 6
  • Network locus covers communication within the vehicle and between the vehicle and external entities, including cellular, Wi-Fi, Bluetooth, V2X, and in-vehicle links.Traffic may use dedicated channels or piggyback on legitimate telemetry; encryption, obfuscation, or fragmentation can make it harder for external observers to distinguish.Source: 1) Operational Locus · p. 6
  • The three loci are not mutually exclusive: a communication port, its controlling firmware, and its traffic span hardware, software, and network loci.A single capability may therefore produce actions and evidence across several loci.Source: 1) Operational Locus · pp. 6–7

2) Behavioural Role:

Behavioural role distinguishes covert, overt, and concealment actions. Classification depends on the observer and the action’s implementation or observable effects.

2) Behavioural Role:

  • Covert actions advance a potential adversarial objective without an apparent unauthorised effect at the specified observer’s interface.They can include sensing, data collection and storage, target or context recognition, passive message reception, or preparing data for later transmission while advertised services continue normally.Source: 2) Behavioural Role · p. 7
  • Overt actions produce observable effects conflicting with expected operation, but a one-time or safety-critical physical effect may cause harm before monitoring responds.Examples include data manipulation, communication interference, disabling protections, unauthorised actuator commands, and changes to vehicle motion.Source: 2) Behavioural Role · p. 7
  • Concealment actions obstruct discovery, observation, analysis, attribution, or preservation of another capability or its evidence.Examples include anti-analysis, context-dependent activation, log deletion, and behaviour changes during inspection; concealment can also replace malicious code with a benign substitute when investigation is detected.Source: 2) Behavioural Role · p. 7
  • The matrix classifies actions rather than components or capabilities, and an action may occupy multiple cells when loci or observer-visible effects span categories.For example, data exfiltration piggybacked on legitimate telematics traffic serves an objective while also concealing the transmission; covert versus overt status depends on observer awareness and detection capability.Source: 2) Behavioural Role · p. 7

C. Behavioural Interaction Model

The Behavioural Interaction Model relates capabilities and activation conditions to realised actions, their manifestations, and possible concealment. It is conceptual, not a chronological attack sequence or an exhaustive catalogue of behaviours.

C. Behavioural Interaction Model

  • The model links capabilities, triggers, actions, operational loci, artefacts, investigation, concealment, and declared purpose as interacting elements.Figure 3 presents these relationships conceptually, not as a chronological attack sequence.Source: C. Behavioural Interaction Model · p. 7, Figure 3 · p. 8

1) Capability Activation and Action:

  • A trigger is the condition or operating mode under which a capability is exercised; once activated, that capability is realised through one or more actions.Triggers may be internal or responsive to external conditions, and may include timers, commands, location, vehicle state, combined conditions, or continuous operation.Source: 1) Capability Activation and Action · pp. 7–8
  • Behavioural roles classify actions, not capabilities: the same capability may support covert, overt, or purpose-conformant actions.Whether an action appears covert or overt depends on the specified observer’s awareness and technical capability.Source: 1) Capability Activation and Action · p. 8
  • Actions manifest at hardware, software, or network loci, connecting abstract capability–action relationships to concrete vehicle components and interfaces.Actions may also alter internal state, supply decision inputs, or enable subsequent actions.Source: 1) Capability Activation and Action · p. 8

2) Concealment and Investigation:

The model connects actions to artefacts that investigators may acquire and interpret, while accounting for concealment that can detect or alter the investigation. Observations therefore need to be interpreted in light of contextual activation and possible concealment.

2) Concealment and Investigation:

  • Actions may leave artefacts at their operational loci, including logs, network traffic, electromagnetic emissions, or physical and electrical changes.Artefacts may not be retained, accessible, or recognised, and one action may leave different artefacts across several loci.Source: 2) Concealment and Investigation · p. 8
  • Investigation can leave traces that a concealment capability detects, prompting other capabilities to suppress, postpone, or modify their actions.Diagnostic requests, test commands, connected instruments, absent peer components, and physical disassembly may reveal examination.Source: 2) Concealment and Investigation · p. 8
  • Concealment may manipulate evidence by deleting or falsifying logs, altering data, suppressing communication, or presenting different behaviour under test conditions.Because investigation changes conditions and vehicles may respond, failure to observe a suspected action does not establish that its capability is absent.Source: 2) Concealment and Investigation · p. 8

3) Purpose Assessment from Observed Behaviour:

The model assesses evidenced operational purpose by comparing realised behaviour and supporting evidence with declared purpose, without treating declarations as necessarily complete or truthful. The discussion highlights tensions when the design authority is within the threat boundary, and the paper identifies conceptual and evidential limits.

3) Purpose Assessment from Observed Behaviour:

  • Purpose assessment compares capabilities, triggers, actions, loci, and supporting artefacts with declared purpose; neither a declaration nor one unusual action alone establishes the relationship.The model concerns evidenced operational purpose, not direct knowledge of design-authority intent.Source: 3) Purpose Assessment from Observed… · pp. 8–9

IV. DISCUSSION

  • Peer-benign, purpose-malicious functionality may affect availability, reliability, safety, integrity, and confidentiality, motivating assurance that does not presume a benign design authority.The model links the behavioural analysis to vehicles that remain authentic and protocol-conformant while evidenced purpose conflicts with declared purpose.Source: §IV · p. 9, 3) Purpose Assessment from Observed… · p. 9

A. Security Controls under an Adversarial Design Authority

  • When the design authority may be adversarial, protections against external attackers can also restrict independent access, suppress observations, or confine examination to manufacturer-controlled tools.The trust boundary includes the party whose functionality is under examination; component binding also trades reduced unauthorised reuse against repairability and dependence on manufacturer-controlled services.Source: A. Security Controls under an… · p. 9

B. Limitations

  • The model does not prescribe evidence-acquisition procedures, analytical tools, or decision thresholds, and it has not been empirically evaluated on vehicles or testbeds with seeded hidden functionality.Its matrix behaviours are illustrative rather than exhaustive; absence of observed behaviour cannot establish absence of a capability, and the model cannot establish subjective intent, prevalence, or legal responsibility.Source: B. Limitations · p. 9

C. Future Work

Future work may formalise the Behavioural Interaction Model and develop tool-supported investigation, while adapting malware-analysis concepts to cyber-physical systems. The conclusion presents the three-part threat model as a conceptual foundation and argues that authenticity and protocol conformance alone do not establish trustworthiness of operational purpose.

C. Future Work

  • Future work may formalise the Behavioural Interaction Model and develop a tool-supported workflow combining static examination, dynamic observation, and contextual stimulation.Such a workflow could consider evidence sources independent of the suspected design authority.Source: C. Future Work · p. 9
  • A possible direction is adapting malware behaviour and attribute catalogues to cyber-physical systems, including physical actions, contextual triggers, distributed components, environmental interactions, and cyber-physical observables.Other proposed directions include independent logging, randomised assessment, additional assurance mechanisms, and applications beyond vehicles.Source: C. Future Work · p. 9

D. Conclusion

  • The three components provide a conceptual foundation for examining functionality that may be distributed, contextually activated, and concealed from peers or conventional monitoring.The conclusion states that authenticity, component genuineness, and protocol conformance alone do not establish trustworthiness of operational purpose, and places the design authority within the threat boundary.Source: D. Conclusion · pp. 9–10
Loading 2610.37059v1…