Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

71

Transcript of Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Page 1: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Università degli Studi di Trieste

Dipartimento di Ingegneria e ArchitetturaCorso di Laurea Magistrale in Ingegneria Informatica

Tesi di laurea in

Reti di Calcolatori

Autenticazione Continua Durante

la Navigazione Web Basata sulla

Dinamica del Mouse

LAUREANDO RELATORE

Daniele De Gan prof. Alberto Bartoli

CORRELATORI

prof. Eric Medvetdott. Andrea De Lorenzo

Anno Accademico 2012/2013

Page 2: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 3: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Ai miei genitori

Page 4: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 5: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Indice

1 Introduzione 1

2 Scenario 32.1 Descrizione del problema . . . . . . . . . . . . . . . . . . . 32.2 Stato dell'arte . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 GWT-Observer . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 GWT-Obesrver client . . . . . . . . . . . . . . . . 72.3.2 GWT-Observer server . . . . . . . . . . . . . . . . 72.3.3 Modalità di utilizzo . . . . . . . . . . . . . . . . . . 82.3.4 La SOP . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Con�gurazioni necessarie . . . . . . . . . . . . . . . . . . . 102.4.1 Registrazione su protocollo HTTPS . . . . . . . . . 10

3 Costruzione del datset 153.1 La raccolta dati . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Durata e soggetti interessati . . . . . . . . . . . . . 153.1.2 Vincoli e modalità . . . . . . . . . . . . . . . . . . 163.1.3 Descrizione �le XML . . . . . . . . . . . . . . . . . 16

3.2 Dati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Privacy degli utenti . . . . . . . . . . . . . . . . . . . . . . 20

4 Analisi dei dati 234.1 Selezione informazioni . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Applicativo Java . . . . . . . . . . . . . . . . . . . 244.1.2 Ordinamento record . . . . . . . . . . . . . . . . . 26

4.2 Approccio all'analisi dei dati . . . . . . . . . . . . . . . . . 274.2.1 Sottosequenze precedenti i click . . . . . . . . . . . 274.2.2 Le features . . . . . . . . . . . . . . . . . . . . . . 28

4.3 La classi�cazione . . . . . . . . . . . . . . . . . . . . . . . 304.3.1 SVM . . . . . . . . . . . . . . . . . . . . . . . . . . 31

v

Page 6: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

INDICE vi

4.3.2 Training e testing SVM . . . . . . . . . . . . . . . 334.3.3 Indici di prestazione . . . . . . . . . . . . . . . . . 35

5 Valutazione Sperimentale 395.1 Presentazione dei risultati . . . . . . . . . . . . . . . . . . 395.2 Esperimento 1 . . . . . . . . . . . . . . . . . . . . . . . . . 415.3 Esperimento 2 . . . . . . . . . . . . . . . . . . . . . . . . . 415.4 Esperimento 3 . . . . . . . . . . . . . . . . . . . . . . . . . 415.5 Esperimento 4 . . . . . . . . . . . . . . . . . . . . . . . . . 435.6 Discussione dei risultati . . . . . . . . . . . . . . . . . . . 49

6 Conclusioni 53

A Sturmenti Software 55A.1 Strumenti software . . . . . . . . . . . . . . . . . . . . . . 55

A.1.1 L'ambiente R . . . . . . . . . . . . . . . . . . . . . 55A.1.2 NetBeans IDE . . . . . . . . . . . . . . . . . . . . 55

Bibliogra�a e siti web consultati 57

Ringraziamenti 59

Page 7: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Elenco dei codici

2.1 Codice da inserire nelle pagine da monitorare in modalitàdirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Comandi UNIX per la creazione del certi�cato auto�rmato. 112.3 Righe per la con�gurazione del proxy HTTPS. . . . . . . . 123.1 Evento registrato relativo ad un movimento del mouse. . . 173.2 Informazioni relative all'interazione. . . . . . . . . . . . . 173.3 Sequenza di eventi in un �le XML. . . . . . . . . . . . . . 184.1 Esempio di �le generato da XMLReader. . . . . . . . . . . 254.2 La funzione traduciEvento. . . . . . . . . . . . . . . . . . . 25

vii

Page 8: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 9: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Elenco delle �gure

2.1 Architettura del sistema GWT-Observer in modalità proxy. 92.2 Menù di sistema per attivare l'utilizzo del server proxy. . . 112.3 Importazione del certi�cato nel browser Chrome. . . . . . 13

4.1 Numerazione delle direzioni tra due punti successivi. . . . 294.2 Separazione lineare indotta da SVM. . . . . . . . . . . . . 324.3 Trasformazione tramite kernel SVM. . . . . . . . . . . . . 344.4 Creazione dei training e testing set per l'utente 1. . . . . . 36

5.1 Gra�co Box and Whisker. . . . . . . . . . . . . . . . . . . 405.2 Accuracy, FPR e FNR per Nc = 10 . . . . . . . . . . . . . 425.3 Accuracy, FPR e FNR per Nc = 15 . . . . . . . . . . . . . 445.4 Accuracy, FPR e FNR per Nc = 20 . . . . . . . . . . . . . 455.5 Accuracy, FPR e FNR per Nc = 25 . . . . . . . . . . . . . 465.6 Accuracy, FPR e FNR per Nc = 30 . . . . . . . . . . . . . 475.7 Accuracy per diversi insiemi di features considerati. . . . . 485.8 Accuracy, FPR e FNR ottenute considerando il primo quar-

to di features. . . . . . . . . . . . . . . . . . . . . . . . . . 505.9 Accuracy, FPR e FNR ottenute considerando la metà delle

features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.10 Accuracy, FPR e FNR ottenute considerando i tre quarti

delle features. . . . . . . . . . . . . . . . . . . . . . . . . . 52

ix

Page 10: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 11: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Elenco delle tabelle

2.1 Esempi di funzionamento della SOP. . . . . . . . . . . . . 9

3.1 Numero di eventi registrati per utente. . . . . . . . . . . . 16

4.1 Numero dei vettori di features per utente (Nc = 10). . . . 31

5.1 Indici di prestazione per Nc = 10 e w = 11. . . . . . . . . 415.2 Indici di prestazione per diversi valori di w. . . . . . . . . 435.3 Numero di feature vector per diversi valori di Nc. . . . . . 43

xi

Page 12: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 13: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 1Introduzione

La richiesta di meccanismi e�cienti e a�dabili per autenticare gli utentiè cresciuta da quando sono emersi i limiti dei tradizionali sistemi ba-sati su password. Sono all'ordine del giorno notizie riguardanti furti dicredenziali [1, 2, 3, 4] o sottrazioni di informazioni sensibili [5], che espon-gono gli utenti a rischi di violazione e abuso delle loro informazioni senzaprecedenti. Anche per questi motivi l'inadeguatezza dell'autenticazio-ne basata su password sta diventando un importante tema per l'interacomunità informatica.

Tra le soluzioni emergenti a questo problema, i sistemi biometrici co-me l'analisi dell'iride o delle impronte digitali, sono stati ampiamentestudiati e sono oramai meccanismi collaudati. Il principio su cui si fon-dano è che ogni soggetto possiede delle caratteristiche uniche, siano esse�siologiche o comportamentali, che possono essere utilizzate al �ne diidenti�care l'utente. Il difetto di molte tecniche biometriche è però quel-lo di richiedere dell'hardware supplementare per essere applicate, comescanner di impronte digitali o dispositivi per l'analisi della retina, ren-dendo tali approcci di�cilmente applicabili su larga scala. Nella maggiorparte dei casi, inoltre, l'autenticazione avviene in singoli istanti prede�-niti e richiede l'interazione diretta dell'utente stesso, come l'inserimentodi username e password in opportuni form o la veri�ca dell'impronta di-gitale. Questo permette di garantire l'e�ettiva legittimità dell'accesso aiservizi al momento del login.

Hanno recentemente iniziato a di�ondersi studi che propongono unapproccio radicalmente diverso, in cui si tenda di utilizzare la dinami-ca di utilizzo del mouse come una proprità biometrica. Monitorandol'utilizzo del dispositivo di puntamento e registrando gli eventi di interes-se, è possibile estrarre delle caratteristiche numeriche che descrivano leabitudini, potenzialmente discriminanti, di un particolare soggetto.

1

Page 14: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

1. Introduzione 2

Un sistema di questo tipo può essere utilizzato come complementoe supporto alla tradizionale autenticazione, attuando una veri�ca conti-nua dell'identità e generando degli alert nel caso si riscontrassero delleanomalie. Inoltre il processo di veri�ca può avvenire in modo traspa-rente all'utente che, durante la normale navigazione, produce in modonaturale le informazioni da analizzare. In�ne, questo approccio non ri-chiede l'installazione di hardware supplementare ed è pertanto facilmenteapplicabile, in linea di principio, su larga scala.

In questo lavoro di tesi, svolto nel laboratorio di Machine Learningdell'Università di Trieste, ci si è posti l'obiettivo di realizzare un sistemadi autenticazione continua applicabile allo scenario della navigazione weblibera, cioè in ambiente non controllato. Registrando gli eventi generatidal mouse durante l'interazione dell'utente con le pagine web e �ltrando idati di interesse si sono estratte delle features caratterizzanti, utili per lasuccessiva fase di classi�cazione, avvenuta grazie a strumenti di Machi-ne Learning. Il sistema realizzato è trasparente agli utenti, non richiedecioè hardware aggiuntivo o con�gurazioni particolari lato client, ed è ap-plicabile a qualunque sito web. Gli esperimenti compiuti sull'utenza dellaboratorio hanno dimostrato un'accuratezza di circa 94%.

Nei capitoli seguenti si esporrà il processo di ricerca e�ettuato, pre-sentando lo scenario e il problema da a�rontare e analizzando lo statodell'arte, descrivendo lo strumento utilizzato per la raccolta dei dati epresentando gli esperimenti condotti e i risultati ottenuti.

Page 15: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 2Scenario

In questo capitolo si focalizza il problema in esame, de�nendo i dettaglidegli obiettivi preposti. Nella sezione 2.1 viene presentato il problema del-l'autenticazione continua tramite dinamica del mouse e messo a confrontocon le attuali tecniche. Quindi si fornirà una panoramica dello stato del-l'arte so�ermandosi sugli aspetti e sulle considerazioni che possono essereespresse in seguito all'analisi della letteratura scienti�ca. Per �nire, nellasezione 2.3, viene descritto lo strumento utilizzato per la raccolta dei datie le con�gurazioni da attuare per renderlo operativo.

2.1 Descrizione del problema

Il problema dell'autenticazione tramite dinamiche del mouse, si fonda sul-le stesse basi dei già noti sistemi biometrici come la scansione dell'irideo delle impronte digitali: la diversità di caratteristiche che contraddistin-gue gli esseri umani può essere sfruttata per la distinzione degli stessisoggetti. Se da un lato le impronte digitali o la trama dell'iride sono ca-ratteristiche sostanzialmente univoche tra le persone, per veri�care questeinformazioni si rende necessario l'utilizzo di sistemi �sici dedicati e spessocostosi, che attualmente non possono essere impiegati in maniera estesanel campo dell'elettronica di consumo che mira alla riduzione del prez-zo dei dispositivi in commercio. Inoltre, l'applicazione di queste tecnicherichiede la partecipazione attiva dell'utente, si pensi alla necessità di avvi-cinare l'occhio o le dita al lettore di iride o di impronte digitali. Pensandoa scenari reali di utilizzo, sarebbe auspicabile un sistema di autenticazio-ne che sia il più possibile trasparente e non invasivo. Se consideriamo iltradizionale meccanismo di autenticazione basato su password, uno svan-taggio evidente, oltre alla possibilità di furto delle credenziali, è quellodella scomodità data dal fatto di dover digitare �sicamente la password

3

Page 16: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

2. Scenario 4

