This document presents the different attacks that can be envisaged on a recent car in order to be able to create a set of tests verifying the security of Automotive Grade Linux (AGL). The more general utility behind this document is to protect the manufacturers, customers and third party from potential financial and information loss. This document is firstly based on an existing AGL security-blueprint.

For security to be effective, the concepts must be simple. And by default, anything that is not allowed is forbidden.

We will cover topics starting from the lowest level (Hardware) up to the highest levels (Connectivity and Application). We will move quickly on Hardware and Connectivity because this is not supported at our level. Solutions of connectivity problems concern updates and secured settings while hardware securing is related to the manufacturers.

The document is filled with tags to easily identify important points:

  • The config tag quickly identifies the configurations and the recommendations to take.
  • The note tag allows you to notify some additional details.
  • The todo tag shows the possible improvements.

In annexes of this document, you can find all the config and todo notes.

Hardening term

The term Hardening refers to the tools, techniques and processes required in order to reduce the attack surface on an embedded system, such as an embedded control unit (ECU) or other managed devices. The target for all hardening activities is to prevent the execution of invalid binaries on the device, and to prevent copying of security related data from the device.

AGL security overview

AGL roots are based on security concepts. Those concepts are implemented by the security framework as shown in this picture:

AGL architecture

Acronyms and Abbreviations

The following table lists the strongest terms utilized within all this document.

Acronyms or Abbreviations Description
AGL Automotive Grade Linux
ECU Electronic Control Unit