Appunti Hardware and embedded security (parte 2)

Indice

1 Sicurezza nei sistemi embedded, veicoli connessi e

macchine intelligenti 6

1.1 Contesto generale: perché la security è centrale nei sistemi embedded

moderni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Connessione interna ed esterna del veicolo . . . . . . . . . . . . . . . . . . 6

1.3 Relazione tra safety e security . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Cyberattacchi e aumento della severità nei veicoli autonomi . . . . . . 7

2 Bisogni fondamentali di sicurezza nei veicoli 8

2.1 Confidenzialità dei dati dell’utente . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Confidenzialità dei dati del veicolo . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Integrità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Disponibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Tracciabilità e non ripudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 Basso costo ed efficienza energetica . . . . . . . . . . . . . . . . . . . . . . 10

3 Modello di minaccia STRIDE 10

3.1 Significato generale di STRIDE . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.3 Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4 Information Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.6 Elevation of Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Necessità di embedded security nei dispositivi edge 12

4.1 Protezione dei dispositivi edge . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Limiti della sicurezza solo software . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Funzioni principali richieste a un HSM . . . . . . . . . . . . . . . . . . . . 12

5 Attacchi reali ai veicoli 13

5.1 Attacco remoto alla Jeep Cherokee . . . . . . . . . . . . . . . . . . . . . . . 13

5.2 Attacco a Tesla Model 3 tramite drone e Wi-Fi . . . . . . . . . . . . . . 13

5.3 Attacco Man-in-the-Middle su comunicazioni V2X . . . . . . . . . . . . 13

6 Sfide aperte nella ricerca e sviluppo 13

6.1 Device manager sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2 Anomaly detection: guasti e intrusioni . . . . . . . . . . . . . . . . . . . . 14

6.3 Minaccia quantistica e crittografia post-quantum . . . . . . . . . . . . . 14

1 2

7 Specifiche automotive per la sicurezza hardware 15

7.1 Evoluzione delle specifiche: SHE, EVITA e specifiche proprietarie . . 15

7.2 Copertura delle specifiche nei prodotti commerciali . . . . . . . . . . . . 15

8 Secure Hardware Extension 15

8.1 Definizione e obiettivi di SHE . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.2 Blocchi fondamentali di SHE . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.3 Vista logica SHE-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.4 Requisiti prestazionali di SHE . . . . . . . . . . . . . . . . . . . . . . . . . . 17

9 Modalità crittografiche e servizi di sicurezza 17

9.1 Perché servono più modalità AES . . . . . . . . . . . . . . . . . . . . . . . 17

9.2 Altre modalità AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

10 Politica delle chiavi in SHE 18

10.1 MASTER ECU KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

10.2 BOOT MAC KEY e BOOT MAC . . . . . . . . . . . . . . . . . . . . . . . 18

10.3 KEY n e RAM KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

SEED, PRNG KEY e PRNG state

10.4 PRNG . . . . . . . . . . . . . . . . . 19

10.5 SECRET KEY e UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

11 EVITA 19

11.1 Concetto generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

11.2 EVITA Light, Medium e Full . . . . . . . . . . . . . . . . . . . . . . . . . . 20

12 Regolamentazione e standard moderni 20

12.1 UN R155 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

12.2 Cyber Security Management System . . . . . . . . . . . . . . . . . . . . . 20

12.3 ISO/SAE 21434 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

12.4 NIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

13 Necessità dell’accelerazione hardware 21

13.1 Perché la CPU general purpose non basta . . . . . . . . . . . . . . . . . . 21

13.2 Vantaggi degli acceleratori hardware . . . . . . . . . . . . . . . . . . . . . . 22

13.3 Relazione tra potenza statica e dinamica . . . . . . . . . . . . . . . . . . . 22

14 Aggiornamenti software e firmware over-the-air 22

14.1 Necessità degli aggiornamenti OTA . . . . . . . . . . . . . . . . . . . . . . 22

14.2 Firma digitale e verifica dell’immagine firmware . . . . . . . . . . . . . . 23

14.3 Crittografia simmetrica e asimmetrica negli update . . . . . . . . . . . . 23

14.4 Chain of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

14.5 Procedura di aggiornamento e rollback . . . . . . . . . . . . . . . . . . . . 23

15 Secure data transfer da memorie esterne 24

3

15.1 Problema delle memorie esterne . . . . . . . . . . . . . . . . . . . . . . . . . 24

15.2 AES in modalità counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

16 Soft errors e hardware security 24

16.1 Errori casuali e funzioni crittografiche . . . . . . . . . . . . . . . . . . . . . 24

16.2 Collegamento tra reliability e security . . . . . . . . . . . . . . . . . . . . . 25

17 Architettura hardware security nelle ECU 25

17.1 Stack software, firmware e hardware . . . . . . . . . . . . . . . . . . . . . . 25

17.2 Security subsystem e AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . 25

