UNIVERSITÀ DEGLI STUDI DI TRIESTE

Facoltà di Ingegneria

Corso di Laurea triennale

INGEGNERIA INFORMATICA

Progetto e realizzazione di

un'applicazione per dispositivi mobili per

la rilevazione di features biometriche

finalizzata alla re-autenticazione continua

Relatore Laureando

prof. Eric Medvet Francesco Bianchi

Anno accademico 2014/2015

Alle mie persone speciali

Ci siamo arrivati

Insieme

Indice dei contenuti

Introduzione ...........................................................................................................................................................6

Telefoni sempre più a rischio ...............................................................................................................................6

Un passato più semplice da proteggere .........................................................................................................7

Cambiano le abitudini ma non quelle legate alla sicurezza ........................................................................8

Il rischio per le nostre informazioni è in continua crescita ..........................................................................9

Cresce la consapevolezza e con essa le soluzioni ....................................................................................... 10

Il rischio maggiore: l’accesso fisico al terminale ........................................................................................ 10

Esempi e vulnerabilità dell’autenticazione a inizio sessione ................................................................... 12

L’autenticazione continua come possibile soluzione ................................................................................ 12

Esempio di applicazione realizzata in ambiente desktop ......................................................................... 14

La nostra soluzione in ambito mobile .............................................................................................................. 16

Struttura ........................................................................................................................................................... 16

Caratteristiche biometriche ........................................................................................................................... 17

Criterio di scelta adottato .......................................................................................................................... 18

Caratteristiche biometriche selezionate ................................................................................................... 19

Il mio contributo al progetto: il rilevatore di impronte biometriche ........................................................... 20

Importanza del rilevatore realizzato all’interno della soluzione complessiva ...................................... 20

Requisiti del rilevatore ................................................................................................................................... 21

Perché una tastiera ......................................................................................................................................... 22

Perché Android ............................................................................................................................................... 23

La tastiera realizzata ....................................................................................................................................... 24

Funzionamento generale della tastiera ........................................................................................................ 25

Indicatori biometrici monitorati ................................................................................................................... 26

Evento Touch ............................................................................................................................................... 26

Campionamento accelerometro ................................................................................................................ 27

Campionamento giroscopio ...................................................................................................................... 27

Implementazione dei rilevatori per gli indicatori biometrici monitorati ............................................... 28

Evento Touch ............................................................................................................................................... 28

Campionamento accelerometro ................................................................................................................ 29

Campionamento giroscopio ...................................................................................................................... 29

Gestione del file di log ................................................................................................................................... 31

Struttura del file di log ............................................................................................................................... 31

Problemi incontrati ......................................................................................................................................... 32

Trovare una tastiera open source ............................................................................................................. 32

Documentazione di difficile consultazione per sviluppi medio-complessi ....................................... 33

Far convivere listener con campionamento ............................................................................................ 33

Timestamp diversi a seconda dispositivo ............................................................................................... 34

Approcci alternativi esplorati per la realizzazione del rilevatore ........................................................... 35

Bibliografia .......................................................................................................................................................... 38

Ringraziamenti .................................................................................................................................................... 40

Introduzione

Il problema della sicurezza informatica è un tema che tutti riconoscono come importante ma a cui ben

pochi prestano attenzione.

Questo è particolarmente vero se parliamo di smartphone, dispositivi sempre più ricchi di

funzionalità di uso quotidiano e di conseguenza di dati sensibili che spesso sono di grande valore per

un malintenzionato. Purtroppo alla rapidissima evoluzione tecnologica dei nostri dispositivi mobili

non è corrisposta una nostra evoluzione in termini di consapevolezza dei rischi che corriamo e delle

buone abitudini di utilizzo del dispositivo. Spesso succede invece che continuiamo a usare il nostro

dispositivo con la stessa leggerezza di quando era uno strumento in grado soltanto di effettuare e

ricevere chiamate.

Per cercare di ovviare al problema il Machine Learning Lab dell’Università degli Studi di Trieste ha

ideato come possibile soluzione un sistema di sicurezza che rilevi costantemente un utilizzo non

autorizzato del dispositivo. Consapevoli che un qualsiasi sistema che infici l’immediatezza

dell’esperienza utente cui siamo ormai abituati non sarebbe mai accettato da un utilizzatore medio di

smartphone, il sistema è stato progettato affinché effettui i suoi controlli in modo non intrusivo in

modo da risultare completamente trasparente per l’utente.

La soluzione che è stata ideata si basa su un sistema intelligente che analizza le misurazioni

biometriche raccolte durante l’utilizzo del terminale monitorato al fine di identificare accessi non

autorizzati.

Il mio contributo al progetto è stata la progettazione e realizzazione del modulo di raccolta delle

rilevazioni biometriche di utilizzo del terminale. La forma scelta per la realizzazione del modulo è

stata quella di un’applicazione per dispositivi mobili Android.

Telefoni sempre più a rischio

Oggi i telefoni cellulari sono molto più a rischio di quanto non fossero fino pochi anni fa. I fattori di

rischio si sono moltiplicati in termini quantitativi e la loro serietà si è di gran lunga aggravata.

Per contro, le abitudini di un utente medio non si sono evolute di pari passo per rendere più sicure le

informazioni contenute nel dispositivo.

Analogo il discorso per quanto gli sforzi dei maggiori produttori di telefoni nel migliorare le

funzionalità offerte. Spesso infatti è stata messa poca enfasi sulla soluzione dei problemi legati alla

sicurezza per favorire aspetti più appetibili e di maggior impatto dal punto di vista del marketing

come miglioramenti lato usabilità e gestione dei contenuti multimediali.

Un passato più semplice da proteggere

Per i primi 20 anni della loro storia i telefoni cellulari si sono limitati ad essere, appunto, dei telefoni

portabili. L’unica informazione che l’utente vi poteva salvare era l’elenco dei propri contatti telefonici.

Per quanto molti utenti potessero trovare fastidioso il fatto che la propria rubrica venisse consultata da

occhi indiscreti o andasse distrutta, si trattava comunque di dati da cui un malintenzionato sarebbe

difficilmente riuscito a trarne guadagno e che probabilmente erano già reperibili da altre fonti

pubbliche e di facile accesso (es. elenco del telefono). Il rischio più grosso legato ad un utilizzo non

autorizzato del proprio dispositivo consisteva nel fatto che un malintenzionato cominciasse ad

effettuare conversazioni costose che sarebbero andate ad aumentare considerevolmente i costi in

bolletta. Rischio fortemente limitato dall’introduzione di contratti di telefonia prepagati.

Il tipo di operatività allora possibile prevedeva un utilizzo attivo e consapevole del dispositivo: per

iniziare una conversazione era necessario afferrare fisicamente il terminale. Una volta terminata la

conversazione, prima di riporre il dispositivo in una tasca o nella borsa, si tendeva ad attivare il

“blocco tasti” per evitare partissero chiamate indesiderate dovute alla digitazione involontaria dei

pulsanti del telefono.

In questo scenario la sessione di utilizzo era chiaramente demarcata e caratterizzata da azioni

deliberate da parte dell’utente. Di fatto il terminale smetteva di funzionare una volta lasciate le mani

del proprietario e riprendeva a farlo solo una volta sbloccato. Un sistema di sicurezza basato su un

codice di sblocco da inserire a inizio sessione che entrasse automaticamente in azione una volta

inserito il “blocco tasti” al termine della sessione stessa era una soluzione che permetteva di

proteggere i pochi dati rilevanti contenuti nel dispositivo senza appesantire in modo particolare

l’esperienza utente.

A metà degli anni 90 i cellulari vedono l’introduzione della possibilità di inviare e ricevere SMS.

Inizialmente tale funzionalità è stata usata principalmente da adolescenti che ne hanno quindi

condizionato le modalità di utilizzo. Le informazioni scambiate tramite SMS erano per lo più di

carattere personale, quindi ancora una volta difficilmente interessanti per un malintenzionato.

I messaggi inviati e ricevuti venivano salvati automaticamente sul dispositivo ma lo scarso spazio a

disposizione costringeva continuamente a selezionare i pochi messaggi da conservare e a cancellare

tutti gli altri. Tipicamente i messaggi che si sceglieva di salvare erano quelli che avevano un valore

affettivo più alto e che quindi raramente potevano risultare interessanti per un malintenzionato.

Dal punto di vista della sicurezza cominciavano a presentarsi le prima problematiche in materia di

difesa della privacy ma ancora non si correva nessun pericolo concreto in caso di furto dei propri dati.

Le modalità di utilizzo e le problematiche connesse rimanevano quindi invariate per altri 10 anni

andando a consolidare abitudini ormai sempre più radicate. Non presentandosene la necessità, anche i

sistemi di sicurezza impiegati non vedevano un’evoluzione significativa e restavano di fatto invariati.

Cambiano le abitudini ma non quelle legate alla sicurezza

Il 29 giugno 2007 Apple rilascia sul mercato il primo iPhone e il mondo della telefonia mobile cambia

drasticamente volto.

Per 30 anni i cellulari ci avevano permesso di fare poco più che qualche telefonata e scambiarci

messaggi, per lo più in formato testuale. L’iPhone ci permette invece di avere in tasca la potenza di un

computer sempre connesso a internet.

Ci troviamo quindi improvvisamente a poter gestire la nostra posta, gallerie di immagini ma anche

conti correnti, analisi mediche e prenotazioni aeree in mobilità, indipendentemente dal posto in cui ci

troviamo.

In brevissimo tempo i nostri cellulari si riempiono di applicazioni che ci permettono di gestire ogni

aspetto della nostra vita. Laddove non sia ancora presente un’applicazione c’è sempre la possibilità di

connettersi al sito di interesse tramite uno degli svariati browser a nostra disposizione.

Prima dell’introduzione degli smartphone dovevamo tenere nota di tutte le attività che volevamo

