Table of Contents Table of Contents
Previous Page  12 / 28 Next Page
Information
Show Menu
Previous Page 12 / 28 Next Page
Page Background

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à