Funzionamento e limiti del secure boot
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: requisiti e scelte tecniche
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à.
Ambito e date 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.
Lista di controllo pratica
- Identificare prodotto, uso previsto, mercato e ambito normativo.
- Registrare disposizioni precise, date ed edizioni delle norme, comprese le restrizioni.
- Scegliere la procedura consentita e definire le evidenze necessarie.
- Collegare rischi, prove, versioni e dichiarazioni nella documentazione tecnica.
- Assegnare responsabilità per modifiche, assistenza e risposte alle autorità.
La lista aiuta la pianificazione; i requisiti normativi pertinenti determinano la valutazione finale.