Teknik och samhälle Datavetenskap
Examensarbete 15 högskolepoäng, grundnivå
Bluetooth-enheter i offentliga rummet och anonymisering av
data
Bluetooth devices in the public domain and anonymization of data
Mattias Nilsson
Sebastian Olsson
Examen: Högskoleingenjörsexamen 180 hp Huvudområde: Datavetenskap
Program: Högskoleingenjörsprogram i Data-teknik och Mobil IT
Handledare: Mia Persson Examinator: Ivan Kruzela
Sammanfattning
Internet of Things (IoT) ger stora möjligheter att samla in data för olika syfte som till exempel att estimera antalet personer för att styra värmen i ett rum. Vidare så kan IoT-system automatisera uppgifter som kan hjälpa oss människor. Den här studien syf-tar till vilken typ av data som kan vara intressant att samla in för att kunna estimera antalet personer på en offentlig plats. Det handlar även om hur känslig data som samlas in kan anonymiseras. För att göra detta så valdes det att undersöka hur MAC-adresser från Bluetooth-enheter skulle fungerar för att uppskatta antalet personer. För att samla in MAC-adresser så utvecklades ett proof of concept-system där en Android-applikation sam-lade in MAC-adresser som anonymiserades innan de lagrades i en databas. Applikationen anonymiserar den unika MAC-adressen enligt tre nivåer med olika säkerhet. Fältstudier gjordes där antalet personer räknades visuellt sedan gjordes anonymiserade insamlingar av MAC-adresser. Slutsatsen var att Bluetooth blir svårt att använda för att estimera antal personer eftersom alla inte har Bluetooth på. Applikationen som utvecklats påvisar att data kan samlas in säkert och på så sätt inte kränka integritet.
Abstract
Internet of Things (IoT) provides great opportunities to collect data for different purposes such as to estimate the number of people to control the heat in a room. Furthermore, IoT systems can automate tasks that can help us humans. This study is aimed at the type of data that can be interesting to gather in order to estimate the number of people in a public place. It is also about how sensitive data can be anonymized when gathered. To do this, Bluetooth devices was chosen for investigating how the MAC addresses would work to estimate the number of people. For collecting MAC addresses a proof of concept system was developed, where an Android application was used to collect MAC addresses. These MAC addresses were anonymized before being stored in a database. The application anonymize the unique MAC address according to three levels of security. Field studies were conducted as the number of people were counted visually then anonymous collection of MAC addresses were made. The conclusion was that Bluetooth will be difficult to use for estimating the number of people because not everyone has Bluetooth on. The application developed demonstrates that data can be collected safely and thus does not violate privacy.
Ordlista
ACM – Association for Computing Machinery API – Application Programming Interface BLE – Bluetooth Low Energy
COD – Class of Device
CoSIS – Cooperative, Self-aware and Intelligent Surveillance Systems DAC – Device Access Code
FHS – Frequency Hopping Spectrum
FHSS – Frequency Hopping Spread Spectrum HTTP –Hypertext Transfer Protocol
HTTPS – Hypertext Transfer Protocol Secure IAC – Inquiry Access Code
IEEE – Institute of Electrical and Electronics Engineers ISM – Industry Scientific Medical band
IOPS – Indoor Outdoor Positioning System IoT – Internet of Things
IOTAP – Internet of Things and People LAMP – Linux, Apache, MySQL and PHP MAC – Media Access Control
MD5 – Message Digest 5
MySQL – My Structured Query Language OUI – Organizationally Unique Identifier PHP – PHP Hypertext Preprocessor PuL – Personuppgiftslagen
RSSI – Received Signal Strength Indication SHA – Secure Hash Algorithm
Förord
Vi vill tacka Malmö högskola och IOTAP för deras stöd under examensarbetet. Vi vill även tacka vår handledare Mia Persson samt våra kontaktpersoner inom IOTAP, Ulrik Eklund och Jan Persson. Slutligen vill vi tacka Johan Gustavsson för att vi fick intervjua honom kring etik och integritet.
Innehåll
1 Inledning 1
1.1 Bakgrund . . . 1
1.2 Syfte och problemformulering . . . 1
1.3 Krav . . . 2
1.4 Avgränsningar . . . 2
1.5 Relaterat arbete . . . 2
1.5.1 About the relationship between people and discoverable Bluetooth devices in urban environments . . . 2
1.5.2 An analysis of visitors’ behavior in The Louvre Museum: a study using Bluetooth data . . . 3
1.5.3 IoT Security & Privacy: Threats and Challenges . . . 3
1.5.4 Location Privacy Vulnerable from Bluetooth Devices . . . 3
1.5.5 Anonymity properties of stored or transmitted data taken from Blu-etooth scans . . . 4
1.5.6 Renew London . . . 4
1.5.7 Bumbee Labs . . . 5
1.5.8 BLIP Systems A/S, Integrating BLIP into Location-Aware System: A Service-Oriented Method . . . 5
1.6 Etik och lagar . . . 5
1.7 Disposition . . . 6
2 Metod 7 2.1 Metodval . . . 7
2.2 Litteratursökning . . . 7
2.3 Utveckling av proof of concept . . . 7
2.4 Arbetsmöte . . . 7 2.5 Intervju . . . 8 2.6 Metodöversikt . . . 8 3 Teknisk bakgrund 9 3.1 Bluetooth . . . 9 3.1.1 Klassisk Bluetooth . . . 9 3.1.2 MAC-adress . . . 9 3.1.3 Uppkoppling . . . 10 3.1.4 BLE . . . 11 3.2 Android . . . 11 3.3 Hashfunktion . . . 12 3.4 Kryptering . . . 12 3.5 MySQL . . . 12 3.6 PHP . . . 13 3.7 Linux . . . 13 3.8 Raspberry Pi . . . 13 4 Resultat 14 4.1 Proof of concept . . . 14 4.1.1 Utvecklingsmiljö . . . 14 4.1.2 Android-applikation . . . 14 4.1.3 Databas . . . 14 4.1.4 Systemöversikt . . . 14
4.1.5 Anonymisering . . . 16
4.1.6 Sensorns funktioner . . . 17
4.2 Analys av säkerhet . . . 18
4.2.1 Datakommunikation . . . 18
4.2.2 Testa hashat värde . . . 18
4.3 Testning . . . 20 4.3.1 Test av sensor . . . 20 4.3.2 Malmö högskola . . . 20 4.3.3 Malmö Central . . . 22 4.3.4 Avståndsmätning . . . 23 4.4 Validering . . . 24
5 Diskussion och slutsats 25 5.1 Insamlad data . . . 25
5.2 Känslig information . . . 25
5.3 Anonymisering . . . 25
5.4 Metoddiskussion . . . 26
5.5 Slutsats . . . 26
5.6 Arbete i vidare sammanhang . . . 27
A Avnämare 32 A.1 Internet of Things and People . . . 32
A.2 Cooperative, Self-aware and Intelligent Surveillance Systems . . . 32
A.3 Arbetsmöte . . . 32 B Bilder 33 B.1 Android-applikation . . . 33 B.2 oclHashcat . . . 37 B.3 Databas . . . 38 C Intervju 39 C.1 Intervjufrågor . . . 39 C.2 Referat . . . 40 D Källkod 44 D.1 Android . . . 44 D.1.1 AnalyzeFragment.java . . . 44 D.1.2 BluetoothDevices.java . . . 46 D.1.3 DeviceAdapter.java . . . 49 D.1.4 Devices.java . . . 50 D.1.5 Display.java . . . 51 D.1.6 DisplayAdapter.java . . . 52 D.1.7 DisplayFragment.java . . . 53 D.1.8 HashMethods.java . . . 57 D.1.9 MainActivity.java . . . 58 D.1.10 ScanBTFragment.java . . . 59 D.1.11 StartFragment.java . . . 63 D.1.12 AndroidManifest.xml . . . 65 D.2 MySQL . . . 66 D.2.1 Skapande av tabeller . . . 66 D.3 PHP . . . 67
D.3.1 get.php . . . 67 D.3.2 insert.php . . . 68
1
Inledning
1.1 BakgrundInternet of Things (IoT) är ett sätt att utöka Internet. Internet har utvecklats från att vara endast en plattform för användare till användare-interaktion till att även vara en plattform för enhet till enhet-interaktion. En kommunikationsmetod som används mellan enhet till enhet är Bluetooth. Bluetooth används i olika enheter så som smartaklockor, mobiltelefoner och hörlurar.
Ända från början av Internets historia (1989) har det utvecklats enheter som kan styras över Internet. För att kunna kommunicera med enheterna krävs det att de är uppkopplade till varandra över Internet. En metod för att koppla ihop enheter via Internet är med trådlös kommunikation som WiFi [1].
Mobila enheter med till exempel Bluetooth kan även vara till hjälp att komplettera bilder från övervakningskameror med information om antalet personer som befinner sig i områ-det. Det kan användas för att se genomströmningen och estimera antalet personer på en offentlig yta. Bluetooth kan vara användbart för att samla in mer data från omgivningen och gör att ingen bildbehandling behöver användas (bilaga A.3).
Metoden att samla in data för att estimera antalet personer i ett område är en del av projektet Cooperative, Self-aware and Intelligent Surveillance Systems (CoSIS). En av projektets intressenter är Axis Communication som tillverkar intelligenta nätverkskame-ror. Projektet bedrivs av forskningscentret Internet of Things and People (IOTAP) vars fokus ligger på forskning hur användare kan interagera med anslutna enheter, hur använ-dare kan bli involverade i IoT tjänster och produkter samt hur intelligens i enheter kan öka användandet och funktionaliteten för IoT-tjänster och produkter. Se bilaga A för mer detaljer om intressenter.
Genom att komplettera övervakningskamerors bildtagning med insamling av data som Media Access Control-adresser (MAC-adresser) från mobila enheter så kan det vara krän-kande för den personliga integriteten. Om den insamlade data ska lagras i databaser ställs det höga krav på säkerheten. Desto säkrare lagring samt skyddande av data, desto svårare blir det för obehöriga att kunna identifiera mönster och hitta information som kan vara kränkande för den personliga integriteten (bilaga A.3).
1.2 Syfte och problemformulering
Syftet med denna studie är att utveckla ett proof of concept-system som ska kunna läsa av data från mobila enheter. Vidare så är syftet att kunna ge underlag till CoSIS vilken typ av data som kan vara intressant att undersöka för att kunna gå vidare och estimera antalet personer på en offentlig yta. Frågeställningar för detta examensarbete är följande.
De generella är:
• Vilka typer av enheter kan hittas i det offentliga rummet?
• Vilken typ av data kan vara intressant för att få tag på i det offentliga rummet? De specifika är:
• Hur går det att undvika att samla in för mycket data för att skydda individers integritet?
1.3 Krav
Kraven vi har fått från intressenter (bilaga A.3) är att fokus ska vara på integritet, säkerhet och insamling av Bluetooth-data.
Systemet som vi ska utveckla kommer bestå av ett proof of concept-system som samlar in MAC-adresser från Bluetooth hos mobila enheter. För att undvika integritetsproblem så kommer hashfunktioner användas för att försvåra möjligheten att utläsa känslig data (ursprunglig indata kommer inte gå att utläsa). Hashningen kommer att ske i en Android applikation på en smartphone, som kommer agera som sensor, för att sedan skickas till en databasserver.
• Kunna identifiera mobila enheter. • Samla in data som MAC-adresser.
• Göra MAC-adresserna oläsliga med hjälp av en hashfunktion. • Systemet kommer lagra indata i olika anonymitetsnivåer. • Lagra data på en databasserver från flera enheter samtidigt. • Kunna visa insamlad data på olika enheter.
1.4 Avgränsningar
För att enheter ska kunna hittas av vårt system så måste Bluetooth vara aktiverat på enheten.
Informationen som sparas från de hittade enheterna kommer att göras oigenkännlig med algoritmen Secure Hash Algorithm (SHA-1), se kapitel 3.3 för mer information, och se-dan skickas vidare till en databas. Databasen kommer bara att användas till lagring, det kommer inte läggas fokus på databassäkerhet.
1.5 Relaterat arbete
I nedanstående kapitel har vi valt att ha med studier som har haft datainsamling med MAC-adresser från både Bluetooth- samt WiFi-enheter. Detta då dessa studier delvis berör anonymisering och för att WiFi:s MAC-adress liknar som Bluetooth-enheters. Förutom vetenskapliga studier har vi även tagit med företag som jobbar med datainsamling från mobila enheter.
1.5.1 About the relationship between people and discoverable Bluetooth de-vices in urban environments
Nicolai och Kenn [2] utförde en studie 2007 där de kollade på fyra platser relationen mellan antalet Bluetooth-enheter och antalet personer på platsen. För att samla in antalet enheter på en plats så användes en dator och en mobiltelefon. Utifrån den insamlade informationen gick det att se att telefoner var det som upptäcktes mest. Men även datorer
och andra enheter med Bluetooth hade upptäckts. Det var vanligare att Bluetooth var på och upptäckbara på telefoner än andra enheter. Dock visade sig att det endast var 2-6% av de mobila enheterna som hade Bluetooth aktiverat.
1.5.2 An analysis of visitors’ behavior in The Louvre Museum: a study using Bluetooth data
Yoshimura et al. [3] har under sin studie 2014 använt Bluetooth-sensorer för att läsa in mobiltelefoner och på så sätt kunna analysera besökarnas beteende på Louvre muséet i Frankrike. Sedan när den insamlade informationen lagras används hashfunktionen SHA-1 för att göra MAC-adresserna oigenkännliga. MAC-adresserna har sedan lagrats i en databas där även datum, incheckningstid, utcheckningstid och även tid för hela besöket på muséet lagras. Yoshimura et al. kom till slutsatsen att i snitt hade 8.2% av besökarna Bluetooth aktiverat.
1.5.3 IoT Security & Privacy: Threats and Challenges
Hwangs [4] tar upp i sin studie att det finns utmaningar och hot som kommer med IoT-system. Det första som nämns i denna studie är E2E (end-to-end) Data Life-cycle Pro-tection vilket innebär att det ska finnas skydd i hela IoT-systemet för att skydda data. Detta eftersom data oftast delas med andra enheter.
Det andra som nämns i studien är Secure Things Orchestration vilket innebär att ”saker” som är sammankopplade ständigt förändras men ”sakerna” måste kunna hålla samma säkerhet hela tiden oavsett ifall fler ”saker” läggs till systemet eller inte. Det skulle gå att säga att har en obehörig person kommit åt en enhet så är det lättare att komma åt de andra som är uppkopplade till samma system.
Det tredje hotet, Security Platform for Multi-Level Things handlar om att det är olika enheter i IoT så är det svårt att hålla samma säkerhetsnivå eftersom prestandan på de olika enheterna skiljer sig åt.
Fjärde hotet, Visible/Usable Security & Privacy handlar om att det är svårt för använ-darna av IoT-system att förstå säkerheten bakom systemet. Använanvän-darna kan göra fel vid konfigurering och på så sätt brister systemet och obehöriga kan komma åt systemet.
1.5.4 Location Privacy Vulnerable from Bluetooth Devices
I studien från 2013 så tar Kikuchi et al. [5] upp begreppet platsintegritet och risker vid användning av Bluetooth. Forskningsfrågor som skulle svaras på i studien var, hur ofta som Bluetooth-enheter kan scannas av, om förhållandet är stabilt eller beroende av plats och tid och den sista frågan var om hur stort hotet för integritet från Bluetooth enheterna. För att kunna svara på forskningsfrågorna så utförde Kikuchi et al. experiment med egen-utvecklad scanner på campus och offentliga platser. Från de hittade Bluetooth-enheterna så samlades bland annat MAC-adresserna och klass av enhet in.
För att få underlag så gjordes en undersökning där Kikuchi et al. kollade hur många som hade enheter med Bluetooth och det visade vara sig 70%. Det visade sig även att 25% har alltid Bluetooth aktiverat. Anledningen till varför Bluetooth var avaktiverat var att spara batteritiden. Det gjordes även klart att de tre vanligaste enheterna med Bluetooth
var mobiltelefoner, bärbara datorer och trådlösa möss. Vissa personer hade även mer än en enhet.
Experimentet att söka efter Bluetooth-enheter gjordes på fakulteten för Information och telekommunikation på Universitetet Tokai i Tokyo. Detta eftersom det stora antalet av IT-studenter gör det högst troligt att många har enheter med Bluetooth. Experimentet utfördes enligt två steg för att kunna ge ett resultat. Det första steget var att med hjälp av en bärbar dator scanna efter andra Bluetooth-enheter 10 meter från sensorn. Steget efter detta var att visuellt räkna antal personer på platsen.
Resultatet av experimentet var att de hade visuellt sett 942 personer och detekterat 1496 Bluetooth-enheter. Ett sammanfattade resultat var att 1.26 personer utav 100 hade bli-vit detekterade över en dag. Genom att göra experimenten på olika platser kunde de konstatera att antalet enheter beror på platsen.
1.5.5 Anonymity properties of stored or transmitted data taken from Blue-tooth scans
I Evans et al. [6] studie tar de upp om anonymitet vid insamling av Bluetooth-data på University of Waterloo. Data som kunde utläsas från Bluetooth var namn av enhet (som kan ändras av användaren), MAC-adressen, device major class (identifierar typ av enhet), device minor class (mer specifikt vilken typ av enhet) och sist vilken service som enheten erbjuder (se kapitel 3.1.1).
För att söka efter Bluetooth-enheter så användes programmet btsscan. Sökningen efter Bluetooth-enheter utfördes på två platser. Första platsen var på University of Waterloo där en Bluetooth-mottagare placerades bakom en dörr vid en passage som var mellan två byggnader. Mätningen gjordes under 88 dagar och 486 olika enheter hade hittats och blev upptäckta 429 925 gånger. Den andra platsen där mätningar utfördes var i en marknära lägenhet. Mätningar gjordes under 101 dagar och 2051 olika enheter hittades 136819 gånger. Från dessa två datainsamlingar så var mobiltelefoner de enheter som blivit upptäckta flest antal gånger.
Utifrån insamlad data så testade de att koppla ihop enheter med personer. Eftersom University of Waterloo har en online-katalog med uppgifter om studenterna så kunde de söka där efter text som användes som Bluetooth-enhetens namn. Resultatet av detta var att de kunde knyta ihop 35 enheter med fysiska personer. Forskarna hade även observerat att namn på personer samt deras telefonnummer hade använts som namn till Bluetooth-enheten och det utgör ett integritetsproblem. Även smeknamn hade använts och om dessa användes på fler ställen så skulle det gå att komma närmare en identifiering.
1.5.6 Renew London
I London har det gjorts tester av Renew London med 12 soptunnor som haft sensorer som läste av förbipasserandes mobiltelefoners MAC-adresser genom WiFi. Soptunnorna var utrustade med LCD-skärmar som var avsedda att ge direktriktad reklam till de som passerade [7].
En av Renew Londons planer var att de skulle sälja in idén till pubägare. Tanken var att det skulle sitta fem stycken spårningsenheter inne i puben; en vid ingången, en på taket, en vid kassan samt en på dam- respektive herrtoaletten. Detta gjorde det möjligt att se dels vad det var för kön på kunden (via badrumsspårningsenheten), hur länge kunden
stannade på puben och vad de gjorde på puben (åt inne eller tog en drink ute). Sedan skulle denna information kunna leda till att ge riktad reklam till kunden via soptunnornas LCD-skärmar [8].
Renew London fick fram bra resultat gällande deras sensorer. Testet har bland annat visat på vilka tider som folk rör sig mest där soptunnorna är placerade. Mätningar under en vecka från en soptunna visar att det är som mest förbipasserande vid transport till och från arbete (morgon och eftermiddag) samt vid lunch samt har kunnat visa att ca 80% av mobiltelefoner har WiFi aktiverat [8].
1.5.7 Bumbee Labs
Ett svenskt företag, Bumbee Labs, erbjuder en tjänst som liknande den som Renew London använder. De använder sig av en teknik som de kallar Indoor Outdoor Positioning System (IOPS). IOPS installeras som ett meshnätverk (i form av WiFi-nätverk) och kan placeras ut i en stadskärna eller köpcentra, eller annan geografisk placering. IOPS lyssnar av WiFi-enheter och registrerar enhetens MAC-adress samt enhetens signalstyrka (och sedan hashas innan informationen skickas till en databas) [9].
Med data som har samlats in genom IOPS har kommunerna kunnat se flödet av individer i till exempel stadskärnan och kunnat se vilka vägar folk rör sig. Med denna information är det möjligt att mäta effekterna av gatubelysning och dekorerat gatuutrymme och kommu-nens gatuplanerare kan se att outnyttjade gator får besökare när gatan blir mer attraktiv i form av till exempel bättre belysning [9].
1.5.8 BLIP Systems A/S, Integrating BLIP into Location-Aware System: A Service-Oriented Method
Tillverkaren BLIP Systems A/S har i sitt produktutbud sensorer som registrerar WiFi och Bluetooth-signaler. Sensorerna är till för att mäta flödet i olika sammanhang som till exempel vägtrafik och hur trafikanter rör sig på tågstationer. Data levereras direkt och ger omedelbar feedback till ansvariga för att styra flödet (möjliggör att se till exempel när det är trafikstockning) [10].
Systemet används bland annat lokalt i Malmö för att utvärdera stadens trafiknät, fin-justera trafik samt kunna förutse hur vägarbete kommer påverka trafikflödet [11].
Lin et al. [12] gjorde ett test med Blip Systems Bluetooth-sensorer på Köpenhamns flyg-plats och fick bra resultat gällande att kunna detektera passagerare och personals mo-biltelefoner, dock upplevdes problem med att systemet kunde vara långsamt. Kring fem sekunder tog det att upptäcka en Bluetooth-enhet. Dock antogs detta inte vara ett problem då mobilbäraren generellt sett stannar på en plats längre än fem sekunder.
1.6 Etik och lagar
För att skydda individers integritet finns det en lag i Sverige som reglerar hur personupp-gifter och information kring individer får lagras genom Personuppgiftslgen (PuL). PuL tillämpas endast på uppgifter som finns lagrat på ett strukturerat sätt, personuppgifter som framkommer i löpande text i till exempel brev anses vara ostrukturerat. Strukturerad
datainsamling innebär att personuppgifter är lagrade i någon form av register, till exempel i en databas och således blir sökbara [13]. En personuppgift är information som direkt eller indirekt kan knytas till en person. Denna information behöver inte bara vara en persons id utan kan vara foton och ljudupptagningar samt även krypterade uppgifter som IP-adresser [14]. Dock finns det oklarheter om en MAC-adress kan anses vara en personuppgift, vid skrivande tillfälle är inte Datainspektionens utredning klar [15].
För att inte bryta mot PuL måste varje person som är med i registret ge sitt samtycke att registreras. Med samtycket godtar personen att personuppgifter om sig själv kan komma att behandlas [16].
Som nämnts i kapitel 1.5.6 har Renew London haft sensorer och samlat in mobila enheters MAC-adresser, detta mottogs dock inte positivt bland allmänheten. Försöket fick avslutas då testerna befann sig i en etisk gråzon och frågor uppkom kring individers integritet. I Storbritannien är dock datainsamling av anonyma uppgifter såsom MAC-adresser lagligt [7].
Datainspektionen har beslutat om att göra en tillsyn av Bumbee Labs (nämns i kapitel 1.5.7). Tillsynen ska pröva användning av tekniken Bumbee Labs använder och hur den påverkas av personuppgiftslagen. Bedömningen väntades vara klar våren 2015, dock har den inte kommit ut vid detta tillfälle [9]. Bumbee Labs själv menar att data de samlar in inte är personuppgifter då det inte går att knyta till en person [15]. Dock finns det andra kritiska röster, som Markus Bylund på Swedish institute of computer science, SICS. Enligt Bylund är det möjligt att koppla hashade MAC-adresser till individer och det är möjligt att se vilka rörelsemönster en MAC-adress har [17]. På så sätt går det att ta reda på individens hem och jobb. Bumbee Labs har ett system för att minska risken för att det ska gå att identifiera individen på en övervakningskamera. För att det inte ska gå att se på övervakningsfilmen vem det var som befann sig på en viss tid slumpas tiden med plus minus 20 minuter [17].
1.7 Disposition
Vi har valt följande disposition för vår uppsats.
Kapitel 2 Metod innehåller vald forskningsmetod och varför den valdes. Vi skriver även
om litteratursökningen, intervju och arbetsmöten.
Kapitel 3 Teknisk bakgrund innehåller den tekniska bakgrunden för arbetet. Vi tar upp
de begrepp och termer som är viktiga för att förstå för att kunna återskapa arbetet.
Kapitel 4 Resultat innehåller beskrivning av proof of concept och vår fallstudie. Kapitel 5 Diskussion och slutsats innehåller slutsatsen för arbetet. Resultatet och
metoden diskuteras även i detta kapitel. Vi tar även upp spekulationer om vad som hade varit intressant att arbeta vidare med.
2
Metod
2.1 MetodvalMetoden som valdes för detta arbete var en blandad metod (mixed methodology) [18]. Metoden kombinerar kvalitativ och kvantitativ datainsamling. Genom att kombinera dessa två datainsamlingsmetoder är det möjligt att generera fler argument till resultatet. På så sätt så blir det lättare att stödja slutresultatet.
Den kvalitativa datainsamlingen kommer bestå av litteratursökning, en intervju samt del-tagande i arbetsmöte med IOTAP (CoSiS).
Den kvantitativa datainsamlingen har bestått av att vi utvecklat en applikation till Android-enheter som vi har använt till att undersöka vilken metod som erbjuder bäst säkerhet i förhållande till personlig integritet. Applikationen verkar även som en proof of concept och den utvärderas enligt ett säkerhetsperspektiv. Applikationen benämns hädanefter som sensor samt applikation i kombination med databasserver som system.
2.2 Litteratursökning
Litteratursökningen gick ut på att vi sökte information från examensarbeten och veten-skapliga artiklar från databaser som IEEE (Institute of Electrical and Electronics Engine-ers) och ACM (Association for Computing Machinery). Genom material som vetenskapliga artiklar så gick det att se vad forskning haft för intresse inom området med att samla in data från enheter samt hur integriteten går att skydda. Undersökningen har även bidragit till hur olika sorters tekniker fungerar så som hashfunktioner, Bluetooth och program-mering av Bluetooth till Android enheter. Vid informationssökningen har fokus lagts på, förutom att hitta relevant material, hitta material som kan tolkas vara pålitlig, opartisk samt aktuell.
2.3 Utveckling av proof of concept
Efter förstudien då vi hade brutit ner vårt proof of concept i delproblem så började vi designa och utveckla delsystem. Sensorn började utvecklas med funktionen att kunna sö-ka efter andra Bluetooth-enheter samt att hasha MAC-adresserna med SHA-1. För att sensorn skulle vara användbar så utvecklades ett grafiskt användargränssnitt för att lätt kunna använda sensorn. Sedan började server-sidan utvecklas. Detta innefattade databas-servern och datasändning till och från databasen.
Systemet är utvecklad enligt designmönstret MVC (Model-view-controller), i form av server-klient (dock används endast servern som databas, ingen logik ligger på servern). View motsvarar det grafiska användargränssnittet, Controller är själva logiken i applika-tionen och Model är databasen [19].
2.4 Arbetsmöte
Vi har även deltagit i arbetsmöte med representanter från deltagande företag i IOTAP. Dessa möten gav en tydligare bild på vad projektet CoSIS i sig handlade om och på så sätt kunde det hjälpa oss att göra avgränsningar på arbetet. För en sammanställning av arbetsmöte, se bilaga A.3.
2.5 Intervju
En intervju gjordes med Johan Gustavsson som är universitetsadjunkt på Institutionen för Datavetenskap på Malmö högskola. Johan föreläser om databasteknik och etik. Frågor som ställdes var angående datainsamling, PuL, anonymisering av data och den etiska synen på insamling av data. För referat av intervjun se bilaga C.2.
2.6 Metodöversikt
Den vetenskapliga stegvisa metoden som vi har arbetat efter framgår i figur 1. Som nämns i kapitel 2.2, 2.3 har vi fått insikt i vad som ska ingå i vår applikation. Vi går sedan tillbaka till våra intressenter och litteratursökning för vidareutveckling allteftersom vi får kännedom om vad som bör vara med och på så sätt iterera fram en applikation. Likaså kommer iterationer ske när vi validerar sensorn. Figur 1 visar hur flödet går när vi utvecklar vårt system.
3
Teknisk bakgrund
3.1 Bluetooth3.1.1 Klassisk Bluetooth
Bluetooth är en teknik för trådlös, energisnål och kostnadseffektiv överföring av data som skapades av Ericsson under 1994 [20].
På grund av Bluetooths egenskaper så har tekniken erhållit en betydelsefull roll när det gäller kommunikation mellan olika mobila enheter. Detta kan vara enheter så som smartp-hones, bärbara datorer, surfplattor osv [20].
Beroende på hur långt Bluetooth-signalerna för en enhet ska nå, så finns det tre olika klasser. Klass 1 är den klass som har längst räckvidd på 100 meter och denna används främst i industriella användningsområden. Klass 2 är vanligt förekommande i dagens mo-biltelefoner och har en räckvidd på 10 meter. Klass 2 har också en låg effektförbrukning på 2.5mW. Den sista klassen klass 3 har en räckvidd på 1 meter [21, 22]. Bluetooths över-föringshastighet är beroende av avstånd, ju längre avstånd ju långsammare att föra över data. Även hinder i vägen minskar hastigheten [22].
Signalerna från Bluetooth använder sig av ISM-bandet (Industry Scientific Medical band) som använder frekvensspektret 2.400 till 2.485 GHz. Signalstyrkan, RSSI (Received Signal Strength Indication) mäts i en logaritmisk skala, dBm. Bluetooth-tekniken använder sig av FHSS (Frequency Hopping Spread Spectrum) vilket innebär frekvenshoppning. Bluetooth hoppar mellan 79 olika frekvenser med hjälp av pseudo-slump. Genom att hoppa bland olika frekvenser så blir det mindre risk för interfererande störningar [20, 23].
3.1.2 MAC-adress
För det ska gå att identifiera olika Bluetooth-enheter då de kopplar upp sig mot en annan Bluetooth-enhet så används unika adresser. Dessa adresser kallas för MAC-adresser och är oftast skrivna i hexadecimal form (XX:XX:XX:XX:XX:XX, där X är 0-F). Den hexadeci-mala formen består av 48 bitar som sedan indelas i sex oktetter (eller bytes). De tre första oktetterna kallas för Organizationally Unique Identifier (OUI). OUI visar vilket företag som har en licens för att få göra produkter där MAC-adress används [24, 25, 26].
MAC-adressens sista tre oktetter innehåller enhetens Class of Device (CoD). CoD anger vilken klass en specifik enhet tillhör. De olika klasserna kategoriseras i Major Service Class och Major Device Class. Major Service Class som består av 11 bitar (bit 13 till och med 23) talar om vilken typ av service som enheten kategoriseras in i. Kategoriseringen används för att Bluetooth-enheter ska veta vilken typ av enhet de kopplar upp sig mot [26, 27]. Se tabell 1 nedan.
Tabell 1: Tabellen visar grupper med olika funktioner som en Bluetooth-enhet kan tillhöra.
Bit No. Major Service Class
13 Limited Discoverable Mode 14 (reserved)
15 (reserved)
16 Positioning (location identification) 17 Networking (LAN, Ad hoc, . . . ) 18 Rendering (Printing, Speakers, . . . ) 19 Capturing (Scanner, Microphone, . . . ) 20 Object Transfer (v-Inbox, v-Folder, . . . )
21 Audio (Speaker, Microphone, Headset service, . . . )
22 Telephony (Cordless telephony, Modem, Headset service, . . . ) 23 Information (WEB-server, WAP-server, . . . )
Källa: Bluetooth Technology Special Interest [27]
Bit nummer 8 -12 talar om vilken typ av enhet det är. Se tabell 2 nedan.
Tabell 2: Tabell som visar vilka olika typer av Bluetooth-enheter det kan finnas.
12 11 10 9 8 Major Device Class
0 0 0 0 0 Miscellaneous
0 0 0 0 1 Computer (desktop, notebook, PDA, organizer, . . . ) 0 0 0 1 0 Phone (cellular, cordless, pay phone, modem, . . . ) 0 0 0 1 1 LAN /Network Access point
0 0 1 0 0 Audio/Video (headset, speaker, stereo, video display, VCR, . . . ) 0 0 1 0 1 Peripheral (mouse, joystick, keyboard, . . . )
0 0 1 1 0 Imaging (printer, scanner, camera, display, . . . )
0 0 1 1 1 Wearable
0 1 0 0 0 Toy
0 1 0 0 1 Health
1 1 1 1 1 Uncategorized: device code not specified X X X X X All other values reserved
Källa: Bluetooth Technology Special Interest [27]
3.1.3 Uppkoppling
För att en Bluetooth-enhet ska kunna söka och koppla upp sig mot andra enheter så måste enheterna vara upptäckbara. En Bluetooth-enhet kan vara i två olika standard-läge som kallas för uppkopplingsstandard-läge och väntestandard-läge. För att enheterna först ska kunna söka efter varandra och sedan skapa en förbindelse så är det ett antal steg som måste genomföras.
Förfrågan (Inquiry procedure) är den första processen som utförs. Processen innebär att den Bluetooth-enhet som agerar master försöker identifiera andra enheter (slav-enheter) inom sitt avstånd. Master-enheten skickar ut meddelande med en Inquiry Access Code (IAC) till slumpmässigt 32 olika kanaler utav 79 kanaler. Slav-enheterna som befinner sig i vänteläge sätter igång en inquiry scan för att ta emot meddelande från master-enheten. När slav-enheten har tagit emot meddelandet från master-enheten så intar slav-enheten läget inquiry response och skickar sedan tillbaka ett Frequency Hopping Spectrum-paket
(FHS-paket). I paketet så ingår information som behövs för att koppla upp enheterna med varandra. Informationen är MAC-adressen och Bluetooth-klockans värde men även information som Bluetooth-namnet, Bluetooth-klass och RSSI. Såvida det inte blir någon kollision med att flera enheter skickar inquiry response samtidigt eller att processen tar längre tid än 10,24 sekunder att genomföra så kommer nästa process att startas. Om det skulle ta längre tid för en förfrågan än 10,24 sekunder så kommer enheten att sättas i vänteläge (för att spara energi) och inquiry procedure kommer att göras om.
Den andra processen heter page procedure och är den sista som krävs för att få kommuni-kation mellan två eller flera slav-enheter. Vid denna process så har master-enheten hittat slav-enheter inom sitt sökområde. Det första som sker i denna process är att slav-enheten utför en page scan vilket innebär att den lyssnar på ett meddelande från master-enheten som sänds ut till de olika kanalerna. Meddelande innehåller en Device Access Code (DAC) som är unik för slav-enheten. Då slav-enheten mottagit sin DAC så skickar slav-enheten ett slave response. Då master-enheten mottagit svaret så bestämmer den ifall den ska ska-pa kommunikation mellan enheterna eller gå tillbaka till ska-page procedure [26, 28]. Se figur 2 för illustration över uppkopplinhsprocess.
Bluetooth Special Interest Group har specificerat för att garantera att inte få fel på da-taöverföring, bör inte RSSI vara högre än -70 dBm [29].
Figur 2: Modell över Bluetooth-enheters uppkopplingsprocedur [30].
3.1.4 BLE
Bluetooth Low Energy (BLE) är en ny version av Bluetooth som används där låg ener-giförbrukning har stor betydelse. Detta kan vara till enheter såsom fitnessarmband och smarta klockor, med andra ord inga stora enheter och det gör att enheterna kan drivas av små energikällor som till exempel knappcellsbatterier. BLE:s funktioner är låg förbrukning då en BLE-enhet är i viloläge och möjlighet för några års användning [31].
3.2 Android
Android är ett operativsystem för mobila enheter som används exempelvis i klockor, tele-foner, surfplattor med flera. Android bygger på öppen källkod och operativsystemet Linux. Applikationerna skrivs i programmeringsspråket Java och Google har en utvecklingsmiljö, Android Studio som låter utvecklare fritt skriva kod till applikationer [32].
3.3 Hashfunktion
Hashfunktioner används för att göra text oigenkännbar för andra som inte bör kunna läsa texten. Funktionen tar in en text och gör sedan om texten till en hashkod. Hashkoden beror av tecknen i originaltexten vilket innebär skulle ett tecken ändras i originaltexten så skulle hashkoden bli annorlunda [33].
Två exempel på vanligt förekommande hashfunktioner är Message Digest 5 (MD5) och SHA-1. MD5 kom ut 1991. MD5 är sårbar på det sättet att den orsakar kollisioner på ett förutsättbart sätt (två olika ord kan ge samma hashade resultat). Med denna kunskap om vilka ord som ger kollisioner gör det att det är möjligt att knäcka och återställa hashade ord genom brute force-attacker1 [33].
Under 1995 kom SHA-1. SHA-1 erbjuder högre säkerhet än MD5 genom att SHA-1 kodar en längd av tecken till 160 bitar medan MD5 endast kodar till 128 bitar [33]. SHA är en hashfunktion som finns i olika former. SHA-2 är en uppdaterad funktion som erbjuder större output (fler bitar). Eftersom det är fler bitar så ökar säkerheten och det blir allt svårare att få fram originaltexten [35].
För att öka säkerheten vid hashning är det möjligt att lägga till ett slumpmässigt tillägg till det ursprungliga ordet. Detta tillägg kallas salt och saltet adderas för att öka komplexiteten av det hashade resultatet och gör att bruce force-attacker blir mycket svårare [33].
3.4 Kryptering
Kryptering används för att göra viktig information oläslig för obehöriga personer. För att information ska bli oläslig så används en krypteringsalgoritm med en eller två nycklar. Två vanliga typer av kryptering är symmetrisk och asymmetrisk kryptering.
Symmetrisk kryptering har en nyckel som delas av sändaren och mottagaren. Nyckeln används sedan tillsammans med krypteringsalgoritmen för att kryptera och dekryptera meddelande som skickas.
Den asymmetriska krypteringen skiljer sig från den symmetriska eftersom den har två nycklar. Sändaren använder en publik nyckel för att kryptera och mottagaren har en privat nyckel för att dekryptera meddelande [36].
3.5 MySQL
My Structured Query Language (MySQL) är en databashanterare för att lagra data. MySQL är även en del av plattformen Linux, Apache, MySQL and PHP (LAMP). Plattfor-men LAMP gör det möjligt att på ett enkelt sätt sätta upp en webbserver på en Linuxdator [37].
1Metod som används till exempel för att upptäcka lösenord. Brute force går ut på att prova alla
kombinationer för att testa sig fram till rätt lösenord. Ett exempel kan vara att använda ord från ordlistor och testa dessa som lösenord, ett ord efter ett annat tills rätt ord fungerar (eller tills ordlistan tar slut) [34].
3.6 PHP
PHP: Hypertext Preprocessor (PHP) är ett scriptspråk som kan användas tillsammans med HTML på en databasserver för att hantera data som finns i databasen [38].
3.7 Linux
Linux är ett operativsystem som går under öppen källkodlicens. Operativsystemet är väl-digt utbrett och används i många olika datorsystem. [39].
3.8 Raspberry Pi
Raspberry Pi är en liten dator som kör Linux. Prestandan för datorn går inte att jämföra med en vanlig stationär dator. Men trots datorns prestanda så går den att använda som till exempel en webbserver [40, 41].
4
Resultat
4.1 Proof of concept
Nedan beskriver vi i detalj hur vi gick till väga i vår fallstudie över utvecklingen av vårt system, bestående av sensor och databasserver.
4.1.1 Utvecklingsmiljö
Sensorn utvecklades genom att programmera Android-applikationen i utvecklingsmiljön Android Studio med Java. Vi använde versionshanteringsprogrammet Github som vi tidi-gare haft erfarenhet av för att smidigt kunna arbeta med samma filer till projektet. Protokollet för att kommunicera med den databasserver som användes var Secure Shell (SSH) för att kunna konfigurera den och för att administrera databasen används phpMy-Admin.
4.1.2 Android-applikation
De API:er som används för Bluetooth är BluetoothAdapter, BluetoothClass samt Blue-toothDevice.
Sensorn är utvecklad med Android API 18 (Android 4.3) som lägsta nivå. Denna nivå valdes då det är det API då BLE introducerades i Android och vi ville kunna ha med BLE-enheter också i vår sökning [42].
För att kommunicera med databasservern används API:et HttpClient för nätverkskommu-nikation, HttpPost för att skicka data till databasen samt BufferedReader för att hämta data som skickas från databasen.
4.1.3 Databas
En Raspberry Pi (som kör LAMP) agerar databasserver, så databasen består av en MySQL-databas (MySQL är en relationsdatabas). Det fanns möjlighet att använda Andro-ids inbyggda databas, SQLite, vilket också är en relationsdatabas. Problemet med SQLite är att data lagras direkt på enheten, detta gör att det inte går att ha en databasserver med SQLite som fungerar enligt klient-server-metoden [43, 44]. För att administrera data-basen använder vi phpMyAdmin, se figur 21 (bilaga B.3) för översikt över hur innehållet i databasen är strukturerat.
4.1.4 Systemöversikt
Varje sensor läser av andra mobila läser av andra mobila Bluetooth-enheters data (MAC-adress, typ av enhet och RSSI). Dessa mobila enheter befinner sig i det offentliga rummet, vilket kan vara ett mindre rum till att täcka en större yta. Databasservern kan ta emot insamlad information från en eller flera sensorer och lagrar informationen. Denna infor-mation analyseras sedan, möjlighet finns att visa resultatet på olika sorters media. I vårt system används sensorn för att hämta information och sedan visa den. Se figur 3 för systemöversikt.
Figur 3: Systemöversikt
Se figur 4 beskrivning över hur de olika komponenterna som som sensor, databasserver och enhet för visning fungerar. När sensorn har hittat en Bluetooth-enhet lagras informa-tion om den (tidpunkt, RSSI, klass samt de tre olika anonymiseringsnivåerna) i en array av namn-värde object (BasicNameValuePair). Denna array är uppbyggd av sex stycken namn-värde objekt och varje namn-värde objekt lagrar en av informationen tillhöran-de Bluetooth-enheten (tidpunkt, RSSI, klass samt tillhöran-de tre olika anonymiseringsnivåerna). Namn-värde objekten fungerar i vår applikation att dels sparas ett fast värde (används som POST-kommando i PHP-scriptet) samt det värdet som tillhör den registrerade Bluetooth-enheten. Denna array skickas till databasservern genom HTTP-protokoll, som sedan ett PHP-script fångar upp POST-kommando. Data läggs sedan in i MySQL-databasen med INSERT-kommando.
I vår som sensor är det samma enhet som samlar in data som visar data (dock är det möjligt att visa insamlad data på andra enheter). För att hämta data som ska visas skickar databasservern iväg data genom ett PHP-script. Detta PHP-script hämtar all data från vald tabell med SELECT-kommando och sedan data skickas denna data iväg med ett echo-kommando från PHP-scriptet.
Figur 4: Kommunikation mellan komponenter.
4.1.5 Anonymisering
För att göra data oigenkännbar så används hashfunktionen SHA-1. En alternativ lösning istället för att använda en hashfunktion hade varit att använda kryptering. Men eftersom den oigenkännbar informationen inte bör återgå till dess ursprung (för att skydda integri-teten hela vägen) så fungerar hashfunktionen utmärkt. Vi valde att använda SHA-1 direkt i sensorn och på så sätt så blir de insamlade MAC-adresserna oigenkännbar tidigt. Den hashade MAC-adressen skickas tillsammans med information om vad för typ av enhet det är som är identifierad till en databasserver.
Vårt system har tre olika sorters anonymiseringsnivåer för att anonymisera data. Den förs-ta och säkraste nivån är full anonymisering. Denna innebär att hashfunktionen använder MAC-adressen, datum och tid som indata. Utdata kommer då bli hashkoden av de oli-ka värdena tillsammans. Aktuellt klockslag blir då det saltade värdet som adderas innan hashning. Se tabell 3 för hur MAC-adressen med värdet AA:BB:CC:DD:EE:FF, som lästs in 2015-05-04 kl. 21:16 får för resultat (output).
Den andra nivån är semi-anonymisering vilket innebär att indata till hashfunktionen är adress och timmen då den blev insamlad. I tabell 3 finns output för samma MAC-adress vid samma datum och klockslag som ovan, dock endast under timme 21.
Sista nivån är endast SHA-1 och den använder bara MAC-adressen som indata till hash-funktionen. På så sätt kommer hela tiden hashkoden erhålla samma värde. Se tabell 3 nedan för exempel på de tre olika nivåerna. De tre olika nivåerna sparas sedan i databasen i olika tabeller, en för varje anonymiseringsnivå. Detta för att underlätta analysen.
Tabell 3: Anonymisering av MAC-adresser.
Typ av anonymisering Input Output
Full anonymisering 201505042116AA:BB:CC:DD:EE:FF ab5d6a6c67f1767bbd2741aa2cbe31ed26cad42f Semi-anonymisering 2015050421AA:BB:CC:DD:EE:FF 16d046b738e8d6d632040eb422d89fca10b97ea4 Endast SHA-1 AA:BB:CC:DD:EE:FF 9ee9a721a06498df89a7488c1434594c012a33bb
Anonymiseringsnivåerna är fastställda efter vad våra intressenter (bilaga 1.3) önskar att kunna erbjuda för olika tjänster. Full och semi-anonymisering är båda hashade
tillsam-mans med ett salt som gör att det inte går att knyta MAC-adressen till någon som en personuppgift, med skillnaden att det går att följa användaren under en timmes tid med semi-anonymisering. Med full anonymisering går det endast att se att en enhet varit på plats. Det går alltså inte att följa enheten.
Orsaken till vi valt att använda minutintervall med full anonymisering är att ifall det är flera sensorer som överlappar varandra så ska användaren få samma hashade värde. På så sätt går det att räkna användaren som en och inte lika många som antalet sensorer registrerat.
I båda fallen går det inte att knyta MAC-adressen till en person men det går att med seminivå kunna se hur länge personen i fråga varit på plats. Med full anonymisering går det endast att se att det har varit en person på plats för datainsamlingen, det går inte att följa personens rörelsemönster.
Med endast SHA-1 finns det möjlighet till att erbjuda andra tjänster, dock krävs det att personen i fråga godkänner att denne kommer finnas med i en datalagring för att inte bryta mot PuL.
4.1.6 Sensorns funktioner
Sensorn fungerar som så att den startar sökningen efter Bluetooth-enheter i området kring sensorn (för räckvidd se kapitel 4.3.4, figur 11). Sökningen innebär att en inquiry scan startas och håller på i 10.24 sekunder sedan utförs en ”page scan”, se teoriavsnitt för mer detaljer om inquiry scan och page scan. Då en Bluetooth-enhet hittas så samlar sensorn in MAC-adressen, enhetens klass samt enhetens signalstyrka. Bluetooth klassen samlas in för att se vilka typer av enheter som finns på platsen. Klassen motsvarar ett binärt tal som returneras till sensorn från de upphittade enheterna. Mjukvaran jämför sedan dessa binära tal för varje upphittad enhet och kan sedan skriva ut vilken typ av enhet det är i användargränssnittet. De binära talen baseras på Major Service Class och Major Device Class som beskrivs i kapitel 3.1.1.
MAC-adressen hashas direkt efter insamlingen med de tre olika anonymiseringsnivåerna så den blir oigenkännbar. Sedan presenteras resultatet i en lista, dels den ursprungliga MAC-adressen och dels de tre olika hashkoderna samt enhetens klass och signalstyrkan. Denna information lagras automatiskt i databasen. Namnet på Bluetooth-enheten visas också, detta används dock inte senare. Se figur 12 och 13, bilaga B.1, för inläsningen av en surfplatta av modellen Asus Transformer TF300T. Inläsningen skedde vid två olika tillfällen (under två olika timmar).
Information om vilka enheter som finns lagrade i databasen går sedan att se i en separat lista. Det går att välja från vilken tabell som information ska läsas in. Figur 14, bilaga B.1, visar tabellen som innehåller full anonymisering. Figur 16, bilaga B.1, delvis anonymisering samt figur 18, bilaga B.1, endast anonymisering genom SHA-1.
Om användaren av sensorn sedan klickar på en av de hittade enheterna så kommer en lista med tider då applikationen senast hittade just den enheten. Se figur 15, 17 samt 19 i bilaga B.1.
Informationen som presenteras i listorna över hittade enheter är tid och datum då enheten hittades, hashkod och vilken klass av enhet som hittades.
4.2 Analys av säkerhet
4.2.1 Datakommunikation
I vårt system har vi inte fokuserat på säkerhet mer än att vad vi har tagit till fasta från intervju med Johan Gustavsson C.2. Sensorn skickar samt tar emot data till och från databasservern okrypterad. Om trafiken skulle avlyssnas så skulle det gå att läsa vad datapaketen innehåller men eftersom MAC-adressen är hashad så går det inte att se den i klartext.
En lösning hade varit att istället för att låta trafiken mellan sensor och databasserver gå över Hypertext Transfer Protocol (HTTP), använda Hypertext Transfer Protocol Secure (HTTPS). HTTPS använder till skillnad mot HTTP en krypterad kommunikation mellan enheterna, vilket innebär att data som skickas inte går att avläsa. Genom certifikat är det också möjligt med HTTPS att vara säker på att mottagaren av data verkligen är rätt mottagare [45].
Databasservern är inte mer säker än att den har standardanvändare med root-access vid mottagande och skickande av data genom PHP. Detta innebär att det är möjligt med hjälp av brute force att gissa sig fram till rätt lösenord [34].
Vidare så krävs det inte att sensorn loggar in på databasen utan PHP-scriptet innehåller användarnamn och lösenordet till databasen, detta gör att det skulle kunna vara möjligt att antingen radera tabellen eller hämta ut all data genom en SQL Injection-attack [46].
4.2.2 Testa hashat värde
För att testa hur säker en MAC-adress är, både när den endast är hashad med SHA-1 samt hashad enligt semi-anonymiseringsnivån, använde vi programmet oclHashcat [47]. Programmet körs på ett grafikkort och knäcker det hashade ordet genom en brute force-attack. Bild över användargränssnitten för programmet finns i bilaga B.2, figur 20. Programmet är utvecklat för att ta reda på det ursprungliga ordet som sedan blivit hashat och det klarar flera olika hashalgoritmer. Uträkningen går ut på att programmet hashar ett ord i vald algoritm (i vårt fall SHA-1) och sedan jämförs det resultatet som program-met fick ut med det hashade ordet som användaren vill knäcka. Stämmer inte ordet sker en ny matchning med ett nytt ord. De orden som hashas av programmet kan antingen vara ord som finns i en ordlista eller att programmet använder sig av en mask, det vill säga användaren instruerar hur det ursprungliga ordet är uppbyggt för programmet. Att använda sig utav en ordlista för MAC-adresser är inte möjligt i vårt fall, då den skulle behöva innehålla 248 adresser, det vill säga 281474976710656 stycken MAC-adresser. Vi har använt oss utav en mask istället, för både SHA-1 och semi-anonymisering. De masker vi har använt är Endast SHA-1:
-1 ?dABCDEF ?1?1:?1?1:?1?1:?1?1:?1?1:?1?1 (tecknet d står för siffror, 0-9) Semi-anonymisering:
-1 ?dABCDEF -2 ?d ?2?2?2?2?2?2?2?2?2?2?1?1:?1?1:?1?1:?1?1:?1?1:?1?1
Masken för anonymiseringsnivån bestående endast av SHA-1 är gjord som så att pro-grammet börjar med att sätta in tecknet 0 på platser där det står ?1, det vill säga oclHashcat testar att ordet 00:00:00:00:00:00 är det som har blivit hashat, för att sen gå vidare till 00:00:00:00:00:01, etc. ända fram tills programmet har kommit fram till
FF:FF:FF:FF:FF:FF. oclHashcat testar att i vårt fall sätta in 0-9 samt A-F på varje plats. Så fort programmet har kommit fram till rätt ord avslutas programmet och det rätta ordet sparas ner i en textfil på hårddisken.
Masken för semi-anonymisering är uppbyggd på samma sätt, med undantaget att masken har blivit utökad för att klara av saltet vi har adderat till MAC-adressen. Här har vi valt att låta programmet testa samma ursprungliga MAC-adress tillsammans med datumet och klockslaget, och då är det 0-9 som gäller för saltet (står som 2 i masken).
Programmet körs på en stationär dators grafikkort, detta då grafikkortet är utvecklat för att klara flera uträkningar parallellt. Det vill säga att istället för att låta datorns CPU utföra en uträkning, låta uträkningarna ske på grafikkortet istället (grafikkort är mycket bättre till parallelliserade uppgifter än CPU [48]. När oclHashcat ska knäcka vårt hashade ord kan programmet hålla en hastighet av 1.4 - 1.6 TH/s, det vill säga uppemot 1.6 miljarder hashvärden kontrolleras per sekund. Direkt när programmet startas att knäcka ett ord anges det hur lång tid det kommer ta att kontrollera alla varianter.
De hashade orden som vi har försökt få fram det ursprungliga ordet är samma som har använts i tabell 3, kapitel 4.1.5.
För att knäcka den hashade MAC-adressen tog det strax under 12 timmar på en PC, utrustad med ett grafikkort av AMD Radeon 6970. På figur 5 går det att se hur lång tid det beräknas att det ska ta att knäcka hashade ordet, 2 dygn. Vi kunde bekräfta att rätt MAC-adress hade hittats genom att läsa ut resultatet från textfilen. Figur 6 visar hur lång tid det tog. För att knäcka hashkoden av semi-anonymiseringsnivå skulle det kräva mer än 10 år med samma hårdvara (se figur 7). Full anonymisering har ännu mer tecken i saltet så den kommer ta längre tid, dock gick det ej att testa den då oclHashcat inte stöder längre ord att knäcka än semi-anonymiseringsnivån.
Figur 6: Knäckt.
Figur 7: Semi-anonymisering
4.3 Testning
4.3.1 Test av sensor
Testerna av sensorn gjordes för att dels se att sensorn kunde samla in MAC-adresser från närliggande enheter samt för att se antalet enheter som var igång och vilka typer av enheter som hittades. Enheten som agerade sensor var en LG Nexus 4 med Android version 5.0.2. Enheten är utrustad med Bluetooth klass 1 [49].
4.3.2 Malmö högskola
För att få en uppfattning om hur många enheter som hade Bluetooth aktiverat så tes-tade vi sensorn i Malmö högskolas lokaler på Östra Varvsgatan 11A i en undersökning. I omgivningen fanns 32 stycken studenter, dessa frågade vi om de hade Bluetooth eller WiFi igång. Se sammanställning över mobiltelefoners inställningar i figur 8. Samtidigt som frågorna ställdes så sökte vår sensor efter Bluetooth-enheter. Vår sensor hittade vid sökningarna sex bärbara datorer, en telefon samt en okategoriserad (uncategorized) en-het. För sammanställning över typer av enheter se figur 9. En av anledningarna till att ha Bluetooth aktiverat var för att dela sitt Internet trådlöst från sin mobiltelefon till sin bärbara dator.
Figur 9: Mätningar på Malmö högskola.
4.3.3 Malmö Central
Vi gjorde också mätningar på Malmö Central, bland annat nere vid spåren bland resenärer som väntade på ett tåg samt uppe bland butiker och caféer. Antalet människor på plats vid mätningarna rörde sig omkring 130-160 personer (vi har räknat med 155 personer för att ta fram andelen enheter). Totalt upptäcktes 20 Bluetooth-enheter. Se figur 10 för sammanställning över vilka enheter som hittades (i procent).
Figur 10: Mätningar på Malmö Central.
4.3.4 Avståndsmätning
Mätningar gjordes över hur signalstyrkan påverkas av ökat avstånd, för att bedöma nog-grannheten för sensorn. För att utföra testet användes en Apple iPhone 6 som hade Blue-tooth sökbart. Mobiltelefonen som agerade sensor var placerad på en EU-pall som stod på högkant, med 1.2 meters höjd. Telefonen som avståndet mättes till hölls i handen. Avstån-det från sensor till mobiltelefon var till en början 1 meter (för att se hur bra avläsningen är vid kort avstånd) för att sen vara på 3 meters avstånd. Därefter ökade vi avståndet med 3 meter hela tiden. Även här gjorde vi mätningar på Malmö högskolas lokaler på Östra Varvsgatan 11A. Mätningarna gjordes mellan vägg till vägg, det vill säga vi hade kunnat mäta över längre sträcka om det funnits utrymme. Ytan där vi mätte var i stort sett tom, enda som fanns i området var bord och stolar. Inga andra människor var på plats och därmed inga andra Bluetooth-enheter som störde ut mätningen. Sammanställning över testet finns i figur 11
Figur 11: RSSI/avstånd.
4.4 Validering
Systemet har testats under olika förutsättningar. Dels har vi testat med våra egna enheter, i bilaga B.1 visas hur sensorn har registrerat informationen från en surfplatta som varit i samma rum som sensorn (notera enligt beskrivning i kapitel 4.1.6). Surfplattan har haft inställningen att alltid vara sökbar i Bluetooth-inställningarna. Vi har även gjort mätningar på Malmö högskola samt Malmö Central (se kapitel 4.3.2 och 4.3.3). Vi har funnit att vår sensor kan hitta Bluetooth-enheter i omgivningen, dock måste enheten vara inställd i sökbart läge och inom ett avstånd av 100 meter (se kapitel 4.3.4).
Systemet testas även utifrån ett säkerhetsperspektiv. För att testa hur svårt det är att få ut originaltexten som var input till hashfunktionen använde vi programmet oclHashcat. Se kapitel 4.2.2 för mer detaljer om hur vi använde programmet.
5
Diskussion och slutsats
5.1 Insamlad dataInsamlad data hjälpte oss att dra slutsatser om huruvida bra Bluetooth skulle passa till att estimera antalet personer på en plats. Utifrån insamlingar som vi gjort på Malmö Central och Malmö högskola på fakulteten teknik och samhälle, så kan vi utläsa att de vanligaste enheterna var mobiltelefoner, surfplattor och bärbara datorer med Bluetooth aktiverat. Jämfört med studien som Kikuchi et al. (se kapitel 1.5.4) gjorde visade det sig att mobiltelefoner och datorer är de enheter som är definitivt vanligast. Genom att räkna antalet personer visuellt och sedan samla in MAC-adresser så kunde vi även dra slutsatsen att alla som har en enhet inte har Bluetooth igång. Att Bluetooth är så enkelt just att sätta igång och stänga av på olika enheter gör det möjligt att låta användaren själv välja ifall dennes MAC-adress tillåts att samlas in.
5.2 Känslig information
Vid insamling av MAC-adresser så upptäckte vi att en del förnamn användes som namn till enheten. Detta är ett problem ifall namnet skulle lagras i databasen för insamlad data. Att lagra GPS-koordinater för insamlingsenheter kan tillsammans med namn och MAC-adresser göra att data kan knytas till en person och därmed bli en personuppgift. Genom att veta platsen där en enhet hittas till exempel Malmö högskola så går det sedan att söka med sökorden namn och plats. På så sätt kan det vara möjligt att via sociala medier till exempel Facebook hitta denna person genom ett antal sökningar. Detta är liknade ett sätt som Evans et al. (se kapitel 1.5.5) använde fast de kopplade ihop insamlad data med en person med hjälp av universitets onlinekatalog.
En annan kombination av data som kan vara kränkande för den personliga integriteten är en kombination av MAC-adresser, GPS-koordinater och tid för insamling. Med dessa data så går det att hitta mönster i databasen där det lagras eftersom det går att se var en enhet befinner sig vid vilken tid och destination. Oavsett ifall MAC-adressen är hashad eller står i klartext så går detta mönster ändå att se. För att undvika det krävs det någon form av saltning.
5.3 Anonymisering
Beroende av vilken typ av tjänst som efterfrågas behöver det vara olika mycket saltning. Om tjänsten som efterfrågas enbart är att ha reda på hur många personer som befinner sig på plats är full anonymitetsnivå bäst. Då är saltet som läggs till aktuellt klockslag på minutnivå. Detta innebär att varje gång en MAC-adress läggs in i databasen är den unik (om inte samma MAC-adress registreras under samma minut). På så sätt går det att se antalet personer på plats men inte kunna knyta MAC-adressen till någon person som en form av personuppgift. För att ha ännu mer anonymitet är ett alternativ att ha en slumpning av vilken tid som MAC-adressen lagras, det vill säga lägga till några minuter före eller efter den verkliga tidpunkten (som Bumbee Labs, kapitel 1.5.8).
För att kunna se hur flödet är, hur länge individerna stannar kvar på samma plats, är det bäst att använda sig utav saltning med aktuell timme plus MAC-adressen. Då går det att se individens mönster under den aktuella timmen, nästa timme kommer individen att få ett nytt unikt värde sparat i databasen. Vad detta innebär är att det inte går att följa
individens rörelsemönster under en längre period utan endast under den aktuella timmen. Om det då har gått mer än en timme tills individen blir registrerad igen, kommer systemet inte känna till något om dennes tidigare rörelsemönster.
För att kunna se var varje individ befinner sig är det bäst att enbart använda en hashfunk-tion och inte salta. Då får individen alltid samma värde och det är då möjligt att koppla värde till person (annars går det inte att se vart individen befinner sig). Detta behöver dock godkännas av varje inblandad person (och denne ska ha möjligheten att lämna när denne önskar). Finns också större risk för att det är möjligt att spåra personens rörelser under en längre tid och kunna se mönster. Dock om tjänsten innebär kontinuitet, till ex-empel kunna erbjuda individen dennes schema när denne kommer in på sin arbetsplats eller andra i arbetslaget ska kunna se var individen befinner sig, måste denna nivå av anonymisering användas.
I teoriavsnittet 3.3 så nämndes det om andra SHA-varianter som har ett större antal bitar som hashkod. Detta gör att säkerheten blir starkare ifall någon av dem skulle väljas. Som det gick att se i kapitel 4.2.2 gick det relativt enkelt att knäcka den hashade MAC-adressen (utan salt), med starkare SHA-variant skulle det ta längre tid.
5.4 Metoddiskussion
Metoden som användes för detta arbete har fungerat detta arbete har uppfyllt våra be-hov, i att både ha kvantitativ och kvalitativ datainsamling. Information som kom från arbetsmöten, handledarmöten, intervju och informationssökningen har gjort att vi kunde utforma arbete och ta med relevanta saker. Vi kunde ha gjort ytterligare intervjuer om säkerhet, dock fick vi inte svar på förfrågningar om intervjuer förutom från Johan Gus-tavsson. Till den vetenskapliga metoden som varit bakom datainsamling så har mixed methodology fungerat bra eftersom vi kombinerat kvalitativ och kvantitativ data.
Utvecklingsarbetet över vårt system kunde gjorts enligt agile utveckling då vi delat upp de identifierade delproblemen i sprintar och arbetat efter det. Som vi arbetade nu var att vi hade ett tidschema (Gantt schema) där vi listat upp de olika delproblemen och sedan utifrån det så delade vi upp det jämnt mellan oss. Sedan arbetade vi mot en deadline då det skulle vara klart.
5.5 Slutsats
Avslutningsvis så har vi utvecklat ett proof of concept-system som kan samla in MAC-adresser och anonymisera dessa i tre olika nivåer. Dessa tre nivåer har olika säkerhetsnivåer varav den högsta anonymiseringsnivån har starkast säkerhet vilket visades under valide-ringen. Vi har även insett att Bluetooth är ett dåligt sätt för att estimera antalet personer som finns på en yta genom vår fältstudie och mätningar (kapitel 4.3.2 och 4.3.3). Orsaken är att folket inte har Bluetooth aktiverat och synligt. I vår mätning om avstånd fann vi att räckvidden för Bluetooth är anmärkningsvärt långt (kapitel 4.3.4). Om Bluetooth ska användas för att estimera antalet personer måste någon form av paketanalysator användas för att registrera trådlös trafik. Om en paketanalysator används eller om alla personer på en plats har Bluetooth igång och har satt sina enheter till att alltid vara upptäckbara skulle det kunna vara möjligt att identifiera fler Bluetooth-enheter. Bluetooth finns i flera enheter vilket vi märkt vid våra insamlingar. De vanligaste enheterna var surfplattor, mo-biltelefoner och datorer. Ett sätt att estimera antal personer kan vara genom att sortera
ut mobiltelefoner i sensorn och endast skicka över de enheternas data till databasen. Data-basen lagrar minimalt med data på så sätt att skulle någon komma åt den så är det svårt att knyta till en fysisk person. Eftersom inga GPS-koordinator eller namn på enheterna lagras så minskas risken för att kränka integritet.
5.6 Arbete i vidare sammanhang
Vid arbete i vidare sammanhang så hade det varit intressant att se vilka typer av tjänster som skulle kunna utvecklas beroende på olika anonymitetsnivåer.
Att undersöka och implementera en säker databas för datainsamling hade också kunnat vara en intressant frågeställning, där frågeställningarna hade varit att hur mycket data går att lagra för att inte kunna hitta olika mönster men samtidigt lagra användbar data. Software Defined Radio (SDR) hade varit intressant för att samla in data. SDR gör det möjligt att bevaka olika typer av signaler. SDR fungerar att köra på allt från vanliga datorer till mindre kraftfulla inbyggda system. Det hade därför varit intressant att testa möjligheterna om vad som går att samla in. Dock med SDR måste det finnas en analys av vilka datapaket det är som skickas, så det går att sortera ut paket från mobila enheter som bärs av individer från datapaket som är irrelevanta (till exempel datatrafik från flygplan).
En annan intressant problemställning är att hur ett det skulle vara att samla in data från en större plats genom att ha flera insamlingsenheter. Genom att ha flera insamlingsenheter så är det möjligt att se åt vilken riktning samt hastighet som individerna rör sig. Som till exempel BLIP Systems A/S (se kapitel 1.5) fast i detta fall så blir det med individer istället för bilar.
Referenser
[1] P. Suresh, J.V. Daniel, V. Parthasarathy, and R.H. Aswathy. A state of the art review on the Internet of Things (IoT) history, technology and fields of deployment. In Science Engineering and Management Research (ICSEMR), 2014 International Conference on, pages 1–8, Nov 2014.
[2] T. Nicolai and H. Kenn. About the Relationship Between People and Discoverable Bluetooth Devices in Urban Environments. In Proceedings of the 4th International Conference on Mobile Technology, Applications, and Systems and the 1st Internatio-nal Symposium on Computer Human Interaction in Mobile Technology, Mobility ’07, pages 72–78. ACM, 2007.
[3] Y. Yoshimura, S. Sobolevsky, and C. Ratti. An analysis of visitors’ behavior in The Louvre Museum: a study using Bluetooth data. In Environment and Planning B: Planning and Design, 41, pages 1113–1131, 2014.
[4] Y. H. Hwang. IoT Security #38; Privacy: Threats and Challenges. In Proceedings of the 1st ACM Workshop on IoT Privacy, Trust, and Security, IoTPTS ’15, pages 1–1, New York, NY, USA, 2015. ACM.
[5] H. Kikuchi and T. Yokomizo. Location Privacy Vulnerable from Bluetooth Devices. In Network-Based Information Systems (NBiS), 2013 16th International Conference on, pages 534–538, Sept 2013.
[6] D. Evans and R.H. Warren. Anonymity Properties of Stored or Transmitted Data Taken from Bluetooth Scans. In Computational Science and Engineering, 2009. CSE ’09. International Conference on, volume 3, pages 133–138, Aug 2009.
[7] J. Miller. City of London calls halt to smartphone tracking bins, August 12, 2013 (accessed March 31, 2015). http://www.bbc.com/news/technology-23665490/. [8] S. Datoo. This recycling bin is following you, August 12, 2013 (accessed March 31,
2015). http://qz.com/112873/this-recycling-bin-is-following-you/.
[9] V. Gillberg. Den nya mätbara staden, December 15, 2014 (accessed May 04, 2015. http://www.fastighetstidningen.se/den-nya%E2%80%A8-matbara-staden/. [10] BLIP Systems A/S. Blip Systems, 2015 (accessed April 02, 2015). http://
www.blipsystems.com/.
[11] BLIP Systems A/S. Swedish City Uses BlipTrack Technology To Ease Traffic, De-cember 13, 2013 (accessed April 02, 2015). http://www.blipsystems.com/swedish-city-uses-bliptrack-technology-to-ease-traffic/.
[12] H. Lin, W. Chu, T. Gong, Y. Ti, Y. Sun, J.H. Nielsen, and A. Naseem. Integra-ting BLIP into Location-Aware System: A Service-Oriented Method. In Computer Sciences and Convergence Information Technology, 2009. ICCIT ’09. Fourth Inter-national Conference on, pages 144–148, Nov 2009.
[13] Datainspektionen. Strukturerat eller ostrukturerat?, (accessed May 06, 2015). http://www.datainspektionen.se/lagar-och-regler/personuppgiftslagen/ strukturerat-eller-ostrukturerat/.
[14] Datainspektionen. Vad är en personuppgift?, (accessed May 06, 2015). http://www.datainspektionen.se/fragor-och-svar/personuppgiftslagen/ vad-ar-en-personuppgift/.
![Figur 2: Modell över Bluetooth-enheters uppkopplingsprocedur [30].](https://thumb-eu.123doks.com/thumbv2/5dokorg/4056251.83819/25.892.132.767.528.673/figur-modell-över-bluetooth-enheters-uppkopplingsprocedur.webp)