18 Trusted Platform Module 26

18.1 Definizione generale di TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18.2 TPM 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18.3 TPM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18.4 Esempio ST33GTPMAI2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

19 Metodi di identificazione e autenticazione nel TPM 27

19.1 Password verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19.2 HMAC challenge-response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19.3 Enhanced Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

20 Trusted Zone e isolamento 27

20.1 Principio di separazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

20.2 Trusted software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

20.3 Trusted hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

21 TrustZone in ARMv8 28

21.1 Secure world e normal world . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

22 CryptoCell in ARM 28

22.1 CryptoCell 312 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

22.2 CryptoCell 700 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

22.3 Architettura CryptoCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

23 Hardware security in Infineon AURIX 29

23.1 AURIX TC2xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

23.2 Connessione tramite System Peripheral Bus . . . . . . . . . . . . . . . . . 29

23.3 AURIX TC3xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

23.4 SHE+ in TC2xx e TC3xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

23.5 AURIX TC4xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

24 Hardware Security Module e sicurezza embedded 31

24.1 Il ruolo degli HSM nei sistemi embedded sicuri . . . . . . . . . . . . . . . 31

4

24.2 Root of Trust e catena di fiducia . . . . . . . . . . . . . . . . . . . . . . . . 32

25 HSM automotive e microcontrollori commerciali 32

25.1 Sicurezza automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

25.2 Crypto Secure Engine in NXP e ST . . . . . . . . . . . . . . . . . . . . . . 33

25.3 Microcontrollori NXP S32K . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

25.4 Secure boot NXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

25.5 Firmware update A/B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

26 STMicroelectronics e Renesas 34

26.1 STMicroelectronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

26.2 Renesas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

27 Security IP commerciali e Root of Trust program-

mabili 35

27.1 Mercato degli IP di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 35

27.2 Root of Trust programmabile . . . . . . . . . . . . . . . . . . . . . . . . . . 36

28 Acceleratori crittografici hardware 36

28.1 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

28.2 HASH e HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

28.3 Crittografia a chiave pubblica . . . . . . . . . . . . . . . . . . . . . . . . . . 37

29 Intel SDM, QAT e sicurezza FPGA/SoC 37

29.1 Secure Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

29.2 Intel QuickAssist Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 38

30 Hardware per Secure Cards 38

30.1 Secure Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

30.2 SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

31 Architettura EPI GPP e Security Sub-System 39

31.1 Architettura generale EPI GPP . . . . . . . . . . . . . . . . . . . . . . . . . 39

31.2 Security Sub-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

31.3 Security Domain e Secure MCU . . . . . . . . . . . . . . . . . . . . . . . . 40

32 Crypto-Tile EPI 40

32.1 Servizi del Crypto-Tile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

32.2 Security strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

32.3 AES supportato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

32.4 ECC, ECDSA e assenza di RSA . . . . . . . . . . . . . . . . . . . . . . . . 42

32.5 SHA, HMAC e RNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

32.6 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5

33 PUF, OTP e Secure Element 43

33.1 OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

33.2 PUF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

34 Side Channel Attacks e contromisure 43

34.1 Side Channel Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

34.2 Clock randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

35 Key management, access restriction, debug e panic

mode 44

35.1 Key slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

35.2 Access restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

35.3 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

35.4 Panic mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

36 IDS automotive, ECU fingerprinting e CAN security 45

36.1 IDS automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

36.2 ECU fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

37 Evoluzione degli HSM: Post-Quantum Cryptography

e affidabilità 46

37.1 Sicurezza nell’era quantistica . . . . . . . . . . . . . . . . . . . . . . . . . . 46

37.2 Post-Quantum Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 46

37.3 PQC, blockchain e IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

37.4 Soft errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6

1 Sicurezza nei sistemi embedded, veicoli connessi e

macchine intelligenti

1.1 Contesto generale: perché la security è centrale nei sistemi

embedded moderni

I sistemi embedded moderni non sono più dispositivi isolati, semplici e con funzionalità limi-

tate. Oggi sono sempre più spesso inseriti in ambienti complessi, distribuiti e connessi, come

veicoli autonomi, robot, sistemi industriali 4.0, droni, dispositivi medicali, sistemi di difesa e

infrastrutture intelligenti. In questi contesti, il dispositivo embedded non si limita a eseguire

un controllo locale, ma comunica continuamente con altri nodi, riceve aggiornamenti software,

scambia dati sensibili e prende decisioni che possono avere conseguenze fisiche sull’ambiente.

Nel caso automotive, il veicolo può essere visto come una rete distribuita di centraline elettroni-

che, cioè ECU, Electronic Control Units. Ogni ECU controlla una funzione specifica: moto-

re, frenata, sterzo, infotainment, climatizzazione, sistemi ADAS, sensori, batterie, comunicazioni

esterne e cosı̀ via. Queste unità comunicano tramite reti interne come LIN, CAN, CAN-FD,

