PaperlayerView exact revision on arXiv

Source-linked AI summary

Autonomous Vehicle: Security by Design

Anupam Chattopadhyay, Kwok-Yan Lam

arXiv:1810.00545v1cs.CR

TL;DR

AV security-by-design is described as poorly understood, while attack studies and standards lack a consistent approach for complex AV systems. The paper models AVs as cyber-physical, socio-technical systems and develops a security-by-design framework. It derives security objectives and control measures from safety requirements, then identifies technical challenges and proposed approaches.

  • Problem

    AV security lacks consistent approaches to attack-surface identification, threat analysis, and risk assessment across its overlapping technology domains.

    Source: A. CPS Security · p. 2, E. System Security Model for AV · p. 7

  • Method

    The paper models AVs as cyber-physical systems and develops a security-by-design framework using a socio-technical perspective.

    Source: §VI · p. 10

  • Results

    The paper derives security objectives and control measures from AV safety requirements and identifies technical challenges and proposed approaches for AV security.

    Source: §VI · pp. 10–11

  • Takeaways & Limitations

    The paper identifies resilience of AV safety operations under cyber attack as a key cybersecurity objective.

    Source: §VI · pp. 10–11

Abstract

from arXiv · show

Security of (semi)-autonomous vehicles is a growing concern, first, due to the increased exposure of the functionality to the potential attackers; second, due to the reliance of car functionalities on diverse (semi)-autonomous systems; third, due to the interaction of a single vehicle with myriads of other smart systems in an urban traffic infrastructure. Beyond these technical issues, we argue that the security-by-design principle for smart and complex autonomous systems, such as an Autonomous Vehicle (AV) is poorly understood and rarely practiced. Unlike traditional IT systems, where the risk mitigation techniques and adversarial models are well studied and developed with security design principles such as security perimeter and defence-in-depth, the lack of such a framework for connected autonomous systems is plaguing the design and implementation of a secure AV. We attempt to identify the core issues of securing an AV. This is done methodically by developing a security-by-design framework for AV from the first principle. Subsequently, the technical challenges for AV security are identified.

I. INTRODUCTION

The paper frames AV security as a system-level CPS problem: increasing autonomy brings more sensing and connectivity, while isolated attack studies do not account for system objectives, adversarial assumptions, or trust boundaries. It therefore emphasizes security-by-design for AVs and derives technical challenges from their safety objectives.

I. INTRODUCTION

  • Levels 0–2 leave driving-environment monitoring to humans, while Levels 3–5 assign it to the system; the paper defines AVs as Level 3 and above.The autonomy levels and associated capabilities are summarized in Table I.Source: §I · p. 1

Related Literature

  • Connected AVs face attack sources through network interfaces and the physical environment, with a compromised Bluetooth connection offered as one example.Attack sources may be external agents or events, or malicious internal components.Source: Related Literature · p. 1, Figure 1 · p. 1
  • The review focuses on CPS and AV security issues, particularly attacks demonstrated in practical settings.It groups AV threats by exposed CPS components and uses generic CPS attack models as a point of reference.Source: Related Literature · pp. 1–2

A. CPS Security

  • CPS combine sensors, computing nodes, actuators, and communications in feedback loops, but localized generic attack studies can miss system objectives, operating context, and roots of trust.The paper also notes the lack of a well-defined security standard aligned with AV road-safety standards.Source: A. CPS Security · pp. 2–3
  • The paper treats AV security as a CPS-wide design problem, deriving safeguards from safety objectives and accounting for vulnerabilities across autonomy levels.It identifies security-by-design as a holistic systems-engineering process rather than a collection of isolated attack analyses.Source: A. CPS Security · pp. 2–3

B. AV Security Issues

AVs connect to other vehicles, infrastructure, manufacturers, and internal control systems. These links and in-vehicle networks create distinct security concerns that require authentication, payload protection, and tightly controlled access.

B. AV Security Issues

  • V2I and V2V links provide traffic and navigation information but are attack surfaces requiring mutual authentication and payload protection against disclosure and modification.These connections link AVs to traffic-management infrastructure and other AVs.Source: B. AV Security Issues · p. 3
  • AVs contain overlapping CPS functions, often communicating over wired CAN or FlexRay networks, which the security design must rigorously protect.Examples of internal functions include adaptive cruise control, anti-lock braking, and assistive parking.Source: B. AV Security Issues · p. 3
  • External access to intra-vehicle networks, including for maintenance or services, should be strictly controlled because even wireline standards can be vulnerable without proper design [29].A study of intra-vehicle network security is described as decoupled from a holistic security-by-design view.Source: B. AV Security Issues · p. 3
  • The communication link to the manufacturer should be authenticated, with payload protection matched to the operational data being transmitted.Source: B. AV Security Issues · p. 3

III. SECURITY-BY-DESIGN