compiere, aspettare di arrivare a casa, accendere il computer e ritagliarci uno spazio di tempo

espressamente dedicato allo smaltimento di tali attività. Il risultato è che spesso ci dimenticavamo

cose o per pigrizia le rimandavamo indefinitamente. Ora è invece molto più facile e immediato

controllare i nostri investimenti, fare acquisti o consultare la nostra agenda nei ritagli di tempo,

quando stiamo aspettando il bus o siamo in fila alla cassa del supermercato o siamo in pausa al lavoro.

Ci basta infilare una mano in tasca, sbloccare il telefono e siamo operativi in tempo zero. È un gesto

che ci è familiare, che ormai fa parte della nostra cultura e delle nostre abitudini quotidiane. È un

gesto che ormai facciamo talmente di continuo da trovare spesso fastidioso bloccare il telefono ogni

volta che abbiamo terminato un’attività. Preferiamo invece che dopo un tempo prestabilito sia il

telefono ad attivare autonomamente l’equivalente di un blocca-schermo. Preferiamo essere pronti a

leggere istantaneamente ogni notifica o messaggio che possa arrivare pochi secondi dopo che

abbiamo posato il telefono.

Analogamente comincia a darci sempre più fastidio sbloccare il telefono a inizio sessione. McAfee

stima che il 36% della popolazione mondiale preferisca lasciare il proprio telefono non protetto (fonte

[1]).

Per quanto sconsiderato da un punto di vista della sicurezza è sicuramente una scelta comprensibile

visto che ormai in media controlliamo il nostro telefono ogni 5 minuti per un totale di 221 accessi medi

al giorno (fonte OnePoll [2]).

221 accessi per una durata complessiva media di 195 minuti di utilizzo al giorno (fonte [3]) significa

che ogni volta che accediamo al nostro dispositivo ci aspettiamo di riuscire a consultare tutte le

informazioni che ci interessano in meno di un minuto. Poiché tipicamente ad ogni accesso vengono

consultate più applicazioni (messaggistica istantanea, posta elettronica, social network, news feed…) è

necessario evitare ogni minimo spreco di tempo.

Per questo i dati vengono precaricati mentre non stiamo utilizzando il telefono in modo da essere

pronti in qualsiasi momento desiderassimo consultarli. Per questo veniamo incentivati a salvare le

nostre credenziali sul dispositivo in modo da non doverle reinserire ogni volta che vogliamo accedere

ad un servizio. Per questo ci viene permesso di salvare i dati della nostra carta di credito in modo da

permetterci di effettuare un acquisto con un singolo click.

Il risultato è duplice. Come utilizzatori possiamo godere di esperienze utente sempre fluide in cui

l’accesso al dato è istantaneo e l’interconnessione con altri sistemi è costante. Come malintenzionati

disponiamo ora di una sorgente facilmente individuabile da cui poter recuperare praticamente

qualsiasi informazione importante ci interessi sapere su una persona.

Il rischio per le nostre informazioni è in continua crescita

I criminali informatici che derivano i propri guadagni illeciti dal possesso di informazioni personali

sono da tempo consapevoli di questa evoluzione nell’utilizzo dei nostri terminali e del loro crescente

valore in termini di informazioni contenute. Ormai da anni infatti si impegnano con dedizione ad

inventare nuovi modi per aggirare le nostre protezioni ed entrare così in possesso dei nostri dati.

Trend questo che non accenna a diminuire ma sta invece crescendo raggiungendo proporzioni

disarmanti.

Significativo il dato riportato dalla famosa azienda di sicurezza McAfee in un report del 2014 [4]

secondo cui in poco più di 2 anni il numero totale di malware esistenti per dispositivi mobile è

cresciuto di quasi 2 ordini di grandezza. Altrettanto allarmante il fatto che nello stesso periodo

intervallo di tempo il tasso di introduzione di nuovi malware è grosso modo quadruplicato.

Ma i malware sono soltanto uno dei modi per sfruttare in modo fraudolento i nostri dati.

Sempre più sono gli exploit software che cercano di sfruttare falle di sicurezza e bug software in

generale per prendere il controllo, spesso totale, dei nostri dispositivi. Il fine principale è quello di

poter accedere senza restrizioni alle nostre informazioni personali ma recentemente si sono registrati

altri scopi. Controllare un dispositivo moderno significa disporre di un calcolatore di potenza non

trascurabile che può compiere per il controllore qualsiasi azione questi desideri lasciando che sia il

proprietario originario a farne le spese, sia in termini economici che legali. In questo modo l’attaccante

può per esempio trasformare il dispositivo di un'altra persona in una macchina per la creazione di

BitCoin senza doversi preoccupare del pagamento della bolletta dell’energia necessaria ad alimentare

il calcolatore o può lanciare attacchi informatici da un dispositivo non proprio in modo da non poter

essere rintracciato come mandante originario.

Crescente anche l’adattamento al contesto mobile di tecniche già in uso da tempo in ambiente

desktop.

Cominciano a diffondersi BOT (script che simulano il comportamento umano) che tramite messaggi di

servizi di messaggistica istantanea come WhatsApp e Skype cercano di adescare utenti poco accorti

facendo loro credere di essere stati contattati da una persona vera.

Si espande il fenomeno del phishing per cui si cerca di carpire le credenziali di un utente invitandolo

tramite email opportunamente camuffata ad inserirle su un sito civetta.

Cresce il numero di strumenti e persino di tutorial dedicati a carpire ogni informazione scambiate da

un dispositivo mobile connesso ad una rete wi-fi no protetta tramite tecnica di “man in the middle”.

Cresce la consapevolezza e con essa le soluzioni

Tutti i rischi presentati finora sono sempre più concreti e difficili da evitare.

Fortunatamente le aziende cominciano a rendersene conto e stanno perciò cominciando ad attrezzarsi.

Infonetics Research, azienda specializzata in ricerche di mercato, stima che un terzo della spesa

mondiale delle aziende in materia di sicurezza informatica sia dedicata a proteggere dispositivi

mobili. Spesa che negli ultimi anni è cresciuta a un ritmo minimo del 60% e che si prevede sfiorerà gli

11 miliardi di dollari nel 2017 (fonte [5]).

Secondo Gartner invece bisognerà aspettare almeno il 2017 perché la consapevolezza di questi pericoli

cominci a farsi strada anche fra gli utenti privati (fonte [6]).

In questo comune sforzo collettivo finalizzato al rendere i nostri dispostivi sempre più sicuri noi

abbiamo deciso di dare il nostro contributo focalizzandoci su uno dei possibili attacchi che non

abbiamo ancora citato.

Si tratta probabilmente dell’attacco più pericoloso ed allo stesso tempo più semplice da perpetrare e

che forse, proprio per questo motivo, viene di solito sottovalutato: l’accesso fisico al nostro dispositivo

da parte di un malintenzionato.

Il rischio maggiore: l’accesso fisico al terminale

La maggior parte delle tecniche di attacco presentate finora garantisce all’attaccante un accesso

limitato alle informazioni salvate sul nostro dispositivo. Inoltre per poter essere applicate richiedono

venga speso tempo, soldi ed energie nella preparazione o reperimento di software adibiti allo scopo,

nell’acquisizione di competenze specifiche ed altamente specializzate, nello studio di un’infrastruttura

esistente e/o nell’installazione di un’infrastruttura di supporto.

Sicuramente i costi e tempi che un malintenzionato deve affrontare prima di poter condurre il suo

attacco stanno diminuendo ma sono ancora enormemente sproporzionati rispetto all’economicità ed

immediatezza di un interazione fisica con il dispositivo bersaglio.

Un attaccante che riesca a mettere le mani su un cellulare ed ad aggirare le protezioni iniziali ne

assume il controllo completo.

Per un attaccante in queste condizioni diventa banale accedere senza restrizioni a tutti i dati salvati sul

dispositivo. Può infatti sfogliare le gallerie di immagini, leggere tutti i messaggi inviati e ricevuti dal

cellulare, consultare tutte le email scaricate localmente (tendenzialmente tutte quelle risalenti agli

ultimi 30 giorni), cercare fra le note password e numeri di carte di credito con la stessa libertà di cui

gode il proprietario del dispositivo. Analogamente può capire velocemente interessi e pattern di

utilizzo del dispositivo da parte del proprietario controllando la cronologia di navigazione internet e

le app installate.

Discorso non dissimile per tutti quei dati che sono salvati in remoto ma vengono regolarmente

acceduti dal dispositivo mobile. Come abbiamo visto spesso le credenziali di accesso ai vari servizi

vengono salvate sul dispositivo stesso per cui è questione di attimi connettersi ai vari servizi di

storage cloud, conti correnti online e cartelle cliniche virtuali saltando direttamente la procedure di

autenticazione al servizio.

Ad aggravare la situazione l’estrema difficoltà che si ha nel tracciare un’operazione fraudolenta

effettuata tramite uno dei servizi per cui sono state salvate le credenziali. In uno scenario simile

l’attaccante riesce infatti a impersonificare in modo assai convincente la vittima perché

automaticamente in grado di fornire tutte le informazioni di accesso richieste. Anche gli eventuali

ulteriori controlli effettuati su un identificativo unico del dispositivo vengono completamente

nullificati perché le richieste avvengono realmente dal dispositivo autorizzato.

C’è infine il rischio che il dispositivo venga manomesso in modo da poter essere controllato da remoto

secondo i tempi e le modalità più comode per l’attaccante.

Tutti i rischi qui esposti sono applicabili, sebbene con leggere sfumature, a qualsiasi tipo di

calcolatore. Diventano però particolarmente critici quando si parla di dispositivi mobili che per loro

stessa natura vengono continuamente spostati da un luogo all’altro. Questi spostamenti sono spesso

così frequenti e imprevedibili da rendere di fatto impossibile assicurarsi costantemente che il luogo in

cui si sta portando il dispositivo sia sicuro.

