# Sicurezza dei dispositivi embedded: secure boot, OTA, chiavi | OneStack > Sicurezza embedded a Brescia: analisi del rischio, secure boot, debug protetto, aggiornamenti firmati, cifratura e SBOM. Pronti per il Cyber Resilience Act. URL: https://www.onestack.it/sicurezza-embedded Cybersecurity · Sicurezza embedded # 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. [Offerta in 48 ore](/contatti)[Cosa chiedono CRA e RED](/cyber-resilience-act) ## 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 [Le date e i requisiti del Cyber Resilience Act →](/cyber-resilience-act) Un esempio ## 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 ## Aggiornamenti sicuri sul campo [ ![Render 3D della scheda di controllo: microcontrollore al centro, connettori dei due canali isolati sul lato, morsettiere estraibili e connettori di alimentazione e servizio](/_astro/interfaccia-rugged.CkQk4iYb_1A6Ozp.webp)![](/_astro/interfaccia-rugged-xray.CZb6dpZZ_Z1kxhOu.webp) 23 test in ~75 s Sistemi per ambienti gravosi ### Un'interfaccia rugged che si aggiorna sul campo e non si blocca mai Un'unità portatile a batteria che alimenta e controlla due dispositivi remoti su canali isolati. La difficoltà era renderla affidabile lontano dal laboratorio. Il firmware si aggiorna sul campo e, se qualcosa va storto, torna da solo all'ultima versione funzionante. Leggi il caso → ](/casi-studio/interfaccia-rugged-ota) ## 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. [Chiedi un’offerta](/contatti)[Urgente? Chiama +39 030 535 7183](tel:+390305357183)