EN 303 645

EN 303 645 — Norma di cibersicurezza per i dispositivi IoT di consumo

La ETSI EN 303 645 (titolo completo: Cyber Security for Consumer Internet of Things: Baseline Requirements) è la norma di base europea — e ormai di riferimento globale — per la cibersicurezza dei dispositivi IoT di consumo. Sviluppata da ETSI (European Telecommunications Standards Institute) e pubblicata per la prima volta nel giugno 2020, definisce 13 disposizioni di sicurezza e 5 disposizioni di protezione dei dati che stabiliscono il livello minimo di cibersicurezza che ogni dispositivo di consumo connesso a Internet dovrebbe possedere.

La EN 303 645 si colloca al centro dell’ecosistema regolamentare UE per la sicurezza dell’IoT: è richiamata dall’Atto delegato RED, fa parte della tabella di marcia di armonizzazione del CRA ed è stata adottata come base per gli schemi nazionali di etichettatura della cibersicurezza nel Regno Unito, a Singapore, in Finlandia e in Germania.

Fatti chiave

Le 13 disposizioni di sicurezza

La EN 303 645 struttura i propri requisiti in 13 disposizioni numerate. Ciascuna disposizione contiene una combinazione di requisiti obbligatori (SHALL) e raccomandazioni di buona pratica (SHOULD):

Disposizione 1: Nessuna password predefinita universale

La disposizione di maggiore impatto. Ogni dispositivo IoT deve, in alternativa:

• Essere fornito senza password predefinita, con l’obbligo per l’utente di impostarne una durante la configurazione, oppure
• Avere una password unica per dispositivo generata in modo da renderla imprevedibile

Le credenziali predefinite condivise (ad es. admin/admin, root/1234) identiche su tutte le unità di un modello sono vietate. Questa singola disposizione elimina il vettore di attacco IoT più comune dell’ultimo decennio — il credential stuffing contro le password predefinite.

Implicazione hardware: le password uniche per dispositivo devono essere memorizzate in modo sicuro in memoria non volatile e devono sopravvivere ai ripristini di fabbrica (oppure essere rigenerate dopo il ripristino). Ciò richiede un processo di provisioning in fase di produzione.

Disposizione 2: Implementare una politica di divulgazione delle vulnerabilità

I fabbricanti devono pubblicare una politica di divulgazione delle vulnerabilità (VDP) chiara e accessibile che:

• Fornisca informazioni di contatto per i ricercatori di sicurezza
• Indichi il periodo minimo per il quale verranno accettate le segnalazioni di vulnerabilità
• Definisca il processo di risposta atteso e le relative tempistiche

Si tratta di un requisito organizzativo — non hardware — ma deve essere in essere prima che il prodotto entri nel mercato dell’UE.

Disposizione 3: Mantenere il software aggiornato

I dispositivi devono supportare gli aggiornamenti software di sicurezza e:

• I processi di aggiornamento devono essere semplici per l’utente (non richiedere conoscenze specialistiche)
• Il dispositivo deve notificare all’utente la disponibilità di un aggiornamento di sicurezza
• Gli aggiornamenti devono essere tempestivi — le vulnerabilità critiche devono essere affrontate prontamente
• Gli aggiornamenti devono essere disponibili per il periodo di supporto definito del dispositivo
• Il dispositivo non deve consentire il downgrade a una versione firmware vulnerabile

Implicazione hardware: richiede una capacità di aggiornamento OTA sicura con protezione contro il rollback. Se l’MCU non può implementare l’anti-rollback (ad es. tramite contatori monotoni in memoria sicura), gli attacchi di downgrade del firmware diventano fattibili.

Disposizione 4: Memorizzare in modo sicuro i parametri di sicurezza sensibili

Credenziali, chiavi crittografiche e altri parametri sensibili devono essere memorizzati con una protezione adeguata. Le credenziali codificate fisse nel firmware sono vietate.

Implicazione hardware: i parametri sensibili dovrebbero essere memorizzati in uno spazio di archiviazione protetto a livello hardware (Secure Element, memoria protetta da TrustZone, aree bloccate tramite eFuse). L’archiviazione solo software in flash standard è insufficiente per i casi d’uso ad alta garanzia.

Disposizione 5: Comunicare in modo sicuro

Tutte le comunicazioni del dispositivo devono utilizzare:

• Trasporto cifrato — la comunicazione in chiaro di dati sensibili è vietata
• Endpoint autenticati — il dispositivo deve verificare di comunicare con il server/servizio previsto
• Protocolli conformi alle attuali buone pratiche — i protocolli deprecati (SSLv3, TLS 1.0, WEP, WPA) non devono essere utilizzati

Questa disposizione richiede TLS 1.2 come minimo (TLS 1.3 raccomandato) per le comunicazioni Internet e una cifratura adeguata per la comunicazione locale tra rete e dispositivo.

Disposizione 6: Ridurre al minimo le superfici di attacco esposte

Il dispositivo deve esporre solo i servizi necessari alla funzionalità prevista:

• Le interfacce di rete, le porte e i servizi non utilizzati devono essere disabilitati per impostazione predefinita
• Le interfacce fisiche (interfacce di debug JTAG, UART) devono essere disabilitate o protette nel firmware di produzione
• I servizi di rete non devono essere eseguiti con privilegi elevati oltre quanto necessario

Implicazione hardware: le interfacce di debug fisiche (JTAG, SWD) dovrebbero essere bloccate tramite protezione con fusibili OTP o disabilitate in modo permanente nei dispositivi di produzione. Lasciare JTAG abilitato sulle unità di produzione è un riscontro comune negli audit di sicurezza.

Disposizione 7: Garantire l’integrità del software

Il dispositivo deve verificare l’integrità del software all’avvio e durante l’aggiornamento:

• Secure boot — verifica crittografica del firmware prima dell’esecuzione
• Convalida dell’aggiornamento — gli aggiornamenti firmware devono essere verificati prima dell’installazione
• Qualsiasi tentativo di modifica del software deve essere rilevato e gestito

Implicazione hardware: catena Secure Boot completa dalla boot ROM fino al firmware applicativo, ancorata all’hardware (chiave radice in fusibili OTP). I controlli di integrità solo software possono essere aggirati.

Disposizione 8: Garantire la sicurezza dei dati personali

I dispositivi che trattano o memorizzano dati personali devono:

• Utilizzare una cifratura adeguata per i dati personali a riposo
• Fornire agli utenti meccanismi per controllare i propri dati personali
• Non trasmettere dati personali senza un adeguato consenso dell’utente
• Supportare la cancellazione sicura dei dati (ripristino di fabbrica che cancelli effettivamente i dati personali)

Disposizione 9: Rendere i sistemi resilienti alle interruzioni

I dispositivi dovrebbero continuare a funzionare in una modalità degradata ma funzionale durante le interruzioni di rete e dovrebbero:

• Non entrare in uno stato permanentemente inutilizzabile a causa di un’interruzione di un servizio di rete
• Supportare il ripristino dopo aggiornamenti falliti

Disposizione 10: Esaminare i dati di telemetria del sistema

I fabbricanti dovrebbero monitorare la telemetria dei dispositivi sul campo per rilevare anomalie di sicurezza. Questa disposizione è in gran parte una raccomandazione (SHOULD) anziché un requisito (SHALL).

Disposizione 11: Facilitare la cancellazione dei dati personali da parte degli utenti

I dispositivi dovrebbero fornire agli utenti un meccanismo semplice e accessibile per cancellare tutti i dati personali — funzionalità di ripristino di fabbrica con cancellazione dei dati confermata e completa.

Disposizione 12: Facilitare l’installazione e la manutenzione

I processi di configurazione e manutenzione non dovrebbero richiedere all’utente conoscenze specialistiche di sicurezza. La sicurezza dovrebbe essere garantita “per impostazione predefinita”, senza richiedere configurazioni da parte dell’utente per essere attiva.

Disposizione 13: Convalidare i dati di input

I dispositivi dovrebbero convalidare tutti gli input ricevuti tramite interfacce utente, API e servizi di rete per prevenire attacchi di injection e lo sfruttamento di buffer overflow.

EN 303 645 ed EN 18031: relazione e differenze

Una comune fonte di confusione è la relazione tra la EN 303 645 e la più recente serie EN 18031:

Guida pratica: per le apparecchiature radio che devono dimostrare la conformità all’Atto delegato RED, la EN 18031 è la norma armonizzata principale da applicare. La EN 303 645 rimane altamente rilevante come riferimento di base, per la pianificazione della conformità al CRA, per la conformità al mercato del Regno Unito e come fondamento di molti schemi nazionali di etichettatura della cibersicurezza.

EN 303 645 e schemi nazionali/internazionali

La EN 303 645 è stata universalmente adottata come base tecnica per la regolamentazione della cibersicurezza dell’IoT a livello mondiale:

Un prodotto che raggiunge la conformità alla EN 303 645 dispone di una solida base per i requisiti di cibersicurezza di molteplici mercati nazionali — rendendola una base di riferimento globale de facto.

Prove di conformità: ETSI TS 103 701

La ETSI TS 103 701 è la specifica di prova complementare alla EN 303 645. Essa fornisce:

• Casi di prova specifici per ciascuna disposizione
• Metodi di prova definiti (black-box, white-box, revisione documentale)
• Criteri di superamento/fallimento per ciascun requisito

I laboratori di prova accreditati utilizzano la TS 103 701 per produrre rapporti di prova strutturati che fungono da evidenza nella documentazione tecnica per la conformità regolamentare.

Riepilogo dei requisiti a livello hardware

Dalla nostra esperienza

Eseguendo gap analysis EN 303 645 su prodotti IoT di consumo, questi sono i pattern che riscontriamo con maggiore costanza:

La disposizione 1 fallisce in circa il 60% delle prime valutazioni. Pur essendo il requisito EN 303 645 più pubblicizzato, le credenziali predefinite condivise rimangono la non conformità più comune che riscontriamo. La credenziale spesso non è admin/admin — i fabbricanti ne sono consapevoli — ma piuttosto un valore predefinito derivato dal modello del dispositivo (ad es. le ultime 4 cifre di un indirizzo MAC) algoritmicamente prevedibile. La ETSI TS 103 701 verifica esplicitamente le credenziali per dispositivo prevedibili, non solo quelle universali. La soluzione richiede sia una modifica del provisioning a livello hardware (credenziale unica generata e iniettata in produzione tramite un HSM) sia una modifica del processo produttivo. Raccomandiamo di trattare questo aspetto come un’attività di ingegneria di produzione, non come un’attività firmware.

Scoperta del JTAG nella disposizione 6: il riscontro più comune negli audit di sicurezza. In oltre l’80% delle valutazioni di sicurezza hardware in cui riceviamo unità di produzione (non campioni di ingegneria), l’accesso di debug JTAG o SWD rimane attivo. I fabbricanti tipicamente collaudano con campioni di ingegneria — in cui JTAG è intenzionalmente abilitato — e la build firmware di produzione non include la bruciatura dei fusibili OTP come fase finale di produzione. Il risultato è un dispositivo di produzione in cui qualsiasi malintenzionato dotato di una sonda di debug da 30 £ può eseguire il dump dell’intera flash, estrarre le credenziali, aggirare il secure boot e installare firmware arbitrario. Implementiamo una fase di verifica obbligatoria con JTAG bloccato nelle attrezzature di collaudo di produzione: qualsiasi unità che risponda a un tentativo di connessione JTAG dopo la fase di programmazione di produzione viene scartata.

Anti-rollback nella disposizione 3: spesso dichiarato, raramente implementato correttamente. Molti fabbricanti affermano che il loro sistema di aggiornamento OTA impedisce il downgrade del firmware. In pratica, riscontriamo che ciò è implementato come un controllo di versione software nel firmware applicativo — banalmente aggirabile da qualsiasi malintenzionato che abbia già compromesso il dispositivo. Un autentico anti-rollback ai sensi della EN 303 645 richiede un contatore hardware monotono in una regione di memoria resistente alle manomissioni che non possa essere decrementato. Sui dispositivi privi di Secure Element o di un SoC con TrustZone, ciò è architetturalmente impossibile da implementare correttamente in puro software. La scelta di un chipset che supporti l’anti-rollback a livello hardware deve essere una decisione di progettazione del primo giorno.

Connessioni backend legacy TLS 1.0/1.1 nella disposizione 5. Un prodotto può avere un’implementazione TLS 1.3 on-device perfetta — e fallire comunque la disposizione 5 se il backend cloud a cui si connette mantiene il supporto TLS 1.0 o 1.1 per i client legacy. La EN 303 645 verifica il protocollo negoziato, non solo la capacità minima del dispositivo. Riscontriamo ciò più frequentemente nei prodotti che si connettono a backend aziendali esistenti non aggiornati quando il firmware del dispositivo è passato a TLS 1.2+. La soluzione è lato backend, non lato dispositivo — e spesso al di fuori del controllo diretto del fabbricante hardware se si utilizza una piattaforma cloud condivisa.

Termini correlati

• EN 18031 — La serie di norme armonizzate successiva per la conformità all’Atto delegato RED, basata sui principi della EN 303 645.
• Atto delegato RED — Lo strumento giuridico che ha reso obbligatoria la conformità a EN 303 645 / EN 18031 per le apparecchiature radio connesse a Internet.
• CRA — Cyber Resilience Act dell’UE; la EN 303 645 costituisce parte del fondamento tecnico per i requisiti di cibersicurezza del CRA.
• Secure Boot — Requisito hardware fondamentale attivato dalla disposizione 7.
• OTA Update — Richiesto dalla disposizione 3; deve includere anti-rollback e verifica della firma.
• Hardware Root of Trust — Sottende le disposizioni 4 e 7.

Fonti ufficiali

• ETSI EN 303 645 V2.1.1 — download gratuito (etsi.org)
• ETSI TS 103 701 — Specifica di prova di conformità per la EN 303 645 (download gratuito)
• Atto delegato RED UE 2022/30 — EUR-Lex
• ETSI Cyber Security for Consumer IoT — pagina di panoramica ETSI

La conformità alla EN 303 645 è sempre più un’aspettativa di base per i prodotti hardware connessi che entrano nei mercati dell’UE, del Regno Unito e globali. Inovasense esegue una gap analysis rispetto a tutte le 13 disposizioni della EN 303 645 — mappando le capacità hardware esistenti rispetto a ciascun requisito SHALL, individuando le modifiche hardware o di processo produttivo necessarie (provisioning, blocco delle porte di debug, archiviazione sicura) e producendo documentazione pronta per la prova da sottoporre a un laboratorio accreditato. Consulta la nostra competenza nella sicurezza embedded e i nostri servizi di conformità UE.