Search Results

The scope of the report is a gap analysis between J3101 requirements that require an API and the API functions described in common automotive security APIs. AUTOSAR Crypto Driver R21-11 was chosen as the first interface to analyze.

The scope of this Information Report is to address the current state of the art in managing confidential data in the technical and regulatory aspects. The report will provide guidance as enumerated below. • Common Principles of data confidentiality must be outlined in one or more informative illustrative examples to provide the context of the role of an HPSE. • J3101 Hardware support for technical aspects of secure management of confidential data • J3101 Hardware support necessary for secure deletion/erase • J3101 Hardware to achieve consistent secure management of the confidential data • Achieve conformance with common principles in privacy regulations and standards • Describe use cases for confidential data management

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.

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.

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.

This document will define architecture, design, and implementation requirements for vehicle key management security. This would of course include KMS interfaces, but would also include the ecosystem constraints, e.g., recommendations for hardening the OEM and Tier-1 backend systems (using role-based separation modeled on Uptane) to avoid single points of failure in key generation and key storage systems.