The paper frames AV security-by-design as a socio-technical process that begins with security objectives and risk, with safety-feature resilience as the prime AV objective. It combines system-level threat modeling with traditional message-level security requirements.

III. SECURITY-BY-DESIGN

  • Resilience of safety features is the prime AV security objective because attacks on collision detection, cruise control, or anti-lock braking may cause injury or loss of life.The paper says these features demand the highest level of security measures.Source: §III · p. 3
  • The framework treats AV security as socio-technical, accounting for people and management alongside technical design, and presents its security-management layers in Fig. 5.The paper describes identifying security objectives within this holistic framework.Source: §III · p. 3, Figure 5 · p. 4

A. Tenets of Security

  • Security-by-design identifies system objectives, assesses asset sensitivity, defines policy, estimates adversary capabilities, and matches controls to sensitivity and risk.The design also accounts for management and people factors in setting objectives and risk-taking decisions.Source: §III · p. 3, A. Tenets of Security · p. 4
  • Message-level CIA requirements guide traditional policies, while STRIDE classifies system-level threats such as spoofing, tampering, repudiation, disclosure, denial of service, and privilege elevation.Policies are implemented through physical and logical controls, including cryptographic primitives and security protocols.Source: A. Tenets of Security · p. 4

B. Adversarial Model

The paper frames adversary modeling around attacker objectives and capabilities, including communications access and computing resources. It notes that a well-defined model for overall AV operations is lacking.

B. Adversarial Model

  • Attack likelihood depends on adversary capabilities and interest in investing resources, while that interest relates to the system’s value and sensitivity to owners and attackers.The paper describes adversarial models as a means of analyzing attacker capabilities.Source: B. Adversarial Model · p. 4
  • AV adversary models consider attack objectives, communication access, and computing capability, including whether attackers can intercept or inject messages and execute analysis efficiently.Examples of channels include the vehicle’s internal CAN bus and V2X communications; computing tasks include cryptanalysis and protocol reverse engineering.Source: B. Adversarial Model · p. 4
  • The paper says overall AV operations lack a well-defined adversarial model; adversarial deep learning work is outside this discussion’s scope.That work addresses attacks on autonomous-driving controls, not security analysis of overall AV operations.Source: B. Adversarial Model · p. 4

C. Trust Model and Security

The paper treats a realistic trust model as the foundation for practical security mechanisms, then outlines trust and network protections for AV-connected systems. Its security-by-design process applies a holistic framework to AVs as socio-technical systems.

C. Trust Model and Security

  • Trust models include trusted third parties, web of trust, and distributed trust; blockchain’s decentralized model may use consensus and decision mechanisms.Cryptography-enabled controls seek confidentiality, integrity, and authenticity at message and data level, requiring key management.Source: C. Trust Model and Security · p. 5
  • A practical trust model establishes who can be trusted and underpins cryptographic mechanisms and protocols; retrofitted systems may rely on unverified key-management code.The paper argues that security-by-design makes the trust basis explicit and subject to verification and assurance.Source: C. Trust Model and Security · p. 5

D. Trust Infrastructure and Security Mechanisms

  • Trust infrastructure includes node admission and malicious-node detection, with key-management approaches such as pre-distribution, identity-based encryption, and certification authorities.Trust management can impose performance overhead on low-end devices through secure key storage or dynamic code attestation.Source: D. Trust Infrastructure and Security… · p. 5
  • Network protections include trusted-base-station authentication and encryption, multipath or geographic routing, heterogeneous-network interoperability, authenticated boot, protected storage, and trusted identification.The paper also identifies PUF-based trust anchoring and hardware Trojans introduced during manufacture or repair as relevant considerations.Source: D. Trust Infrastructure and Security… · p. 5

IV. SECURITY-BY-DESIGN FOR AUTONOMOUS VEHICLES

  • For AV security-by-design, the paper sets out five steps from defining objectives and assessing sensitivity to policy, adversary estimation, and risk-matched controls.It says a sound framework first establishes an AV operation model for holistic analysis of security objectives and requirements.Source: §IV · pp. 5–6

A. AV Operation Model

The assumed Level-5 AV operation model includes external communications, environmental sensing, and navigation and safety control functions. From this model, the paper derives integrity, confidentiality, and authenticity requirements for vehicle functions, communications, updates, and keys.

A. AV Operation Model

  • The assumed AV periodically sends logs to its manufacturer, accepts workshop software updates, communicates with traffic management, senses its environment, and performs navigation and safety control.Navigation includes route updates, planning, and steering; safety functions include steering, speed regulation, and braking according to road conditions.Source: A. AV Operation Model · p. 6

