Uno Studio Empirico sui Consumi Energetici in Ambiente Android
Upcoming SlideShare
Loading in...5
×
 

Uno Studio Empirico sui Consumi Energetici in Ambiente Android

on

  • 126 views

 

Statistics

Views

Total Views
126
Views on SlideShare
126
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Uno Studio Empirico sui Consumi Energetici in Ambiente Android Uno Studio Empirico sui Consumi Energetici in Ambiente Android Document Transcript

    • TESI IN SICUREZZA - LUGLIO 2013 1 Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza Giuseppe De Rosa, Marco Fazzone, Sabato Napolitano, Michele Tufano ` Universita degli Studi di Salerno, 84084 Fisciano (SA), Italia {g.derosa30, m.fazzone, s.napolitano16, m.tufano10}@studenti.unisa.it Sommario—Viene presentato uno studio di analisi dei consumi energetici su dispositivi mobili Android. Sono stati misurati i consumi energetici delle varie tecnologie web messe a disposizione da HTML5 e Javascript. I risultati di tali misurazioni sono stati ottenuti attraverso dei test eseguiti con l’ausilio della suite di Energy-Testing BatteryBench realizzata a tale scopo. I test hanno evidenziato quali tecnologie risultano essere maggiormente dispendiose in termini ` di consumo energetico. Quest’ultime sono state utilizzate per analizzare la possibilita di attuare un attacco di Denial of Service energetico altres` chiamato Battery Drain. ı Index Terms—Android, Sicurezza, Consumi, Energia, Batteria, Test, Web, HTML5, Codec. ! 1 I NTRODUZIONE O GNI giorno 1,3 milioni di nuovi dispositivi Android, tra tablet e smartphone, vengono attivati. La base di installazioni conta 480 milioni di dispositivi nel mondo. International Data Corporation (IDC) stima che il solo mercato dei tablet superer` quello dei PC a nel 2015 [1], mentre se si considera l’intero mercato mobile (smartphone + tablet) il sorpasso a ` a discapito dei PC e gi` avvenuto. ` L’utenza si sta spostando sempre piu sul mobile, e con esso, di conseguenza, anche quell’insieme di operazioni che finora erano esclusivamente ad appannaggio dei computer. ` Oggigiorno i sempre piu evoluti dispositivi mobile gestiscono una miriade di informazioni personali ed attivit` , rappresentando per molte a persone strumenti indispensabili nel quotidiano. Browsing internet, social networking, com• Prof. Alfredo De Santis E-mail: ads@dia.unisa.it • Dr. Aniello Castiglione E-mail: castiglione@acm.org • Prof. Ugo Fiore E-mail: ufiore@dia.unisa.it Esame di Sicurezza, Corso di Laurea in Informatica munication e gaming, tra le principali attivit` a svolte con essi. Lo sviluppo hardware di questi dispositivi mostra una crescita esponenziale, supportata dall’ampio bacino d’utenza e da una forte concorrenza tra le case costruttrici. Ogni anno processori, memorie, display e ` altre componenti diventano sempre piu veloci, migliori ed economiche, perlomeno per chi le produce. Vengono offerte maggiore capacit` , a pixel del display e potenza computazionale. La legge di Moore1 a proposito resta ancora valida e la tecnologia dietro gli smartphone ` cresce esponenzialmente. Attualmente piu che ` mai questi ultimi hanno processori piu veloci, ` memorie di massa piu economiche, maggiore RAM e display di alta qualit` . La stessa difa ferenza tra uno smartphone attuale e uno di ` qualche anno fa e enorme. La tecnologia costruttiva delle batterie tuttavia non ha subito lo stesso miglioramento. ` Se da un lato si puo affermare che il processo evolutivo non sia completamente fermo, lo 1. ”Le prestazioni dei processori, e il numero di transistor ad esso relativo, raddoppiano ogni 18 mesi.”[2]
    • TESI IN SICUREZZA - LUGLIO 2013 ` stesso procede pero molto lentamente. Il diva` rio e palese se paragonato a quello rapido ed esponenziale che accompagna le restanti componenti, che nel tempo tendono a incrementare le loro prestazioni e a miniaturizzarsi. Rispetto a queste ultime la batteria occupa ancora gran parte della struttura di un telefono. ` Tale fenomeno e dovuto a diversi fattori. Innanzitutto lo sviluppo delle batterie sem` bra realmente procedere piu lentamente rispetto alle altre componenti. Basti pensare che la tecnologia su cui si basano le batterie per dispo` sitivi mobili e, da diversi anni, ancora quella agli ioni di litio, con lievi miglioramenti. ` In secondo luogo, la tendenza odierna e quel` la di fornire dispositivi sempre piu sottili e leggeri. Piuttosto che sfruttare i vantaggi che si avrebbero mantenendo le stesse dimensioni, con una maggiore autonomia, i produttori di ` smartphone forniscono batterie sempre piu sottili in modo da poter ridurre le dimensioni dei loro terminali. Infine, un ruolo influente lo giocano anche ` i software che necessitano di sempre piu potenza, insieme a notifiche push e servizi in background sempre attivi. In questo contesto diviene di fondamentale importanza una gestione oculata dell’energia. La batteria diviene quindi il punto debole dell’infrastruttura dei dispositivi mobili e, pertanto, forte candidato passibile di attacco. In questo lavoro si indaga su possibili attacchi indotti al fine di ottenere un consumo energetico anomalo della batteria di dispositivi mobili Android. ` La scelta di questa piattaforma e dovuta al miglior trend di espansione rispetto agli altri S.O. mobile e alla maggior facilit` di misuraa zione e analisi grazie alle API native e al codice aperto del sistema Android. ` Il lavoro svolto e stato articolato in diverse ` fasi. Si e partiti da un prima fase di spe` rimentazione nella quale e stato osservato il consumo energetico dei codec audio/video te` stati singolarmente in ambiente controllato. Piu precisamente i test eseguiti hanno riguardato la riproduzione di file video e audio di durata ` variabile. Dall’analisi dei risultati e emerso che ` i codec piu dispendiosi in termini energetici sono H264 per i file video e Wave per i file audio. 2 Tali codec sono stati utilizzati nell’ultima fase ` della sperimentazione in cui e stata realizzata una pagina web malevola con l’impiego delle ` piu recenti tecnologie web messe a disposizione da HTML5, Ajax e Javascript. Confrontando il consumo energetico della pagina realizzata con i normali siti web di comune utilizzo si ` e riuscito ad ottenere un consumo energetico pari ad 11 volte il consumo delle stesse pagine in HTML. Di seguito vengono illustrati i capitoli attraverso i quali si articoler` questo documento: Il a capitolo 2 illustra lo stato dell’arte nell’ambito in cui il nostro lavoro si vuole inserire. Nel capitolo 3 viene introdotto l’attacco di sicurezza realizzato. Il capitolo 4 descrive la sperimentazione effettuata in termini di misurazioni energetiche e realizzazione dell’attacco di sicurezza. 2 S TATO DELL’A RTE In letteratura, molti articoli scientifici trattano dei consumi energetici in ambiente Android. La maggior parte di essi si focalizzano sulla misurazione dei consumi dei singoli moduli hardware che formano l’infrastruttura degli smartphone. Il lavoro ”An Analysis of Power Consumption in a smartphone”[3] offre un’analisi approfondita dell’utilizzo energetico delle varie componenti hardware. In questo studio vengono mostrati i risultati di misurazioni fisiche effettuate tramite sensori di resistori posizionati sui circuiti degli smartphone. ` Un altro lavoro importante e rappresentato da: ”Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for smartphones” [4]. Quest’ultimo si differenzia dal precedente per la metodologia di misurazione che, in questo caso, avviene anche via software e non solo in maniera fisica. In questo lavoro viene descritto PowerTutor: un tool che offre la stima in tempo reale del consumo energetico dei vari componenti hardware del dispositivo Android. Questa stima viene fatta sulla base di un modello di scarica ottenuto come descritto nel capitolo 7 di [4]. ` Il modello di scarica e una funzione che, in base al livello attuale di carica della batteria e i
    • TESI IN SICUREZZA - LUGLIO 2013 livelli di utilizzo dei singoli componenti hardware del dispositivo (ottenuti attraverso API Android), restituisce una stima del consumo energetico in tempo reale. Tale modello viene generato con la tecnica PowerBooter che prevede i seguenti passi: 1) Ottenere la curva di scarica della batteria (Figura 1). Il voltaggio della batteria viene registrato nel tempo fino all’esaurimento di essa. 2) Determinare il consumo di ogni componente hardware nei vari stati di utilizzo (es. idle, low, high). Variando lo stato di utilizzo di un componente (lasciando gli altri invariati) viene registrata a distanza di un minuto, per quindici minuti, il voltaggio della batteria. 3) Si effettua una regressione per derivare il modello di scarica. Tramite il dataset ottenuto, utilizzando la tecnica di bootstrap [10], viene generato il modello di scarica. ` Il modello cos` ottenuto e stato validato conı frontando i dati misurati fisicamente attraverso un power meter con quelli stimati utilizzando il modello precedentemente generato (come descritto nel capitolo 6 di [4]). 3 total) e un tipo di rilevazione (current power, average power, energy usage). Ogni volta che il profiling viene disattivato, tutti dati vengono resettati. In questo modo le sessioni di profiling restano indipendenti. In dettaglio, tramite l’utilizzo delle API standard di Android (android.media.AudioManager, android.net.wifi.WifiManager, android.hardware.SensorManager, etc.) viene monitorato lo stato dei singoli moduli hardware. Coi dati rilevati viene stimato il consumo energetico dei componenti attraverso interpolazione sulla base del modello precedentemente generato. Figura 1: Curva di scarica della batteria rappresentata in un grafico Voltaggio/stato di scarica. PowerTutor offre un servizio di profiling energetico (Figure 2, 3 e 4), mostrando le informazioni dei consumi della batteria, sia per i singoli moduli presenti nello smartphone, sia per le singole applicazioni in esecuzione sul dispositivo. E’ possibile diversificare il tipo di profiling settando un intervallo di tempo (last minute, last hour, last day, Figura 2: Schermata del profiling di PowerTutor. Questa schermata mostra i grafici dei consumi per ogni singolo componente. ` E doveroso segnalare, inoltre, il lavoro di Battery Exhaustion Attack Detection with Small
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 3: Schermata del profiling di PowerTutor. Questa schermata mostra il consumo energetico totale per ogni ` singola applicazione ed e stata ottenuta settando l’intervallo di tempo a total e il tipo di rilevazione a energy usage. Handheld Mobile Computers [8] in cui, attraverso algoritmi e moduli di comunicazione Wi-Fi e Bluetooth, si realizzano Battery Drain Attacks, ovvero attacchi di sicurezza che mirino ad ottenere un denial of service attraverso l’esaurimento delle risorse energetiche dei dispositivi mobili. Infine, per l’analisi dei codec audio/video, in Video network traffic and quality comparison of VP8 and H.264 SVC [7] viene fatto uno studio di confronto sulla qualit` , data rate e la velocit` a a di encoding. In questo articolo, viene condotto un lavoro di analisi del consumo energetico dei codec multimediali che, a differenza di quanto fatto 4 Figura 4: Schermata del profiling di PowerTutor. Per una singola applicazione vengono mostrati i consumi energetici dei componenti hardware utilizzati. nel lavoro di Seeling[7], si concentra sui consumi energetici dei codec anzich´ sui fattori di e data rate, qualit` etc. Prendendo spunto dal a lavoro di Buennemeyer[8], anche nel nostro studio viene interpretato il consumo di batteria come una possibile vulnerabilit` per i sistemi a mobili, ma, allo stesso tempo ci distinguiamo da esso perch´ utilizziamo i codec supportati e da Android ed HTML5, per eseguire l’attacco di Battery Drain. 3 ATTACCO DI SICUREZZA L’attacco di sicurezza progettato, si basa sull’idea di sfruttare al massimo il consumo energetico dei codec audio/video analizzati, uti` lizzando quelli che sono risultati piu energy
    • TESI IN SICUREZZA - LUGLIO 2013 inefficient, al fine di ottenere un Battery Drain. Inoltre, in combinazione all’utilizzo dei contenuti multimediali, abbiamo previsto l’utilizzo di funzionalit` che mirassero a sfruttare a pieno a tutte le risorse disponibili, includendo funzioni di: lettura/scrittura di file in memoria, chiamate AJAX e caricamento di font non presenti nel dispositivo. ` La tipologia di attacco e stata scelta pensando all’utilizzo da parte dell’utente medio di un dispositivo mobile escludendo, quindi, l’idea di poter installare sui dispositivi applicazioni di terze parti e puntando ad eseguire l’attacco attraverso una pagina web. La scelta di utilizzare il web per condurre ` l’attacco di Battery Drain e stata presa in base ` alla semplicit` con cui l’utente puo accedervi, a considerando la possibilit` di poter navigare a senza l’installazione di alcun software aggiuntivo. Durante la progettazione dell’attacco, ci siamo posti il vincolo che l’utente non debba ` accorgersi che l’attacco e in corso. Questa scelta ha implicato diverse difficolt` nella realizzazioa ne e nelle scelte implementative del sito web malevolo, attraverso il quale condurre l’attacco. ` L’attacco e stato realizzato utilizzando strumenti relativi alle tecnologie di sviluppo HTML5, Javascript, AJAX e php, le quali vengono utilizzate al fine di realizzare uno script malevolo, inserito in quella che all’utente appare come una normale pagina web, che esegue tutte le funzionalit` piu costose in termini enera ` getici e di computazione, senza dare all’utente la possibilit` di distinguere la nostra pagina da a un’altra priva di codice malevolo. 4 S PERIMENTAZIONE ` L’attacco e stato pianificato sulla base dei risultati ottenuti in fase di sperimentazione, nella quale abbiamo osservato il consumo energetico dei vari codec audio/video, testati singolarmente in ambiente controllato. ` La sperimentazione, dunque, si e svolta in ` 3 step principali: inizialmente e stato preparato un ambiente di test controllato in modo da automatizzare il testing dei consumi energetici, successivamente sono stati eseguiti tali test sui diversi codec multimediali compatibili con HTML5, infine, dall’analisi dei risultati ` precedenti e stato creato il sito malevolo. 5 4.1 Creazione ambiente di test Il successo del nostro studio si basava sull’ottenere misurazioni affidabili dei consumi energetici in modo da poter effettuare le migliori scelte per l’attacco di sicurezza. A tal fine si ` e reso necessario creare un ambiente di test controllato che automatizzasse il testing dei consumi in modo che i risultati non fossero, quindi, influenzati da errori e rumore umano. Abbiamo creato BatteryBench, applicazione Android che effettua benchmark energetici e automatizza le seguenti tipologie di test: • • • Video Audio Stress ` L’applicazione e divisa in 3 omonime sezioni, in cui ognuna predispone la scelta dei possibili test da effettuare per la categoria scelta. Nella ` sezione Video (Figura 6) e possibile effettuare i test energetici sulla riproduzione dei contenuti ` video e dei relativi codec. Si puo selezionare il codec da testare, la durata del test in minuti, e l’opzione che abilita/disabilita l’audio del video. In modo analogo per quanto riguarda la sezione Audio (Figura 5), dedicata ai test sui consumi della riproduzione di file audio, ` e possibile scegliere il codec e la durata in minuti del test. Infine la sezione Stress (Fi` gura 7) e dedicata al testing di una serie di script malevoli. Tale sezione viene definita in questo modo poich´ gli script in questione e tentano di esaurire le risorse energetiche del dispositivo mobile stressandone il consumo. Di seguito vengono riportati gli script di stress (che verranno dettagliati nella sezione 4.4): • • • • HTML5 Web Storage: ripetute scritture/cancellazioni di file in local storage. Ajax Stress Calls: continue richieste al web con lo scopo di mantenere attivo il modulo Wi-Fi. Fonts Stress Calls: ricerca di fonts unsafe che mirano al consumo della CPU. Hidden Muted Video: esecuzione in background di file video senza che l’utente ne sia consapevole.
    • TESI IN SICUREZZA - LUGLIO 2013 6 scarica della batteria (e quindi non costruito adhoc) migliorato attraverso i log anonimi inviati dagli utenti di PowerTutor che utilizzano lo stes• so dispositivo. Questo ovviamente comporta degli errori di stima del consumo energetico. Tuttavia, data la natura comparativa dei test della nostra sperimentazione, non era impor` E possibile selezionare attraverso apposite tante conoscere precisamente il consumo enerı checkbox le opzioni da attivare e la durata del getico in termini di joule bens` capire quali ` codec e tecnologie fossero piu dispendiosi. test in minuti. In dettaglio, attraverso questa ` sezione e possibile creare uno stress test persoInfine, la licenza libera di PowerTutor, a difnalizzato in base all’esigenze dell’utente e dei ferenza della maggior parte delle altre applidati da raccogliere abilitando o disabilitando cazioni di profiling disponibili closed source, una determinata opzione. ci ha permesso di automatizzare la fase di All’avvio del test di Stress, l’applicazione testing abilitando/disabilitando via codice il comunica tramite una richiesta http al server le profiling. Tale automazione non sarebbe stata opzioni di stress selezionate. Il server include possibile con applicazioni esterne closed sournella pagina web solo gli script php e javascript ce, in quanto avrebbero necessitato di un input relativi alle opzioni selezionate dall’utente, in dell’utente, il quale avrebbe inevitabilmente questo modo la pagina web visualizzata dal compromesso le misurazioni (es. precisione in client conterr` e caricher` esclusivamente le termini di tempo; pressione di tasti a schermo a a opzioni di stress desiderate. che comportano consumo). I risultati dei consumi energetici vengono misurati da PowerTutor, il cui codice con licenza Con riferimento alla figura 8 illustriamo i ` libera e stato inglobato all’interno della no- relativi passi di esecuzione del programma stra applicazione. All’interno di quest’ultima, il BatteryBench: codice di PowerTutor viene richiamato quando 1) Vengono settati i parametri del test necessario, come se fosse una semplice routine. (tipologia di testing, tempo, codec etc.); 2) Viene lanciato il test attraverso l’apposito Nonostante siano disponibili molteplici aptasto; plicazioni per Android che offrono servizi di 3) Viene avviato il profiling di PowerTutor misurazione dei consumi energetici (quali Batsettando l’intervallo di tempo a total e ` teryDoctor o DU Battery Saver), si e scelto di il tipo di rilevazione a energy usage in utilizzare PowerTutor poich´ e risultato l’unico, e ` modo da misurare il consumo energetico tra quelli trovati, che, oltre a fornire valutaziodella sola applicazione browser che verr` a ni dei consumi energetici dettagliati per ogni lanciata successivamente; componente hardware del dispositivo e per 4) Viene avviato il browser predefinito di ogni applicazione in esecuzione, sia stata anche sistema con la pagina web relativa al test comprovata la sua affidabilit` nelle misurazioni a selezionato; attraverso rilevazioni fisiche con strumentazio5) Allo scadere del tempo definito al passo ni adeguate (”Accurate Online Power Estima1, il browser viene chiuso. tion and Automatic Battery Behavior Based Power 6) Viene interrotto il servizio di profiling di Model Generation for smartphones” [4]). PowerTutor 7) Viene mostrata una nuova finestra in cui Nello studio sopracitato vengono validate si possono osservare i risultati del test. le misurazioni solo per alcuni device mobili ` ` Android, tra i quali pero non compare lo smartE da sottolineare che l’avvio del profiling phone utilizzato nella nostra sperimentazione. precedentemente l’apertura del browser non PowerTutor installato sul nostro device (HTC comporta errori di stima in quanto PowerTuIncredible S) utilizza un modello generico di tor, configurato appositamente per il browser, • Hidden Muted Audio: esecuzione in background di file audio senza che l’utente ne sia consapevole. Hidden Infrasound Audio: esecuzione di file audio ad infrasuoni, non percepibili all’orecchio umano.
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 5: Schermata di Battery Bench per il testing dei codec audio. inizier` a misurare da quando il processo del a browser sar` attivo. a 7 Figura 6: Schermata di Battery Bench per il testing dei codec video. • • H.264 WebM Theora (non supportato [5]) • La pagina dei risultati (Figura 4) mostra il consumo del browser rispetto ai singoli moduli presenti nello smartphone. Tali risultati HTML5 Audio possono essere memorizzati in un file di log. • Ogg Vorbis • WAV PCM 4.2 Analisi e monitoraggio dei consumi • MP3 ` In questa fase, e stato monitorato il consumo di • AAC tutti i codec multimediali previsti dallo stan• WebM Vorbis dard HTML5 che fossero, allo stesso tempo, • Ogg Opus supportati dal browser stock di Android: Di conseguenza, i nostri test non comprenHTML5 Video dono il codec Theora.
    • TESI IN SICUREZZA - LUGLIO 2013 8 Figura 7: Schermata di Battery Bench con le varie opzioni per il lancio dello stress-test. 4.2.1 Metodologia di Test I test sono stati eseguiti su uno smartphone Android a nostra disposizione, in particolare HTC Incredible S con Android 2.3, processore Qualcomm Snapdragon 1024MHz, Display 4’ TFT 480*800 pixel. La durata dei singoli test segue questi step incrementali: • • • 5 min 15 min 30 min Il dispositivo viene riavviato ad ogni step e la cache del sistema svuotata per avere, ad ogni test, lo stesso ambiente di partenza. Figura 8: Schema del funzionamento di Battery Bench.
    • TESI IN SICUREZZA - LUGLIO 2013 ` Siccome il consumo della batteria non e uniforme, ma dipende dallo stato di scarica in cui essa si trova [4], tutti i test sono stati eseguiti partendo dallo stato di carica completa della batteria del dispositivo. I test sono stati eseguiti con l’ausilio di BatteryBench. 4.2.2 Test eseguiti I test eseguiti riguardano la riproduzione di files video (con o senza traccia audio) e di files audio di durata variabile (5, 15 e 30 minuti). Precisamente ogni test consiste nella visita di una pagina web contenente una traccia video o audio codificata con uno dei codec elencati precedentemente. I test riguardanti i video contenenti traccia audio avranno le seguenti combinazioni di codec audio/video e formato: • mp4: H.264/MPEG4 (AAC LC) • WebM: VP8/Vorbis Di seguito vengono elencati i test eseguiti: HTML5 Video con traccia audio • mp4: H.264/MPEG4 (AAC LC) • WebM: VP8/Vorbis HTML5 Video con traccia audio muta • mp4: H.264/MPEG4 • WebM: VP8/Vorbis HTML5 Audio • Ogg Vorbis • WAV PCM • MP3 • AAC • WebM Vorbis Nella Tabella 21 vengono mostrati i test video eseguiti con le varie combinazioni di tempo, volume e codec. Analogamente, nella Tabella 2 vengono mostrati i test audio eseguiti per i diversi codec e step di tempo. 4.2.3 Risultati Di seguito vengono riportati i grafici dei risultati dei test sui codec audio per gli step da 5, 15, 30 minuti (rispettivamente Figure 15, 16 e 17) e sui codec video per gli stessi step di tempo 9 TestID 1 2 3 4 5 6 7 8 9 10 11 12 Codec H264 H264 H264 H264 H264 H264 WebM WebM WebM WebM WebM WebM Volume Max Max Max Min Min Min Max Max Max Min Min Min Time 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes Tabella 1: Test Video TestID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Codec MP3 MP3 MP3 Wave Wave Wave Opus Opus Opus Vorbis Vorbis Vorbis AAC AAC AAC WebM WebM WebM Time 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes 30 Minutes 15 Minutes 5 Minutes Tabella 2: Test Audio previsti da 5, 15, 30 minuti (rispettivamente Figure 19, 20 e 21). Sono stati, inoltre, ricavati i relativi diagrammi di Pareto (Figure 18 e 22) in modo da ottenere un’informazione ` quanto piu dettagliata possibile circa la percentuale di consumo energetico prodotto da ciascun modulo hardware. ` Video: Durante la sperimentazione e emerso un consumo costantemente in crescita del codec H264 nei singoli step da 5, 15, 30 minuti. Il gap energetico tra H264 ed il codec di comparazione WebM rimane costante per ogni step, aumentando in maniera funzionale rispetto al tempo di test. Inoltre, il trend energetico descritto in prece` denza, e stato registrato anche per i test effettuati sui medesimi codec e tempi, con traccia audio muta, in particolare, si osserva come il
    • TESI IN SICUREZZA - LUGLIO 2013 volume dell’audio influisca in minima parte nel consumo energetico del modulo audio, cos` ı come riportato anche nello studio [4]. ` ` Dai test e risultato che il modulo piu dispen` dioso in termini energetici e quello LCD, che singolarmente costituisce il 53% del consumo totale. La somma dei moduli LCD, Audio, CPU risulta essere il 92% dell’intero dispendio energetico prodotto, lasciando al modulo Wi-Fi il dispendio minore con il solo 8%. Audio: Per quanto riguarda i test eseguiti sui ` codec audio, non e emersa una situazione del tutto definita, poich´ i consumi energetici di e alcuni codec sono risultati piuttosto variabili ` nei singoli step da 5, 15, 30 minuti. Tuttavia si e notato un consumo medio maggiore del codec Wave, soprattutto nei tempi brevi, come risulta dai relativi grafici riportati in appendice A. Analizzando il consumo medio dei singoli moduli abbiamo notato che la componente Audio insieme al modulo CPU costituiscono l’80% circa del consumo energetico totale, mentre il modulo Wi-Fi assorbe il 20% dell’energia utilizzata per compiere la riproduzione audio. ` Per i test audio non e stato preso in considerazione il modulo LCD, non essendo ovviamente rilevante nel confronto. 4.2.4 Overhead comunicazione con il Server Al termine di questa prima fase di test, abbiamo cercato di quantificare l’impatto della comunicazione con il server in termini di consumo energetico. L’obiettivo era quello di confrontare i diversi codec multimediali senza l’overhead della comunicazione e scambio dati tra il client e il server. In altre parole, si voleva scoprire se un codec intrinsecamente energy efficient in termini di riproduzione e codifica, veniva penalizzato nei test energetici a causa della dimensione del file e quindi del trasferimento dati. Ovviamente una semplice esclusione del consumo del modulo Wi-Fi non rappresenta, a nostro parere, una strategia affidabile in termini assoluti. La strategia che volevamo adottare era quella di trasferire un file multimediale di piccole dimensioni e ripeterlo in loop per l’intera durata del test. ` Non e stato tuttavia possibile portare avanti tale tecnica, date le politiche di risparmio ener- 10 getico adottate dal browser stock di Android. Quest’ultimo ignora la funzionalit` associata al a tag loop [9] previsto dallo standard HTML5, che permette la riproduzione in loop di un contenuto multimediale. Per aggirare il problema abbiamo provato ad utilizzare le funzionalit` di Javascript per a simulare un loop. Nello specifico abbiamo provato a richiamare la funzione play sull’elemento multimediale ogni volta che la riproduzione ` terminava. Tale tecnica e stata dapprima testata su un browser per PC, con esito positivo, ma ` lo stesso non si e riscontrato sul browser stock di Android. In conclusione, non abbiamo potuto annullare l’overhead di comunicazione come pianificato, ma abbiamo dovuto cercare un modo alternativo per avere un termine di paragone nei consumi dei contenuti audio/video. Per eseguire i test sui contenuti multimediali annullando l’overhead della comunicazione in rete abbiamo effettuato le stesse misurazioni eseguite precedentemente, ma questa volta utilizzando il player multimediale di Android per riprodurre gli audio/video. 4.3 Testing locale Come descritto in precedenza, volevamo avere dei termini di confronto sui consumi energetici dei codec multimediali annullando il consumo e l’overhead del modulo Wi-Fi, che influisce pesantemente sui consumi per il trasferimento di file molto grandi e poco adatti allo streaming (es. Wave). Visto il fallimento di tutti gli altri tentativi di riprodurre i file multimediali all’interno del browser, in ambiente locale, abbiamo provato ad effettuare le nostre misurazioni utilizzando il player multimediale stock di Android per riprodurre i suddetti file.
    • TESI IN SICUREZZA - LUGLIO 2013 TestID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Type Video Video Video Video Video Video Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Audio Codec H264 H264 H264 WebM Wave Wave MP3 MP3 MP3 Wave Wave Wave Vorbis Vorbis Vorbis AAC AAC AAC WebM WebM WebM 11 Time 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes 5 Minutes 15 Minutes 30 Minutes Tabella 3: Test eseguiti utilizzando il riproduttore multimediale stock di Android. I diversi file sono stati precedentemente memorizzati in memoria locale per annullare l’overhead di comunicazione su rete. La metodologia applicata per il testing in ` locale e stata del tutto simile a quella utilizzata per il testing su rete precedentemente descritto. In particolare, abbiamo testato i file codificati con i codec ritenuti meno efficienti in termini energetici nella precedente fase di testing, ovvero: Wave per i contenuti audio e H264 per quelli video. I file sono stati memorizzati sul supporto di memorizzazione di massa dello stesso dispositivo mobile utilizzato per le altre ` fasi di testing. L’apparecchio e stato riavviato ad ogni iterazione del testing (5min, 15min, 30min) quest’ultimo effettuato sempre con batteria completamente carica. La pianificazione ` dei test locali e stata riportata in Tabella 3, in cui sono descritte le diverse iterazioni del testing. Com’` possibile notare dalla Tabella e ` 3, il codec audio Opus non e presente, dal momento che i riproduttori multimediali di Android non supportano il sudetto codec come riportato nella guida ufficiale per gli svilup` patori [6], quindi non e stato possibile fornire statistiche per i file codificati in Opus. Le misurazioni energetiche, come per i precedenti test, sono state registrate grazie a PowerTutor, il quale veniva avviato appena dopo l’accensione, subito prima dell’esecuzione della riproduzione dei files. I risultati ottenuti ven- gono riportati di seguito sotto forma di grafici, mentre le relative tabelle numeriche vengono descritte all’interno dell’apposita appendice B. In Figura 9, Figura 10 e Figura 11 possiamo osservare il consumo energetico di ogni modulo hardware per i due tipi di codec video. Ogni figura si riferisce ad un determinato step di tempo (5 min, 15 min, 30 min). Allo stesso modo, in Figura 12, vengono mostrati i consumi ( in Joule ) nello step da 5 min. per i diversi tipi di codec audio, per ogni modulo coinvolto nella riproduzione ne viene riportato il dispendio energetico. In Figura 13 e Figura ` 14 e possibile osservare il comportamento degli stessi codec audio per gli step di testing di 15 min (Figura 13) e 30 min (Figura 14). ` Da quanto si puo osservare nei grafici, i test locali, non hanno fatto altro che confermare i risultati osservati precedentemente con i test ` comparativi su rete. Seppur in maniera piu attenuata, per via del minor sforzo di calcolo da parte del componente CPU, il codec H264 vince il confronto con WebM, riconfermandosi ` come codec video piu energeticamente costoso. Per i codec audio, Wave, continua ad essere ` il piu dispendioso in termini energetici, soprattutto per la differenza di consumi del modulo CPU, il quale incide maggiormente nella differenza dei consumi con gli altri codec.
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 9: Risultati dei test locali relativi ai codec video - 5 min. con riferimento alla Tabella 13 Figura 10: Risultati dei test locali relativi ai codec video - 15 min. con riferimento alla Tabella 14 12
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 11: Risultati dei test locali relativi ai codec video - 30 min. con riferimento alla Tabella 15 Figura 12: Risultati dei test locali relativi ai codec audio - 5 min. con riferimento alla Tabella 16 13
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 13: Risultati dei test locali relativi ai codec audio - 15 min. con riferimento alla Tabella 17 Figura 14: Risultati dei test locali relativi ai codec audio - 30 min. con riferimento alla Tabella 18 14
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 15: Risultati Codec Audio - 5 min. con riferimento alla Tabella 7 Figura 16: Risultati Codec Audio - 15 min. con riferimento alla Tabella 8 15
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 17: Risultati Codec Audio - 30 min. con riferimento alla Tabella 9 Figura 18: Diagramma di Pareto riferito ai Codec Audio 16
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 19: Risultati Codec Video - 5 min. con riferimento alla Tabella 10 Figura 20: Risultati Codec Video - 15 min. con riferimento alla Tabella 11 17
    • TESI IN SICUREZZA - LUGLIO 2013 Figura 21: Risultati Codec Video - 30 min. con riferimento alla Tabella 12 Figura 22: Diagramma di Pareto riferito ai Codec Video 18
    • TESI IN SICUREZZA - LUGLIO 2013 4.4 19 Costruzione sito malevolo Grazie ai risultati ottenuti in fase di sperimentazione sui codec audio/video, abbiamo potuto individuare quei codec che fossero meno efficienti in termini di risparmio energetico. Con queste informazioni abbiamo sviluppato una pagina web con scripts malevoli, tali da ` esaurire l’energia del dispositivo nel piu breve tempo possibile. ` La base di partenza e stata una pagina in HTML statico di Wikipedia, all’interno della quale abbiamo nascosto contenuti multimediali e gli scripts malevoli descritti in seguito. 4.4.1 Descrizione sito malevolo In questa sezione sono descritte brevemente le tecnologie utilizzate per realizzare il sito malevolo. • Video e audio nascosti e con volume a zero (Hidden Muted Video e Hidden Muted Audio). I video sono stati inseriti all’interno della pagina, in modo da non dare all’utente la percezione della loro presenza. Per i ` video sono stati nascosti i controlli ed e stato settato il tag di autoplay, impostando l’audio a 0, al fine di renderli invisibili, le dimensioni sono state impostate a 0*0 ` pixel. Per gli audio e stata seguita la stessa logica. • Utilizzo di codec specifici. I codec utilizzati per i contenuti multimediali sono stati scelti in maniera mirata, sulla base dei risultati della sperimentazione e dei con` fronti sui risultati. Abbiamo percio scelto H264 (video) e Wave (audio). • Scrittura e cancellazione continua di dati (HTML5 Web Storage). Utilizzando la funzionalit` di Web Storage fornita da HTML5 a abbiamo inserito uno script che esegue ogni 6 secondi la scrittura e cancellazione all’interno della memoria di un file contenente una stringa di 25Kb. • Chiamate continue con Ajax (Ajax Stress Calls). Per tenere sempre attivo il modulo Wi-Fi con un continuo scambio di dati con il web, abbiamo incluso delle chiamate AJAX ad intervalli regolari di 1 secondo. • Richiesta di diversi font (Fonts Stress Calls). Al fine di stressare ulteriormente • il modulo CPU, abbiamo incluso l’utilizzo all’interno della pagina di fonts considerati unsafe dai browser; ovvero quei fonts non inclusi di default all’interno dei browser. In questo modo, costringiamo il sistema a cercare i fonts da caricare all’interno del dispositivo stesso. Utilizzo di infrasuoni (Infrasound Audio). Per aumentare il consumo di tutti i moduli, abbiamo introdotto, tra i contenuti multimediali, dei file audio codificati con codec Wave che riproducessero una traccia in infrasuoni (2Hz) al massimo del volume digitale. La Tabella 4 mostra i test di stress effettuati. TestID 1 2 3 4 5 6 7 8 9 Stress Option None HTML5 Web Storage Ajax Stress Calls Fonts Stress Calls Hidden Muted Video Hidden Muted Audio Hidden Infrasound Audio All https://www.facebook.com Tabella 4: Test Stress 4.4.2 HTML5 vs HTML4.01 Per la realizzazione del sito malevolo abbiamo utilizzato lo standard HTML5 che ci ha permesso di inserire all’interno della pagina contenuti multimediali in modo semplice ed efficace per nostri fini. HTML5 definisce due nuovi tag, <video> e <audio>, che definiscono lo standard per incorporare un audio o un video in una pagina web. Se avessimo dovuto utilizzare l’ultima versione precedente ad HTML5, ovvero la versione 4.01 dello standard HTML, l’efficacia del sito malevolo sarebbe stata ridotta e alcune componenti impossibili da utilizzare. ` Infatti, in HTML4.01 non e previsto un supporto nativo per video e audio. Per permettere la loro esecuzione, essi necessitano di essere incorporati usando tecnologie che si basano su Adobe Flash o su Apple QuickTime. In riferi` mento alla tecnologia Adobe Flash, essa e stata ormai abbandonata da molti sistemi operativi mobile per motivi di efficienza e di sicurezza.
    • TESI IN SICUREZZA - LUGLIO 2013 20 ` Inoltre non e possibile nascondere video e/o audio. Infine non sarebbe stato possibile utilizzare la tecnologia Web Storage, introdotta appunto con HTML5, la quale consente una memoriz` zazione di dati sul dispositivo client molto piu ` efficace dei cookie, e per tale motivo piu adatta ai nostri scopi. 4.4.3 Risultati I consumi energetici del sito prodotto sono stati testati in maniera molto fine, abilitando un solo tipo di script per volta. I risultati raccolti sono stati organizzati all’interno di un grafico (Figura 23) in cui possiamo notare quale script ` risulta essere il piu energy inefficient. Figura 25: Composizione del circuito. 5 VALIDAZIONE Le misurazioni effettuate durante la fase di sperimentazione sono state validate attraverso Una volta realizzata la pagina web malevola l’uso di un multimetro (mod. DT830 Digital abbiamo condotto uno studio comparativo con Multimeter). Sono stati effettuati due tipi di test: le altre pagine web di utilizzo quotidiano, qua- test di amperaggio e test di voltaggio. li: la stessa pagina di Wikipedia dalla quale siamo partiti per realizzare la pagina male- 5.1 Test di amperaggio vola ed una pagina di Facebook. Registran- Il circuito (Figura 25) e stato realizzato colle` do ed analizzando i consumi, abbiamo potuto gando in serie il multimetro, la batteria e il diconfrontarli (Figura 24). spositivo mobile. L’obiettivo della validazione ` e di verificare, attraverso strumentazione fisica, i risultati presentati da PowerTutor. 4.5 Massive Dynamic Web Attack ` Attraverso il multimetro e stato misurato In seguito ai normali test, abbiamo voluto di- l’amperaggio all’interno del circuito, con il discostarci dai soli obiettivi prefissati di Battery spositivo in funzione e col profiling di PowerDrain Attack, cercando di testare i limiti di Tutor attivo. Sono stati registrati i valori rilevati stress sopportabili da un dispositivo mobile. da PowerTutor (in mW e V) e dal multimetro Abbiamo creato una ulteriore pagina web ma- (in A). Per confrontare i valori ottenuti da Polevola di Dynamic Web Attack, nella quale werTutor con quelli del multimetro, sono stati abbiamo incluso gli script malevoli descritti convertiti mW e V in A applicando la formula: in precedenza e forzato, in maniera dinamimW 1000 ca, l’inserimento dei contenuti multimediali ad A= V intervalli di 1 secondo. Conducendo l’esperimento sul dispositivo sotto testing, abbiamo I risultati sono riassunti in tabella 5. notato che dopo soli 3’ e 10”, si verificava PowerTutor Multimetro Errore Percentuale un overflow in memoria, il browser e tutte 0,171 A 0,180 A 0,009 A 5% le altre applicazioni e servizi in esecuzione in Tabella 5: Risultati test amperaggio background, compreso il servizio di gestione della UI, venivano chiusi da Android stesso Dai risultati si evince che l’errore commesso con la conseguente perdita di dati non salvati ` ed un consumo ulteriore dovuto al riavvio da PowerTutor in termini assoluti e dell’ordine di mA (con uno scarto percentuale del 5%). dell’interfaccia. 4.4.4 Confronto consumi
    • TESI IN SICUREZZA - LUGLIO 2013 21 Figura 23: Confronto tra i consumi (in Joule) dei diversi script malevoli presenti nella pagina di stress test con riferimento alla Tabella 19 5.2 Test di voltaggio Utilizzando gli stessi strumenti utilizzati du` rante il test di amperaggio, e stata modificata la struttura del circuito ponendo in parallelo il multimetro, per misurare il voltaggio. I risultati ottenuti sono riassunti in tabella 6. PowerTutor 3,77 V Multimetro 3,97 V Errore 0,20 V Percentuale 5,3% Tabella 6: Risultati test voltaggio ` Confrontando i risultati si e evinto che il valore di errore, anche in questo caso risulta essere del 5%. 6 C ONCLUSIONI Valutando i risultati ottenuti in fase di testing ` ` e emerso che i codec piu dispendiosi in termini energetici sono risultati essere H264 per i contenuti video e Wave per gli audio. Questi formati sono stati inseriti poi in una normale pagina HTML statica di Wikipedia, in maniera invisibile, insieme ad altri script esposti in precedenza, per creare la pagina web malevola. Confrontando il consumo energetico della pagina da noi realizzata con i normali siti web di comune utilizzo siamo riusciti ad ottenere un consumo energetico pari ad 11 volte il consumo della stessa pagina in HTML e consumi pari al 4.5 volte maggiori rispetto ad una pagina di Facebook. Siamo giunti alla conclusione che at` traverso l’impiego malevolo delle piu semplici e note tecnologie web, si ottengono consumi energetici tali da portare la batteria del dispo` sitivo in uso alla scarica in tempi molto piu brevi. ` Una possibile soluzione che un utente puo utilizzare al fine di evitare attacchi di questo ` genere, puo essere quella di disabilitare l’e` secuzione di codice JavaScript. Cio comporta ovviamente il vantaggio di essere meno vulnerabile ad attacchi che sfruttino le potenzialit` a di questo linguaggio, ma lo svantaggio di non poter usufruire di contenuti dinamici offerti
    • TESI IN SICUREZZA - LUGLIO 2013 22 Figura 24: Confronto dei consumi (in Joule) tra le diverse pagine web con riferimento alla Tabella 20 ormai da numerose pagine web. Se l’utente rilevare e difendere l’utente da eventuali attacriesce ad individuare la pagina web che pro- chi di Denial of Service energetico. Le possibili voca il consumo anomalo della batteria del strategie di difesa potrebbero essere due: proprio dispositivo, si consiglia di contattare • Analisi statica del codice sorgente delle l’amministratore del sito. pagine web prima di essere caricate in modo da individuare il codice malevolo. • Analisi dinamica delle prestazioni e dei consumi della batteria in modo da av7 S VILUPPI F UTURI vertire prontamente l’utente e bloccare ` Il naturale proseguimento di tale studio e rapl’esecuzione del codice. presentato dal continuo aggiornamento dei casi di test, sia per quanto riguarda i nuovi coA PPENDICE A dec multimediali che verranno introdotti, sia per le future tecnologie web che si avranno a R ISULTATI T EST C ODEC A.1 Codec Audio disposizione. Si necessita, inoltre, di incrementare il nuCPU Audio Wi-Fi mero di dispositivi su cui effettuare benchWave 93.40 134.10 94.90 mark. Una possibile soluzione potrebbe esseOpus 58.40 128.20 72.60 Vorbis 49.80 122.80 65.20 re il rilascio dell’applicazione ”Battery Bench” WebM 87.20 117.20 61.70 sullo store Android in modo da ricevere anoMP3 98.80 116.90 69.40 nimamente log di esecuzioni di test da utenti AAC 47.10 118.80 60.40 volontari. Un ulteriore sviluppo potrebbe essere quello Tabella 7: Valori di consumo energetico (espressi in di creare un’applicazione che sia in grado di Joule) ottenuti dal testing dei codec audio per 5 minuti.
    • TESI IN SICUREZZA - LUGLIO 2013 Wave Opus Vorbis WebM MP3 AAC CPU 313.40 264.20 318.90 307.80 289.30 297.70 23 Audio 354.20 338.40 364.80 357.50 313.80 343.80 Wi-Fi 178.80 175.70 185.10 197.10 161.90 178.80 A PPENDICE B R ISULTATI T EST L OCALI Tabella 8: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec audio per 15 minuti. Wave Opus Vorbis WebM MP3 AAC CPU 673.90 675.80 667.70 665.90 689.90 669.40 Audio 693.50 694.60 695.10 689.80 693.10 675.10 CPU 52.40 48.90 LCD 311.40 310.90 Audio 118.30 107.20 Tabella 13: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 5 minuti. Wi-Fi 332.80 324.50 329.10 318.50 247.60 269.30 H264 WebM Tabella 9: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec audio per 30 minuti. A.2 H264 WebM CPU 167.50 154.80 LCD 840.70 835.50 Audio 342.50 317.90 Tabella 14: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 15 minuti. Codec Video H264 WebM H264 vol. 0 WebM vol. 0 CPU 93.20 97.50 87.70 91.50 LCD 289.80 278.50 284.50 273.20 Audio 109.80 90.30 106.40 76.80 Wi-Fi 50.80 66.80 63.10 52.80 H264 WebM CPU 328.80 318.40 LCD 1674.00 1643.00 Audio 692.40 691.80 Tabella 15: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 30 minuti. Tabella 10: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 5 minuti. H264 WebM H264 vol. 0 WebM vol. 0 CPU 305.40 297.60 268.20 270.50 LCD 901.80 825.30 826.50 815.70 Audio 337.10 323.30 332.90 331.40 Wi-Fi 158.60 129.70 126.40 128.20 Tabella 11: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 15 minuti. H264 WebM H264 vol. 0 WebM vol. 0 CPU 653.40 637.70 558.40 548.70 LCD 1785.00 1589.00 1689.10 1654.00 Audio 685.80 665.10 581.00 565.50 Wi-Fi 241.30 191.80 230.50 196.40 Tabella 12: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 30 minuti. MP3 Wave Vorbis AAC WebM CPU 37.10 39.80 32.40 29.40 34.90 Audio 109.90 112.60 111.80 110.50 111.80 Tabella 16: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 5 minuti. MP3 Wave Vorbis AAC WebM CPU 99.50 118.40 112.90 118.10 115.80 Audio 345.60 364.80 353.90 365.10 328.90 Tabella 17: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 15 minuti.
    • TESI IN SICUREZZA - LUGLIO 2013 24 CPU 214.80 235.90 221.90 117.80 221.30 MP3 Wave Vorbis AAC WebM Audio 695.40 701.90 675.10 698.20 687.50 A PPENDICE E C ODICE S ORGENTE Di seguito vengono elencati i file sorgenti utilizzati durante la sperimentazione, disponibili al seguente link: https://www.dropbox.com/ Tabella 18: Valori di consumo energetico (espressi in sh/cxgyl09fzdjoagj/5ShETNttio Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 30 minuti. A PPENDICE C R ISULTATI T EST S ITO M ALEVOLO Infrasounds Audio Video Web Storage Ajax Fonts CPU 54.90 61.20 84.20 113.90 32.50 28.50 Wi-Fi 197.70 186.80 161.80 13.80 34.60 39.40 Audio 117.80 110.60 60.30 0.00 0.00 0.00 Tabella 19: Valori di consumo energetico (espressi in Joule) ottenuti dallo stress test per ogni opzione applicabile. Static HTML Battery Drain Attack facebook.com CPU 25.70 283.80 75.40 Wi-Fi 33.60 228.36 72.70 Audio 0.00 153.90 0.00 Tabella 20: Valori di consumo energetico (espressi in Joule) ottenuti dal confronto delle diverse pagine web prese in esame. A PPENDICE D I NVENTARIO F ILE U TILIZZATI Type Audio Audio Audio Audio Audio Audio Video Video Audio Infrasuono Codec AAC MP3 Ogg Opus Ogg Vorbis Wave WebM H264 WebM Wave Size 28.8 MB 28.9 MB 34.1 MB 28.1 MB 318.3 MB 28.9 MB 43.4 MB 15.4 MB 53.1 MB Tabella 21: File utilizzati audio B a t t e r y T e s t . php stress video . / audio : src TestAudioAac . html TestAudioMP3 . html TestAudioOpus . html TestAudioVorbis . html TestAudioWav . html TestAudioWebM . html . / audio/ s r c : audio . aac audio . m4a audio . mp3 audio . ogg opus . opus audio . ogg vorbis . ogg audio . wav audio . webm ./ s t r e s s : addAudio . php addFonts . php a d d I n f r a . php addObj . php a j a x . php audio audio . php B a t t e r y D r a i n A t t a c k . php doRequest . php f i l l &e r a s e . j s f o n t s . php fonts . txt infra
    • TESI IN SICUREZZA - LUGLIO 2013 i n f r a s o u n d s . php linkAudio . t x t linkInfra . txt link . txt Sicurezza files S i c u r e z z a . html video video . php . / s t r e s s /audio : audio . wav ./ s t r e s s /i n f r a : 1hz . wav . / s t r e s s /video : NoAudio . mp4 . / video : src TestVideoH264 . html TestVideoH264NoAudio . html TestVideoWebM . html TestVideoWebMNoAudio . html . / video/ s r c : NoAudio . mp4 NoAudio . webm video . mp4 video . webm R INGRAZIAMENTI Si ringraziano gli autori di PowerTutor per la licenza libera (GNU General Public License) sotto ` la quale e stata rilasciata la sopracitata applicazione, utilizzata nel nostro studio per il rilevamento dei consumi energetici. 25 R IFERIMENTI BIBLIOGRAFICI [1] Ryan Reith, Tom Mainelli e Michael Shirer ”IDC Forecasts Worldwide Tablet Shipments to Surpass Portable PC Shipments in 2013, Total PC Shipments in 2015” http://www.idc.com/getdoc.jsp?containerId= prUS24129713, 28 Maggio 2013. [2] Legge di Moore http://it.wikipedia.org/wiki/Legge di Moore, 1965. [3] A. Carroll e G. Heiser ”An Analysis of Power Consumption in a smartphone”, In Proceedings of the 2010 USENIX conference on USENIX annual technical conference, pp. 2-12. [4] L. Zhang, B. Tiwana, R. P. Dick, Z. Qian, Z. M. Mao, Z. Wang e L. Yang: ”Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones”, In Proceedings of the 8th IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis 2010, pp. 1-10. [5] Compatibility table for support of the Ogg/Theora video format http://caniuse.com/ogv, 2013. [6] Supported Media Formats http://developer.android.com/ guide/appendix/media-formats.html [7] P. Seeling F. Fitzek, G. Ertli, A. Pulipaka e M. Raisslein: ”Video Network Traffic And Quality Comparison Of VP8 And H264 SVC”, In Proceedings of the 3rd Workshop on Mobile Video Delivery, 2010, pp. 1-5. [8] T.K.Buennemeyer, M. Gora, R. Marchany e J. Tront: ”Battery Exhaustion Attack Detection With Small HandHeld Mobile Computers”, In Proceedings of IEEE International Conference on Portable Information Devices, 2007, pp. 1-5. [9] HTML5 Autoplay, Loop and Muted: table list of which browser support the autoplay, loop and muted attributes http://www.longtailvideo.com/html5/autoloop/. [10] Wikipedia Bootstrapping (statistics) http://en.wikipedia.org/wiki/Bootstrapping (statistics).