Il mercato dei dispositivi medici è tra i più ostici in termini di regolamentazione. Rendere un dispositivo medico o un’applicazione software che gira su uno di questi dispositivi idonei alla loro commercializzazione significa soddisfare degli standard sempre più stringenti, a partire dalla conformità in termini di cyber sicurezza. Vediamo in questo articolo che cosa significhi essere sicuri in topologie IoT che coinvolgono appunto dispositivi medici. La versione aggiornata del Medical Device Regulation (MDR) entrerà in vigore ufficialmente nella primavera 2021, dopo un ritardo di un anno sulla tabella di marcia dovuto, ancora una volta, alla pandemia COVID-19.
Il nuovo MDR si metterà al passo con i tempi e si occuperà di regolamentazioni per il software in uso dai dispositivi medici e, quindi di conseguenza, dell’intero ecosistema IT (inclusi hardware, network e accessi). Inutile dire che, in pratica, uno dei grossi cambiamenti che caratterizzeranno il nuovo MDR riguarderà una maggiore attenzione verso la cyber sicurezza. D’altro canto, non è difficile credere che gli ecosistemi IT aventi a che fare con dispositivi medici che richiederanno una strategia solida in termini di sicurezza siano gli ecosistemi IoT. Questo soprattutto grazie alla diffusione della tecnologia 5G che porterà alla piena realizzazione delle architetture IoT, ivi incluse quelle che coinvolgono dispositivi medici.
Verso l’automatizzazione delle applicazioni mediche IoT
Senza aspettare la promulgazione del MDR, si può (e anzi si consiglia) a chi progetta dispositivi medici (per un uso in un ecosistema IoT e non) di farlo già con i massimi standard di sicurezza. Alcuni tra questi dispositivi medici utilizzati in applicazioni IoT sono ad esempio le pompe a insulina. Inoltre, il tipo di servizio che si vuole dare a un paziente che soffre di diabete attraverso le pompe a insulina sta cambiando. Sia i grossi giganti nell’industria dei dispositivi medici (e.g. Medtech) che le piccole e medie imprese innovative (come la francese Diabeloop) stanno investendo risorse affinché al paziente possa essere somministrata la giusta dose di insulina automaticamente, senza il suo contributo attivo, grazie ad algoritmi di intelligenza artificiale. In questo tipo di configurazione, un detector di glucosio rileva in maniera intermittente (di solito ogni cinque minuti) il livello di glicemia nel sangue. L’algoritmo di intelligenza artificiale riesce a computare l’esatta quantità di insulina che la pompa deve rilasciare prendendo come input sia i dati rilevati dal detector del livello glicemico, sia i dati personali del paziente relativi ai pasti consumati e all’attività fisica svolta durante la giornata. Ed è il paziente, interagendo con la corrispondente applicazione da smartphone (o tablet), che si farà carico di inserire i dati sopra detti concernenti il proprio stile di vita. Tale algoritmo di intelligenza artificiale può essere ulteriormente irrobustito da un ulteriore algoritmo di gestione dei dati medici che consente, su autorizzazione del paziente stesso, la consultazione di tali dati da parte del medico curante o di un altro operatore sanitario che ne monitorano lo stato di salute.
In cosa consiste una topologia IoT con dispositivi medici
In questa situazione, in cui esiste un approccio automatizzato all’erogazione del servizio medico al paziente, il tipo di topologia che si viene a creare è IoT perché coinvolge più dispositivi in locale (detector, pompa a insulina e smartphone) e un back end dove di fatto viene ospitato il software che regola l’erogazione del servizio (algoritmo di intelligenza artificiale e algoritmo di gestione dei dati).
Il detector comunica allo smartphone ogni cinque minuti il livello di glicemia rilevato nel sangue. Lo smartphone funge in questo caso da gateway, perché a sua volta inoltra tali dati al back end dove il SW dell’applicazione viene fatto girare. Assieme ai dati trasmessi dal detector, lo smartphone invia al back end anche i dati inseriti manualmente dal paziente che riguardato il proprio stile di vita. Una volta che la giusta dose di insulina da erogare è stata computata, tale informazione viene trasmessa dal back end allo smartphone e, a sua volta, dallo smartphone alla pompa di insulina per l’effettiva erogazione dell’ormone. Lo smartphone funge come supporto all’interfaccia utente dell’applicazione, dove appunto il paziente può inserire dati e dove i rilevamenti del livello di glicemia e la dose di insulina computata possono essere dallo stesso consultati. Oltre a questa funzione di interfaccia utente, la funzione più importante dello smartphone in questa configurazione IoT è, come già accennato sopra, quello del gateway.
Il detector e la pompa a insulina non avrebbero potuto infatti comunicare direttamente con il back end e, rispettivamente, mandargli e ricevere dati. Questo perché dispositivi come il detector e la pompa a insulina (come anche un pacemaker) possono comunicare solamente attraverso Bluetooth. Più precisamente, il protocollo di comunicazione utilizzato da questi dispositivi è il Bluetooth Low Energy (BLE). Questo perché i dati inviati e ricevuti non sono né continui né ingenti come ad esempio quelli di uno speaker che suona musica secondo un’applicazione scaricata su uno smartphone. D’altro canto, un back end (che può essere un Cloud o un qualsiasi server) comunica solo attraverso il network IP e, più precisamente, attraverso un protocollo http. Uno smartphone invece può chiaramente comunicare in entrambi i modi e riesce quindi a ritrasmettere le misure di tasso glicemico al back end modulandoli per essere inviati attraverso Internet al back end e, viceversa, a ricevere i dati dal back end e rimodularli in modo da poterli inoltrare alla pompa a insulina via BLE.
Come rendere sicura una topologia IoT che consiste di dispositivi medici
Ora che lo scheletro di una topologia IoT sviluppata per l’erogazione di un servizio medico tale quello descritto sopra, cerchiamo di capire come possiamo rendere tale servizio sicuro. Per sicurezza si intende in questo caso la protezione della confidenzialità, dell’integrità e dell’autenticità dei dati medici generati e trasmessi in questo tipo di ecosistema (e non della così detta “safety” del dispositivo medico, che non viene trattata in questo articolo). Chiaramente sta alla crittografia rendere sicuri i dati medici secondo i parametri della confidenzialità, dell’integrità e dell’autenticità attraverso la configurazione di canali sicuri di comunicazione.
Per quanto riguarda la comunicazione via internet tra lo smartphone e il back end, il canale sicuro si ottiene quando il protocollo http diventa protocollo https attraverso l’utilizzo del protocollo Transport Layer Security (TLS) che cifra il canale e autentifica le due parti che vogliono comunicare con delle firme digitali.
Per quanto riguarda invece la comunicazione sicura tra dispositivi medici e smartphone, la situazione si complica leggermente perché molto spesso tali dispositivi non possiedono le capacità computazionali per eseguire gli algoritmi crittografici necessari alla configurazione del protocollo TLS per comunicazioni BLE né tantomeno lo spazio di memoria necessario per lo stoccaggio di tali chiavi crittografiche.
La tendenza che si sta facendo sempre più largo nel settore è quella di incamerare nel chip del dispositivo medico un aggiuntivo componente hardware detto Secure Element (SE). Un SE è un dispositivo che funziona come un Hardware Security Module (HSM) in miniatura in quanto è in grado di generare chiavi crittografiche e supporta gli algoritmi di cifratura, di firma, e di scambio delle chiavi tipici del protocollo TLS per la comunicazione sicura. Come con gli HSM, esistono procedure per testarne la sicurezza. Per gli SE che risultano resilienti ai cosiddetti attacchi side-channel e attacchi di fault injection (i tipici attacchi contro l’hardware), vengono emesse delle certificazioni particolari. Tra le più note troviamo le certificazioni “Active Shield” e “EAL5+-certified”.
Naturalmente, rispetto a un HSM, gli SE riescono a generare chiavi molto più lentamente, hanno meno possibilità di stoccaggio e offrono una suite di primitive crittografiche molto ridotta. Rimangono però la miglior soluzione al momento per rendere sicura un’applicazione IoT che tratta dati sensibili come quelli medici. Un HSM (o, in alternativa, un servizio Cloud di HSM) è invece l’opzione da adottare a livello del back end, visto che di solito un server dedicato ha abbastanza spazio per ospitarlo.
Conclusioni
È certo che l’MDR che presto entrerà in vigore renderà ancora più stringenti le regolamentazioni di conformità per i dispositivi medici, specialmente per quanto riguarda la cyber sicurezza. Per i dispositivi medici che fanno parte di un ecosistema IoT e che comunicano attraverso Bluetooth si può già presumere che verrà richiesta la configurazione di un canale di comunicazione sicuro. Il metodo più accreditato per farlo è quello dell’incameramento di un SE all’interno del dispositivo stesso in modo che anche il dispositivo riesca a computare quelle primitive crittografiche necessarie per l’implementazione di un canale crittato e autenticato.