più volte nell'arco di una giornata, a meno di non utilizzare plugin e com-ponenti aggiuntivi dei browser per l'autocompletamento dei form di login.Come già anticipato poi, l'approccio tradizionale all'autenticazione di unutente è del tipo a punto di accesso: agli utenti è richiesto di autenticarsiin determinati istanti e tempistiche (solitamente all'inizio dell'interazionecon il servizio tramite form dedicati). Questa caratteristica rende l'au-tenticazione 'intermittente' problema a cui si potrebbe ovviare riducendoil tempo massimo della durata di una sessione per consentire delle veri�-che più frequenti, chiedendo quindi all'utente di autenticarsi a intervallibrevi e regolari. Ma ciò porterebbe ad un'invasività del meccanismo checrescerebbe �no a diventare eccessiva e controproducente nell'ambito quo-tidiano. La ricerca di un meccanismo di autenticazione che sia allo stessotempo a�dabile e poco invasivo (se non completamente trasparente), sipuò concentrare sulle metodologie pseudo-biometriche che si servono deglieventi generati dall'utente durante la regolare navigazione. Raccogliendoi dati generati dalle interazioni degli utenti, infatti, è possibile disporre diinformazioni che possono essere utilizzate sia in tempo reale che in istan-ti successivi. Nel caso del loro utilizzo in tempo reale, si può parlare diautenticazione continua, che si distingue dall'usuale meccanismo statico,come sarà spiegato nella prossima sezione. In particolare si è cercato diformalizzare un metodo di raccolta dei dati e di analisi degli stessi perprodurre un approccio di autenticazione continuo che rispondesse alle ri-chieste di non invasività e di e�cienza. L'idea è quella di registrare tuttigli eventi che occorrono durante l'interazione di un utente con le pagineweb visitate, in particolare concentrandosi sugli eventi del mouse come imovimenti e i click. Avendo a disposizione le sequenze di tutti gli eventigenerati dagli utenti si dovrà poi a�rontare una fase di analisi per cercaredi caratterizzarli sulla base delle loro sequenze (o sottosequenze) di even-ti. Per la registrazione delle interazioni ci si è serviti di uno strumentoprecedentemente implementato nell'ambito di una tesi quinquennale.

2.2 Stato dell'arte

In letteratura le pubblicazioni che trattano di autenticazione attraversola dinamica del mouse, possono essere divise in due categorie.

Nel primo gruppo trovano posto le soluzioni che sfruttano un pun-to di accesso determinato e che richiedono esplicitamente l'attenzionee l'interazione dell'utente. Tipicamente l'autenticazione viene eseguitachiedendo ai soggetti di eseguire un task di operazioni o una serie di mo-vimenti e click ben precisi, appositamente studiati per ricavare un pro�loda poter confrontare con quello di riferimento [6, 7, 8, 9]. Si tratta di unamodalità de�nita static authentication, che richiede dunque un punto di

Page 17: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5 Stato dell'arte

accesso statico, simile all'approccio normalmente utilizzato per l'accessotramite username e password.

La seconda tipologia di studi si concentra, invece, sulla continuousauthentication, ossia un processo continuo che mira a veri�care ininter-rottamente l'identità dell'utente, attraverso l'analisi del comportamentonell'utilizzo del mouse (e della tastiera), durante la navigazione web oattività di routine. In questo scenario, i dati vengono raccolti in modotrasparente, mirando allo sviluppo di sistemi non invasivi [10, 11]. Per lamaggior parte degli studi il metodo di raccolta dati prevede l'utilizzo diapplicazioni eseguite in background ed implementate in diversi linguaggidi programmazione. Tali metodi possono essere potenzialmente utilizzatiintegrando gli usuali approcci e permetterebbero di coprire gli interval-li di tempo in cui, se si utilizzasse l'autenticazione statica, potrebberosorgere problemi di sicurezza.

Ciò che emerge dall'analisi della letteratura è che in generale le pre-stazioni raggiunte dai vari sistemi non rientrano, al momento, nei valoriminimi necessari �ssati dallo standard europeo per le biometriche com-merciali (FNR< 0.001% e FPR< 1%, per il signi�cato di questi indici siveda la sezione 4.3.3) e dunque, allo stato attuale, l'analisi dei comporta-menti nell'uso del mouse non può considerarsi una biometrica sostitutivadei vari meccanismi di autenticazioni attuali. L'utilizzo congiunto di que-sta metodologia e del di�uso paradigma username-password, può fornireinvece un interessante contributo alle tecniche standard, permettendo diestendere la veri�ca dell'utente anche agli istanti successivi ad una primaautenticazione.

L'approccio che appare ormai consolidato in questo �lone di ricer-ca consiste nell'utilizzo di tecniche di Machine Learning. Si registranoinizialmente i dati relativi all'utilizzo del mouse con diverse modalità eapplicazioni sviluppate per l'occasione, per poi eseguire una fase di featu-res extraction. Questa fase consiste nel ricavare da un insieme di sequenzedi eventi dei feature vector ossia dei vettori le cui componenti siano costi-tuite dal valore di una certa feature per quella data sequenza. Esempi difeatures possono essere la lunghezza totale di una traiettoria, la velocitàmedia o il numero di click in un certo intervallo di tempo. Per ogni utentesi produrranno quindi un insieme di vettori di features che costituirannol'input per gli strumenti di classi�cazione.

Va sottolineato che, a di�erenza di altre biometriche, come quellebasate sulle impronte digitali o sull'iride, i comportamenti degli utentipossono subire notevoli variazioni, rendendo le prestazioni anche moltovariabili nel tempo. Tali abitudini possono essere in�uenzate dalla di-versità dei dispositivi di puntamento utilizzati, nonché dalla risoluzionedello schermo o da altre variabili ambientali spesso non considerate [8].

Page 18: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

2. Scenario 6

Si rileva la mancanza di dataset pubblici disponibili, rendendo i risul-tati dei vari approcci non direttamente confrontabili tra loro.

Per concludere, l'unico prodotto commerciale, allo stato attuale chesi è potuto individuare sul mercato, propone un sistema di continuousauthentication basato sia sulla dinamica del mouse, sia sulla pressionedei tasti della tastiera 1. Il sistema è cosituito da un'architettura client-server con due tipologie di client. Un primo client application-based puòessere installato su singole workstation per monitorare l'utente durantetutti i task (non solo quelli di navigazione web). Il secondo tipo di clientè web-based nella forma di plugin utilizzati per monitorare l'attività dinavigazione dell'utente in singoli siti web.

Un sistema implementato che sfrutti unicamente le informazioni de-rivanti dalla dinamica del mouse per attuare l'autenticazione continuadurante la navigazione web, in uno scenario non controllato non è, alnostro stato di conoscenza, attualmente disponibile sul mercato.

2.3 GWT-Observer

Riscontrata la mancanza di dataset pubblici a disposizione, si è dovutaa�rontare una fase di raccolta dei dati. A di�erenza degli approcci �noratrovati in letteratura, che prevedevano l'utilizzo di applicazioni sviluppateper l'occasione in diversi linguaggi di programmazione, si è optato per unasoluzione basata su un'architettura web. Per questi scopi si è utilizzatouno strumento, GWT-Observer, precedentemente realizzato nell'ambitodi una tesi. L'applicativo in questione fornisce le funzionalità per laregistrazione remota delle informazioni relative alla navigazione web diuno o più utenti. Il sistema si compone di due parti:

• client, eseguito nel browser degli utenti;

• server, addetto a ricevere i dati dai client.

Il client è costituito da uno script JavaScript che, se integrato in undocumento HTML, permette di raccogliere tutte le informazioni qualimovimenti del cursore, eventi della tastiera e click del mouse inviandolial server.

Il server è un webservice implementato mediante una servlet Javaper gestire le varie sessioni e ricevere le informazioni inviate dai client.Permette di salvare gli eventi registrati in �le XML dai quali si potrannoestrarre le informazioni di interesse.

Lo strumento è stato utilizzato in una modalità di utilizzo che lo rendecompletamente trasparente agli utenti e ai siti web visitati. Impostandolo

1http://plurilock.com/products/biotracker

Page 19: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

7 GWT-Observer

come server proxy, tramite una semplice con�gurazione del browser, laraccolta delle informazioni avviene in modo non intrusivo e senza richie-dere l'attenzione dell'utente che può continuare navigare normalmentesul web.

2.3.1 GWT-Obesrver client

La parte client dell'applicativo è in esecuzione nel browser. Dal puntodi vista dell'utente, l'esecuzione è trasparente e viene avviata medianteuna chiamata allo script, all'atto del caricamento della pagina HTML. Ilclient, una volta avviato, stabilisce una connessione con il servizio server einizia la trasmissione delle informazioni relative alle azioni dell'utente. Inparticolare vengono rilevate e inviate al backend le seguenti informazioni:

• Movimenti e posizione del cursore del mouse;

• Pressione dei tasti del mouse;

• Velocità della rotella del mouse;

• Pressione dei tasti della tastiera;

• Scroll della �nestra;

• Resize della �nestra;

• Informazioni relative al rendering della pagina.

Le informazioni relative agli eventi vengono raccolte dal client e regi-strate localmente per poi essere inviate al server ad intervalli periodici ditempo oppure quando il numero di eventi attualmente memorizzati su-pera una certa soglia. Il client e�ettua anche una selezione degli eventi,registrandone al più un numero �ssato per intervallo di tempo. La con-nessione tra client e server viene chiusa quando viene rilevata la chiusuradella pagina oppure quando viene caricata un'altra risorsa.

2.3.2 GWT-Observer server

Il backend di GWT-Observer è stato progettato per essere eseguito al-l'interno di un application server conforme alle speci�che JavaEE5. Essomette a disposizione un servizio web in attesa di richieste da parte deiclient descritti nel paragrafo precedente. Il server è in grado di gestireaccessi concorrenti, consentendo di registrare contemporaneamente piùinterazioni di diversi utenti. Le informazioni ricevute dal server, al ter-mine di una connessione con un client, vengono salvate in �le XML e resequindi disponibili per l'analisi dei dati.

Page 20: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

2. Scenario 8

2.3.3 Modalità di utilizzo

Originariamente l'applicativo è stato pensato per funzionare in due pos-sibili modalità: direct o proxy.

Nella modalità direct, il gestore di un sito web può registrare le intera-zioni degli utenti con le pagine web di interesse del proprio dominio. Perfar sì che questo accada, è necessario aggiungere manualmente il codiceHTML per la chiamata allo script dell'applicativo, nel body o nello headdelle pagine da monitorare. Nel Codice 2.1 è mostrata la linea di codiceda inserire in ognuna delle pagine.

1 <body>

2 <script language="javascript" src="/GWT -Observer/it.

univ.trieste.observer/it.univ.trieste.observer.

nocache.js"></script >

3 [...]

4 </body>

Codice 2.1: Codice da inserire nelle pagine da monitorare in modalità direct

Questa modalità risulta scomoda qualora il sito web o le pagine da moni-torare siano in grande quantità. Inoltre per i nostri scopi non è funzionale,in quanto non si sono posti vincoli ai domini da analizzare.

La modalità proxy, quella utilizzata per il nostro studio, consente diregistrare tutte le interazioni degli utenti con qualunque pagina web vi-sitata. L'applicativo deve essere per questo motivo associato all'utilizzodi un server proxy HTTP con�gurato per lo scopo. Un software di redi-rection permette quindi di istruire il sistema ad inoltrare le richieste deiclient di GWT-Observer verso il backend, consentendo la comunicazionetra le due parti del sistema. Il codice HTML, che nella modalità directdoveva essere inserito manualmente nelle pagine da monitorare, in questocaso viene iniettato automaticamente da un server ICAP, un server che halo scopo di modi�care il contenuto delle pagine web richieste dall'utente.Nel nostro caso l'unica operazione necessaria è l'inserimento della riga dicodice che permette di eseguire lo script dell'applicativo, già mostrata inprecedenza. La struttura dell'architettura è rappresentata in Figura 2.1.

L'utilizzo di un software per la redirection si rende necessario peraggirare le limitazioni imposte da una importante politica di sicurezzachiamata SOP.

2.3.4 La SOP

La SOP (Same Origin Policy) [12] è una politica di sicurezza che inte-ressa un vasto numero di linguaggi di programmazione lato client. Iltermine origine de�nisce una particolare con�gurazione data dal nome

