70 / 86
XII
Medical
MEDICAL 15 -
OTTOBRE 2017
Root of Trust
– Il SoC utilizzato dalla piattaforma har-
dware è sufficientemente avanzato da poter fornire una
Root of Trust? In caso negativo, nella piattaforma hardwa-
re è presente un qualche componente sicuro alternativo
in grado di offrire funzionalità similari,
con modalità analoghe a quelle del SoC?
È importante sottolineare che, anche se la
risposta fosse negativa a entrambe queste
domande, esistono comunque sul mercato
fornitori specializzati che offrono soluzio-
ni di Root of Trust basate puramente su software.
Chain of Trust
- Una volta garantita la presenza di una
Root of Trust (figura 1), il processo di boot è in grado di
impostare una Chain of Trust. Le tipiche domande da
porsi relativamente alla implementazione di una Chain
of Trust efficace sono le seguenti:
- L’hardware ha validato ed autenticato il bootloader?
- Il bootloader ha validato ed autenticato il sistema ope-
rativo / i sistemi operativi?
- Il sistema operativo ha validato ed autenticato il codice
applicativo?
Se si utilizzano le tecnologie sopra elencate, si può essere
certi che sul dispositivo verrà eseguito solamente codice
applicativo autentico e non manomesso – con un rischio
estremamente ridotto che l’apparecchio possa essere
forzato ad operare in modo difforme.
Protezione dei dati in uso
I requisiti seguenti si applicano al dispositivo durante le
fasi di normale operatività, nel corso delle quali avviene
la generazione e la manipolazione dei dati. Tra le tecno-
logie che devono essere utilizzate in questa fase vi sono:
Isolamento applicativo via hardware
Alcuni sviluppatori di software scelgono di forzare un
isolamento di tipo fisico delle diverse applicazioni, uti-
lizzando molteplici SoC operanti in parallelo. Spesso tut-
tavia una soluzione di questo tipo è troppo onerosa: in
tal caso, la migliore strategia alternativa è rappresentata
dall’utilizzo di ARM TrustZone.
L’implementazione, all’interno di un SoC, della tecnolo-
gia ARM TrustZone può essere sfruttata per affrontare i
molteplici aspetti di un modello di sicurezza stratificato,
operante sia a livello di rete, che applicativo, che a livel-
lo dei dati. L’architettura ARM TrustZone fornisce una
soluzione in grado di ritagliare, o partizionare, una por-
zione hardware dell’intero SoC. Lo fa definendo proces-
sori, periferiche, spazi di indirizzamento della memoria,
e perfino aree della cache di secondo livello, in modo
tale da comportarsi in esecuzione come hardware “sicu-
ro” oppure “non-sicuro”.
Separazione applicativa via software
Quando l’opzione della separazione hardware non è per-
corribile, l’alternativa migliore rimane quella di utilizzare
il software per isolare e proteggere le applicazioni. In pas-
sato, in particolare nei SoCdi tipo single-co-
re, alcuni progetti venivano basati sul con-
cetto di un apposito kernel di separazione.
Attualmente, con la disponibilità di SoC
multicore che supportano le estensioni di
virtualizzazione già a livello del silicio, proli-
feranoiprogettibasatisull’usodegliembeddedhypervisors.
Gli hypervisors consentono l’esecuzione, sullo stesso
SoC, di molteplici istanze dello stesso o di differenti siste-
mi operativi, sotto forma di macchine virtuali (VM). Ogni
VM può essere isolata dalle altre e, mediante l’utilizzo di
una Memory Management Unit (MMU) di sistema, pos-
sono essere virtualizzati ulteriori bus master. Questo tipo
di separazione può essere utilizzato per proteggere le ri-
sorse e gli asset presenti in ogni VM, isolandoli da quelli
delle altre VM.
Isolamento dello spazio utente
Molti sistemi operativi offrono oggi una qualche forma
di isolamento, garantito tramite una MMU, del codice
applicativo in esecuzione nella RAM; in Linux esiste il
presente il process model (Fig. 2). L’idea di fondo è che
mentre il kernel del sistema operativo viene eseguito ad
un livello dotato di privilegi più elevati, come EL1 o EL2,
le applicazioni girano invece a livello EL0 e fanno leva su
svariate tecniche di isolamento degli spazi di memoria
per proteggere sia il codice che i dati, secondo una logi-
ca di separazione legata alle diverse applicazioni.
Offuscamento dei dati e di altre informazioni
La maggior parte degli sviluppatori provvede a nascon-
dere efficacemente le password, crittografandole. È tut-
tavia necessario assicurarsi che vengano offuscati anche i
valori delle variabili e delle stringhe di testo presenti sia
nella memoria di lavoro che in quella di archiviazione.
Ciò rende molto più difficoltose, per i malintenzionati,
le azioni tendenti a modificare le variabili o le stringhe
di testo, se non addirittura a fare “reverse engineering”
della logica operativa di funzionamento dell’apparato.
In aggiunta alle tecniche di isolamento sopra elencate
non va trascurato il fatto che questi dispositivi si connet-
tono frequentemente a molti altri presenti nel mondo
esterno, ed è necessario proteggere con cura ognuna
di tali connessioni. In un simile contesto, il minimo che
uno sviluppatore possa fare è di abilitare e configurare
un firewall, nonché eseguire attività di stress testing delle
connessioni di rete ed analisi di penetrazione, utilizzan-
do i numerosi strumenti pubblicamente reperibili.
L’integrazione di funzionalità
tipiche della IoT all’interno
dei dispositivi medicali offre
preziose opportunità