Guida alla progettazione della sicurezza hardware

Con il Cyber Resilience Act dell’UE (Regolamento (UE) 2024/2847) che impone Secure Boot, aggiornamenti autenticati e gestione delle vulnerabilità per tutti i prodotti connessi entro dicembre 2027, la sicurezza hardware non è più facoltativa — è un requisito normativo.

Lo stack di sicurezza hardware

Un dispositivo embedded adeguatamente protetto implementa la sicurezza a ogni livello:

Livello	Componente	Funzione	Esempio
Radice di fiducia	Secure Element (SE) o TPM	Archiviazione delle chiavi resistente alle manomissioni, operazioni crittografiche	Infineon OPTIGA Trust M (CC EAL6+), NXP SE050
Secure Boot	Bootloader di primo stadio in OTP/flash protetta	Verifica la firma del firmware prima dell’esecuzione	ARM TrustZone + Secure Boot ROM
Partizione OS sicura	TrustZone Secure World o RISC-V PMP	Esecuzione isolata del codice critico per la sicurezza	OP-TEE, TF-M (Trusted Firmware-M)
Motore crittografico	Acceleratore hardware AES, SHA, ECC	Crittografia performante senza sovraccarico della CPU	STM32 CRYP/HASH, ESP32 AES-XTS
Archiviazione sicura	Flash cifrata con chiave derivata dal SE	Dati di firmware e configurazione protetti	OTFDEC (decifratura al volo)
Comunicazione sicura	TLS 1.3 con credenziali ancorate all’hardware	Dati in transito autenticati e cifrati	ATECC608B + AWS IoT Core
Aggiornamento sicuro	OTA dual-bank A/B con protezione dal rollback	Aggiornamenti del firmware autenticati	MCUboot, SWUpdate

Secure Element: la base della fiducia hardware

Un Secure Element (SE) è un IC dedicato e resistente alle manomissioni, progettato per archiviare chiavi crittografiche ed eseguire operazioni crittografiche in un ambiente fisicamente protetto:

Secure Element	Certificazione	Archiviazione chiavi	Algoritmi crittografici	Interfaccia	Fascia di prezzo
Infineon OPTIGA Trust M	CC EAL6+	ECC P256/P384, RSA 2048	ECDSA, ECDH, SHA-256, TRNG	I²C	0,80–1,50 €
NXP SE050	CC EAL6+	ECC, RSA, AES, Ed25519	ECDSA, ECDH, AES-128/256, SHA-256/384/512	I²C	1,00–2,00 €
Microchip ATECC608B	FIPS 140-2 (in attesa)	ECC P256	ECDSA, ECDH, SHA-256, AES-128, TRNG	I²C	0,50–0,80 €
STMicro STSAFE-A110	CC EAL5+	ECC P256/P384	ECDSA, ECDH, SHA-256/384, TRNG	I²C	0,60–1,00 €

Perché hardware e non software? Una chiave crittografica archiviata nella flash di un MCU può essere estratta tramite debug JTAG/SWD, attacchi side-channel (analisi della potenza, emanazione elettromagnetica) o lettura della flash. Un Secure Element archivia le chiavi in un ambiente schermato e capace di rilevare le manomissioni, dotato di contromisure attive — la chiave letteralmente non può lasciare il chip.

PSA Certified: il framework di sicurezza del settore

Il framework PSA Certified (Platform Security Architecture) di ARM fornisce una certificazione di sicurezza standardizzata per i dispositivi basati su MCU:

Livello	Cosa certifica	Valutazione di laboratorio richiesta	MCU tipici
PSA Certified Level 1	Questionario di sicurezza, modello delle minacce, funzioni di sicurezza di base	Autovalutazione	STM32L5, Nordic nRF5340
PSA Certified Level 2	Resistenza agli attacchi software, Secure Boot, aggiornamento sicuro	Laboratorio indipendente (8–12 settimane)	STM32U5, NXP LPC55S69
PSA Certified Level 3	Resistenza agli attacchi hardware (fault injection, SCA)	Laboratorio avanzato (12–16 settimane)	STM32H5 + SE, Renesas RZ/G

Il PSA Certified Level 2 sta diventando l’aspettativa minima per i prodotti IoT commerciali. Si allinea strettamente ai requisiti tecnici del CRA e fornisce un chiaro argomento di conformità.

La catena di Secure Boot

Una catena di Secure Boot correttamente implementata impedisce l’esecuzione di qualsiasi codice non autorizzato sul dispositivo:

1. Bootloader in ROM (immutabile, integrato nel silicio)
   ├── Verifica la firma del bootloader di secondo stadio
   └── Firma non valida → HALT (il dispositivo non si avvia)

2. Bootloader di secondo stadio (MCUboot / U-Boot)
   ├── Verifica la firma del firmware applicativo
   ├── Gestisce gli slot firmware A/B per gli aggiornamenti OTA
   └── Firma non valida → ritorno all'ultima immagine funzionante

3. Firmware applicativo
   ├── Viene eseguito nel Non-Secure World (TrustZone)
   ├── Accede ai servizi crittografici tramite le API del Secure World
   └── Non può accedere direttamente alle chiavi del Secure Element

Requisito critico: il bootloader di primo stadio deve essere immutabile — archiviato in memoria OTP (One-Time Programmable) o ROM. Se un attaccante è in grado di modificare il bootloader, l’intera catena di sicurezza crolla.

Crittografia post-quantistica: prepararsi alla minaccia quantistica

La crittografia asimmetrica attuale (RSA, ECC, Diffie-Hellman) sarà violata da computer quantistici sufficientemente potenti. Nel 2024 il NIST ha finalizzato i primi standard di crittografia post-quantistica:

Algoritmo	Standard NIST	Tipo	Dimensione chiave	Prestazioni su Cortex-M4
ML-KEM (CRYSTALS-Kyber)	FIPS 203	Incapsulamento di chiavi	1.568 byte (KEM-768)	~1 ms incapsulamento
ML-DSA (CRYSTALS-Dilithium)	FIPS 204	Firma digitale	2.420 byte (DSA-65)	~3 ms firma, ~1 ms verifica
SLH-DSA (SPHINCS+)	FIPS 205	Firma digitale (stateless)	7.856 byte	~50 ms firma

Impatto sui sistemi embedded: le dimensioni delle chiavi e delle firme post-quantistiche sono da 10 a 100 volte superiori rispetto agli equivalenti ECC. Ciò incide sull’archiviazione flash (per le catene di certificati), sulla RAM (per i buffer di verifica delle firme) e sulla larghezza di banda (per le firme degli aggiornamenti OTA). I progettisti hardware devono pianificare questi requisiti fin da ora, anche prima che la PQC diventi obbligatoria.

L’approccio consigliato: certificati ibridi che includono sia firme ECC sia firme PQC, garantendo la compatibilità con l’infrastruttura attuale e fornendo al contempo resistenza quantistica.

Errori comuni nell’architettura di sicurezza

Errore	Perché è pericoloso	Approccio corretto
Credenziali condivise tra dispositivi	Un solo dispositivo compromesso espone tutti i dispositivi	Credenziali univoche per dispositivo, provisioning durante la produzione
Scambio di chiavi solo simmetrico	Nessuna forward secrecy, possibili attacchi replay	Scambio di chiavi ECDHE o ML-KEM per ogni sessione
Porta di debug lasciata abilitata	JTAG/SWD consente la lettura completa della memoria	Disabilitare il debug in produzione tramite option byte + RDP Level 2
Archiviazione delle chiavi solo software	Chiavi estraibili tramite dump della flash o glitching	SE hardware con rilevamento delle manomissioni e schermatura attiva
Nessuna protezione dal rollback del firmware	L’attaccante può effettuare il downgrade a una versione vulnerabile	Contatore monotono nel SE/OTP per impedire il downgrade

Il nostro approccio all’ingegneria della sicurezza

In Inovasense, la sicurezza hardware è una decisione architetturale presa nella fase dei requisiti — non una funzionalità aggiunta prima della certificazione. Progettiamo la sicurezza a partire dal silicio:

1. Modellazione delle minacce — analisi STRIDE durante l’architettura di sistema per individuare le superfici di attacco
2. Selezione dell’IC di sicurezza — il SE/TPM giusto per l’applicazione (costo, livello di certificazione, supporto degli algoritmi)
3. Implementazione del Secure Boot — bootloader immutabile + MCUboot per aggiornamenti A/B gestiti
4. Provisioning delle credenziali — iniezione di chiavi per dispositivo durante la produzione tramite flusso di lavoro HSM automatizzato
5. Infrastruttura OTA — distribuzione di firmware firmato e cifrato con aggiornamenti delta e protezione dal rollback

Tutte le implementazioni di sicurezza seguono le linee guida PSA Certified e sono progettate per la conformità al CRA fin dal primo giorno. Contattateci per discutere della vostra architettura di sicurezza.

Fonti e riferimenti ufficiali

• Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Gazzetta ufficiale dell'UE)