Software Mitigations for Side-Channel Analysis Attacks in the Automotive Domain

TL;DR

Side-channel analysis (SCA) attacks can extract cryptographic secrets from automotive ECUs by observing physical signals, such as power consumption, while cryptographic operations run. SCA attacks have been publicly demonstrated on vehicle components, and many ECUs currently on the road lack adequate protection due to long development cycles and the difficulty in adding new hardware security. In cases where hardware cannot be retrofitted, various  software-based mitigations can be applied – such as limiting the number of times cryptographic operations can be triggered, introducing randomness to obscure patterns, or using masking techniques. When mitigating SCA attacks, automakers should take care to balance security aspects with the strict CPU and memory constraints of embedded vehicle systems.

Introduction

Modern vehicles rely on networks of ECUs running embedded software to deliver critical functionality. As vehicles become increasingly connected and security requirements become more prevalent, cryptography is being deployed more widely and the security of the cryptographic implementations is becoming as important as the algorithms themselves. 

Side-channel analysis (SCA) is a class of cyber attacks that exploit unintended leakage of secret information to physical channels (e.g., power consumption, electro-magnetic radiation) during cryptographic operations. SCA exploits the cryptographic implementation rather than breaking the cryptography mathematically.

What is Side-Channel Analysis (SCA)?

In the context of physical attacks on embedded systems, a side channel analysis attack is an exploitation of information about the internal execution of an embedded processor chip. The purpose is to obtain information leaking to external channels (such as the chip’s power supply line or its electromagnetic emission) during the execution of cryptographic operations in order to recover confidential information (e.g., encryption keys).

To understand how an SCA attack works, let’s consider the following example.  We’ll begin with a processor that can execute an encryption operation using a secret key. An attacker that uses SCA to recover that key will have a device that listens to a side channel (e.g., the chip’s power consumption) while the encryption is happening. Additionally, there will be some way for the attacker to trigger the encryption operation, as many SCA attacks require numerous recordings of the same operation to successfully obtain the key.  

The attack setup typically includes a recording device (e.g. an oscilloscope) recording the power consumption traces of the embedded processor during the encryption operation. Additionally, the attacker triggers the cryptographic operation under attack (e.g., by sending a CAN message). This is repeated thousands to millions of times to collect enough measurements.

The recorded traces are then analyzed offline using statistical methods to recover key-dependent information.

SCA Algorithms

There are several different types of SCA algorithms. The “classic” algorithms are Simple Power Analysis (SPA), Differential Power Analysis (DPA) and Correlation Power Analysis (CPA), while other examples  include MIA, DL-SCA, template attack, etc.

So how do these algorithms work? In a DPA attack on AES, for example, the attacker groups power traces based on a predicted property of the AES SubBytes output for each key guess – such as whether a specific output bit is 0 or 1. By subtracting the average power traces of these two groups, the correct key guess produces a noticeable differential peak, revealing the targeted key bit. Incorrect key guesses will ideally produce a flat line.

Different algorithms extract other forms of mutual information between the key and the side channel trace, resulting in variance in the required number of traces for the attack to be successful (with simpler algorithms failing on some targets regardless of number of traces). After the key is extracted, it will later be used to get privileged access to diagnostic jobs on the ECU in order to obtain code execution,impersonate the device or bypass other security controls, depending on the target private key that was obtained.  

SCA in the Automotive Domain

It has been publicly demonstrated that SCA attacks can be performed on various ECUs. For example, it was shown that SCA can be used to Dismantle Immobilizer systems, break key fob coding schemes,  and extract CAN authentication keys. However, despite the existence of robust hardware solutions that protect from SCA attacks, a significant number of automotive ECUs currently on the road are not adequately protected against this vector. 

This lack of protection could be due to several possible reasons:

• The design of an ECU starts a few years before it appears on the road, and is commonly based on a “previous generation” architecture/design. This typically results in an ECU that is lagging behind from a security perspective. 
• It is difficult to retrofit security into existing architectures, especially when it involves introducing new hardware into the design.
• Even when applying ISO/SAE 21434, risk assessment does not always take into consideration the full impact or relative simplicity of SCA attacks on the ECU, resulting in an absence or shortage of security requirements in this area.

There are several types of ECUs that should be equipped with robust SCA resistance:

• Body Control Modules (BCM) / Immobilizer:  These directly store the keys that protect the vehicle from theft.
• Gateway ECUs: These act as firewalls and routers between different vehicle domains (e.g., CAN, Ethernet) and hold critical keys for message authentication and encryption
• Telematics Control Units (TCU): These units provide external connectivity (OTA, cellular) and are often the initial entry point for remote attacks. They store keys for secure remote communication and firmware updates.

Software Mitigations for SCA

Let’s consider the case of an ECU that is either already on the road or has finished the major architecture/design process and needs to be protected against SCA for some AES encryption operation. Such an ECU will have the means to update its software, however changing the hardware to include SCA-resistant solutions is not an option.

What can be done on the software level to protect this ECU from SCA (e.g., power analysis)?

There are two strategies that can work for software-based mitigation implementations: Since the SCA attack assumes that key-related information is leaking into the side channel, it’s possible to use either acquisition limiting (to prevent an attacker from obtaining sufficient number of traces), hiding (to reduce SNR/desynchronize the key information in the side channel), or use masking (to randomize sensitive values so leakage is statistically independent).

Acquisition Limiting Countermeasures

Countermeasure	Principle	Implementation Cost (CPU/RAM)	Effectiveness
Rate Limiting	Limits the number of power traces an attacker can obtain at a given time.	Very low CPU/RAM/ROM. Usually a small code fix.	Not applicable for some applications. If applicable, highly effective against DPA/CPA as most attacks require a large number of power traces.
Re-keying/Session Keys	Limit the number of traces per key by frequently deriving fresh keys (per session, per time window, or per message).	Moderate CPU, minimal RAM/ROM; requires protocol support.	Not applicable for some applications. If applicable, can dramatically increase attack difficulty because DPA/CPA needs many traces for one key.

Hiding Countermeasures

This table summarizes common software countermeasures that operate by hiding the key information in the side channel:

Countermeasure	Principle	Implementation Cost (CPU/RAM)	Effectiveness
Instruction Shuffling	Randomly re-ordering independent instructions within a cryptographic operation to vary the temporal position of data-dependent operations.	Moderate CPU overhead (due to randomization logic). Minimal RAM/ROM.	Highly effective against SPA and DPA/CPA that rely on precise timing alignment. Requires a random number generator (RNG).
Dummy Operations / Random Delays	Inserting random, data-independent operations (e.g., dummy reads/writes, NOPs, wait states) to cause desynchronization/ misalignment between traces.	Low CPU overhead. Minimal RAM/ROM.	Effective against SPA and improves the resistance of DPA/CPA by making syncing of traces harder, increasing the noise floor and requiring more traces.

Random Masking

A method to prevent the leakage of the key value to the side channel, we must ensure that the encryption operation does not use the key directly. 

Random masking is a technique designed to break the direct relationship between sensitive data (e.g., the secret key) and their physical leakage by randomizing all key-dependent intermediate values and splitting them into multiple ‘shares,’ such that any single share is not confidential on its own. The shares are, each by itself, not confidential. The encryption is done only using masked shares, and the final result is recombined to get the normal encryption result. 

Below is an example for first-order boolean masking of AES:

As illustrated above, in its simplest form (called first order masking) the masking works as follows:

• Generate a random masking value rand (in the length of the key)
• Calculate two shares: s1 = rand, s2 = key XOR rand
• Perform joint masked AES on the shares to get c1,c2 (since AES is a non-linear operation, there is a joint calculation on the non-linear internal stages)
• Perform unmasking, which is the process of obtaining the normal AES result c (the result of encrypting using non-masked elements) from recombining the shares