È relativamente semplice mettere in sicurezza un PC desktop. Normalmente conosco la rete a cui lo

connetto e chi altri sia autorizzato a farlo, posso monitorare l’accesso all’edificio e alla stanza in cui è

installato, tendenzialmente il computer è raggiungibile solo da persone che conosco e di cui mi fido. È

molto più difficile ricreare la stesso ambiente sicuro nel ristorante che quel giorno decido di provare

per la prima volta o nel negozio che attrae la mia attenzione ed in cui vado portando con me il mio

telefono.

Esempi e vulnerabilità dell’autenticazione a inizio sessione

Le tecniche di protezione attualmente esistenti ed già parzialmente utilizzate per prevenire i rischi

appena descritti sono tutte basate su un controllo effettuato a inizio sessione e che non è più richiesto

per la durata dell’intera sessione di utilizzo.

Di seguito riportiamo 10 tra i metodi più utilizzati per sbloccare un telefono (fonte [7]):

Inserimento di un pin numerico

Inserimento di un pattern grafico

Inserimento di una password

Ripetizione di una sequenza di colpi sullo schermo

Riconoscimento dell’impronta digitale

Riconoscimento facciale

Prossimità con dispositivo NFC fidato

Prossimità con dispositivo Bluetooth fidato

Connessione ad una rete WiFi fidata

Purtroppo le prime 7 delle 10 tecniche elencate sono facilmente aggirabili. Basta osservare un tentativo

di autenticazione da parte dell’utente (shoulder surfing) o presentare al telefono un’immagine [8] o

video [9] di qualità sufficientemente elevati. Le rimanenti 3 richiedono uno sforzo maggiore ma sono

tutt’altro che invalicabili se l’attaccante è determinato.

A volte all’attaccante non è nemmeno richiesto di aggirarle. Per le abitudini di utilizzo descritte

precedentemente è infatti tipico che un utente decida non attivare la protezione del dispositivo

immediatamente dopo aver finito di utilizzarlo ma lasci invece che questo avvenga automaticamente

dopo un periodo di inattività prefissato. Tipicamente questa temporizzazione è impostata a 30 secondi

ma non è raro venga estesa a favore di una maggior praticità. Basta che per un qualsiasi motivo il

proprietario del dispositivo debba lasciare incustodito il cellulare e questi resterà privo di protezione

alcuna per tutto il tempo rimanente all’attivazione automatica dell’autenticazione.

Non dimentichiamoci infine che secondo una ricerca McAfee soltanto 2 persone su 3 decidono di

proteggere il proprio telefono con qualche forma di autenticazione (fonte [1]).

L’autenticazione continua come possibile soluzione

Il principale problema dell’autenticazione a inizio sessione (anche detta statica), è che una volta

aggirata non offre più alcuna protezione per tutta la durata della sessione di lavoro.

Per risolvere questo problema si stanno studiando nuove tecniche di sicurezza che autentichino

continuamente l’utente. In questo modo, quandanche un attaccante riesca ad aggirare un primo

controllo, si troverà dopo brevissimo tempo (tipicamente parliamo di secondi) a superare una seconda

barriera, e poi una terza e così via.

La sessione di lavoro risulta così protetta per tutta la sua durata e non soltanto nel momento in cui

inizia.

Inoltre, se l’intervallo di tempo che intercorre tra una procedura di autenticazione e l’altra è

sufficientemente piccolo e il controllo effettuato non immediato da aggirare, è probabile l’attacco

diventi troppo oneroso perché possa essere ancora considerato conveniente. Diventa addirittura

impossibile da perpetrare se tutto il tempo a disposizione del malintenzionato deve essere impiegato a

cercare di superare il successivo step di autenticazione.

Ci sono molti modi per implementare un meccanismo di autenticazione continua.

Farlo sfruttando le stesse tecniche descritte per la protezione del telefono a inizio sessione non è di

fatto possibile perché:

Richiedere all’utente di re-inserire di continua delle credenziali in una qualche forma è troppo

invasivo e rovinerebbe la sua esperienza di utilizzo al punto da portarlo presto a disattivare la

funzionalità

Spesso le autenticazioni a inizio sessione si basano su un segreto che può essere considerato

immutabile nel tempo. Una volta scoperto, diventa banale ripeterlo ad ogni richiesta di ri-

autenticazione

Per ovviare a questi 2 problemi recentemente si sono studiate tecniche di autenticazione basate su

caratteristiche biometriche comportamentali. Sono cioè tecniche che analizzano continuamente il

comportamento dell’utente corrente e confrontano i dati raccolti con altri dati raccolti in precedenza

per lo stesso utente.

Per essere applicate tipicamente richiedono la presenza sul client con cui sta interagendo l’utente da

monitorare di un software capace di generare un flusso di dati che descriva il comportamento

dell’utente. Questi dati vengono poi inviati ad una componente server (che non deve risiedere per

forza su un’altra macchina) che li confronta con altri dati raccolti in precedenza per lo stesso utente e

considerati affidabili.

Se il comportamento rilevato viene considerato sufficientemente simile a quello già noto, all’utente

viene confermata l’autenticazione fino al controllo precedente. In caso contrario, il sistema può per

esempio intervenire inviando un messaggio di allarme, richiedendo l’inserimento di una parola

chiave, bloccando il dispositivo.

Si possono trovare in letteratura casi di implementazioni di autenticazione continua basati sulle

seguenti caratteristiche biometriche comportamentali:

Digitazione dei tasti di una tastiera [10] [11]

Traiettorie seguiti dal mouse durante i suoi spostamenti in combinazione coi click effettuati

[12] [13] [14] [15] [16] [17] [11]

Interazioni con touch-screen [18]

Esempio di applicazione realizzata in ambiente desktop

Anche il laboratorio di Machine Learning dell’Università di Trieste ha ideato una sua soluzione per

l’autenticazione continua basata su misure biometriche comportamentali [19].

La soluzione si concentra sull’ambiente desktop e si propone di verificare l’identità dell’utente mentre

naviga sul web da tramite monitoraggio delle dinamiche di utilizzo del mouse.

Per “verifica dell’identità” si intende il controllo effettuato dal sistema per determinare se l’utente

corrente sia veramente chi dichiara di essere. Viene ipotizzato che lo step di identificazione, in cui al

sistema è richiesto di riconoscere l’utente corrente all’interno di un insieme di utenti noti, sia già stato

effettuato esternamente alla soluzione.

Il software realizzato dal laboratorio è costituito da:

un modulo javascript per la rilevazione dei movimenti del mouse (Collector-C)

un proxy HTTP incaricato di iniettare il modulo javascript in tutte le pagine web visualizzate

dall’utente

un motore decisionale capace di verificare l’identità dell’utente in base ai movimenti rilevati

del mouse (Collector-C)

Il proxy inietta in ogni pagina web richiesta dall’utente il codice javascript del Collector-C.

In modo del tutto trasparente all’utente, sfruttando l’evento del DOM event e, il Collector-C rileva

continuamente timestamp, posizione del mouse e tipo di azione che ha scatenato l’evento (click,

doppio-click, movimento).

Ogni qualvolta il mouse risulta inutilizzato per almeno 500ms, il Collector-C crea un “feature vector”

utilizzando soltanto le ultime rilevazioni immediatamente precedenti il momento della creazione del

vettore.

I feature vector così creati vengono accumulati dal Collector-C e inviati in batch ogni pochi secondi al

modulo server Collector-C perché li usi come input di un algoritmo di machine learning di tipo

Support Vector Machine (SVM). A partire dai dati raccolti l’algoritmo riesce a identificare 39

caratteristiche biometriche (direzione, velocità, accelerazione, numero di cambi di direzione…).

I dati così computati vengono confrontati con i valori associati al profilo dell’utente che si vuole

verificare durante una fase di apprendimento off-line. Se il numero di confronti considerati negativi

supera una certa soglia definita per l’utente, il sistema genera un alert.

I risultati di questa soluzione sono stati decisamente incoraggianti. Sono infatti stati monitorati 2

diversi dataset di utenti. Il primo, composto da 8 persone che hanno lavorato per 4 settimane dalla

propria postazione, rappresenta una popolazione di persone che usano la soluzione integrata in una

specifica applicazione web. Il secondo dataset, composto da 18 utenti che hanno lavorato per 2

settimane da postazioni omogenee tra loro, copre lo scenario di un’organizzazione che adotti degli

standard in fatto di macchine date in dotazione dei suoi dipendenti e attivi per tutti i controlli di

autenticazione continua tramite proxy aziendale. In entrambi i casi, a seconda della durata del periodo

di apprendimento, si è raggiunto un livello di accuratezza di oltre il 90%, con massimi che hanno

raggiunto il 96.5%. Anche limitando il più possibile il periodo di apprendimento l’accuratezza minima

è stata comunque dell’83.3%.

Forti di questi risultati abbiamo pensato di ideare e realizzare una nuova versione della soluzione per

l’autenticazione continua questa volta pensata per l’ambito mobile.

La nostra soluzione in ambito mobile

Consapevoli dell’importanza di proteggere i dati salvati sui nostri smartphone dai rischi sempre

crescenti che li minacciano abbiamo cercato di ideare una soluzione che dia una risposta ai problemi

che abbiamo riscontrato essere tuttora irrisolti.

La soluzione si basa sulla tecnica dell’autenticazione continua per garantire la messa in sicurezza del

nostro dispositivo durante tutta la durata della sessione di lavoro. Per implementare un meccanismo

di autenticazione continua abbiamo deciso di sfruttare misurazioni biometriche rilevate per tutta la

durata dell’utilizzo del dispositivo.

Per evitare ogni possibile impedimento all’adozione della nostra soluzione abbiamo tenuto in gran

conto un’utenza sempre più impaziente ed esigente in termini di usabilità. Per questo la nostra