B. Security Objectives and Requirements of AV

  • Security objectives require integrity of remote control, sensor data, and safety- and navigation-related control operations.The control operations should follow sensed road conditions, remote instructions, or a preprogrammed route path, as applicable.Source: B. Security Objectives and… · p. 6
  • The objectives also require confidentiality for traffic-management communications and cryptographic keys, plus confidentiality and integrity for manufacturer communications and integrity and authenticity for workshop updates.These requirements support protection of safety-related parameters, vehicle maintenance, and high-assurance software patching and updates.Source: B. Security Objectives and… · p. 6

C. Safety Standards for AV

AV security objectives should derive from relevant safety standards, while adversarial models specify capabilities that security controls must address. The section presents standards-based objective analysis and assumes attackers can manipulate vehicle communications or introduce malicious nodes.

C. Safety Standards for AV

  • ISO 26262 defines automotive ASIL classifications for severity, exposure, and controllability, with higher levels indicating more grievous situations.The standard provides a safety lifecycle spanning management, development, production, operation, service, and decommissioning; HARA, FTA, and FMEA are among the assessment techniques identified.Source: C. Safety Standards for AV · p. 6
  • SAE J3061 [1] distinguishes system safety from cybersecurity and states that cybersecurity-critical systems are not necessarily safety-critical, while the reverse is true.Based on ISO 26262, it addresses the automotive threat landscape and promotes shared awareness and terminology across the AV supply chain.Source: C. Safety Standards for AV · p. 6
  • The AV security design flow analyzes security objectives and requirements based on relevant safety and security policies and standards.The adversarial-model subsection frames attacker capabilities as a basis for designing controls commensurate with system sensitivity and risk.Source: C. Safety Standards for AV · p. 7, Figure 6 · p. 7, D. Adversarial Models for AV Security · p. 7

D. Adversarial Models for AV Security

  • The adversarial model assumes attackers can intercept and tamper with inter- and intra-vehicle communications and introduce malicious nodes into those networks.The paper characterizes these capabilities as practical and demonstrated in several attacks.Source: D. Adversarial Models for AV Security · p. 7

E. System Security Model for AV

The paper addresses inconsistent approaches to AV attack-surface identification, threat identification, and risk assessment with a three-layer security model. It uses layer boundaries and trust assumptions to organize security design, countermeasures, and testing.

E. System Security Model for AV

  • The paper identifies inconsistent approaches to attack-surface identification, threat identification, and risk assessment, with no single AV-security standard covering the overlapping technology domains.The overlap includes wireless communications, electronics, mechanical systems, and software development practices.Source: E. System Security Model for AV · p. 7
  • AV security issues span the vehicle core, its gateway, and V2V/V2I communications, within a model that also includes connected infrastructure and backend modules.The paper identifies the core as the vehicle enclosure, the interface layer as external connectivity, and the infrastructure layer as connected systems trusted by and connected to the AV.Source: E. System Security Model for AV · p. 7
  • The core layer relies on physical security, while the gateway layer uses network access controls to guard internal AV functions across links such as Bluetooth, WiFi, and ZigBee.The gateway model assumes the core's physical security and does not treat physical damage within that layer as a cybersecurity hazard.Source: E. System Security Model for AV · p. 7
  • External vehicles, traffic infrastructure, and cloud services require dynamic trust management because trusted components can send malicious packets and untrusted ones can bypass the gateway.A breached perimeter does not necessarily compromise safety if safety-related features are inaccessible from the wireless gateway.Source: E. System Security Model for AV · p. 7

V. AV SECURITY: IMPLEMENTATION, OPERATION AND MANAGEMENT

  • Security design proceeds through perimeter and root-of-trust definition, then trust infrastructure; the resulting threat environments guide vulnerability analysis, countermeasure design, and security testing or auditing.Perimeters divide the AV into domains with different threat environments, while reinforcing each layer's boundary supports realistic assumptions for analysis of layers above it.Source: §V · pp. 7–8, A. Security Perimeter · p. 8

A. Security Perimeter

  • The perimeter model excludes sensor spoofing that requires physical intrusion from cyber-attack scope, while recognizing compromise of gateway access controls or tampering by a trusted compromised component.The paper uses this distinction to separate cybersecurity incidents from physical tampering.Source: A. Security Perimeter · p. 8

B. Establishing Roots of Trust

The paper grounds AV trust in key-management mechanisms and lifecycle support, then calls for dynamic trust decisions in vehicle communications and software updates. Its safety-operation examples assume a navigation provider and trusted traffic infrastructure within the root of trust and security perimeter.

