Appunti Hardware and embedded systems (parte 1)

Indice

1 Il ruolo dell’hardware nella cybersecurity 5

1.1 L’hardware come base della sicurezza digitale . . . . . . . . . . . . . . . . 5

1.2 Le tre dimensioni dell’hardware nella cybersecurity . . . . . . . . . . . . 5

1.3 Esempio della ECU automotive . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Hardware Security e Hardware Trust 7

2.1 Differenza tra sicurezza e fiducia . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Hardware-based Security e dipendenza dalla sicurezza dell’hardware . 7

3 Ciclo di vita della sicurezza hardware 8

3.1 Sicurezza e fiducia lungo tutto il ciclo di vita . . . . . . . . . . . . . . . . 8

3.2 Security-by-design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Hardware come Root of Trust 9

4.1 Significato di Root of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 La cybersecurity hardware come realtà complessa 10

5.1 Un problema multidimensionale . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Dimensioni di analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Hardware Security 11

6.1 Come ottenere Hardware Security . . . . . . . . . . . . . . . . . . . . . . . 11

6.2 Aggiornamento OTA di una ECU . . . . . . . . . . . . . . . . . . . . . . . 12

6.3 Modalità diagnostica e manutenzione . . . . . . . . . . . . . . . . . . . . . 12

7 Hardware Trust 13

7.1 Definizione di trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7.2 Autenticità e genuinità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8 Counterfeiting hardware 13

8.1 Il counterfeiting come minaccia industriale . . . . . . . . . . . . . . . . . 14

8.2 Tipi di counterfeiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8.3 Cause del counterfeiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

9 Hardware-based Security 16

9.1 Definizione generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9.2 Hardware Security come abilitatore . . . . . . . . . . . . . . . . . . . . . . 16

9.3 Tipi di implementazioni hardware-based . . . . . . . . . . . . . . . . . . . 16

10 Trusted Platform Module 17

10.1 Funzione generale del TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

10.2 Root of Trust e Chain of Trust nel TPM . . . . . . . . . . . . . . . . . . . 18

1 2

11 Trusted Execution Environment 18

11.1 Definizione di TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

11.2 Differenza tra TEE e TPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

11.3 Secure OS e secure hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . 19

12 Soluzioni architetturali: Memory Protection Unit 19

12.1 Sicurezza a livello architetturale . . . . . . . . . . . . . . . . . . . . . . . . 20

12.2 Funzione della MPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

13 Componenti hardware orientati alla sicurezza 21

13.1 Hardware ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

13.2 Smart card, SIM card e secure storage . . . . . . . . . . . . . . . . . . . . 21

13.3 Random Number Generators e PUF . . . . . . . . . . . . . . . . . . . . . . 21

13.4 Anti-tamper, secure boot e side-channel countermeasures . . . . . . . . 22

13.5 Anomaly detection, intrusion detection e fingerprinting . . . . . . . . . 22

14 Soluzioni proprietarie 22

14.1 Esempi principali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

15 Piattaforme open security 23

15.1 Valore dell’approccio open . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

15.2 OpenTitan e SEcube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

16 Sicurezza della supply chain hardware 24

16.1 Il problema della sicurezza hardware . . . . . . . . . . . . . . . . . . . . . 24

16.2 Outsourcing e nuove minacce . . . . . . . . . . . . . . . . . . . . . . . . . . 24

17 Che cosa si intende per hardware 25

17.1 Circuiti integrati, microprocessori, memorie e SoC . . . . . . . . . . . . 25

17.2 PCB e integrazione dei componenti . . . . . . . . . . . . . . . . . . . . . . 25

18 Esempi di problemi causati da hardware non sicuro 25

18.1 Settore difesa e intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18.2 Settori ICT, reti ed energia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18.3 Settore medicale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

18.4 Settore automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19 Flusso di progettazione e fabbricazione dei chip 27

19.1 Dalla specifica al circuito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19.2 Front-end, back-end e GDSII . . . . . . . . . . . . . . . . . . . . . . . . . . 27