FlexRay e Automotive Ethernet. Il veicolo diventa quindi un sistema cyber-fisico, dove

un’informazione digitale può produrre un effetto fisico reale.

1.2 Connessione interna ed esterna del veicolo

Un veicolo moderno comunica su due livelli principali.

• Comunicazione interna: le ECU devono scambiarsi dati in tempo reale. La centra-

lina motore può comunicare con quella del cambio, i sensori di velocità possono inviare

dati ai sistemi di frenata, i radar e le telecamere possono inviare informazioni ai sistemi

ADAS. Queste comunicazioni devono essere rapide, affidabili e deterministiche, perché

spesso influenzano funzioni safety-critical.

• Comunicazione esterna: il veicolo comunica con smartphone, cloud, infrastrutture stra-

dali, altri veicoli, satelliti e servizi online. Questa comunicazione abilita funzioni avanzate

come navigazione aggiornata, aggiornamenti OTA, diagnostica remota, guida cooperativa,

infotainment e servizi V2X.

Il problema principale è che ogni nuova connessione aumenta la superficie d’attacco. Più

porte di comunicazione esistono, più possibilità ha un attaccante di trovare un punto debole.

Un veicolo isolato può essere attaccato solo localmente; un veicolo connesso può invece essere

attaccato da remoto. 7

1.3 Relazione tra safety e security

La safety riguarda la protezione da guasti accidentali, errori hardware, errori software, mal-

funzionamenti, condizioni ambientali estreme o eventi casuali. La security riguarda invece la

protezione da attacchi intenzionali, quindi da soggetti che cercano volontariamente di violare il

sistema.

Nei veicoli connessi, safety e security sono strettamente collegate. Una vulnerabilità di security

può trasformarsi in un problema di safety. Per esempio, se un attaccante riesce a modificare i

messaggi inviati sul bus CAN, può alterare il comportamento del veicolo. Questo può portare

a una frenata non richiesta, alla disattivazione di un sistema di assistenza, all’apertura non

autorizzata delle porte o alla perdita di controllo di una funzione critica.

La security diventa quindi una condizione necessaria per garantire la safety. Non basta pro-

gettare un sistema resistente ai guasti casuali: bisogna anche proteggerlo da manipolazioni

volontarie. Figura 1: architettura

1.4 Cyberattacchi e aumento della severità nei veicoli autonomi

Nei veicoli tradizionali, molti comandi erano meccanici o locali. Nei veicoli moderni, invece, mol-

te funzioni sono software-defined. Questo significa che il comportamento del veicolo dipende

fortemente dal software, dai sensori, dagli algoritmi e dalla comunicazione tra ECU.

Sistemi come ADAS, guida autonoma, controllo automatico della corsia, cruise control adattivo,

frenata automatica e parcheggio assistito dipendono da dati e decisioni software. Se questi dati

vengono falsificati, ritardati o alterati, il veicolo può prendere decisioni sbagliate.

Naturlamente, aumentando il livello di automazione, aumenta anche la dipendenza dal software e

dai sistemi elettronici. Di conseguenza, un attacco informatico può avere conseguenze sempre più

gravi, perché non compromette solo dati digitali, ma può influenzare direttamente movimento,

traiettoria e sicurezza fisica. 8

2 Bisogni fondamentali di sicurezza nei veicoli

2.1 Confidenzialità dei dati dell’utente

La confidenzialità consiste nel garantire che le informazioni siano accessibili solo ai sogget-

ti autorizzati. Nei veicoli moderni vengono raccolti molti dati personali: abitudini di guida,

percorsi frequenti, posizione, stile di guida, preferenze dell’utente, dati biometrici, impostazioni

del sedile, climatizzazione, radio, profili personali e informazioni legate allo stato di salute o

attenzione del conducente.

Questi dati possono sembrare secondari, ma in realtà hanno grande valore. Le abitudini di

viaggio possono rivelare dove vive una persona, dove lavora, quali luoghi frequenta e in quali

orari è assente da casa. I dati biometrici possono essere ancora più sensibili, perché riguardano

caratteristiche fisiche dell’individuo.

La confidenzialità protegge quindi la privacy del conducente e dei passeggeri, impedendo che

dati personali vengano letti, copiati o venduti senza autorizzazione.

2.2 Confidenzialità dei dati del veicolo

Oltre ai dati dell’utente, esistono dati relativi al veicolo. Questi includono stato di manutenzione,

chilometraggio, identificativo del veicolo, storico degli aggiornamenti software e firmware, dati

su guasti, incidenti, velocità media e massima, comportamento dei componenti e condizioni di

invecchiamento.

La protezione di questi dati è importante per diversi motivi. Un attaccante potrebbe usare infor-

mazioni tecniche sul veicolo per preparare un attacco mirato. Potrebbe anche manipolare dati

diagnostici, alterare lo storico del