- 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, garantendo la 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 entra in vigore in modo obbligatorio nel 2027, imponendo a tutti i prodotti con elementi digitali venduti nell’UE di implementare la gestione delle vulnerabilità, la distinta base del software (SBOM) e l’impegno a fornire aggiornamenti di sicurezza per 5 anni. I prodotti classificati come “critici” (apparecchiature di rete, controllori industriali, contatori intelligenti) sono soggetti a una valutazione della conformità da parte di terzi.
La sicurezza radicata nell’hardware non è più una funzionalità premium — è un requisito normativo.
⚠ Questo è l'unico percorso verso la conformità a CRA e RED.
Non applichiamo patch al software — implementiamo un Hardware Root of Trust fisico con certificazione EAL6+ per garantire la vostra marcatura CE. 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 EAL6+ | Percorso di upgrade firmware |
| Moduli TPM | STMicroelectronics ST33 (TPM 2.0), Infineon SLB 9672 | TCG 2.0, FIPS 140-3 | Sì |
| Java Card | STMicroelectronics ST31 / STPay, NXP JCOP4 | CC EAL6+, EMVCo | A livello di applet |
| MCU sicuri | STM32H5 / STM32U5 (TrustZone + ST-ONE), 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 |
|---|---|---|---|---|
| BLE 5.4 | 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.3/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) | Obbligatorio dal 2027 | Gestione delle vulnerabilità, SBOM, aggiornamenti per 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 | 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) | Ago. 2025 | 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–2027 | 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: la guida dell'ingegnere hardware
Andate oltre i firewall software. Scoprite la sicurezza IoT a livello hardware: catene di Secure Boot, TPM vs Secure Element e protezione del bitstream FPGA.
Sicurezza IoT: 15 tipi di attacchi (2026)
15 tipi di attacchi alla sicurezza IoT — dagli exploit del firmware alle botnet potenziate dall'IA. Incidenti reali 2024–2026. Per ingegneri e CISO.
Guida alla progettazione della sicurezza hardware
Progettare la sicurezza hardware significa ancorare la fiducia nel silicio — Secure Element, TPM e catene di Secure Boot. Una guida pratica per ingegneri HW.
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) è una normativa dell'UE che impone a tutti i prodotti con elementi digitali di soddisfare i requisiti di cibersicurezza durante l'intero ciclo di vita, inclusi la gestione delle vulnerabilità, la SBOM e aggiornamenti di sicurezza per 5 anni. Diventa obbligatorio nel 2027.