19.3 ASIC e FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

20 Assemblaggio, distribuzione e fine vita 28

20.1 Le fasi successive alla fabbricazione . . . . . . . . . . . . . . . . . . . . . . 28

3

21 Cambiamento del modello industriale dei semicon-

duttori 29

21.1 Modello verticale e modello orizzontale . . . . . . . . . . . . . . . . . . . . 29

21.2 Aziende fabless, foundry e IP vendor . . . . . . . . . . . . . . . . . . . . . 30

22 Third-Party IP e System-on-Chip 30

22.1 IP hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

22.2 SoC composti da IP di aziende diverse . . . . . . . . . . . . . . . . . . . . 31

22.3 Mancanza di controllo sul processo . . . . . . . . . . . . . . . . . . . . . . . 31

23 Minacce hardware nella supply chain 31

23.1 Attori e fiducia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

23.2 IP piracy, system trust e IC trust . . . . . . . . . . . . . . . . . . . . . . . 32

24 Contraffazione e Hardware Trojan 32

24.1 Counterfeiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

24.2 Hardware Trojan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

25 Make or Buy Integrated Circuits 33

25.1 Acquistare COTS o progettare ASIC . . . . . . . . . . . . . . . . . . . . . 34

25.2 Formula del costo unitario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

26 Contraffazione dei circuiti integrati 34

26.1 Perché la contraffazione è redditizia . . . . . . . . . . . . . . . . . . . . . . 34

26.2 Riciclo illegale ed e-waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

26.3 Crisi dei chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

27 Tipologie di componenti contraffatti 35

27.1 Recycled e remarked ICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

27.2 Overproduced ICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

27.3 Out-of-spec e defective ICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

27.4 Cloned, forged documentation e tampered ICs . . . . . . . . . . . . . . . 36

28 Original Component Manufacturer 36

28.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

29 Riciclo e remarking degli IC 37

29.1 Processo di riciclo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

29.2 Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

30 Overproduction, out-of-spec, defective e cloning 37

30.1 Overproduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

30.2 Componenti difettosi e fuori specifica . . . . . . . . . . . . . . . . . . . . . 37

30.3 Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4

31 Forged documentation e componenti obsoleti 38

32 Vulnerabilità lungo l’intera supply chain 38

33 Counterfeits are defective 39

34 Contromisure e detection 39

34.1 Approccio generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

34.2 Partner fidati e tracciabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

35 Tassonomia dei difetti 40

35.1 Difetti fisici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

35.2 Difetti elettrici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

36 Testing per difetti 40

36.1 Strumenti di test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

36.2 Metodi di detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

37External Visual Inspection 41

38 X-Ray Inspection e Low Power Visual Inspection 42

38.1 X-Ray Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

38.2 Low Power Visual Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . 42

393D X-Ray Tomography 42

40 Test parametrici, funzionali, burn-in e strutturali 42

40.1 Test parametrici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

40.2 Test funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

40.3 Burn-in tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

40.4 Structural tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5

1 Il ruolo dell’hardware nella cybersecurity

1.1 L’hardware come base della sicurezza digitale

La cybersecurity non riguarda solo software, reti, sistemi operativi, applicazioni e protocolli.

Alla base di ogni sistema digitale esiste sempre un livello fisico: l’hardware. È l’hardware che

esegue le istruzioni, conserva dati, gestisce comunicazioni, controlla periferiche e rende possibili

tutte le funzioni superiori. Per questo motivo, se il livello hardware è compromesso, non affidabile

o progettato in modo debole, anche le protezioni software possono diventare inefficaci.

Il concetto centrale è che l’hardware rappresenta spesso la base più profonda della fiducia di un

sistema. Antivirus, firewall, autenticazione, cifratura e controlli software funzionano solo se il

supporto fisico su cui vengono eseguiti è corretto e non manipolato. Se processore, memoria,

circuito integrato, controller o modulo embedded sono stati alterati, contraffatti o progettati