soluzione è pensata per operare in maniera completamente trasparente rispetto all’utente senza

necessità di intervento alcuno da parte sua se non in caso di rilevazione di un accesso non consentito.

Struttura

La nostra soluzione si compone principalmente di 3 moduli:

Rilevatore di misure biometriche

Motore decisionale in grado di riconoscere l’utente sulla base delle misure rilevate

Strumento di controllo del dispositivo

La figura sottostante ne rappresenta un semplice schema logico

Rilevatore (1)

Motore decisionale (2)

Controllare dispositivo (3)

Il principio di funzionamento è piuttosto semplice:

(1) Un rilevatore monitora costantemente il comportamento dell’utente e come questo interagisce con

il dispositivo. Per farlo sfrutta i rilevatori più comuni fra i dispositivi mobili moderni:

Schermo tattile

Accelerometro

Giroscopio

(2) I dati raccolti vengono inviati al motore decisionale che li analizza per cercare di definire così

un’impronta biometrica dell’utilizzatore corrente.

(3) Qualora il motore decisionale non riconosca l’impronta biometrica come autorizzata richiede

l’intervento dello strumento che controlla il dispositivo che in base alle circostanze può attendere il

risultato di un’ulteriore verifica, inviare una notifica d’allarme ad un indirizzo prestabilito o attivare

una qualsiasi altra misura cautelativa che potremo definire.

Caratteristiche biometriche

La biometria è la disciplina che studia come identificare i meccanismi di funzionamento di grandezze

biofisiche al fine di individuare dei valori che possano permettere ad un sistema tecnologico di

comportarsi in maniera diversa a seconda delle misure rilevate.

Perché una misura sia utilizzabile in biometria è importante presenti le seguenti caratteristiche ideali:

Deve essere universale, nel senso che tutti i soggetti osservabili devono possederla

Deve essere unica, ovvero non deve essere possibile trovare 2 individui per i quali vengano

individuati gli stessi valori per una stessa caratteristiche biometrica

Deve essere permanente, e quindi non variare significativamente nel tempo

Deve essere collezionabile, ovvero misurabile quantitativamente

È possibile definire svariate classificazioni da applicare alle caratteristiche biometriche. Una delle più

diffuse e intuitive è sicuramente quella che distingue tra caratteristiche fisiologiche e caratteristiche

comportamentali.

Sono dette caratteristiche fisiologiche tutte quelle caratteristiche che sono proprie di una persona e della

sua dimensione fisica. Rispondono alla domanda “come è fatto”.

Alcuni esempi di questo tipo di grandezze che siano già stati utilizzati come base per

l’implementazione di meccanismi di sicurezza software sono per esempio le curve che compongono le

impronte digitali, il tracciato della retina di un occhio, la fisionomia del volto.

Le caratteristiche comportamentali non sono invece legate allo stato di una persona ma alle azioni che

questa compie. Rispondo alla domanda “come si comporta”.

Sono caratteristiche comportamentali ad esempio l’impronta vocale rilevabile quando parliamo, la

firma che apponiamo sui documenti, lo stile con cui digitiamo su una tastiera, fisica o digitale che sia.

Generalmente le caratteristiche fisiologiche presentano una maggior rispondenza ai 4 requisiti

sopracitati rispetto a quelle comportamentali. In particolare per queste ultime spesso non è garantita

l’unicità perché con il giusto allenamento più o meno chiunque può imparare a simulare abbastanza

fedelmente il comportamento di un altro. Pensiamo per esempio a imitatori e ad insegnanti di

calligrafia. Inoltre le caratteristiche comportamentali sono più soggette a variare nel tempo tanto a

causa di scelte deliberate che dell’accumularsi di fattori ambientali. Un infortunio può modificare il

modo in cui camminiamo o usiamo un oggetto, l’abitudine a leggere notifiche sul cellulare e articoli

brevi può cambiare il modo in cui il nostro sguardo scorre il testo su un libro tradizionale, per motivi

estetici possiamo scegliere di esercitarci a modificare la nostra calligrafia.

Criterio di scelta adottato

Descrivere un’azione o un comportamento è più complesso che descrivere uno stato poiché un’azione

può essere vista come una sequenza di stati che l’azione stessa attraversa per essere compiuta.

Fortunatamente ciò che spesso succede è che presi singolarmente gli stati intermedi che servono a

descrivere un’azione sono caratterizzabili con pochi dati.

Conseguenza diretta è che i rilevatori di attività tendono ad essere più economici di quelli di

caratteristiche fisiologiche e per questo più facilmente presenti anche in smartphone meno costosi.

D’altra parte, sebbene i dati primitivi ottenuti dalla misurazione di un singolo stato dell’azione siano

tipicamente semplici da elaborare, è anche vero che presi singolarmente sono pressoché inutilizzabili.

Perché abbiano un senso è necessario analizzarne una sequenza. Operazione questa che richiede delle

opportune elaborazioni e di cui i sensori più comuni lasciano spesso l’onere all’utilizzatore.

Viceversa la misurazione di caratteristiche fisiologiche tende a richiedere strumenti dedicati, spesso

costosi, che raramente sono presenti di serie sui nostri dispositivi mobili. Per contro, i dati ottenuti con

questi strumenti sono spesso pre-processati dagli strumenti stessi e per questo di facile fruizione.

Dal punto di vista implementativo sarebbe quindi stato più semplice (e più economico) decidere di

basare la nostra soluzione su rilevatori di caratteristiche fisiologiche.

D’altra parte, poiché ritenevamo fosse importante i nostri risultati potessero essere subito usati da un

utente medio senza bisogno di dotarsi di attrezzatura specifica, abbiamo deciso di optare per una

rilevazione basata esclusivamente su caratteristiche comportamentali scegliendo in particolare fra

queste quelle gestite nativamente dalla quasi totalità dei dispositivi mobili.

Caratteristiche biometriche selezionate

Ci è sembrato che per distinguere quale utente stia attualmente utilizzando il dispositivo e quindi

determinare se sia autorizzato a farlo la scelta più naturale fosse osservare come questi interagisse

fisicamente col cellulare.

Per motivi tecnologici che esporremo in seguito abbiamo dovuto restringere il nostro campo di

osservazione ad un sottoinsieme di interazioni possibili.

Poiché in precedenza il Machine Learning Lab aveva già condotto un’esperienza analoga [19] in

ambiente desktop in cui aveva potuto riscontrare come l’utilizzo della combinazione “tastiera +

mouse” fosse una buona caratteristica comportamentale ai fini dell’autenticazione continua, abbiamo

scelto di concentrarci su quelle interazioni utente che avvengono nel momento in cui questi digita

sulla tastiera virtuale del telefono.

Per ottenere un’impronta biometrica quanto più fedele e unica possibile abbiamo deciso di monitorare

un insieme di caratteristiche biometriche invece di limitarci ad una sola.

In particolare la nostra scelta è caduta su:

Frequenza di battitura

Durata della pressione dei tasti ad ogni singola battuta

Forze applicate al telefono durante la battitura

Il mio contributo al progetto: il rilevatore di impronte biometriche

La soluzione ideata dal Machine Learning Lab si compone di 3 moduli principali:

Un rilevatore di misure biometriche

Un motore decisionale in grado di riconoscere l’utente sulla base delle misure rilevate

Uno strumento di controllo del dispositivo

L’incarico che mi è stato assegnato prevedeva mi occupassi soltanto del primo di questi componenti,

ovvero del rilevatore di misure biometriche.

Più in particolare mi è stato richiesto di ricercare una soluzione che soddisfacesse al meglio tutti i

requisiti di progetto e di implementarne un prototipo che potesse essere usabile all’interno del

laboratorio per proseguire con lo sviluppo dei successivi step di progetto.

Importanza del rilevatore realizzato all’interno della soluzione complessiva

L’obiettivo principale della nostra ricerca (perché è lì che si concentra la maggior parte del valore

aggiunto della nostra soluzione) è riuscire a creare un motore decisionale che basandosi su

misurazioni di caratteristiche biometriche riesca a capire con un elevato grado di affidabilità se chi stia

utilizzando il dispositivo in quel momento sia l’utilizzatore atteso o meno (binary classification). Per

raggiungere i nostri scopi non ci interessa invece raggiungere un livello di dettaglio tale da riuscire a

capire esattamente chi sia il reale utilizzatore (open-world multiclass classification).

Per realizzare questo componente è necessaria una doppia attività di ricerca: in una prima fase iniziale

viene ideato l’algoritmo considerato più adatto a risolvere il problema; in una fase successiva

l’algoritmo stesso viene istruito tramite tecniche di machine learning al fine di aumentarne

l’accuratezza. Questa seconda fase ci serve inoltre a validare la bontà del modello che abbiamo ideato.

Affinché possano produrre dei risultati soddisfacenti, sia la fase di apprendimento dell’algoritmo che

quella di verifica dei dati ottenuti richiedono una mole significativa di dati reali.

È necessario che i dati a disposizione siano molti per poter individuare i tratti salienti di ogni profilo

utente che si intende tracciare riducendo al minimo l’impatto di falsi positivi e anomalie di

rilevazione.

È necessario che i dati siano reali e non definiti ad hoc da un umano per evitare che i pregiudizi di chi

li crea possano condizionare in modo non trascurabile, per quanto involontariamente, i risultati

ottenuti.

Uno dei possibili modi in cui questo condizionamento può avvenire è la mancata inclusione di alcuni

atteggiamenti soltanto perché non si erano mai notati prima. Un’altra possibilità è un’eccessiva

enfatizzazione delle caratteristiche principali che rendono unico un profilo utente.

Il motivo principale per cui mi è stato chiesto di realizzare il rilevatore è proprio soddisfare

quest’esigenza fornendo uno strumento che permetta di raccogliere agevolmente dati reali.

Incidentalmente nel realizzarlo abbiamo potuto verificare una serie di ipotesi implementative che