B. Establishing Roots of Trust

  • A root of trust supports secure key exchange and key management, with options including PUF-based authentication and signatures, public-key protocols, or pre-distributed keys.PUFs can establish device identity from silicon characteristics, addressing the device-identity administration problem described for trust management.Source: B. Establishing Roots of Trust · p. 8
  • AV lifecycle trust infrastructure should support secure software patches, secure boot, and theft prevention, alongside secure supply-chain management that accounts for Trojan hardware.The paper points to PKI-based infrastructure in the smartphone industry as an example of lifecycle management and software-upgrade support.Source: A trusted infrastructure · p. 8
  • V2V communications should support critical operations only at a suitable trust level, and software updates must come from a trusted source grounded in an established root of trust.The paper calls for dynamically managing trust in AV networks because malicious or compromised participants can expose a cluster of vehicles to chain-reaction attacks.Source: Trust Management · p. 8

C. Security of Safety Operations

  • The safety-operation examples assume the navigation service provider and integrity of safety/navigation controls in the root of trust, with the AV gateway and trusted traffic infrastructure forming the perimeter.The section introduces collision-avoidance and navigation scenarios to illustrate security objectives under these assumptions.Source: C. Security of Safety Operations · pp. 8–9

1) Collision Avoidance:

The collision-avoidance example calls for independent, high-assurance collision detection and integrity of safety and navigation controls. The navigation example considers compromise of a third-party provider or input interface and proposes an independent position source and spoof identification.

1) Collision Avoidance:

  • An attacker may force the AV into collision, so the design calls for an independent, high-assurance collision detector able to override other mechanisms and stop the vehicle gracefully.The paper favors efficient real-time embedded obstacle sensors because software implementation makes assurance difficult and AI or analytic detection may be probabilistic.Source: 1) Collision Avoidance · p. 9
  • Collision-avoidance security objectives include integrity of sensor data, braking and speed controls, steering and navigation operations, stored cryptographic keys, and the kill switch.The proposed embedded obstacle sensor-actuator system overrides safety or navigation switches to brake and stop the engine when an obstacle threatens collision.Source: 1) Collision Avoidance · p. 9

2) Navigation:

  • A navigation attacker may enter through the third-party service interface, breach provider trust, or exploit the hardware/software interface receiving navigation inputs.A supplementary GPS system can reduce singular dependence on third-party providers by giving the car its own position estimate.Source: 2) Navigation · p. 9
  • Navigation security requires integrity of navigation controls and either spoof identification or an independent GPS system.The paper says the other specific security measures are essentially the same as those for collision avoidance.Source: 2) Navigation · p. 9, 1) Collision Avoidance · p. 9

3) Remote Control:

Remote-control access can expose vehicle networks to attacks that compromise cruise or braking functions, while AV security management requires continuing assessment and testing across the vehicle’s lifetime. The section reviews attack controls, risk-assessment approaches, and security-testing methods.

3) Remote Control:

  • Remote access can expose the car network to replay attacks and enable attackers to take over cruise or braking control, disrupting the vehicle’s journey.A remote keyless-entry replay records and later resends an RF code to gain entry.Source: 3) Remote Control · p. 9
  • Remote-control protections include monitoring unusual IoT communications, authenticating remote functions, safeguarding safety controls, and protecting cryptographic keys.The listed measures include biometric identification or two-factor authentication and maintaining the confidentiality of stored keying materials.Source: 3) Remote Control · pp. 9–10

D. AV Security Management

  • AV security management requires continuous assessment of security challenges throughout the vehicle’s lifetime.The section includes threat and risk assessment, security testing, and legal perspectives on AV security incidents.Source: D. AV Security Management · p. 10
  • Risk-assessment approaches include attack trees, TVRA, software vulnerability analysis, and STRIDE; SAE J3061 leaves risk-level determination and TARA-method choice to each organization.Attack trees can identify worst-case scenarios and quantify risk across safety, privacy, financial, and operational dimensions.Source: Threat Analysis and Risk Assessment… · p. 10
  • Software vulnerability analysis accounts for differences between development and deployment environments, including AV-like resource constraints and malicious attackers.Source: Threat Analysis and Risk Assessment… · p. 10
  • Security testing methods include fuzzing, network stress and configuration testing, penetration testing, and red teaming.Network testing can decode packets and match network topology; penetration tests may use black-box or white-box settings.Source: Security Testing Methods · p. 10

VI. CONCLUSION AND OPEN PROBLEMS

The paper develops a security-by-design framework for AVs and derives security objectives and control measures from safety requirements. It identifies resilience of safety operations against cyberattacks as a key objective, while legal and liability issues remain an open challenge.

VI. CONCLUSION AND OPEN PROBLEMS

  • The paper develops an AV security-by-design framework from first principles, modeling the vehicle as a cyber-physical system and examining objectives through a socio-technical perspective.Source: §VI · p. 10
  • The paper derives security objectives and control measures from AV safety requirements, with resilient safety operations under cyberattacks as a key cybersecurity objective.Source: §VI · pp. 10–11
  • Legal and liability issues remain a major challenge, including determining responsibility after crashes that may cause loss of life.The paper identifies these issues as a subject for future AV security studies.Source: §VI · p. 11
Loading 1810.00545v1…