Iniziare dal modello di minaccia
Identificare gli asset: credenziali del dispositivo, infrastruttura di firma, dati personali, comandi e disponibilità. Stabilire chi raggiunge ogni interfaccia e se un attaccante può possedere fisicamente il dispositivo. Valutare le conseguenze per la sicurezza delle persone. Scegliere controlli in base ai rischi e documentare le prove; il certificato di un componente non certifica il prodotto completo.
Sequenza pratica di progettazione e verifica
- Definire confini di fiducia tra applicazione, firmware privilegiato, periferiche e backend.
- Separare chiavi private di firma e materiale di verifica; pianificare provisioning, rotazione e revoca.
- Scegliere protezioni di avvio, debug e memoria supportate dalla precisa revisione del dispositivo.
- Autenticare aggiornamenti e provare il recupero dopo scritture interrotte.
- Limitare i servizi, autenticare utenti e dispositivi e verificare autorizzazioni nelle API.
- Provare immagini errate, credenziali revocate, vecchie versioni, input malformati e perdita di connessione.
- Conservare dipendenze, triage delle vulnerabilità, evidenze dei rilasci e piano di assistenza.
I risultati devono descrivere dispositivo, configurazione e ipotesi di attacco. Una prova riuscita di secure boot non dimostra resistenza a ogni attacco fisico o durante l’esecuzione.
Fiducia hardware e protezione delle chiavi
Una radice hardware di fiducia ancora determinate funzioni a meccanismi hardware sulla cui integrità il sistema fa affidamento. Può usare codice di avvio protetto, materiale crittografico, esecuzione isolata o un componente dedicato. La chiave pubblica di verifica o il suo hash non è la chiave privata di firma: il fabbricante protegge normalmente quest’ultima nell’infrastruttura di firma. TrustZone, TPM e secure element hanno ruoli distinti; nessuno costituisce automaticamente un’architettura completa o una certificazione del prodotto. La resistenza alle manomissioni ha un modello di minaccia e un livello di garanzia, non garantisce l’impossibilità fisica di estrarre chiavi. Valutare separatamente debug, fault injection, canali laterali e recupero chiavi.
Secure boot: protezione e limiti
Secure boot autentica il software di avvio prima di consentirne l’esecuzione. In un progetto embedded comune, codice iniziale protetto verifica un bootloader firmato, che verifica l’applicazione. Fasi e algoritmi dipendono dal processore e dall’implementazione. Protegge dalla sostituzione non autorizzata dell’immagine; non dimostra che il software approvato sia privo di vulnerabilità né impedisce tutti gli attacchi durante l’esecuzione. Measured boot registra misure per una valutazione successiva; la sola misura non blocca necessariamente l’esecuzione. Anti-rollback e recupero protetto sono ulteriori scelte da valutare e testare.
CRA e scelte tecnologiche
I requisiti CRA sono orientati ai risultati e tecnologicamente neutrali, in base alla valutazione dei rischi e all’applicabilità. Secure boot, radice hardware di fiducia, TPM, TrustZone e OTA wireless possono essere misure opportune; non sono obblighi universali per ogni prodotto. Documentare perché i controlli scelti soddisfano i requisiti, senza equiparare una singola architettura alla conformità.
Date e ambito CRA
Il CRA è entrato in vigore il 10 dicembre 2024. Le segnalazioni dell’articolo 14 si applicano dall’11 settembre 2026; i requisiti principali dall’11 dicembre 2027. L’articolo 69 contiene regole transitorie per prodotti già immessi sul mercato. I prodotti soggetti a MDR o IVDR sono esclusi dall’articolo 2(2); verificare anche altre esclusioni e il software libero/open-source non commerciale.
Domande frequenti
Il CRA richiede sempre secure boot?
I requisiti CRA sono orientati ai risultati e tecnologicamente neutrali, in base alla valutazione dei rischi e all’applicabilità. Secure boot, radice hardware di fiducia, TPM, TrustZone e OTA wireless possono essere misure opportune; non sono obblighi universali per ogni prodotto. Documentare perché i controlli scelti soddisfano i requisiti, senza equiparare una singola architettura alla conformità.
Un secure element garantisce conformità?
No. Può proteggere chiavi e operazioni specifiche; la conformità riguarda prodotto completo, requisiti, processi ed evidenze.