Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza

286 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
286
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza

  1. 1. 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 Universit`a 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 realizzare un attacco di Denial of Service energetico altres`ı chiamato Battery Drain. Index Terms—Android, Sicurezza, Consumi, Energia, Batteria, Test, Web, HTML5, Codec. ! 1 INTRODUZIONE OGNI giorno 1,3 milioni di nuovi dispositivi Android, tra tablet e smartphone, vengo- no attivati. La base di installazioni conta 480 milioni di dispositivi nel mondo. International Data Corporation (IDC) stima che il solo mercato dei tablet superer`a quello dei PC nel 2015 [1], mentre se si considera l’intero mer- cato mobile (smartphone + tablet) il sorpasso a discapito dei PC `e gi`a avvenuto. L’utenza si sta spostando sempre pi`u sul mobile, e con esso, di conseguenza, anche quell’insieme di operazioni che finora erano esclusivamente ad appannaggio dei computer. Oggigiorno i sempre pi`u evoluti dispositivi mobile gestiscono una miriade di informazioni personali ed attivit`a, rappresentando per molte persone strumenti indispensabili nel quotidia- no. 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 pi`u 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 pi`u che mai questi ultimi hanno processori pi`u veloci, memorie di massa pi`u economiche, maggiore RAM e display di alta qualit`a. La stessa dif- ferenza tra uno smartphone attuale e uno di qualche anno fa `e enorme. La tecnologia costruttiva delle batterie tut- tavia non ha subito lo stesso miglioramento. Se da un lato si pu`o affermare che il proces- so evolutivo non sia completamente fermo, lo 1. ”Le prestazioni dei processori, e il numero di transistor ad esso relativo, raddoppiano ogni 18 mesi.”[2]
  2. 2. TESI IN SICUREZZA - LUGLIO 2013 2 stesso procede per`o molto lentamente. Il diva- rio `e palese se paragonato a quello rapido ed esponenziale che accompagna le restanti com- ponenti, 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 pi`u lentamente rispet- to 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 pi`u 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 pi`u sot- tili in modo da poter ridurre le dimensioni dei loro terminali. Infine, un ruolo influente lo giocano anche i software che necessitano di sempre pi`u po- tenza, insieme a notifiche push e servizi in background sempre attivi. In questo contesto diviene di fondamenta- le importanza una gestione oculata dell’ener- gia. La batteria diviene quindi il punto debo- le dell’infrastruttura dei dispositivi mobili e, pertanto, forte candidato passibile di attacco. In questo lavoro si indaga su possibili at- tacchi 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`a di misura- 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. Pi`u 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 pi`u dispendiosi in termini energetici so- no H264 per i file video e Wave per i file audio. Tali codec sono stati utilizzati nell’ultima fase della sperimentazione in cui `e stata realizzata una pagina web malevola con l’impiego delle pi`u recenti tecnologie web messe a disposizio- ne 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 attra- verso i quali si articoler`a questo documento: Il 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 sicu- rezza realizzato. Il capitolo 4 descrive la spe- rimentazione effettuata in termini di misura- zioni energetiche e realizzazione dell’attacco di sicurezza. 2 STATO DELL’ARTE 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 modu- li 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 vengo- no mostrati i risultati di misurazioni fisiche ef- fettuate tramite sensori di resistori posizionati sui circuiti degli smartphone. Un altro lavoro importante `e rappresenta- to 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 Power Tutor: un tool che offre una stima in tempo reale del consumo energetico dei vari componenti hardware del dispositivo Android. La stima viene fatta sulla base di un modello di scarica (come descritto nel capitolo del capitolo 7 di [4]). Tale modello viene generato con la tecnica PowerBooter che prevede i seguenti passi:
  3. 3. TESI IN SICUREZZA - LUGLIO 2013 3 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 in- variati) viene registrata a distanza di un minuto, per quindici minuti, il voltaggio della batteria. 3) Si effettua una regressione per derivare il mo- dello 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]). Figura 1: Curva di scarica della batteria rappresentata in un grafico Voltaggio/stato di scarica. PowerTutor offre un servizio di profiling energetico (Figura 3), mostrando le informazioni dei consumi della batteria in tempo reale, sia per i singoli moduli presenti nello smartphone, sia per le singole applicazioni in esecuzione sul dispositivo (Figura 2).In dettaglio, tramite l’utilizzo delle API standard di Android (android.media.AudioManager, android.net.wifi.WifiManager, an- droid.hardware.SensorManager, etc.) viene monitorato lo stato dei singoli moduli hardware. Coi dati rilevati viene calcolato il consumo energetico dei componenti sulla base del modello precedentemente generato attraverso interpolazione. Figura 2: Schermata del profiling di PowerTutor `E doveroso segnalare, inoltre, il lavoro di Battery Exhaustion Attack Detection with Small 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 otte- nere 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`a, data rate e la velocit`a di encoding. In questo articolo, viene condotto un lavoro di analisi del consumo energetico dei codec
  4. 4. TESI IN SICUREZZA - LUGLIO 2013 4 Figura 3: Schermata del profiling di PowerTutor multimediali che, a differenza di quanto fatto nel lavoro di Seeling[7], si concentra sui consu- mi energetici dei codec anzich´e sui fattori di data rate, qualit`a etc. Prendendo spunto dal lavoro di Buennemeyer[8], anche nel nostro studio viene interpretato il consumo di batteria come una possibile vulnerabilit`a per i sistemi mobili, ma, allo stesso tempo ci distinguiamo da esso perch´e utilizziamo i codec supportati da Android ed HTML5, per eseguire l’attacco di Battery Drain. 3 ATTACCO DI SICUREZZA L’attacco di sicurezza progettato, si basa sull’i- dea di sfruttare al massimo il consumo ener- getico dei codec audio/video analizzati, uti- lizzando quelli che sono risultati pi`u energy inefficient, al fine di ottenere un Battery Drain. Inoltre, in combinazione all’utilizzo dei conte- nuti multimediali, abbiamo previsto l’utilizzo di funzionalit`a che mirassero a sfruttare a pieno tutte le risorse disponibili, includendo funzioni di: lettura/scrittura di file in memoria, chiama- te AJAX e caricamento di font non presenti nel dispositivo. La tipologia di attacco `e stata scelta pensan- do 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`a con cui l’utente pu`o accedervi, considerando la possibilit`a di poter navigare senza l’installazione di alcun software aggiun- tivo. 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`a nella realizzazio- ne e nelle scelte implementative del sito web malevolo, attraverso il quale condurre l’attacco. L’attacco `e stato realizzato utilizzando stru- menti relativi alle tecnologie di sviluppo HTML5, Javascript, AJAX e php, le quali ven- gono utilizzate al fine di realizzare uno script malevolo, inserito in quella che all’utente appa- re come una normale pagina web, che esegue tutte le funzionalit`a pi`u costose in termini ener- getici e di computazione, senza dare all’utente la possibilit`a di distinguere la nostra pagina da un’altra priva di codice malevolo. 4 SPERIMENTAZIONE 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 prepa- rato un ambiente di test controllato in modo da automatizzare il testing dei consumi ener- getici, successivamente sono stati eseguiti tali test sui diversi codec multimediali compatibi- li con HTML5, infine, dall’analisi dei risultati precedenti `e stato creato il sito malevolo.
  5. 5. TESI IN SICUREZZA - LUGLIO 2013 5 4.1 Creazione ambiente di test Il successo del nostro studio si basava sull’ot- tenere misurazioni affidabili dei consumi ener- getici 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 5) `e possibile effettuare i test energetici sulla riproduzione dei contenuti video e dei relativi codec. Si pu`o 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 4), 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 (Figura 6) `e dedicata al testing di una serie di script malevoli. Tale sezione viene definita in questo modo poich´e gli script in questione tentano di esaurire le risorse energetiche del dispositivo mobile stressandone il consumo. Di seguito vengono riportati gli script di stress: • HTML5 Web Storage • Ajax Stress Calls • Fonts Stress Calls • Hidden Muted Video • Hidden Muted Audio • Hidden Infrasound Audio `E possibile selezionare attraverso apposite checkbox le opzioni da attivare e la durata del test in minuti. In dettaglio, attraverso questa sezione `e possibile creare uno stress test perso- nalizzato in base all’esigenze dell’utente e dei dati da raccogliere abilitando o disabilitando una determinata opzione. I risultati dei consumi energetici vengono misurati da PowerTutor, il cui codice con licenza libera `e stato inglobato all’interno della no- stra applicazione. All’interno di quest’ultima, il codice di PowerTutor viene richiamato quando necessario, come se fosse una semplice routine. Nonostante siano disponibili molteplici ap- plicazioni per Android che offrono servizi di misurazione dei consumi energetici (quali Bat- teryDoctor o DU Battery Saver), si `e scelto di utilizzare PowerTutor poich´e `e risultato l’unico, tra quelli trovati, che, oltre a fornire valutazio- ni dei consumi energetici dettagliati per ogni componente hardware del dispositivo e per ogni applicazione in esecuzione, sia stata anche comprovata la sua affidabilit`a nelle misurazioni attraverso rilevazioni fisiche con strumentazio- ni adeguate (”Accurate Online Power Estima- tion and Automatic Battery Behavior Based Power Model Generation for smartphones” [4]). Nello studio sopracitato vengono validate le misurazioni solo per alcuni device mobili Android, tra i quali per`o non compare lo smart- phone utilizzato nella nostra sperimentazione. PowerTutor installato sul nostro device (HTC Incredible S) utilizza un modello generico di scarica della batteria (e quindi non costruito ad- hoc) 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- tante conoscere precisamente il consumo ener- getico in termini di joule bens`ı capire quali codec e tecnologie fossero pi`u dispendiosi. Infine, la licenza libera di PowerTutor, a dif- ferenza della maggior parte delle altre appli- cazioni di profiling disponibili closed source, ci ha permesso di automatizzare la fase di testing abilitando/disabilitando via codice il profiling. Tale automazione non sarebbe stata possibile con applicazioni esterne closed sour- ce, in quanto avrebbero necessitato di un input dell’utente, il quale avrebbe inevitabilmente compromesso le misurazioni (es. precisione in
  6. 6. TESI IN SICUREZZA - LUGLIO 2013 6 termini di tempo; pressione di tasti a schermo che comportano consumo). Figura 4: Schermata di Battery Bench per il testing dei codec audio. Con riferimento alla figura 7 illustriamo i relativi passi di esecuzione del programma BatteryBench: 1) Vengono settati i parametri del test (tipologia di testing, tempo, codec etc...); 2) Viene lanciato il test attraverso l’apposito tasto; 3) Viene avviato il profiling di PowerTu- tor configurato in modo da misurare il consumo energetico della sola ap- plicazione browser che verr`a lanciata successivamente; Figura 5: Schermata di Battery Bench per il testing dei codec video. 4) Viene avviato il browser predefinito di sistema con la pagina web relativa al test selezionato; 5) Allo scadere del tempo definito al passo 1, il browser viene chiuso. 6) Viene interrotto il servizio di profiling di PowerTutor 7) Viene mostrata una nuova finestra in cui si possono osservare i risultati del test. `E da sottolineare che l’avvio del profiling precedentemente l’apertura del browser non comporta errori di stima in quanto PowerTu- tor, configurato appositamente per il browser, inizier`a a misurare da quando il processo del browser sar`a attivo.
  7. 7. TESI IN SICUREZZA - LUGLIO 2013 7 Figura 6: Schermata di Battery Bench con le varie opzioni per il lancio dello stress-test. La pagina dei risultati (Figura 8) mostra il consumo del browser rispetto ai singoli mo- duli presenti nello smartphone. Tali risultati possono essere memorizzati in un file di log. 4.2 Analisi e monitoraggio dei consumi In questa fase, `e stato monitorato il consumo di tutti i codec multimediali previsti dallo stan- dard HTML5 che fossero, allo stesso tempo, supportati dal browser stock di Android: HTML5 Video • H.264 • WebM • Theora (non supportato [5]) Figura 7: Schema del funzionamento di Battery Bench.
  8. 8. TESI IN SICUREZZA - LUGLIO 2013 8 HTML5 Audio • Ogg Vorbis • WAV PCM • MP3 • AAC • WebM Vorbis • Ogg Opus Di conseguenza, i nostri test non compren- dono il codec Theora. Figura 8: Schermata dei risultati di Battery Bench ottenuta attraverso PowerTutor. 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. Siccome il consumo della batteria non `e uni- forme, 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 trac- cia 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 19 vengono mostrati i test video eseguiti con le varie combinazioni di tempo, volume e codec. Analogamente, nella Tabella 2 vengono mo- strati i test audio eseguiti per i diversi codec e step di tempo.
  9. 9. TESI IN SICUREZZA - LUGLIO 2013 9 TestID Codec Volume Time 1 H264 Max 30 Minutes 2 H264 Max 15 Minutes 3 H264 Max 5 Minutes 4 H264 Min 30 Minutes 5 H264 Min 15 Minutes 6 H264 Min 5 Minutes 7 WebM Max 30 Minutes 8 WebM Max 15 Minutes 9 WebM Max 5 Minutes 10 WebM Min 30 Minutes 11 WebM Min 15 Minutes 12 WebM Min 5 Minutes Tabella 1: Test Video TestID Codec Time 1 MP3 30 Minutes 2 MP3 15 Minutes 3 MP3 5 Minutes 4 Wave 30 Minutes 5 Wave 15 Minutes 6 Wave 5 Minutes 7 Opus 30 Minutes 8 Opus 15 Minutes 9 Opus 5 Minutes 10 Vorbis 30 Minutes 11 Vorbis 15 Minutes 12 Vorbis 5 Minutes 13 AAC 30 Minutes 14 AAC 15 Minutes 15 AAC 5 Minutes 16 WebM 30 Minutes 17 WebM 15 Minutes 18 WebM 5 Minutes Tabella 2: Test Audio 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 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 pi`u 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 effet- tuati sui medesimi codec e tempi, con traccia audio muta, in particolare, si osserva come il 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 pi`u dispendioso 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´e i consumi energetici di 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 Au- dio 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 considera- zione 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, ab- biamo cercato di quantificare l’impatto del- la 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 effi- cient in termini di riproduzione e codifica, veni- va 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
  10. 10. TESI IN SICUREZZA - LUGLIO 2013 10 nostro parere, una strategia affidabile in termini assoluti. La strategia che volevamo adottare era quella di trasferire un file multimediale di piccole di- mensioni 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- getico adottate dal browser stock di Android. Quest’ultimo ignora la funzionalit`a associata al 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`a di Javascript per simulare un loop. Nello specifico abbiamo pro- vato 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 annul- lare l’overhead di comunicazione come piani- ficato, 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 uti- lizzando 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. TestID Type Codec Time 1 Video H264 5 Minutes 2 Video H264 15 Minutes 3 Video H264 30 Minutes 4 Video WebM 5 Minutes 5 Video Wave 15 Minutes 6 Video Wave 30 Minutes 7 Audio MP3 5 Minutes 8 Audio MP3 15 Minutes 9 Audio MP3 30 Minutes 10 Audio Wave 5 Minutes 11 Audio Wave 15 Minutes 12 Audio Wave 30 Minutes 13 Audio Vorbis 5 Minutes 14 Audio Vorbis 15 Minutes 15 Audio Vorbis 30 Minutes 16 Audio AAC 5 Minutes 17 Audio AAC 15 Minutes 18 Audio AAC 30 Minutes 19 Audio WebM 5 Minutes 20 Audio WebM 15 Minutes 21 Audio WebM 30 Minutes Tabella 3: Test eseguiti utilizzando il riproduttore mul- timediale 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, ov- vero: 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 bat- teria completamente carica. La pianificazione dei test locali `e stata riportata in Tabella 3, in cui sono descritte le diverse iterazioni del testing. Com’`e possibile notare dalla Tabella 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 prece- denti test, sono state registrate grazie a Po- werTutor, il quale veniva avviato appena dopo l’accensione, subito prima dell’esecuzione della riproduzione dei files. I risultati ottenuti ven-
  11. 11. TESI IN SICUREZZA - LUGLIO 2013 11 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 pu`o 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 pi`u 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 pi`u energeticamente costoso. Per i codec audio, Wave, continua ad essere il pi`u 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. 4.4 Costruzione sito malevolo Grazie ai risultati ottenuti in fase di sperimen- tazione sui codec audio/video, abbiamo po- tuto 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 pi`u 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. 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 uti- lizzati per i contenuti multimediali sono stati scelti in maniera mirata, sulla base dei risultati della sperimentazione e dei con- fronti sui risultati. Abbiamo perci`o scelto H264 (video) e Wave (audio). • Scrittura e cancellazione continua di dati. Utilizzando la funzionalit`a di Web Storage fornita da HTML5 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. Per tenere sempre attivo il modulo Wi-Fi con un con- tinuo scambio di dati con il web, abbiamo incluso delle chiamate AJAX ad intervalli regolari di 1 secondo. • Richiesta di diversi font. Al fine di stressa- re 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. Per aumentare il consumo di tutti i moduli, abbiamo in- trodotto, 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. 4.4.2 HTML5 vs HTML4.01 Per la realizzazione del sito malevolo abbiamo utilizzato lo standard HTML5 che ci ha permes- so di inserire all’interno della pagina contenuti multimediali in modo semplice ed efficace per nostri fini. HTML5 definisce due nuovi tag,
  12. 12. TESI IN SICUREZZA - LUGLIO 2013 12 Figura 9: Risultati dei test locali relativi ai codec video - 5 min. con riferimento alla Tabella 11 Figura 10: Risultati dei test locali relativi ai codec video - 15 min. con riferimento alla Tabella 12
  13. 13. TESI IN SICUREZZA - LUGLIO 2013 13 Figura 11: Risultati dei test locali relativi ai codec video - 30 min. con riferimento alla Tabella 13 Figura 12: Risultati dei test locali relativi ai codec audio - 5 min. con riferimento alla Tabella 14
  14. 14. TESI IN SICUREZZA - LUGLIO 2013 14 Figura 13: Risultati dei test locali relativi ai codec audio - 15 min. con riferimento alla Tabella 15 Figura 14: Risultati dei test locali relativi ai codec audio - 30 min. con riferimento alla Tabella 16
  15. 15. TESI IN SICUREZZA - LUGLIO 2013 15 Figura 15: Risultati Codec Audio - 5 min. con riferimento alla Tabella 5 Figura 16: Risultati Codec Audio - 15 min. con riferimento alla Tabella 6
  16. 16. TESI IN SICUREZZA - LUGLIO 2013 16 Figura 17: Risultati Codec Audio - 30 min. con riferimento alla Tabella 7 Figura 18: Diagramma di Pareto riferito ai Codec Audio
  17. 17. TESI IN SICUREZZA - LUGLIO 2013 17 Figura 19: Risultati Codec Video - 5 min. con riferimento alla Tabella 8 Figura 20: Risultati Codec Video - 15 min. con riferimento alla Tabella 9
  18. 18. TESI IN SICUREZZA - LUGLIO 2013 18 Figura 21: Risultati Codec Video - 30 min. con riferimento alla Tabella 10 Figura 22: Diagramma di Pareto riferito ai Codec Video
  19. 19. TESI IN SICUREZZA - LUGLIO 2013 19 TestID Stress Option 1 None 2 HTML5 Web Storage 3 Ajax Stress Calls 4 Fonts Stress Calls 5 Hidden Muted Video 6 Hidden Muted Audio 7 Hidden Infrasound Audio 8 All 9 https://www.facebook.com Tabella 4: Test Stress <video> e <audio>, che definiscono lo standard per incorporare un audio o un video in una pagina web. Se avessimo dovuto utilizzare l’ultima ver- sione precedente ad HTML5, ovvero la versio- ne 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 sup- porto 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. 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 pi`u efficace dei cookie, e per tale motivo pi`u 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 pi`u energy inefficient. 4.4.4 Confronto consumi Una volta realizzata la pagina web malevola abbiamo condotto uno studio comparativo con le altre pagine web di utilizzo quotidiano, qua- li: la stessa pagina di Wikipedia dalla quale siamo partiti per realizzare la pagina male- vola ed una pagina di Facebook. Registran- do ed analizzando i consumi, abbiamo potuto confrontarli (Figura 24). 4.5 Massive Dynamic Web Attack In seguito ai normali test, abbiamo voluto di- scostarci dai soli obiettivi prefissati di Battery Drain Attack, cercando di testare i limiti di stress sopportabili da un dispositivo mobile. Abbiamo creato una ulteriore pagina web ma- levola di Dynamic Web Attack, nella quale abbiamo incluso gli script malevoli descritti in precedenza e forzato, in maniera dinami- ca, l’inserimento dei contenuti multimediali ad intervalli di 1 secondo. Conducendo l’esperi- mento sul dispositivo sotto testing, abbiamo notato che dopo soli 3’ e 10”, si verificava un overflow in memoria, il browser e tutte le altre applicazioni e servizi in esecuzione in background, compreso il servizio di gestione della UI, venivano chiusi da Android stesso con la conseguente perdita di dati non salvati ed un consumo ulteriore dovuto al riavvio dell’interfaccia. 5 CONCLUSIONI Valutando i risultati ottenuti in fase di testing `e emerso che i codec pi`u dispendiosi in ter- mini 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 manie- ra 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 pi`u semplici e note tecnologie web, si ottengono consumi energetici tali da portare la batteria del dispo- sitivo in uso alla scarica in tempi molto pi`u brevi.
  20. 20. TESI IN SICUREZZA - LUGLIO 2013 20 Figura 23: Confronto tra i consumi (in Joule) dei diversi script malevoli presenti nella pagina di stress test con riferimento alla Tabella 17 6 SVILUPPI FUTURI Il naturale proseguimento di tale studio `e rap- presentato dal continuo aggiornamento dei casi di test, sia per quanto riguarda i nuovi co- dec multimediali che verranno introdotti, sia per le future tecnologie web che si avranno a disposizione. Si necessita, inoltre, di incrementare il nu- mero di dispositivi su cui effettuare bench- mark. Una possibile soluzione potrebbe esse- re il rilascio dell’applicazione ”Battery Bench” sullo store Android in modo da ricevere ano- nimamente log di esecuzioni di test da utenti volontari. Validazione dei risultati con misurazioni fisiche sull’hardware. APPENDICE A RISULTATI TEST CODEC A.1 Codec Audio CPU Audio Wi-Fi Wave 93.40 134.10 94.90 Opus 58.40 128.20 72.60 Vorbis 49.80 122.80 65.20 WebM 87.20 117.20 61.70 MP3 98.80 116.90 69.40 AAC 47.10 118.80 60.40 Tabella 5: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec audio per 5 minuti. CPU Audio Wi-Fi Wave 313.40 354.20 178.80 Opus 264.20 338.40 175.70 Vorbis 318.90 364.80 185.10 WebM 307.80 357.50 197.10 MP3 289.30 313.80 161.90 AAC 297.70 343.80 178.80 Tabella 6: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec audio per 15 minuti.
  21. 21. TESI IN SICUREZZA - LUGLIO 2013 21 Figura 24: Confronto dei consumi (in Joule) tra le diverse pagine web con riferimento alla Tabella 18 CPU Audio Wi-Fi Wave 673.90 693.50 332.80 Opus 675.80 694.60 324.50 Vorbis 667.70 695.10 329.10 WebM 665.90 689.80 318.50 MP3 689.90 693.10 247.60 AAC 669.40 675.10 269.30 Tabella 7: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec audio per 30 minuti. A.2 Codec Video CPU LCD Audio Wi-Fi H264 93.20 289.80 109.80 50.80 WebM 97.50 278.50 90.30 66.80 H264 vol. 0 87.70 284.50 106.40 63.10 WebM vol. 0 91.50 273.20 76.80 52.80 Tabella 8: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 5 minuti. CPU LCD Audio Wi-Fi H264 305.40 901.80 337.10 158.60 WebM 297.60 825.30 323.30 129.70 H264 vol. 0 268.20 826.50 332.90 126.40 WebM vol. 0 270.50 815.70 331.40 128.20 Tabella 9: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 15 minuti. CPU LCD Audio Wi-Fi H264 653.40 1785.00 685.80 241.30 WebM 637.70 1589.00 665.10 191.80 H264 vol. 0 558.40 1689.10 581.00 230.50 WebM vol. 0 548.70 1654.00 565.50 196.40 Tabella 10: Valori di consumo energetico (espressi in Joule) ottenuti dal testing dei codec video per 30 minuti.
  22. 22. TESI IN SICUREZZA - LUGLIO 2013 22 APPENDICE B RISULTATI TEST LOCALI CPU LCD Audio H264 52.40 311.40 118.30 WebM 48.90 310.90 107.20 Tabella 11: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 5 minuti. CPU LCD Audio H264 167.50 840.70 342.50 WebM 154.80 835.50 317.90 Tabella 12: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 15 minuti. CPU LCD Audio H264 328.80 1674.00 692.40 WebM 318.40 1643.00 691.80 Tabella 13: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file video per 30 minuti. CPU Audio MP3 37.10 109.90 Wave 39.80 112.60 Vorbis 32.40 111.80 AAC 29.40 110.50 WebM 34.90 111.80 Tabella 14: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 5 minuti. CPU Audio MP3 99.50 345.60 Wave 118.40 364.80 Vorbis 112.90 353.90 AAC 118.10 365.10 WebM 115.80 328.90 Tabella 15: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 15 minuti. CPU Audio MP3 214.80 695.40 Wave 235.90 701.90 Vorbis 221.90 675.10 AAC 117.80 698.20 WebM 221.30 687.50 Tabella 16: Valori di consumo energetico (espressi in Joule) ottenuti dai test di riproduzione in ambiente locale dei file audio per 30 minuti. APPENDICE C RISULTATI TEST SITO MALEVOLO CPU Wi-Fi Audio Infrasounds 54.90 197.70 117.80 Audio 61.20 186.80 110.60 Video 84.20 161.80 60.30 Web Storage 113.90 13.80 0.00 Ajax 32.50 34.60 0.00 Fonts 28.50 39.40 0.00 Tabella 17: Valori di consumo energetico (espressi in Joule) ottenuti dallo stress test per ogni opzione applicabile. CPU Wi-Fi Audio Static HTML 25.70 33.60 0.00 Battery Drain Attack 283.80 228.36 153.90 facebook.com 75.40 72.70 0.00 Tabella 18: Valori di consumo energetico (espressi in Joule) ottenuti dal confronto delle diverse pagine web prese in esame. APPENDICE D INVENTARIO FILE UTILIZZATI Type Codec Size Audio AAC 28.8 MB Audio MP3 28.9 MB Audio Ogg Opus 34.1 MB Audio Ogg Vorbis 28.1 MB Audio Wave 318.3 MB Audio WebM 28.9 MB Video H264 43.4 MB Video WebM 15.4 MB Audio Infrasuono Wave 53.1 MB Tabella 19: File utilizzati
  23. 23. TESI IN SICUREZZA - LUGLIO 2013 23 APPENDICE E CODICE SORGENTE Di seguito vengono elencati i file sorgenti uti- lizzati durante la sperimentazione, disponibili al seguente link: https://www.dropbox.com/ sh/cxgyl09fzdjoagj/5ShETNttio audio BatteryTest . php s t r e s s video ./ audio : src TestAudioAac . html TestAudioMP3 . html TestAudioOpus . html TestAudioVorbis . html TestAudioWav . html TestAudioWebM . html ./ audio/src : 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 addInfra . php addObj . php ajax . php audio audio . php BatteryDrainAttack . php doRequest . php f i l l&erase . j s fonts . php fonts . t x t infra infrasounds . php linkAudio . t x t l i n k I n f r a . t x t link . t x t S i c u r e z z a f i l e s Sicurezza . html video video . php ./ s t r e s s /audio : audio .wav ./ s t r e s s /infra : 1hz .wav ./ s t r e s s /video : NoAudio .mp4 ./ video : src TestVideoH264 . html TestVideoH264NoAudio . html TestVideoWebM . html TestVideoWebMNoAudio . html ./ video/src : NoAudio .mp4 NoAudio .webm video .mp4 video .webm RINGRAZIAMENTI Si ringraziano gli autori di PowerTutor per la licenza libera (GNU General Public License) sotto la quale `e stata rilasciata la sopracitata ap- plicazione, utilizzata nel nostro studio per il rilevamento dei consumi energetici.
  24. 24. TESI IN SICUREZZA - LUGLIO 2013 24 RIFERIMENTI 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).

×