Access mechanisms to system data and/or control is a primary use case of the hardware protected security environment (hardware protected security environment) during different uses and stages of the system. The hardware protected security environment acts as a gatekeeper for these use cases and not necessarily as the executor of the function. This section is a generalization of such use cases in an attempt to extract common requirements for the hardware protected security environment that enable it to be a gatekeeper. Examples are: Creating a new key fob Re-flashing ECU firmware Reading/exporting PII out of the ECU Using a subscription-based feature Performing some service on an ECU Transferring ownership of the vehicle Some of these examples are discussed later in this section and some have detailed sections of their own. This list is by no means comprehensive. Other use cases that require hardware protected security environment-based access control may be used by each manufacturer/service provider based on vehicle capabilities, architecture, and business model. This section describes how the hardware protected security environment provides a platform to implement access control by enabling secure authentication, authorization and access enforcement. It does not define any specific access control system (DAC/MAC/capability-based/role-based/etc.), models, or polices. A general access control system is based on the following stages: 1 Identifying and authenticating the user. 2 Authorizing access to the resource. a Comparing authenticated user to policies (database/certificates/other). b Comparing other conditions (temporal/spatial/other) to policies database. c Unlocking access to the resource. 3 Using the resource. 4 (Optional) Removing access to the resource based on temporal or other conditions. a Locking access to the resource. The hardware protected security environment can be involved to different extents in each of the stages listed above. The main two types of hardware protected security environment involvements are full control and partial control. In partial control, the hardware protected security environment is responsible to authenticate and authorize the access, while the normal environment is responsible to lock/unlock the resource. In full control, the hardware protected security environment is responsible for both. Automotive computer systems are required to establish trustworthiness through device identity, sealing, attestation, data integrity, and availability. These systems must be resilient to a wide range of attacks that cannot be thwarted through software-only security mechanisms. A hardware root of trust and the hardware-based security primitives are fundamentally necessary to satisfy demands of connected and highly or fully automated vehicles. This document provides a comprehensive view of security mechanisms supported in hardware for automotive use cases, along with best practices for using such mechanisms.


    Access

    Check access

    Check availability in my library

    Order at Subito €


    Export, share and cite



    Title :

    Hardware Protected Security for Ground Vehicles


    Publication date :

    2020-02-10



    Type of media :

    Conference paper


    Type of material :

    Print


    Language :

    English




    Hardware-Based Cyber Security for Connected Vehicles

    Harrison, Lee / Pickford, James | British Library Conference Proceedings | 2023


    Leveraging Hardware Security to Secure Connected Vehicles

    Corbett, Christopher / Brunner, Martin / Schmidt, Karsten et al. | British Library Conference Proceedings | 2018


    Leveraging Hardware Security to Secure Connected Vehicles

    Corbett, Christopher / Schmidt, Karsten / Brunner, Martin et al. | SAE Technical Papers | 2018


    Hardware-Based Cyber Security for Connected Vehicles

    Pickford, James / Harrison, Lee | SAE Technical Papers | 2023