1. No category

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 Datateknik och Mobil IT
Datum för slutseminarium: 2015-06-04
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 syftar 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 samlade 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
UHF – Ultra High Frequency
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 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Syfte och problemformulering . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Relaterat arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 About the relationship between people and discoverable Bluetooth
devices in urban environments . . . . . . . . . . . . . . . . . . . .
1.5.2 An analysis of visitors’ behavior in The Louvre Museum: a study
using Bluetooth data . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 IoT Security & Privacy: Threats and Challenges . . . . . . . . . .
1.5.4 Location Privacy Vulnerable from Bluetooth Devices . . . . . . . .
1.5.5 Anonymity properties of stored or transmitted data taken from Bluetooth scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6 Renew London . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.7 Bumbee Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8 BLIP Systems A/S, Integrating BLIP into Location-Aware System:
A Service-Oriented Method . . . . . . . . . . . . . . . . . . . . . .
1.6 Etik och lagar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Metod
2.1 Metodval . . . . .
2.2 Litteratursökning .
2.3 Utveckling av proof
2.4 Arbetsmöte . . . .
2.5 Intervju . . . . . .
2.6 Metodöversikt . . .
. . . . . . .
. . . . . . .
of concept
. . . . . . .
. . . . . . .
. . . . . . .
3 Teknisk bakgrund
3.1 Bluetooth . . . . . . . . .
3.1.1 Klassisk Bluetooth
3.1.2 MAC-adress . . . .
3.1.3 Uppkoppling . . .
3.1.4 BLE . . . . . . . .
3.2 Android . . . . . . . . . .
3.3 Hashfunktion . . . . . . .
3.4 Kryptering . . . . . . . .
3.5 MySQL . . . . . . . . . .
3.6 PHP . . . . . . . . . . . .
3.7 Linux . . . . . . . . . . .
3.8 Raspberry Pi . . . . . . .
4 Resultat
4.1 Proof
4.1.1
4.1.2
4.1.3
4.1.4
.
.
.
.
.
.
.
.
.
.
.
.
of concept . . . . . .
Utvecklingsmiljö . .
Android-applikation
Databas . . . . . . .
Systemöversikt . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
2
.
2
.
.
.
3
3
3
.
.
.
4
4
5
.
.
.
5
5
6
.
.
.
.
.
.
7
7
7
7
7
8
8
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
11
11
12
12
12
13
13
13
.
.
.
.
.
14
14
14
14
14
14
.
.
.
.
.
.
.
.
.
.
.
16
17
18
18
18
20
20
20
22
23
24
.
.
.
.
.
.
25
25
25
25
26
26
27
A Avnämare
A.1 Internet of Things and People . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Cooperative, Self-aware and Intelligent Surveillance Systems . . . . . . . . .
A.3 Arbetsmöte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
32
32
4.2
4.3
4.4
4.1.5 Anonymisering . . .
4.1.6 Sensorns funktioner
Analys av säkerhet . . . . .
4.2.1 Datakommunikation
4.2.2 Testa hashat värde .
Testning . . . . . . . . . . .
4.3.1 Test av sensor . . . .
4.3.2 Malmö högskola . .
4.3.3 Malmö Central . . .
4.3.4 Avståndsmätning . .
Validering . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
5 Diskussion och slutsats
5.1 Insamlad data . . . . . . . . .
5.2 Känslig information . . . . .
5.3 Anonymisering . . . . . . . .
5.4 Metoddiskussion . . . . . . .
5.5 Slutsats . . . . . . . . . . . .
5.6 Arbete i vidare sammanhang
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
D.1 Android . . . . . . . . . . . .
D.1.1 AnalyzeFragment.java
D.1.2 BluetoothDevices.java
D.1.3 DeviceAdapter.java . .
D.1.4 Devices.java . . . . . .
D.1.5 Display.java . . . . . .
D.1.6 DisplayAdapter.java .
D.1.7 DisplayFragment.java
D.1.8 HashMethods.java . .
D.1.9 MainActivity.java . . .
D.1.10 ScanBTFragment.java
D.1.11 StartFragment.java . .
D.1.12 AndroidManifest.xml .
D.2 MySQL . . . . . . . . . . . .
D.2.1 Skapande av tabeller .
D.3 PHP . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
44
46
49
50
51
52
53
57
58
59
63
65
66
66
67
D.3.1 get.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.3.2 insert.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1
Inledning
1.1
Bakgrund
Internet 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ätverkskameror. 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ändare 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änkande 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:
• Vilka säkerhetsaspekter finns det vid insamling och lagring?
1
• 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 sedan 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 devices 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
2
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 SHA1 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 IoTsystem. Det första som nämns i denna studie är E2E (end-to-end) Data Life-cycle Protection 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ändarna av IoT-system att förstå säkerheten bakom systemet. Användarna 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 egenutvecklad Bluetooth-scanner på campus och offentliga platser. Från de hittade Bluetoothenheterna 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
3
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 blivit 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 Bluetooth 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 Bluetoothenheten 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
4
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 WiFienheter 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 kommunens 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, finjustera 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 flygplats och fick bra resultat gällande att kunna detektera passagerare och personals mobiltelefoner, 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 personuppgifter 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
5
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.
6
2
2.1
Metod
Metodval
Metoden 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 deltagande i arbetsmöte med IOTAP (CoSiS).
Den kvantitativa datainsamlingen har bestått av att vi utvecklat en applikation till Androidenheter 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 vetenskapliga artiklar från databaser som IEEE (Institute of Electrical and Electronics Engineers) 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 programmering 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 databasservern 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 applikationen 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.
7
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.
Figur 1: Metodöversikt. Utveckling (heldragna linjer) och iterering (streckade linjer).
8
3
Teknisk bakgrund
3.1
3.1.1
Bluetooth
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 smartphones, 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 mobiltelefoner 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 överfö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 hexadecimala 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.
9
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.
12
0
0
0
0
0
0
0
0
0
0
1
X
Tabell
11
0
0
0
0
0
0
0
0
1
1
1
X
2: Tabell
10 9
0
0
0
0
0
1
0
1
1
0
1
0
1
1
1
1
0
0
0
0
1
1
X X
som visar vilka olika typer av Bluetooth-enheter det kan finnas.
8 Major Device Class
0 Miscellaneous
1 Computer (desktop, notebook, PDA, organizer, . . . )
0 Phone (cellular, cordless, pay phone, modem, . . . )
1 LAN /Network Access point
0 Audio/Video (headset, speaker, stereo, video display, VCR, . . . )
1 Peripheral (mouse, joystick, keyboard, . . . )
0 Imaging (printer, scanner, camera, display, . . . )
1 Wearable
0 Toy
1 Health
1 Uncategorized: device code not specified
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 standardläge som kallas för uppkopplingsläge och väntelä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
10
(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å kommunikation 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 skapa kommunikation mellan enheterna eller gå tillbaka till 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å dataö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 energifö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, telefoner, 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].
11
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). Plattformen LAMP gör det möjligt att på ett enkelt sätt sätta upp en webbserver på en Linuxdator
[37].
1
Metod 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].
12
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äldigt 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].
13
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 tidigare 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 phpMyAdmin.
4.1.2
Android-applikation
De API:er som används för Bluetooth är BluetoothAdapter, BluetoothClass samt BluetoothDevice.
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ätverkskommunikation, 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 Androids 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 databasen 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 (MACadress, 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 information 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.
14
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 information 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örande Bluetooth-enheten (tidpunkt, RSSI, klass samt 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 Bluetoothenheten. 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.
15
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 integriteten 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örsta 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 olika 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
MAC-adress och timmen då den blev insamlad. I tabell 3 finns output för samma MACadress 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 hashfunktionen. 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
Full anonymisering
Semi-anonymisering
Endast SHA-1
Input
201505042116AA:BB:CC:DD:EE:FF
2015050421AA:BB:CC:DD:EE:FF
AA:BB:CC:DD:EE:FF
Output
ab5d6a6c67f1767bbd2741aa2cbe31ed26cad42f
16d046b738e8d6d632040eb422d89fca10b97ea4
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 tillsam16
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.
17
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 forceattack. 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 programmet 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 programmet 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
18
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 5: Starten av att knäcka det hashade värdet.
19
Figur 6: Knäckt.
Figur 7: Semi-anonymisering
4.3
4.3.1
Testning
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å testade 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) enhet. 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.
20
Figur 8: Mätningar på Malmö högskola.
21
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).
22
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 noggrannheten för sensorn. För att utföra testet användes en Apple iPhone 6 som hade Bluetooth 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åndet 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
23
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.
24
5
5.1
Diskussion och slutsats
Insamlad data
Insamlad 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 MACadresser 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
25
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 hashfunktion 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 exempel 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 behov, 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 Gustavsson. 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 MACadresser 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 valideringen. 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, mobiltelefoner och datorer. Ett sätt att estimera antal personer kan vara genom att sortera
26
ut mobiltelefoner i sensorn och endast skicka över de enheternas data till databasen. Databasen 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.
27
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 International 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).
www.blipsystems.com/.
http://
[11] BLIP Systems A/S. Swedish City Uses BlipTrack Technology To Ease Traffic, December 13, 2013 (accessed April 02, 2015). http://www.blipsystems.com/swedishcity-uses-bliptrack-technology-to-ease-traffic/.
[12] H. Lin, W. Chu, T. Gong, Y. Ti, Y. Sun, J.H. Nielsen, and A. Naseem. Integrating BLIP into Location-Aware System: A Service-Oriented Method. In Computer
Sciences and Convergence Information Technology, 2009. ICCIT ’09. Fourth International 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/.
28
[15] K. Lagerwall.
Datainspektionen ska granska övervakning via mobilen, January 23, 2015 (accessed May 04, 2015). http://www.dn.se/nyheter/sverige/
datainspektionen-ska-granska-overvakning-via-mobilen/.
[16] Datainspektionen. Vad menas med samtycke enligt personuppgiftslagen och hur
ska det se ut?, (accessed May 06, 2015). http://www.datainspektionen.se/
fragor-och-svar/personuppgiftslagen/vad-menas-med-samtycke-enligtpersonuppgiftslagen-och-hur-ska-det-se-ut-1/.
[17] J. Ryberg. Svenska tekniken som spårar dig på stan, January 28, 2015 (accessed May
04, 2015). http://www.idg.se/2.1085/1.606293/svenska-tekniken-som-sparardig-pa-stan.
[18] J. W. Creswell. Research Design: Qualitative, Quantitative and Mixed Methods. SAGE
Publications, 2014.
[19] A. Leff and J.T. Rayfield. Web-application development using the Model/View/Controller design pattern. In Enterprise Distributed Object Computing Conference, 2001.
EDOC ’01. Proceedings. Fifth IEEE International, pages 118–127, 2001.
[20] Bluetooth SIG. Welcome to Bluetooth Technology 101 - A brief tutorial on Bluetooth wireless technology, 2015 (accessed May 05, 2015). http://www.bluetooth.com/
Pages/Fast-Facts.aspx.
[21] Bluetooth SIG. Bluetooth Basics, 2015 (accessed April 01, 2015). http://http:
//www.bluetooth.com/Pages/Basics.aspx.
[22] J.I.N. Hipolito, N.C. Arballo, J.A. Michel-Macarty, and E.J. Garcia. Bluetooth Performance Analysis in Wireless Personal Area Networks. In Electronics, Robotics and
Automotive Mechanics Conference, 2009. CERMA ’09., pages 38–43, Sept 2009.
[23] E. Firmansyah, L. Grezelda, and Iswandi. RSSI based analysis of Bluetooth implementation for intra-car sensor monitoring. In Information Technology and Electrical
Engineering (ICITEE), 2014 6th International Conference on, pages 1–5, Oct 2014.
[24] R. Bouhenguel, I. Mahgoub, and M. Ilyas. Bluetooth Security in Wearable Computing
Applications. In High Capacity Optical Networks and Enabling Technologies, 2008.
HONET 2008. International Symposium on, pages 182–186, Nov 2008.
[25] A. Vaha-Sipila and T. Virtanen. BT-Crowds: Crowds-Style Anonymity with Bluetooth and Java. In System Sciences, 2005. HICSS ’05. Proceedings of the 38th Annual
Hawaii International Conference on, pages 320a–320a, Jan 2005.
[26] M. Johansson. Restidsuppskattningar med hjälp av Bluetoothdata. Bachelor thesis,
Linköpings universitet, Linköping, 2014.
[27] Bluetooth SIG.
Baseband, 2015 (accessed April 01, 2015).
https://
www.bluetooth.org/en-us/specification/assigned-numbers/baseband/.
[28] W. Stallings. Wireless Communications & Networks, Second Edition. Pearson Prentice Hall, 2004.
R Core Specification 4.2, 2014.
[29] Bluetooth SIG. Bluetooth
[30] E Bhaskar, A Chung. Fundamental understanding on the use of Bluetooth scanner
as a complementary transport data. Transportation Research Part C : Emerging
Technology, (37):42–72, 2013.
29
[31] Bluetooth SIG. The Low Energy Technology Behind Bluetooth Smart, 2015 (accessed
April 01, 2015). http://www.bluetooth.com/Pages/low-energy-tech-info.aspx/.
[32] Android. Android, the world’s most popular mobile platform, 2015 (accessed May 07,
2015). http://developer.android.com/about/index.html/.
[33] A.A. Putri Ratna, P. Dewi Purnamasari, A. Shaugi, and M. Salman. Analysis and
comparison of MD5 and SHA-1 algorithm implementation in Simple-O authentication
based security system. In QiR (Quality in Research), 2013 International Conference
on, pages 99–104, June 2013.
[34] M. Rouse. What is brute force cracking?, (accessed April 15, 2015). http://
searchsecurity.techtarget.com/definition/brute-force-cracking/.
[35] W. Penard och T. van Werkhoven. On the Secure Hash Algorithm, (accessed May
08, 2015). http://www.staff.science.uu.nl/~werkh108/docs/study/Y5_07_08/
infocry/project/Cryp08.pdf/.
[36] S. Chandra, S. Paira, S.S. Alam, and G. Sanyal. A comparative survey of Symmetric
and Asymmetric Key Cryptography. In Electronics,Communication and Computational Engineering (ICECCE), 2014 International Conference on, pages 83–93, Nov
2014.
[37] Oracle. What is MySQL, (accessed April 08, 2015). https://dev.mysql.com/doc/
refman/4.1/en/what-is-mysql.html/.
[38] The PHP Group. What is PHP, (accessed May 08, 2015). http://php.net/manual/
en/intro-whatis.php/.
[39] The Linux Foundation. What is Linux, (accessed April 08, 2015).
www.linuxfoundation.org/what-is-linux/.
http://
[40] Raspberry Pi Foundation. What is a Raspberry Pi?, (accessed April 08, 2015). http:
//www.raspberrypi.org/help/what-is-a-raspberry-pi/.
[41] Raspberry Pi Foundation. Setting up an Apache web server on a Raspberry Pi,
(accessed April 08, 2015). http://www.raspberrypi.org/documentation/remoteaccess/web-server/apache.md/.
[42] Android.
Bluetooth Low Energy, (accessed May 07, 2015).
https://
developer.android.com/guide/topics/connectivity/bluetooth-le.html/.
[43] SQLite. Appropriate Uses For SQLite, (accessed May 07, 2015).
www.sqlite.org/whentouse.html/.
https://
[44] SQLite. SQLite Is Serverless, (accessed May 07, 2015). https://www.sqlite.org/
serverless.html/.
[45] M. Rouse. What is HTTPS (HTTP over SSL or HTTP Secure), August, 2008(accessed May 18, 2015). http://searchsoftwarequality.techtarget.com/definition/
HTTPS/.
[46] S. Venom.
HIOB: WebSite Hacking Series Part 1: Hacking WebSites Using
SQL Injection, (accessed May 18, 2015). http://null-byte.wonderhowto.com/
forum/hiob-website-hacking-series-part-1-hacking-websites-using-sqlinjection-error-based-0158949/.
30
[47] hashcat. hashcat, (accessed May 06, 2015). http://hashcat.net/wiki/doku.php?id=
frequently_asked_questions/.
[48] S. Music. Grafikkort till parallella beräkningar. Bachelor thesis, Malmö högskola,
Malmö, 2012.
[49] T-Mobile. Tech specs: Google Nexus 4, December 31, 2014 (accessed June 13, 2015).
https://support.t-mobile.com/docs/DOC-5032/.
[50] Malmö högskola. This is IOTAP, (accessed March 26, 2015). http://iotap.mah.se/
about/.
[51] Malmö högskola. Cooperative, Self-aware and Intelligent Surveillance Systems – CoSIS, (accessed March 26, 2015). http://iotap.mah.se/cosis/.
31
Bilagor
A
A.1
Avnämare
Internet of Things and People
IOTAP är ett forskningscenter som drivs av Malmö högskola. IOTAPs fokus ligger på
forskning kring hur användare kan interagera med anslutna enheter, hur användare 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 [50].
A.2
Cooperative, Self-aware and Intelligent Surveillance Systems
Malmö högskola, Axis Communications, Sigma Connectivity samt Sigma Technology är
intressenterna av ett projekt inom IOTAP, CoSIS. Syftet med CoSIS är att komplettera
till exempel kamerabilder med data från olika mobila enheter (till exempel Bluetooth
och WiFi). Denna data kan användas till olika syften, exempelvis se genomströmning
av personer i ett rum och uppskatta antalet personer på en större yta så som ett torg.
CoSIS syfte är inte bara att förbättra systemen från ett övervakningsperspektiv men också
för att utveckla system för att stödja tjänster med andra ändamål i den offentliga och
halvoffentliga miljön, såsom fastighetsförvaltning och aktivitetsloggning [51].
A.3
Arbetsmöte
Under våren deltog vi under två arbetsmöte med representanter från Malmö högskola,
Axis Communications, Sigma Connectivity samt Sigma Technology. Under dessa möten
framgick det att CoSIS skulle utveckla system för att räkna antal personer i det offentliga
rummet genom nämnda personers mobila enheter (datainsamling genom Bluetooth). Då
detta är ett område som kan vara integritetskränkande så behövs det forskning om hur
datainsamling kan skydda individer samtidigt som datainsamlingen kan stödja CoSIS
önskemål. Önskemålen kan vara att antingen styra en byggnads ventilationsystem eller
användare ska kunna få feedback från lokaler, om det finns plats eller om alla borden i
lokalen är fulla. Då krävs det en möjlighet att räkna antalet personer men vem personerna
är behöver inte kännas till. Samtidigt så fanns det diskussioner om huruvida det är möjligt
att när en individ kommer in på kontoret automatiskt bli igenkänd av systemet och kunna
få sitt schema visat på närliggande sensorer eller medlemmar i individens arbetsgrupp
ska veta var individen är. Då måste systemet känna till vilken mobil enhet som tillhör
vem.
Av ovan nämnda önskemål kunde vi utläsa vissa krav, det var att det skulle utvecklas ett
system som kunde hantera anonymisering samt att vi skulle få utveckla ett system som
samlade in information via Bluetooth.
32
B
B.1
Bilder
Android-applikation
Figur 12: Insamling av Bluetooth-enheter före nästa timme.
Figur 13: Insamling av Bluetooth-enheter efter nästa timme.
33
Figur 14: Visning av helt anonymiserade Bluetooth-enheter.
Figur 15: Information över en vald enhet.
34
Figur 16: Visning av delvis helt anonymiserade Bluetooth-enheter.
Figur 17: Information över en vald enhet.
35
Figur 18: Visning av Bluetooth-enheter endast anonymiserade av SHA-1.
Figur 19: Information över en vald enhet.
36
B.2
oclHashcat
Figur 20: GUI för oclHashcat
37
B.3
Databas
Figur 21: Databas via phpMyAdmin.
38
C
Intervju
C.1
Intervjufrågor
Intervjufrågorna användes för att ha diskussionsgrund.
1. Hur går det att se insamlingen på ett etiskt sätt?
2. Bör personer bli meddelade om deras enheter är med i ett system för datainsamling?
3. Om ja, borde du kan välja att du ska raderas från systemet efter önskemål eller ska
du kunna göra ett aktiv val med att t.ex. stänga av WiFi eller Bluetooth?
4. Vem bör ansvaret ligga på för att inte kränka integritet? Den som samlar in data
eller den som blir ”insamlad” (aktivt stänga av när enheterna inte ska användas)?
5. Bör staten få reglera vad som ska samlas in eller inte?
6. Hur ”farligt” anser du det var att samla in MAC-adresser från olika mobila enheter?
7. Vilka data anser du inte borde få samlas in i ett offentligt rum?
8. Vilken kombination av data tror du kan kränka en individs integritet?
9. Kränks den personliga integriteten om en jobbtelefon spåras medan en person har
den på sig?
10. Hur går det att ”designa” en databas för att kunna undvika att obehöriga kan
samköra data för att ”skada” någon? (Men databasen ska även gå att använda för
olika sorters tjänster)
39
C.2
Referat
Intervju med: Johan Gustavsson, universitetsadjunkt på Institutionen för Datavetenskap på Malmö högskola.
Ämne: Datainsamling, PuL, anonymisering av data och den etiska synen på insamling
av data
Ansvariga: Mattias Nilsson, Sebastian Olsson.
Datum intervju: 2015-04-27
Datum transkribering av intervju 2015-04-28
Johan: När jag läser frågorna finns det en uppenbar sak som slår mig med en och kopplar
in till fråga två, tre och fyra, bör personer bli meddelade om de är med i ett system för
datainsamling och vem bör ansvaret ligga på för att inte kränka integriteten, så kan vi
börja med att titta på personuppgiftslagen. Den är baserad på ett EU-direktiv så vi är
bundna av det även utanför Sveriges gränser. Personuppgiftslagen är väldigt tydlig i att
du får inte behandla personuppgifter, i vilket även innefattar att samla in dom samt att
du får inte samla in dom utan personens uttryckliga tillåtelse. Det är otillåtet att samla
in personuppgifter om du inte har fått ett otvetydigt godkännande av personen. Så att
svaret på fråga fyra är att lagen säger att det är den insamlade som är skyldig att bevara
integriteten här och personerna måste bli meddelade. Du får inte samla in information
utan den person vars information blir insamlad är medveten om det och har godkänt det
och känner till vad informationen används till. Du måste ha ett informerat, personligt
otvetydigt samtycke från personen i fråga.
Om vi tittar på andra sammanhang där stora mängder data samlas in går det att se
hur till exempel Amazon, Facebook eller liknande har gjort, då sker det ett godkännande
i samband med att man skapar sitt konto på tjänsten. Du kan inte kräva som kund hos
Amazon att sina uppgifter inte samlas in därför jag har aktivt valt att skapa konto här,
det innebär också att jag accepterar dom villkor som följer med det. Men det innebär att
du inte kan på samma sätt, när du bara rör dig i en offentlig miljö, ha anses ha gett ditt
godkännande. Det finns ett steg av aktivt godkännande som måste finnas med, för varje
enskild person som finns med. Det går inte att ta det för en hel grupp. Vi kan inte säga
generellt säga i den här miljön så kommer du att bli registrerad. Den typen av personlig
information måste godkännas av varje individ, med ett informerat samtycke. Enligt PuL
och motsvarande EU-direktiv som det baseras på finns det en väldigt tydlig gräns för vad
som är möjligt.
Mattias: Men om man då helt har anonymiserat uppgifterna, då borde det väl vara
ok?
Johan: Men hur skulle du helt anonymisera uppgifterna, menar du?
Mattias: Låt säga att du har MAC-adressen, så hashar du den tillsammans med aktuell timestamp, så vid nästa tillfällen du läser av den kommer du få ett nytt värde. Så
du kommer aldrig få att personen har samma värde från gång till gång utan hela tiden nya.
Johan: Då kan du inte svara på frågan är det samma personen som är kvar.
Mattias: Nä precis. Då blir det mer personen som är här nu, så då blir det ett mer
högre perspektiv.
40
Johan: Precis, då är det en fråga om nivåer. Också en fråga om problem med modern
datainsamling. Det är nuförtiden lättare att, om man ska uttrycka det så, att samla in.
Vi måste anstränga oss för att avidentifiera informationen snarare än tvärtom. Skulle vi
gjort det här för 20 år sen, då skulle vi haft en person med räknare som räknade varje
besökare med en räknare. Nu är vi 25 personer här inne". En timme senare, Nu är vi 32".
Skulle den här personen då försöka ta reda på vilka det var då skulle han vara tvungen
att gå och fråga alla vilket skulle vara lite ansträngande. Medan nuförtiden är det lättare
att samla in MAC-adresser och MAC-adresser är väldigt lättidentifierbara.
Där ligger en skillnad i att nuförtiden måste vi anstränga oss ganska aktivt. Jag ser att
fråga 3 här, du ska kunna välja att radera från systemet efter önskemål, det ingår också
i PUL att du måste ha möjlighet att säga nej, du är inte med längre. Du måste först ha
aktivt godkänt och sen kan du närsomhelst säga Nu vill jag inte vara med längre". Man
kan använda den information som är insamlad fram till dess men inte efteråt.
Sebastian: Hur fungerar det om det är en tredje part inblandad som har hand om både
insamling och lagring av data?
Johan: Ska vi vara säkra på att ha en säker integritet då innebär det att vi måste göra den
här hashningen direkt i sensorn. Så att den information som lagras inte är identifierbar.
Det här är något som, här finns en fråga som säger att, hur farligt är det att samla in
MAC-adresser. Det är något som är intressant, för det här hänger ihop med diskussioner
om metadata vid telefonsamtal, trafikdata, som i princip handlar om vilket telefonnummer
har ringt till vilket annat telefonnummer när.
Sebastian: Det nya datalagringsdirektivet?
Johan: Precis. Där säger man att det handlar inte om vad man pratar om utan om
vem som ringt till vem vid vilket tillfälle.
Givet en stor mängd information är det ganska lätt att se mönster, även om man har
vad som man kan tänka sig vara en anonym siffra som en MAC-adress. En MAC-adress
skulle vara typexempel på sådant som inte är med i ett sökbart register som ett telefonnummer är men ändå så har vi sett att så länge vi kan se att den är knuten till mig och via
den kan följa ett mönster så krävs det inte särskilt mycket för att med offentliga resurser
konstatera att det här är du.
Johan: Fråga sex till åtta hänger ihop, här finns en aspekt till som inte finns med i
själva ordet av att vi registrerar MAC-adressen. I det här ligger också att vi registrerar
position, vi talar om att personen är här, vilket också är en vidare effekt av det här. Men
om du har den på något sätt så du får ett unikt, identifierbart nummer för den här enheten
vare sig det är en hash, MAC eller telefonnummer, så länge den här är unik över tid så
kan du följa den här personens vanor och spåra den.
Det här hänger ihop med sådana frågor som vad är det som är grejen med den personliga integriteten här. Det beror i mångt och mycket på vem som tittar och hur länge.
Det finns det klassiska argumentet, har man bara rent mjöl i påsen-argumentet, om du
inte gör något dumt så är det ingen fara. Dock finns det ganska många situationer där
man kan ha rent mjöl i påsen utan att för den skull vara ofarligt att registrera var man
41
är.
Den generella visdomen för hur man ser till att sköta system att de inte blir sårbara
är att hålla koll på dom ordentligt, uppdatera dom så snart det kommer ut buggrapport,
se till att hålla brandväggar och liknande och det där är hanterbart när vi har en central
server som vi hanterar. Men när vi har 200 enheter utspridda över stan som kommunicerar
när någon kommer i närheten av dom och dessutom kör på hårdvara som inte är oerhört
kraftig, då finns det ett problem både i uppdaterbarheten och kontrollen över de här systemen. Om det nu dessutom de här kommunicerar med varandra på olika vis räcker det att
en av de här fallerar så har vi en väg in. Modern information är väldigt lätt att spara och
väldigt lätt att flytta. Det är lättare att samla in personlig information än avpersonifiera
information nuförtiden.
Sebastian: Angående fråga nio, jobbtelefoner.
Johan: Det är en fråga man kan ställa sig. I mitt fall, jobbtelefonen har jag på mig
mest hela tiden eftersom den numera är mobil. Det innebär ju att jag har den på mig när
jag går hem. Det är inte orimligt att tänka att arbetsgivaren vill spåra mitt användande av jobbtelefonen på samma sätt som man anser att arbetsgivaren har rätt att spåra
mitt datoranvändande under arbetstid därför att arbetsgivaren har ett intresse av att jag
faktiskt jobbar och inte bara sitter och surfar och ringer privatsamtal. Så där finns det
en aspekt att arbetsgivaren har ett sådant intresse och kan tänkas sig ha intresse av att
jag befinner mig åtminstone i arbetslokalerna i varje fall under arbetstid. Det finns en
personuppgiftsansvarig på min arbetsplats som är skyldig att se till att den informationen
inte sprids utanför HR-avdelningens system.
Sebastian: Om man tänker i ett större perspektiv, istället för att man kollar MACadressen på din mobil så är det jobbtelefonen, men det är fortfarande inte du personligen.
Johan: Fast en personuppgift är en uppgift som kan knytas till en person. Är det min
jobbtelefon och vi kan anta att det är jag som bär den, jag kanske tom är skyldig till
att hålla koll på vem som bär den enligt mitt avtal med arbetsgivaren, då är det också
en personuppgift. En personuppgift är vilken uppgift som gör att vi kan knyta tillbaka
till dig som person. Om man tar en bild, över till exempel centralstationen och det körs
face recognition-teknik för att identifiera vilka personer som är där, då är bildmaterialet
personuppgifter.
Mattias: Om fråga 10, databas?
Johan: På 10, om databas, om vi ska strikt designa en databas då måste vi se till att
vi inte kan spåra den här individen. Det vill säga att vi aldrig får ha en osaltade MACadressen. Då måste vi ha ett sätt att säga att ja, vi har här en hash som innefattar MAC
och tid och för att det här ska fungera, kan vi ha till exempel MAC och timme. Då kan
vi räkna på och följa personer på stationen under en timme så då får vi användbarhet.
Det innebär att sen när den här personen blir siktad på en annan station när de varit och
ätit lunch har de en annan lunch och då kan man inte följa de dit. Då måste vi komma
till en nivå att data som lagras i databasen inte är individualiserbar. Då måste vi göra
hashningen redan i sensorn så data som hamnar i databasen inte är möjlig att återför till
individuella enheter. Det är naturligtvis trivialt att säga att vi har data i databasen och
sen när den presenteras är den avidentifierad. Alternativet är ju man måste se till att fråga
42
varje enskild person för annars har du personuppgifter.
Mattias: Om man skulle ha en app, där man antingen ställer upp frivilligt eller får
något i utbyte, där man har installerat appen på telefonen. Då kan man ha att ska du
vara med måste du godkänna. Då kan man göra vad man vill?
Johan: Inte helt och hållet vad du vill. Dels måste du tala om vad du ska använda datan
till i villkoren och får inte använda till annat och dessutom finns det begränsningar i vilka
data du får samla in. Har du särskilt känsligt data du vill samla in måste du ändå ha ett
godkännande av datainspektionen. Särskilt känslig information innefattar möjlighet att ta
reda på politisk inriktning, sexuell läggning, religion och lite annat som är kritiskt. Men
den typen av appar har vi idag, i form av turfing-appar. Det är en fråga om datainsamling
för reklam, det är det som är syftet med hela grejen. Vi gör ett spel där vi ska följa var ni
går hela dagarna. Finns det en baktanke? Ja kanske. . .
43
D
Källkod
D.1
D.1.1
Android
AnalyzeFragment.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
import
import
android.os.Bundle;
android.app.Fragment;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.ArrayAdapter;
android.widget.ListView;
android.widget.TextView;
import java.util.ArrayList;
/**
* Contains logic for showing when a specific device have been scanned.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class AnalyzeFragment extends Fragment {
private String hash;
private String device;
private ArrayList<String> time;
public AnalyzeFragment() {
// Required empty public constructor
}
/* Sets up the fragment. When the fragment is launched from DisplayFragment,
arguments
* are sent from that fragment to this fragment.
*/
public static AnalyzeFragment newInstance(String hash, String device,
ArrayList<String> time){
AnalyzeFragment fragment = new AnalyzeFragment();
Bundle args = new Bundle();
args.putString("Hash", hash);
args.putString("Device", device);
args.putStringArrayList("Time", time);
fragment.setArguments(args);
return fragment;
}
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(getArguments() != null){
hash = getArguments().getString("Hash");
device = getArguments().getString("Device");
time = getArguments().getStringArrayList("Time");
}
44
}
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// Inflate the layout for this fragment
View view = inflater.inflate(R.layout.fragment_analyze, container, false);
TextView textView = (TextView) view.findViewById(R.id.textViewAnalyze);
textView.setText("The device with the hashed MAC-address " + hash +
"\nthat is a Bluetooth device of class " + device +
" has been at this location at these times:");
ListView listView = (ListView) view.findViewById(R.id.listViewAnalyze);
ArrayAdapter<String> arrayAdapter = new ArrayAdapter<String>
(getActivity(), android.R.layout.simple_list_item_1, time);
listView.setAdapter(arrayAdapter);
return view;
}
}
45
D.1.2
BluetoothDevices.java
package bluetooth.exjobb.com.findbt;
/**
* Returns the Bluetooth class of found device.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class BluetoothDevices {
public static String DeviceClass(int input){
switch (input){
//Values below come from
//developer.android.com/reference/android/bluetooth/BluetoothClass.Device.html
case 1076:
return "AUDIO_VIDEO_CAMCORDER";
case 1056:
return "AUDIO_VIDEO_CAR_AUDIO";
case 1032:
return "AUDIO_VIDEO_HANDSFREE";
case 1048:
return "AUDIO_VIDEO_HEADPHONES";
case 1064:
return "AUDIO_VIDEO_HIFI_AUDIO";
case 1044:
return "AUDIO_VIDEO_LOUDSPEAKER";
case 1040:
return "AUDIO_VIDEO_MICROPHONE";
case 1052:
return "AUDIO_VIDEO_PORTABLE_AUDIO";
case 1060:
return "AUDIO_VIDEO_SET_TOP_BOX";
case 1024:
return "AUDIO_VIDEO_UNCATEGORIZED";
case 1068:
return "AUDIO_VIDEO_VCR";
case 1072:
return "AUDIO_VIDEO_VIDEO_CAMERA";
case 1088:
return "AUDIO_VIDEO_VIDEO_CONFERENCING";
case 1084:
return "AUDIO_VIDEO_VIDEO_DISPLAY_AND_LOUDSPEAKER";
case 1096:
return "AUDIO_VIDEO_VIDEO_GAMING_TOY";
case 1080:
return "AUDIO_VIDEO_VIDEO_MONITOR";
case 1028:
return "AUDIO_VIDEO_WEARABLE_HEADSET";
case 260:
return "COMPUTER_DESKTOP";
case 272:
return "COMPUTER_HANDHELD_PC_PDA";
case 268:
return "COMPUTER_LAPTOP";
case 276:
return "COMPUTER_PALM_SIZE_PC_PDA";
case 264:
46
return
case 256:
return
case 280:
return
case 2308:
return
case 2332:
return
case 2320:
return
case 2324:
return
case 2328:
return
case 2312:
return
case 2304:
return
case 2316:
return
case 516:
return
case 520:
return
case 532:
return
case 528:
return
case 524:
return
case 512:
return
case 2064:
return
case 2060:
return
case 2068:
return
case 2052:
return
case 2048:
return
case 2056:
return
case 1812:
return
case 1808:
return
case 1804:
return
case 1800:
return
case 1792:
return
case 1796:
return
"COMPUTER_SERVER";
"COMPUTER_UNCATEGORIZED";
"COMPUTER_WEARABLE";
"HEALTH_BLOOD_PRESSURE";
"HEALTH_DATA_DISPLAY";
"HEALTH_GLUCOSE";
"HEALTH_PULSE_OXIMETER";
"HEALTH_PULSE_RATE";
"HEALTH_THERMOMETER";
"HEALTH_UNCATEGORIZED";
"HEALTH_WEIGHING";
"PHONE_CELLULAR";
"PHONE_CORDLESS";
"PHONE_ISDN";
"PHONE_MODEM_OR_GATEWAY";
"PHONE_SMART";
"PHONE_UNCATEGORIZED";
"TOY_CONTROLLER";
"TOY_DOLL_ACTION_FIGURE";
"TOY_GAME";
"TOY_ROBOT";
"TOY_UNCATEGORIZED";
"TOY_VEHICLE";
"WEARABLE_GLASSES";
"WEARABLE_HELMET";
"WEARABLE_JACKET";
"WEARABLE_PAGER";
"WEARABLE_UNCATEGORIZED";
"WEARABLE_WRIST_WATCH";
47
//Values below comes from
//developer.android.com/reference/android/bluetooth/BluetoothClass.Device.Major.html
case 1536:
return "IMAGING";
case 0:
return "MISC";
case 768:
return "NETWORKING";
case 1280:
return "PERIPHERAL";
case 7936:
return "UNCATEGORIZED";
default:
return null;
}
}
}
48
D.1.3
DeviceAdapter.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
android.content.Context;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.ArrayAdapter;
android.widget.TextView;
import java.util.ArrayList;
/**
* Modified adapter to show found devices on the scan.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class DeviceAdapter extends ArrayAdapter<Devices> {
public DeviceAdapter(Context context, ArrayList<Devices>devices) {
super(context, 0,devices);
}
public View getView(int position, View convertView, ViewGroup parent){
Devices devices = getItem(position);
if (convertView == null) {
convertView =
LayoutInflater.from(getContext()).inflate(R.layout.devices,
parent, false);
}
TextView textViewMAC = (TextView)convertView.findViewById(R.id.tvMAC);
TextView textRSSI = (TextView)convertView.findViewById(R.id.tvRSSI);
TextView textClass = (TextView)convertView.findViewById(R.id.tvClass);
TextView textViewType = (TextView)convertView.findViewById(R.id.tvType);
TextView textViewHashFull =
(TextView)convertView.findViewById(R.id.tvHashFull);
TextView textViewHashSemi =
(TextView)convertView.findViewById(R.id.tvHashSemi);
TextView textViewHashNo =
(TextView)convertView.findViewById(R.id.tvHashNo);
textViewMAC.setText("MAC-address is: " + devices.macAddress);
textRSSI.setText("RSSI: " + devices.RSSI + " dBm");
textViewType.setText("Name of Bluetooth-device: " + devices.type);
textClass.setText("Class: " + devices.BTclass);
textViewHashFull.setText("Full anonymization: " + devices.hashFull);
textViewHashSemi.setText("Semi anonymization: " + devices.hashSemi);
textViewHashNo.setText("Only SHA-1: " + devices.hashNo);
return convertView;
}
}
49
D.1.4
Devices.java
package bluetooth.exjobb.com.findbt;
/**
* Stores the found Bluetooth device as an object.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class Devices {
public String macAddress;
public String type;
public String hashFull;
public String hashSemi;
public String hashNo;
public int RSSI;
public String BTclass;
public Devices(String type, String macAddress, String hashFull, String
hashSemi, String hashNo,
int RSSI, String BTclass){
this.type = type;
this.macAddress = macAddress;
this.hashFull = hashFull;
this.hashSemi = hashSemi;
this.hashNo = hashNo;
this.RSSI = RSSI;
this.BTclass = BTclass;
}
public String getMacAddress(){
return macAddress;
}
}
50
D.1.5
Display.java
package bluetooth.exjobb.com.findbt;
/**
* Stores data about a Bluetooth device (data from database).
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class Display {
public String timeStamp;
public String hashedMAC;
public String deviceClass;
public int RSSI;
public Display(String timeStamp, String hashedMAC, String deviceClass, int
RSSI){
this.timeStamp = timeStamp;
this.hashedMAC = hashedMAC;
this.deviceClass = deviceClass;
this.RSSI = RSSI;
}
}
51
D.1.6
DisplayAdapter.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
android.content.Context;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.ArrayAdapter;
android.widget.TextView;
import java.util.ArrayList;
/**
* Modified adapter to show devices from database.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class DisplayAdapter extends ArrayAdapter<Display> {
public DisplayAdapter(Context context, ArrayList<Display>display) {
super(context, 0,display);
}
public View getView(int position, View convertView, ViewGroup parent){
Display display = getItem(position);
if (convertView == null) {
convertView =
LayoutInflater.from(getContext()).inflate(R.layout.display,
parent, false);
}
TextView textViewTime = (TextView)convertView.findViewById(R.id.tvTime);
TextView textViewHashed =
(TextView)convertView.findViewById(R.id.tvHashed);
TextView textViewDevice =
(TextView)convertView.findViewById(R.id.tvDevice);
TextView textViewRSSI =
(TextView)convertView.findViewById(R.id.tvDisplayRSSI);
textViewTime.setText(display.timeStamp);
textViewHashed.setText(display.hashedMAC);
textViewDevice.setText(display.deviceClass);
textViewRSSI.setText("RSSI: " + display.RSSI + " dBm");
return convertView;
}
}
52
D.1.7
DisplayFragment.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
import
import
import
import
import
import
android.app.FragmentTransaction;
android.os.AsyncTask;
android.os.Bundle;
android.app.Fragment;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.AdapterView;
android.widget.Button;
android.widget.ListView;
android.widget.RadioGroup;
android.widget.Toast;
import
import
import
import
import
import
import
java.io.BufferedReader;
java.io.IOException;
java.io.InputStreamReader;
java.net.URL;
java.net.URLConnection;
java.util.ArrayList;
java.util.concurrent.ExecutionException;
/**
* Fragment that fetches Bluetooth devices from database and displays them in a
list.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class DisplayFragment extends Fragment implements View.OnClickListener{
private
private
private
private
private
private
private
private
private
private
private
private
String link = "http:// /get.php"; //URL to database.
String radioButtonResult = "";
ArrayList<String> time;
ArrayList<Integer> RSSI;
ArrayList<String> deviceClass;
ArrayList<String> hashFull;
ArrayList<String> hashSemi;
ArrayList<String> hashNo;
ArrayList<String> hash;
ArrayList<Display> arrayListDisplay;
DisplayAdapter displayAdapter;
ListView devicesList;
public DisplayFragment() {
// Required empty public constructor
}
/*
* Sets up the fragment.
*/
public static DisplayFragment newInstance() {
DisplayFragment fragment = new DisplayFragment();
return fragment;
}
53
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// Inflate the layout for this fragment
View view = inflater.inflate(R.layout.fragment_display, container, false);
arrayListDisplay = new ArrayList<Display>();
displayAdapter=new DisplayAdapter(getActivity(),arrayListDisplay);
devicesList = (ListView) view.findViewById(R.id.listViewDisplay);
devicesList.setAdapter(displayAdapter);
time = new ArrayList<String>();
RSSI = new ArrayList<Integer>();
deviceClass = new ArrayList<String>();
hashFull = new ArrayList<String>();
hashSemi = new ArrayList<String>();
hashNo = new ArrayList<String>();
hash = new ArrayList<String>();
Button displayButton = (Button) view.findViewById(R.id.buttonDisplay);
displayButton.setOnClickListener(this);
/*
* Selects which anonymization-level to show in list.
*/
RadioGroup radioGroupDisplay = (RadioGroup)
view.findViewById(R.id.radioGroupDisplay);
radioGroupDisplay.setOnCheckedChangeListener(new
RadioGroup.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(RadioGroup group, int checkedId) {
switch (checkedId) {
case R.id.radioButtonFullAnonDisplay:
radioButtonResult = "FullAnon";
break;
case R.id.radioButtonSemiAnonDisplay:
radioButtonResult = "SemiAnon";
break;
case R.id.radioButtonNoAnonDisplay:
radioButtonResult = "NoAnon";
break;
}
}
});
/*
* Sends the device to AnalyzeFragment.
*/
devicesList.setOnItemClickListener(new AdapterView.OnItemClickListener() {
@Override
public void onItemClick(AdapterView<?> parent, View view, int
position, long id) {
int split = 0;
if(radioButtonResult.equals("FullAnon")){
split = 20;
} else if(radioButtonResult.equals("SemiAnon")){
split = 20;
} else if(radioButtonResult.equals("NoAnon")){
split = 12;
54
}
AnalyzeFragment fragment =
AnalyzeFragment.newInstance(hash.get(position).
substring(split), deviceClass.get(position).substring(7),
getTimeFromPosition(position));
FragmentTransaction transaction =
getFragmentManager().beginTransaction();
transaction.replace(R.id.container_main, fragment);
transaction.addToBackStack("Analyze");
transaction.commit();
}
});
return view;
}
@Override
public void onClick(View view) {
switch (view.getId()) {
case R.id.buttonDisplay:
display();
}
}
/*
* Logic for splitting the stream from database and display devices in list.
*/
private void display(){
if (radioButtonResult.equals("")){
Toast.makeText(getActivity(), "Select a hash method",
Toast.LENGTH_SHORT).show();
}
else{
ArrayList<String> result;
displayAdapter.clear();
int j = 0;
try {
result = new GetAsyncTask().execute().get();
time = new ArrayList<String>(result.size()-1);
RSSI = new ArrayList<Integer>(result.size()-1);
deviceClass = new ArrayList<String>(result.size()-1);
hashFull = new ArrayList<String>(result.size()-1);
hashSemi = new ArrayList<String>(result.size()-1);
hashNo = new ArrayList<String>(result.size()-1);
if(!result.contains("0 results")) {
for (int i = 0; i < result.size()-1; i++) {
String[] parts = result.get(i).split(";");
time.add(parts[0]);
RSSI.add(Integer.parseInt(parts[1].substring(6)));
deviceClass.add(parts[2]);
hashFull.add(parts[3]);
hashSemi.add(parts[4]);
hashNo.add(parts[5]);
j++;
}
if(radioButtonResult.equals("FullAnon")){
hash = new ArrayList<String>(hashFull);
} else if(radioButtonResult.equals("SemiAnon")){
55
hash = new ArrayList<String>(hashSemi);
} else if(radioButtonResult.equals("NoAnon")){
hash = new ArrayList<String>(hashNo);
}
for (int i = 0; i < j; i++) {
displayAdapter.add(new Display(time.get(i), hash.get(i),
deviceClass.get(i),
RSSI.get(i)));
}
}
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
}
/*
* Gets all the time that selected device have been scanned.
*/
private ArrayList<String> getTimeFromPosition(int pos){
String hashdev = hash.get(pos);
ArrayList<String> res = new ArrayList<String>();
for (int i = 0; i < hash.size(); i++){
if(hashdev.equals(hash.get(i))){
res.add(time.get(i));
}
}
return res;
}
/*
* Gets data from database.
*/
class GetAsyncTask extends AsyncTask<String, String, ArrayList<String>> {
@Override
protected ArrayList<String> doInBackground(String... arg0) {
ArrayList<String> devicesArray = new ArrayList<String>();
int i = 0;
URL urlObj = null;
try {
urlObj = new URL(link);
URLConnection lu = urlObj.openConnection();
BufferedReader rd = new BufferedReader(new
InputStreamReader(lu.getInputStream()));
String line = "";
while ((line = rd.readLine()) != null) {
devicesArray.add(line);
}
} catch (IOException e) {
e.printStackTrace();
}
return devicesArray;
}
}
}
56
D.1.8
HashMethods.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
java.math.BigInteger;
java.security.MessageDigest;
java.security.NoSuchAlgorithmException;
java.text.SimpleDateFormat;
java.util.Date;
/**
* Contains methods to hash a MAC-address and returns the current time.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class HashMethods {
/*
* Hashes a string to SHA-1.
*/
public static String hashMethodSHA_1 (String mac) {
MessageDigest md = null;
try {
md = MessageDigest.getInstance("SHA-1");
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
md.update(mac.getBytes(), 0, mac.length());
String sha_1 = new BigInteger(1, md.digest()).toString(16);
while (sha_1.length() < 32) {
sha_1 = "0" + sha_1;
}
return sha_1;
}
/*
* Return current time (hour of day) as well as the date.
*/
public static String currentHour(){
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMMddHH");
Date curentTime = new Date();
return dateFormat.format(curentTime);
}
/*
* Return current time (hour and minute) as well as the date.
*/
public static String currentMinute(){
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMMddHHmm");
Date curentTime = new Date();
return dateFormat.format(curentTime);
}
}
57
D.1.9
MainActivity.java
package bluetooth.exjobb.com.findbt;
import android.app.Activity;
import android.os.Bundle;
/**
* Launches the fragment StartFragment once the application starts.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
getFragmentManager().beginTransaction().replace(R.id.container_main,
StartFragment.newInstance(), "Start").commit();
}
@Override
public void onDestroy() {
super.onDestroy();
}
}
58
D.1.10
ScanBTFragment.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
android.bluetooth.BluetoothAdapter;
android.bluetooth.BluetoothClass;
android.bluetooth.BluetoothDevice;
android.content.BroadcastReceiver;
android.content.Context;
android.content.Intent;
android.content.IntentFilter;
android.os.AsyncTask;
android.os.Bundle;
android.app.Fragment;
android.util.Log;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.Button;
android.widget.ListView;
android.widget.Toast;
import
import
import
import
import
import
import
org.apache.http.HttpResponse;
org.apache.http.NameValuePair;
org.apache.http.client.HttpClient;
org.apache.http.client.entity.UrlEncodedFormEntity;
org.apache.http.client.methods.HttpPost;
org.apache.http.impl.client.DefaultHttpClient;
org.apache.http.message.BasicNameValuePair;
import java.util.ArrayList;
/**
* Fragment that scans Bluetooth devices, displays them in a list and sends the
data to database.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class ScanBTFragment extends Fragment implements View.OnClickListener{
private
private
private
private
private
private
private
private
final static int REQUEST_ENABLE_BT = 1;
BluetoothAdapter mBlueAdapter;
ListView listView;
ArrayList<Devices> arrayListDevices;
DeviceAdapter deviceAdapter;
String resultHashFull, resultHashSemi, resultHashNo, resultClass;
int RSSI;
String link = "http:// /insert.php"; //URL to database.
public ScanBTFragment() {
// Required empty public constructor
}
/*
* Sets up the fragment.
*/
public static ScanBTFragment newInstance() {
ScanBTFragment fragment = new ScanBTFragment();
59
return fragment;
}
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_scan_bt, container, false);
arrayListDevices = new ArrayList<Devices>();
deviceAdapter = new DeviceAdapter(getActivity(),arrayListDevices);
listView = (ListView) view.findViewById(R.id.listViewDevices);
listView.setAdapter(deviceAdapter);
mBlueAdapter = BluetoothAdapter.getDefaultAdapter();
if(mBlueAdapter==null){
Toast.makeText(getActivity(), "This device do not have Bluetooth",
Toast.LENGTH_SHORT).show();
}
if (!mBlueAdapter.isEnabled()) { //returns false if BT is not enabled
///Creates dialog for turning on Bluetooth
Intent enableBtIntent = new
Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
}
Button searchButton = (Button) view.findViewById(R.id.buttonSearch);
searchButton.setOnClickListener(this);
return view;
}
public void onClick(View view){
switch (view.getId()) {
case R.id.buttonSearch:
scan();
break;
}
}
@Override
public void onDestroy() {
super.onDestroy();
getActivity().unregisterReceiver(mReceiver);
}
/*
* Starts the scanning of Bluetooth devices.
*/
public void scan(){
Toast.makeText(getActivity(), "Starting search for BT devices",
Toast.LENGTH_SHORT).show();
deviceAdapter.clear();
arrayListDevices = new ArrayList<Devices>();
mBlueAdapter.startDiscovery();
}
/*
* Sends Bluetooth devices to database.
*/
class PostAsyncTask extends AsyncTask<Void, Void, Boolean> {
60
@Override
protected Boolean doInBackground(Void... params) {
HttpClient httpclient = new DefaultHttpClient();
HttpPost httppost = new HttpPost(link);
try {
ArrayList<NameValuePair> nameValuePairsFull = new
ArrayList<NameValuePair>(6);
nameValuePairsFull.add(new BasicNameValuePair("time",
HashMethods.currentMinute()));
nameValuePairsFull.add(new BasicNameValuePair("RSSI",
String.valueOf(RSSI)));
nameValuePairsFull.add(new BasicNameValuePair("resultClass",
resultClass));
nameValuePairsFull.add(new BasicNameValuePair("resultFull",
resultHashFull));
nameValuePairsFull.add(new BasicNameValuePair("resultSemi",
resultHashSemi));
nameValuePairsFull.add(new BasicNameValuePair("resultNo",
resultHashNo));
httppost.setEntity(new UrlEncodedFormEntity(nameValuePairsFull));
HttpResponse response = httpclient.execute(httppost);
}
catch(Exception e)
{
Log.e("log_tag", "Error: " + e.toString());
}
return null;
}
}
@Override
public void onResume() {
super.onResume();
// Register the BroadcastReceiver
IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND);
getActivity().registerReceiver(mReceiver, filter); // Unregister in
onDestroy
}
/*
* Scans Bluetooth devices, adds the found device to list and database.
*/
private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
// When discovery finds a device
if (BluetoothDevice.ACTION_FOUND.equals(action)) {
// Get the BluetoothDevice object from the Intent
BluetoothDevice device =
intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
BluetoothClass
btClass=intent.getParcelableExtra(BluetoothDevice.EXTRA_CLASS);
boolean found = true;
int i = 0;
/*
* Checks that found Bluetooth device not have been found earlier
on same scan.
61
*/
do{
if (arrayListDevices.size() == 0){
found = false;
}
else {
if
(device.getAddress().equals(arrayListDevices.get(i).getMacAddress())){
found = true;
break;
} else{
found = false;
}
}
i++;
}while (i < arrayListDevices.size());
/*
* Hashes found device, shows the device in list and sends it to
database.
*/
if(!found){
resultClass =
BluetoothDevices.DeviceClass(btClass.getDeviceClass());
RSSI = intent.getShortExtra(device.EXTRA_RSSI,
Short.MIN_VALUE);
resultHashFull = HashMethods.hashMethodSHA_1
(HashMethods.currentMinute() + device.getAddress());
resultHashSemi = HashMethods.hashMethodSHA_1
(HashMethods.currentHour() + device.getAddress());
resultHashNo = HashMethods.hashMethodSHA_1
(device.getAddress());
new PostAsyncTask().execute((Void) null);
deviceAdapter.add(new Devices(device.getName(),
device.getAddress(),
resultHashFull, resultHashSemi, resultHashNo, RSSI,
resultClass));
arrayListDevices.add(new Devices(device.getName(),
device.getAddress(),
resultHashFull, resultHashSemi, resultHashNo, RSSI,
resultClass));
}
}
}
};
}
62
D.1.11
StartFragment.java
package bluetooth.exjobb.com.findbt;
import
import
import
import
import
import
android.os.Bundle;
android.app.Fragment;
android.view.LayoutInflater;
android.view.View;
android.view.ViewGroup;
android.widget.Button;
/**
* Simple fragment that lets the user select whether to search for Bluetooth
devices or show
* devices from the database by launching the fragment for that task.
* Created by Mattias Nilsson & Sebastian Olsson
*/
public class StartFragment extends Fragment implements View.OnClickListener{
View view;
public StartFragment() {
// Required empty public constructor
}
/*
* Sets up the fragment.
*/
public static StartFragment newInstance() {
StartFragment fragment = new StartFragment();
return fragment;
}
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// Inflate the layout for this fragment
view = inflater.inflate(R.layout.fragment_start, container, false);
Button scan = (Button) view.findViewById(R.id.buttonScan);
scan.setOnClickListener(this);
Button display = (Button) view.findViewById(R.id.buttonDisplay);
display.setOnClickListener(this);
return view;
}
@Override
public void onClick(View view){
switch (view.getId()){
case R.id.buttonScan:
getFragmentManager().beginTransaction().replace(R.id.container_main,
ScanBTFragment.newInstance(),
"Scan").addToBackStack("Scan").commit();
break;
case R.id.buttonDisplay:
getFragmentManager().beginTransaction().replace(R.id.container_main,
DisplayFragment.newInstance(),
"Display").addToBackStack("Disp").commit();
break;
63
}
}
}
64
D.1.12
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="bluetooth.exjobb.com.findbt" >
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.INTERNET"/>
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name="bluetooth.exjobb.com.findbt.MainActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
65
D.2
D.2.1
MySQL
Skapande av tabeller
CREATE TABLE collectedBT(
id INT NOT NULL AUTO_INCREMENT,
time VARCHAR(100) NOT NULL,
RSSI INT NOT NULL,
resultClass VARCHAR(100) NOT NULL,
resultFullAnon VARCHAR(100) NOT NULL,
resultSemiAnon VARCHAR(100) NOT NULL,
resultNoAnon VARCHAR(100) NOT NULL,
PRIMARY KEY (id)
);
66
D.3
D.3.1
PHP
get.php
<?php
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "hash";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
$sql = "SELECT * FROM collectedBT";
$result = $conn->query($sql);
if ($result->num_rows > 0) {
// output data of each row
while($row = $result->fetch_assoc()) {
echo "Time: " . $row["time"]. ";RSSI: " . $row["RSSI"]
. ";Class: ". $row["resultClass"] . ";Full Anonymization: " .
$row["resultFullAnon"] . ";Semi Anonymization: " .
$row["resultSemiAnon"] . ";Only SHA-1: " . $row["resultNoAnon"].
"\n";
}
} else {
echo "0 results";
}
$conn->close();
?>
67
D.3.2
insert.php
<?php
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "hash";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn -> connect_error){
die("Connection failed: " .$conn->connect_error);
}
$time = mysqli_real_escape_string ($conn, $_POST[’time’]);
$RSSI = mysqli_real_escape_string ($conn, $_POST[’RSSI’]);
$resultClass = mysqli_real_escape_string ($conn, $_POST[’resultClass’]);
$resultFull = mysqli_real_escape_string ($conn, $_POST[’resultFull’]);
$resultSemi = mysqli_real_escape_string ($conn, $_POST[’resultSemi’]);
$resultNo = mysqli_real_escape_string ($conn, $_POST[’resultNo’]);
$sql = "INSERT INTO collectedBT (time, RSSI, resultClass, resultFullAnon,
resultSemiAnon, resultNoAnon)
VALUES (’$time’, ’$RSSI’, ’$resultClass’, ’$resultFull’, ’$resultSemi’,
’$resultNo’)";
if ($conn->query($sql) == TRUE) {
echo "New record created successfully";
} else {
echo "Error: " .$sql . "<br>" .$conn->error;
}
$conn->close();
?>
68