Page 21: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

9 GWT-Observer

Figura 2.1: Architettura del sistema GWT-Observer in modalità proxy.

URL Errorehttp://www.esempio.com:81/dir/documento2.html Numero di porta di�erentehttps://www.esempio.com/dir/documento2.html Protocollo di�erentehtpp://www.altroHost.com/dir/documento.html Host di�erente

http://esempio.com/dir/documento2.html Host di�erente

Tabella 2.1: Esempi di funzionamento della SOP.

di dominio, dall'Application Layer Protocol e dal numero di porta diun URL. In generale, documenti prelevati da origini di�erenti sono iso-lati tra di loro. Ad esempio, se un documento prelevato all'indirizzohttp://esempio.com/documento1.html tenta di accedere al DOM di undocumento prelevato all'indirizzo https://esempio.com/documento2.html,la policy di sicurezza vieterebbe l'accesso in quanto l'origine del primodocumento (example.com, http, 80) non corrisponde a quella del secon-do documento (example.com, https, 443). Altri esempi di casistiche incui la SOP interviene, impedendo l'accesso sono riportati in Tabella 2.1.Nell'esempio si suppone che la pagina che richiede l'accesso alle risorsesia identi�cata dall'URL http://www.esempio.com/documento1.html. Danotare come il nome dell'host deve essere perfettamente uguale.

Al �ne di riuscire a comunicare con il server di GWT-Observer, l'appli-cativo client è stato progettato per eseguire le richieste in modo da rispet-tare la politica descritta. In particolare se il client è eseguito nel contestodi un documento identi�cato dall'URL http://www.dominio.com, tutte lerichieste contenenti le informazioni raccolte dall'applicazione saranno in-

Page 22: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

2. Scenario 10

viate all'URL http://www.dominio.com/GWT-Observer/nomeservizio. Lefasi di una richiesta inviata al backend dell'applicativo si compone di trefasi:

1. Il browser in cui è in esecuzione il client di GWT-Observer, percomunicare con il server, invia una richiesta a http://dominio.com/GWT-Observer/nomeservizio;

2. Il proxy invia l'URL della richiesta al servizio di URL-rewriterSquirm. Squirm identi�ca la presenza nell'URL di una chiamataal servizio di backend e modi�ca l'URL di destinazione della ri-chiesta in www.dominioServer.com/GWT-Observer/nomeservizio do-ve dominioServer.com è il dominio in cui è in esecuzione il serverGWT-Observer;

3. Squirm restituisce l'URL al proxy Squid che inoltra la richiesta delbrowser in modo trasparente, al nuovo URL che identi�ca il serviziodel lato server dell'applicativo.

Questa architettura permette quindi di risolvere in modo trasparentele limitazioni della SOP, consentendo al client di raccogliere le informa-zioni sull'uso del mouse e inviarle al server che potrà renderle persistentinei �le XML.

2.4 Con�gurazioni necessarie

La fase di raccolta dati è stata preceduta da quella di con�gurazione deibrowser degli utenti. Nelle impostazioni di sistema è bastato attivarel'opzione per l'utilizzo di un server proxy, inserendo l'indirizzo IP e laporta su cui il servizio resta in attesa di richieste, come mostrato inFigura 2.2.

2.4.1 Registrazione su protocollo HTTPS

Da una rapida analisi delle abitudini degli utenti coinvolti, si è constata-to come la quotidiana navigazione internet coinvolga, per larghi intervallitemporali, risorse che utilizzano il protocollo applicativo HTTPS. Taleprotocollo permette di creare canali di comunicazione criptati tra i cliente i server, grazie allo scambio di certi�cati. In internet questo permettedi fornire l'autenticazione di un sito web e del relativo web server, pro-teggendo l'utente che utilizza il browser e che accede alla risorsa di essereprotetto dagli attacchi man-in-the-middle. La necessità di permettereil funzionamento dell'applicativo GWT-Observer anche in HTTPS, harichiesto quindi di creare una coppia di chiavi per la crittogra�a a chia-ve pubblica e un certi�cato auto�rmato utilizzato dal proxy server [13].

Page 23: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

11 Con�gurazioni necessarie

Figura 2.2: Menù di sistema per attivare l'utilizzo del server proxy.

Senza questo passaggio, infatti, la navigazione con protocollo HTTPSsarebbe impedita dal browser (Chrome in particolare).

Il certi�cato auto-�rmato è stato generato in ambiente UNIX tramiteil comando openssl. Eseguendo il comando sotto riportato, ci vengonorichieste alcune informazioni da associare al certi�cato. Al termine delprocesso verrà generato il �le in formato .pem. In�ne otteniamo unacopia in formato .der per essere importata nei browser degli utenti. Ilprocedimento è descritto nel Codice 2.2.

1 openssl req -new -newkey rsa :1024 -days 365 -nodes -

x509 -keyout certificato.pem -out certificato.pem

2 You are about to be asked to enter information that

will be incorporated

3 into your certificate request.

4 What you are about to enter is what is called a

Distinguished Name or a DN.

5 There are quite a few fields but you can leave some

blank

6 For some fields there will be a default value ,

7 If you enter '.', the field will be left blank.

8 -----

9 Country Name (2 letter code) [AU]:IT

10 State or Province Name (full name) [Some -State ]:

Page 24: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

2. Scenario 12

Italy

11 Locality Name (eg, city) []: Trieste

12 Organization Name (eg , company) [Internet Widgits

Pty Ltd]: Universita ' degli Studi di Trieste

13 Organizational Unit Name (eg , section) []:IT

14 Common Name (eg , YOUR name) []: MaLe Lab

15 Email Address []:.

16 openssl x509 -in certificato.pem -outform DER -out

certificato.der

Codice 2.2: Comandi UNIX per la creazione del certi�cato auto�rmato.

Una volta ottenuto il certi�cato, il proxy è stato opportunamente con-�gurato per utilizzarlo in ambito HTTPS, modi�cando il �le squid.conf,il �le di con�gurazione del proxy server SQUID. L'aggiunta di alcune ri-ghe (Codice 2.3) di con�gurazione permette di fare in modo che il serverutilizzi il certi�cato appena creato.

1 http_port 3128 generate -host -certificates=on ssl -

bump cert=/home/userlab/certificato/

certificatoLab.pem key=/home/userlab/certificato/

certificatoLab.pem

2 always_direct allow all

3 ssl_bump allow all

4 # the following two options are unsafe and not

always necessary:

5 sslproxy_cert_error allow all

6 sslproxy_flags DONT_VERIFY_PEER

Codice 2.3: Righe per la con�gurazione del proxy HTTPS.

L'ultima operazione è stata in�ne quella di importare il certi�cato neibrowser degli utenti, dichiarando �data la Certi�cation Authority rap-presentata dal MaLe Lab. In Chrome, dalle impostazioni del browser ènecessario aprire il menù Gestisci certi�cati. Da qui, sotto la tab Au-torità di certi�cazione radice attendibili, sarà su�ciente cliccare ilpulsante Importa per avviare il menù wizard che ci guiderà nel processodi importazione del certi�cato (Figura 2.3). Queste con�gurazioni sonosu�cienti per permettere al client di funzionare in tutte le condizioni,assicurando la registrazione degli eventi anche in presenza di navigazionecon protocollo HTTPS.

Page 25: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

13 Con�gurazioni necessarie

(a) Menù di Chrome per importa-re il certi�cato.

(b) Wizard di Chrome per impor-tare il certi�cato.

Figura 2.3: Importazione del certi�cato nel browser Chrome.

Page 26: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 27: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 3Costruzione del datset

In questo capitolo si forniranno i dettagli relativi alla fase di raccolta dati,che ha permesso la creazione di un dataset per i successivi esperimenti.

3.1 La raccolta dati

Terminata la fase di con�gurazione, è iniziata la vera e propria raccoltadati, con l'obiettivo di registrare un numero su�ciente di informazioniriguardanti le interazioni degli utenti con le pagine web visitate.

3.1.1 Durata e soggetti interessati

La fase di raccolta dati ha interessato 5 utenti. Per ragioni pratiche, gliutenti partecipanti sono stati scelti tra coloro i quali avessero la possibilitàdi svolgere le mansioni personali e di lavoro all'interno del laboratorio.

Il server in cui è stato installato l'applicativo GWT-Observer appar-tiene infatti alla sottorete del laboratorio di Machine Learning dell'Uni-versità di Trieste e nella con�gurazione attuale non è raggiungibile pub-blicamente dall'esterno della rete. Inoltre, la possibilità di assegnare nellasottorete degli indirizzi IP privati �ssi per ogni utente ha sempli�cato ilprocesso di classi�cazione dei dati grezzi raccolti, permettendo con im-mediatezza di distinguere i vari eventi registrati e associarli all'utente cheli ha generati.

Per quanto riguarda la durata della raccolta dati, essa è stata variabi-le a seconda dell'utente, non scendendo comunque sotto la settimana dimonitoraggio, tempo su�ciente a registrare un numero di eventi per sog-getto che fosse signi�cativo per i nostri obiettivi. Questa fase ha permessodi ottenere un insieme E degli eventi per ogni utente. Il numero di azioni

15

Page 28: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

3. Costruzione del datset 16

Utente |E| Tempo tot. (h)1 160 998 2402 260 158 763 206 130 4804 339 532 1645 244 140 385

Tabella 3.1: Numero di eventi registrati per utente.

rilevate e il tempo (in ore), calcolato come di�erenza tra il timestampdell'ultimo evento registrato e del primo, sono riportati in Tabella 3.1.