con vulnerabilità, anche il software più sicuro può essere aggirato.

L’hardware può quindi essere considerato la “last line of defense”, cioè l’ultima linea di difesa.

Se un’applicazione è compromessa, può intervenire il sistema operativo; se il sistema operativo

è compromesso, può intervenire un hypervisor o un ambiente isolato. Ma se è compromesso il

livello hardware, il problema diventa molto più grave, perché l’intera catena di esecuzione può

essere alterata alla radice.

1.2 Le tre dimensioni dell’hardware nella cybersecurity

Il ruolo dell’hardware nella cybersecurity può essere organizzato in tre aree principali:

• Hardware Security

• Hardware Trust

• Hardware-based Security

La Hardware Security riguarda la protezione dell’hardware contro vulnerabilità, attacchi,

manipolazioni, hardware trojans, side-channel attacks e sfruttamenti malevoli del dispositivo

fisico. In altre parole, si occupa di rendere l’hardware resistente agli attacchi.

La Hardware Trust riguarda invece la fiducia nell’hardware. Un componente è trusted quando

si può dimostrare che è autentico, genuino, non contraffatto, non alterato e capace di comportarsi

nel modo atteso. Il trust non dipende solo dalla robustezza tecnica, ma anche da provenienza,

certificazione, validazione e possibilità di verificarne l’identità.

La Hardware-based Security indica l’uso dell’hardware per fornire servizi di sicurezza. Qui

l’hardware non è solo qualcosa da proteggere, ma diventa uno strumento attivo di protezione.

6

Esempi tipici sono generatori hardware di numeri casuali, PUF, acceleratori crittografici, HSM,

secure boot, TPM, TEE, meccanismi di isolamento hardware e unità dedicate alla protezione

della memoria.

Queste tre dimensioni devono coesistere. Non basta usare hardware per fornire sicurezza se

l’hardware stesso non è sicuro o non è trusted. Allo stesso modo, non basta fidarsi formalmente

di un componente se questo può essere attaccato durante l’uso.

1.3 Esempio della ECU automotive

Un esempio concreto è quello di una scheda elettronica usata come ECU, cioè Electronic

Control Unit, per il controllo di pompe automotive

Figura 1: ECU

Questa scheda non nasce necessariamente per fornire funzioni di cybersecurity: il suo compito

principale è controllare una pompa per liquidi, come acqua o olio. Tuttavia, essendo inserita in

un contesto mission-critical, deve comunque essere sicura e affidabile. Se una ECU di questo

tipo venisse compromessa, un attaccante potrebbe alterare parametri di funzionamento, impe-

dire il corretto controllo della pompa, causare guasti o compromettere la sicurezza complessiva

del veicolo.

In particolare, fondamentale è il SoC Infineon TLE9893-2QKW62S, dotato di HSM on-chip,

cioè di un Hardware Security Module integrato. Un SoC concentra su un unico chip proces-

sore, memoria, periferiche, controller e, in alcuni casi, funzioni di sicurezza. L’HSM è invece un

blocco hardware specializzato nella gestione di operazioni sensibili, come protezione delle chiavi,

autenticazione, cifratura, verifica di integrità e secure boot.

Questo esempio mostra un punto importante: anche un hardware che non fornisce direttamente

funzioni di sicurezza può dover essere secure e trusted, perché controlla parti fisiche critiche del

sistema. 7

Figura 2: SoC Infineon TLE9893-2QKW62S

2 Hardware Security e Hardware Trust

2.1 Differenza tra sicurezza e fiducia

Hardware Security e Hardware Trust sono concetti diversi ma strettamente collegati.

Un hardware può essere tecnicamente sicuro, cioè progettato con buone contromisure e capace

di resistere a certi attacchi. Tuttavia, se non è possibile identificarlo, validarlo o certificarlo, il

sistema potrebbe non potersi fidare di esso. In questo caso il componente può essere sicuro dal

punto di vista tecnico, ma non pienamente trusted.

Questa situazione genera inefficienze. Se non ci si fida completamente dell’hardware, si può intro-

