Technical guide for “Cybersecurity Controls” in Automotive

Home - CyberSecurity - Technical guide for “Cybersecurity Controls” in Automotive
Technical guide for “Cybersecurity Controls” in Automotive

After the introduction of ISO/SAE 21434, Road Vehicle Cybersecurity standards and associated R155 regulations, it become mandatory to implement Cybersecurity controls in the Automotive ECUs to get corresponding vehicle type approvals in many regions of the world. Also, with the increase in complexity of the vehicle architecture and its networking capabilities, it is essential to implement robust cybersecurity controls to protect the road users against potential cyber threats.

In general, Automotive Cybersecurity controls are the measures implemented to manage and mitigate the risk of cyber threats and attacks on the road vehicle. These controls are generally defined through Cybersecurity goals derived from TARA (Threat Analysis and Risk Assessment). The goal of cybersecurity controls is to ensure confidentiality, integrity and availability of vehicle functions & to safeguard the road users and their privacy. Below are some commonly used Cybersecurity controls in the Automotive ECUs and their brief technical concepts.

Trusted Execution Environment (TEE)

To store sensitive data like “keys” and to execute sensitive cryptographic operations like “CMAC verifications” a hardware enforced Trusted Execution Environment (TEE) to be used. In modern processors, TEE is a separate core where these secure storage and operations takes place, and it is called HSM (Hardware Security Module). HSM provides a TEE by using hardware supported cryptographic operations and hardware trust anchors. Using HSM to verify integrity and authenticity of a message ensures security during Secure flashing, Secure boot, Secure Onboard communication etc. HSM is also used in key management functionalities like injecting, generating, deriving and persisting keys for all supported cipher suites.

Figure 1 is an example block diagram of Infineon Aurix microcontroller with 32-bit HSM core in it. It contains Advanced Encryption Standard (AES128) and True Random Number Generation (TRNG) implemented in the HSM HW itself, which can be used for hardware accelerated Encryption/Decryption, key generation and for Cipher-based message authentication code (CMAC) verification. There are Secure key storage areas (Program and Data flash areas) in HSM core which are secured by a firewall to provide exclusive access to the host core. TEE or HSM provides protection against logical attacks and debugger-based access.

Fig 1: block diagram of Infineon Aurix microcontroller showing Trusted Execution Environment

Source: AURIX™ HSM documentations in www.infineon.com

Secure Software Download

Secure SWDL contains off-board signing of the SW with a signature and then validating such signatures in the on-board ECUs as part of the secure software download (SWDL) process. The same process should be followed while updating SW in service station or during OTA (Over The Air) update.

A general Secure SWDL contains several steps as shown in Figure 2 and explained below:

Step 1: The software is developed in development centres and released to a Trust centre.

Step 2: In trust centre, the SW is accessed and for each block of the software a hash value is calculated. That hash is later encrypted with a private key. This encrypted hash is called “signature”.

A secure SW is now generated in the trust centre by combining “software parts” + “signature parts”. This Signed SW is now stored in the secure SW repository.

Step 4: Public key corresponding to the trust centre encryption is now stored in the TEE area of the ECU. (TEE is not mandatory for public keys but it will enhance the security)

Step 5: Trust centre signed SW is now transferred to the ECU (SWDL).

Step 6:  The software stored in the ECU is now verified using the public key (stored in TEE) to complete the SWDL process.

Fig 2: Secure SWDL process

Secure boot

Secure Boot is a security mechanism to ensure that only authenticated and thus trusted software, signed in the trust centre can only be executed in the ECU. This is ensured during boot stage of the ECU. The objective of the secure boot is to protect the execution of un-authorized software by following the secure boot sequence of the ECU.

Secure boot uses Hardware Trust Anchor (HTA) capabilities of TEE and establishes a root of trust for the computing system. The on-chip root of trust code is the starting point that can be trusted as secure. The Root of Trust key (provisioned to the hardware at production) is used by the Root of Trust code to verify the first boot stage of signed software. Then it typically involves a chain of trust that extends from the hardware level through various software layers. This involves verifying the integrity of the firmware and operating system during the system’s startup, ensuring that only authorized and unmodified code is executed.

Secure boot can be implemented by using a Symmetric keys or by using Asymmetric keys as explained below;

Secure boot using Symmetric keys and TEE:

When Symmetric keys (Private keys) are used in secure boot flow, TEE must be used for the key storage, MAC calculation and for verification. The basic flow of secure boot in this case is as below:

Step 1: When ECU boots up, Root of trust code executes from TEE, the Hardware Trust Anchor (HTA)

Step 2: Using bootloader secret key stored in TEE, MAC over bootloader SW is calculated by TEE and then compared to the stored “Bootloader MAC” value.

Step 3. Bootloader executes after successful verification of step2. Else, boot fails

Step 4 : Using SW verification secret key stored in TEE, MAC over application SW is calculated by TEE and then compared to the stored “SW MAC” value.

Step 5. Application SW executes after successful verification of step4. Else, booting fails.

Fig 3: Secure boot using Symmetric keys and TEE

Secure boot using Asymmetric keys:

When Public keys (Asymmetric) are used in secure boot flow, signature is part of the bootloader SW and application SW. The keys used to verify them are normally stored in TEE or in some OTP area. The basic flow of secure boot in this case is as below:

Step 1: When ECU boots up, Root of trust code executes from TEE, the Hardware Trust Anchor (HTA)

Step 2: Using bootloader public key, signature appended to the bootloader SW will be verified.

Step 3. Bootloader executes after successful verification of step2. Else, boot fails.

Step 4 : Using  SW verification public key, signature appended to the application SW will be verified.

