Mikael Danielsson
Dokumenttyp – Datateknik GR (C), Examensarbete Huvudområde: Datateknik
Högskolepoäng: 15 hp Termin, år: Vår, 2020
Handledare: Martin Kjellqvist, martin.kjellqvist@miun.se Examinator: Dr. Ulf Jennehag, ulf.jennehag@miun.se Utbildningsprogram: Datateknik, 180 hp
Sammanfattning
I dagens samhälle, särskilt efter bland annat allt som rapporterades av Ed- ward Snowden när han under 2013 påvisade hur USAs NSA jobbade med global övervakning, är det av stor vikt av att kommunikation bör hållas säker. Säker både på så sätt att innehållet i meddelanden skyddas från oön- skade personer och på så sätt att meddelandens autenticitet kan styrkas. Det är minst lika viktigt att veta vem man kommunicerar med som att veta att ingen obehörig kan läsa material som inte är ämnat för dem. Vi ser fler och fler lösningar som till exempel Let’s Encrypt som erbjuder gratis kryptering av webbtrafik men när det gäller just SMS-trafik finns inte lika många och effektiva lösningar.
Syftet med det här arbetet är att utveckla ett system för att undersöka hur man på bästa sätt skulle kunna behandla SMS på ett säkert och autentis- erat sätt. Målet är att, till skillnad mot många andra lösningar, inte vara beroende av en tredje part utan istället nyttja det befintliga SMS-protokollet men se till att innehållet är krypterat med hjälp av public key cryptography.
Detta leder till att det räcker att använda applikationen för att kunna kom- municera säkert, det finns ingen central server som skulle kunna stängas ner eller på andra sätt påverkas för att försämra kommunikationens säker- het. Vi får också ett system som är mycket mindre beroende av mobildata och blir därför mer flexibelt i områden där dessa kan vara kostsamma eller svåråtkomliga. Utöver detta kommer ett system för extern autentisering av nycklar undersökas. Även om detta, om avsändaren väljer att utnyttja det, kommer att kräva tillgång till mobil datatrafik så skulle det vara ett nyttigt verktyg för att kunna autentisera kommunikation med personer som man aldrig tidigare varit kontakt med då dessa i så fall kan publicera sin nyckel online och sedan hänvisa till den i meddelandet. Exempel på användning för detta är om en myndighet behöver gå ut med information till medbor- garna; då kan denna nyckel publiceras på dess webbsida så att alla enkelt kan kontrollera den (målet är i så fall att detta skall ske automatiskt under hämtning av ett meddelande).
Keywords: Android, Kryptering, SMS, Public Key Kryptografi, Nyckel- hantering, Autentisering
Abstract
In today’s society, especially after everything that was reported by Edward Snowden when he, during 2013, showed how USA’s NSA worked with global surveillance, there is a great need to keep communication secure. Se- cure both in such a way that the contents in messages are protected from unwanted parties as well as in such a way that messages’ authenticity can be verified. It’s just as important to know who one is communicating with as it is to know that no unauthorized person can read material not meant for them. We see more and more solutions like for instance Let’s Encrypt that offer free encryption for web traffic but when it actually comes to SMS traffic there aren’t as many effective options available.
The purpose of this work is to develop a system to examine how one most effectively could treat SMS in a secure and authenticated fashion. The goal is to, contrary to many other solutions, not be dependent upon a third party but rather utilize the existing SMS protocol and to make sure that the con- tents is encrypted by use of public key cryptography. This leads to it being enough to use the application to be able to communicate securely as there would be no central server that could be closed down or in other ways af- fected to lessen the security of the communication. We also get a system that is much less dependent on mobile data and will thus become more flexible in areas where this can be costly or hard to reach. Beyond this a system for verification of external keys will be explored. Even if it, in case the user chooses to use it, will need access to mobile data, it could be a useful tool for authentication of communication with parties with whom one has not been in contact with before since they can publish their public key and then refer to it within the message. An example use case for this would be a gov- ernment needing to publish information to its citizens; then this key can be published on their web site so that anyone easily could verify it (the goal is to have this be done automatically during message retrieval).
Keywords:Android, Encryption, SMS, Public Key Cryptography, Key man- agement, Authentication
Förord
Jag skulle vilja tacka följande personer och företag:
• Min handlerare på Mittuniversitetet; Martin Kjellqvist som löpande guidat mig och hjälpt mig strukturera upp mitt arbetsflöde.
• Min handledare på Dewire; Sebastian Försth som ständigt funnits till- gänglig för assistans vid behov även om jag till stor del varit självgående.
• Dewire som företag och Johanna Edström som trott på mig tillräckligt för att anställa mig redan innan examensarbetet var färdigställt.
Abstract ii
Förord iii
Terminologi vi
1 Introduktion 1
1.1 Bakgrund och problemmotivering . . . 1
1.2 Övergripande syfte . . . 2
1.3 Avgränsningar . . . 2
1.4 Konkreta och verifierbara mål . . . 3
1.5 Översikt . . . 3
1.6 Författarens bidrag . . . 4
2 Teori 5 2.1 Språk . . . 5
2.2 IDE / Arbetsmiljö . . . 5
2.3 Kryptografi . . . 5
2.3.1 Nyckelgenerering . . . 6
2.3.2 Kryptering / Dekryptering . . . 6
3 Metod 7 3.1 Enkätundersökning . . . 7
3.2 Utveckling . . . 8
3.3 Symmetrisk kryptografi . . . 8
3.4 Asymmetrisk kryptografi . . . 9
3.5 Strukturering . . . 9
3.5.1 Must have . . . 9
3.5.2 Should have . . . 10
3.5.3 Could have . . . 10
3.6 Androidapplikation. . . 10
4 Konstruktion 12 4.1 MainActivity . . . 12
4.2 ContactDatabaseReader . . . 12
4.3 MessageDatabaseReader . . . 12
4.4 Message . . . 13
4.5 MessageComparator . . . 13
4.6 DataStorage . . . 13
4.7 KeyManager . . . 13
4.8 SmsBroadcastReceiver . . . 14
4.10 Fragments till MainActivity . . . 15
4.10.1 HomeFragment . . . 16
4.10.2 KeyManagement . . . 16
4.10.3 Settings. . . 16
4.11 ConversationItemview. . . 16
4.12 MessageItemView . . . 17
4.13 ChatActivity. . . 17
4.14 ComposeActivity . . . 17
5 Resultat 19 5.1 Friskrivningsklausul . . . 19
5.2 Jämförelse . . . 19
5.3 Enkätsvar . . . 21
5.4 Kostnad . . . 21
5.5 Vidare forskning . . . 22
6 Slutsats 24 6.1 Enkäten . . . 24
6.2 Metoddiskussion . . . 25
6.3 Etiska aspekter . . . 25
Källförteckning 27 A Bilaga A 1 A.1 Resultat från enkät . . . 1
A.2 Varför använder du krypterad kommunikation? . . . 3
A.3 Varför använder du inte krypterad kommunikation? . . . 4
A.4 Övriga synpunkter från enkäten . . . 4
Terminologi
SMS Short Message Service (textmeddelanden)
MMS Multimedia Messaging Service (multimediameddelanden) RSA En krypteringsalgorithm
Activity En del av en Androidapplikation Fragment En underdel av en Androidapplikation
IDE Integrated development environment (Utvecklingsmiljö) URL Uniform Resource Locator (webbaddress)
Header Startinformation i ett meddelande Footer Avslutande del i ett meddelande
1 Introduktion
Det här arbetet undersöker möjligheten att med hjälp av public key cryptog- raphy skydda innehållet i de meddelanden som skickas som vanliga SMS via mobilnätet. Närmare bestämt kommer detta att ske med hjälp av PKCS
#1 (RSA-kryptografi) [1]. Det finns andra lösningar för att skicka krypterade meddelanden men de kräver i så fall att man behöver vara beroende av en tredje part. Här ska istället innehållet i den befintliga trafiken krypteras och signeras för att kunna erbjuda ett sätt att både säkra innehållet och autentis- era avsändare utan att mobiloperatörer eller andra aktörer ska kunna läsa detta. Detta är ett arbete som gjorts tillsammans med Dewire i Sundsvall.
1.1 Bakgrund och problemmotivering
Vi lever i ett samhälle där mer och mer kommunikation sker online, både vardaglig kommunikation mellan vänner och bekanta och mer formell kom- munikation så som betalande av räkningar samt myndighetsinformation.
Detta leder till att gemene man nu är van och bekväm vid att sköta mer och mer av sin kommunikation online. Dock har det också uppdagats, till exem- pel tack vare Edward Snowden [2], hur mycket av detta som faktiskt över- vakas och till vilken utsträckning detta även görs utan grund i existerande lagstiftning. Även om man kan argumentera för att övervakning bara görs i brottsförebyggande eller brottsbekämpande syfte går det även att argu- mentera för att det alltid finns en fara med sådan övervakning. Många an- vänder argumentet att de inte har någonting att dölja men skulle kanske ändå inte vara bekväm med liknelsen att någon hela tiden tittar över deras axel när de sitter vid en dator och läser det som skrivs. Vad gör man i så fall om man inte är bekväm med detta? Det finns i dagsläget andra verktyg som erbjuder vissa lösningar. När det gäller webbtrafik har Let’s Encrypt [3] låtit allt fler skydda trafiken till sina webbsidor via gratis certifikat och när det gäller meddelandetjänster är ett av de mest framstående Signal [4]
som utvecklas av Open Whisper Systems. De gör ett mycket bra jobb men för att använda deras tjänster krävs det att man litar på dem och är bekväm med att alla meddelanden går via deras servrar. Det finns i dagsläget in- genting som tyder på att man inte skulle kunna lita på dem men det här arbetet är menat att undersöka vilka möjligheter det finns att istället vara helt oberoende av företags eller organisationers servrar och inte heller be- höva använda sig av datatrafik då detta kan vara besvärande i områden med dålig täckning eller där detta kan vara kostsamt. Om vi dessutom utvecklar denna lösning med öppen källkod så låter vi andra själva inspek- tera koden för att kunna ta ställning till om det är något de är villiga att lita på samt även göra egna applikationer men som då ändå är kompatibla att kommunicera med varandra.
Utöver detta kan man, efter att studerat den officiella specifikationen för SMS [5], konstatera att det inte finns något inbyggt stöd för kryptering av meddelandeinnhållet. Detta gör att det i teorin inte är något som hindrar mobiloperatörer att komma åt innehållet i sina kunders SMS. Detta kan så klart variera beroende på hur olika operatörer jobbar och vilket samarbete de har med myndigheterna i sitt land. För att en operatör (på ett något någorlunda enkelt sätt) ska kunna läsa alla SMS krävs det att de har en in- frastruktur uppbyggd för att stödja detta genom att lagra alla meddelanden som passerar deras system. Detta är något som snabbt kräver en hel del la- gringsutrymmen och förmodligen inte görs om man inte måste. Exakt hur olika operatörer jobbar med detta är lite svårt att veta då det skulle röra sig om känsliga uppgifter för obehöriga. Efter ett samtal med en av de större mobiloperatörerna i Sverige fick jag detta bekräftat. De kunde säga att det inte var så lätt som att bara läsa sina kunders SMS men fick inte gå in på mer detalj än så då det var skyddade uppgifter. Dock kan man konstatera att om en operatör har för avsikt (antingen självständigt eller på begäran av en myndighet) att analysera texten i alla SMS som passerar deras system så finns det i teorin ingenting som stoppar dem och inte heller något som slutanvändaren skulle bli varse. Vi vet även att en del länder jobbar aktivt med censur inom sina egna gränser. Till exempel är Kina kända för att ak- tivt kontrollera vad deras invånare ska kunna se online och kommunicera om [6] och det är därför inte orimligt att tro att SMS i dessa länder i större utsträckning aktivt analyseras.
1.2 Övergripande syfte
Syftet med projektet är att undersöka hur man bäst säkrar innehållet i befintlig SMS-trafik. Detta kommer att undersökas genom att:
• Undersöka inställning hos folk i allmänhet till säkerheten kring SMS och användande av krypterad kommunikation.
• Undersöka i vilken mån innehållet i SMS-meddelanden kan skyddas med hjälp av kryptering.
• Utveckla en applikation som kan agera bas för detta samt fungera som
"proof of concept".
1.3 Avgränsningar
Detta arbete kommer endast att fokusera på en applikation för Android och inga andra plattformar så som iOS, Windows, Linux eller andra opera- tivsystem. Detta val är inte baserat någon konkret fördel med just Android utan snarare författarens egna förkunskaper när det gäller både utveckling samt användning av den plattformen.
Applikationen kommer heller inte ha som fokus att kunna utföra mer än just det som är av vikt för att kunna lösa de problemformuleringar som ställts upp. Funktionalitet så som MMS eller integration med andra applikationer kommer med största sannolikhet inte byggas in. Målet är att ha något av ett
“proof of concept” för hur detta kan lösas. Eventuella saknade funktioner kommer i så fall att tas upp under kapitlet för vidare forskning.
1.4 Konkreta och verifierbara mål
• Skicka ut en undersökning för att få en uppskattning om folks syn på säkerhet och behov av säkerhet kring SMS.
• Undersöka vilka metoder som lämpar sig bäst för att kryptera medde- landen; vilken typ av kryptografi som bör användas.
• Hur bör nycklarna för denna kryptografi hanteras och distribueras?
• Välja plattform att utveckla mot; iOS eller Android.
• Utveckla en enklare "proof of concept"-lösning när det kommer till mobilapplikation.
• Säkerställa att det faktiskt går att både skicka och ta emot krypterade meddelanden samt att dekryptera och verifiera dessas avsändare.
• Undersöka vilka tydliga säkerhetsproblem som skulle kunna finnas dels i en generell sådan lösning och dels i den faktiskt utvecklade ap- plikationen.
• Om tid finnes, undersöka möjligheten med länkning av externa pub- lika nycklar för verifiering av personer man tidigare inte haft kontakt med.
1.5 Översikt
Denna rapport är strukturerad på följande sätt:
Kapitel 2 innehåller information om de olika språk och system som kommer att användas under arbetet.
Kapitel 3 fokuserar på hur arbetet planeras och läggs upp. Vilka val som görs, hur enkäten utformas och hur arbetet utförs.
Kapitel 4 handlar om hur den praktiska biten av arbetet utvecklats och förk- larar dess ingående klasser.
Kapitel 5 går igenom resultat av enkätsvaren, hur mycket användande av denna applikation skulle kunna påverka faktiska kostnader och påpekar områden för vidare forskning.
Kapitel 6 tar upp slutsatsen om hur det faktiskt gått att säkra SMS-meddelandens innehåll och vad detta kan ha för konsekvenser.
1.6 Författarens bidrag
Till min hjälp i detta arbete har jag dels haft min kontaktperson på Dewire i Sundsvall; Sebastian Försth och dels min handledare på Mittuniversitetet;
Martin Kjellqvist. Under arbetets gång har regelbundna möten med båda parter hållits, oftast ett i veckan. Dessa har varit bra för att hjälpa mig att hålla mig på rätt kurs samt få tydliga mål som jag bör försöka nå på inför nästa veckas möte. Detta har varit mycket hjälpsamt då det annars kan ha funnits en risk att man fokuserat allt för mycket på någon specifik sak och låtit annat halka efter.
Utvecklingen av applikationen har gått bra och jag har inte behövt ta hjälp av Sebastian på Dewire någon gång när det gäller rena kodproblem. Martin har ställt upp med lite förslag på hur saker bör läggas upp som till exempel när jag fokuserat för mycket på att bygga upp applikationen i Fragments istället för att ha separata Activities för olika delar av programmet.
Det har dock varit en lite annorlunda period att utföra arbetet på grund av allt som hänt i och med pandemin covid-19. Allt arbete har fått ske hemifrån istället för, som tänkt, på plats på kontoret hos Dewire. Det har överlag gått bra men ibland har den bistra verkligheten kommit i vägen lite för arbetet och orsakat vissa förseningar.
2 Teori
2.1 Språk
Eftersom applikationen utvecklas till Android finns det framför allt två språk att välja på; Java [7] och Kotlin [8]. Nu för tiden är Kotlin de facto standard när det gäller applikationsutveckling till Android [9]. På grund av tidigare erfarenhet med Java men ingen med Kotlin valdes dock Java som utveck- lingsspråk. Även om Kotlin är väldigt närbesläktat med Java och något som hade kunnat vara nyttigt att sätta sig in i mer kändes det bättre att välja ett språk som undertecknad hade lite mer vana med för att inte behöva ägna allt för mycket tid i att sätta sig in i själva språket.
2.2 IDE / Arbetsmiljö
Som utvecklingsmiljö när det gäller Androidutveckling blir Android Studio [10] ett enkelt val. Det är designat av Google specifikt för att utveckla app- likationer till Android. Den har även använts under tidigare kurser (framför allt Applikationsutveckling i Java - DT170G) där den nyttjats som huvud- plattform för det utvecklande som skett där. Detta ledde till att det kändes naturligt att fortsätta på angiven bana.
2.3 Kryptografi
RSA Cryptography [1] valdes för att lösa krypteringen av meddelanden.
Grunden för detta system utgörs av att alla parter har var sitt respektive ny- ckelpar bestående av en privat och en publik nyckel. Den publika nyckeln kan distribueras fritt medan den privata nyckeln måste hållas skyddad.
För att sedan kryptera något till vald person använder man dennes publika nyckel att kryptera med. Det enda som då sedan kan dekryptera resultatet är denne persons privata nyckel.
Samma princip används även för signering av meddelanden för att en avsän- dare ska kunna verifieras. Då skapar man ett hash av meddelandet som krypteras med avsändarens privata nyckel. Om en mottagare sedan vill verifiera att ett meddelande skickats från den avsändaren så använder de dennes publika nyckel för att dekryptera meddelandets hash och jämför det med ett hash de själva gör av samma meddelande. På det sättet kan de vara säkra på att meddelandet kom från rätt person och att det inte modifierats sedan det skickats.
Matematiken bakom algoritmen ser ut som följer: [11]
2.3.1 Nyckelgenerering
För att generera den publika och privata nyckeln följer man dessa steg:
1. Generera två stora, slumpmässiga primtal; p och q 2. Beräkna en modulus n så att n = qp
3. Välj en ojämn publik exponent e mellan 3 och n-1 som är relativt primt till p-1 och q-1
4. Låt den privata exponenten e vara inversen till d modulo L:
de≡1 mod L
5. Den publika nyckeln är nu (n, e) och den privata är (n, d).
2.3.2 Kryptering / Dekryptering
För att kryptera ett meddelande m:
c = memod n
För att dekryptera ett krypterat meddelande c:
m = cdmod n
Detta är något som sedan sköts av Androids Cipher-klass [12] så dessa beräkningar behöver inte göras manuellt.
3 Metod
3.1 Enkätundersökning
För att kunna få en uppfattning om hur folk i allmänhet ser på säkerheten hos SMS och behovet för detta inom både arbete och privatliv så skapades en enkät som skickats ut. Tanken är att, först och främst, kunna få en bättre förståelse för om folk över huvud taget är medvetna om att SMS är en osäker kommunikationskanal. Därefter undersöks också den allmänna känslan av hur mycket detta behövs dels i arbetslivet och dels i privatlivet. En kontroll görs även angående sannolikheten att ett sådant verktyg faktiskt skulle an- vändas om det erbjudits. Slutligen finns också en fråga om något krypterat kommunikationsverktyg används i dagsläget och varför alternativt varför inte. Plats finns även för övriga kommentarer.
Frågorna som ställs i undersökningen är följande:
• Kön
• Ålder
• Högsta genomförda utbildning
• Sysselsättning
• Är du medveten om att SMS inte bör klassas som en säker kommu- nikationskanal (dvs, det finns inget i protokollet som hindrar oper- atörer från att få tillgång till innehållet)?
• Ser du en nytta med att skydda SMS-konversationer i arbetslivet?
• Hur troligt är det att du skulle använda en sådan lösning i arbetetslivet om det erbjudits?
• Ser du en nytta med att skydda SMS-konversationer privat?
• Hur troligt är det att du skulle använda en sådan lösning privat om det erbjudits?
• Använder du i dagsläget någon form av krypterad kommunikation?
• Om ja, varför? Om nej, varför inte?
• Har du några övriga åsikter eller synpunkter gällande krypterad kom- munikation?
Resultatet från denna kommer sedan att sammanställas för att undersöka om någon tydlig trend kan utläsas baserat på ålder, utbildningsnivå, yrke och så vidare.
3.2 Utveckling
Eftersom målet med det här arbetet var att försöka skydda innehållet i SMS- meddelanden från tredje part (till exempel mobiloperatörer, myndigheter och så vidare) så behövde det först bestämmas hur detta skulle ske samt undersöka hur folk i allmänhet ser på denna fråga.
För att få in ett underlag angående hur folk ser på vikten av kryptering både privat och i arbetslivet skapades en enkät som skickades ut via olika kanaler.
I denna undersöks personens kön, ålder, utbildning, sysselsättning samt om de är medvetna om att SMS bör ses som en osäker kommunikationskanal.
Slutligen efterfrågas också deras behov av att skydda denna kommunika- tion och deras vilja att faktiskt använda ett sådant verktyg om det funnits tillgängligt.
Då det redan finns många andra applikationer som tillhandahåller krypterad kommunikation men som sköter det genom att skicka all trafik över in- ternet via deras servrar valdes det att istället utveckla något som var helt oberoende av externa servrar och som skulle fungera med alla mobiloper- atörer (så länge de följer standarder).
Detta betyder att det inte kunde finnas en central punkt för distribuering av krypteringsnycklar eller meddelanden utan detta måste hanteras av varje användares applikation.
Valet av krypteringsalgoritm fick baseras på det faktum att varje användare skulle behöva kommunicera sin krypteringsnyckel till varje mottagare de vill kommunicera med samt att varje meddelande skulle skickas som SMS och inte via mobildatatrafik.
Det första steget var då att bestämma om krypteringen skulle baseras på symmetrisk eller asymmetrisk kryptografi.
3.3 Symmetrisk kryptografi
När det kommer till symmetrisk kryptografi så finns det flera fördelar, till exempel att många moderna processorer har inbyggt stöd för dessa [13]
vilket gör dem väldigt effektiva samt att de ofta kräver kortare nycklar [14]
för att uppnå en likvärdig säkerhetsnivå jämfört med asymmetrisk kryp- tografi.
Dock finns det en sak som är värd att ha i åtanke och det är distributionen av krypteringsnyckeln. Eftersom samma nyckel används för både kryptering och dekryptering måste man dels ha en unik nyckel för varje konversation samt dels kunna överföra denna på ett säkert sätt mellan de användare som vill kunna kommunicera med varandra.
3.4 Asymmetrisk kryptografi
Här slipper vi genast tänka på hur nyckeln ska distribueras till respektive kontakt eftersom man här istället använder ett nyckelpar. Man har då dels en privat nyckel som hålls skyddad och dels en publik nyckel som fritt kan distribueras till alla kontakter man skulle vilja kunna kommunicera med.
Även om det i regel kräver längre nycklar för asymmetrisk kryptografi gjorde enkelheten med nyckelhanteringen det till ett mer attraktivt alternativ. Nu gick det med lätthet att bygga in en funktion i applikationen som lät an- vändaren skicka sin publika nyckel direkt via SMS, trots att denna kanal bör anses som osäker, eftersom det inte finns någon negativ aspekt på det faktum att denna nyckel skulle kunna komma på villovägar.
Detta ledde till att RSA blev den kryptoalgoritm som skulle användas i det här arbetet.
3.5 Strukturering
Nu när valet av algoritm var avklarat kunde planeringen av det faktiska arbetet börja. Detta startade med att det skapades en Scrum board via Trello [15] där applikations olika beståndsdelar strukturerades upp som olika kort kategoriserade som "Must have", "Should have" och "Could have" beroende på hur högt prioriterade dessa var.
3.5.1 Must have
• A name
• Access to phone contacts
• Access to the Android SMS storage
• A GUI
– Conversation List view – Contact conversation view – Contact details view – Key management view – Personal details view
• Ability to send SMS messages
• Ability to receive SMS messages
• Be able to be set as default SMS app
• A specified message format – Header
– Encrypted message – Public key URL – Signature – Footer
• Ability to generate key pair
• Ability to store own key pair
• Ability to store contacts’ public keys
• Encrypt messages
• Decrypt messages
• Ability to send public key
• Ability to receive public key
3.5.2 Should have
• Be able to verify public key from URL
• Specify URL of own public key
3.5.3 Could have
• Share keys via NFC
• An icon
3.6 Androidapplikation
Det viktigaste i detta arbete var att konstruera en fungerande applikation för att över huvud taget kunna se om det i praktiken var görbart att kryptera SMS-meddelanden. Med tanke på detta så blev nu därför huvudfokuset att bygga sagda applikation.
Det behövdes först och främst konstrueras en rudimentär SMS-applikation som skulle klara av att läsa telefonens SMS-databas samt skicka och ta emot meddelanden.
Grunden till denna applikation utvecklades baserat på en guide designad för just detta, att framställa en väldigt grundläggande SMS-applikation utan större finesser [16]. Den hanterade läsning av telefonens interna lagring av
skickade och mottagna SMS via användande av en ContentResolver [17].
Vidare implementerades även en BroadcastReceiver [18] för att låta applika- tionen reagera på inkommande meddelanden även när den inte är aktiv i förgrunden. Detta tillåter skapande av popup-notifikationer för att upplysa användaren när ett meddelande inkommer (förutsatt att applikationen är satt som standard för SMS [19]).
När en stabil bas hade konstruerats var det dags att börja implementera resterande Must have-funktioner som specificerats ovan. En viktig punkt var hur det egna nyckelparet skulle hanteras. Till en början stod det mellan två val, att lagra dem i applikationens egna privata lagringsutrymme [20]
alternativt att använda Androlid Keystore [21]. Från början hade lutade det mot Keystore då det skyddar användarens privata nyckel på ett väldigt effektivt sätt.
Det fungerar så att nyckeln genereras i Android Keystore-system och kan användas därifrån men kan inte extraheras. Det finns med andra ord inget sätt (förutsatt att inget okänt säkerhetshål finns) för den privata nyckeln att läcka och komma i annans ägo. Detta är av stor vikt eftersom det är den som ansvarar för att dekryptera alla inkommande meddelanden samt skapa giltiga signaturer så att mottagare kan säkerställa att det verkligen är rätt användare som skrivit dem.
Om man däremot ser till applikationens interna lagringsutrymme istället så är det till viss del skyddat av Android men inte på den hårdvarunivå som Keystore är. Här lagras filer som bara just den applikationen ska kunna komma åt och andra applikationer stoppas från att läsa dessa. Här finns dock en svaghet på det sätt att om en telefons användare har root-behörigheter i sin telefon så kan denna data läsas via andra applikationer.
Detta kändes ändå som en risk som var värd att ta i beräkning då det kändes viktigt att den privata nyckeln skulle kunna gå att exportera. Finns inte det alternativet så blir nyckelparet man använder permanent låst till just den telefonen och vid eventuellt byte av telefon så måste dels alla kontakter användaren vill kommunicera med få den nya publika nyckeln och dels blir alla tidigare meddelanden oläsbara i den nya telefonen (även om de exporteras och flyttas över till den nya enheten).
Vidare behövde även telefonens kontaktlista läsas av för att kunna associera meddelandens telefonnummer för avsändare och mottagare till dess kor- rekta namn. Detta sköttes återigen av en ContentResolver [22] och lästes in till en HashMap [23] där en kontakts telefonnummer agerar nyckel och namnet agerar värde.
När detta väl var planerat så kunde arbetet sätta igång ordentligt. Applika- tionens struktur gås igenom mer ingående i kapitlet Konstruktion.
4 Konstruktion
Som tidigare nämnts har den praktiska aspekten av detta arbetet varit att utveckla en demonstrationsapplikation för Android. Denna har utvecklats i Java med hjälp av Android Studio och har under utvecklingen testats på ett par Samsung Galaxy S20 Ultra. För att kunna implementera de funktioner som behövs och som tidigare nämnts delades programmet upp i ett antal olika klasser.
4.1 MainActivity
Detta är programmets grund. Den sköter saker som att se till att program- met ber om de behörigheter det behöver, står som bas för navigationen samt skapar en notifikationskanal som behövs för att kunna skicka notifikationer inom Android.
4.2 ContactDatabaseReader
Här sköts inläsningen av användarens kontaktlista för att kunna associera SMS-meddelandens mottagar- och avsändaradresser till sina korrekta kon- taktnamn.
Detta görs genom att använda en ContentResolver och sedan loopa igenom alla kontakter som återfinns i telefonen. [17]. Dessa sparas sedan i en HashMap där kontakternas telefonnummer agerar nyckel och deras namn agerar värde. På detta sätt kan man sedan enkelt slå på ett telefonnummer i denna HashMap för att snabbt ta reda på vem det tillhör.
4.3 MessageDatabaseReader
återigen används en ContentResolver för att kunna läsa innehållet i telefo- nens skickade och mottagna SMS. Dessa återfinns i content://sms/inbox och content://sms/sent.
Inläsandet av dessa påminner väldigt mycket om sättet att läsa in telefo- nens kontakter, de sparas dock annorlunda för åtkomst inom applikationen sedan.
Här har en Message-klass skapats för att hålla enskilda meddelanden. Alla meddelanden som läses in sparas därför i en ArrayList av typen Message.
Denna loopas senare igenom för att lista korrekta meddelanden för korrekt konversation.
4.4 Message
Detta är klassen som lagrar enskilda SMS-meddelanden. Det är en enkel konstruktion som bara innehåller fem olika variabler samt setters och get- ters för dessa.
Det som lagras för varje meddelande är följande variabler:
address Telefonnummer för mottagare eller avsändare.
contactName Namnet på kontakten som skickat eller tagit mot meddelandet.
contents Textinnehållet i meddelandet.
date Datum och tid då meddelandet skickats eller tagits emot.
wasReceived True om meddelandet mottagits, annars false.
4.5 MessageComparator
Detta är en klass skapad för att kunna sortera meddelanden baserat på det datum de skickats eller tagits emot. Den använder Comparator [24] och jämför variabeln date som finns i varje Message.
4.6 DataStorage
Här lagras de olika uppgifter som lästs in av tidigare klasser och det är från denna klass resterande funktioner vänder sig när något behöver kommas åt. Vi har ArrayLists för alla adresser som återfinns i användarens konver- sationshistorik, för alla inlästa meddelanden samt en HashMap för att lagra alla separata konversationer. Där agerar kontaktens telefonnummer nyckel och själva konversationens ArrayList agerar värde. På detta sett kan man med hjälp av telefonnumret sedan ta ut hela konversationen med den kon- takten för att presentera den till användaren.
4.7 KeyManager
KeyManager påminner lite om DataStorage i det att den lagrar data för åtkomst i resterande applikation. Det som skiljer dem åt är att den även kan generera dessa själv. Det handlar om lagring av publika och privata RSA-nycklar för användande i applikationens kryptering. När klassen ini- tieras kontrollerar den först om användaren har ett nyckelpar skapat sedan tidigare och i så fall sparade i applikationens interna lagringsutrymme. Om dessa finns så läses de in från textfiler, avkodas från hexadecimalt format till RSAPublicKey och RSAPrivateKey.
Finns de inte så skapas dessa istället (och lagras sedan till tidigare nämnda textfiler) med hjälp av KeyPairGenerator [25] där algoritmen specificeras till RSA.
Vi ser även till att lagra dessa nycklar i hexadecimalt format (både med och utan headers och footers) för att lättare kunna skicka dem till sina kontakter.
Även här återfinns en HashMap där kontaktens telefonnummer återigen agerar nyckel och dennes publika nyckel agerar värde för att möjliggöra hämtning av dessa vid kryptering och verifiering.
4.8 SmsBroadcastReceiver
Det är denna klass som ligger aktiv och lyssnar efter inkommande SMS även när applikationen inte är i förgrunden (förutsatt att den är inställd som stan- dardapplikation för SMS-hantering i telefonen). Meddelanden som är län- gre än 160 tecken delas upp i flera bitar [26] och måste därför hanteras med detta i åtanke.
Man får börja med att kontrollera meddelandets längd. Är den 1 så är det inte ett MultiPart-SMS och då är det fritt fram att hämta meddelandeinnhål- let. Om längden däremot är större så måste man kombinera innehållet i lika många SMS som längden angett.
När ett meddelande tagits emot så är det även denna klass som skapar notifikationen som visas på användarens telefon. Här görs en distinktion baserat på om det är ett vanligt meddelande eller om det är en inkom- mande publik nyckel. Skulle det vara en publik nyckel så läggs denna till i KeyManager för att kunna användas vid kryptering till eller verifiering av meddelanden från den användaren. Då läggs heller inte meddelandet till i telefonens lagring för SMS, detta görs bara för inkommande meddelanden.
Just hur sparandet av meddelanden i telefonens interna lagring sköts var något som tog en stund att inse. Från början gick arbetet vidare under tron att SMS sparades med automatik. När meddelanden började försvinna utan synbar förklaring blev det svårt att hitta orsaken. Det visade sig att alla SMS måste manuellt sparas i antingen content://sms/inbox eller con- tent://sms/sent med hjälp av ContentResolvers insert-funktion [27] beroende på om det är ett inkommande eller utgående meddelande.
4.9 CryptoEngine
Här sköts all kryptografi för applikationen [28]. Både när det gäller krypter- ing av utgående meddelanden, skapande av meddelandesignaturer, ver- ifiering av inkommande meddelandens signaturer samt dekryptering av inkommande meddelanden.
Här används Cipher [12] i encrypt- eller decrypt-mode för att kryptera eller dekryptera meddelandens text. Algoritmen som används är RSA och nyck- larna är de som lagrats i KeyManager tidigare.
Här upptäcktes en intressant konsekvens som inte funnits med i de initiella beräkningarna.
När man använder asymmetrisk kryptografi så har varje användare var sitt nyckelpar med en privat och en publik nyckel. Krypterar man något med den publika nyckeln så kan bara dess motsvarande privata nyckel dekryptera meddelandet efteråt. Det som hände i det här fallet var att när användaren skulle skicka ett krypterat meddelande till en kontakt så krypterades innehållet med deras publika nyckel och resultatet skickades.
När meddelandet kom fram så kunde det avkodas och läsas utan problem.
Dock upptäcktes det då att avsändaren inte kunde läsa de meddelanden som skickats eftersom de bara var krypterade med mottagarens nyckel.
För att lösa detta skickas varje meddelande dubbelt. Första delen är krypterat med mottagarens publika nyckel och den andra halvan är krypterad med användarens publika nyckel. Efter att detta implementerats så läser app- likationen bara av den andra halvan av skickade meddelanden och avko- dar dessa med användarens privata nyckel. På så sätt har vi en läsbar kopia att visa upp för användaren så att konversationerna blir lite mer lättlästa jämfört med att bara kunna läsa inkommande meddelanden.
När det gäller signering och verifiering av meddelanden så sköts detta med hjälp av Androids Signature-klass [29]. Där specificeras vilken algoritm som skall användas. Det finns stöd för många och här valdes först under den tidiga utvecklingen SHA1withRSA bara för att se att det skulle fungera.
Värt att notera att denna algoritm (SHA1) inte längre bör klassas som säker [30] och en bättre algoritm bör användas här om detta tas i produktion. Syn- taxen är dock densamma så ett byte av algoritm skulle inte orsaka några svårigheter. Det som händer är att det skapas ett hash av meddelandet och detta signeras med hjälp av användarens privata nyckel. Om en mottagare sedan har användarens publika nyckel så verifierar dennes applikation att signaturen stämmer. Visar det sig att signaturen är korrekt så visas ett låst hänglås i pratbubblan för att symbolisera att det både är krypterat och sign- erat. Har man däremot inte tillgång till den publika nyckeln visas ett olåst hänglås för att visa att meddelandet är krypterat men inte kunnat verifieras.
Är meddelandet inte heller krypterat saknas hänglåset helt.
4.10 Fragments till MainActivity
Eftersom MainActivity har underliggande Fragments [31] med tillhörande ViewModels [32] som var och en använder ovan beskrivna klasser så får de ligga i ett eget samlingskapitel här.
4.10.1 HomeFragment
HomeFragment är det fragment som man landar på när man startar app- likationen. Till att börja med så använder dess ViewModel en MutableLive- Data [33] som innehåller listan med alla adresser som har aktiva konversa- tioner.
Varje konversation i denna lista består av ett ConversationItemView.
Det som presenteras för användaren är namnet (eller telefonnumret om man inte har den kontakten inlagd i sin kontaktlista), innehållet i det senaste meddelandet samt tid och datum då det skickats eller tagits emot.
Denna information hämtas från DataStorage och har sedan en Observer i själva fragmentet för att kunna uppdatera och sortera konversationslistan när datan uppdateras. På detta sätt hamnar den konversation som har det senaste meddelandet överst i listan.
Klickar man på en av dessa konversationer i listan så öppnas istället klassen ChatActivity som kommer att beskrivas nedan.
4.10.2 KeyManagement
Det är detta fragment som låter användaren hantera sina nycklar. När den öppnas för första gången så skapas ett nyckelpar som sparas till textfiler och vid kommande tillfällen läses dessa filer istället in.
Man kan här se båda sina nycklar i hexadecimalt format samt även skicka sin publika nyckel till valfri kontakt eller valfritt nummer. Ett krav för att kunna skicka krypterade meddelanden till en kontakt är att denne skickat sin publika nyckel till användaren via detta fragment.
4.10.3 Settings
För närvarande ett oanvänt fragment. Tanken här är att man skall kunna ställa in olika aspekter för applikationen. Saker så som nyckelstorlek (just nu används nycklar i storleken 2048 bitar), om den privata nyckeln ska vara lösenordskyddad och i så fall hur ofta denna ska anges. Dock var inget av detta kritiskt för att demonstrera grundprinciperna i detta arbete.
4.11 ConversationItemview
Detta är ett inlägg i konversationslistan. Det innehåller tre TextViews som populeras med kontaktens telefonnummer eller namn, det senaste medde- landets innehåll och datumet där det skickats.
4.12 MessageItemView
Det här är är den View som skapar de individuella pratbubblorna när man är inne i en konversation. Den innehåller ett textfält för meddelandets in- nehåll, dess datum och en hänglåsikon. Synligheten för hänglåsikonen och bakgrundsfärgen sätts baserat på om meddelandet är krypterat eller inte (vilket i sin tur specificeras som ett argument i klassens konstruktor)
4.13 ChatActivity
Detta är den aktivitet som laddas om användaren klickar på en konversa- tion i HomeFragment. Här visas då alla inkommande och utgående med- delanden i "pratbubblor" som är färgkodade på olika sätt.
Är meddelanden okrypterade så har skickade meddelanden en ljusblå bak- grundsfärg och mottagna en ljusgrå färg.
När de istället är krypterade så blir skickade meddelanden gröna och mark- eras med ett hänglås. Mottagna meddelanden blir mörkare blå och får även de ett hänglås.
För att populera denna lista så skickas kontaktens telefonnummer med som extra data i dess intent [34] när den öppnas från HomeFragment. Detta används i sin tur för att hämta konversationen från DataStorage och sedan skapa ett MessageItemView för varje meddelande.
Här finns också ett fält att ange text och en skicka-knapp (som även den får ett hänglås om man har mottagit användarens publika nyckel för att visa att meddelanden kommer att skickas krypterat).
Det finns en lyssnare på knappen som tar innehållet i textfältet och skickar ett SMS via SmsManager [35] i Android.
4.14 ComposeActivity
Det här är den aktivitet man kommer till om man klickar på den flytande kuvert-ikonen [36] nere till höger i applikationen.
Den låter användaren skapa ett nytt meddelande som inte är del av en befintlig konversation.
Här finns ett fält för att ange ett nummer att skicka till samt även en rull- gardinsmeny bestående av en Spinner [37] som populeras med innehållet i HashMapen från DataStorage, dvs alla kontakter i användarens kontaktlista med först nummer och sedan namn.
Dessa nummer görs även om så att de får internationellt format, det vill säga 070 XXX YY ZZ görs om till +4670 XXX YY ZZ eftersom det är så num-
ren presenteras i SMS och det är så applikationen är designad att hantera nummer.
5 Resultat
5.1 Friskrivningsklausul
Det är värt att notera att även om detta är ett arbete fokuserat på kryp- tografi och säkerhet så är det först och främst en demonstration på hur det skulle kunna implementeras. Det bör därför inte ses som en slutgiltigt re- sultat och när det kommer till själva applikationen så kan den inte heller klassas som fullständigt säker. Undertecknad kan inte heller garantera dess säkerhet utan har istället byggt upp den som en simplare grund där olika principer kan demonstreras. Det finns saker som är värda att notera, sådant som medvetet inte implementeras, det kan vara på grund av tidsbrist eller för att det inte behövdes i det här arbetet. En sådan sak är att användarens privata nyckel inte är lösenordsskyddad. Det hade inte behövts om det in- terna Keystore-systemet använts men då istället applikationens interna la- gring används, vilken går att komma åt om man får root-behörigheter i sin telefon skulle det teoretiskt sett kunna vara en säkerhetsrisk. Applikationen i sig har inte heller något inbyggt system för verifikation av mottagna pub- lika nycklar. Detta är något man istället får göra på egen hand via en annan kanal och sedan hålla reda på själv att nyckeln inte ändrats. Det kan även finnas problem i programmet som inte ännu upptäckts.
5.2 Jämförelse
Eftersom SMS lagras i en dedikerad databas i Androidtelefoner och som man kan komma åt med olika applikationer blev det en lätt sak att faktiskt påvisa skillnaden på hur ett av dessa krypterade meddelanden visas i denna applikation jämfört med en ordinarie SMS-applikation.
Som tidigare nämnts visas de krypterade meddelandena dekrypterade i ap- plikationen men när man försöker läsa dem i någonting annat så ser man hur de egentligen ser ut och hur de levereras av mobiloperatörer.
Ett enkelt meddelande innehållande bara ordet "hej" ser ut så här i denna applikationen:
Figure 1: Ett dekrypterat meddelande
När man istället öppnar samma meddelande i "Samsung Meddelanden" får man se det faktiska innehållet:
Figure 2: Ett meddelande i dess krypterade form
5.3 Enkätsvar
Enkätsvaren finns bifogade i bilagan Resultat från enkät. Man kan se att en övervägande majoritet är medvetna om att SMS bör klassas som en osäker kommunikationskanal men att det är inte en fullt lika stark andel som ser vikten av att använda någon form av kryptering för att skydda dem. Det märks dock en skillnad när man jämför privatlivet med arbetslivet. När det kommer till privatlivet kan man ana att allmänheten inte är lika måna om att skydda innehållet jämfört med hur de ser på det inom arbetslivet även om det finns en svag tendens mot att föredra det även privat.
Med andra ord kan det konstateras att medvetenheten absolut finns där, men däremot verkar det inte vara något som allmänheten överlag oroar sig allt för mycket över. Ser man till nyttan att skydda sina privata SMS så är svaren nästan jämt fördelade över hela skalan och det lutar mer åt att inte använda något liknande verktyg om det erbjuds. Inom arbetslivet lutar det lite mer åt det positiva hållet men inte heller där har vi någon överhängande vikt.
5.4 Kostnad
Eftersom alla meddelanden som skickas via denna applikation kommer att växa i storlek jämfört med dess okrypterade form kan det finns en viss ökn- ing i kostnad om användaren betalar styckvis för varje skickat SMS. Utöver den själva krypterade texten skickas även en kopia krypterad till avsän- daren samt både signatur, headers och footers för att applikationen lättare skall kunna avgöra om ett meddelande är krypterat eller inte samt kunna verifiera att det skickats från den det utges ha skickats från. Eftersom ett SMS bara får vara 160 tecken långt kommer dessa att delas upp i multi- partmeddelande om de är längre än så. Då ett meddelande dels blir längre när det är krypterat och dels inkluderas två gånger samt dels får lite extra headers och annan data så blir det en markant längdskillnad på medde- landena. Om detta är något som man bör ha i hänsyn är ju helt och hållet upp till användaren.
Om man till exempel ser till meddelandet i kapitlet Jämförelse så ser man att en text på tre bokstäver ("hej") faktiskt skickas som ett textstycke på 1130 tecken. Eftersom ett enskilt SMS är 160 tecken långt har meddelandet i det här fallet egentligen skickats som ett multipartmeddelande bestående av sju SMS. Betalar man då per SMS så hade det här meddelandet alltså kostat sju gånger så mycket att skicka jämfört med om det skickats via en traditionell, icke krypterad, applikation.
Detta skulle kunna minskas en aning genom att till exempel använda ko- rtare headers istället för "— incognitext encrypted msg —", "— incognitext
sender copy —" samt "— incognitext signature —" men rent procentuellt står de dock inte för en så stor del av meddelandet.
5.5 Vidare forskning
Det finns, som tidigare nämnts, vissa saker som inte implementerats i detta arbete. Ett exempel skulle kunna vara ett enklare sätt att både dela och ver- ifiera kontakters publika nycklar. Ett alternativt för detta skulle kunna vara användande av QR-koder [38] för enkel avläsning via telefonens kamera.
Även om RSA bör räknas som säkert [11] så finns det kryptografiska lös- ningar som klassas som helt säkra och en sådan är one time pads [39]. Det vill säga att man för varje meddelande använder en på förväg helt slump- mässig nyckel som är minst lika lång som meddelandet och som bara an- vändas en gång. Detta kräver dock att både avsändaren och mottagaren de- lar på en kodbok med dessa nycklar för att kunna kommunicera med varan- dra. Detta är något som skulle kunnat delas via NFC [39] för att förhindra att någon tredje part får tillgång till dem. Dessa nycklar hade då kunnat an- vändas för att kryptera varje enskilt meddelande. Det man hade fått tänka på då är att man måste fysiskt ses och dela fler nycklar med varandra efter ett tag när alla de man haft tagit slut eftersom de inte får återanvändas.
En annan teknik som från början var tänkt att finnas med i detta arbete men som dessvärre tiden inte räckte till för var verifiering av publika nycklar från publika webbsidor. Tanken var att man skulle kunna ladda upp sin publika nyckel på en webbsida och sedan inkludera denna URL i medde- landets footer. Då hade applikationen själv kunnat ladda ner den nyckeln (om detta var en kontakt man tidigare inte kommunicerat med och således inte redan verifierat deras nyckel) från denna URL och kontrollerat om den överensstämmer med det krypterade innehållet. Därefter hade användaren kunnat presenteras med ett meddelande som sagt någonting i stil med att meddelanden krypterats av en användare som verifierar sig på URL XXX.
Sedan hade det varit upp till användaren om de valt att lita på denna ny- ckel eller inte. Trovärdigheten hade i sådana fall blivit ställd i proportion till trovärdigheten hos den webbsida nyckeln publicerats på. Om man till exempel fått ett SMS som hävdas vara från polisen och som krypterats med en nyckel som överensstämmer med en nyckel på www.polisen.se så bör man kunna vara relativt säker att det är ett autentiskt meddelande.
Om detta är något som skulle implementeras så finns det även en del säker- hetsaspekter att ha i åtanke. Dels skulle det stödja sig på DNS om det rör sig om en URL till en nyckel och DNS är i dagsläget i sig inte garanterat säkert [40].
Eventuellt skulle man behöva något betrott som kan certifiera att nyckeln
behövas en central entitet som står för sådant och det var något som var menat att undvikas i det här arbetet.
Utöver detta skulle man även behöva vara väldigt noga med hur man hanterar det som hämtas från adressen i fråga för att kunna vara säker på att man inte hämtar något icke önskvärt. Det vore mycket olyckligt om någon okänd bug i applikationen gör att den skulle gå att utnyttja genom att länka till skadlig kod i sin footer.
En annan nackdel, om man ser till hur det här arbetet utformats, är att man inte längre bara skulle använda SMS-protokollet. För att kunna hämta en nyckel på en webbsida behövs datatrafik. Det är kanske inget större prob- lem för de flesta men ett av målen var att försöka hålla kommunikationen till enbart SMS för att applikationen skall kunna fungera även när mobildata inte finns tillgängligt.
6 Slutsats
Målet med den här arbetet var att undersöka hur man kan skydda innehållet i SMS-konversationer. Detta har gjorts genom att utveckla en SMS-applikation för Android. Den genererar först ett RSA-nyckelpar och kan sedan både kryptera och dekryptera meddelanden samt signera och verifiera dessa.
Om man ser till matematiken bakom RSA så ser man att styrkan i detta kryptosystem ligger i faktoriseringen av stora primtal. Trots åratal av forskn- ing har man fortfarande inte kunnat lösa sådana problem utan att det krävs ett orimligt stort arbete. Eftersom krypteringen i detta arbete använder sig av just RSA via befintliga algoritmer och färdiga system i Android så bör resultatet, förutsatt att inga icke upptäckta problem i koden hittas, kunna klassas som säkert.
Eftersom det tidigare kunnat konstateras att det inte finns något i det befintliga SMS-protokollet som skyddar meddelandens innehåll från de mobiloper- atörer som hanterar dem blir resultatet av detta arbete ett system som an- vänder befintliga och välbeprövade metoder att göra just det.
Det har vissa konsekvenser, till exempel kräver det att användaren delar nycklar med de personer som de vill kunna kommunicera med, ett extra steg utöver att i som i vanliga fall bara kunna ange ett mobilnummer och skriva ett meddelande.
Det har även kunnat konstateras att varje meddelande blir längre än det varit i sin okrypterade form och detta kan leda till extra kostnader för an- vändaren beroende på hur deras abonnemangsform ser ut.
Det går dock att hävda att man på det här sättet kan, på ett relativt smidigt och effektivt sätt, skydda innehållet i sin SMS-trafik, om man känner att det finns ett behov av detta, utan att det bör finnas någon realistisk risk för att denna ska kunna avläsas av icke behörig tredje part.
6.1 Enkäten
Ser man till enkäten så måste det tilläggas att undersökningen inte bör klas- sas som helt tillförlitlig då det fanns vissa problem med att få in tillräckligt många svar. Som det såg ut när detta skrevs hade bara 49 personer svarat på den. Tanken var att bryta ner de olika frågeställningarna baserat på olika kriterier för att se om det gick att ana några trender när det gäller ålders- grupper, utbildning, sysselsättning och så vidare. Dock visade sig antalet svar bli för lågt för att få ett tillräckligt representativt utfall för att kunna göra en ordentlig sådan jämförelse. Det finns till exempel bara en person som svarat på frågorna och som jobbat statligt.
tillräckligt bred publik och många av de som svarade på den jobbade inom IT-relaterad yrken. Hade det lagts mer tid åt att försöka få ut den till en större publik så hade det resulterat i ett bättre genomsnitt av allmänhetens åsikter kring kryptering.
6.2 Metoddiskussion
Om man ser till de mål som sattes i början av arbetet; hur har det då egentli- gen gått? Är alla mål uppnådda eller är det något av vikt som saknas eller misslyckats?
På det hela har de mål som återfinns i kapitlet Konkreta och verifierbara mål uppnåtts, om än kanske inte fullt ut i vissa fall.
Den punkt som blivit mest lidande är, som redan konstaterats, enkäten. Den hade behövt nå en större och bredare publik för att kunna bli helt tillförlitlig och användbar. Den är dock utskickad och strax under 50 personer svarade på den så den uteblev inte helt.
När det gäller valet av krypteringsalgoritm hade ett större arbete kunna göras. RSA valdes framför allt på grund av att den är så väletablerad och väl undersökt. Ingen har ännu hittat några uppenbara problem med den.
Dock hade det kunnat vara av intresse att undersöka till exempel elliptic curve-kryptografi då denna ofta kräver en kortare nyckellängd [41] jämfört med RSA. Tyvärr ägnades inte tillräckligt mycket tid åt att undersöka alla alternativ så huruvida hade varit ett bättre eller sämre val får vara osagt.
Målet med att faktiskt utveckla en applikation som "proof of concept" har gått bättre. Det går att skapa nyckelpar, dela sin publika nyckel med sina kontakter, ta emot andras publika nycklar samt att skicka och ta emot krypter- ade meddelanden. Dessa verifieras även mot den mottagna nyckeln om så finnes. Nog för att applikationen i sig kanske inte är helt produktionsdug- lig, men det var inte heller tanken utan den utvecklades bara för att se om principerna som tagits upp i denna rapport faktiskt fungerade.
Verifiering av publika nycklar via en URL i meddelanden är något som inte undersöktes djupare men det var också en punkt som var uppsatt att tas med om tiden skulle räcka till och det var just det det föll på. Grundfunk- tionaliteten var tvungen att prioriteras för att få de viktigaste funktionerna på plats.
6.3 Etiska aspekter
När det gäller krypterad kommunikation så finns det förespråkare både för och emot användandet.
Det finns dels de som anser att kryptering antingen borde förbjudas helt alternativt bara tillåtas om det finns något sätt för myndigheter att ändå komma åt innehållet.
Andra menar att allting som går bör vara krypterat och att det snarare bör handla om en rättighet att kunna hålla sin kommunikation skyddad från oönskade ögon.
Utöver dessa båda grupper så finns även en stor mängd som inte är särskilt engagerade åt endera hållet. De kanske använder denna typ av verktyg om de erbjuds, men inte nödvändigtvis på grund av krypteringen i sig utan snarare för att deras arbete krävt det, någon bekant använder det för att kommunicera och så vidare.
De olika lägren har argument som går att förstå även om man inte nöd- vändigtvis håller med dem till fullo. Till exempel är det fullt förståeligt att rättsväsendet känner ett behov av att ha möjlighet att kunna avlyssna olika typer av kommunikationer. Det kan göra deras arbete svårare om det inte finns någon praktisk möjlighet att komma över sådan kommunikation.
Samtidigt finns det alltid risker med att till exempel lagstadga mot krypter- ing. Som tidigare påpekats har uppgifter kommit fram om att vissa myn- digheter använt sig av avlyssning och analysering av meddelanden i my- cket större utsträckning än vad lagen egentligen tillåter. Om krypterad kommunikation då vore olagligt skulle ett sådant scenario kunna leda till att fler medborgares kommunikationer avlyssnas än vad som egentligen vore tillåtet eftersom de inte får skydda dessa med hjälp av kryptografi.
Det finns som sagt många som tycker att det inte är så viktigt med krypter- ing; ett vanligt argument brukar vara att de inte tycker att de har något att dölja. Dock kan det ändå leda till att man känner sig obekväm med det faktum att saker som skickas är lika lätta att läsa som ett fysiskt vykort.
Många verktyg finns också redan tillgängliga även om de kan vara lite för avancerade för gemene man. Skulle man dock förbjuda kryptering bety- der ju inte detta att verktygen och den befintliga forskningen kring kryp- tografi skulle försvinna. Kunskapen om hur man säkrar sina meddelanden till exempel med hjälp av RSA som i det här arbetet finns redan och den kunskapen går inte att radera.
Det finns då istället en risk för ett scenario där de som faktiskt använder kryptering för att kommunicera kring brottsliga aktiviteter fortfarande skulle göra det det då de ändå inte följer lagen och därför inte går att övervaka medan gemene mans trafik kan övervakas även om inget brott begås.
Källförteckning
[1] et al. Moriarty. PKCS #1: RSA Cryptography Specifications Version 2.2.
URL: https://tools.ietf.org/html/rfc8017 (hämtad 2020-06-03).
[2] The Courage Foundation. Revelations.URL: https://www.edwardsnowden.
com/revelations/(hämtad 2020-06-03).
[3] Let’s Encrypt. Let’s Encrypt - Gratis SSL/TLS-certifikat.URL: https://
letsencrypt.org/sv/(hämtad 2020-06-03).
[4] Signal. Home.URL: https://signal.org/ (hämtad 2020-06-03).
[5] 3rd Generation Partnership Project. Technical realization of the Short Message Service (SMS) (Release 15). URL: https://portal.3gpp.org/
desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=
747(hämtad 2020-06-03).
[6] Reporters Without Borders. INTERNET ENEMIES REPORT 2012.URL: https://web.archive.org/web/20120323215225/http://march12.
rsf.org/i/Report_EnemiesoftheInternet_2012.pdf(hämtad 2020- 06-03).
[7] Oracle. Java Software | Orace.URL: https://www.oracle.com/java/
(hämtad 2020-06-03).
[8] JetBrains. Kotling Programming Language. URL: https://kotlinlang.
org/(hämtad 2020-06-03).
[9] Android Developers Blog. Google I/O 2019: Empowering developers to build the best experiences on Android + Play. URL: https : / / android - developers.googleblog.com/2019/05/google-io-2019-empowering- developers- to- build- experiences- on- Android- Play.html (häm- tad 2020-06-03).
[10] Android Developers. Download Android Studio and SDK tools.URL: https:
//developer.android.com/studio(hämtad 2020-06-03).
[11] Burt Kaliski. The Mathematics of the RSA Public-Key Cryptosystem.URL: http://www.mathaware.org/mam/06/Kaliski.pdf(hämtad 2020-06- 03).
[12] Android Developers. Cipher.URL: https://developer.android.com/
reference/javax/crypto/Cipher(hämtad 2020-06-03).
[13] Shay Gueron. Intel Advanced Encryption Standard (AES) New Instruc-R tions Set. URL: https://www.intel.com/content/dam/doc/white- paper / advanced - encryption - standard - new - instructions - set - paper.pdf(hämtad 2020-06-03).
[14] Sourabh Chandra, Smita Paira, Sk Alam, et al. “A comparative sur- vey of Symmetric and Asymmetric Key Cryptography”. In: Nov. 2014.
DOI: 10.1109/ICECCE.2014.7086640.
[15] Trello. Trello.URL: https://trello.com/ (hämtad 2020-06-03).
[16] Adam Sinicki. How to create an SMS app part one – sending and receiv- ing messages. URL: https : / / www . androidauthority . com / how - to - create-an-sms-app-721438/(hämtad 2020-06-03).
[17] Android Developers. ContentResolver.URL: https://developer.android.
com / reference / android / content / ContentResolver (hämtad 2020- 06-03).
[18] Android Developers. BroadcastReceiver. URL: https : / / developer . android.com/reference/android/content/BroadcastReceiver(häm- tad 2020-06-03).
[19] Mike M. android - How do I set my app as the default SMS app? - Stack Overflow. URL: https://stackoverflow.com/questions/30127564/
how-do-i-set-my-app-as-the-default-sms-app(hämtad 2020-06- 03).
[20] Android Developers. Data and file storage overview. URL: https : / / developer . android . com / training / data - storage (hämtad 2020- 06-03).
[21] Android Developers. Android keystore system.URL: https://developer.
android.com/training/articles/keystore(hämtad 2020-06-03).
[22] mudit. java - Android get all contacts telephone number in ArrayList - Stack Overflow. URL: https://stackoverflow.com/questions/15243278/
android - get - all - contacts - telephone - number - in - arraylist / 15243483#15243483(hämtad 2020-06-03).
[23] Android Developers. HashMap. URL: https://developer.android.
com/reference/java/util/HashMap(hämtad 2020-06-03).
[24] Android Developers. Comparator.URL: https://developer.android.
com/reference/java/util/Comparator(hämtad 2020-06-03).
[25] Android Developers. KeyPairGenerator. URL: https : / / developer . android . com / reference / java / security / KeyPairGenerator (häm- tad 2020-06-03).
[26] stackoverflow. Android - receiving long SMS (multipart). URL: https : / / stackoverflow . com / questions / 4306020 / android - receiving - long-sms-multipart(hämtad 2020-06-03).
[27] stackoverflow. Android SMS app I made not storing sent messages on the phone. URL: https://stackoverflow.com/questions/6152641/
android- sms- app- i- made- not- storing- sent- messages- on- the- phone(hämtad 2020-06-03).
[28] stackoverflow. RSA Encryption Decryption in Android. URL: https://
stackoverflow.com/questions/12471999/rsa-encryption-decryption-
[29] Android Developers. Signature. URL: https://developer.android.
com/reference/java/security/Signature(hämtad 2020-06-03).
[30] Marc Stevens, Elie Bursztein, Pierre Karpman, et al. “The First Colli- sion for Full SHA-1”. In: Advances in Cryptology – CRYPTO 2017. Ed.
by Jonathan Katz and Hovav Shacham. Cham: Springer International Publishing, 2017, pp. 570–596.ISBN: 978-3-319-63688-7.
[31] Android Developers. Fragments.URL: https://developer.android.
com/guide/components/fragments(hämtad 2020-06-03).
[32] Android Developers. ViewModel Overview.URL: https://developer.
android.com/topic/libraries/architecture/viewmodel (hämtad 2020-06-04).
[33] Android Developers. MutableLiveData. URL: https : / / developer . android.com/reference/android/arch/lifecycle/MutableLiveData (hämtad 2020-06-03).
[34] Android Developers. Intent.URL: https://developer.android.com/
reference/android/content/Intent(hämtad 2020-06-03).
[35] Android Developers. SmsManager.URL: https://developer.android.
com / reference / android / telephony / SmsManager (hämtad 2020-06- 03).
[36] Android Developers. Add A Floating Action Button. URL: https : / / developer . android . com / guide / topics / ui / floating - action - button(hämtad 2020-06-03).
[37] Androlid Developers. Spinners. URL: https://developer.android.
com/guide/topics/ui/controls/spinner(hämtad 2020-06-03).
[38] Information technology — Automatic identification and data capture tech- niques — QR Code bar code symbology specification. Standard. Interna- tional Organization for Standardization, 2015.
[39] Daniel Bosk, Martin Kjellqvist, and Sonja Buchegger. “Towards per- fectly secure and deniable communication using an NFC-based key- exchange scheme”. In: Nordic Conference on Secure IT Systems. Springer.
2015, pp. 72–87.
[40] Suranjith Ariyapperuma and Chris Mitchell. “Security vulnerabilities in DNS and DNSSEC”. In: Jan. 2007, pp. 335–342.DOI: 10.1109/ARES.
2007.139.
[41] Víctor Gayoso Martínez, Luis Hernandez Encinas, and Carmen Sánchez Ávila. “A Survey of the Elliptic Curve Integrated Encryption Scheme”.
In: Journal of Computer Science and Engineering 2 (Jan. 2010), pp. 7–13.
A Bilaga A
A.1 Resultat från enkät
Kön Antal
Man 32
Kvinna 17
Annat 0
Table 1: Kön Ålder Antal
0-18 0
19-29 12 30-39 24 40-49 9 50-59 1 60-69 3
70+ 0
Table 2: Ålder
Utbildning Antal
Grundskola 0
Gymnasie 4
Högskola/Universitet 45 Table 3: Utbildning
Sysselsättning Antal
Arbetssökande 0
Studerar 2
Arbetar (privat) 32 Arbetar (kommunalt) 13 Arbetar (statligt) 2
Pensionär 0
Table 4: Sysselsättning
Medveten Antal
Ja 40
Nej 9
Table 5: Medveten om att SMS är osäkert
Val Antal
1 8
2 11
3 5
4 12
5 13
Table 6: Nyttan med att skydda SMS inom arbetet
Val Antal
1 11
2 5
3 7
4 13
5 13
Table 7: Troligt att det kommer att användas inom arbetet om tillgängligt
Val Antal
1 9
2 10
3 9
4 12
5 9
Table 8: Nyttan med att skydda SMS privat
Val Antal
1 9
2 10
3 14
4 8
5 8
Table 9: Troligt att det kommer att användas privat om tillgängligt
Val Antal
Ja 27
Nej 18
Vet ej 4
Table 10: Utbildning
A.2 Varför använder du krypterad kommunikation?
• I arbetet
• Integritet
• Jag anser att mina meddelanden ska vara mina, och med det är krypterad kommunikation en av dom bättre alternativen
• Ja, används för att skicka credentials i jobbet.
• Ja, främst i mail (PGP), kryptering av filer som sedan skickas i valfri kommunikationskanal (AES).
• Personlig integritet
• Krav inom arbetet
• För att det känns tryggare att göra det.
• Krav att använda krypterade mail från arbetsgivare.
• För att min man tvingar mig.
• I jobbet, pga sekretesskyddade uppgifter.
• Chattklienter jag använder är kryterade. Ingen sellingpoint
• I jobbet, vårt datasystem. Vår interna mail är också krypterad
• För att kryptera min trafik och kommunikation.
• För att skydda min personliga integritet.
• Icke-krypterade meddelanden använts flitigt av privata företag för att skapa ekonomiska-/sociala-/psykologiska- profiler av användare för marknadsföring och annan storskalig påverkan. Utöver det är privat kommunikation viktig för allt ifrån arbetsrätt till demokrati. Synd att det används för brott också :)
• e2e-kryptering så långt det går. Facebook & google vet redan tillräck- ligt om mig och jag tycker inte de ska profilera mig mer än de redan gjort.
• By default
• Jag använder mig av krypterad kommunikation inom arbetet för att skydda känslig information.
• Bank och företagsinformation kräver högre säkerhet
• Använder whatsapp och det erbjuds per automatik
