Hardware Root of Trust (HRoT)
Un Hardware Root of Trust è un componente hardware fisicamente isolato e resistente alla manomissione che funge da ancoraggio di sicurezza fondamentale per un intero sistema informatico. Fornisce un punto di partenza immutabile per la verifica crittografica: l’unico elemento del sistema di cui ci si deve fidare incondizionatamente perché la sua integrità è garantita dalla progettazione fisica, non dal software.
Perché “Root”?
Nella sicurezza crittografica, ogni verifica dipende dal fatto che qualcos’altro sia stato verificato prima. Questa catena deve iniziare da qualche parte: da una “radice” che non può a sua volta essere compromessa. Un Hardware Root of Trust fornisce questa radice memorizzando le chiavi di verifica iniziali in hardware fisicamente non estraibile (fusibili OTP, ROM o silicio sicuro dedicato).
Senza una radice hardware, qualsiasi sicurezza realizzata in software può essere compromessa: un attaccante che controlla il firmware di boot può vanificare qualsiasi cifratura, autenticazione o controllo degli accessi caricato successivamente.
Come funziona
La Chain of Trust
┌──────────────────────────────────────────────────────────────────────────────┐
│ HARDWARE ROOT OF TRUST (immutabile — ROM/OTP/Secure Element) │
│ Contiene chiave pubblica radice e codice di verifica dell’avvio │
│ Verifica la firma dello stadio successivo │
└──────────────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────────────┐
│ BOOTLOADER DI STADIO 1 (primo codice modificabile) │
│ Verificato dall’HRoT; verifica il bootloader di stadio 2 │
└──────────────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────────────┐
│ BOOTLOADER DI STADIO 2 / KERNEL DEL SISTEMA OPERATIVO │
│ Verificato dallo stadio 1; verifica il firmware applicativo │
└──────────────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────────────┐
│ FIRMWARE APPLICATIVO │
│ Verificato dallo stadio 2; esegue il normale funzionamento del dispositivo │
└──────────────────────────────────────────────────────────────────────────────┘Ogni stadio è verificato crittograficamente dallo stadio precedente. Se uno stadio non supera la verifica, il processo di boot si arresta, impedendo l’esecuzione di firmware compromesso.
Tecnologie di Hardware Root of Trust
| Tecnologia | Implementazione | Certificazione | Utilizzata in |
|---|---|---|---|
| Secure Element | IC dedicato resistente alla manomissione (STSAFE-A110, OPTIGA Trust M, SE050) | CC EAL5+/EAL6+ | Dispositivi IoT, controllori industriali |
| TPM (Trusted Platform Module) | Chip discreto o basato su firmware (fTPM) | TCG 2.0, FIPS 140-3 | Server, PC, automotive |
| ARM TrustZone | Isolamento a livello di CPU (Secure World / Normal World) | PSA Certified L1-L3 | MCU (STM32, NXP i.MX) |
| Fusibili OTP | Memoria programmabile una sola volta nel SoC | Varia in base al produttore del SoC | Tutto il silicio — memorizzazione dell’hash delle chiavi |
| Codice di boot in ROM | Codice immutabile in mask ROM | Verificato in fabbrica | Verifica di boot di primo stadio |
| DICE (Device Identifier Composition Engine) | Standard TCG per l’identità a livelli del dispositivo | TCG DICE | IoT vincolato, automotive |
Perché il CRA impone l’Hardware Root of Trust
Il Cyber Resilience Act dell’UE richiede che i prodotti con elementi digitali implementino:
- Secure boot — che è sicuro solo se ancorato all’hardware.
- Memorizzazione delle chiavi resistente alla manomissione — la memorizzazione delle chiavi solo software non soddisfa questo requisito.
- Identità del dispositivo non falsificabile — richiede l’attestazione hardware, non ID software clonabili.
- Aggiornamenti firmware autenticati — le chiavi di firma devono essere memorizzate in hardware resistente alla manomissione.
La conclusione normativa: se il vostro MCU non dispone di un’enclave sicuro fisico o di un Secure Element, non potete dichiarare la conformità al CRA aggiungendo software. Il silicio deve cambiare.
Software Root of Trust vs. Hardware Root of Trust
| Aspetto | Software Root of Trust | Hardware Root of Trust |
|---|---|---|
| Memorizzazione delle chiavi | Memoria flash (leggibile con JTAG/SWD) | Silicio resistente alla manomissione (fisicamente non estraibile) |
| Verifica del boot | Può essere aggirata sovrascrivendo la flash | Codice ROM immutabile — non può essere modificato |
| Resistenza agli attacchi | Vulnerabile a dump del firmware e glitching | Progettato per resistere ad attacchi fisici (schermature a maglia, sensori) |
| Costo | Gratuito (solo software) | —0,50——3,00 per unità (Secure Element) |
| Conformità al CRA | ? Non soddisfa il requisito di “resistenza alla manomissione” | ? Soddisfa i requisiti di sicurezza hardware |
| Certificazione | Non certificabile a livelli di garanzia elevati | CC EAL5+, EAL6+, FIPS 140-3 |
Termini correlati
- Secure Boot — Il processo che utilizza l’Hardware Root of Trust per verificare l’integrità del firmware a ogni stadio del boot.
- Secure Element — Un chip discreto resistente alla manomissione comunemente utilizzato come Hardware Root of Trust.
- HSM — Hardware Security Module che forniscono il Root of Trust a livello di server/infrastruttura.
- CRA — Il regolamento dell’UE che impone l’Hardware Root of Trust per i prodotti connessi.