Progetto e realizzazione di un'applicazione per dispositivi mobili per la rilevazione di features biometriche finalizzata alla re-autenticazione continua

1. 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

3. Alle mie persone speciali
Ci siamo arrivati
Insieme

4. 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

5. 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

6. 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.

7. 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.

8. 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

9. 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.

10. 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.

11. 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

12. 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

13. 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:

14.  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.

15. 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.

16. 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)

17. 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”.

18. 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.

19. 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

20. 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.

21. 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

22. 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

23. 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

24.  è 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

25. 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

26. 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.

27. 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.

28. 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;
}
});

29. 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
}
}

30. 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
}
}

31. 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();
}
}
}

32. 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.

33. 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

34. 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.

35. 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.

36. 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

37. 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]).

38. 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.

39. [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

40. 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.