Search Results

This document specifically pertains to cybersecurity for road vehicles. This document encompasses the entire vehicle lifecycle of key management. It has been developed by SAE Committee TEVEES18F, Vehicle Security Credentials Interoperability (VSCI), a subcommittee of SAE Committee TEVEES18A, Vehicle Cybersecurity Systems Engineering Committee. This committee is authorized under the scope and authority fo the SAE Electronic Design Automation Steering Committee (also known as the Electronic Systems Group) that is directly under the scope and authority fo the SAE Motor Vehicle Council. The SAE Motor Vehicle Council’s stated scope of influence and authority, as defined by the SAE includes, passenger car and light truck in conjunction with ISO/SAE 21434.

This document provides an information report to the readers for the management of confidential data associated with hardware protected security environment (HPSE). The scope of the present document is common principles of confidential data, methodologies, conformance of SAE J3101 with regulations and standards, and use cases.

To gain an understanding of the software Application Programming Interface (API) landscape for SAE J3101 [SAEJ3101] devices, the SAE Vehicle Electrical Hardware Security Task Force conducted an analysis of various automotive-relevant crypto APIs. The purpose of this analysis was to identify how well the existing APIs cover the SAE J3101 requirements and to highlight the areas of coverage within these APIs. By examining these APIs, the Task Force aimed to gain insights into the current state of API support for SAE J3101 devices and identify any gaps in coverage that need to be addressed.

The purpose of this information report is to provide an analysis and summary of the coverage of J3101 requirements by existing GlobalPlatform technologies – Secure Elements (SE) and Trusted Execution Environment (TEE)

In this report, we aim to create a survey of side channel and fault injection attacks that have an impact on automotive embedded systems. The report will provide a taxonomy of attack types and suggested countermeasures that can be considered by manufacturers based on the their risk tolerance to such attacks. Additionally, the report will provide a common language to facilitate the communication of side channel and fault injection mitigation requirements among the various stakeholders.

In this report we aim to complete HPSE trusted applications threat analysis to determine the effectiveness of isolation security models and suggest HPSE isolation building blocks. The report will enumerate the threats applicable to HPSE trusted applications based on their deployed use case and suggested security models for manufacturers based on their risk profile.

Survey of existing best practices, standards, and challenges in automotive (and potentially other industries) for implementation of trust anchors and authentication infrastructures (e.g., PKI and related hardware trust anchors).

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.