EMBEDDED
53 • SETTEMBRE • 2014
73
SOFTWARE
CRITTOGRAFIA
tua dei controlli sul richiedente prima di
rilasciare il certificato. Una volta che i
dispositivi di comunicazione ottengono
i loro certificati dalla CA, si scambiano i
loro rispettivi certificati al fine di stabilire
un segreto condiviso tra di loro. Poiché
la chiave pubblica della CA è comune
a tutti i dispositivi che partecipano alla
comunicazione e non viene mai cam-
biata, può essere pre-installata su tutti i
dispositivi in una rete in generale attra-
verso una serie di tecniche offline.
Quando la crittografia
non basta…
Molti progettisti software del mondo
embedded ritengono che la sicurezza
di questi sistemi debba essere gestita a livello infrastrutturale:
utilizzo di protocolli di comunicazione di rete sicuri, firewall,
crittografia dei dati, autenticazione delle sorgenti dei dati, moni-
toraggio del flusso di controllo assistito dall’hardware. Queste
tecniche tradizionali rappresentano ovviamente sempre un’otti-
ma base da implementare per aumentare il livello di sicurezza,
ma ormai non sono più sufficienti a dare adeguate garanzie.
Gli hacker si servono oggi anche di altre informazioni quali
la misura dei consumi energetici, perdite elettromagnetiche,
emissioni acustiche, misure di temporizzazioni. Occorre per-
tanto adottare numerosi altri accorgimenti di sicurezza in
un’ottica di realizzare livelli di sicurezza multipli (Mils, multiple
indipendent levels of security): sistema operativo, memoria,
bus interno, architettura, rete di trasmissione, software appli-
cativo e così via. Oltre a scegliere metodi e protocolli più adatti
per il trasferimento sicuro dei dati, i dispositivi devono essere
garantiti in termini di protezione da accessi non autorizzati alle
componenti hardware più critiche in termini di sicurezza, per
esempio le aree di memoria che contengono la chiave crittogra-
fica segreta, la cui scoperta potrebbe minare la sicurezza dell’in-
tero sistema. Una soluzione per rafforzare la sicurezza interna
al dispositivo embedded è creare un “secure SoC” (System On
Chip), una zona in grado di fornire protezione fisica alle chiavi
segrete tenendo la ROM (luogo di memorizzazione delle chiavi
crittografiche), la RAM (luogo di caricamento delle chiavi
segrete in testo chiaro) e relativo bus di collegamento tutti
interni al chip. Questo approccio impedisce che la ROM possa
essere fisicamente acceduta per recuperare le chiavi segrete,
che i bus interni non possano essere monitorati per intercetta-
zioni, e che la rimozione o sostituzione di qualsiasi componente
nel Secure SoC risulti impossibile o distruttiva per l’intero chip.
Una zona di bootloader sicuro, protetta in scrittura, può assicu-
rare infine che il dispositivo parta con un sistema operativo o un
firmware genuino con gli esatti privilegi di esecuzione. Inoltre,
è consigliabile adottare architetture con sistemi operativi a
microkernel piuttosto che monolitici e
meccanismi di partizionamento o acces-
so controllato (black-list o access-list) a
zone di memoria e file-system.
In alcuni casi, oltre a salvaguardare la
sicurezza degli accessi al chip, è bene
anche pensare a garantire la sicurezza
fisica del sistema embedded nel suo
complesso nel luogo ove è installato
e operante, impedendo o restringendo
opportunamente gli accessi fisici all’ap-
parecchiatura e al suo hardware.
I sistemi wireless, sempre più diffusi,
aggiungono un ulteriore strato di vul-
nerabilità rispetto a quelli già presenti
nelle soluzioni cablate. Infatti, per una
rete cablata il mezzo di trasmissione (il
cavo) può essere protetto da intercettazioni facendolo passare
per intercapedini inaccessibili, sotto terra, sospeso su tralicci,
inserito nel cemento. In una rete wireless, per la quale il mezzo
trasmissivo è l’etere, il sistema trasmette informazioni in tutte
le direzioni, e un malintenzionato ha solo bisogno di un’antenna
per effettuare intercettazioni. Per questo motivo, la maggior
parte dei protocolli wireless adotta metodi di crittografia incor-
porati, via via sempre più sicuri.
Molti attacchi di sicurezza sono concentrati su vulnerabilità del
software applicativo. In questi casi, anche se la linea software
di difesa non sarà perfetta, occorre lavorare su questa linea
riducendo la dimensione della “finestra di attacco” esistente nel
software sviluppato. Il primo passo è quello di cercare di imme-
desimarsi in un attaccante, chiedendosi come potrebbe cercare
di trovare delle vulnerabilità nel sistema e nel software al fine
di penetrarlo. In altre parole, occorre effettuare un’analisi delle
minacce e usare i risultati per descrivere quello che il proprio
software non dovrebbe fare. Anche se c’è ancora molto lavoro
da fare, ultimamente sono stati compiuti notevoli sforzi per
migliorare la sicurezza nei sistemi embedded, puntando non
solo a migliorare singole tecniche di protezione infrastruttu-
rale o applicativa, ma soprattutto orientando i progettisti verso
approcci metodologici generali di analisi e gestione dei rischi e
delle minacce e l’adozione di standard di sicurezza.
Ad esempio un consorzio di alcuni grandi produttori (AT&T,
Cisco, GE, IBM, Intel) ha proposto il framework “Industrial
IoT” per la definizione di interfacce standard tra i dispositivi
della Internet of Things e i servizi cloud, mentre in Europa alcu-
ni produttori stanno lavorando insieme nello sviluppo di mec-
canismi di sicurezza per l’iniziativa denominata “Industry 4.0”
(quarta rivoluzione industriale, guidata da internet e mondo
virtuale). Nel segmento automotive, l’adozione dello standard
Autosar (Automotive Open System Architecture) rappresenta
un’ottima via per migliorare anche le specifiche di sicurezza
nei veicoli.
Fig. 4 – IoT industrial integra caratte-
ristiche che garantiscono una conse-
gna affidabile dei messaggi
