EO_462

XII

Medical

MEDICAL 14 -

MAGGIO 2017

gine integrato. Un crypto engine è un modulo indipen-

dente progettato per scaricare il processore primario del

carico computazionale legato al lavoro di cifratura/deci-

fratura. Essendo il crypto engine racchiuso in un blocco

IP indipendente, per gli hacker risulta più difficoltoso

individuare delle tecniche che consentano di accedere

al processo crittografico. L’utilizzo di un crypto engine

può avere un impatto enorme sulla capacità dell’appli-

cazione di manipolare dati sicuri in modo rapido ed ef-

ficiente.

Il partizionamento del dispositivo

Utilizzando la tecnologia ARM TrustZone (o memoria

protetta) è possibile partizionare le risorse di sistema

riservate alla memorizzazione delle chiavi di sicurezza,

impedendone l’accesso da parte di malware o di appli-

cazioni non autorizzate. L’isolamento dell’hardware

può essere esteso anche oltre la memoria di sistema, in-

cludendo le regioni di memoria destinate all’indirizza-

mento dell’I/O delle periferiche. Le risorse di sistema

possono dunque essere certificate come “sicure”, il che

ne consentirà l’accesso solo da parte delle applicazioni

sicure, in esecuzione all’interno del dominio sicuro.

Il software, la “forza vitale” all’interno di ogni dispositivo me-

dicale indossabile

Come illustrato, la selezione dell’hardware giusto, do-

tato delle dovute caratteristiche di sicurezza, è il primo

importante passo per la costruzione di un dispositivo

medicale indossabile sicuro. Senza il software appro-

priato, tuttavia, l’utilizzo delle funzionalità di sicurezza

hardware può comportare lo sviluppo di codice aggiun-

tivo, con un significativo aumento dei costi, dei tempi e

della complessità dello sviluppo. Oppure, peggio anco-

ra, l’utilizzo del software sbagliato può portare al com-

pleto inutilizzo delle funzionalità di sicurezza. Si rivela

quindi essenziale la presenza di un sistema operativo,

un OS (Operating System), dotato di un framework che

supporti la presenza all’interno del silicio dei blocchi IP

dedicati alla sicurezza, quali un crypto engine e le fun-

zioni di secure boot, ed assista nell’utilizzo dei relativi

algoritmi e della crittografia. L’OS appropriato deve in-

cludere un framework per l’implementazione di una

chain of trust che garantisca l’autenticazione del codice

prima della sua esecuzione. Ciò è indispensabile per ve-

rificare che il software non sia stato manomesso. Inoltre,

poiché le informazioni personali di natura sanitaria sono

sia confidenziali che di importanza vitale, andrebbe pre-

so in considerazione anche l’utilizzo di un OS in grado

di memorizzare i dati in file di tipo sicuro. Il che va ben

oltre l’utilizzo di una semplice protezione basata su pas-

sword. Una protezione aggiuntiva realizzata mediante

la crittografia dei dati, atta a garantire che essi possano

essere letti e modificati solo dai soggetti autorizzati, è

dunque essenziale per la sicurezza complessiva del dispo-

sitivo. Poiché i dispositivi indossabili sono caratterizzati

da stringenti vincoli di risorse, è evidente la necessità di

ricorrere a librerie di funzioni crittografiche con una fo-

otprint ridotta ma in grado di offrire funzionalità equi-

valenti a quelle delle diffuse librerie OpenSSL. A causa

delle limitazioni di memoria, inoltre, il sistema operativo

deve supportare anche l’esecuzione in-place e il carica-

mento dinamico sia per il runtime sia per il file system.

Quanto al file system, è necessario che esso supporti le

funzioni di crittografia e di hashing, per un’efficace pro-

tezione contro la compromissione dei dati.

Upgrade e aggiornamenti

Un requisito chiave per i dispositivi medicali indossabi-

li consiste nella possibilità di aggiornare il dispositivo a

fronte del rilascio di aggiornamenti relativi alla sicurez-

za. I produttori di SoC, che sono soggetti a forti pressioni

legate ai fattori di time-to-market, normalmente monta-

no a bordo dei propri chip una versione di Linux, oppu-

re di un RTOS freeware, insieme ad altri componenti e

driver open source o proprietari. Il produttore del dispo-

sitivo indossabile, d’altro canto, sceglie il chip da utilizza-

re in base sia al prezzo che alle funzionalità, ivi incluso il

software a corredo. Il problema legato a questo scenario

consiste nel fatto che, se viene identificato un problema

Fig. 2

– Il modello di sicurezza basato sulla

chain of trust garantisce che ogni file scaricato

venga firmato ed autenticato,

a partire dal boot loader e salendo

fino al livello applicativo