Da notare come un monitoraggio di relativamente poca durata (adesempio nel caso dell'utente 2) non si con�guri necessariamente in uninsieme ristretto di eventi registrati.

3.1.2 Vincoli e modalità

Le interazioni registrate sono state ottenute senza porre alcun vincolosul tipo di siti da visitare e sulle tempistiche o riguardo ad altri aspet-ti che potessero modi�care il normale comportamento di ogni soggetto.L'ambiente in cui si colloca questo esperimento è dunque di tipo noncontrollato, ossia lo scenario più prossimo alla realtà, ottenibile nelle no-stre condizioni. In e�etti, se escludiamo la con�gurazione del browser el'importazione del certi�cato, gli utenti hanno potuto utilizzare i loro di-spositivi in piena libertà, come in un qualsiasi regolare periodo di lavoro.Anche per quanto riguarda i dispositivi non ci sono state restrizioni: ognisoggetto ha utilizzato il proprio PC personale o di lavoro come al solito.In verità è stato chiesto ai partecipanti di servirsi di un dispositivo dipuntamento esterno (mouse) e di non sfruttare eventuali touchpad inte-grati dei pc portatili. Dato però che tale abitudine era già consolidatain tutti gli utenti, non vi sono state, in e�etti, limitazioni di sorta alleconsuetudini dei soggetti.

3.1.3 Descrizione �le XML

L'applicativo descritto produce come output un �le XML per ogni intera-zione tra un utente e una pagina web visitata. Per interazione si intendel'insieme delle azioni che un utente intraprende nel contesto di una singo-la pagina web. In prima approssimazione, per ogni pagina web richiestadall'utente sarà creato un �le contenente tutti gli eventi registrati. Se unutente visita più volte la stessa pagina web in istanti di�erenti, sarannocreati tanti �le quanto il numero delle volte in cui la pagina è stata visi-tata. In questi �le sono memorizzate tutte le azioni dell'utente (relative

Page 29: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

17 La raccolta dati

al mouse e alla tastiera) con il rispettivo istante temporale in cui sonostate generate. Il formato di un tipico evento registrato dall'applicativoè visibile nel Codice 3.1.

1 [...]

2 <it.univ.trieste.client.utils.shots.MouseAction >

3 <time>1267127711668 </time>

4 <eventType >64</eventType >

5 <scrollTop >0</scrollTop >

6 <scrollLeft >0</scrollLeft >

7 <x_Win>1500</x_Win >

8 <y_Win>212</y_Win >

9 </it.univ.trieste.client.utils.shots.MouseAction >

10 [..]

Codice 3.1: Evento registrato relativo ad un movimento del mouse.

Ogni evento, racchiuso in un elemento MouseAction, viene registratocon diverse informazioni, tra cui il timestamp e le coordinate assolute inpixel del punto in cui l'evento è stato generato dall'utente. Nel �le unaserie di eventi sarà quindi rappresentata da una successione di elementiMouseAction.

Ulteriori informazioni sono registrate all'interno di un elemento de-fault. Questi dati sono fondamentali per distinguere le varie interazioni epoterle associare ai giusti utenti. Nel Codice 3.2 è mostrato un esempio ditale elemento. Oltre agli istanti di inizio e �ne dell'interazione (startTi-me e endTime), si nota la presenza di un elemento URL che rappresental'indirizzo della pagina web a cui si riferisce l'insieme di eventi registrati.L'elemento userIP rappresenta l'indirizzo IP dell'host che ha generatol'insieme degli eventi contenuti nel �le. I restanti elementi sono utilizzatidall'applicativo per gestire correttamente il �usso di informazioni tra ilclient e il server.

1 [...]

2 <default >

3 <startTime >1374757557624 </startTime >

4 <endTime >1374757643730 </endTime >

5 <numTape >2</numTape >

6 <ID>13747575939164314 </ID>

7 <SID>5f0233c71c177043df197d12ece8 </SID>

8 <URL>https: //www.google.com</URL>

9 <correctlyClosed >true</correctlyClosed >

10 <referURL ></referURL >

11 <userAgent >Mozilla /5.0 (Windows NT 6.1; WOW64)

AppleWebKit /537.36 (KHTML , like Gecko) Chrome

/28.0.1500.72 Safari /537.36 </userAgent >

12 <userIP >172.30.42.116 </userIP >

13 </default >

Page 30: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

3. Costruzione del datset 18

14 [..]

Codice 3.2: Informazioni relative all'interazione.

3.2 Dati ottenuti

Durante l'arco della raccolta dati sono stati creati circa 13000 �le XMLper un totale di quasi 600 MB di informazione. Va speci�cato che il nume-ro di �le non corrisponde esattamente al numero di pagine web visitate,in quanto, nel caso una pagina web contenga degli iFrame, viene generatoun �le per ogni iFrame esistente. Ogni �le contiene quindi le informazionirelative agli eventi che si sono svolti in un iFrame. Per ricostruire l'interainterazione con una pagina web è necessario selezionare tutti gli eventipresenti nei diversi (eventuali) �le distinti e ordinarli temporalmente.

Per praticità l'applicativo assegna ai �le un nome univoco, costituitoda una coppia (ID-IP), consentendo un'elaborazione più facile nella fasedi selezione dei dati. L'ID rappresenta un identi�cativo univoco dell'in-sieme di eventi registrati nel contesto di un iFrame a cui si riferisce il�le e l'aggiunta dell'indirizzo IP al nome rende immediata l'assegnazionedi una interazione al relativo utente. Per completezza si riporta partedel contenuto saliente di uno dei �le generati durante la fase di raccol-ta dati. Nel Codice 3.3 è mostrata una serie di eventi di movimento(riconoscibili dal codice eventType 64), con le relative informazioni. No-tare anche gli elementi alla �ne del listato che contengono le informazionisull'interazione.

1 <it.univ.trieste.client.utils.Tape serialization="

custom">

2 <unserializable -parents/>

3 <vector >

4 [...]

5 <it.univ.trieste.client.utils.shots.MouseAction >

6 <time>1370941228321 </time>

7 <eventType >64</eventType >

8 <scrollTop >342</scrollTop >

9 <scrollLeft >0</scrollLeft >

10 <x__Win >221</x__Win >

11 <y__Win >479</y__Win >

12 </it.univ.trieste.client.utils.shots.MouseAction >

13 <it.univ.trieste.client.utils.shots.MouseAction >

14 <time>1370941228330 </time>

15 <eventType >64</eventType >

16 <scrollTop >342</scrollTop >

17 <scrollLeft >0</scrollLeft >

18 <x__Win >222</x__Win >

Page 31: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

19 Dati ottenuti

19 <y__Win >478</y__Win >

20 </it.univ.trieste.client.utils.shots.MouseAction >

21 <it.univ.trieste.client.utils.shots.MouseAction >

22 <time>1370941228335 </time>

23 <eventType >64</eventType >

24 <scrollTop >342</scrollTop >

25 <scrollLeft >0</scrollLeft >

26 <x__Win >224</x__Win >

27 <y__Win >478</y__Win >

28 </it.univ.trieste.client.utils.shots.MouseAction >

29 <it.univ.trieste.client.utils.shots.MouseAction >

30 <time>1370941228352 </time>

31 <eventType >64</eventType >

32 <scrollTop >342</scrollTop >

33 <scrollLeft >0</scrollLeft >

34 <x__Win >229</x__Win >

35 <y__Win >477</y__Win >

36 </it.univ.trieste.client.utils.shots.MouseAction >

37 <it.univ.trieste.client.utils.shots.MouseAction >

38 <time>1370941228359 </time>

39 <eventType >64</eventType >

40 <scrollTop >342</scrollTop >

41 <scrollLeft >0</scrollLeft >

42 <x__Win >233</x__Win >

43 <y__Win >476</y__Win >

44 </it.univ.trieste.client.utils.shots.MouseAction >

45 <it.univ.trieste.client.utils.shots.MouseAction >

46 <time>1370941228367 </time>

47 <eventType >64</eventType >

48 <scrollTop >342</scrollTop >

49 <scrollLeft >0</scrollLeft >

50 <x__Win >239</x__Win >

51 <y__Win >476</y__Win >

52 </it.univ.trieste.client.utils.shots.MouseAction >

53 <it.univ.trieste.client.utils.shots.MouseAction >

54 <time>1370941228375 </time>

55 <eventType >64</eventType >

56 <scrollTop >342</scrollTop >

57 <scrollLeft >0</scrollLeft >

58 <x__Win >251</x__Win >

59 <y__Win >477</y__Win >

60 </it.univ.trieste.client.utils.shots.MouseAction >

61 <it.univ.trieste.client.utils.shots.MouseAction >

62 <time>1370941228391 </time>

63 <eventType >64</eventType >

64 <scrollTop >342</scrollTop >

65 <scrollLeft >0</scrollLeft >

66 <x__Win >281</x__Win >

Page 32: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

3. Costruzione del datset 20

67 <y__Win >483</y__Win >

68 </it.univ.trieste.client.utils.shots.MouseAction >

69 </vector >

70 <it.univ.trieste.client.utils.Tape>

71 <default >

72 <elementCount >1382</elementCount >

73 <endTime >1370941276565 </endTime >

74 <numTape >17</numTape >

75 <startTime >1370941224625 </startTime >

76 <ID>13709412363381987 </ID>

77 <SID>277247239 c0a308d3d6ab3d550f7 </SID>

78 <URL>http: //27 esimaora.corriere.it/articolo/

hillary -clinton -debutta -su -twitter -con -una -

bio -memorabile/</URL>

79 <correctlyClosed >false </correctlyClosed >

80 <referURL >http://www.corriere.it/</referURL >

81 <userAgent >Mozilla /5.0 (Windows NT 6.2; WOW64;

rv:21 .0) Gecko /20100101 Firefox /21.0</

userAgent >

82 <userIP >172.30.42.117 </userIP >

83 </default >

84 </it.univ.trieste.client.utils.Tape>

85 </it.univ.trieste.client.utils.Tape>

Codice 3.3: Sequenza di eventi in un �le XML.

Notiamo che nella parte �nale del �le l'elemento elementCount cifornisce il numero di eventi registrati durante l'interazione. Il campoURL indica invece l'indirizzo della pagina web a cui si riferisce l'insiemedi eventi contenuti nel �le. Vi sono anche altre informazioni utilizzabili,che nel nostro caso non risultano di interesse, come l'indicazione dellouser agent.

3.3 Privacy degli utenti

Risulta evidente che lo strumento di registrazione può sollevare diversidubbi in merito alla privacy dell'utente monitorato. Il sistema originaleera in grado di memorizzare, oltre agli eventi del mouse, anche tutte lepressioni dei tasti della tastiera, con il relativo dettaglio del tasto pre-muto. Potenziali violazioni della privacy possono derivare dall'utilizzoscorretto dell'applicativo, che permetterebbe la registrazione di passworde credenziali private dell'utente. Per ovviare al problema della memo-rizzazione delle password, i dettagli relativi alla pressione dei tasti sonostati o�uscati, rendendo l'applicazione in grado di registrare solo il gene-rico evento 'pressione tasto' ma non registrando l'e�ettivo tasto premuto.

Page 33: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

21 Privacy degli utenti

In particolare, nei �le XML l'elemento che indica il keycode del tastopremuto è stato impostato ad un valore �sso pari a 100.

Page 34: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 35: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 4Analisi dei dati

La fase di raccolta dati ha permesso di ottenere un insieme di �le XML,ognuno corrispondente ad un insieme di eventi generati da un utente nelcontesto di un iFrame. Prima di procedere con l'analisi dei dati è statonecessario elaborare tali �le per selezionare le informazioni di interesse,ricostruire le interazioni con le singole pagine web e tradurle in un formatofacilmente utilizzabile dagli strumenti software utilizzati. Ottenuti i datinel formato voluto, si è a�rontata la fase di analisi, che viene qui descrittanei particolari.

4.1 Selezione informazioni

I �le, così come sono stati presentati nella sezione precedente, non sonoutilizzabili per i nostri scopi di analisi senza una preliminare elaborazione.È necessario infatti selezionare, per ognuno, le informazioni di interesseper i nostri scopi e tradurle in un formato pratico per gli strumenti soft-ware con cui condurremo l'analisi. All'interno di ogni documento sonopresenti numerosi dettagli che non sono necessari, basti pensare a tuttii tag degli elementi o a valori come numTape che sono esclusivamenteutilizzati dall'applicativo per una corretta memorizzazione del �usso didati dal client. Il nostro obiettivo è ottenere un �le in formato CSV 1

per ogni utente. In ognuno di questi CSV, le righe rappresenteranno unevento registrato e le colonne i vari campi descrittivi dell'evento, come iltimestamp e le coordinate in pixel del punto in cui l'evento è avvenuto.Procedendo in questo modo si otterranno dei �le riassuntivi di tutta l'at-tività di navigazione di ogni utente che saranno importabili facilmentenegli ambienti software che presenteremo.

1RFC 4180 - Common Format and MIME Type for Comma-Separated Values(CSV) Files. http://tools.ietf.org/html/rfc4180

23

Page 36: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 24

4.1.1 Applicativo Java

La selezione delle informazioni dai �le XML è avvenuta grazie ad un pro-gramma Java scritto appositamente. L'input dell'applicativo è costituitodall'intera collezione di �le XML generati da GWT-Observer, l'output daun �le CSV per ogni utente contenente tutti gli eventi registrati durantela fase di raccolta dati.

In ambiente Java sono possibili due approcci alla lettura di un �leXML. DOM e SAX sono i due parser più popolari usati nel linguaggioJava per eseguire il parsing di un �le XML. La di�erenza principale èil modo in cui i due parser lavorano. Il parser DOM (Document ObjectModel) carica l'intero �le XML in memoria e costruisce una rappresen-tazione ad albero del documento XML. L'utente potrà quindi navigarel'albero per accedere ai dati contenuti nei vari nodi del �le XML.

SAX è invece un parser event based e non carica in memoria l'interodocumento. In questo approccio, il parser genera degli eventi durante ilparsing del �le XML. Quando durante l'accesso al �le il parser incontraun tag iniziale <mioTag>, viene generato un evento tagStarted. Analo-gamente, incontrando un tag terminale </mioTag>, un evento tagEnded

viene generato. Sarà cura dell'utente gestire questi eventi per i propriscopi, quindi la struttura del �le deve essere gestita dall'utente, mentrenel caso DOM il lavoro sporco viene svolto dal parser stesso.

Per questi motivi il SAX parser è indicato nei casi in cui il �le da ac-cedere sia di notevoli dimensioni, in quanto un approccio DOM potrebbecausare un ingente utilizzo di memoria. Si migliorano le prestazioni in ter-mini di tempi di esecuzione, a scapito di un impegno maggiore in terminidi scrittura di codice.

Nel nostro caso, ci troviamo di fronte a un gran numero di �le XML dipiccole dimensioni (raramente oltre il MB). Vista la facilità di approcciofornita dal DOM parser e la quantità di memoria pienamente su�cientea disposizione, si è optato per questa soluzione.

L'applicativo creato, denominato XMLReader è stato implementatoper rispettare delle semplici speci�che. L'applicativo legge da una cartellaprede�nita tutti i �le XML così come sono stati prodotti dal sistemaGWT-Observer. Inoltre, l'esecuzione di XMLReader deve produrre un�le in formato CSV per ogni utente. Il �le dell'utente u conterrà tutte leinterazioni registrate durante la raccolta dati imputabili ad u. Ogni rigadel �le CSV costituisce un singolo evento registrato durante la navigazioneweb ed esso viene associato ad un certo numero di informazioni, quali:

• codice numerico per identi�care il tipo di evento

• coordinata X assoluta del punto in cui l'evento è stato generato

• coordinata Y assoluta del punto in cui l'evento è stato generato

Page 37: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

25 Selezione informazioni

• timestamp dell'evento, indica l'istante di tempo in cui l'evento èstato registrato

• ID della sessione a cui l'evento è associato

• indirizzo IP dell'host che ha generato l'evento

• URL della pagina web che l'utente stava visitando quando ha ge-nerato l'evento.

Un esempio di record contenuti nei �le CSV è rappresentato nelCodice 4.1

1 64 ,43 ,15 ,1370934279511 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

2 64 ,47 ,17 ,1370934279519 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

3 64 ,50 ,17 ,1370934279535 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

4 64 ,51 ,18 ,1370934279543 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

5 64 ,53 ,18 ,1370934279551 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

6 4 ,53 ,18 ,1370934279632 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,G

7 8 ,53 ,18 ,1370934279764 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,H

8 1 ,53 ,18 ,1370934279765 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,B

9 64 ,53 ,18 ,1370934279769 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

10 64 ,53 ,10 ,1370934279836 ,13709342824371506 ,172.30.42.118 ,

https :// www.google.com ,A

Codice 4.1: Esempio di �le generato da XMLReader.

Si nota come sia presente un'informazione aggiuntiva (ultimo elemen-to di ogni record). La lettera corrisponde ad una traduzione in simbolialfabetici del codice numerico dell'evento ed è stata inserita per sempli-�care l'elaborazione delle informazioni in ambiente R. Nell'applicativoXMLReader tale traduzione è eseguita dalla funzione traduciEvento, ilcui sorgente è rappresentato nel Codice 4.2.

1 private static String traduciEvento(String eventType)

{

2 switch(eventType) {

3 case "64":

4 return "A"; // MOVIMENTO MOUSE

5 case "1":

Page 38: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 26

6 return "B"; // ONCLICK

7 case "2":

8 return "C"; // ONDOUBLECLICK

9 case "128":

10 return "D"; // ONKEYDOWN

11 case "256":

12 return "E"; // ONKEYPRESS

13 case "512":

14 return "F"; // ONKEYUP

15 case "4":

16 return "G"; // ONMOUSEDOWN

17 case "8":

18 return "H"; // ONMOUSEUP

19 case "131072":

20 return "I"; // ONMOUSEWHEEL

21 case "16384":

22 return "J"; // ONSCROLL

23 default:

24 return "K";

25 }

26 }

Codice 4.2: La funzione traduciEvento.

4.1.2 Ordinamento record

L'output di XMLReader fornisce dei �le in un formato (CSV) che risultapratico per gli ambienti software utilizzati. La necessità di ottenere un�le con la sequenza di azioni eseguite dall'utente, richiede un ultimo passoprima di poter dire di avere il dataset 'pronto all'uso'. Per come è statoimplementato GWT-Observer, vi sono dei �le XML che corrispondonoad insiemi di eventi registrati all'interno di iFrame e quindi in un certosenso possiamo de�nirli degli slave Frame contenuti in una master page.Come già anticipato, quindi, al �ne di ottenere una sequenza di tuttigli eventi registrati in una singola pagina web è necessario concatenaretutti gli eventi registrati nella pagina master e negli eventuali iFramecontenuti. XMLReader legge sequenzialmente i �le e quindi non e�ettuaun ordinamento temporale dei record, che deve essere eseguito in questafase.

Si è utilizzato il comando UNIX sort che permette di ordinare numeri-camente un �le, speci�cando le colonne da considerare nell'ordinamento.Nel nostro caso, per ordinare un �le CSV rispetto alla colonna dei time-stamps, che come mostrato nel Codice 4.1 è la quarta, sarà su�cienteeseguire il comando:

sort -t ',' -k4,4 fileNonOrdinato.csv -o fileOrdinato.csv

Page 39: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

27 Approccio all'analisi dei dati

Tra le opzioni da speci�care troviamo il carattere di separazione del �le(nel nostro caso la virgola essendo un �le CSV), la colonna o camporispetto al quale e�ettuare l'ordinamento, il �le di input e quello di outputche conterrà i record ordinati.

Al termine di queste operazioni si sono ottenuti dei �le ordinati tem-poralmente, uno per ogni utente, contenenti le sequenze di tutti gli eventiregistrati durante il periodo di raccolta dei dati.

4.2 Approccio all'analisi dei dati

In questa sezione si descriveranno gli approcci ideati per a�rontare il pro-blema della ri-autenticazione continua tramite le mouse dynamics. Le in-formazioni raccolte nelle fasi precedenti sono numerose e, come vedremo,non sono tutte necessarie per la metodologia proposta in questo lavorodi tesi. Considerato che il sistema di registrazione è in grado di memo-rizzare un evento ogni centesimo di secondo, la risoluzione alla quale sisono memorizzate le azioni del mouse è stata molto elevata, producen-do d'altro canto ingenti quantitativi di dati che sono stati �ltrati. Adesempio pur potendo usufruire di tutti gli eventi del mouse, si è deciso diutilizzare solo le informazioni relative ai movimenti e ai click del mouse.L'approccio seguito ha mirato a selezionare delle sottosequenze di eventiprecedenti ai click e ad utilizzarle come input per un classi�catore. Perquesto scopo è stata utilizzata SVM, un particolare strumento di MachineLearning di cui si darà una breve descrizione. Tramite questa tecnica siè quindi cercato di classi�care gli esempi in input come esempi positivio negativi, veri�cando se fosse possibile una distinzione degli utenti sullabase di queste sottosequenze di eventi.

La valutazione sperimentale condotta si è composta di diversi espe-rimenti, in cui sono stati variati uno o più parametri esistenti. In que-sto capitolo si descriveranno gli esperimenti condotti, mentre i risultatisaranno presentati in dettaglio nel capitolo successivo.

4.2.1 Sottosequenze precedenti i click

Alla luce delle precedenti considerazioni, si è deciso di concentrare l'at-tenzione sugli eventi precedenti ai click del mouse. Nello speci�co si èvoluto veri�care se una distinzione tra gli utenti sia attuabile sulla ba-se dei comportamenti che anticipano il click su un link o qualsiasi altraparte di una pagina web. Per ogni utente si sono, per questo, individuatii click del mouse e si sono selezionate le sottosequenze di eventi di lun-ghezza �ssa che precedono ogni click. Formalmente, sia E = (e1, e2, . . . )la sequenza di eventi relativa ad un utente. Data E, si è generata unasequenza C di sottosequenze come segue:

Page 40: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 28

1. si selezionano tutti gli eventi click in E

2. per ogni evento click ei, si considera la sottosequenza degli Nc even-ti precedenti al click: C = (ei−Nc , . . . , ei). Gli eventi possono esserea loro volta dei click, anche se questo è molto raro. Se due click suc-cessivi sono distanziati da più di Nc eventi, i restanti non vengonoconsiderati.

3. si aggiunge C a C. La sequenza C è ordinata rispetto al timestampdell'ultimo evento di ogni sottosequenza.

Questo procedimento consente di selezionare le sottosequenze di interesse,che saranno poi prese in considerazione per il passaggio successivo.

4.2.2 Le features

Una volta ottenute le 5 sequenze relative agli altrettanti utenti, si sonoprese in esame le sottosequenze che le compongono. Per caratterizzare levarie sequenze si è operata una fase di features extraction, che viene diseguito descritta.

Innanzitutto è necessario speci�care alcuni concetti a cui si farà ri-ferimento, in primis la nozione di direzione tra due punti. Ogni eventodelle sequenze contiene l'informazione spaziale relativa al punto (coordi-nate X e Y assolute) dello schermo in cui è stato generato. Una sequenzadi eventi può dunque essere considerata come una sequenza di punti sul-lo schermo, associati a istanti temporali dati dai timestamp, ossia unatraiettoria. Si consideri quindi un punto della sequenza e lo si facciacoincidere con il centro di una circonferenza. Si divida poi la circonferen-za in spicchi di 45◦ ciascuno e si numeri ogni settore, come mostrato inFigura 4.1. Con questa divisione è possibile assegnare un valore numeri-co alla direzione associata alle coppie di punti successivi nella sequenza,semplicemente considerando il settore in cui è situato il secondo puntodella coppia, traslando i punti in modo che il primo sia l'origine (cioèil centro della circonferenza immaginaria) e il secondo mantenga la suaposizione relativa rispetto al primo punto. Può succedere che due punticonsecutivi abbiano le stesse coordinate, quindi nessun valore della dire-zione sarebbe corretto. In questi casi si è arbitrariamente assegnato unvalore di direzione pari a 0, che indicherà dunque due punti sovrappostinel piano. Per ogni sottosequenza si sono calcolate quindi le occorrenzedelle direzioni per tutte le coppie di punti adiacenti.

Inoltre, avendo a che fare con sequenze di eventi tra le cui proprie-tà �gurano oltre alle coordinate x e y assolute, anche i timestamps, èpossibile parlare di velocità e accelerazioni. Ad esempio, velocità vabassociata ad una coppia di punti (xa, ya) e (xb, yb) relativi ad eventi re-gistrati negli istanti ta e tb (con ta < tb) è de�nita come il rapporto

Page 41: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

29 Approccio all'analisi dei dati

1

23

4

5

6 7

8

Figura 4.1: Numerazione delle direzioni tra due punti successivi.

tra la distanza dei due punti e la di�erenza dei loro timestamps, ossia:

vab =

√(xb−xa)2+(yb−ya)2

tb−ta; In seguito si utilizzerà la notazione vk per in-

dicare v(k−1)k. Analogamente, per l'accelerazione si considereranno duevalori di velocità relativi a coppie di punti ad esempio vab e vbc e side�nisce l'accelerazione come il rapporto tra la variazione di velocità el'intervallo di tempo in cui è avvenuta, formalmente aab,bc =

vbc−vabtc−tb

.Ad ogni sottosequenza C è stato associato un vettore delle features

f(C), le cui componenti sono le seguenti:

• la durata della sottosequenza, calcolata come tNC− t0;

• l'estensione orizzontale in pixel della sottosequenza, calcolata comemaxNC

k=0 xk −minNCk=0 xk;

• l'estensione verticale in pixel della sottosequenza, calcolata comemaxNC

k=0 yk −minNCk=0 yk;

• il numero di cambi di direzione nella sottosequenza, cioè il numerodi eventi ek per cui dk 6= dk−1;

• la distanza totale della sottosequenza in pixel, calcolata come∑NCk=1

√(xk − xk−1)2 + (yk − yk−1)2;

• la velocità media, in px/s calcolata come1

NC

∑NCk=1 vk;

• la direzione prevalente, ossia la direzione con l'occorrenza più altanella sottosequenza;

Page 42: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 30

• la direzione prevalente, senza considerare i valori nulli (nessun spo-stamento);

• la massima distanza tra gli eventi della sottosequenza e la linearetta che collega il primo e l'ultimo punto (x0, y0) e (xNC

, yNC);

