[image] [image] Ressource protégée - CEA - Commissariat à l'énergie atomique et aux énergies alternatives Accéder directement au contenu

*[image] [image]*

* [Documentation](#)

• FR
Français (FR)

- Anglais (EN)
  Se connecter

• [Portail HAL CEA](#)

* Recherche
Loading...

Recherche avancée

Information de documents

Titres

○ [Titres](#)

○ [Sous-titre](#)

○ Titre de l'ouvrage

○ <u>Titre du volume (Série)</u>

○ <u>Champ de recherche par défaut (multicritères) + texte intégral des PDF</u>

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ <u>Tous les identifiants du document</u>

○ Identifiant HAL du dépôt

○ <u>Langue du document (texte)</u>

○ Pays (Texte)

○ Ville

○ <u>À paraître (true ou false)</u>

Ajouter
<figure><img src="image_1.png" /></figure>

HAL
open science

# On hardware acceleration of quantum-resistant FOTA systems in automotive

Pericle Perazzo, Stefano Di Matteo, Gianluca Dini, Sergio Saponara

► To cite this version:

Pericle Perazzo, Stefano Di Matteo, Gianluca Dini, Sergio Saponara. On hardware acceleration of quantum-resistant FOTA systems in automotive. Computers and Electrical Engineering, 2024, 118 (PartA), pp.109327. 10.1016/j.compeleceng.2024.109327. cea-04616076

HAL Id: cea-04616076

https://cea.hal.science/cea-04616076v1

Submitted on 18 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
<figure><img src="image_3.png" /></figure>

ELSEVIER

<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /></figure>

# On hardware acceleration of quantum-resistant FOTA systems in automotive

Pericle Perazzo<sup>a,∗</sup>, Stefano Di Matteo<sup>b,c,a</sup>, Gianluca Dini<sup>a</sup>, Sergio Saponara<sup>a</sup>

## ARTICLE INFO

**Keywords:**

Automotive FOTA

Post-quantum cryptography

Crystals-dilithium

Falcon

SHAKE

Hardware acceleration

## ABSTRACT

The Firmware Over-The-Air (FOTA) technology aims at updating the firmware of mobile computing devices via wireless. In the automotive industry, FOTA can keep the firmware of the various electronic controllers up-to-date without any manual intervention, so that to improve the operational performance and quickly fix the security vulnerabilities of vehicles. Of course, FOTA must avoid that a malicious party installs vulnerable or backdoored firmware on electronic controllers, which may lead to safety risks for the driver. It follows that a FOTA management system must guarantee the integrity and authenticity of all the firmware updates. While these security requirements are generally guaranteed by means of digital signatures, the advent of quantum computing is making traditional signature schemes increasingly vulnerable. Large-scale quantum computers able to break RSA and ECDSA could appear during the long lifetime of vehicles that are now in production, which can often reach two decades. In this paper, we experimentally evaluate the performance from an automotive FOTA perspective of Crystals-Dilithium and Falcon, two quantum-resistant lattice-based digital signature schemes that have been selected in 2022 by the NIST Post-Quantum Cryptography standardization process, and that represent the most probable choices for the future security technology. In particular, we evaluate the running time of various cryptographic operations performed by Uptane, which is a standard for automotive FOTA systems by the IEEE Industry Standards and Technology Organization, on three reference hardware architectures representing different classes of electronic control units. By means of experiments we also highlight that the hashing function is the primary limiting factor for the performance of automotive FOTA and, consequently, is the most convenient component to accelerate in hardware to improve FOTA execution time. Finally, we propose a hardware accelerator for SHAKE, the hash function used by both Crystals-Dilithium and Falcon, and experimentally evaluate the performance improvement that it brings about in automotive FOTA operations.

## 1. Introduction

The automotive industry is experiencing a significant change as in-vehicle systems are being digitalized to enable automation, connectivity, and shared mobility. Presently, cars have up to 150 Electronic Control Units (ECUs) [1,2] and approximately 100 million lines of software code, which is four times more than what a fighter jet has. It is expected that the number of lines of code

<footnote><sup>a</sup> Department of Information Engineering, University of Pisa, Via Caruso, Pisa, 56122, Italy</footnote>

<footnote><sup>b</sup> CEA-Leti, Grenoble Alpes University, F-38000, Grenoble, France</footnote>

<footnote><sup>c</sup> CEA-List, Grenoble Alpes University, F-38000, Grenoble, France</footnote>

<footnote>* Corresponding author.</footnote>

<footnote>E-mail addresses: pericle.perazzo@unipi.it (P. Perazzo), stefano.dimatteo@cea.fr (S. Di Matteo), gianluca.dini@unipi.it (G. Dini), sergio.saponara@unipi.it (S. Saponara).</footnote>
Autres

Champ de recherche par défaut (multicritères)

○ <u>Champ de recherche par défaut (multicritères)</u>

○

○ <u>Revues (multicritères)</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Titre abrégé</u>

○ <u>Revue : Titre</u>

○ <u>Revue : Identifiant interne</u>

○ <u>Revue : Date de début de publication</u>

○ <u>Revue : ISSN électronique</u>

○ <u>Revue : ISSN</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Couleur dans SHERPA/RoMEO</u>

○ <u>Revue : État dans le référentiel</u>

○

○ <u>Colloque (multicritères)</u>

○ <u>Colloque : Titre</u>

○ <u>Colloque : Organisateur</u>

○ <u>Colloque : date de début (Année)</u>

○ <u>Colloque : date de fin (Année)</u>

○ <u>Conférence invitée (oui/non)</u>

○

○ <u>Projets ANR (multicritères)</u>

○ <u>Projet ANR : Acronyme</u>

○ <u>Projet ANR : Acronyme du programme</u>

○ <u>Projet ANR : Code décision (référence)</u>

○ <u>Projet ANR : Nom</u>

○ <u>Projet ANR : Identifiant interne</u>

○ <u>Projet ANR : État dans le référentiel</u>

○

○ <u>Projets européens (multicritères)</u>

○ <u>Projet européen : Acronyme</u>

○ <u>Projet européen : Identifiant de l'appel à projet</u>

○ <u>Projet européen : Référence</u>

○ <u>Projet européen : Nom</u>

○ <u>Projet européen : Date de fin</u>

○ <u>Projet européen : Financement</u>

○ <u>Projet européen : Date de début</u>
will increase to 300 million by 2030. Considering that complex software inevitably contains bugs, and that vehicles are increasingly accessible via wireless and connected to the Internet and thus exposed to attacks, it becomes paramount to rapidly distribute firmware updates and security patches [3]. The United Nations issued two regulations on cybersecurity and software updates that will help tackle the security risks in the automotive field [4,5]. The UN regulation 155 (R155) is on provisions concerning the approval of vehicles with regards to cybersecurity and a cybersecurity management system. R155 references the industry standard ISO/SAE 21434 "Road vehicles – Cybersecurity Engineering" which specifies engineering requirements for cybersecurity risk management system. Besides that the UN regulation 156 (R156) also comes with requirements on security and is focusing on software updates. In particular, R156 regulates the safety of software updates in "over-the-air" mode specifying, among others, requirements of integrity and authenticity of the update delivery mechanism. R155 and R156 are the first ever internationally harmonized and binding norms in this area, and constitute a severe challenge for manufacturers. In the European Union, for example, the new regulations became mandatory for all new vehicle types in July 2022 and will become mandatory for all new vehicles produced from July 2024.

In this direction, several solutions already address the challenge of *Firmware Over-The-Air* (FOTA), namely wirelessly updating the operating software of automotive Electronic Control Units (ECUs) without any physical intervention [6–8]. One of the main issues in FOTA is authentication, that is, assuring that a given firmware comes from the legitimate software originator, typically a tier-1 vendor, in its latest version. Generally, FOTA systems use digital signatures as a key technology to accomplish this task. Unfortunately, the potential emergence of quantum computers threatens the security of currently widespread digital signature schemes. By running Shor's algorithm [9] on large-scale quantum computers, an attacker can break RSA and ECC-based cryptosystems, and thus generate fake digital signatures in seconds. Although such powerful quantum computers are not available at the moment, quantum computing power keeps climbing [10]. For this reason, in 2016, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms. In 2022, NIST selected three quantum-resistant digital signature schemes [11]. In August 2023 NIST published draft standards for two of them [12,13]. However, it remains largely unexplored how the adoption of these standards affects the performance of automotive FOTA.

In this paper we evaluate the impact of two of the three standardized Post-Quantum Cryptography (PQC) signature algorithms, namely Crystals-Dilithium [14] (hereafter "Dilithium" for brevity) and Falcon [15], which are both based on the efficient structured-lattice mathematics. We leave out the third one, Sphincs+ [16], because it has considerably worse performance than Dilithium and Falcon. Indeed, Sphincs+ is not based on lattices, and NIST selected it only as a fallback option, in case of a major breakthrough in lattice cryptanalysis should occur [11]. We focus on the vehicle side, which has limited computing resources. For our benchmarks, we use an FPGA Xilinx ZCU106 evaluation board, which is usually employed for prototypes in the automotive field. In addition, we refer to Uptane [17], an open standard for automotive FOTA by the IEEE Industry Standards and Technology Organization (IEEE-ISTO), to design our reference FOTA system.

Our experiments show that, in a typical automotive FOTA system, where a vehicle mainly verifies digital signatures rather than generating them, Falcon is preferable to Dilithium, because the signature verification algorithm is faster. However, experiments also show that the choice of the quantum-resistant signature algorithm has little impact on performance, because the primary limiting factor consists in hashing of large bundles of firmware updates. Indeed, the size of such bundles may even reach 1 GiB in modern vehicles. This suggests us that hardware acceleration of the hashing component is more effective in improving FOTA performance than hardware acceleration of the digital signature functions. To corroborate this intuition, we design a hardware accelerator for the SHAKE function, which is the hash function used in both Dilithium and Falcon. Performance evaluation shows that SHAKE hardware acceleration is able to considerably improve the overall FOTA execution times.

The rest of the paper is organized as follows. Section 2 provides background on SHAKE and the SHA-3 family and compares the present work to relevant related work. Section 3 describes our Uptane-compliant reference FOTA system. Section 4 describes our experimental setup. Furthermore, the section presents the performance evaluation of the reference FOTA system with a software-only implementation of SHAKE, Dilithium, and Falcon. Section 5 describes our proposed hardware accelerator for SHAKE and presents the performance improvements that it brings about in the reference FOTA system. Finally, Section 6 draws the conclusions of this work.

## 2. Background and related work

This section is organized in three sub-sections: Section 2.1 introduces some background on SHA-3, Section 2.2 compares with related work about SHA-3 hardware accelerators, and Sections 2.3 compares with related work about performance evaluation of quantum-resistant cryptography in the automotive domain.

### 2.1. Background on SHA-3 functions

SHA-3 (Secure Hash Algorithm 3) is the latest member of the Secure Hash Algorithm family of standards, released by NIST in 2015 [18]. Despite being part of the same series of standards, SHA-3 differs internally from the MD5-like structure found in SHA-1 and SHA-2.

The SHA-3 family consists of four cryptographic hash functions (whose output length is fixed), and two eXtendable-Output Functions (XOFs) (whose output length may be arbitrary). The former category encompasses the SHA3-224, SHA3-256, SHA3-384, and SHA3-512 hash functions, which respectively produce outputs of 224, 256, 384, and 512 bits; the latter category includes the SHAKE128 and SHAKE256 functions, whose maximum security levels against collision attacks are respectively 128 and 256 bits.
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
<table><thead><tr><th>List of Acronyms</th><th></th></tr><tr><th>Acronym</th><th>Meaning</th></tr></thead><tbody><tr><td>AUTOSAR</td><td>AUTomotive Open System Architecture</td></tr><tr><td>AXI</td><td>Advanced eXtensible Interface</td></tr><tr><td>CAN</td><td>Controller Area Network</td></tr><tr><td>CLB</td><td>Configurable Logic Block</td></tr><tr><td>ECU</td><td>Electronic Control Unit</td></tr><tr><td>FF</td><td>Flip-Flop</td></tr><tr><td>FOTA</td><td>Firmware Over-The-Air</td></tr><tr><td>FPD</td><td>Full Power Domain</td></tr><tr><td>FPGA</td><td>Field-Programmable Gate Array</td></tr><tr><td>LUT</td><td>Look-Up Table</td></tr><tr><td>NTS</td><td>Network Time Security</td></tr><tr><td>PQC</td><td>Post-Quantum Cryptography</td></tr><tr><td>RLWE</td><td>Ring Learning With Errors</td></tr><tr><td>SHA-3</td><td>Secure Hash Algorithm 3</td></tr><tr><td>SHAKE</td><td>Secure Hash Algorithm/KEcck</td></tr><tr><td>TPM</td><td>Trusted Platform Module</td></tr><tr><td>UART</td><td>Universal Asynchronous Receiver-Transmitter</td></tr><tr><td>V2X</td><td>Vehicle-to-Everything</td></tr><tr><td>XOF</td><td>eXtendable-Output Function</td></tr></tbody></table>

<table><caption>**Table 1**
Parameters of the SHA-3 functions.</caption><thead><tr><th>List of Symbols</th><th></th></tr><tr><th>Symbol</th><th>Meaning</th></tr></thead><tbody><tr><td>N<sub>ecu</sub></td><td>Number of ECUs that must be updated by the FOTA procedure</td></tr><tr><td>t<sub>p</sub></td><td>Primary execution time, i.e., the time to execute the FOTA procedure on the primary ECU</td></tr><tr><td>t<sub>s</sub></td><td>Secondary execution time, i.e., the time to execute the FOTA procedure on all the secondary ECUs</td></tr><tr><td>t<sub>s</sub>(&mu;p)</td><td>Secondary execution time on a secondary microprocessor ECU</td></tr><tr><td>t<sub>s</sub>(&mu;c)</td><td>Secondary execution time on a secondary microcontroller ECU</td></tr></tbody></table>

<table><thead><tr><th>Algorithm</th><th>b</th><th>r</th><th>c</th><th>Output length (bits)</th></tr></thead><tbody><tr><td>SHA3-224</td><td>1600</td><td>1344</td><td>256</td><td>224</td></tr><tr><td>SHA3-256</td><td>1600</td><td>1088</td><td>512</td><td>256</td></tr><tr><td>SHA3-384</td><td>1600</td><td>832</td><td>768</td><td>384</td></tr><tr><td>SHA3-512</td><td>1600</td><td>576</td><td>1024</td><td>512</td></tr><tr><td>SHAKE128</td><td>1600</td><td>1344</td><td>256</td><td>Unlimited</td></tr><tr><td>SHAKE256</td><td>1600</td><td>1088</td><td>512</td><td>Unlimited</td></tr></tbody></table>

Each of the SHA-3 functions is based on the Ke'acc algorithm, which is a family of sponge functions; such functions are produced from an iterative approach called sponge construction [19,20], that employs three main components: a fixed-length permutation (or transformation) *f* that operates on a state of fixed number of bits *b* (*width*); a parameter *r* called *rate*; a padding rule named *pad*. The state is composed of *b* = *r* + *c* bits, where the value *c* is the capacity.

The analogy to a sponge is due to the fact this class of functions “absorb” an arbitrary number of input bits into the state, and “squeeze” an arbitrary number of output bits out of the state. Fig. 1 explains this procedure: initially, the input string of *N* bits is padded with a reversible padding rule *pad* and cut into blocks of *r* bits. Then, the state of the sponge function is initialized to zero, and the sponge construction proceeds in two phases, the absorbing and the squeezing phase. In the absorbing phase, each *r*-bit block of the input string (after padding and cutting) is first XORed with the first *r* bits of the state, and interleaved with applications of the *f* function. When all input blocks are processed, the sponge construction switches to the squeezing phase. In this phase, the first *r* bits of the state are returned as output blocks, interleaved with applications of the function *f*. The number of output blocks is chosen by the user.

The first *r* bits of the state corresponding to the *rate* are directly affected by the input blocks in the absorbing phase and are output during the squeezing phase. The last *c* bits of the state corresponding to the capacity are never directly affected by the input blocks and are never output during the squeezing phase. The parameters of the SHA-3 family algorithms and of the underlying Ke'acc sponge function are reported in Table 1.

In Ke'acc, the underlying function *f* is a permutation chosen in a set of seven Ke'acc-*f* permutations, denoted Ke'acc-*f*[b], where *b* ∈ {25, 50, 100, 200, 400, 800, 1600} is the width of the permutation (and of the state of the sponge function). As reported in Table 1, SHA-3 family employs Ke'acc-*f*[1600], a permutation function based on XOR, AND, and NOT operations, so ensuring convenient
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche
Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

[image] Production scientifique du CEA en libre accès

• Accueil

• Consulter

○ dépôts récents

○ par année

○ par type de publication

○ par domaine scientifique

○ par projet ANR

○ par projet européen

○ par journal

○ par direction / institut CEA

• Documentation - Tutoriels

○ Je publie : Quels sont mes droits ? (nov 2020)

○ tutoriel vidéo-Le dépôt de mon article scientifique (5 minutes)

○ Identifiant auteur IdHAL et CV

○ Alimenter son ORCID avec HAL

○ appliquer un embargo

○ Tous les tutoriels vidéo CNRS

○ Consulter les laboratoires connus de HAL
<figure><img src="image_6.png" /><figcaption>Fig. 1. Sponge construction for the SHA-3 functions.</figcaption></figure>

implementation in both software and hardware. Keccak-$f$[1600] permutations can be equivalently named as Keccak-$p$[1600, 24], where 1600 indicates the width of the state, 24 the number of iterations (named rounds) of the transformation, and the term Keccak-$p$ indicates the single iteration. The latter is composed of a sequence of five transformations (named step mappings) denoted by $\theta, \rho, \pi, \chi$, and $\iota$. Further information about step mappings can be found in the NIST standard [18].

## 2.2. Related work on hardware accelerators for SHA-3 functions

Different approaches can be used to implement hardware accelerators for SHA-3 hash functions and XOFs. Such functions all rely on the common Keccak sponge function. Consequently, it is straightforward to convert the implementation of one algorithm into the other or utilize the same hardware primitive, i.e., the Keccak, to implement all the functions. Hardware implementations of SHA-3 functions involve executing a certain number of rounds of the Keccak-$p$ transformation. As a result, different trade-offs in terms of latency, throughput, and area of the circuit can be obtained depending on the chosen number of rounds executed per clock cycle. Nannipieri et al. [21] presented some results of these trade-offs. The authors evaluate different hardware implementation strategies for the SHA-3 hash functions, with all the digest lengths. They claim that the multiple rounds per clock cycle approach can increase the throughput at the cost of higher area consumption and that the one-round-per-clock-cycle approach is the best one for area efficiency purposes. Authors in [22,23] propose a systematic design space exploration of Keccak hardware implementations. Specifically, the work in [22] targets generic applications, while the work in [23] focuses on lightweight implementations. In both papers, the authors delve into the implementation details of Keccak but do not address the algorithms at the highest level, namely SHA3 and SHAKE. There is no information provided on the implementation of padding rules and the physical interface. In contrast, works [24–26] present the implementation and integration of SHA3/SHAKE functions in lattice-based PQC schemes such as Crystals-Kyber and Dilithium. All of these works adopt the one-round-per-clock-cycle approach for their implementations. Fritzmann et al. [27] proposed a hardware accelerator for SHAKE functions, which is used to generate the polynomial coefficients involved in the computation of Ring Learning With Errors (RLWE) algorithms. The hardware architecture is one-round-per-clock-cycle, and it outperforms microcontroller implementations of SHAKE functions. Sravani et al. [28] proposed a two-round-per-clock-cycle architecture for multimodal biometric authentication. The article also provides a review of hardware implementations of SHA-3 functions, comparing architectures and results with respect to different figures of merit, including frequency, throughput, area, and efficiency. None of the above papers evaluated SHAKE/Keccak hardware accelerators within FOTA, which usually deals with quite large messages: up to 1 GiB for firmware images of full-resource ECUs.

## 2.3. Related work on quantum-resistant cryptography performance evaluation in automotive

Ravi et al. [29] compared classic cryptographic schemes (namely ECDH and ECDSA) to quantum-resistant ones (namely Crystals-Kyber and Dilithium) on an automotive-oriented computing board. The reference application considered by the authors is the secure in-vehicle communication via CAN bus. Therefore, their experimental results do not constitute a satisfactory benchmark for FOTA, which has radically different characteristics. In particular, the authors evaluated quantum-resistant signature verification over small messages, i.e., whose size is smaller than 1 KiB, which are typical in CAN communication. On the other hand, FOTA usually deals with large amounts of data, up to 1 GiB for firmware images of full-resource ECUs. Consequently, as we will show in Section 4, the time consumed for hash computation becomes a serious bottleneck for the overall FOTA system. Unlike [29], we do not experimentally compare quantum-resistant schemes with classic ones, because the latter are easily broken by quantum computers, so from this viewpoint they are not competing technologies. The quantum-resistant schemes are destined to replace the classic ones when they are no longer secure.

Fritzmann et al. [30] evaluated several quantum-resistant encryption schemes that participated to the NIST PQC standardization process, among which Crystals-Kyber, NTRU, and Saber. Again, these results do not constitute a satisfactory benchmark for FOTA,
• Aide

○ Pour toute question contacter hal@cea.fr

○ atelier one to one (IdHAL et publications)

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2024-11-18 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources

• Documentation

• FAQ

• API

• OAI-PMH

• AuréHAL

Informations

• À propos

• Données personnelles

• Mentions légales

• Accessibilité

• Conformité RGAA

Questions juridiques

• Je publie, quels sont mes droits ?
as the authors did not consider digital signature schemes at all. However, from their evaluation of Crystals-Kyber, it emerged that the SHAKE portion of the processing time has the strongest influence on the overall performance, taking around 19% for encryption and 12% for decryption. This suggests that SHAKE hardware accelerators can be beneficial not only for digital signatures but also for encryption.

Nannipieri et al. [31] evaluated the performance of the different cryptography primitives involved in Crystals-Kyber and Dilithium algorithms, and proposed a RISC-V instruction set extension for the number theoretic transform. The authors carried out a benchmark campaign on a CVA6 RISC-V processor implemented on FPGA, and they considered short messages (32 bytes), showing that around 50% of the clock cycles are taken by hashing in both key generation and message verification functions for Dilithium. Like for the Ravi et al.'s paper [29], their experimental results do not constitute a satisfactory benchmark for FOTA, which deal with much larger messages.

La Manna et al. [32] evaluated the performance of Falcon and Dilithium digital signature verification algorithms for protecting ECUs' firmware authenticity. They reported a slight advantage of Falcon over Dilithium as to the execution time, for medium–large messages (up to 5.9 MiB) and a much more noticeable advantage as to the digital signature size. In the software-only implementation, they noticed that SHAKE is the real performance bottleneck, but they did not propose nor evaluate a hardware accelerator for that.

Perazzo et al. [33] evaluated the performance of quantum-resistant attribute-based encryption to protect the confidentiality of firmware updates in FOTA, for intellectual property protection purposes. The problem of guaranteeing the confidentiality of firmware updates is important, but it can be addressed separately from the problem of guaranteeing their authenticity, for example by properly encrypting all the communication channels in an end-to-end fashion.

Bos et al. [34] investigate the application of Dilithium to protect the integrity and authenticity of over-the-air update packages and its integration in AUTOSAR using the NXP S32G vehicle network processor. It is interesting that, although the authors used a different reference FOTA system from us (compliant to AUTOSAR rather than Uptane), they conclude similarly, i.e., that the quantum-resistant signature algorithm has little impact on performance, because the bottleneck mostly depends on hashing of large bundles of firmware updates.

The works in [35,36] evaluate the impact of PQC migration on the automotive field. In [35], authors investigate the practical impact of migrating toward PQC secure boot flow on a vehicle network processor, while authors of [36] propose a set of PQC hardware accelerators (including SHAKE functions) for future generations of automotive hardware security modules.

Finally, we note that quantum-resistant hash-based signatures like XMSS, LMS, and SPHINCS+ are gaining some momentum in industry. Indeed they are attractive when hardware-accelerated hash functions are already available. For example, Infineon launched a TPM supporting XMSS signatures for FOTA applications,<fnref n="1" /> while IETF standardized XMSS [37] and LMS signatures [38]. However, hash-based signatures are quite large. More precisely, XMSS signatures take from 2500 to 2820 bytes with the IETF parameters, and from 4963 to 27 688 bytes with the XMSSMT variant [37]. A similar performance is saw with LMS signatures, which take from 1616 to 3652 bytes as reported by IETF [38]. Moreover, using a stateful signature and considering that in an Uptane system the primary ECU must sometimes produce signatures in addition to verify them (see Section 3), the same ECU should maintain a state. This is difficult for an embedded system like an automotive ECU is. We thus focused on stateless signatures like Dilithium and Falcon.

### 3. Reference FOTA system

Designing an automotive FOTA system is not an easy task, because it must take into consideration numerous threat agents and deal with many possible attacks. In order to give to our reference FOTA system more realism, we designed it to be compliant to Uptane<fnref n="2" /> by Kuppusamy et al. [7] originally presented at USENIX Security Symposium [39], which is an industry recognized IEEE-ISTO standard [17] and it is now incorporated in the Automotive Grade Linux operating system.<fnref n="3" /> Uptane has a broad applicability to a plethora of architectures, and it focuses on ground vehicles in general, thus including cars, light- or heavy-duty trucks, and motorcycles. Uptane provides a set of standard specifications to develop secure automotive FOTA systems that guarantee the authenticity, integrity, freshness, and coherence of the firmware updates, regardless of the source of the download. It retains the strongest level of security possible, even if a vehicle is attacked by a determined adversary. To achieve this, Uptane employs an in-depth defense approach that forces the attacker to compromise many different systems that are protected in diverse ways to successfully launch an attack. Uptane makes abundant use of digital signatures, but does not mandate a specific digital signature scheme to use. Therefore, quantum-resistant signatures like Dilithium or Falcon can be seamlessly used in Uptane without breaking the standard. We remark that our reference FOTA is based on Uptane and should not be considered in contrast or as an alternative to Uptane itself. In practice, we have defined the FOTA system from the Uptane specification retaining only those aspects that are relevant for performance evaluation.

Fig. 2 shows the architecture of our Uptane-compliant FOTA system. The *director repository* is a server responsible for managing the FOTA procedures for the vehicles. It is a sort of remote package manager, which informs vehicles about which software to install and resolves dependencies among software packages on behalf of the vehicles. It can also blacklist faulty software or customize software in case the vehicle owner paid for extra features. The *image repository* is a public cloud server that hosts the firmware images, which can be downloaded by the vehicles. The *time server* provides a trusted time reference to the vehicles. Inside a vehicle,

<footnote n="1">¹ https://embeddedcomputing.com/technology/security/software-security/infineon-launches-worlds-first-tpm-with-a-pqc-protected-firmware-update-mechanism.</footnote>

<footnote n="2">² https://uptane.github.io/.</footnote>

<footnote n="3">³ https://www.automotivelinux.org/.</footnote>
* <u>Loi pour une République numérique</u>

• <u>Stratégie de non-cession des droits</u>

• <u>SHERPA/RoMEO</u>

Portails

- <u>Portails institutionnels</u>

• <u>HAL</u>

• <u>HAL SHS</u>

• <u>HAL Thèses</u>

• <u>MédiHAL</u>

CCSD

- <u>CCSD</u>

• <u>Episciences</u>

• <u>Sciencesconf</u>
<figure><img src="image_7.png" /><figcaption>Fig. 2. Reference FOTA system. Red circuits represent primary ECUs, while black ones represent secondary ECUs.</figcaption></figure>

ECUs are classified as either primary or secondary. A *primary ECU* (ECU 1 in the figure) is in charge of contacting the director repository, downloading the necessary firmware images from the image repository, and distributing them to the *secondary ECUs* (ECUs 2, 3, 4, and 5 in the figure). Each vehicle must have at least one primary ECU.

Fig. 3 shows a sequence diagram of the protocol between the primary ECU and the time server, the director repository, and the image repository. Initially, the primary ECU retrieves a trusted time reference from the time server. The simplest way to do that is to perform a signed challenge-response protocol with the time server, in which the response message conveys the time reference and a nonce freshly generated by the primary ECU. More complex ways involves standard protocols for secure time reference retrieval, for example NTS [40]. In any case, the primary ECU is required to verify a digital signature on a timestamp. Then, the primary ECU sends a signed *vehicle version manifest* to the director repository, in which it declares general information about the vehicle and the current firmware configuration of itself and all the secondary ECUs. This requires generating a digital signature. Upon receiving the manifest, the director repository replies with a series of signed metadata, which inform the primary ECU about which firmware image download and install in which ECU. In particular, the director repository sends (i) a signed *timestamp metadata* file, which informs the primary ECU about which is the latest firmware configuration, (ii) a signed *snapshot metadata* file, which contains the detailed information about which firmware of which version has to run on which ECU, (iii) multiple signed *targets metadata* files, which contain information about the specific firmware images including their hashes, and (iv) a signed *root metadata* file, which is a public-key certificate for all the keys used to sign the previous metadata files. Please, refer to the Uptane standard for the actual contents of the vehicle version manifest and the various metadata files.

Of course, the vehicle firmware update could be partial, that is it could be necessary to update only a portion of the ECUs. Assuming that $N_{ecu}$ is the number of (primary or secondary) ECUs that must be updated, the primary ECU verifies $3 + N_{ecu}$ digital signatures, that is the signatures on the timestamp, the snapshot, and the root metadata files plus a signature on each targets metadata file of the firmware images to install. Finally, the primary ECU can request and download the $N_{ecu}$ firmware images from the image repository. Upon receiving the firmware images, the primary ECU recomputes the hashes of all the downloaded firmware images to check whether they match with those included in the relative targets metadata files. After this all, the primary ECU distributes each downloaded firmware image to the relative secondary ECUs.

Fig. 4 shows a sequence diagram of the protocol between the secondary ECU and the primary ECU. Initially, the primary ECU notifies the secondary ECU that a new firmware image is to install. The primary ECU gives a proof of that by sending the timestamp, snapshot, and root metadata files, and the (single) targets metadata file relative to the firmware image. The secondary ECU verifies
<figure><img src="image_8.png" /><figcaption>Fig. 3. Reference FOTA protocol between the primary ECU and the time server, the directory repository, and the image repository. Besides the time line of the primary ECU we indicate the necessary cryptographic operations (“s” = signature generation, “v” = signature verification, “h” = hash) that it performs. $N_{ecu}$ is the number of ECUs that must be updated.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 4. Uptane-compliant protocol between secondary ECU and primary ECU. Besides the time line of the secondary ECU we indicate the necessary cryptographic operations that it performs.</figcaption></figure>

4 digital signatures.<fnref n="4" /> Finally, the secondary ECU downloads the firmware image from the primary ECU. This requires the secondary ECU to recompute the hash of the downloaded firmware image, to check whether it matches with that included in the targets metadata file. If all these checks are successful, the secondary ECU can install the new firmware image and reboot.

## 4. Experimental setup and SW-only performance evaluation

In this section, we evaluate the performance of a plain software implementation of the cryptographic operations needed by primary and secondary ECUs to execute the Uptane-compliant protocols detailed in the previous section.

<footnote n="4">⁴ We refer here to the metadata verification method called “full verification” in the Uptane standard. An alternative method is “partial verification”, in which the secondary ECUs do not re-verify the metadata files, and instead they trust entirely the primary ECU. Partial verification is of course more efficient, but less secure in case of primary ECU compromise.</footnote>
<figure><img src="image_10.png" /><figcaption>Fig. 5. ARM-based architecture used for performance evaluation.</figcaption></figure>

## 4.1. Experimental setup

For our experiments, we assume that the time reference, the vehicle version manifest, and each metadata file in the reference FOTA system is signed with Falcon or Dilithium digital signatures, as they were selected for standardization by NIST in 2022 [11]. We consider three security levels for Dilithium, namely 128 bits, 192 bits, and 256 bits, corresponding respectively to “Dilithium Level 2”, “Dilithium Level 3”, and “Dilithium Level 5” in the Dilithium supporting documentation [41]. We consider two security levels for Falcon, namely 128 bits and 256 bits, corresponding respectively to “Falcon-512” and “Falcon-1024” in the Falcon supporting documentation [42]. These security levels express the computational complexity of signature forging attacks. We also assume that all the firmware image hashes are 512-bit digests computed with the SHAKE256 function, as it is standardized by NIST in 2015 as part of the SHA-3 hash family [43]. This is a reasonable choice, since Dilithium and Falcon signatures already use SHAKE internally. These digests give a security level of 256 bits against collision attacks. We also assume that the size of a single firmware image ranges from 100 KiB to 1 GiB. We found it difficult to precisely estimate the size of the average firmware image due to industry secrets protection. However, this range should reasonably encompass the large majority of cases, as confirmed by recent technical reports [44]. Regarding the size of the time reference, the vehicle version manifest, and the various metadata files, we assume that they vary inside a range from 1 KiB to 100 KiB (excluding the signatures). The size of such data greatly depends on the format in which they are represented, and Uptane does not mandate any particular format for them. However, the aforementioned range should be reasonable considering binary formats (e.g., DER), which are preferable to save traffic.

The evaluation has been carried out on a Xilinx ZCU106 board, which is typically used for automotive prototype applications. Such a board is equipped with an MPSoc ZynQ Ultrascale+, which includes a multicore ARM Cortex-A53 processor and an FPGA that can be used to implement other components like generic peripherals, processors, and microcontrollers. The ZynQ Ultrascale+ allows us to explore and benchmark both purely software implementations and implementations with hardware acceleration (achieved through the FPGA) of PQC algorithms for digital signature. We assume that primary ECUs mount powerful processors like those in the Cortex-A family. Therefore, we represent a primary ECU with two possible hardware architectures, both implemented through the ZCU106 board: an ARM-based architecture and a CVA6-based architecture. The ARM-based architecture (Fig. 5) mounts an ARM Cortex-A53 equipped with 32KB L1 cache and 1MB L2 cache, which is included inside the MPSoc ZynQ Ultrascale+. The ZynQ Ultrascale+ equips the interface for DDR4 memory (2 GiB of memory), and the UART peripheral to communicate with the host PC. The clock frequency of the ARM Cortex-A53 is 1.2 GHz. The CVA6-based architecture (Fig. 6) mounts a CVA6 RISC-V processor [45] implemented on the FPGA, equipped with 32 KiB L1 cache, and connected to 512 MiB of DDR4 memory and to standard peripherals (i.e. UART and JTAG) provided as Vivado hardware IPs. The clock frequency of the CPU and peripherals/interconnect is 100 MHz. The processor reaches 900 MHz of frequency on a 22 nm standard-cell technology. The decision to use a RISC-V processor is based on its promising prospects in the automotive industry, primarily due to its instruction set being free from licensing restrictions. Regarding the secondary ECUs, we assume that they mount real-time processors or 32-bit microcontrollers, like those in the Cortex-M family. Therefore, we represent a secondary ECU with a RISCY-based architecture (Fig. 7), again implemented through the ZCU106 board. Such an architecture consists in a 32-bit RISC-V RISCY processor (also named CV32E40P) implemented on the FPGA and running at 100 MHz [46]. We used the NIST round-3 reference software implementations of Dilithium [41] and Falcon [42], whose source code is available on the NIST website.<fnref n="5" /> To the best of our knowledge, no open-source optimized code for Dilithium and Falcon currently exists for ARM Cortex-A53 and RISC-V architectures. However, we can still mention some references to software implementations like the work in [47], which proposes a compact software implementation of Dilithium for ARM Cortex M3 and M4 microcontrollers; the works in [48,49], which present software implementations for ARMv8 architecture of Dilithium and Falcon respectively, but the source code is not publicly available.

<footnote n="5">⁵ https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submission.</footnote>
<figure><img src="image_11.png" /><figcaption>Fig. 6. CVA6-based architecture used for performance evaluation.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Fig. 7. RI5CY-based architecture used for performance evaluation.</figcaption></figure>

<table><caption>**Table 2**
SHAKE256 average computation time wrt firmware image size on the three considered architectures w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">FW img.</th><th colspan="6">SHAKE256 computation time [ms]</th></tr><tr><th colspan="2">ARM-based arch.</th><th colspan="2">CVA6-based arch.</th><th colspan="2">RI5CY-based arch.</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>100 KiB</td><td>1.43</td><td>0.25</td><td>86.47</td><td>8.12</td><td>3106.74</td><td>20.96</td></tr><tr><td>500 KiB</td><td>7.13</td><td>1.24</td><td>432.13</td><td>40.49</td><td>16,548.07</td><td>104.80</td></tr><tr><td>1 MiB</td><td>14.60</td><td>2.52</td><td>884.96</td><td>82.92</td><td>34,174.09</td><td>214.63</td></tr><tr><td>5 MiB</td><td>73.10</td><td>12.78</td><td>4142.50</td><td>414.28</td><td>174,287.85</td><td>1073.15</td></tr><tr><td>10 MiB</td><td>146.18</td><td>25.57</td><td>8848.53</td><td>828.56</td><td>-</td><td>-</td></tr><tr><td>100 MiB</td><td>1460.44</td><td>253.16</td><td>88,483.49</td><td>8289.25</td><td>-</td><td>-</td></tr><tr><td>1 GiB</td><td>14,954.28</td><td>2617.80</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

The code was compiled using the GCC compiler and the maximum optimization level (-O3 option). In order to get more statistically significant results, each reported value is the average of 100 independent repetitions of the experiment. Furthermore, in order to assure that repetitions are really independent, we generated a new random message for each hash computation and a new random key pair and a new random message for each signature generation and verification.

## 4.2. SW-only experimental results

Table 2 (“SW-only” columns<fnref n="6" />) reports the hash computation average times on the three architectures for firmware images ranging from 100 KiB to 1 GiB. The software implementation of SHAKE is the C reference implementation (contained in the “fips202.c” and “fips202.h” files within the NIST submission packages). The data relative to the CVA6-based architecture at 1 GiB message size are absent due to memory limitations of such a hardware architecture. The data relative to the RI5CY-based architecture at message size greater than 5 MiB are absent because it is unlikely that ECUs equipped with RI5CY microcontroller enjoy more than 5 MiB ROM capacity for their firmware.

<footnote n="6">⁶ We reported the experimental results of the present section together with those of the next section involving the SHAKE hardware accelerator, in order to ease the comparison and to quickly notice the hardware speedup.</footnote>
<table><caption>**Table 3**
Signature average verification time wrt message size on the ARM-based architecture w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Dilithium signature verification time on ARM [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>0.68</td><td>0.65</td><td>1.06</td><td>1.01</td><td>1.66</td><td>1.61</td></tr><tr><td>5 KiB</td><td>0.74</td><td>0.66</td><td>1.11</td><td>1.02</td><td>1.72</td><td>1.62</td></tr><tr><td>10 KiB</td><td>0.81</td><td>0.67</td><td>1.18</td><td>1.04</td><td>1.79</td><td>1.63</td></tr><tr><td>50 KiB</td><td>1.38</td><td>0.77</td><td>1.75</td><td>1.14</td><td>2.36</td><td>1.73</td></tr><tr><td>100 KiB</td><td>2.09</td><td>0.89</td><td>2.47</td><td>1.26</td><td>3.07</td><td>1.85</td></tr></tbody><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Falcon signature verification time on ARM [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>0.24</td><td>0.23</td><td>-</td><td>-</td><td>0.49</td><td>0.48</td></tr><tr><td>5 KiB</td><td>0.30</td><td>0.24</td><td>-</td><td>-</td><td>0.54</td><td>0.49</td></tr><tr><td>10 KiB</td><td>0.37</td><td>0.26</td><td>-</td><td>-</td><td>0.62</td><td>0.50</td></tr><tr><td>50 KiB</td><td>0.94</td><td>0.35</td><td>-</td><td>-</td><td>1.19</td><td>0.60</td></tr><tr><td>100 KiB</td><td>1.65</td><td>0.48</td><td>-</td><td>-</td><td>1.90</td><td>0.72</td></tr></tbody></table>

<table><caption>**Table 4**
Signature average verification time wrt message size on the CVA6-based architecture w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Dilithium signature verification time on CVA6 [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>22.59</td><td>20.38</td><td>37.16</td><td>34.69</td><td>61.61</td><td>59.40</td></tr><tr><td>5 KiB</td><td>26.06</td><td>20.86</td><td>40.59</td><td>35.14</td><td>65.11</td><td>59.86</td></tr><tr><td>10 KiB</td><td>30.27</td><td>21.42</td><td>44.72</td><td>35.70</td><td>69.21</td><td>60.41</td></tr><tr><td>50 KiB</td><td>63.51</td><td>25.70</td><td>77.94</td><td>39.91</td><td>102.30</td><td>65.56</td></tr><tr><td>100 KiB</td><td>104.85</td><td>30.76</td><td>119.25</td><td>44.96</td><td>143.60</td><td>69.53</td></tr></tbody><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Falcon signature verification time on CVA6 [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>6.94</td><td>5.33</td><td>-</td><td>-</td><td>13.81</td><td>11.26</td></tr><tr><td>5 KiB</td><td>10.03</td><td>5.71</td><td>-</td><td>-</td><td>16.95</td><td>11.64</td></tr><tr><td>10 KiB</td><td>14.11</td><td>6.19</td><td>-</td><td>-</td><td>20.89</td><td>12.12</td></tr><tr><td>50 KiB</td><td>45.29</td><td>10.10</td><td>-</td><td>-</td><td>52.01</td><td>16.06</td></tr><tr><td>100 KiB</td><td>83.99</td><td>15.06</td><td>-</td><td>-</td><td>90.71</td><td>21.04</td></tr></tbody></table>

<table><caption>**Table 5**
Signature average verification time wrt message size on the RI5CY-based architecture w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Dilithium signature verification time on RI5CY [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>454.07</td><td>405.34</td><td>741.76</td><td>693.02</td><td>1250.99</td><td>1202.26</td></tr><tr><td>5 KiB</td><td>551.22</td><td>406.17</td><td>838.94</td><td>693.89</td><td>1348.23</td><td>1203.18</td></tr><tr><td>10 KiB</td><td>674.10</td><td>407.22</td><td>961.83</td><td>694.95</td><td>1471.18</td><td>1204.30</td></tr><tr><td>50 KiB</td><td>1648.76</td><td>415.61</td><td>1936.48</td><td>703.33</td><td>7503.02</td><td>6269.87</td></tr><tr><td>100 KiB</td><td>3511.86</td><td>426.09</td><td>4066.62</td><td>980.84</td><td>15,831.38</td><td>12,745.60</td></tr></tbody><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Falcon signature verification time on RI5CY [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>133.34</td><td>84.61</td><td>-</td><td>-</td><td>226.18</td><td>177.45</td></tr><tr><td>5 KiB</td><td>230.50</td><td>85.45</td><td>-</td><td>-</td><td>323.34</td><td>178.29</td></tr><tr><td>10 KiB</td><td>353.38</td><td>86.50</td><td>-</td><td>-</td><td>446.22</td><td>179.34</td></tr><tr><td>50 KiB</td><td>1328.04</td><td>94.88</td><td>-</td><td>-</td><td>1420.88</td><td>187.72</td></tr><tr><td>100 KiB</td><td>3191.14</td><td>105.36</td><td>-</td><td>-</td><td>3283.98</td><td>198.20</td></tr></tbody></table>

**Discussion.** We can notice that the ARM-based architecture has the best performance. The ARM processor takes only 15 s to compute the hash of a 1 GiB sized firmware image. The CVA6-based architecture is sensibly slower, as it takes more than a minute to compute the hash of a 100 MiB sized firmware image. Of course, a hardware accelerator would decrease sensibly this processing time, as we will see in the next section. Finally, the RI5CY-based architecture takes almost 3 min to compute the hash of a 5 MiB sized firmware image. Therefore, it is highly preferable to implement some hardware acceleration for hash computation on ECUs mounting this type of microcontroller.

Tables 3, 4, and 5 ("SW-only" columns) report the signature verification average times of Dilithium and Falcon for messages ranging from 1 KiB to 100 KiB, respectively on the ARM-based, the CVA6-based, and the RI5CY-based architecture. Here, a message can be a time reference, a vehicle version manifest, or a metadata file. In these tables, we do not distinguish the time to hash the message from the time to verify the signature on such a hash. This fine-grained measurement would fall outside our general objective of a system-oriented performance evaluation.
<table><caption>**Table 6**
Signature average generation time wrt message size on the ARM-based architecture w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Dilithium signature generation time on ARM [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>2.61</td><td>2.57</td><td>4.03</td><td>3.99</td><td>6.06</td><td>6.01</td></tr><tr><td>5 KiB</td><td>2.46</td><td>2.37</td><td>4.40</td><td>4.31</td><td>5.57</td><td>5.47</td></tr><tr><td>10 KiB</td><td>2.41</td><td>2.26</td><td>3.88</td><td>3.73</td><td>6.37</td><td>6.21</td></tr><tr><td>50 KiB</td><td>3.20</td><td>2.58</td><td>6.05</td><td>5.41</td><td>6.41</td><td>5.78</td></tr><tr><td>100 KiB</td><td>3.93</td><td>2.73</td><td>5.98</td><td>4.77</td><td>7.73</td><td>6.51</td></tr></tbody><thead><tr><th rowspan="2">Msg. size</th><th colspan="6">Falcon signature generation time on ARM [ms]</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>18.93</td><td>18.92</td><td>-</td><td>-</td><td>41.34</td><td>41.33</td></tr><tr><td>5 KiB</td><td>18.99</td><td>18.93</td><td>-</td><td>-</td><td>41.40</td><td>41.35</td></tr><tr><td>10 KiB</td><td>19.03</td><td>18.92</td><td>-</td><td>-</td><td>41.48</td><td>41.36</td></tr><tr><td>50 KiB</td><td>19.61</td><td>19.02</td><td>-</td><td>-</td><td>42.00</td><td>41.41</td></tr><tr><td>100 KiB</td><td>20.34</td><td>19.17</td><td>-</td><td>-</td><td>42.74</td><td>41.56</td></tr></tbody></table>

<table><caption>**Table 7**
Signature average generation time wrt message size on the CVA6-based architecture w/wo hardware acceleration.</caption><thead><tr><th rowspan="3">Msg. size</th><th colspan="6">Dilithium signature generation time on CVA6 [ms]</th></tr><tr><th colspan="2">128-bit security</th><th colspan="2">192-bit security</th><th colspan="2">256-bit security</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>73.39</td><td>65.84</td><td>116.86</td><td>112.98</td><td>183.71</td><td>179.32</td></tr><tr><td>5 KiB</td><td>71.63</td><td>65.19</td><td>129.04</td><td>121.75</td><td>171.66</td><td>164.60</td></tr><tr><td>10 KiB</td><td>72.63</td><td>62.56</td><td>135.46</td><td>106.66</td><td>196.72</td><td>185.22</td></tr><tr><td>50 KiB</td><td>113.58</td><td>72.71</td><td>195.89</td><td>137.95</td><td>246.44</td><td>174.86</td></tr><tr><td>100 KiB</td><td>157.32</td><td>78.09</td><td>217.34</td><td>152.95</td><td>276.65</td><td>196.37</td></tr></tbody><thead><tr><th rowspan="2">Msg. size</th><th colspan="6">Falcon signature generation time on CVA6 [ms]</th></tr><tr><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th><th>SW-only</th><th>SW/HW</th></tr></thead><tbody><tr><td>1 KiB</td><td>489.68</td><td>482.13</td><td>-</td><td>-</td><td>1082.10</td><td>1077.71</td></tr><tr><td>5 KiB</td><td>492.50</td><td>486.06</td><td>-</td><td>-</td><td>1085.37</td><td>1078.31</td></tr><tr><td>10 KiB</td><td>496.32</td><td>486.25</td><td>-</td><td>-</td><td>1088.42</td><td>1076.92</td></tr><tr><td>50 KiB</td><td>522.32</td><td>481.45</td><td>-</td><td>-</td><td>1114.68</td><td>1043.10</td></tr><tr><td>100 KiB</td><td>555.08</td><td>475.85</td><td>-</td><td>-</td><td>1147.37</td><td>1067.09</td></tr></tbody></table>

**Discussion.** We can notice that, for each hardware architecture, the signature verification time is far less compared to the hash computation time of big (≥10 MiB) firmware images. As expected, the signature verification time grows as the hardware architecture becomes less powerful, from ARM-based to CVA6-based to RI5CY-based. For each platform, Falcon signatures are quicker to verify than Dilithium ones. This suggests us that Falcon signatures are preferred for quantum-resistant FOTA procedures. As expected, for both Dilithium and Falcon the signature verification time grows with the security level. With small messages (1 KiB) the signature verification times at 256-bit security are more than twice the ones at 128-bit security. However, this difference becomes less and less pronounced as the size of the message grows. This is because both Dilithium and Falcon use SHAKE functions internally to hash the message and, in case of Dilithium, produce pseudorandom numbers. As the message grows towards 100 KiB, the internal SHAKE computation becomes rapidly the bottleneck of the whole signature verification. Of course, this means that the hardware acceleration of SHAKE will improve the performance of the signature verification too; the impact of hashing functions within Dilithium and Falcon is highlighted in a benchmark analysis<fnref n="7" /> carried out by the developers of the PQM4 library on ARM Cortex M4 processor.

Tables 6 and 7 (“SW-only” columns) report the signature generation average times of Dilithium and Falcon for messages ranging from 1 KiB to 100 KiB, respectively on the ARM-based and the CVA6-based architecture. We did not perform similar experiments on the RI5CY-based architecture because only primary ECUs generate signatures in Uptane-compliant FOTA systems.

**Discussion.** We can notice that, for each hardware architecture, the signature generation time is far less compared to the hash computation time of big firmware images. For the signature generation, Dilithium is several times faster than Falcon. This could suggest to use different quantum-resistant signatures for different data: Dilithium for the vehicle version manifest, which is signed by the vehicle (in particular by the primary ECU), and Falcon for all the other data including the time reference and the various metadata files, which are signed by full-resource servers. However, if using heterogeneous signatures is not possible, Falcon is still preferred because signature verification is more prevalent compared to signature generation in FOTA. Like we experienced for the signature verification, for both Dilithium and Falcon the signature generation time grows with the security level, and such a difference becomes less and less pronounced as the message grows. Even here, this is because both Dilithium and Falcon use SHAKE functions internally, therefore the hardware acceleration of SHAKE will improve the performance of the signature generation too, as we will see in Section 5.

<footnote n="7">⁷ https://github.com/mupq/pqm4/blob/master/benchmarks.md#hashing-evaluation.</footnote>
### 4.3. Complete firmware update: a worst case scenario

In this section we consider a case study to get an overall quantitative perception about how hashing impacts on automotive FOTA from the execution time perspective.

We consider a vehicle composed of 100 ECUs where 10 are microprocessors ($\mu p$) and the remaining 90 are microcontrollers ($\mu c$). Microprocessors are ARM-based architectures whereas microcontrollers are RI5CY-based architectures. To fix ideas, we assume that a microprocessor image size is about 1 GiB, a microcontroller image is 500 KiB, and the sizes of the time reference, the vehicle version manifest, and the various metadata files are 100 KiB. As a worst case, we consider the *complete update scenario*, i.e., a scenario in which all the ECUs of the car are updated by a single primary ECU, thus $N_{ecu} = 100$. As a performance indicator, we evaluate the execution time $t$ necessary for complete update operation. Such a performance indicator is given by two addends, namely, the time to execute the protocol in Fig. 3 on the primary ECU (*primary execution time*, $t_p$) and the time to execute the protocol in Fig. 4 on all the secondary ECUs (*secondary execution time*, $t_s$). For simplicity we assume that secondary ECUs operate in parallel, neglecting any in-vehicle networking effect. As secondary ECUs may be either microprocessors or microcontrollers we will consider the largest execution time, that is, $t_s = \max(t_s(\mu p), t_s(\mu c))$, where $t_s(\mu p)$ is the execution time on a secondary microprocessor ECU and $t_s(\mu c)$ is the execution time on a secondary microcontroller ECU.

In order to evaluate the $t_p$ and $t_s$ we refer to Figs. 3 and 4. With reference to Fig. 3, a primary ECU has to generate in total one signature on vehicle version manifest, $4 + N_{ecu}$ verifications of signatures on time reference and various metadata files, and the computation of $N_{ecu}$ hashes on firmware images, 10 of which have 1 GiB size and 90 have 500 KiB size. In contrast, a secondary ECU has to perform in total 4 verifications of signatures on various metadata files and just one hash of the firmware image to be installed. As to the last step, the image will be 1 GiB, if the secondary ECU is a microprocessor; 500 KiB, if the secondary ECU is a microcontroller.

In case of Falcon with 128-bit security, the primary execution time $t_p = 150.40$ s, 99.87% of which is spent in hashing. The secondary execution time on a microprocessor (ARM-based) is $t_s(\mu p) = 14.96$ s, 99.96% of which spent in hashing. The secondary execution time on a microcontroller (RI5CY-based) is $t_s(\mu c) = 29.31$ s, 56.45% of which spent in hashing. As $t_s(\mu c) > t_s(\mu p)$, then $t = t_n + t_s(\mu c) = 179.69$ s.

In case of Falcon with 256-bit security, the primary execution time $t_p = 150.43$ s, 99.84% of which is spent in hashing. The secondary execution time on a microprocessor (ARM-based) is $t_s(\mu p) = 14.96$ s, 99.95% of which spent in hashing. The secondary execution time on a microcontroller (RI5CY-based) is $t_s(\mu c) = 29.68$ s, 55.75% of which spent in hashing. As $t_s(\mu c) > t_s(\mu p)$, then $t = 180.11$ s. This means that, independently from the level of security, a complete firmware update takes at least three minutes of cryptographic operations, without counting the communication and installation times. Considering that firmware updates are typically executed when the vehicle is steady and the engine is turned off, waiting three minutes to start the engine could be an annoying disservice for the driver.

From these experiments, it emerges that the most of the execution time is spent in computing the hash of images. This of course is true not only for post-quantum FOTA applications but also for pre-quantum ones, using classic signatures like ECDSA. In any case, we expect that a hardware acceleration of the SHAKE256 function will introduce a relevant speedup improvement. More in details, on a microprocessor, regardless it is primary or secondary ECU, hash computation time is the predominant component of the execution time as the former is larger than 99% of the latter. Therefore, we expect that the speedup will be almost the same as the speedup of the accelerated SHAKE256 function with respect to the software one. In contrast, on a microcontroller, hashing is still a relevant component of but it is not the predominant anymore. Actually hashing accounts for the 55%-57% of the execution time while signature verification for the 43%-45%. However, we remind that both Dilithium and Falcon use SHAKE functions internally, thus we expect that SHAKE acceleration will introduce speedup benefits also during signature verification.

For the sake of brevity, we have just considered a complete update scenario with ARM-based and RI5CY-based architectures, and the Falcon algorithm. However, data are available for the reader to consider other scenarios involving the CVA6 microprocessor and the Dilithium algorithm.

## 5. SHAKE accelerator and SW/HW performance evaluation

In this section, we provide a detailed description of the proposed hardware accelerator for the SHAKE functions and its integration in the architectures presented in Section 4. Then, we present the results of our performance evaluation of the hardware accelerator.

### 5.1. SHAKE accelerator

We propose a one-round-per-clock-cycle hardware accelerator able to accelerate both SHAKE128 and SHAKE256 algorithms. Fig. 8 depicts its architecture. The hardware accelerator includes an AXI4 Memory Mapped Slave interface with a 32/64-bit data bus, a 1344-bit shift register for input/output from/to the AXI Master interface, and dedicated registers for configuration and status. The SHAKE core (reported in the blue box of Fig. 8) contains the hardware logic that actually executes the SHAKE algorithm following the sponge construction described in Section 2.1. In the absorbing phase, the hardware padder processes the input message that is held in the Data register. This message is XORed with either the all-zero initial state (when it is the first block of the message) or the output of the Keccak function. The Keccak function is implemented using a 1600-bit state register and combinational logic to perform the five transformations. The subsequent squeezing phase involves truncating the state register and executing the Keccak function until the required number of output blocks has been produced, if multiple output blocks are needed. The Data register is
<figure><img src="image_13.png" /><figcaption>**Fig. 8.** On the left side the building blocks of the hardware accelerator for Keccak-p[1600,24] function. On the right side the architecture of the hardware accelerator for SHAKE128/256 functions.</figcaption></figure>

<figure><img src="image_14.png" /><figcaption>**Fig. 9.** ARM-based HW architecture used for performance evaluation.</figcaption></figure>

<table><caption>**Table 8**

Synthesis results on the Xilinx ZCU106 FPGA of the hardware accelerator for SHAKE functions.</caption><thead><tr><td>Accelerator</td><td>Frequency</td><td>CLB LUTs</td><td>CLB regs</td></tr></thead><tbody><tr><td>SHAKE</td><td>333 MHz</td><td>6172</td><td>3327</td></tr></tbody></table>

reused to send data to the AXI4 Master interface. Table 8 shows the synthesis results for the proposed hardware accelerator on the FPGA of the Xilinx ZCU106 board. Those results include both the resources for the AXI4 slave interface and the various configuration, data, and status registers. They reflect the hardware depicted in the left part of Fig. 6. Considering the resource consumption of the SHAKE core only (right side of Fig. 6), which are 5812 CLB LUTs and 1608 FFs, they are significantly lower with respect to work in [25], and in line with works in [24,26].

The hardware accelerator for SHAKE functions has been integrated into the three architectures considered for the benchmark campaign, as reported in Figs. 9–11. In the case of the ARM-based architecture, the accelerator is connected to the ARM-A53 processor through a 64-bit AXI4 Master Full Power Domain (FPD) interface that is implemented on the FPGA. Both the interface and the accelerator run at 300 MHz, which is the maximum frequency of the AXI4 Master interface. In both the CVA6-based and RI5CY-based systems the hardware accelerator has been connected to the CPUs through the AXI4 interconnect, in the former case using a 64-bit interface and in the latter with a 32-bit one.

As for the software, we modified the NIST round-3 reference implementations of Dilithium and Falcon to internally use the hardware-implemented SHAKE128 and SHAKE256 functions in place of the software ones. In particular, Dilithium and Falcon use the hardware SHAKE256 function to internally hash the message, and Dilithium uses the hardware SHAKE128 function to generate pseudo-random numbers. The code was compiled using the GCC compiler and the maximum optimization level (-O3 option).

## 5.2. SW/HW experimental results

Table 2 (“SW/HW” columns) reports the hash computation average times on the three architectures for firmware images ranging from 100 KiB to 1 GiB, with the hardware accelerator for SHAKE functions.
<figure><img src="image_15.png" /><figcaption>Fig. 10. CVA6-based HW architecture used for performance evaluation.</figcaption></figure>

<figure><img src="image_16.png" /><figcaption>Fig. 11. RI5CY-based HW architecture used for performance evaluation.</figcaption></figure>

**Discussion.** We can notice that the SHAKE hardware acceleration sensibly improves the hashing performance in all the three architectures and for all the considered sizes of the firmware images. The speedup is bigger when the considered hardware architecture is less powerful. Indeed, to hash a 100 KiB sized firmware image, the hardware speedup is ×5.72 for the ARM-based architecture, ×10.65 for the CVA6-architecture, and ×148.22 for the RI5CY-based architecture. On the other hand, for each architecture the speedup is roughly constant with respect to the size of the firmware image.

Tables 3, 4, and 5 (“SW/HW” columns) report the signature verification average times of Dilithium and Falcon for messages ranging from 1 KiB to 100 KiB, respectively on the ARM-based, the CVA6-based, and the RI5CY-based architecture, with the hardware accelerator for SHAKE functions.

**Discussion.** We can notice that the SHAKE hardware acceleration improves the signature verification performance too. As we said before, this is because both Dilithium and Falcon use SHAKE functions internally to hash the message and, in case of Dilithium, produce pseudorandom numbers. Of course, we obtain less pronounced speedups with respect to hash computation, because SHAKE constitutes only a part of the signature verification. In general, the speedup grows with the prevalence of the SHAKE function on the total processing time of the verification. This explains why the speedup grows with the size of the message and decreases with the security level. Indeed, the greater speedups are with 100 KiB sized messages and 128-bit security, for both Dilithium and Falcon and for all the hardware architectures. More precisely, the best speedups are ×2.35 for Dilithium and ×3.44 for Falcon on ARM-based architecture, ×3.41 for Dilithium and ×5.58 for Falcon on CVA6-based architecture, and ×8.25 for Dilithium and ×30.29 for Falcon on RI5CY-based architecture. Speedups are also greater for Falcon than for Dilithium for the same reason: since Falcon verification is quicker than Dilithium, its SHAKE part is more prevalent on the whole operation, so it benefits more from the SHAKE hardware acceleration.

Tables 6 and 7 (“SW/HW” columns) report the signature generation average times of Dilithium and Falcon for messages ranging from 1 KiB to 100 KiB, respectively on the ARM-based and the CVA6-based architecture, with the hardware accelerator for SHAKE functions.

**Discussion.** We can notice that the speedups are in general hardly perceptible for the signature generation, for both Dilithium and Falcon and for all the hardware architectures. For the same reason explained for signature verification, the speedup grows with the size of the message and decreases with the security level. Indeed, the greater speedups are with 100 KiB sized messages and 128-bit security, for both Dilithium and Falcon and for all the hardware architectures. More precisely, the best speedups are ×1.44 for Dilithium and ×1.06 for Falcon on ARM-based architecture, and ×2.01 for Dilithium and ×1.17 for Falcon on CVA6-based architecture. In contrast to the verification, the speedups here are greater for Dilithium than for Falcon since Dilithium verification is quicker, thus its SHAKE part is more prevalent on the whole operation.
## 5.3. Impact of SHAKE hardware acceleration on the complete update scenario

Let us now evaluate the speedup introduced in the complete vehicle update scenario discussed in Section 4.2.

In case of Falcon with 128-bit security with hardware acceleration of SHAKE, the primary execution time is $t_p = 26.36$ s, of which the 99.74% is spent in hashing, with a speedup equal to ×5.71. The secondary execution time on a microprocessor (ARM-based) is $t_s(\mu p) = 2.62$ s, 99.93% of which is spent in hashing, for a speedup of ×5.71. The secondary execution time on a microcontroller (RI5CY-based) is $t_s(\mu c) = 0.53$ s, 19.91% of which spent in hashing, for a speedup equal to ×55.70. As $t_s(\mu p) > t_s(\mu c)$, then $t = 28.98$ s, for an overall speedup equal to ×6.20. It is worthwhile to observe that hardware acceleration makes the execution time on a secondary microcontroller ECU smaller than that on a secondary microprocessor ECU. This depends on the two facts. First, hardware acceleration introduces a large speedup both in digital signature verification (×30.29) and hash computation (×148.22) on a RI5CY-based architecture. Second, a secondary ECU hashes firmware images of at most 500 KiB.

In case of Falcon with 256-bit security with hardware acceleration of SHAKE, the primary execution time $t = 26.41$ s, of which the 99.56% is spent in hashing, with a speedup equal to ×5.70. The secondary execution time on a microprocessor (ARM-based) is $t_s(\mu p) = 2.62$ s, 99.89% of which is spent in hashing, for a speedup of ×5.71. The secondary execution time on a microcontroller (RI5CY-based) is $t_s(\mu c) = 0.90$ s, 11.68% of which spent in hashing, for a speedup equal to ×33.07. As $t_s(\mu p) > t_s(\mu c)$, then $t = 29.03$ s, for an overall speedup equal to ×6.20. Again, hardware acceleration makes the execution time on a secondary microcontroller ECU smaller than that on a secondary microprocessor ECU.

Finally, we observe that moving from Falcon with 128-bit security to Falcon with 256-bit security causes a 0.2% increment in the execution time both with and without hardware acceleration of SHAKE. This is not surprising, given the prevalence of hashing on the execution time. Therefore, given such a negligible impact on the overall execution time, it is advisable to use 256-bit security for its higher security level.

## 6. Conclusions and future work

In this paper we experimentally evaluated the impact of two of the three PQC standardized signature algorithms, namely Dilithium [14] and Falcon [15], on automotive FOTA systems. Our experiments showed that, in a typical automotive FOTA system, where a vehicle mainly verifies digital signatures rather than generating them, Falcon is preferable to Dilithium, because the signature verification algorithm is faster. However, experiments also show that the choice of the quantum-resistant signature algorithm has little impact on performance, because the primary limiting factor consists in hashing of large bundles of firmware updates. This led us to conclude that hardware acceleration of the hashing component is more effective in improving FOTA performance than hardware acceleration of the digital signature functions. To corroborate this conclusion, we designed a hardware accelerator for the SHAKE function, the hash function used in both Dilithium and Falcon. Performance evaluation showed that a mixed software-hardware approach with hardware acceleration of SHAKE makes it possible to achieve speedup improvements of up to two orders of magnitude according to the underlying computing platform.

In addition to over-the-air software updates, there are further application areas in the automotive sector that will be influenced by post-quantum security, e.g., secure charging of electric vehicles [50] and Vehicle-to-Everything (V2X) [51,52] secure communication. We plan to measure the impact of post-quantum security in these areas.

## Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

## Data availability

Data will be made available on request.

## Acknowledgments

This work has been partially financed by the Italian Ministry of Education and Research (MUR), within the framework of the Forelab project (Departments of Excellence), and within the PRIN-2022 project "Future generation security for smart and connected cars" (FuSeCar) under Grant 2022W3EPEP (CUP E53D23008210006); by the European Union within the Horizon2020 Project "European Processor Initiative—Specific Grant Agreement 2" (EPI-SGA2) under Grant 101036168, and within the EuroHPC "TEXTAROSSA" project under Grant 956831; and by the European Union–NextGenerationEU National Sustainable Mobility Center CN00000023, Italian Ministry of University and Research Decree n. 1033—17/06/2022 Spoke 10.
## References

[1] NXP. Whitepaper NXP. 2018, https://www.nxp.com/docs/en/white-paper/AUTOGWDEVWPUS.pdf.

[2] Charette RN. This car runs on code. IEEE Spectr 2009;46(3):1-6.

[3] Odat HA, Ganesan S. Firmware over the air for automotive, fotomotive. In: IEEE international conference on electro/information technology. 2014, p. 130-9. http://dx.doi.org/10.1109/EIT.2014.6871751.

[4] UNECE. UN regulation no. 155 - uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system. 2021, https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security. [Accessed 17 July 2023].

[5] UNECE. UN regulation no. 156 - software update and software update management system. 2021, https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update. [Accessed 17 July 2023].

[6] Steger M, Boano CA, Niedermayr T, Karner M, Hillebrand J, Roemer K, Rom W. An efficient and secure automotive wireless software update framework. IEEE Trans Ind Inf 2018;14(5):2181-93. http://dx.doi.org/10.1109/TII.2017.2776250.

[7] Kuppusamy TK, DeLong LA, Cappos J. Uptane: Security and customizability of software updates for vehicles. IEEE Veh Technol Mag 2018;13(1):66-73. http://dx.doi.org/10.1109/MVT.2017.2778751.

[8] La Manna M, Treccozi L, Perazzo P, Saponara S, Dini G. Performance evaluation of attribute-based encryption in automotive embedded platform for secure software over-the-air update. Sensors 2021;21(2). http://dx.doi.org/10.3390/s21020515, URL https://www.mdpi.com/1424-8220/21/2/515.

[9] Shor P. Algorithms for quantum computation: discrete logarithms and factoring. In: Proceedings 35th annual symposium on foundations of computer science. 1994, p. 124-34. http://dx.doi.org/10.1109/SFCS.1994.365700.

[10] Yang Z, Zolanvari M, Jain R. A survey of important issues in quantum computing and communications. IEEE Commun Surv Tutor 2023;25(2):1059-94. http://dx.doi.org/10.1109/COMST.2023.3254481.

[11] Alagic G, Apon D, Cooper D, Dang Q, Dang T, Kelsey J, Lichtinger J, Miller C, Moody D, Peralta R, et al. Status report on the third round of the NIST post-quantum cryptography standardization process. US Department of Commerce, NIST; 2022.

[12] National Institute of Standards and Technology. Module-lattice-based digital signature standard. Tech. rep. federal information processing standards publications (FIPS) NIST FIPS 204 ipd, Washington, D.C.: U.S. Department of Commerce; 2023, http://dx.doi.org/10.6028/NIST.FIPS.204.ipd.

[13] National Institute of Standards and Technology. Stateless hash-based digital signature standard. Tech. rep. federal information processing standards publications (FIPS) NIST FIPS 205 ipd, Washington, D.C.: U.S. Department of Commerce; 2023, http://dx.doi.org/10.6028/NIST.FIPS.205.ipd.

[14] Ducas L, Kiltz E, Lepoint T, Lyubashhevsky V, Schwabe P, Seiler G, Stehlé D. CRYSTALS-dilithium: A lattice-based digital signature scheme. IACR Trans Cryptogr Hardw Embed Syst 2018;2018(1):238-68. http://dx.doi.org/10.13154/tches.v2018.i1.238-268, URL https://tches.iacr.org/index.php/TCHES/article/view/839.

[15] Fouque P-A, Hoffstein J, Kirchner P, Lyubashhevsky V, Pornin T, Prest T, Ricosset T, Seiler G, Whyte W, Zhang Z. Falcon: Fast-Fourier lattice-based compact signatures over NTRU. In: Submission to the NIST's post-quantum cryptography standardization process. 2018.

[16] Bernstein DJ, Hülsing A, Kölbl S, Niederhagen R, Rijneveld J, Schwabe P. The SPHINCS+ signature framework. In: Proceedings of the 2019 ACM SIGSAC conference on computer and communications security. CCS '19, New York, NY, USA: Association for Computing Machinery; 2019, p. 2129-46. http://dx.doi.org/10.1145/3319535.3363229.

[17] IEEE-ISTO. Uptane standard for design and implementation 2.1.0. 2023, https://uptane.org/docs/2.1.0/standard/uptane-standard [Online; Accessed 20 April 2024].

[18] Dworkin MJ. SHA-3 standard: permutation-based hash and extendable-output functions. Tech. rep. 202, Gaithersburg, MD: Federal Inf. Process. Stds. (NIST FIPS). National Institute of Standards and Technology; 2015.

[19] Bertoni G, Daemen J, Hoffert S, Peeters M, Assche1 GV, Keer RV. Keccak specifications summary. 2023, https://keccak.team/keccak_specsumary.html. [Accessed 21 July 2023].

[20] Bertoni G, Daemen J, Peeters M, Aasche GV. Cryptographic sponge functions. Tech. rep., STMicroelectronics and NXP Semiconductors; 2011.

[21] Nannipieri P, Bertolucci M, Baldanzi L, Crocetti L, Di Matteo S, Falaschi F, Fanucci L, Saponara S. SHA2 and SHA-3 accelerator design in a 7 nm technology within the European processor initiative. Microprocess Microsyst 2021;87:103444. http://dx.doi.org/10.1016/j.micpro.2020.103444, URL https://www.sciencedirect.com/science/article/pii/S0141933120305986.

[22] Jungk B, Stöttinger M. Among slow dwarfs and fast giants: A systematic design space exploration of KECCAK. In: 2013 8th international workshop on reconfigurable and communication-centric systems-on-chip. ReCoSoC, 2013, p. 1-8. http://dx.doi.org/10.1109/ReCoSoC.2013.6581527.

[23] Jungk B, Stöttinger M. Serialized lightweight SHA-3 FPGA implementations. Microprocess Microsyst 2019;71:102857. http://dx.doi.org/10.1016/j.micpro.2019.102857.

[24] Land G, Sasdrich P, Güneysu T. A hard crystal - implementing dilithium on reconfigurable hardware. Cryptol ePrint Arch 2021. https://eprint.iacr.org/2021/355. Paper 2021/355.

[25] Wang T, Zhang C, Cao P, Gu D. Efficient implementation of dilithium signature scheme on FPGA SoC platform. IEEE Trans Very Large Scale Integr (VLSI) Syst 2022;30(9):1158-71. http://dx.doi.org/10.1109/TVLSI.2022.3179459.

[26] Mu J, Tan H, Chen S, Cai M, Ye J, Li H, Li X. Configurable and high-level pipelined lattice-based post quantum cryptography hardware accelerator design. In: 2023 IEEE 32nd Asian test symposium. ATS, Los Alamitos, CA, USA: IEEE Computer Society; 2023, p. 1-6. http://dx.doi.org/10.1109/ATS59501.2023.10318005.

[27] Fritzmann T, Sharif U, Müller-Gritschneder D, Reinbrecht C, Schlichtmann U, Sepulveda J. Towards reliable and secure post-quantum co-processors based on RISC-V. In: 2019 design, automation & test in europe conference & exhibition. DATE, 2019, p. 1148-53. http://dx.doi.org/10.23919/DATE.2019.8715173.

[28] Sravani MM, Durai SA. On efficiency enhancement of SHA-3 for FPGA-based multimodal biometric authentication. IEEE Trans Very Large Scale Integr (VLSI) Syst 2022;30(4):488-501. http://dx.doi.org/10.1109/TVLSI.2022.3148275.

[29] Ravi P, Sundar VK, Chattopadhyay A, Bhasin S, Easwaran A. Authentication protocol for secure automotive systems: Benchmarking post-quantum cryptography. In: 2020 IEEE international symposium on circuits and systems. ISCAS, 2020, p. 1-5. http://dx.doi.org/10.1109/ISCAS45731.2020.9180847.

[30] Fritzmann T, Vith J, Flórez D, Sepúlveda J. Post-quantum cryptography for automotive systems. Microprocess Microsyst 2021;87:104379. http://dx.doi.org/10.1016/j.micpro.2021.104379, URL https://www.sciencedirect.com/science/article/pii/S0141933121005299.

[31] Nannipieri P, Di Matteo S, Zulberti L, Albicocchi F, Saponara S, Fanucci L. A RISC-V post quantum cryptography instruction set extension for number theoretic transform to speed-up CRYSTALS algorithms. IEEE Access 2021;9:150798-808. http://dx.doi.org/10.1109/ACCESS.2021.3126208.

[32] La Manna M, Perazzo P, Treccozi L, Dini G. Assessing the cost of quantum security for automotive over-the-air updates. In: 2021 IEEE symposium on computers and communications. ISCC 2021, IEEE; 2021, p. 1-6.

[33] Perazzo P, La Manna M, Iemma F. Post-quantum attribute-based encryption: Performance evaluation and improvement for embedded systems. In: Proceedings of the 2022 international conference on embedded wireless systems and networks. EWSN '22, New York, NY, USA: Association for Computing Machinery; 2023, p. 268-73.

[34] Bos JW, Dima A, Kiening A, Renes J. Post-quantum secure over-the-air update of automotive systems. Cryptol ePrint Arch 2023. https://eprint.iacr.org/2023/965. Paper 2023/965sss.
[35] Bos JW, Carlson B, Renes J, Rotaru M, Sprenkels D, Waters GP. Post-quantum secure boot on vehicle network processors. Cryptol ePrint Arch 2022. https://eprint.iacr.org/2022/635. Paper 2022/635.

[36] Wang W, Stöttinger M. Post-quantum secure architectures for automotive hardware secure modules. Cryptol ePrint Arch 2020. https://eprint.iacr.org/2020/026. Paper 2020/026.

[37] Huelsing A, Butin D, Gazdag S-L, Rijneveld J, Mohaisen A. RFC8391. XMSS: extended Merkle signature scheme. 2018. Internet Requests for Comments.

[38] McGrew D, Curcio M, Fluhrer S. RFC8554. Leighton-micali hash-based signatures. 2019. Internet Requests for Comments.

[39] Kuppusamy TK, Brown A, Awwad S, McCoy D, Bielawski R, Mott C, Lauzon S, Weimerskirch A, Cappos J. Uptane: Securing software updates for automobiles. In: International conference on embedded security in car. 2016. p. 1–11.

[40] Franke DF, Sibold D, Teichel K, Dansarie M, Sundblad R. Network time security for the network time protocol. 2020. http://dx.doi.org/10.17487/RFC8915. URL https://www.rfc-editor.org/info/rfc8915. RFC 8915.

[41] Bai S, Ducas L, Kiltz E, Lepoint T, Lyubashevsky V, Schwabe P, Seiler G, Stehlé D. CRYSTALS-dilithium: algorithm specifications and supporting documentation. Tech. rep., 2020.

[42] Fouque P-A, Hoffstein J, Kirchner P, Lyubashevsky V, Pornin T, Prest T, Ricosset T, Seiler G, Whyte W, Zhang Z. Falcon: fast-fourier lattice-based compact signatures over NTRU specification v1.2. Tech. rep., 2020.

[43] Dworkin MJ. SHA-3 standard: Permutation-based hash and extendable-output functions. 2015. http://dx.doi.org/10.6028/NIST.FIPS.202. https://www.nist.gov/publications/sha-3-standard-permutation-based-hash-and-extendable-output-functions.

[44] Abuelsamid S. Automotive over-the-air updates: a cost consideration guide. Tech. rep., Guidehouse Insights; 2021.

[45] Valente L, Tortorella Y, Sinigaglia M, Tagliavini G, Capotondi A, Benini L, Rossi D. HULK-V: a heterogeneous ultra-low-power linux capable RISC-V SoC. In: 2023 design, automation & test in europe conference & exhibition. DATE, 2023, p. 1–6. http://dx.doi.org/10.23919/DATE56975.2023.10137252.

[46] RY5cy: User manual. 2019. https://www.pulp-platform.org/docs/ri5cy_user_manual.pdf.

[47] Greconici DOC, Kannwischer MJ, Sprenkels A. Compact dilithium implementations on Cortex-M3 and Cortex-M4. Cryptol ePrint Arch 2020. http://dx.doi.org/10.46586/tches.v2021.i1.1-24. https://eprint.iacr.org/2020/1278. Paper 2020/1278.

[48] Kim Y, Song J, Youn T-Y, Seo SC, Liu Z-L. Crystals-dilithium on ARMv8. Sec. Commun. Netw. 2022;2022. http://dx.doi.org/10.1155/2022/5226390.

[49] Kim Y, Song J, Seo SC. Accelerating Falcon on ARMv8. IEEE Access 2022;10:44446–60. http://dx.doi.org/10.1109/ACCESS.2022.3169784.

[50] Kern D, Krauß C, Lauser T, Alnahawi N, Wiesmaier A, Niederhagen R. QuantumCharge: Post-quantum cryptography for electric vehicle charging. In: Tibouchi M, Wang X, editors. Applied cryptography and network security. Cham: Springer Nature Switzerland; 2023, p. 85–111.

[51] Twardokus G, Bindel N, Rahbari H, McCarthy S. When cryptography needs a hand: Practical post-quantum authentication for V2V communications. Cryptol ePrint Arch 2022. https://eprint.iacr.org/2022/483. Paper 2022/483.

[52] Yoshizawa T, Preneel B. Post-quantum impacts on V2X certificates – already at the end of the road. In: 2023 IEEE 97th vehicular technology conference. 2023, p. 1–6. http://dx.doi.org/10.1109/VTC2023-Spring57618.2023.10199793, VTC2023-spring.