In this example a simple XOR operation was used. This is called boolean masking. Other operations can be used (additive, multiplicative, affine), each with a different complexity. 

In addition to first order masking, it’s possible to use higher order (where the key is split into more than two shares) and then perform joint AES on more shares. 

It should be noted that in the same way it’s possible to encrypt using higher order masking, it’s also possible to attack using a higher order attack. Such an attack would entail attacking all share encryption calculations and combining their results for all shares. However, it is generally accepted that n-th order masking is a good protection against n-th order attacks. In other words, first order masking is a good protection against a first order attack, which is the simple SCA attack. Moreover, a higher level attack is much harder to implement, and will work less effectively since it requires more traces, more recording time per trace, better sync between power traces, lower noise rates etc. 

Naturally, implementing such a mitigation does not come without a cost. The joint AES on two shares practically consumes the resources of two separate AES calculations, while also requiring a different random value for each data block encrypted, additional intermediate registers, etc. The cost of such a mitigation is estimated in the table below, which details the required resources (CPU Cycles, RAM,ROM) for different types of masking implementations as compared to a basic AES implementation without masking:

	Required Resources			Requirements for a successful SCA attack
	CPU Cycles (approx., per block)	RAM	ROM	Attack Order	Number of traces
No Masking Plain AES (Unprotected)	~1.6k–2k	~0.5KB	~1-2KB	First order (Simple SCA)	~1-7k (moderate noise)
First-Order Boolean Masking	~x2–x10	~x2–x10	~x2–x10	Second order	~1-7k (moderate noise), ~10-100k (high noise)
Second-Order Boolean Masking	~x10-x1000	~x5–x50	~x2–x10	Third order	50-100k (moderate noise) 100k-1m (high noise)
First-Order Multiplicative Masking	~x2–x10	~x2–x10	~x2–x10	First order (can succeed with controlled input)	~1-7k (moderate noise)
First-Order Affine Masking	~x10-x100	~x2–x10	~x2–x10	Second order	~50k-100k (moderate noise) ~100k-1M (high noise)

Resources used to gather the information in the table above:

[1] First-Order Masking with Only Two Random Bits

[2] All the AES You Need on Cortex-M3 and M4

[3] Affine Masking against Higher-Order Side Channel Analysis

[4] Review of Side Channel Attacks and Comparison of Masking and Re-keying Countermeasures

[5] Syn-STELLAR: An EM/Power SCA-Resilient AES-256 With Synthesis-Friendly Signature Attenuation

[6] Exploiting Small Leakages in Masks to Turn a Second-Order Attack into a First-Order Attack and Improved Rotating Substitution Box Masking with Linear Code Cosets

Please take into account that this is a rough ballpark estimate based on published implementations and your mileage may vary. The exact resource requirements are implementation-dependent and will be determined by the target chip, architecture, form of AES implementation (e.g., bitsliced vs table-based), etc.

Practical Recommendations

Based on our experience working with OEMs and Tier 1 suppliers, here are some practical suggestions and pointers for mitigating side channel attacks

• When looking for the appropriate software solution, start with rate limiting when possible. If not, for TCUs and gateway ECUs, session keys are especially practical because communication already includes handshake phases and counters. For immobilizer/key fob systems, masking is typically more practical than key rotation due to protocol constraints and backward compatibility.
• For masking and shuffling, use hardware RNG if available to prevent entropy depletion attacks and leaks from limited entropy.
• Perform SCA evaluation as part of your ECU security testing to test against CPA and profiling attacks.

Bottom Line

Side channel analysis is a physical side-channel attack that poses a serious threat to automotive ECUs. Even for ECUs that were not designed with protection against such an attack, it’s possible to mitigate the risk with a suitable software implementation as long as the ECU’s software can be updated. While highly effective from a security standpoint, these software changes introduce a performance overhead that can be significant for embedded devices with limited resources.