• la direzione diretta tra il primo e l'ultimo punto della sottosequenza,cioè la direzione del vettore tra (x0, y0) e (xNC

, yNC);

• la distanza diretta tra il primo e l'ultimo punto della sottosequenzacioè

√(x0 − xNC

)2 + (y0 − yNC)2;

• la velocità media degli ultimi cinque eventi della sottosequenza, cioè15

∑NCk=NC−4 vk;

• la velocità media dei primi cinque eventi della sottosequenza, cioè15

∑4k=0 vk;

• 9 features relative alle occorrenze delle direzioni riscontrate nellasottosequenza tra coppie successive di punti. Per ogni punto dellasequenza (eccetto l'ultimo) si è calcolata la direzione tra esso eil punto successivo, così come de�nito all'inizio di questa sezione,a pagina 28. Se denotiamo con i ∈ {0, . . . , 8} la i-esima delle 9features, allora i rappresenta il numero di volte in cui il calcolodella direzione ha dato come risultato la direzione i.

• 9 features relative alle velocità tra le ultime 9 coppie di punti primadel click. Per k = (Nc− 8), . . . , Nc, la k-esima features rappresentail valore vk.

• 8 features relative alle accelerazioni tra gli ultimi dieci punti pri-ma del click. Per k = (Nc − 8), . . . , (Nc − 1) la k-esima featuresrappresenta il valore ak =

vk−vk−1

tk−tk−1.

Per ogni sottosequenza il vettore f(C) associato conterà quindi 39 featu-res. Inizialmente si è �ssato il parametro Nc = 10.

Al �ne di escludere dall'analisi le sottosequenze 'intermedie', cioè quel-le costituite da eventi di interazioni diverse, si sono esclusi tutti i vettoriche presentassero un valore maggiore di 5 secondi per quanto riguarda lafeature relativa alla durata della sottosequenza. In Tabella 4.1 è riportatoil numero di vettori di features per ogni utente per Nc = 10.

4.3 La classi�cazione

Le fasi precedentemente descritte hanno consentito di ottenere un insiemedi vettori di features per ogni utente. Si è valutata ora la possibilità

Page 43: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

31 La classi�cazione

Utente |vettori|1 10872 15123 10024 18395 1110

Tabella 4.1: Numero dei vettori di features per utente (Nc = 10).

di discriminare gli utenti sulla base dei loro vettori di features. Comeaccennato in precedenza, per la classi�cazione ci si è serviti di SVM, cheintroduciamo brevemente.

4.3.1 SVM

In Machine Learning, le SVM (Support Vector Machines) sono un model-lo di apprendimento supervisionato sviluppato da Vladimir Vapnik, chetramite opportuni algoritmi di learning, permettono di analizzare dei datie riconoscere patterns, principalmente per scopi di classi�cazione. Sonodei classi�catori binari, ossia hanno lo scopo, dato un input, di assegnar-lo ad una delle due classi che la SVM può distinguere. Inizialmente vaeseguita la fase di training, che ha lo scopo di istruire la macchina per lafase successiva: dato un insieme di esempi di training, ognuno etichettatocome appartenente ad una delle due classi, l'SVM costruisce un modelloche permetterà di assegnare dei nuovi esempi ad una delle due classi. Ilmodello creato è una rappresentazione degli esempi come punti in unospazio, mappati in modo che esempi di categorie separate siano divise ilpiù nettamente possibile.

Più precisamente, SVM individua l'iperpiano, in uno spazio multidi-mensionale, che permetta di dividere in due lo spazio, a�nché in ogniarea siano contenuti gli esempi di una delle classi, ecco perché in questavariante è de�nito come classi�catore lineare. L'iperpiano scelto dovràavere distanza massima dagli esempi delle due classi e dividere gli esempiin due aree per l'appunto. In Figura 4.2 SVM individua in H3 l'iper-piano che consente di dividere i due gruppi di esempi con la separazionemaggiore. L'iperpiano H1 non è una soluzione al problema, in quantonon separa in due classi gli esempi, mentre H2 pur essendo una poten-ziale soluzione, non è l'iperpiano che permette di ottenere la separazionemaggiore tra i punti nello spazio. I nuovi esempi saranno classi�cati inbase alla loro posizione rispetto all'iperpiano, assegnando loro una delledue classi a disposizione. Formalmente, sia dato un insieme T di training

Page 44: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 32

Figura 4.2: Separazione lineare indotta da SVM.

data costituito da n punti nella forma

T = {(xi, yi)|xi ∈ Rp, yi ∈ {−1, 1}}ni=1 (4.1)

dove ogni yi ha valore o 1 o −1, indicando a quale delle due classi ilpunto xi appartiene. Ogni punto xi è un vettore p-dimensionale di valorireali. L'obiettivo è quello di trovare l'iperpiano che divide, con marginemaggiore, i punti aventi yi = 1 da quelli aventi yi = −1. Sia w il vettorenormale all'iperpiano, e b il termine costante, allora ogni iperpiano puòessere de�nito come l'insieme dei punti x tali per cui

wT · x+ b = 0 (4.2)

Se gli esempi per il training sono linearmente separabili, possiamo sele-zionare due iperpiani tali che separino gli esempi e non abbiano puntitra di loro. Si indichi con d− e d+ la minima distanza dall'iperpianodegli esempi negativi e positivi. Ora, si supponga che tutti gli esempi ditraining soddis�no i seguenti vincoli:

wTxi + b ≥ +1 per yi = +1 (4.3)

wTxi + b ≥ −1 per yi = −1 (4.4)

Page 45: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

33 La classi�cazione

che si possono riunire nell'espressione:

yi(wTxi + b)− 1 ≥ 0 (4.5)

Se si considerano i punti che rispettano il vincolo 4.4, si nota che essigiacciono sull'iperpiano h1 : xiw+ b = 1, dove w è la normale, a distanza|1−b|/‖w‖. Analogamente i punti che rispettano il vincolo 4.3, giaccionosull'iperpiano h2 : xiw + b = −1. Di conseguenza si ha che d− = d+ =1/‖w‖ e il margine è quindi di 2/‖w‖. I due iperpiani h1 e h2 sonoinoltre paralleli e tra essi non vi sono punti di training. SVM ha quindilo scopo di trovare i due iperpiani che massimizzano il margine, cioè cheminimizzano ‖w‖2 rispettando l'equazione 4.5. Il tutto si può quindide�nire come un problema di ottimizzazione (minimizzazione) dato da:{

minw,b12‖w‖

2

yi(wTxi + b) ≥ 1 i = 1, . . . , n

Dove, si ricorda, n è il numero dei punti del training set. I punti dell'in-sieme di training che veri�cano l'equazione yi(wTxi + b) = 1 sono dettivettori di supporto e se rimossi dal set sono i responsabili del cambio disoluzione del problema. Una volta de�nita la separazione tra le due classidisponibili, ogni input viene assegnato alla propria classe di appartenen-za (presunta) sulla base della sua posizione rispetto all'iperpiano soprade�nito.

Oltre alla classi�cazione lineare, SVM può operare anche la classi�-cazione non lineare, attraverso l'uso dei cosiddetti kernel che mappanogli input in spazi delle features di dimensioni eventualmente aumentate,per permettere una separazione degli esempi delle due classi che sia piùe�ciente rispetto al caso lineare. Non sempre, infatti, è possibile divi-dere linearmente i punti relativi agli esempi di training. In Figura 4.3ad esempio i punti delle due classi sono separabili solamente grazie aduna funzione non lineare che permette di proiettare i punti su uno spaziodelle features trasformato. In questo spazio trasformato, il classi�catoreutilizza un iperpiano, come nella versione base, ma pur essendo linearenello spazio a dimensioni aumentate, potrebbe non essere lineare nellospazio originale di input.

4.3.2 Training e testing SVM

Sebbene i dati di training siano stati diversi a seconda del tipo di espe-rimento condotto, le modalità con cui si sono addestrate le SVM sonosempre uguali. Ogni macchina SVM addestrata è associata ad un utente(detto anche utente legittimo) ed ha lo scopo di determinare se i vettoriin input appartengano ad esso o meno. Gli utenti non associati alla mac-china sono detti utenti fraudolenti. Per il training e la predizione si sono

Page 46: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 34

Figura 4.3: Trasformazione tramite kernel SVM.

utilizzati i parametri di default, utilizzando quindi un kernel radiale2. Arotazione ogni utente è stato considerato legittimo e si sono addestrate lerispettive SVM con la procedura che segue. Si sono addestrate 5 SVM perogni utente legittimo i, ad ognuna delle quali sono stati forniti 4 insiemidi vettori:

• F−i : il training set degli esempi negativi, ossia l'insieme di vettori

di features, appartenenti all'utente legittimo, utilizzato per la fasedi training.

• F+i : il training set degli esempi positivi, ossia l'insieme di vettori di

features, appartenenti agli utenti fraudolenti, utilizzato per la fasedi training.

• F−i,test: il testing set degli esempi negativi, ossia l'insieme di vettori

di features, appartenenti all'utente legittimo, utilizzato per la fasedi testing.

• F+i,test: il testing set degli esempi positivi, ossia l'insieme di vettori

di features, appartenenti agli utenti fraudolenti, utilizzato per lafase di testing.

Gli insiemi sopra descritti sono stati composti in modo diverso perognuna delle 5 SVM associate ad ogni utente i. Sia Fi l'insieme dei vettoriassociati all'utente i. Ognuno di questi insiemi è stato partizionato in 5insiemi con la stessa cardinalità ed indichiamo con F k

i il k-esimo di questiinsiemi. Per la k-esima di queste macchine (k = 1, . . . , 5) :

• F−i,test: è costituito dall�insieme F k

i ;

• F+i,test: unione degli insiemi F (k+1)mod5

j per ogni utente j (j 6= i);

2http://en.wikipedia.org/wiki/Radial_basis_function_kernel

Page 47: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

35 La classi�cazione

• F−i : i restanti 4/5 di Fi non utilizzati per l'insieme F−

i,test

• F+i : unione degli insiemi F k

j per ogni utente j (j 6= i).

In Figura 4.4 è descritto visivamente il processo di costruzione degliinsiemi di training e testing relativi al solo primo utente. Con questo ap-proccio, ne consegue che per ogni esperimento si sono addestrate 25 SVM,5 per ogni utente, al �ne di minimizzare e�etti negativi sulle prestazionidati da insiemi di features vector sfortunati.

Per quanto riguarda il testing, dati gli insiemi F−i,test e F

+i,test, la va-

lutazione nel nostro approccio è avvenuta con un metodo che potremmode�nire a maggioranza:

1. si è �ssato il valore del parametro w che rappresenta il numero divettori utilizzati per discriminare l'utente legittimo;

2. si sono valutati tutti gli insiemi, di w vettori successivi di F−i,test,

shiftati di un'unità. Su ogni insieme si è applicata la decisione:

• maggioranza di vettori classi�cati legittimi → utente autenti-cato;

• altrimenti → utente non autenticato;

3. si è ripetuto il punto 2 per l'insieme F+i,test.

Quindi, ad esempio, se F−i,test fosse composto di 100 campioni, che

denotiamo con {c1, c2, . . . , c100} e il valore del parametro fosse w = 10,si valuterebbe l'insieme {c1, c2, . . . , c10}, poi l'insieme {c2, c3, . . . , c11} ,�no all'ultimo insieme {c91, c92, . . . , c100}. Risulta evidente che con uninsieme di n campioni si valutino in totale n − w insiemi di w featurevector, ottenendo lo stesso numero di decisioni del tipo autenticato/nonautenticato.

4.3.3 Indici di prestazione

I risultati che saranno presentati nel prossimo capitolo saranno fornitimediante degli indici di prestazione che descriviamo in questa sezione.Tali indici sono le percentuali Accuracy, Falsi Positivi e Falsi Negativi.

L'accuracy è la percentuale di predizioni esatte eseguite dalla SVMin analisi. Ciò vuol dire che se su n insiemi di campioni la macchinaetichetta correttamente sia quelli legittimi che quelli fraudolenti, alloral'accuracy sarà del 100%. In generale se su n campioni ne vengono cor-rettamente etichettati k, allora l'accuracy sarà data da k/n. Da sola ilvalore di accuracy non è sempre su�ciente a fornire un quadro esatto del-le prestazioni del sistema. Ad esempio un valore di accuracy molto alto

Page 48: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

4. Analisi dei dati 36

F1 F2 F3 F4 F5

k = 5

k = 4

k = 3

k = 2

k = 1

F−1 F+

1 F−1,test F+

1,test

Figura 4.4: Creazione dei training e testing set per l'utente 1.

Page 49: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

37 La classi�cazione

non è sinonimo di un buon funzionamento se la SVM tende ad assegnaretutti i campioni in una delle due classi e allo stesso tempo gli esempi daclassi�care appartengano in grande maggioranza proprio alla classe versocui la SVM è sbilanciata. Nel momento in cui si forniscono in input allaSVM dei campioni dell'altra classe, questa sbaglierà la predizione ma sulcomputo totale degli esempi, questi pochi errori non in�uiranno pesante-mente. Per capire meglio consideriamo un esempio pratico. Si chiaminole due classi in gioco A e B e si supponga che per qualche motivo (casolimite) l'SVM che stiamo utilizzando sia fortemente sbilanciata verso unadelle due classi, tanto da assegnare la totalità dei campioni da valutarealla classe A. Siano inoltre tA e tB due insiemi di esempi da testare, dovetA è l'insieme di campioni appartenenti alla classe A e tB l'insieme dicampioni appartenenti alla classe B. Se le cardinalità dei due insiemi so-no fortemente sbilanciate verso la classe A, diciamo |ta| = 90 e |tB| = 10,allora l'accuracy totale sarebbe del 90% anche se in realtà la macchinanon è in grado e�ettivamente di identi�care i campioni appartenenti al-la classe B. L'accuracy sarebbe più signi�cativa se gli esempi forniti ininput alla SVM fossero in numero uguale per le due classi. Se nella fasedi training noi possiamo intervenire fornendo alla macchina due insiemibilanciati, durante il funzionamento non è detto che gli esempi in ingressosiano per forza bilanciati tra le due classi.

Per fornire una valutazione più completa ci si serve solitamente anchedi altri due indici, ossia la valutazione del numero di falsi positivi e di falsinegativi. Nel nostro caso, dobbiamo pensare alla SVM come una sortadi sistema che emette un allarme qualora rilevi un campione in input chenon appartenga alla stessa classe la cui macchina è associata. Si pensiad un potenziale scenario pratico di utilizzo: una SVM addestrata perriconoscere l'utente u che rilevi eventuali utilizzi del browser da parte diutenti diversi da u. La macchina è sempre di fronte ad una scelta binaria,cioè assegnare l'input ad una delle due classi a disposizione, quella relativaall'utente u e la seconda relativa a tutti gli altri potenziali utenti diversida u. Qualora il sistema rilevi uno o più esempi di utenti 'estranei'viene lanciato un alert che informa sul potenziale utilizzo fraudolento delbrowser. In questo scenario ci possono essere due modi in cui la macchinapuò sbagliare l'assegnazione della classe: può accadere che l'utente uvenga classi�cato come estraneo, in questo caso il sistema segnala unFalso Positivo, oppure un utente estraneo può venire classi�cato comeutente u e si cade in questo caso in un Falso Negativo. I falsi positivie negativi saranno d'ora in poi denotati con gli acronimi FPR (FalsePositive Ratio) e FNR (False Negative Ratio).

Page 50: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 51: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 5Valutazione Sperimentale

In questo capitolo sono presentati i diversi esperimenti compiuti e i ri-sultati ottenuti. Per ogni esperimento viene data una breve descrizionee successivamente, grazie all'ausilio di gra�ci e tabelle vengono riporta-ti i relativi risultati in termini dei valori degli indici di prestazione giàpresentati nella sezione 4.3.3.

5.1 Presentazione dei risultati

I risultati ottenuti nei vari esperimenti sono presentati principalmentetramite gra�ci Box-and-Whisker. Per praticità si fornisce di seguito unadescrizione delle informazioni visualizzate da questo tipo di gra�co, chein generale risulta utile per descrivere la distribuzione di un campione divalori. In Figura 5.1 è rappresentato un tipico dettaglio del gra�co 'a can-dela' con l'indicazione delle varie informazioni visualizzate. In particolaresi notano le seguenti caratteristiche:

• Outliers: sono rappresentati da dei piccoli cerchi in corrispondenzaal valore che rappresentano. Nel caso di più outliers con lo stessovalore, questi sono visualizzati a�ancati. Gli outliers sono conside-rati tali se il loro valore è maggiore dei 3/2 del quartile superiore ominore dei 3/2 del quartile inferiore.

• Limite superiore: rappresenta il valore massimo della serie di dati,escludendo gli outliers.

• Quartile superiore: i quartili sono de�niti come quei valori che ri-partiscono la popolazione in quattro insiemi di uguale cardinali-tà. Il quartile superiore ci indica cioè che il 25% di tutti i valoriconsiderati sono maggiori del quartile stesso.

39

Page 52: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 40

Outliers

Outliers

Limite superiore

Quartile superiore

Mediana

Quartile inferiore

Limite inferiore

Figura 5.1: Gra�co Box and Whisker.

• Mediana: ci informa che il 50% dei valori considerati sono superiorial valore della mediana stessa.

• Quartile inferiore: in questo caso sappiamo che il 25% dei valorisono inferiori al quartile inferiore.

• Limite inferiore: rappresenta il valore minimo della serie di dati,escludendo gli outliers.

Nel nostro caso, per chiarezza di visualizzazione, si sono omessi gli ou-tliers dai gra�ci. Tutti i gra�ci riportati hanno inoltre come valori delleascisse il parametro w relativo alla larghezza della �nestra utilizzata perdeterminare l'appartenenza dell'insieme di feature vector ad una delledue classi individuate dalla SVM. Sulle ordinate, a seconda del gra�cocompariranno i valori di accuracy, FPR o FNR. Oltre ai gra�ci Box-and-Whisker, si sono utilizzati anche tabelle e gra�ci più intuitivi che sarannoper questo descritti nel corso del capitolo.

Page 53: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

41 Esperimento 1

Utente FPR σ FPR FNR σ FNR Accuracy1 0.14 0.03 0.29 0.06 0.742 0.10 0.07 0.12 0.04 0.883 0.12 0.07 0.27 0.11 0.764 0.16 0.07 0.27 0.08 0.755 0.10 0.06 0.32 0.10 0.72

Media 0.13 0.06 0.25 0.08 0.77

Tabella 5.1: Indici di prestazione per Nc = 10 e w = 11.

5.2 Esperimento 1

In questo esperimento si sono �ssati i valori dei parametri w e Nc. Inparticolare abbiamo valutato le prestazioni del sistema e�ettuando unavalutazione a maggioranza su insiemi di w = 11 sample vector. Inoltre sisono considerate sottosequenze di Nc = 10 eventi precedenti ad ogni clickdel mouse. In Tabella 5.1 sono riportati i valori di accuracy, FPR e FNRper singolo utente. I valori si riferiscono alla media dei valori ottenutinelle 5 ripetizioni per ogni utente.

5.3 Esperimento 2

In questo esperimento si è �ssato il valore di Nc = 10, facendo variareil parametro w. Analizzando le frequenze dei click per ogni utente si èstabilito, approssimativamente, il tempo medio intercorso tra due eventiclick. Tale valore, a seconda degli utenti varia da un minimo di 30 ad unmassimo di 70 secondi. In media un evento click è generato circa ogni50 secondi. Variando il valore della �nestra w, stiamo sostanzialmenteaumentando o diminuendo il tempo di osservazione dell'utente. Con w =11, il valore considerato nel primo esperimento, la macchina SVM cerca diclassi�care insiemi di esempi in input che coprono all'incirca un intervallodi 550 secondi, cioè poco più di 9 minuti. La larghezza della �nestraconsiderata è stata fatta variare da un minimo di 1 ad un massimo di60 eventi. In Tabella 5.2 sono riportati i valori, mediati su tutti gliutenti, di accuracy, FPR e FNR per diversi valori di w. I risultati globalidell'esperimento sono proposti nella Figura 5.2.

5.4 Esperimento 3

In questo esperimento si sono variati sia il parametro Nc ∈ {15, 20, 25, 30}che il parametro w ∈ {1, . . . , 60}. La variazione del parametroNc richiede

Page 54: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 42

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.00

0.05

0.10

0.15

0.20

0.25

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

w

FNR

Figura 5.2: Accuracy, FPR e FNR per Nc = 10

Page 55: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

43 Esperimento 4

w FPR FNR Accuracy Intervallo (min.)11 0.13 0.26 0.77 9.115 0.10 0.21 0.81 12.525 0.08 0.15 0.86 25.045 0.04 0.08 0.92 37.559 0.03 0.07 0.94 49.1

Tabella 5.2: Indici di prestazione per diversi valori di w.

Utente Nc = 15 Nc = 20 Nc = 25 Nc = 30

1 1062 1053 1027 9992 1493 1480 1469 14593 978 962 946 9274 1814 1782 1756 17265 1070 1041 1027 1002

Tabella 5.3: Numero di feature vector per diversi valori di Nc.

di calcolare nuovamente i features vector, dato che si devono consideraresottosequenze di lunghezza Nc. Come fatto in precedenza si sono esclusele sottosequenze di durata maggiore ai 5 secondi, per permettere di elimi-nare sequenze a cavallo di due sessioni di�erenti. L'aumento del numerodi eventi precedenti al click considerati ha fatto si però che un numeromaggiore di sequenze siano state eliminate. Il numero di vettori utili alvariare di Nc è riportato in Tabella 5.3 Si è deciso di utilizzare solo i primi925 vettori di ogni utente, per consentire un confronto delle prestazioni suun numero uguale di feature vector. Nelle Figure 5.3, 5.4, 5.5 e 5.6 sonomostrati gli andamenti di accuracy, FPR e FNR al variare della �nestraw per le 4 diverse scelte di Nc.

5.5 Esperimento 4

Nell'ultimo esperimento si sono valutate le prestazioni variando il nume-ro di features coinvolte nella creazione dei features vector. Ordinando lefeatures per valori decrescenti di mutua informazione con la classe dell'u-tente, è stata eseguita la classi�cazione considerando il primo quarto dellefeatures, poi metà ed in�ne i tre quarti (l'utilizzo dell'intero set di featu-res coincide con l'esperimento 2 descritto in precedenza). In Figura 5.7sono mostrati gli andamenti dell'accuracy al variare della �nestra w per iquattro insiemi di features individuati. Si nota dalla �gura l'incrementodel valore di accuracy al crescere del numero di features utilizzate. Con-siderando il solo primo quarto delle features, cioè il gruppo di 10 featurescon i maggiori valori di autoinformazione, l'accuracy si stabilizza su valori

Page 56: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 44

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.4

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

w

FNR

Figura 5.3: Accuracy, FPR e FNR per Nc = 15

Page 57: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

45 Esperimento 4

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.4

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

0.6

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

w

FNR

Figura 5.4: Accuracy, FPR e FNR per Nc = 20

Page 58: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 46

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

w

FNR

Figura 5.5: Accuracy, FPR e FNR per Nc = 25

Page 59: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

47 Esperimento 4

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.4

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.00

0.10

0.20

0.30

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

w

FNR

Figura 5.6: Accuracy, FPR e FNR per Nc = 30

Page 60: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 48

0 10 20 30 40 50 60

0.5

0.6

0.7

0.8

0.9

w

Accuracy

1/4 features2/4 features3/4 features4/4 features

Figura 5.7: Accuracy per diversi insiemi di features considerati.

Page 61: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

49 Discussione dei risultati

poco superiori al 70%. Includendo anche il secondo gruppo di featuresle prestazioni crescono �no all'80%, mentre includendo il terzo e l'ultimoset si passa su valori del 90-95%.

5.6 Discussione dei risultati

Dagli esperimenti eseguiti emergono alcune caratteristiche del sistema.Nell'esperimento 1 si nota come per valori di w relativamente bassi,

ossia per tempi di monitoraggio dell'utente brevi (w = 11 → 9.1 min.),le prestazioni in termini di accuracy presentino una marcata variabilitàtra i diversi utenti. Inoltre le percentuali di falsi positivi e falsi negativici inducono a ricercare con�gurazioni che consentano di ridurne l'entità.

Nell'esperimento 2 la crescita del parametro w comporta un sensibileaumento delle prestazioni in termini di accuracy ed una corrispondenteriduzione dei valori di FPR e FNR. Come è lecito aspettarsi quindi, la de-cisione sull'identità dell'utente risulta più a�dabile se valutata su periodidi tempo più lunghi. Nell'ambito dell'autenticazione continua questo èpossibile, dato che il tempo non è il fattore critico. É preferibile infattiun sistema che generi alert con un'accuratezza elevata seppur in tempipiù lunghi rispetto ad un sistema che interrompa frequentemente l'utentegenerando alert con una bassa accuratezza.

Nell'esperimento 3 emerge come l'aumento di Nc non sia su�ciente agarantire prestazioni migliori. Pur notando una tendenza dell'accuracyad aumentare con l'incremento del parametro, questa si attesta su valoriinferiori a quelli ottenuti nell'esperimento 2. Inoltre, le percentuali diFPR e FNR mantengono valori troppo elevati e dall'alta variabilità. Al-l'aumento del numero di eventi considerati per ogni sottosequenza deveseguire, quindi, anche un adattamento delle features, che nel nostro casosono state de�nite inizialmente per Nc = 10. Alcune features (come ivalori di velocità e accelerazione degli ultimi 10 punti) se applicate a sot-tosequenze più lunghe non permettono infatti di coprire l'intera sequenza,cosa che avveniva per le sequenze di lunghezza 10.

Nell'esperimento 4 emerge come l'insieme delle features de�nito possaconsiderarsi l'insieme minimo per raggiungere le prestazioni ottenute tra-mite l'approccio seguito. Le prestazioni, in termini di accuracy, risultanoleggermente superiori al 90% anche nel caso in cui si utilizzino i 3/4 dellefeature più signi�cative (con i valori maggiori di mutua informaizone) mai valori massimi si sono ottenuti includendo tutto il set di features.

Page 62: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 50

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.2

0.4

0.6

0.8

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

1.0

w

FNR

Figura 5.8: Accuracy, FPR e FNR ottenute considerando il primo quarto difeatures.

Page 63: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

51 Discussione dei risultati

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

1.0

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

0.8

w

FNR

Figura 5.9: Accuracy, FPR e FNR ottenute considerando la metà dellefeatures.

Page 64: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

5. Valutazione Sperimentale 52

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.4

0.5

0.6

0.7

0.8

0.9

1.0

w

Accuracy

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.1

0.2

0.3

0.4

0.5

w

FPR

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57

0.0

0.2

0.4

0.6

w

FNR

Figura 5.10: Accuracy, FPR e FNR ottenute considerando i tre quarti dellefeatures.

Page 65: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Capitolo 6Conclusioni

In questo lavoro di tesi è stato presentato un sistema di analisi della di-namica del mouse per l'autenticazione continua durante la navigazioneweb. Si può a�ermare che il lavoro di tesi abbia raggiunto, in relazio-ne agli obiettivi iniziali, lo scopo che ci si era posti. Si è realizzato unmetodo di analisi dei dati potenzialmente applicabile in sistemi di con-tinuous login. A livello assoluto va però sottolineato come i risultati,seppur incoraggianti, siano relativi a un ristretto numero di utenti. Leprestazioni del sistema potrebbero, al crescere del bacino di utenza, su-bire un sensibile decadimento. Questo perché, se la selezione di featuresutilizzate sembra essere su�cientemente e�cace nel caratterizzare il com-portamento di 5 utenti, potrebbe però non essere abbastanza adeguatanel caso di un numero maggiore di soggetti interessati. Con l'utilizzodi GWT-Observer si è potuto contare su uno strumento di raccolta datiremoto e non invasivo e potenzialmente adattabile per raccolte dati didimensioni maggiori. Sviluppi futuri si possono concentrare quindi sul-l'aumento delle dimensioni del dataset in termini di utenti, con�gurandoad esempio l'applicativo GWT-Observer per la raccolta dati su larga sca-la e valutando quindi se l'approccio seguito in questo lavoro di tesi risultiancora e�cace. Se così non fosse si dovrà rivedere l'insieme delle featureso variare l'approccio di analisi dei dati. Concentrandosi sull'ampliamentodel dataset, inoltre, si può mirare a fornire alla comunità scienti�ca unodei primi dataset pubblici per questo tipo di ricerche, ponendo le basiper un confronto oggettivo delle metodiche di continuous login tramitedinamica del mouse.

Le varie fasi descritte in questo documento sono state a�rontate nel-l'arco di tempo di circa 4 mesi, incluso un periodo di apprendimento delletecnologie utilizzate. A titolo personale, il candidato si ritiene soddisfat-to dell'esperienza compiuta per diversi motivi: lo stretto contatto con la

53

Page 66: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

6. Conclusioni 54

realtà del laboratorio e i suoi membri, impegnati in ambito di ricerca, gliha dato modo di rendersi conto delle dinamiche, delle tempistiche e anchedelle problematiche che si possono incontrare in questo settore, nonchédel grado di innovazione che caratterizzano gli svariati ambiti di ricercanell'area di studio del Machine Learning.

Page 67: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Appendice ASturmenti Software

A.1 Strumenti software

Si citano qui le principali tecnologie utilizzate durante il lavoro descritto.

A.1.1 L'ambiente R

R è un ambiente di sviluppo dedicato all'analisi statistica dei dati. Il soft-ware è libero e distribuito con licenza GNU-GPL1. La sua di�usione, oltreal vantaggio di essere gratuito, è dovuta anche alla grande disponibilitàdi moduli distribuiti sotto licenza GPL che coprono un ampia gamma disettori e permettono di estendere notevolmente le capacità del program-ma. Nell'ambito del Machine Learning diversi pacchetti permettono diusufruire di funzioni già sviluppate, come l'implementazione di SVM nelnostro caso. Il software è fornito con un'interfaccia a riga di comandoma sono disponibili diversi ambienti gra�ci come RStudio2, un IDE chefacilita la gestione dei progetti e dei moduli installati. In questo lavorodi tesi si è utilizzato R nella versione 3.0.1 e l'IDE RStudio nella versione0.97. Tutta la fase di analisi dei dati, fatta salva la selezione iniziale delleinformazioni dai �le XML, è stata compiuta grazie a questa tecnologia.

A.1.2 NetBeans IDE

Un altro strumento utilizzato è stato l'IDE NetBeans nella sua versione7.3 liberamente scaricabile dal sito dedicato3. Lo si è sfruttato per im-plementare l'applicativo java, descritto nella sezione 4.1, per la selezionedelle informazioni dai �le XML utili alla creazione del dataset �nale.

1http://it.wikipedia.org/wiki/GNU_GPL2http://www.rstudio.com3https://netbeans.org

55

Page 68: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse
Page 69: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Bibliogra�a e siti web

consultati

[1] 450,000 Yahoo passwords just got hacked. http://news.yahoo.com/450-000-yahoo-passwords-just-got-hacked-might-155505616.html

[2] O�cial MSI Taiwan Hacked 50,000 Accounts & Other Dataleaked, Sites Defaced. http://www.cyberwarnews.info/2013/05/04/o�cial-msi-taiwan-hacked-50000-accounts-other-data-leaked-sites-defaced/

[3] Twitter: hackers may have stolen passwords of 250,000users. http://www.telegraph.co.uk/technology/twitter/9843864/Twitter-hackers-may-have-stolen-passwords-of-250000-users.html

[4] Ubuntu forum defaced, breached by hackers. http://www.pcworld.com/article/2044881/ubuntu-forum-defaced-breached-by-hackers.html

[5] Hacker cracks Vodafone Germany, steals data of 2 mil-lion customers. http://www.theregister.co.uk/2013/09/12/vodafone_germany_breach/

[6] C. Shen, Z. Cai,X. Guan, Y. Du, R. A. Maxion. User Authentica-tion Through Mouse Dynamics. In IEEE Transaction on InformationForensics and Security, vol. 8, No. 1, January 2013.

[7] M. Frank, R. Biedert, E. Ma, I. Martinovic, D. Song. Touchalytics:On the Applicability of Touchscreen Input as a Behavioral Biometricfor Continuous Authentication. In IEEE Transaction on InformationForensics and Security, vol. 8, No. 1, January 2013.

[8] Z. Jorgensen, T. Yu. On Mouse Dynamics as a Behavioral Biome-tric for Authentication. In Proceedings of the 6th International Sym-posium on Information, Computer and Communications Security,ASIACCS 2011.

57

Page 70: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

BIBLIOGRAFIA E SITI WEB CONSULTATI58

[9] B. Sayed, I. Traoré, I. Woungang, M. S. Obaidat. Biometric Authen-tication Using Mouse Gesture Dynamics. In IEEE Systems Journal,vol. 7, No. 2, June 2013.

[10] C. Shen, Z. Cai,X. Guan. Continuous Authentication for Mouse Dy-namics: A Pattern-Growth Approach. In Proceedings of the 201242nd Annual IEEE/IFIP International Conference on DependableSystems and Networks (DSN).

[11] A. A. E. Ahmed, I. Traoré. A New Biometric Technology Based onMouse Dynamics. In IEEE Transactions on Dependable and SecureComputing, vol. 4, No. 3, July-September 2007.

[12] W3C. Same Origin Policy. http://www.w3.org/Security/wiki/Same_Origin_Policy

[13] Squid Cache Wiki. Dynamic SSL Certi�cate Generation. http://wiki.squid-cache.org/Features/DynamicSslCert.

Page 71: Autenticazione Continua Durante la Navigazione Web Basata sulla Dinamica del Mouse

Ringraziamenti

Prima di tutti voglio ringraziare papà Oscar, mamma Valdina e fratelloAndrea, solidi esempi di onestà ed umiltà. Il raggiungimento di questoobiettivo è anche merito loro, che mi hanno sempre dato tutto ciò di cuiavessi bisogno.

Grazie a Monica per la costante e amorevole presenza, per avermiincoraggiato e accompagnato in questi ultimi anni a volte di�cili.Grazie anche per aver imparato col tempo che la bellezza va contemplata(ed essa include anche le pubblicità di lingerie).

Ringrazio sentitamente il prof. Alberto Bartoli, per noi studenti �Dio�.Grazie per l'indiscussa professionalità dimostrata in questi anni e per lapuntuale presenza. Unico toscano, che io abbia conosciuto, che provi anascondere il suo accento. Ricordarsi di contattarlo solo dopo una vitto-ria (al più un pareggio) del Milan.

Ringrazio Eric, correlatore stilisticamente ineccepibile e presente, so-prattutto perché fornisce agli studenti un benaugurate esempio universi-tario: un (bravo) professore italiano può avere meno di 40 anni, indossarefelpe di Bart Simpson ed essere campione mondiale di citazioni dei �lmdi Fantozzi. Insomma: �come è umano lei!�.

Un grosso grazie ad Andrea (MaLe Lab) per il prezioso e costante sup-porto, le spiegazioni tecniche e anche i momenti divertenti (gli occhiettiminuscoli delle 8 di mattina resteranno scolpiti nella memoria).Ringrazio inoltre l'ego di Andrea che ci ha sempre tenuto compagnia.Ringrazio anche l'ego dell'ego di Andrea che ogni tanto ha fatto capolino.

Un grazie a tutti gli amici e ai compagni di corso (in ordine sparso)Matteo, Francesco, Giulio, Martina, Silvia, Davide, Marta, Paolo, [...],con cui ho condiviso gioie e dolori di questi anni da studente. Fate partedel lato positivo dell'università.

59