Step 5. Application SW executes after successful verification of step4. Else, booting fails.

Fig 4: Secure boot using Asymmetric keys

Secure on-board communication

The motive of secure on-board communication (SecOC) is to provide authenticated and fresh data between sender and receiver on the in-vehicle network. That means the receiver shall be able to verify that a message is sent by a trusted source, and it is the latest. In SecOC, authenticity and integrity on end-to-end level of the application signal is ensured by message signing for critical in-vehicle messages. Examples of critical messages are messages controlling safety, brake, start/stop, locking signal etc. The applications that provide critical services shall have an access control policy for which clients should authorize to use the service.

There are various ways to achieve SecOC in the network but importantly an “authentication tag” shall be added to the data bytes by sender. This authentication tag can contain information like freshness value (time stamp/counter for freshness) and authenticator (e.g : MAC). On the receiver side, the SecOC module verifies the freshness and authenticity of the received message against pre-defined algorithms and MAC verification through secret key. This verification shall be executed in a TEE. The verification process should check for message integrity, freshness and authenticity. A failure handling mechanism like re-sending of message shall also be available to increase the robustness.

Note: To provide message freshness, the SecOC module on the sending and receiving side get freshness from an external Freshness Manager for each uniquely identifiable Secured I-PDU, i.e. for each secured communication link

Fig 5: Autosar specification for Message Authentication and Freshness Verification flow in SecOC

Source: Specification of Secure Onboard Communication in www.autosar.org

Security Access

On Board Diagnostics port (OBD-II) CAN communication link between ECU and Diagnostic service tester is one of the major attack paths in Automotive cybersecurity.  To avoid unauthorised access to the ECU through the tester, a challenge-response algorithm based on a common secret PIN code is implemented in both ECU and Tester. This is referred to as Security access in UDS protocol. Many diagnostic services, software download and memory writing are protected through this security access service.

Security access is defined by the UDS service 27 with basic Seed/Key mechanism as shown below. Though a very simple use case of security access method is explained below, using the same principle many advanced methods of ECU protection are possible.

Fig 6: Security access service

In the process of security access, first Tester will request for a seed from the ECU. ECU responds to the tester request with a seed generated from random numbers. Now, tester will calculate the corresponding key for that seed and send back to the ECU. ECU also calculates the key and then compare it with the Tester provided key. When they match, access to ECU is granted for a defined duration. If keys doesn´t match access is denied.

Different modes of security access shall be implemented to provide different levels of access during development, production, after market, cryptographic key updates etc.

Secure Log

Secure Log is logging of all the major ECU event records in the TEE area. In general, the events like Total number of reported events, Total number of successful events, Total number of failed events, Failure reasons, Time stamp of events etc will be stored in a round robin fashion. These logs are very useful to investigate the root cause of attacks in case of security breaches.

Some commonly used Secure Log events are Secure Software download, Secure boot, Cryptographic operations, Debugger access, SecOC, Security access, ECU Reset, Diagnostics session control etc.

Secure Debug

If an attacker manages to connect to an open debug port of MCU (often called as JTAG port), it’s easy to bypass all security mechanisms put on the device. Then using powerful debuggers, the attacker can inject malicious code, leak cryptographic keys and can extract software information. The most secure solution to this attack path is to permanently disable the hardware debug interface at the end of production stage. But however, this is not feasible, because of the need of field analysis for returned faulty devices. So, Password Based JTAG Locking is one of the secure debug solutions followed in Automotive industry.

In password based JTAG port Locking, a device unique 256-bit password is used to protect the debug interface. The debug interface protection shall be activated by configuring the corresponding UCB area of the MCU. The JTAG locking password needs to be written in the read protected UCBs during End Of Line (EOL) activity.  The entire password or key for password generation of each ECU needs to be stored in the production database.

Whenever there is a need to unlock the JTAG port, the correct password corresponding to that specific ECU from the database shall be supplied to the UCB area and JTAG locking should be removed following the sequence defined in MCU user manual.

 Other Cybersecurity controls

Along with the Cybersecurity controls explained above there are several other controls which may also need to be applied based on the specific usage and functionality of the ECU. Some example control methods are listed below:

  • An Intrusion Detection and Prevention system (IDPS) should be implemented where it can prevent on-going or future attack through terminating certain applications, closing wireless interfaces or limiting connectivity.
  • An IP firewall shall be used to prohibit all unintended internet communication as well as all unintended onboard IP communication.
  • Using Public-Key Cryptography Standards (PKCS) including Policies in order to achieve a secure and efficient Key & certificate handling.
  • Different Tasks/processes shall be separated using state-of-the-art mechanisms. Each process shall only have access to the resources actually needed.
  • When communications like RF, Ethernet, Bluetooth, Cellular, Wifi etc. are used, the corresponding cybersecurity controls shall be implemented so that such networks are always secured.

The list of cybersecurity controls will keep growing over the time since we are dealing with an adverse mindset. A systematic approach towards SW Development, Security mindset, Vulnerability management, Incident response and constant monitoring of threats and attacks on similar systems will enable us to develop secure vehicles for the road users.

Siri AB is a Sweden, based organization with expertise in Automotive, Telecom and IoT engineering. It can help in design and development of Cybersecurity controls for your automotive applications. It can also help your organization in developing Cybersecurity management according to ISO/SAE 21434 to reach the Cybersecurity Management System (CSMS) journey.

About the Author

Ishwara prasada S

Ishwaraprasada is the Head of Cyber Security Services in Siri AB with several years of experience in the Automotive domain. His area of expertise includes Cyber security, Functional safety, Autosar, Base Software, Battery management system, Vehicle Charging standards, Inverters & Engine management.

Leave A Comment

Tags