Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Tesi laurea triennale Ingegneria Informatica - Francesco Bianchi

4.085 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
  • Follow the link, new dating source: ❶❶❶ http://bit.ly/2F90ZZC ❶❶❶
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Dating for everyone is here: ❤❤❤ http://bit.ly/2F90ZZC ❤❤❤
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Tesi laurea triennale Ingegneria Informatica - Francesco Bianchi

  1. 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
  2. 2. Alle mie persone speciali Ci siamo arrivati Insieme
  3. 3. 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
  4. 4. 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
  5. 5. 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.
  6. 6. 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.
  7. 7. 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
  8. 8. 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.
  9. 9. 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.
  10. 10. 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
  11. 11. 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
  12. 12. 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:
  13. 13.  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.
  14. 14. 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.
  15. 15. 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)
  16. 16. 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”.
  17. 17. 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.
  18. 18. 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
  19. 19. 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.
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23.  è 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
  24. 24. 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
  25. 25. 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.
  26. 26. 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.
  27. 27. 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; } });
  28. 28. 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 } }
  29. 29. 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 } }
  30. 30. 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(); } } }
  31. 31. 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.
  32. 32. 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
  33. 33. 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.
  34. 34. 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.
  35. 35. 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
  36. 36. 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]).
  37. 37. 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.
  38. 38. [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
  39. 39. 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.

×