contiamo di sfruttare quando andremo a realizzarne la versione finale. La versione attuale è però

volutamente un prototipo.

Requisiti del rilevatore

Il rilevatore che ho realizzato è un prototipo e in quest’ottica vanno visti tutti i requisiti per esso

definiti.

Per quanto riguarda quali dati vadano raccolti si è deciso che le informazioni minime da raccogliere

sarebbero state:

in che istante viene premuto un tasto

in che posizione dello schermo avviene un evento di touch

che movimenti traslatori e rotatori subisce il telefono durante l’uso

Trattandosi di un prototipo abbiano preferito concentrare i nostri sforzi sull’individuazione di una

soluzione e sull’esplorazione di approcci alternativi piuttosto che su un’ingegnerizzazione

particolarmente elaborata.

Gli utenti del prototipo saranno tutte persone impiegate direttamente nel Machine Learning Lab o da

loro opportunamente istruite. Sebbene nel definire il prototipo si sia cercato di avvicinarsi il più

possibile a quello che immaginiamo sarà il risultato finale, si è preferito dedicare il minor tempo

possibile agli abbellimenti che ci si aspetterebbe da un prodotto finito. Non è stato quindi necessario

curare in modo particolare la gradevolezza estetica o la completezza di tutte le funzionalità avanzate a

supporto di una scrittura più rapida e agevole (es. composizione basata su gesti, auto-completamento,

supporto multilingue) la cui mancanza potrebbe impedire l’adozione della tastiera causa ridotta

usabilità.

La scelta deliberata di usare la tastiera soltanto per raccolta dati in ambiente controllato ha avuto altre

conseguenze sull’implementazione quali:

nessuna importanza è stata data all’impatto sulle performance della batteria

l’attenzione riposta alla dimensione del file di log prodotto è stata minima

non si è creato un meccanismo di sicurezza per evitare la tastiera venisse semplicemente

disabilitata da un malintenzionato

non è stato implementato un meccanismo di trasmissione dei dati raccolti. Ci è sufficiente

poter accedere al file di log connettendo fisicamente il dispositivo ad un PC

L’applicazione deve poter essere installata sulla maggior parte dei telefoni che attualmente

costituiscono la fascia media assumendo siano stati aggiornati alla versione di Android più recente,

nei limiti di quanto permesso per il modello di telefono specifico.

Per evitare il rischio di incompatibilità con particolari sistemi (magari a seguito di aggiornamento di

versione del sistema operativo) e per ridurre la complessità di modifiche future al rilevatore da parte

di un programmatore inesperto non vogliamo fare ricorso a chiamate a codice nativo.

Perché una tastiera

Le possibilità tra cui scegliere quale tipo di rilevatore di impronta biometrica realizzare erano

molteplici.

Scegliere di focalizzarci sulla raccolta di caratteristiche comportamentali ha ristretto

considerevolmente il numero di opzioni disponibili ma ne ha comunque lasciate aperte molte.

Avremmo per esempio potuto sfruttare la fotocamera per implementare un meccanismo di eye

tracking al fine di identificare i pattern con cui un utente consulta i vari tipi di contenuti o un

geolocalizzatore per individuare spostamenti anomali del telefono. Abbiamo invece scelto di

implementare una tastiera. Perché?

Innanzitutto per motivi di usabilità e per evitare resistenze nell’adozione della soluzione ci serviva un

rilevatore che non richiedesse l’installazione di componenti fisici esterni. Volevamo poi uno strumento

che potesse attuare i suoi controlli senza stravolgere l’esperienza d’utilizzo a cui l’utente è già

abituato.

Una tastiera software è uno degli strumenti più comuni con cui l’utente interagisce coi contenuti a cui

accede tramite telefono. Di più, è lo strumento con cui accede in modo più significativo. Il resto del

tempo è infatti impiegato nella fruizione passiva dei contenuti presentati. Anche quando l’interazione

con un servizio avvenga tramite app dedicata, è improbabile non venga mai richiesto di utilizzare una

tastiera tramite cui comunicare dati o comandi. Tipico caso è la richiesta di inserimento di credenziali,

dati che sono tra i più importanti da proteggere.

La scelta di una tastiera come rilevatore ci garantisce quindi una buona copertura dei casi d’uso di cui

ci interessa aumentare la sicurezza.

Inoltre per funzionare non richiede l’installazione di nessun componente aggiuntivo ma solo di

un’applicazione. Operazione ormai estremamente familiare a ogni utente di dispositivo mobile e che

comunque viene richiesta una tantum.

La scelta di una tastiera rende facile capire quando via sia un effettivo utilizzo attivo del dispositivo.

Per utilizzare una tastiera infatti l’utente deve consapevolmente decidere di farlo e scegliere quale

azione compiere (utilizzo attivo). Deve inoltre trovarsi fisicamente in possesso del telefono (utilizzo

effettivo).

Anche il fattore economico ha giocato la sua parte. Non dimentichiamoci che il rilevatore necessario a

questa fase è solo un prototipo che ha l’unico obiettivo di permetterci di raccogliere agevolmente dei

dati. Avrebbe avuto poco scopo investire grosse quantità di tempo nella realizzazione di un software

potenzialmente “usa e getta”. Una tastiera ha il vantaggio di essere un oggetto software di

realizzazione relativamente comune. Potevamo quindi sperare di trovare ampia documentazione e

disponibilità al supporto da parte di programmatori che avessero già affrontato il problema in

precedenza. In più avevamo già verificato la disponibilità di tastiere open-source che avremmo potuto

usare come base di partenza.

È doveroso infine ammettere che una soluzione basata su tastiera avrebbe presentato diverse

similarità con quanto già sperimentato con successo dal Machine Learning Lab in ambiente desktop

[19]. Potremo così lavorare con un set di dati di input che ci aspettiamo presenti problematiche di

interpretazione similari a quelle già affrontate nell’esperienza precedente.

Perché Android

La scelta di quale tecnologia utilizzare per la realizzazione del rilevatore è stata relativamente

naturale.

Trattandosi di un prototipo finalizzato alla raccolta di dati campione non eravamo interessati a

supportare qualsiasi dispositivo mobile presente sul mercato.

Ciò che ci interessava era poter accedere in modo economico e senza particolari restrizioni ai dati

raccolti dai sensori del nostro terminale.

Partendo con questi presupposti ci è sembrato naturale rivolgere il nostro sguardo direttamente a una

soluzione nativa lasciando ipotesi come HTML5 o l’utilizzo di un metalinguaggio cross-platform (es.

PhoneGap) ad un’eventuale realizzazione di un prodotto commerciabile.

Tra i 3 principali sistemi operativi disponibili oggi sul mercato (Android, iOS e Windows) ci è

sembrato la scelta più sensata fosse Android perché:

è in assoluto il sistema operativo più diffuso al mondo. Possiamo così massimizzare le

probabilità di riuso di parti del nostro prototipo qualora fosse necessario

fornisce una piattaforma di sviluppo aperta e gratuita, sia in termini di linguaggio che di

strumenti (Android Studio)

permette di scrivere applicazioni in un linguaggio già ampiamente diffuso come lo è Java.

Massimizziamo così la facilità di trovare persone già dotate delle competenze necessarie a far

evolvere il nostro codice

è supportato da una community di sviluppatori molto ampia e propensa alla condivisione del

sapere ed all’aiuto reciproco

eravamo già in possesso di un numero sufficiente di smartphone da usare per condurre i

nostri test. In tutti gli altri casi avremmo invece dovuto la problematica aggiuntiva di come

procurarceli

La tastiera realizzata

Nelle immagini successive è possibile vedere la tastiera che ho realizzato.

1

2

3

4

Ognuna delle 4 schermate rappresenta uno dei 4 set di caratteri supportati:

1. alfabeto minuscolo

2. alfabeto maiuscolo

3. numeri e caratteri speciali più comuni

4. caratteri speciali meno comuni

Sono presenti anche alcune funzionalità di base come:

Tasto maiuscole, per digitare un carattere maiuscolo dalla schermata che presenta l’alfabeto

minuscolo

Blocco maiuscole

Attivazione automatica tasto maiuscole a inizio riga o dopo un carattere di punto seguito da

uno spazio

Possibilità di inserire un carattere accentato premendo ripetutamente sul pulsante

corrispondente alla vocale desiderata

Possibilità di chiudere la tastiera

Funzionamento generale della tastiera

La tastiera che ho realizzato usa il codice di esempio fornito da Google nella sua documentazione

Android (vedi sorgenti). Da lì sono partito per andare ad aggiungere il supporto ai caratteri accentati,

originariamente non inclusi perché assenti nell’alfabeto inglese, e per inserire il codice incaricato di

registrare le rilevazioni biometriche relative alle misure d’interesse.

Quando la tastiera si apre parte la registrazione dei sensori di movimento che si interrompe quando la

tastiera viene nascosta. I dati arrivano sotto forma di campionamento delle posizioni che il telefono

assume mentre viene usato.

L’intervallo di campionamento è di 60ms. Il valore è mutuato dalla precedente esperienza condotta

dal laboratorio per l’autenticazione continua in ambiente desktop. Poiché le tecniche di misurazione

biometrica utilizzate in quel caso sono molto simili a quelle che vogliamo usare in questo nuovo

sistema siamo fiduciosi che tale valore possa andare bene anche questa volta. Inoltre, sebbene non

fosse una priorità, grazie a questa scelta possiamo beneficiare delle considerazioni già fatte su

bilanciamento ottimale tra granularità dei dati raccolti e mole di dati generati al fine di ottimizzare

l’occupazione del file di log su disco e l’occupazione di banda in caso di una futura implementazione

di trasmissione dei dati in rete.

Importante notare che la durata dell’intervallo di campionamento scelta non è garantita ma può solo

essere suggerita come parametro al momento della registrazione di un ascoltatore di sensore. È

