Dispositivi sicuri, dalla scheda al firmware
La sicurezza di un dispositivo si decide quando si progetta: una porta di debug lasciata aperta, una memoria troppo piccola per aggiornare o una chiave scritta nel codice non si correggono dopo. Progettiamo scheda e firmware con le misure che chiedono il Cyber Resilience Act e il Regolamento Macchine, e le documentiamo per il vostro fascicolo tecnico.
Perché va fatto all’inizio
Se la sicurezza arriva a progetto finito, spesso serve una nuova revisione della scheda: un secure element non previsto, la flash da raddoppiare per gli aggiornamenti, le interfacce da ridisegnare. Per questo i requisiti di sicurezza entrano già nello studio di fattibilità e nella specifica, insieme a tutti gli altri.
Cosa facciamo
Analisi del rischio
Cosa va protetto, da chi e attraverso quali interfacce. Ne escono i requisiti di sicurezza della specifica e la documentazione per il fascicolo tecnico.
Sicurezza sulla scheda
Porte di debug protette o chiudibili, interfacce esterne ridotte al necessario, root of trust e secure element dove servono, memoria dimensionata per aggiornare.
Secure boot e aggiornamenti
Catena di avvio con immagini firmate, protezione dal ritorno a versioni vulnerabili, boot A/B con ritorno automatico all’ultima versione funzionante, OTA a prova di interruzione.
Dati e comunicazioni
Separazione delle funzioni critiche con TrustZone, flash protetta da letture esterne, dati cifrati in memoria e in transito, TLS, registro degli accessi e delle modifiche.
Produzione
Progettiamo il banco di collaudo in modo che carichi in ogni dispositivo chiavi e certificati propri e chiuda la porta di debug a fine collaudo.
Dopo la vendita
SBOM del firmware, controllo delle vulnerabilità di librerie e RTOS, aggiornamenti di sicurezza per il periodo di supporto, con un contratto di manutenzione. Penetration test con laboratori specializzati.
Dai requisiti alla scheda e al firmware
I requisiti del Cyber Resilience Act sono scritti per qualsiasi prodotto. Su un dispositivo embedded diventano scelte precise.
| Requisito | Sulla scheda | Nel firmware |
|---|---|---|
| Superficie d’attacco ridotta | Debug protetto, connettori di servizio non esposti | Debug bloccato in produzione, servizi non usati disattivati |
| Integrità del software | Memoria per più immagini, root of trust | Secure boot con firme, anti-rollback |
| Aggiornamenti di sicurezza | Memoria e alimentazione dimensionate per aggiornare | OTA firmato, boot A/B con rollback automatico |
| Riservatezza dei dati | Secure element per le chiavi | Cifratura in memoria e in transito, TLS |
| Identità del dispositivo | Chiave unica per ogni scheda | Certificati caricati in produzione |
| Sicuro di default | — | Nessuna password uguale per tutti, ripristino di fabbrica |
| Registro degli eventi | Memoria non volatile per i log | Log di accessi, modifiche e aggiornamenti |
| Componenti di terzi | BOM con ciclo di vita dei componenti | SBOM di librerie, RTOS e SDK |
La sicurezza scritta nella specifica
In un progetto recente, un dispositivo connesso su microcontrollore con TrustZone, i requisiti di sicurezza sono entrati nella specifica fin dalla prima stesura.
- Le funzioni critiche girano nella parte sicura del microcontrollore, separate dal resto del firmware.
- La flash è protetta da letture e scritture dall’esterno.
- I penetration test sono pianificati nella fase di hardening, prima della produzione.
Cosa ricevete
- Analisi del rischio e requisiti di sicurezza nella specifica
- Architettura di sicurezza documentata
- Firmware con secure boot e aggiornamenti firmati
- Procedura e strumenti per caricare le chiavi in produzione
- SBOM in formato leggibile da una macchina
- Documentazione per il fascicolo tecnico
Domande frequenti
Lavorate anche su un dispositivo già in vendita?
Sì. Analizziamo scheda e firmware, vi diciamo cosa manca e lo correggiamo. Se il prodotto ha già una scheda, spesso molto si fa nel firmware: debug bloccato, immagini firmate, aggiornamenti sicuri.
Fate i penetration test?
Li pianifichiamo nel progetto e li facciamo eseguire da laboratori specializzati. Poi correggiamo quello che emerge.
Ci rilasciate la certificazione CRA?
No: per la maggior parte dei prodotti la conformità la dichiara il fabbricante, e per alcune categorie serve un organismo notificato. Noi progettiamo le misure tecniche e vi diamo la documentazione per il fascicolo.
Chi segue gli aggiornamenti di sicurezza dopo la consegna?
Voi, oppure noi con un contratto di manutenzione: controllo delle vulnerabilità dei componenti, correzioni e rilascio degli aggiornamenti per il periodo di supporto.
Hai una scadenza?
Raccontaci il progetto: entro 48 ore ricevi un’offerta con fasi e date. Se serve, firmiamo l’NDA prima di vedere i tuoi file.