durre ridondanza eccessiva, aumentando costi, complessità, consumi, area di silicio e overhead.

Inoltre, alcune funzionalità potrebbero non essere usate perché non considerate sufficientemente

affidabili.

La situazione opposta è ancora più pericolosa: un sistema può fidarsi di un hardware che però

non è realmente sicuro. Questo può accadere a causa di hardware trojans, side-channel attacks,

attacchi non rilevati o counterfeiting. In questo caso l’intero sistema si basa su una fiducia

mal riposta, e un componente apparentemente valido può diventare il punto di ingresso per

compromettere software, dati, comunicazioni e infrastrutture.

2.2 Hardware-based Security e dipendenza dalla sicurezza

dell’hardware

La Hardware-based Security consiste nell’utilizzare l’hardware per fornire servizi di sicurez-

za. Tuttavia, questo approccio funziona solo se l’hardware che fornisce sicurezza è esso stesso

sicuro e trusted. 8

Un acceleratore crittografico può rendere più veloce l’esecuzione di algoritmi come AES, RSA,

SHA o algoritmi post-quantum. Ma se contiene una backdoor, se perde informazioni tramite

canali laterali o se è contraffatto, non aumenta la sicurezza: la riduce.

Lo stesso vale per un generatore hardware di numeri casuali. La crittografia dipende dalla

qualità della casualità. Se un Random Number Generator produce numeri prevedibili o

manipolabili, chiavi crittografiche, nonce, challenge e protocolli di autenticazione possono essere

compromessi.

Quindi la Hardware-based Security è efficace solo se poggia su Hardware Security e Hardware

Trust. L’hardware può proteggere il sistema soltanto se prima è stato protetto e verificato.

3 Ciclo di vita della sicurezza hardware

3.1 Sicurezza e fiducia lungo tutto il ciclo di vita

La sicurezza e la fiducia dell’hardware devono essere considerate lungo tutto il ciclo di vita del

componente:

• specifica;

• design;

• implementazione tecnologica;

• test;

• commercializzazione;

• uso;

• manutenzione;

• dismissione.

Nella fase di specifica si definisce cosa il componente deve fare, quali requisiti deve rispettare,

quali interfacce deve avere, quali minacce deve considerare e quali proprietà di sicurezza deve

garantire. Se la sicurezza non viene prevista qui, sarà più difficile aggiungerla dopo.

Nella fase di design si definiscono architettura, blocchi funzionali, interconnessioni, protocolli

e logica interna. Un errore progettuale può introdurre vulnerabilità difficili da correggere.

Nella fase di implementazione il progetto viene realizzato in una tecnologia specifica, come

FPGA, ASIC, microcontrollore o SoC. Ogni tecnologia ha vantaggi e rischi propri. Un FP-

GA offre riconfigurabilità, ma richiede protezione del bitstream; un ASIC può offrire maggiore

robustezza e prestazioni, ma è meno flessibile. 9

Nella fase di test bisogna verificare non solo il funzionamento corretto, ma anche l’assenza di

comportamenti anomali, difetti, vulnerabilità o manipolazioni.

Durante commercializzazione e uso entrano in gioco supply chain, distribuzione, autenticità,

tracciabilità e rischio di contraffazione. Un componente autentico può essere sostituito da uno

falso lungo la catena di fornitura.

La manutenzione introduce aggiornamenti, riconfigurazioni, calibrazioni e diagnostica. Queste

operazioni sono necessarie, ma aprono anche superfici di attacco.

Infine, la dismissione deve essere gestita con attenzione, perché il dispositivo può ancora

contenere dati sensibili, chiavi crittografiche, configurazioni o informazioni proprietarie.

3.2 Security-by-design

Il principio di security-by-design significa progettare la sicurezza fin dall’inizio. È l’ap-

proccio più efficace, perché permette di integrare i meccanismi di protezione direttamente

nell’architettura.

Affrontare la sicurezza quando il dispositivo è già operativo è meno efficiente. Può richie