prerogativa del sistema operativo, a seconda dell’hardware a disposizione e del carico di lavoro del

momento, decidere se rispettare le frequenze richieste o dilatarle per non compromettere il

funzionamento complessivo dell’apparecchio.

Quando un tasto viene premuto vengono registrate in 2 eventi distinti le coordinate in cui comincia la

pressione e in cui questa si interrompe.

Ogni rilevazione viene salvata come record indipendente in un file di log che viene aggiornato in

tempo reale. Ogni record contiene l’informazione temporale relativa a quando l’evento registrato è

stato generato più 2 timestamp di riferimento.

Per essere analizzato il file dovrà essere prelevato fisicamente dal dispositivo per essere trasferito

dove serva.

Indicatori biometrici monitorati

Ricordiamo che le caratteristiche biometriche che abbiamo deciso di monitorare sono:

Frequenza di battitura

Durata della pressione dei tasti ad ogni singola battuta

Forze applicate al telefono durante la battitura

I primi 2 indicatori ci vengono forniti dai sensori con cui è realizzato lo schermo tattile del dispositivo.

Questi sono capaci di capire in che momento e in che punto della videata comincia il contatto e

quando e dove si conclude.

L’indicatore relativo alle forze è un dato che possiamo ottenere indirettamente analizzando le

accelerazioni e le rotazioni subiti dal telefono in un intervallo di tempo noto. Le accelerazioni sono

rilevate dall’accelerometro, le rotazioni dal giroscopio.

È inoltre possibile definire ulteriori indicatori derivati dalla combinazione delle informazioni raccolte

dal rilevatore.

Potremmo per esempio misurare la distanza cartesiana media tra il punto in cui inizia la pressione di

un tasto e punto in cui questa termina.

Evento Touch

L’evento di Touch è descritto dalla coppia di coordinate cartesiane che identificano il punto centrale

dello schermo in cui l’evento è stato scatenato.

Distinguiamo tra momento in cui inizia il contatto con lo schermo e momento in cui questo finisce, che

in termini di linguaggio Android corrispondono agli oggetti CLICK e RELEASE.

Il sistema di riferimento ha origine nell’angolo in alto a sinistra dello schermo.

I valori sono espressi in pixel.

Campionamento accelerometro

L’accelerometro misura l’accelerazione applicata al dispositivo

esprimendola in funzione delle sue componenti lungo i 3 assi

che compongono il nostro sistema di riferimento.

I 3 assi sono orientati come in figura.

Il sistema di riferimento così definito non cambia col ruotare del

telefono. L’orientamento degli assi non varia cioè modificando

l’inclinazione del dispositivo.

Sebbene in figura l’asse Y venga rappresentato come parallelo al

lato lungo del telefono, questo non è sempre vero per ogni

dispositivo. È vero che valori positivi sull’asse delle ordinate

corrispondono alla parte alta dello schermo nella sua

configurazione naturale. Che la configurazione naturale sia l’orientamento portrait o landascape è

qualcosa che dipende dal singolo dispositivo (fonte).

Verrebbe naturale pensare che questo sensore tenga conto solo delle accelerazioni che producono un

movimento, ovvero che rispettino la formula:

ai = -Σ Fi / m

Dove:

ai = la componente dell’accelerazione lungo l’asse i-esimo

Fi = la componente della forza applicata lungo l’asse i-esimo

m = massa totale del dispositivo

Le misure fornite dall’accelerometro esplicitano invece il contributo dell’accelerazione di gravità g

secondo la seguente formula:

ai = -g -Σ Fi / m

Ne consegue che per un dispositivo che si trovi fermo, poggiato su una superficie, il valore

dell’accelerazione verticale sarà 9.81 m/s2 (fonte).

Campionamento giroscopio

Il giroscopio misura la velocità di rotazione di un dispositivo lungo i 3 assi che compongono il sistema

di riferimento. Il sistema di riferimento utilizzato è lo stesso già visto per l’accelerometro.

I valori sono espressi in radianti al secondo.

La rotazione è positiva se il dispositivo sta ruotando in senso anti-orario (fonte).

Implementazione dei rilevatori per gli indicatori biometrici monitorati

Ho dovuto gestire il monitoraggio di 3 tipi di eventi, 2 dei quali molto simili tra loro.

Gli eventi relativi al contatto vengono notificati in modo sincrono a tutti i listener in ascolto. La

notifica arriva sotto forma di invocazione alla callback onTouch(View, MotionEvent) definita

nell’interfaccia android.view.View.OnTouchListener che tutti gli ascoltatori devono implementare. I

dati che descrivono l’evento sono contenuti nell’oggetto android.view.MotionEvent passato come

parametro di input.

Dal punto di vista della programmazione accelerometro e giroscopio sono 2 istanze di un oggetto

android.hardware.Sensor.

Non è possibile invocare direttamente dei Sensor per richiedere lo stato rilevato per il dispositivo in

un determinato momento. Bisogna invece registrare un ascoltatore delle notifiche dei dati rilevati

tramite campionamento di un certo aspetto. Il campionamento avviene a frequenza non garantita che

empiricamente possiamo dichiarare approssimabile a costante. La frequenza di campionamento può

essere solo suggerita come parametro del metodo invocato per registrare il listener ma verrà decisa

esclusivamente dal sistema operativo sulla base di carico di hardware disponibile e carico del telefono.

Es. mSensorManager.registerListener( mAccelerometerEventListener, mAccelerometer, SensorManager.SENSOR_DELAY_UI

);

I dati rilevati vengono notificati all’ascoltatore tramite parametro di input di tipo

android.hardware.SensorEvent del metodo di callback onSensorChanged(SensorEvent).

Evento Touch

Il listener incaricato di registrare gli eventi di inizio e fine pressione di un tasto poteva essere espresso

in poche e semplici righe di codice. Per questo ho scelto di usare una classe anonima dichiarata

direttamente al momento della registrazione:

mInputView.setOnTouchListener(new View.OnTouchListener() { @Override

public boolean onTouch(View v, MotionEvent event) { if (event.getAction() == MotionEvent.ACTION_DOWN) { SimpleFileLogger.appendLog(getTouchEventMessage(event)); } else if (event.getAction() == MotionEvent.ACTION_UP) { SimpleFileLogger.appendLog(getTouchEventMessage(event)); } return false;

} });

Campionamento accelerometro

Il listener incaricato di registrare le rilevazioni dell’accelerometro viene registrato ogni qualvolta la

tastiera appare e viene deregistrato quando questa viene chiusa.

Il codice incaricato di registrare i dati campionati dall’accelerometro è completamente contenuto nella

classe AccelerometerEventListener di cui segue il listato:

Campionamento giroscopio

Il listener incaricato di registrare le rilevazioni del giroscopio si comporta in modo del tutto analogo a

quello dell’accelerometro. Viene infatti registrato ogni qualvolta la tastiera appare e viene deregistrato

quando questa viene chiusa.

