- Service Definition
- Sicurezza IoT radicata nell'hardware — Secure Element, HSM e crittografia post-quantistica. Progetti allineati a CRA, NIS2 e IEC 62443.
Sicurezza dei sistemi embedded e IoT — gestione end-to-end
Che cos'è la sicurezza dei sistemi embedded?
La sicurezza dei sistemi embedded consiste nell'integrare la protezione crittografica direttamente nell'hardware utilizzando componenti come Secure Element, HSM e TPM. Stabilisce un Hardware Root of Trust che protegge i dispositivi da manomissioni, clonazione e attacchi informatici, a supporto della conformità al Cyber Resilience Act dell'UE e alla Direttiva NIS2 per le infrastrutture critiche e l'IoT.
La sicurezza dei sistemi embedded è la pratica di integrare la protezione crittografica direttamente nell’hardware — utilizzando Secure Element resistenti alle manomissioni, Hardware Security Module (HSM) e catene di avvio cifrate per stabilire un Hardware Root of Trust. A differenza della sicurezza basata solo sul software, la protezione radicata nell’hardware non può essere aggirata da malware, exploit della memoria o attacchi di esecuzione di codice da remoto.
Attraverso la sua rete di partner, Inovasense gestisce progetti IoT secure by design — orientati alla conformità al Cyber Resilience Act dell’UE (Regolamento (UE) 2024/2847), alla Direttiva NIS2 (Direttiva (UE) 2022/2555), alla norma IEC 62443 per la sicurezza industriale e alla norma ETSI EN 303 645 per l’IoT di consumo.
Perché la sicurezza hardware è cruciale nel 2026
Il Cyber Resilience Act dell’UE impone ai fabbricanti, dall’11 settembre 2026, di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, e i suoi obblighi principali si applicano dall’11 dicembre 2027: i prodotti con elementi digitali che rientrano nell’ambito di applicazione necessitano della gestione delle vulnerabilità, di una distinta base del software (SBOM) e di aggiornamenti di sicurezza per un periodo di assistenza di norma pari ad almeno cinque anni. I prodotti “importanti” di classe II (ad es. firewall, microcontrollori a prova di manomissione) e i prodotti “critici” (ad es. gateway per contatori intelligenti, carte intelligenti e Secure Element) richiedono una valutazione della conformità da parte di terzi o, ove applicabile, una certificazione europea della cibersicurezza.
Il CRA non impone tecnologie specifiche, ma la sicurezza radicata nell’hardware è spesso un modo appropriato per soddisfarne i requisiti basati sul rischio.
⚠ Le decisioni hardware condizionano la conformità a CRA e RED.
Non applichiamo patch al software — implementiamo un Hardware Root of Trust fisico su Secure Element certificati Common Criteria laddove la valutazione dei rischi del prodotto lo richieda. Un aggiornamento firmware non può aggiungere un Secure Element che non esiste sulla vostra scheda.
Prenota una Compliance Gap Analysis →- Archiviazione delle chiavi resistente alle manomissioni — Le chiavi crittografiche non lasciano mai il Secure Element; la loro estrazione richiede un’analisi fisica distruttiva
- Measured boot — Ogni fase del firmware viene verificata crittograficamente prima dell’esecuzione, impedendo la persistenza di rootkit
- Resistenza agli attacchi fisici — Schermature a mesh attiva, rilevatori di voltage glitch e sensori di luce rilevano e rispondono ai tentativi di intrusione fisica
- Sicurezza del ciclo di vita — Provisioning sicuro, rotazione delle chiavi, gestione dei certificati e dismissione a fine vita gestiti tramite hardware
- Predisposizione post-quantistica — Scambio di chiavi ibrido (ML-KEM + X25519) e firme digitali (ML-DSA) a protezione dalle future minacce quantistiche
Stack dell’architettura di sicurezza
Hardware Root of Trust
I progetti integrano IC di sicurezza certificati dei principali produttori europei (STMicroelectronics, Infineon, NXP) per garantire la sovranità hardware:
| Componente | Prodotti | Certificazione | Pronto per PQC |
|---|---|---|---|
| Secure Element | STMicroelectronics STSAFE-A110, Infineon OPTIGA Trust M, NXP EdgeLock SE050 | CC EAL5+ (STSAFE-A110); CC EAL6+ (OPTIGA Trust M, SE050) | Percorso di upgrade firmware |
| Moduli TPM | STMicroelectronics ST33 (TPM 2.0), Infineon SLB 9672 | TCG TPM 2.0; la validazione FIPS 140 dipende dal componente e dal firmware (SLB 9672: FIPS 140-2) | Sì |
| Java Card | STMicroelectronics ST31 / STPay, NXP JCOP4 | CC EAL6+, EMVCo | A livello di applet |
| MCU sicuri | STM32H5 / STM32U5 (TrustZone), NXP LPC55S | PSA Certified L3 | Supporto a libreria |
| Secure Enclave | STM32MP2 (isolamento hardware), ARM CCA | Isolamento certificato | Assistito da hardware |
Implementazione crittografica
- Simmetrica: AES-128/256-GCM (accelerata in hardware), ChaCha20-Poly1305
- Asimmetrica: ECC P-256/P-384, Ed25519/Ed448, RSA-3072/4096
- Post-quantistica (standard NIST): ML-KEM-768/1024 (incapsulamento delle chiavi), ML-DSA-65/87 (firme digitali), SLH-DSA (firme stateless basate su hash)
- Schemi ibridi: X25519 + ML-KEM per TLS 1.3, ECDSA + ML-DSA per la firma del firmware
- Hashing: SHA-256, SHA-3, SHAKE-256, HMAC per l’autenticazione dei messaggi
- Gestione delle chiavi: derivazione HKDF, catene di certificati X.509v3, interfacce PKCS#11, DICE (Device Identifier Composition Engine)
Secure Boot e protezione del firmware
Le implementazioni di Secure Boot seguono il modello ARM PSA (Platform Security Architecture):
- Bootloader immutabile — Memorizzato in ROM, verifica crittograficamente la fase successiva utilizzando Ed25519 o ML-DSA
- Chain of trust — Ogni fase di avvio autentica la successiva; il root of trust è ancorato a fusibili hardware
- Integrità a runtime — Le memory protection unit (MPU) e TrustZone applicano l’isolamento dei processi
- Aggiornamenti OTA sicuri — Pacchetti firmware firmati (manifest SUIT) con rollback atomico in caso di fallimento della verifica
- Integrazione SBOM — Generazione automatizzata della distinta base del software per la conformità al CRA
Sviluppo di applicazioni Java Card
Java Card è un ambiente di esecuzione sicuro che gira su IC per Smart Card certificati (CC EAL6+), che consente la distribuzione di applet resistenti alle manomissioni per pagamenti, identità, controllo degli accessi e autenticazione IoT. Attraverso la nostra rete di partner, realizziamo applicazioni Java Card personalizzate sulle piattaforme STMicroelectronics ST31/STPay e NXP JCOP4, collaborando con integratori di Smart Card certificati ove richiesto.
Cosa offriamo
- Sviluppo di applet personalizzati — Applet sicuri in Java Card 3.1 per pagamenti (EMVCo), bigliettazione per il trasporto, eID governativi e controllo degli accessi aziendali
- Soluzioni di pagamento — Applet di pagamento EMV con contatto/contactless, tokenizzazione e implementazioni di wallet sicuri basati su STPay per il settore fintech e bancario
- Identità e accessi — Identità digitale basata su PKI, autenticatori FIDO2/WebAuthn e gestione dei certificati X.509 su Secure Element
- Autenticazione di dispositivi IoT — Autenticazione TLS reciproca tramite certificati ospitati su Java Card, attestazione dei dispositivi e provisioning sicuro per la gestione delle flotte
- NFC e contactless — Applet conformi a ISO 14443 / ISO 7816 per transazioni contactless, accesso agli edifici e infrastrutture per smart city
Piattaforme e certificazioni
| Piattaforma | Tipo | Certificazione | Casi d’uso |
|---|---|---|---|
| ST31 / STPay (STMicroelectronics) | IC per Smart Card sicuro | CC EAL6+, EMVCo | Pagamenti, trasporti, eID |
| NXP JCOP4 | Java Card OS su SE | CC EAL6+, FIDO | Identità, controllo degli accessi |
| Infineon SLE 78 | Security Controller | CC EAL6+ | Documenti d’identità governativi, sanità |
Tutte le soluzioni Java Card includono provisioning di canale sicuro conforme a GlobalPlatform, gestione del ciclo di vita degli applet e funzionalità di gestione remota degli applet (RAM).
Connettività wireless per l’IoT
I progetti puntano a soluzioni di connettività adeguate ai requisiti di potenza, portata e larghezza di banda di ciascuna applicazione:
| Protocollo | Portata | Velocità dati | Consumo | Ideale per |
|---|---|---|---|---|
| Bluetooth LE (5.4 o successivo) | 100 m | 2 Mbps | Ultra-basso | Wearable, asset tag, PAwR |
| LoRaWAN 1.0.4 | 15 km | 50 kbps | Molto basso | Monitoraggio ambientale, misurazione |
| NB-IoT (Rel-17) | Cellulare | 250 kbps | Basso | Tracciamento di asset su area estesa |
| Wi-Fi 7 (802.11be) | 50 m | 5,8 Gbps | Medio | Video in tempo reale, gateway |
| Thread 1.4/Matter | 30 m | 250 kbps | Basso | Smart home/edifici, interoperabilità |
| 5G RedCap (Rel-17) | Cellulare | 150 Mbps | Medio | IoT industriale, sistemi autonomi |
| DECT NR+ (2024) | 1 km | 3 Mbps | Basso | Mesh industriale privata, non cellulare |
Progettazione a consumo ultra-basso
I progetti IoT puntano a una durata della batteria pluriennale tramite:
- Ottimizzazione della modalità sleep — Consumo di corrente <500 nA in deep sleep con risveglio da RTC
- Duty cycling — Algoritmi di scheduling intelligenti riducono il tempo attivo a <0,1%
- Energy harvesting — Circuiti di raccolta di energia solare (interna/esterna), termoelettrica e da vibrazione
- Profilazione dei consumi — Il consumo di corrente reale viene misurato in ogni fase di progettazione con analizzatori come Otii Arc e PPK2
- Ottimizzazione della chimica delle batterie — LiFePO4 per temperature estreme, celle a stato solido per la longevità, topologie ibride con supercondensatore
Conformità e certificazione (2026)
| Normativa | In vigore | Requisito | Come vi aiutiamo |
|---|---|---|---|
| Cyber Resilience Act dell’UE (Regolamento (UE) 2024/2847) | Segnalazione dall’11 set. 2026; obblighi principali dall’11 dic. 2027 | Gestione delle vulnerabilità, SBOM, aggiornamenti di sicurezza per il periodo di assistenza (di norma almeno 5 anni) | Architettura secure-by-design, SBOM automatizzato, documentazione tecnica CRA |
| Direttiva NIS2 (Direttiva (UE) 2022/2555) | Ott. 2024 | Sicurezza della catena di approvvigionamento per i soggetti essenziali e importanti | Ciclo di sviluppo sicuro, piano di risposta agli incidenti |
| IEC 62443 | In corso | Sicurezza dell’automazione industriale | Modello zone/conduit, valutazione SL-T, SDL |
| ETSI EN 303 645 | In corso | Baseline di sicurezza per l’IoT di consumo | Tutte le 13 disposizioni: nessuna password predefinita, archiviazione sicura, superficie di attacco minima |
| Atto delegato RED (2022/30) | Dal 1° ago. 2025; abrogato dall’11 dic. 2027 | Cibersicurezza per le apparecchiature radio | Secure Boot, aggiornamenti autenticati, protezione di rete |
| GDPR Art. 25 | In corso | Protezione dei dati fin dalla progettazione | Architettura privacy-preserving, elaborazione locale, raccolta dati minima |
| Regolamento sull’intelligenza artificiale (AI Act) (Regolamento (UE) 2024/1689) | 2025–2028 (alto rischio: 2 dic. 2027 / 2 ago. 2028) | Classificazione del rischio dei sistemi di IA | Supporto alla valutazione della conformità per IoT abilitato all’Edge AI |
Tutte le architetture di sicurezza sono progettate e documentate all’interno dell’Unione europea. I deliverable standard includono la documentazione del modello di minaccia (STRIDE/DREAD), report dei test di sicurezza, SBOM e analisi dei gap di conformità.
Fonti e riferimenti ufficiali
- Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Gazzetta ufficiale dell'UE)
- NIS2 Directive — Directive (EU) 2022/2555 — EUR-Lex (Gazzetta ufficiale dell'UE)
- RED Delegated Act — Regulation (EU) 2022/30 — EUR-Lex (Gazzetta ufficiale dell'UE)
- EU AI Act — Regulation (EU) 2024/1689 — EUR-Lex (Gazzetta ufficiale dell'UE)
- GDPR — Regulation (EU) 2016/679 — EUR-Lex (Gazzetta ufficiale dell'UE)
Guide su questo tema
Sicurezza IoT: buone pratiche per progettisti
Sicurezza pratica di firmware, identità, API, aggiornamenti e operazioni, con limiti hardware e obblighi CRA corretti.
15 tipi di attacchi IoT: esempi e difese
Quindici minacce IoT, scenari illustrativi identificati, il caso Mirai documentato e difese basate sui rischi.
Sicurezza hardware: fiducia, chiavi e verifica
Progettare sicurezza hardware in base alle minacce: limiti della radice di fiducia, secure boot, chiavi e requisiti CRA neutrali.
Domande frequenti
Che cos'è la sicurezza dei sistemi embedded nell'IoT?
La sicurezza dei sistemi embedded nell'IoT significa integrare la protezione crittografica direttamente nell'hardware utilizzando Secure Element, TPM e HSM. A differenza della sicurezza basata solo sul software, la protezione radicata nell'hardware non può essere aggirata da malware o attacchi remoti. Inovasense gestisce progetti IoT con un Hardware Root of Trust conforme al Cyber Resilience Act dell'UE.
Perché la sicurezza hardware è importante per i dispositivi IoT?
La sicurezza basata solo sul software può essere aggirata. La sicurezza hardware fornisce un Hardware Root of Trust resistente alle manomissioni che protegge le chiavi crittografiche, garantisce il Secure Boot e impedisce aggiornamenti firmware non autorizzati — un elemento essenziale per le infrastrutture critiche e i dispositivi connessi ai sensi del CRA dell'UE e della Direttiva NIS2.
Che cos'è il Cyber Resilience Act dell'UE?
Il Cyber Resilience Act dell'UE (CRA, Regolamento (UE) 2024/2847) stabilisce requisiti di cibersicurezza per i prodotti con elementi digitali che rientrano nel suo ambito di applicazione, inclusi la gestione delle vulnerabilità, una SBOM e aggiornamenti di sicurezza per un periodo di assistenza di norma pari ad almeno cinque anni. Gli obblighi di segnalazione si applicano dall'11 settembre 2026; gli obblighi principali si applicano dall'11 dicembre 2027.