mInputView.addOnLayoutChangeListener(new View.OnLayoutChangeListener() { @Override

public void onLayoutChange(View view, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom) {

if(view.isShown()) { // [...] mSensorManager.registerListener(mAccelerometerEventListener, mGyroscope,

SensorManager.SENSOR_DELAY_UI); } else { // [...] mSensorManager.unregisterListener(mAccelerometerEventListener, mGyroscope); } } });

public class AccelerometerEventListener implements SensorEventListener { private static final long FROM_NANO_TO_MILLI_CONVERSION_FACTOR = 1 * 1000 * 1000; @Override public void onSensorChanged(SensorEvent event) { if (event.sensor.getType() == Sensor.TYPE_ACCELEROMETER) { long sensorTimeStamp = event.timestamp / FROM_NANO_TO_MILLI_CONVERSION_FACTOR; long systemTimestampOfExecution = System.currentTimeMillis(); long internalTimerTimestampOfExecution = System.nanoTime() / FROM_NANO_TO_MILLI_CONVERSION_FACTOR; float sensorX = event.values[0]; float sensorY = event.values[1]; float sensorZ = event.values[2];

String accelerometerEventMessage = String.format(Locale.ENGLISH, "A;%d;%d;%d;%f;%f;%f",

sensorTimeStamp, systemTimestampOfExecution, internalTimerTimestampOfExecution, sensorX, sensorY, sensorZ

); SimpleFileLogger.appendLog(accelerometerEventMessage); } } @Override public void onAccuracyChanged(Sensor sensor, int accuracy) { // nothing to do } }

Anche la classe incaricata di registrare le rilevazioni del giroscopio è del tutto simile a quella

dell’accelerometro al punto si sarebbe potuta definire una classe comune. Per semplicità e flessibilità

ho preferito non farlo.

mInputView.addOnLayoutChangeListener(new View.OnLayoutChangeListener() { @Override

public void onLayoutChange(View view, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom) {

if(view.isShown()) { // [...] mSensorManager.registerListener(mGyroscopeEventListener, mGyroscope,

SensorManager.SENSOR_DELAY_UI); } else { // [...] mSensorManager.unregisterListener(mGyroscopeEventListener, mGyroscope); } } });

public class GyroscopeEventListener implements SensorEventListener { private static final long FROM_NANO_TO_MILLI_CONVERSION_FACTOR = 1 * 1000 * 1000; @Override public void onSensorChanged(SensorEvent event) { if (event.sensor.getType() == Sensor.TYPE_GYROSCOPE) { long sensorTimeStamp = event.timestamp / FROM_NANO_TO_MILLI_CONVERSION_FACTOR; long systemTimestampOfExecution = System.currentTimeMillis(); long internalTimerTimestampOfExecution = System.nanoTime() / FROM_NANO_TO_MILLI_CONVERSION_FACTOR; float sensorX = event.values[0]; float sensorY = event.values[1]; float sensorZ = event.values[2]; String gyroscopeEventMessage = String.format(Locale.ENGLISH, "G;%d;%d;%d;%f;%f;%f",

sensorTimeStamp, systemTimestampOfExecution, internalTimerTimestampOfExecution, sensorX, sensorY, sensorZ

); SimpleFileLogger.appendLog(gyroscopeEventMessage); } } @Override public void onAccuracyChanged(Sensor sensor, int accuracy) { // nothing to do } }

Gestione del file di log

Puntando al massimo della semplicità abbiamo concordato che il file di log fosse scritto in locale in

una posizione accessibile manualmente.

Poiché Android non fornisce nativamente una versione di Logger capace di scrivere su file, ho definito

una semplice classe incaricata di farlo.

Struttura del file di log

Anche nella scelta del formato per il file di log la priorità è stata la semplicità, tanto in termini di

leggibilità da parte di un umano che di immediatezza di utilizzo in fase di analisi.

Abbiamo quindi optato per l’universalmente riconosciuto formato CSV in cui ogni riga corrisponde

ad una rilevazione di sensore o touchscreen.

Ogni evento è descritto da:

Un codice che identifica il tipo di evento (es. G = giroscopio)

Un timestamp che identifica il momento in cui la rilevazione è stata effettuata dal dispositivo

2 timestamp di riferimento (motivati successivamente)

Una coppia di coordinate nel caso dell’evento di Touch

Una tripla di coordinate nel caso di rilevazioni effettuate dai Sensor

public class SimpleFileLogger { private static BufferedWriter LOG_WRITER; public static void appendLog(String text) { try { LOG_WRITER.write(text); LOG_WRITER.newLine(); LOG_WRITER.flush(); } catch (IOException e) { Log.e("BiometricKeyboard",

"The following message could not be logged: " + text + "\n", e

); } } public static void initLoggingFile(String fileName) throws IOException { File logFile = new File(Environment.getExternalStorageDirectory(),

fileName); if (!logFile.exists()) { logFile.createNewFile(); } LOG_WRITER = new BufferedWriter(new FileWriter(logFile, true)); } public static void closeLoggingFile() throws IOException { if(LOG_WRITER != null) { LOG_WRITER.close(); } } }

Segue un esempio di file di log effettivamente generato.

Problemi incontrati

Riportiamo di seguito i problemi incontrati in fase di realizzazione del rilevatore e le decisioni prese

su come affrontarli

Trovare una tastiera open source

In fase di studio di fattibilità avevamo individuato alcuni candidati di tastiere open-source da

utilizzare come base per la realizzazione del rilevatore.

Passati alla fase di realizzazione ci siamo accorti che tutti i candidati scelti erano poco adatti ai nostri

scopi.

Progetti come AnySoftKeyboard, Hacker’s Keyboard e Indic Keyboard si sono infatti tutti dimostrati

corposi e quindi complessi da estendere senza una documentazione su come farlo nel modo più

opportuno. Inoltre alcuni di questi (es. Hacker’s Keyboard) sfruttano chiamate native al sistema

operativo, cosa che volevamo evitare per ridurre complessità e prevenire problemi di portabilità tra

versioni differenti di Android e dispositivo.

Abbiamo anche valutato l’opzione di costruire una tastiera da zero ma guide e tutorial si sono

dimostrati troppo basici (esempio di tutorial) e lo sforzo richiesto per ottenere un prodotto usabile

sproporzionato rispetto al tempo totale disponibile per la realizzazione dell’intero progetto del

rilevatore.

Fortunatamente in corso d’opera abbiamo scoperto tra la documentazione ufficiale Android la

presenza di un esempio di tastiera perfettamente funzionante ed abbasanza essenziale che si è

dimostrato essere la base perfetta per la nostra implementazione.

Documentazione di difficile consultazione per sviluppi medio-complessi

Google ha rilasciato il suo sistema operativo mobile corredandolo di ampia documentazione.

Avevamo quindi creduto non ci servissero altri riferimenti per trovare tutte le informazioni e

imparare ad usare i componenti di cui avevamo bisogno.

L’esperienza ha confermato la validità della nostra ipotesi. Il processo con cui reperire queste

informazioni è stato però molto più oneroso di quanto sperassimo.

La documentazione di base [20] è estremamente efficace nel fornire una panoramica su tutti gli aspetti

legati alla programmazione in ambiente Android a chi la stia approcciando per la prima volta. Risulta

invece troppo superficiale per chiunque debba cimentarsi nell’implementazione di funzionalità meno

comuni, cosa che purtroppo è stato il nostro caso.

Per contro la documentazione delle singole classi [21] che compongono la piattaforma di sviluppo è

sicuramente molto più dettagliata ma poco o nulla dice su come vadano usate certe classi base.

Presuppone invece un livello di conoscenza dei meccanismi generali che non si può ottenere

direttamente dalla documentazione base.

Imparando a conoscere meglio come la documentazione sia strutturata ci è stato infine possibile

trovare quei punti che spiegano col livello di dettaglio a noi necessario il funzionamento generale di

Android e di come le sue classi chiave interagiscano. Ci saremmo però aspettati minori difficoltà

nell’individuazione di queste parti.

Far convivere listener con campionamento

L’idea iniziale era di registrare posizione e accelerazioni impresse al telefono soltanto allo scatenarsi

di un evento di Touch.

Il listener degli eventi Touch avrebbe quindi svolto un doppio compito:

Catturare tutti gli eventi di Touch

Richiedere puntualmente un’istantanea dello stato ad accelerometro e giroscopio

In questo modo avremmo ottenuto in modo immediato una rappresentazione di ogni interazione

come insieme di valori già associati tra loro, input ideale per un algoritmo di Machine Learning basato

su un modello di tipo SVM (Support Vector Machine).

Abbiamo però scoperto in corso d’opera che accelerometro e giroscopio (e tutti i Sensor in genere) non

possono essere interrogati puntualmente. L’unico modo previsto per usarli è registrarsi come

ascoltatore per ricevere tutti gli eventi di campionamento da questi rilevati. Sarà cura dell’ascoltatore

poi ignorare quei campionamenti che non ritiene rilevanti.

Capito che non sarebbe stato possibile ottenere dati dai Sensor perfettamente corrispondenti al

momento in cui l’evento di Touch viene generato, abbiamo deciso di riportare nel file di log tutti i dati

rilevati dai campionamenti dei sensori da quando viene aperta la tastiera a quando viene chiusa. I dati

verranno poi aggregati in una fase di pre-elaborazione dell’algoritmo di machine learning. Provare a

sincronizzare eventi di Touch e campionamenti lato rilevatore sarebbe stato molto più complesso e

comunque non ci avrebbe assicurato un risultato migliore. Così facendo invece non perdiamo

informazione e ci assicuriamo un algoritmo più pronto a rispondere a cambiamenti in caso in una

seconda fase si decida di adottare un rilevatore diverso.

Timestamp diversi a seconda dispositivo

Quando abbiamo deciso il formato dei dati da salvare ci aspettavamo i timestamp di evento di Touch

e dei campionamenti dei Sensori fossero allineati tra loro e quindi comparabili.

Testando l’applicazione su 2 modelli di telefono diversi (HTC One e Nexus 5) ci siamo invece accorti

che in un caso tutti 2 timestamp erano espressi come offset a partire da una data convenzionale

(accensione del telefono), mentre nell’altro i timestamp di evento di Touch e dei sensori erano espressi

come offset relativi ad 2 date convenzionali diverse (accensione del telefono e, in stile Linux,

mezzanotte del 1/1/1970).

Questo comportamento è noto e descritto nei bug Android 78858 e 79763, in cui si legge che per

quanto riguarda il Nexus 5 sono osservabili entrambi i comportamenti a seconda della versione di

Android installata.

La soluzione ideale per rendere tutti i timestamp comparabili tra loro sarebbe stata capire

programmaticamente quale data convenzionale fosse stata scelta per esprimere gli offset con cui

vengono calcolati i singoli timestamp ma tale informazione non è reperibile dalle API Android.

D’altra parte era necessario poter determinare in qualche modo quale fosse la base di riferimento.

Abbiamo subito scartato l’ipotesi di censire tutte le combinazioni di telefoni / versione di sistema

operativo con relativi approcci adottati perché troppo onerosa da mantenere.

Analogamente abbiamo scartato l’ipotesi di registrare, per ogni evento di log, il timestamp di sistema.

In questo caso infatti avremmo sì ottenuto valori tutti comparabili tra loro perché espressi nella stessa

base ma avremmo introdotto del rumore non quantificabile nei dati rilevati. Non è infatti garantito

che un evento venga processato immediatamente dopo essere stato generato né che l’intervallo di

tempo che passa tra il momento della sua generazione e quello della sua presa in carico sia

assimilabile come costante.

Poiché dopo aver indagato un po’ abbiamo scoperto che le date convenzionali effettivamente usate si

riducono a 2 soltanto (accensione telefono e 1/1/1970) e che queste differiscono tra loro in modo

significativo, abbiamo deciso di riportare per ogni evento di log 2 timestamp di riferimento. Il primo è

rilevato tramite chiamata a System.currentTimeMillis() e identifica l’ora corrente rappresentata come

millisecondi trascorsi a partire dalla mezzanotte del 1/1/1970 mentre il secondo è preso da

System.nanoTime() e rappresenta (tipicamente) i nanosecondi trascorsi da quanto il telefono è stato

acceso. Sarà poi compito di uno step di pre-processazione occuparsi di capire quale delle 2 date fosse

stata scelta come data convenzionale.

Approcci alternativi esplorati per la realizzazione del rilevatore

Il rilevatore realizzato e descritto in questa tesi ha una notevole limitazione: è in grado di rilevare

soltanto le interazioni che l’utente ha con la tastiera stessa. I controlli per l’autenticazione continua

non possono pertanto avvenire in tutti quei momenti in cui la tastiera non è attiva, come per esempio

accade mentre si sta sfogliando una galleria di immagini o si stia interagendo con un’applicazione

nativa che non richiede l’inserimento di testo.

Avevamo pensato a questa limitazione ancora in fase di analisi iniziale e per questo, prima di

procedere con la realizzazione del rilevatore, avevo provato ad esplorare approcci alternativi che

potessero fornire lo stesso set di informazioni ma permettendoci di ricoprire una casistica di utilizzo

più ampia.

L’idea comune a tutti gli approcci alternativi era cercare di mettersi in ascolto di tutti gli eventi di

Touch generati tramite l’interazione con una qualsiasi applicazione installata sul sistema. A tal fine

sarebbe stato necessario poter definire un servizio (detto Service) sempre attivo e avviato

automaticamente durante la procedura d’avvio del telefono.

Purtroppo questa strada non è stata pienamente perseguibile in nessuna delle sue declinazioni per

una serie di ostacoli. Vediamoli nell’ordine in cui sono stati affrontati.

(1) Gli eventi di Touch possono essere ricevuti soltanto da oggetti di tipo Activity che in primissima

approssimazione potremmo definire come quella parte dell’applicazione incaricata di gestire una o

più schermate video di un’app (dette View). Un servizio può solo richiedere ad un’Activity che gli

inoltri gli eventi touch che questa riceve quando l’utente interagisce con una delle sue View.

Android non permette la definizione di un’Activity senza che ad essa sia associata una controparte

grafica visibile né è possibile avviare l’esecuzione di un’Activity automaticamente ma è necessario sia

l’utente a farlo esplicitamente.

Inoltre un’Activity può ricevere soltanto gli eventi di Touch generati dall’interazione dell’utente con

quella specifica l’Activity.

La prima idea è stata quella di creare un servizio che allo startup identificasse tutte le Activity attive e

richiedesse loro l’inoltro degli eventi Touch. Per limitazioni di sicurezza di Android però, un servizio

ha accesso soltanto alle Activity definite nella stessa app di cui lui stesso fa parte. Non può invece

comunicare direttamente con Activity definite in altre app.

(2) Pensando a come sono impostati altri framework non Android basati su eventi ho provato a

vedere se esistessero degli eventi visibili a livello globale a cui un servizio potesse agganciarsi

liberamente.

In Android tali eventi esistono, sono chiamati Intent e sono stati definiti proprio per permettere lo

scambio di dati tra applicazioni diverse. Si tratta di eventi che devono essere generati

consapevolmente da un’app quando vuole inviare un messaggio ad una qualsiasi altra che si trovi in

ascolto per permetterle di reagire in qualche modo senza che però le 2 applicazioni si conoscano. Un

esempio tipico è quello di un App1 che segnala che l’utente ha selezionato un file multimediale

sperando ci sia almeno una seconda App2 in ascolto che si incarichi di riprodurlo. Purtroppo per noi,

ma abbastanza prevedibilmente, non ci sono eventi, nemmeno quelli di Touch, che vengano inoltrati

in automatico tramite meccanismo degli intenti. Con questa tecnica avremmo quindi potuto

monitorare soltanto applicazioni progettate appositamente per comunicare con la nostra, non tutte

quelle già esistenti e installate su un comune telefono.

(3) Sono quindi tornato all’idea di un servizio che si registrasse come ascoltatore degli eventi Touch su

ogni Activity attiva. Questa volta invece di tentare una strategia di discovery, magari ripetuta ad

intervalli di tempo prestabiliti, ho cercato di tentare la registrazione (eventualmente invocando

opportuni metodi tramite meccanismi come la Reflection) ogni qual volta il servizio da realizzare si

fosse accorto che una nuova Activity veniva avviata.

Nelle mie previsioni la difficoltà sembrava risiedere nel come fare a capire in un servizio esterno come

il nostro quando una qualsiasi Activity venisse avviata senza conoscerne a priori l’identià. Avevo

invece sottovalutato le complessità legate alla parte di registrazione.

Nella pratica si è invece visto mostrato che sfruttando gli eventi di accessibilità è relativamente facile

accorgersi di quando e persino quale Activity sia stata avviata. L’evento però non porta con sé nessun

riferimento diretto all’oggetto la cui attivazione ha generato la notifica ma solo un descrizione di come

questo sia fatto (AccessibilityNodeInfo).

L’evento di accessibilità è molto interessante perché ci comunica molte informazioni sul contesto in

cui una determinata azione avviene. Avremmo per esempio potuto capire che era stato digitato un

carattere e con un po’ di manipolazione anche quale fosse ma avremmo dovuto rinunciare

all’informazione sulla posizione in cui il click era avvenuto, requisito fondamentale per il nostro

algoritmo di autenticazione. Per reperire questa informazione avevamo bisogno di poter accedere

direttamente all’Activity che aveva preso parte all’interazione, l’unico oggetto che abbia visibilità sulle

coordinate del click.

(4) Ho infine provato a recuperare indirettamente una View a partire dalla proprietà getWindowId() di

un AccessibilityNodeInfo. Purtroppo anche in questo caso non è stato possibile arrivare fino in fondo

nemmeno provando a utilizzare tecniche poco ortodosse (accesso tramite reflection a variabili

d’istanza dell’AccessibilityNodeInfo legato all’evento o modifica delle librerie usate dal compilatore

per accedere a metodi marchiati come nascosti sebbene definiti a runtime [23]).

Bibliografia

[1] More Than 30% of People Don’t Password Protect Their Mobile Devices

[2] New Study Says We Pick Up Our Smartphones 1,500 Times a Week, Stare at Them 3 Hours a Day

[3] Consumers use smartphones for 195 minutes per day, but spend only 25% of that time on

communications

[4] McAfee Labs Threats Report - June 2014

[5] Enterprises are fueling 'explosive growth' in mobile security market, says ABI

[6] Gartner Says Worldwide Information Security Spending Will Grow Almost 8 Percent in 2014 as

Organizations Become More Threat-Aware

[7] 10 best ways to secure your smartphone

[8] Hacker fakes German minister's fingerprints using photos of her hands

[9] How to bypass Android liveness check

[10] D. Gunetti and C. Picardi, “Keystroke analysis of free text,” ACM Trans. Inf. Syst. Secur., vol. 8, pp.

312–347, Aug. 2005.

[11] I. Traore, I. Woungang, M. S. Obaidat, Y. Nakkabi, and I. Lai, “Online risk-based authentication

using behavioral biometrics,” Multimedia Tools and Applications, pp. 1–31, June 2013.

[12] A. Ahmed and I. Traore, “A new biometric technology based on mouse dynamics,” IEEE Transactions on

Dependable and Secure Computing, vol. 4, pp. 165–179, July 2007.

[13] Y. Nakkabi, I. Traore, and A. Ahmed, “Improving mouse dynamics biometric performance using

variance reduction via extractors with separate features,” IEEE Transactions on Systems, Man and Cybernetics,

Part A: Systems and Humans, vol. 40, pp. 1345–1353, Nov. 2010.

[14] Z. Jorgensen and T. Yu, “On mouse dynamics as a behavioral biometric for authentication,” in

Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, 2011.

[15] C. Shen, Z. Cai, and X. Guan, “Continuous authentication for mouse dynamics: A pattern-growth

approach,” in 2012 42nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks

(DSN), pp. 1–12, 2012.

[16] C. Shen, Z. Cai, X. Guan, Y. Du, and R. Maxion, “User authentication through mouse dynamics,” IEEE

Transactions on Information Forensics and Security, vol. 8, no. 1, pp. 16–30, 2013.

[17] S. Mondal and P. Bours, “Continuous authentication using mouse dynamics,” in Biometrics Special

Interest Group (BIOSIG), 20

[18] A. De Luca, A. Hang, F. Brudy, C. Lindner, and H. Hussmann, “Touch Me Once and I Know It’s

You!: Implicit Authentication Based on Touch Screen Patterns,” in Proceedings of the SIGCHI Conference on

Human Factors in Computing Systems, pp. 987–996, 2012.

[19] Eric Medvet, Alberto Bartoli, Francesca Boem, Fabiano Tarlao, "Continuous and Non-Intrusive

Reauthentication of Web Sessions based on Mouse Dynamics", 2014 9th International Conference on

Availability, Reliability and Security

[20] Android: Traning - Getting started

[21] Android: Reference

[22] Android: bug tracking system

[23] Using internal (com.android.internal) and hidden (@hide) APIs

Ringraziamenti

Una delle cose più belle e preziose che un viaggio possa offrire è la possibilità di conoscere nuove

persone. È dal confronto con le loro personalità ed esperienze di vita che il nostro percorso trae

ispirazione per diventare unico e significativo per la nostra crescita.

Ad ognuna di queste persone va la mia gratitudine per quanto mi hanno dato.

Poiché il mio viaggio nel mondo universitario è stato molto lungo, sono molte le persone che dovrei e

vorrei ringraziare.

Tra loro alcune spiccano per l’importanza che il loro contributo ha saputo dare a quest’avventura.

Innanzitutto i miei genitori che mi hanno sostenuto e incoraggiato per tutta la vita in ogni mia scelta.

Anche quando iniziare ingegneria in ritardo sembrava pura follia. Anche quando io stesso non

nutrivo più nessuna speranza di farcela a chiudere.

I miei compagni di università, che in quegli anni non ho saputo apprezzare quanto avrebbero

meritato.

L’amico e ora professore Eric Medvet, che ha saputo adattarsi magistralmente alle mie difficoltà

logistiche, seguirmi con grande impegno, serietà e dedizione e fornirmi indicazioni sempre di gran

qualità rendendo così anche questa tappa un momento di crescita.

Giacomo Petronio, la fotografia del miglior amico cui si possa pensare.

Anna, che per 6 lunghi anni mi ha supportato e sopportato in ogni modo dando tutta sé stessa perché

non dovessi mai soffrire per il rimpianto di non aver raggiunto anche questo traguardo. Sei tu.