Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete |Medieteknik

Vårterminen 2018 | LiU-ITN-TEK-G--18/045--SE

MumblrEn chattapplikation baserad på Web of Trust

David ErikssonJosefine FlüggeJohnny MelinAndreas SiebmannsEmma Weberyd

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-581 83 Linköping

013–28 10 00, www.liu.se

Figurer

2.1 Tidsplan - De gröna blocken representerar milstolpar och de blå blocken aktiviteter. . 4

2.2 Hantering av backlogg och sprintuppgifter i Trello. . . . . . . . . . . . . . . . . . . 6

2.3 Flöde för git-rutiner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Foto från det andra användartestet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Kontaktlistan i prototypen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Chatten utseende i prototypen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Utdrag av grafiska element från applikationen. . . . . . . . . . . . . . . . . . . . . . 11

3.4 Konceptbild och slutgiltig ikon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Kryptering med AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.1 Sekvensdiagram som beskriver hur komponenterna kommunicerar då QR-koden skan-nas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Sekvensdiagram som beskriver hur komponenterna kommunicerar i enhet 1 efter attQR-koden har skannats av enhet 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.1 Profil-vyn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.2 List-vyn med chatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.3 Skanner-vyn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.4 Nyskapad, oaktiverad chatt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.5 Skanner-vyn då ny chatt skannas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.6 Chatten när den är ansluten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.7 Profil-vyn för applikationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.8 Vyn som visas för att redigera avataren. . . . . . . . . . . . . . . . . . . . . . . . . 24

7.9 En välkomstskärm som användaren möter första gången appen öppnas i enheten. . . 25

7.10 En vy som är del av välkomstguiden, där användaren får välja färg på avataren. . . . 25

7.11 En vy som är del av välkomstguiden, där användaren får fylla i sitt namn. . . . . . . 25

i

Tabeller

2.1 Utvecklingsgruppens Roller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6.1 Databas schema för mumblr.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ii

Sammanfattning

Teknikens snabba utveckling ökar antalet kommunikationsvägar för människor, vilket i regel ansesvara en positiv sak. Det finns dock nackdelar med en ökad kommunikation över internet. De månganya sätten att enkelt komma i kontakt med nästan vem som helst på nätet, ökar risken för nätmob-bing, trakasserier och nätgromning. En av de grupper som är mest sårbara och utsatta för detta ärbarn och ungdomar. Syftet med projektet är att skapa en produkt för barn och ungdomar där de skakunna kommunicera med sina vänner, utan att riskera att komma i kontakt med obehöriga personerpå internet.

Projektet är utfört av fem studenter vid Linköpings universitet och har utvecklats under ungefär tioveckor. Under systemutvecklingen har utvecklingsmetodiken Scrum använts för att maximera arbetetsflexibilitet och effektivitet. För att öka produktiviteten ytterligare användes förutbestämda versions-hanteringsrutiner. Applikationen utvecklades i javascript-ramverket React Native, vilket ska underlät-ta utvecklandet av mobilapplikationer som ska ges ut för både iOS och Android.

För att skapa ett säkert kommunikationsverktyg användes konceptet ”Web of Trust”, vilket innebär atten användare kan dela med sig av en krypteringsnyckel till andra tillförlitliga användare. Krypterings-nycklarna används sedan för att kryptera och avkryptera kommunikationen mellan dessa användare.

Arbetet resulterade i en applikation som har en fungerade realtidschatt som baseras på ”Web of Trust”med AES kryptering. Användarna kan lägga till sitt namn och sammankoppla chatter med andraanvändare med hjälp av en QR-kod. Eftersom det enda sättet att skapa kontakt är att skanna en QR-kod måste användarna fysiskt träffas, vilket fungerar som ett lager av säkerhet.

Gränssnittets avgränsningar fastställs av målgruppen som först och främst är barn. Detta har gjortatt projektgruppen har utvecklat ett användargränssnitt som är självklart och enkelt att använda. An-vändartester utfördes i ett tidigt stadium för att få en inblick i hur användaren faktiskt upplevde pro-totypen. Ett formulär togs fram för att föra statistik, samt för att besvara frågor kring hur intuitivtgränssnittet är. Ändringar gjordes sedan i enlighet med feedbacken.

Under projektets gång har gruppen utforskat säkerhetshål och etiska dilemman med ”Web of Trust”och även hur användarupplevelsen kan förändras. Slutsatserna som drogs är att användarupplevelsenutmanas av säkerhetsaspekten, att det finns teoretiska säkerhetshål med ”Web of Trust” men att det ärosannolikt att de utnyttjas. Om appen skulle användas i kriminellt syfte, skulle det gå att kompromissamed myndigheter om hur mycket information om misstänkta applikationsanvändare som ska ges ut,utan att äventyra de andra användarnas integritet.

iii

Ord och begrepp

Ord och begrepp som inte tidigare nämnts markeras genom att skrivas kursivt. Förklaringar till dessafinns i bilaga E.

iv

Innehåll

Tabeller ii

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Rutiner och utveckling 32.1 Utvecklingsmetodik och organisation . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Tidsplan och milstolpar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Refaktorering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Backlogg-hantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.1 Kommentarer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.2 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.3 Mötesprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.7 Granskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.8 Kvalitetssäkring och testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.8.1 Integrationstester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.8.2 Användartester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Användargränssnitt och varumärke 103.1 Initial prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Slutligt gränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Applikationens namn och logotyp . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Relaterat arbete 134.1 Kryptering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Web of trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

v

INNEHÅLL vi

4.3 Facebook Messenger, Instagram och Snapchat . . . . . . . . . . . . . . . . . . . . . 14

5 Verktyg, språk och API:er 155.1 React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2 Node.js, Express och Socket.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Teknisk redogörelse 176.1 Chatt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Profilsida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 QR-skanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.4 Kontaktlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.5 Kryptering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.6 Lokal datalagring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.7 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Resultat 227.1 List-vyn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.2 Chattfönstret och skannern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.3 Profilsida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.4 Välkomstguide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8 Analys och diskussion 268.1 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.3 Källkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.4 Etiska aspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.5 Säkerhetshål i ”Web of Trust” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8.6 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9 Slutsatser 309.1 Användarvänlighet och säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.2 Säkerhetshål i ”Web of Trust” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.3 Kriminella ändamål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Litteraturförteckning 32

A Individuella prestationer 35

B Resultat från användartester 1.0 37

C Resultat från användartester 2.0 42

INNEHÅLL vii

D Det första utkastet av backloggen 45

E Lista över ord och begrepp 46

Kapitel 1

Inledning

Det är vanligt att barn och ungdomar kommer i kontakt med nätmobbing, näthat eller andra tra-kasserier på sociala medier. Följande arbete har som drivkraft att skapa en trygg plats för barn ochungdomar online genom att undersöka om det går att utveckla en krypterad webbapplikation somhindrar användaren från att komma i kontakt med obehöriga personer. Denna projektrapport redogörför arbetsprocessen, utvecklingen och resultatet av den applikationen.

1.1 Bakgrund

Nätbaserad kommunikation via en chatt har länge varit en populär aktivitet, inte minst hos den yngregenerationen. De mest använda chatt-applikationerna som exempelvis Facebook Messenger ger barnoch ungdomar ett enkelt sätt att skapa ett konto, och möjligheten att lägga till sina vänner snabbt. Dettamedför också ett antal risker som kan äventyra barnets säkerhet på internet. Förutom nätmobbingoch trakasserier kan en sådan applikation även skapa en kanal för eventuell nätgromning1. Annanproblematik som kan uppstå i chattsammanhang är att informationen som kommuniceras läcks ut tillobehöriga personer. Det är ofta oönskat att någon annan än just de som chattar ska kunna få tillgångtill informationen, vare sig det gäller illvilliga tredje parter eller själva utgivaren av applikationen.

Därför har projektgruppen fått i uppdrag att utforma en säker webb-baserad chatt med barn 6–16års åldern som den fokuserade målgruppen. Det kommer att kräva att användare träffas fysiskt ochverifierar varandras identiteter för att säkerställa att kontakt etableras mellan två tillförlitliga personer.Tekniker för kryptering ska användas för att se till att informationen som kommuniceras hålls privat,vilket även sätter krav på ett intuitivt och effektivt gränssnitt. På detta sätt kan man minska riskernaför användare i en chatt-applikation, stärka kontrollen över vilka som kan ta del av informationen somskickas och skapa en säkrare miljö på internet.

1.2 Syfte

Syftet med projektarbetet är att utveckla en säker och användarvänlig chattapplikation för barn, däranvändare kan kommunicera med varandra utan att någon obehörig tredje part kan lägga till användareeller ta del av informationen som skickas.

1Refererar till när vuxna människor låtsas vara yngre på nätet för att komma i kontakt med barn och ungdomar.

1

KAPITEL 1. INLEDNING 2

1.3 Frågeställningar

1. Hur kan en säker chatt implementeras så att applikationen är användarvänlig för barn?

2. Vad för säkerhetshål kan uppstå i en chatt-applikation som är baserad på Web of Trust?

3. Hur kan man förhindra att systemet nyttjas för kriminella ändamål, utan att försämra använ-darvänligheten för den tänkta målgruppen?

1.4 Avgränsningar

Applikationen utvecklades för mobiltelefoner och surfplattor som är Android- eller IOS-baserade.Denna avgränsning anses lämplig då majoriteten av mobilanvändare äger en Android- eller IOS-enhet. Applikationen har inte utvecklats till datorer, då en chatt präglas av snabb kommunikation ochmobiltelefoner erbjuder en mer frekvent tillgänglighet hos användarna än en dator. Ytterligare motivtill att utveckla appen för mobiltelefoner är att en kamera krävs vid QR-skanning, vilket de flestamoderna smartphones har.

Gränssnittets avgränsningar fastställs med hänsyn till målgruppen. Detta gör att ett enkelt och naturligtanvändargränssnitt prioriteras, medan komplicerade och avancerade funktioner undviks.

Kapitel 2

Rutiner och utveckling

I stora projekt som detta, när det gäller att få ut största möjliga effekt av ett samarbete i en utveck-lingsgrupp, är det viktigt med en stadig struktur. Då varje gruppmedlem har arbetat i olika projektinnan, med grupper som alla har haft olika arbetssätt och konventioner, var det viktigt för den ny-bildade gruppen att enas i gemensamma rutiner. Den struktur, som gruppen kom överens om, ba-seras på scrum-metodiken, samt regelbundna mötesrutiner, protokollföring, versionshantering i gitoch backlogg-hantering i Trello. Tack vare denna grund av rutiner har gruppen kunnat vila säkra iatt alla gruppens medlemmar utför sina uppgifter på samma sätt. Att det finns en gemensam grundminskar risken för missförstånd och att olika typer av t.ex. versionshantering uppstår, som kan skapaförvirring, ta tid och kräva extra kommunikation för gruppen.

2.1 Utvecklingsmetodik och organisation

Utvecklingsmetodiken som har använts under projektets gång kallas för Scrum-metoden och är envariant av agil utveckling. Scrum innebär att teamet arbetar med ett mål under en viss tidsperiod,en så kallad sprint, som går ut på att göra ett förutbestämt antal uppgifter som bestäms i börjanav perioden. Dessa uppgifter hämtas från en produkt-backlogg, vilket är en lista med uppgifter somska utföras under projektet för att uppfylla kundkraven. Vid gruppens första möte etablerades enpreliminär backlogg som innehöll de större mål och uppgifter som gruppen skulle genomföra, för attuppnå ett önskat slutresultat. Gruppen valde att dela upp uppgifterna i två större områden, front-endoch back-end, för att ge ytterligare struktur i utvecklingsprocessen. Det första utdraget av backloggenkan ses i Bilaga D.

Sprintarnas längd brukar variera från projekt till projekt, men fastställdes här till två veckor. I scrum-teamet sitter, i enlighet med Scrum-guiden [2], en produktägare och en Scrummästare. Produktägarenbestämmer över och ordnar backloggen så att värdet av produkten maximeras, medan Scrummästarenser till att teamet följer Scrumteorin för att maximera Scrumteamets värde. Efter varje avklarad sprinthölls ett återblicksmöte samt ett planeringsmöte inför nästkommande sprint för att reflektera över hurarbetsprocessen gått och för att besluta vilka uppgifter som skulle arbetas med i kommande sprint.Möten med kunden bokades in när det ansågs viktigt att diskutera målet med projektet och se till attkundens och utvecklarnas mål fortfarande stämde överens innan man fortsatte med arbetet.

Roller delades ut mellan gruppmedlemmarna för att styra upp utvecklingen. Dessa kan avläsas i tabell??. Varje medlem har även arbetat med utvecklingen av applikationen, arbetsfördelningen beskrivsöverskådligt nedan och mer omfattande i Bilaga A på sidan 35.

3

KAPITEL 2. RUTINER OCH UTVECKLING 4

Tabell 2.1: Utvecklingsgruppens Roller.

Namn Roll/er

David Eriksson GitmästareBack-end

Josefin Flügge Scrummästare

Johnny Melin KodansvarigFront-End

AndreasSiebmanns

Produktägare/Kodansvarig

Emma Weberyd Sal- ochdokumentansvarig

2.2 Tidsplan och milstolpar

Den överskådliga tidsplanen som sattes upp i början av projektet visas i figur 2.1. Sprint 0 är den förstaarbetsperioden som sätts upp för att skapa en prototyp av applikationen. Sprint 0 estimerades till någotlängre än resten av sprintarna då gruppen ansåg att mycket forskningsarbete och arbetstimmar skullekrävas för att komma igång med en första produkt. Tanken var att när prototypen färdigställdes skulleutvecklarna övergå i att jobba i kortare sprintar för att utveckla den produkt som hade levererats eftersprint 0.

Figur 2.1: Tidsplan - De gröna blocken representerar milstolpar och de blå blocken aktiviteter.

De stora milstolparna som användes som referenspunkt under projektet är följande och kan följas iGantt-schemat i figur 2.1:

1. En prototyp som innehåller ett gränssnitt över de grundläggande funktionerna ska ha skapats.

KAPITEL 2. RUTINER OCH UTVECKLING 5

2. Applikationen ska möjliggöra kommunikation mellan två användare över internet.

3. En ny kontakt ska kunna läggas till genom delning av kryptonyckel då en QR-kod skannas.

4. All data som skickas mellan användare ska AES-krypteras så att en säker chatt skapas.

5. Projektrapporten skall vara inlämnad.

6. Slutgiltig projektrapport skall vara inlämnad och produkten skall anses färdigställd.

Gantt-schemat visade sig vara en bra referenspunkt under arbetets gång. Gruppen kunde hela tidenjämföra arbetets status med hur långt det var tanken att gruppen skulle ha kommit enligt tidsplanen.Dock kortades sprint 0 ned till två veckor efter insikten att det inte skulle bli någon färdig produktunder sprint 0, utan att hela utvecklingstiden skulle gå åt till att skapa en minsta möjliga produkt.Scrum-metoden utgår egentligen ifrån att det redan finns en produkt som utvecklas iterativt i sprinterefter vad som behöver förbättras och i vilken prioritetsordning. Hela arbetet gick ut på att utveckla enförsta produkt, som egentligen redan ska vara färdig när arbetet i Scrum inleds. Men Scrum metodengår att använda även då det ej finns en produkt till en början genom att omdefiniera vad ett inkrementkan innebära. I detta projekt blev ett inkrement en viss färdig produkt men inte den produkt somtotalt reflekterar slut målet. Produkten blev en färdig produkt efter sprint 4 och därmed kunde Scrummetoden användas till sin helhet efter det, det skulle även kunna användas vid vidare utveckling.

2.3 Refaktorering

Under projektets gång har det inte funnits några formella refaktoreringstillfällen utan finslipning avkoden har gjorts löpande. Detta har skett bland annat genom att flera gruppmedlemmar har bearbetatsamma kodmodul samt att koden har granskats, diskuterats och effektiviserats i samband med enfärdig sprint. Refaktorering har också skett genom att se till att kodstycken som återupprepas i kodenskrivs till funktioner eller separata moduler.

2.4 Backlogg-hantering

För hantering av produkt-backloggen användes verktyget Trello. Trello gör det möjligt att skapanamngivna listor med digitala post-it-lappar, som kan flyttas mellan listorna. I projektet användeslistor för att åskådliggöra vilka poster från produkt-backloggen som valts att ingå i den aktuella sprin-ten. Dessa flyttades under sprintens gång till listorna ”Påbörjat” och slutligen ”Färdigt” när en postansågs avklarad. I figur 2.2 syns t.ex. vyn i Trello under Sprint 4, där en rad poster har påbörjats.Tanken är att sprinten är färdig när samtliga av dessa överförts till Färdigt-listan eftersom sprintmåletdå är uppnått. Trello var passande i det här sammanhanget eftersom det ger en överblick över hurarbetet fortskrider och vad resterande gruppmedlemmar gör. Det är även möjligt att förankra speci-fika gruppmedlemmar vid en post i Trello, vilket tydliggör vad de andra i gruppen arbetar med förtillfället.

KAPITEL 2. RUTINER OCH UTVECKLING 6

Figur 2.2: Hantering av backlogg och sprintuppgifter i Trello.

2.5 Versionshantering

Versionshanteringssystemet git har använts för att hantera olika versioner av koden under utvecklings-processen. Git gör det möjligt för ett team att arbeta med flera lokala kopior, av ett utvecklingsprojekt,och att kontrollera när dessa ska sättas ihop till en sammansatt och fungerande produkt. För att undvi-ka onödiga konflikter vid sammanfogning av kod skapades en ny förgrening i början av varje sprint,och för varje uppgift skapades ytterligare en förgrening från sprintgrenen, se figur 2.3. När en upp-gift var testad och ansågs vara färdig sammanfogades den med sprintgrenen igen. Vid en sprints slutsammanfogas sprinten med master-grenen. Detta sätt att hantera versionerna på säkerställer att detalltid finns en fullt fungerade version av applikationen i master-grenen, vilket kan vara användbart dåapplikationen ska användartestas eller visas upp för kund.

Figur 2.3: Flöde för git-rutiner.

KAPITEL 2. RUTINER OCH UTVECKLING 7

2.6 Dokumentation

Dokumenteringen under projektets gång har främst skett genom webbsidan GitHub[1] i sambandmed att uppgifter blivit färdiga och sammanfogats med tillhörande gren. Resterande dokumentationhar skett under de dagliga scrum-mötena samt kommentarer i koden. Mer ingående dokumentationsker i form av README-filer i projektets git-repository.

2.6.1 Kommentarer

Vid projektets start var det önskat av gruppmedlemmarna att använda kommentarer i källkoden föratt öka förståelsen för t.ex. separata komponenter och funktioner. Gruppen upplevde dock svårighetermed hur kommentering sker i React Native, då det verkade som att kompilatorn tolkade kommenta-rerna som kod vilket skapade problem vid körning av applikationen. Detta gjorde att kommentarerundveks i större delen av projektet och fokus lades på uppgifter som ansågs viktigare. I ett senare ske-de kom gruppen underfund med att orsaken till problemet var att det krävs olika slags kommentarerberoende på var i koden de skrivs. Kommentarerna skiljer sig beroende på om de skrivs inom JSX-taggar som är specifika för React Native eller inom ett Javascript-block. Detta eftersom JSX-blockenoch Javascript-blocken översätts på olika sätt av React Native. Eftersom problemet hanterades i ettsent stadie av projektet är koden i viss mån bristfällig gällande kommentarer. Ett försök till att mot-verka detta gjordes genom att lägga till dokumentation om varje komponent i en separat tillhörandeREADME-fil.

2.6.2 GitHub

Dokumentation i form av så kallade commit-meddelanden i GitHub har skett löpande under projektet.Dessa meddelanden består av ett stycke beskrivande text som hör till en färdig uppgift, som blivitsammanfogad med en sprintgren. Där finns även README-filer tillgängliga med mer ingående do-kumentation. Dokumentationen som finns i GitHub tillhör majoriteten av dokumentationen tillgängligför projektet.

2.6.3 Mötesprotokoll

Mötesprotokoll har förts under såväl dagliga sprintmöten som återblicks- och planeringsmöten ochhar varit en betydande del av projektet. Då gruppmedlemmarna ofta arbetat enskilt med specifikasprint-uppgifter har mötena varit ett tillfälle att beskriva vad olika delar av koden gör för resterandegruppmedlemmar. På mötena har det även diskuterats om arbetsprocessen har gått som väntat enligtscrum-metoden och gruppen har tagit beslut gällande vad som ska prioriteras i projektet.

2.7 Granskning

Eftersom utvecklingen främst skett genom att gruppmedlemmarna jobbat enskilt med sprint-uppgifternakrävdes det att koden kontinuerligt granskades av andra gruppmedlemmar. Granskningen utfördes föratt se till att koden följde god programmeringspraxis och var fri från programfel såväl som problem iarkitekturen.

Granskningen skedde främst under sprint-möten då en del av koden skulle sammanfogas med sprint-eller master-grenen genom att den som implementerat koden förklarade denna för resten av teamet.

KAPITEL 2. RUTINER OCH UTVECKLING 8

Granskningen skedde också genom att arbetsområdena roterade mellan medlemmarna vilket krävdeatt fler än en person i teamet blev bekant med en viss del av koden. Vid mer tidskrävande elleravancerade uppgifter användes parprogrammering för att kunna diskutera designval ur flera perspektivoch för kontinuerlig kodgranskning. Gruppen såg till att granskningen gjordes av olika utvecklare såatt inte en ensam utvecklare hade för stort inflytande på slutprodukten.

2.8 Kvalitetssäkring och testning

Inom ramen för Scrum är det önskvärt att det alltid ska finnas en fungerande och kvalitativ version avprodukten i slutet av varje sprint [2], därför var regelbunden testning och kvalitetsförsäkring av storvikt under projektet. Att den implementerade koden höll god kvalitet säkerställdes i viss mån av attden granskades med jämna mellanrum. Förutom att eliminera eventuella fel i programkoden var detockså viktigt att se till att de separata modulerna fungerade tillsammans, samt att implementeringenav applikationen hela tiden stämde överens med kraven och den tänkta målgruppen.

2.8.1 Integrationstester

Integrationstester gjordes i slutskedet av varje sprint för att säkerställa att fristående komponenter varintegrerbara i hela systemet och för att upptäcka eventuella defekter i interaktionen mellan kompo-nenter. På det sättet kunde gruppen försäkra sig om att ett nytt inkrement med fungerande påbyggdfunktionalitet fanns i början av nästkommande sprint.

2.8.2 Användartester

I slutet av den inledande sprinten gjordes användartester för att få återkoppling från utomstående påden första prototypen av applikationen. Denna innehöll endast ett gränssnitt där det var möjligt attväxla mellan olika sidor i appen men utan någon funktionalitet. Meningen med testet var att upptäckabrister i användarvänligheten, se hur intuitiv applikationen upplevdes och att skriva ned generellatankar kring chattapplikationer innan implementationen av appen inleddes.

Testerna utfördes genom att samtliga gruppmedlemmar intervjuade 2-3 studenter var genom att förstställa allmänna frågor om deras internetvanor i chattsammanhang, sedan låta testpersonerna navigerasig fram genom appen efter att ha fått en rad uppmaningar. Resultatet från användartesterna presente-ras i Bilaga B.

Testet utfördes på personer i åldersgruppen 20-25 år, av den anledning att dessa personer var lätta attfå tag i. Det fanns ingen snabb tillgång till barn som kunde testa applikationen i det första skedet. Detvar dock önskvärt att göra detta senare i processen, när applikationen blivit mer fullständig. Trots attåldern 20-25 starkt skiljer sig från målgruppen ansågs det första testet ändå användbart då det endastskulle generera en grundläggande förståelse för hur en generell användare upplevde appen. Mot slutetav utvecklingsprocessen utfördes även tester på barn i åldrarna 10-12 år, se Figur 2.4.

KAPITEL 2. RUTINER OCH UTVECKLING 9

Figur 2.4: Foto från det andra användartestet.

Även i detta test ställdes först generella frågor om testpersonernas internetvanor, och därefter fickde testa applikationen och kommentera sin upplevelse. Resultatet från användartesterna presenteras iBilaga C. Samtliga användartester upplevdes värdefulla och fick gruppen att reflektera över designvali applikationen, vilket går att läsa om i Kapitel 3.

Kapitel 3

Användargränssnitt och varumärke

I ett tidigt skede av projektet diskuterades designval i applikationens användargränssnitt. Eftersom deimplementerade teknikerna för kryptering medför att användaren måste utföra några extra handlingarän den genomsnittliga chattapplikationen, d.v.s. träffas och skanna en QR-kod, är det extra viktigt attgränssnittet är designat så att de handlingarna inte är ett problem för användaren. Gruppen fann ävenatt en annan viktig aspekt är att se till att gränssnittet passar målgruppen. I samband med att designenfastställdes diskuterades det även vilket namn, logotyp och funktioner som passar målgruppen.

3.1 Initial prototyp

Gruppmedlemmarna kom först fram till ett gränssnitt med relativt stora ikoner, ljusblå layout ochavatarer med djur-tema. Denna prototyp gjordes i prototypverktyget Adobe XD och kan ses i figur3.1 och 3.2. De initiala designvalen var grundade i att applikationen skulle ge ett mer barnvänligt ochmindre plottrigt intryck än t.ex. Facebook Messenger samt att erbjuda barnen att välja sitt favoritdjursom avatar. Denna prototyp användes i det första användartestet som beskrevs i Kapitel 2.8.2.

Figur 3.1: Kontaktlistan iprototypen.

Figur 3.2: Chatten utseendei prototypen.

10

KAPITEL 3. ANVÄNDARGRÄNSSNITT OCH VARUMÄRKE 11

Något som gruppen tog med sig från användartestet var att barn kanske inte uppskattar det barnanpas-sade gränssnittet, och hade eventuellt uppfattat designen som för ”barnslig”. En mer ”häftig” design,i dess bredaste bemärkelse, ansågs därefter vara mer passande, då barn och ungdomar ofta har ettbehov av att känna sig äldre och föredrar möjligtvis en mer mogen design.

Gruppen insåg också fördelen med att använda sig av etablerade standarder när element i användar-gränssnittet placeras. Vana mobilanvändare förväntar sig att viss funktionalitet ska stämma överensmed deras tidigare uppplevelser av chattapplikationer, som Facebook Messenger eller Snapchat. Ex-empel på detta är bakåtpilen högst upp till vänster i chattfönstret, som indikerar att användaren återgårtill föregående sida, d.v.s kontaktlistan. En annan standard i chattfönstret är att det placeras en pil tillhöger i textinmatningsrutan som innebär att meddelandet sänds.

Efter användartestet som gjordes på den tänkta målgruppen, visade det sig att barnen hade lätt attutföra de grundläggande funktionerna i appen och att de uppskattade enkelheten. Det kom t.ex fram attde använt Snapchat innan, vilket också erbjuder en form av QR-skanning. En del av barnen hade svårtatt förstå hur man skannade, vilket ledde till att gruppen lade till en ikon och text i navigeringsfältetsom skulle tydliggöra detta. Se figur 3.3. Det visade sig också att de flesta av barnen främst chattademed sina kompisar i olika datorspel, detta ledde till en diskussion om att integrera applikationen ispel. Detta och flera vidareutvecklingsmöjligheter diskuteras vidare i Kapitel 8.

3.2 Slutligt gränssnitt

Efter att ha utfört användartesterna kom projektgruppen fram till en rad förbättringar i gränssnittet.Förutom att implementera fler element som stämmer överens med redan kända chattapplikationer fo-kuserade gruppen på en mer stilren och mörk design för att gå ifrån ett för barnsligt uttryck. Eftersomgruppen ansåg att applikationen fortfarande borde behålla en viss lekfullhet, behölls idén med djurkopplade till användaren, vilket motiveras ytterligare nedan. I figur 3.3 visas några grafiska utdragfrån applikationen. I Kapitel 7 presenteras gränssnittet för samtliga vyer i applikationen.

Figur 3.3: Utdrag av grafiska element från applikationen.

KAPITEL 3. ANVÄNDARGRÄNSSNITT OCH VARUMÄRKE 12

3.3 Applikationens namn och logotyp

Det var önskvärt att applikationens namn och logotyp reflekterade vad som skiljer den från andrachattapplikationer, vilket är ”Web of Trust”-aspekten och att den riktar sig till barn. Gruppen tyckteockså att det var passande med ett lekfullt utseende med tanke på målgruppen. Det bestämdes attapplikationen skulle symboliseras med en nyckel och en kameleont, vilken illustreras i figur 3.4. Tan-ken är att kameleonten symboliserar datasäkerhet med sin förmåga att bli transparent och dölja sig föromgivningen, samt att den gör varumärket mer lekfullt. Eftersom krypteringsnycklar ofta illustrerassom fysiska nycklar ansågs detta visa att applikationen använder krypteringstekniker.

Figur 3.4: Konceptbild och slutgiltig ikon.

Applikationens namn är Mumblr, en variant på ordet mumble, d.v.s. det engleska ordet för att mumlaeller att säga något tyst. Även detta skulle symbolisera att kommunikationen sker utan att någon annankan avlyssna den. Anledningen till den speciella stavningen på ordet är att det är en trend hos mångavälkända onlineportaler, t.ex. använder Tumblr och Flickr en liknande stavning.

Kapitel 4

Relaterat arbete

Det finns inte mycket arbete som är relaterat till detta projekt, för att göra förstudier fick gruppen tadelar av andra projekt och teorier för att sammanfoga dessa till den slutgiltiga produkten.

4.1 Kryptering

För att kryptera användares data används krypteringsalgoritmen AES (Advanced Encryption Stan-dard). Den starkaste varianten av AES algoritmen är AES-256 vilket är den metod som har använtsför kryptering i applikationen. Det som gör denna starkare är att den använder en 256 bitars krypto-nyckel. AES-256 är en symmetrisk blockchiffer[3] som utsetts som standardkrypteringsalgoritm avNIST(National Institute of Standards and Technology)[4]. En nackdel med att använda AES med en256-bitars kryptonyckel jämfört med någon mindre kryptonyckel är prestandan, det är mer tidskrä-vande att kryptera och avkryptera, då det krävs ytterligare två iterationer jämfört med en 128-bitarskryptonyckel.

För att skapa kryptonycklar till användarna skapas ett 256-bitars slumpmässigt hash med SHA-256.Kryptonycklarna används för att såväl kryptera som att avkryptera meddelanden och information somskickas över servern.

AES-256 bygger på algoritmen Rijndael, som använder sig av tre idéer för att kryptera information.Först används substitution, vilket innebär att tecken skiftas med hjälp av en substitutionstabell. Nästasteg är diffusion, som innebär att meddelandet sprids ut med hjälp av matrismultiplikation. Dettautförs i 12 iterationer. Den sista idén är att det enda som hålls hemligt är nyckeln, medan algoritmenär öppen och läsbar av alla.

För att använda AES krävs texten som ska krypteras och en 256-bitars krypteringsnyckel som indata.Tillsammans skapas ett chiffer som sedan kan sparas som en chiffertext, se Figur 4.1. För att avkrypte-ra chiffertexten används chiffertexten och samma krypteringsnyckel där algoritmen används åt andrahållet för att resultatet ska bli detsamma som den ursprungliga texten [5].

13

KAPITEL 4. RELATERAT ARBETE 14

Figur 4.1: Kryptering med AES.

Det har utförts en mängd attacker mot AES men alla framgångsrika attacker har alltid utnyttjat sigav problem i implementation av AES i mjukvaran i sig. En studie som utforskade en teknik kalladBiclique Attack[6] på AES lyckades avkryptera data snabbare än en Brute-force Attack [7]. Men ävendenna metod anses vara för långsam för att användas i praktiken mot data krypterat med AES [5].

4.2 Web of trust

”Web of Trust” är ett koncept som används i samband med PGP [8] lösningar. ”Web of Trust” byggerpå att användare kan dela med sig av krypteringsnycklar till andra använder som de har tillit till.Vanligtvis sker detta digitalt med olika verifikationssystem inbyggda i PGP. I applikationen användsen lösning där ett fysiskt verifikationssystem kräver att användare träffas i verkligheten för att de skakunna starta en chatt med varandra. Denna sortens verifikationssystem för chattapplikationer är ingetsom enligt gruppens kunskap existerar. Anledning till att en produkt likt denna ej existerar kan varaatt detta försämrar användarupplevelsen något då en användare ej kan starta en chatt med någon deej är geografiskt nära. En annan orsak kan vara att det fysiska verifikationssystemet kan upplevas talängre tid och vara mer omständligt än att söka upp en publik användare online.

4.3 Facebook Messenger, Instagram och Snapchat

Användargränssnitt och design har inspirerats av Snapchat, Facebook Messenger och Instagram. Ef-tersom chatt-applikationer är så pass vanliga och användarna redan är vana vid ett visst användar-gränssnitt, är det svårt att göra banbrytande design-förändringar utan att förlora användarvänligheten.Layout och element som liknar dessa standarder användes och anpassades efter systemet i applikatio-nen. Både Facebook Messenger och Instagram är utvecklade i ramverket React Native.

Facebook Messenger, och andra chatt-applikationer på marknaden erbjuder redan krypterad kommu-nikation. Det som skiljer denna app från andra är att den även använder ett ”Web of Trust” för att ökasäkerheten.

Kapitel 5

Verktyg, språk och API:er

Inför utvecklingen av applikationen utfördes en förstudie i vilka ramverk, APIer och algoritmer somkan användas för att förenkla utvecklingen och förbättra slutprodukten.

5.1 React Native

För att utveckla applikationen användes ramverket React Native. [9] Med React Native byggs korsplattforms-applikationer med hjälp av nativ kod. Detta innebär att en kodbas används för att kompileras till se-parata applikationer med hjälp av de nativa biblioteken för apputveckling. De plattformer som ReactNative stödjer är Android och IOS. React Native använder sig av de grundläggande element som an-vänds när en applikation byggs i Objective-C, Swift eller Java. Om behovet uppstår att skriva nativkod för de olika operativsystemen så finns det även möjlighet att göra det.

Det finns tre grundläggande metoder för att utveckla mobilapplikationer:

1. Den första är att utveckla applikationen i det nativa programmeringsspråket, alltså Java förAndroid och Objective-C eller Swift för IOS. Fördelen med den första metoden är att det gene-rellt blir högpresterande kod och utvecklarna får tillgång till alla de inbyggda funktionerna somoperativsystemet tillgår dem.

2. Den andra metoden är att bygga en webbapplikation som konverteras till en applikation. Dennametod är väldigt enkel och snabb för att bygga en applikation, däremot tappar applikationen iprestanda och får ej tillgång till en stor del av den nativa kodbasen.

3. Den sista metoden är den som denna applikation utvecklades med, en metod som använder sigav en kodbas för att sedan bygga applikationen i nativ kod. Denna metod är generellt snabbareatt utveckla i då applikationen till de olika operativsystemen ej behöver utvecklas separat. Menapplikationens prestanda och funktionalitet blir närmare en nativ lösning.

En annan fördel med React Native är att det finns en stor mängd öppen källkod med komponenter somenkelt kan installeras med hjälp av pakethanteraren Npm1. Detta förenklar utvecklingen av produktenavsevärt då det möjliggör att delar av slutprodukten inte kommer att behöva skapas från grunden,då redan befintliga, trovärdiga lösningar kan appliceras. Det faktum att React Native har en bredanvändarbas och är väldokumenterat är också fördelaktigt då det underlättade felsökning av eventuellafel i koden som uppstod under utvecklingsprocessen.

1Node Package Manager

15

KAPITEL 5. VERKTYG, SPRÅK OCH API:ER 16

React Native är ett komponentbaserat ramverk. En komponent är en ensamstående bit av en mjukvarasom kan återanvändas i flera delar av systemet. Detta gör det möjligt att dela kod med andra utveck-lare, Både utvecklare inom en projektgrupp såväl som utanför. Det medför också att applikationenkan hållas uppdaterad genom att byta ut eller skriva om de självständiga komponenterna istället föratt bygga om hela projektet från grunden. [10]

5.2 Node.js, Express och Socket.io

Produktens back-end har utvecklats med hjälp av Node.js[11] med Express[12] och Socket.io[13].Servern som hanterade all kommunikation var en apache-server som kördes på en Raspberry Pi. Fördatabashantering användes MySQL[14].

Node.js är ett eventdrivet ramverk som tillåter JavaScript att användas som ett serverspråk. Gruppenvalde tidigt att använda ramverket Express som är ett minimalistiskt ramverk för Node.js som harde metoder och funktioner som eftertraktades. Express gör det enklare att hantera databasanrop samtatt skapa en RESTful (Representational State Transfer) webbtjänst[15] för att kommunicera mellanmobilapplikationen och databasen. Express förenklar de vanligaste uppgifter en RESTful webbtjänstbehöver så som till exempel dirigering av användaranrop. Dessa uppgifter kan Node.js klara av utanexpress men express ökar utvecklingshastigheten.

Även Socket.io är ett event-drivet ramverk som används för att skapa realtidskommunikation på web-ben mellan webbklienter, t.ex. en React Native applikation, och servrar byggda på Node.js. Socket.iobestår av ett API på klientsidan samt ett API på serversidan byggt på Node.js, där syntaxen på debåda API:erna är närmast identiska. Socket.io är en variant av dataöverföringsprotokollet WebSoc-ket, som tillåter en dubbelriktad kommunikationskanal över en TCP (Transmission Control Protocol)förbindelse[16]. Med hjälp av TCP gör klienten och servern en såkallad ”handshake”[16] det etableraren koppling mellan klienten och servern, efter det kan båda parter kommunicera.

Då projektet avser en chattapplikation är fördelarna stora med att använda ett websocket-ramverk somSocket.io. WebSocket-protokollet stödjs av de flesta stora webbläsare och Socket.io används av fleraframgångsrika bolag som t.ex. Microsoft Office och Trello, vilket indikerar att det är en pålitlig pro-gramvara. Eftersom det är ett kraftfullt ramverk där det mesta sker "under ytan" krävs det få rader kodför att snabbt etablera kanalen mellan klienter och servern. På både server- och klientsidan finns enslutpunkt, så kallad socket, som fungerar som en eventavlyssnare och eventavsändare. Med hjälp avdessa slutpunkter blir det möjligt att sända önskade event, som ett nytt chattmeddelande och se till attandra anslutna slutpunkter som lyssnar mottar eventet och behandlar det därefter, t.ex visar chattmed-delandet på skärmen hos den önskade mottagaren. Eftersom dataöverföringen sker med så pass kortresponstid är det lämpligt att använda i en chattapplikation, som definieras av realtidskommunikation.Då både klient- och serversidan använder snarlika kommandon för att sända ut event underlättar detutvecklingen och förståelsen för ramverket.

En del av projektet har innefattat att implementera redan färdiga bibliotek som finns publicerade pånpmjs hemsida. Men alla bibliotek har inte varit kompatibla med projektet. Detta har gjort att gruppenhar fått testa sig fram med hjälp av olika bibliotek som har samma ändamål. Ett exempel på detta vart.ex. när sökfunktionen skulle implementeras. Det finns ett stort antal bibliotek som tillhandahållersökfunktionalitet med tillhörande sökruta, men alla var inte kompatibla med sättet att rendera chatter-na i hem-vyn. Här testades ett stort antal bibliotek innan en specificerad filtreringsmetod skapades.

Kapitel 6

Teknisk redogörelse

Applikationen som skapades i samband med den här rapporten är en chatt med smarttelefonen somplattform. Det har gjorts förut. Den unika delen av arbetet är att se till att informationen som skickasmellan användare ska vara oåtkomlig för obehöriga, samt att kontakt endast ska kunna etableras mel-lan användare som har träffats i verkligheten. För att säkerställa att informationen som skickas intekan nås av obehöriga, sparas viss information på de enheter som delar chatten och annan informationi databasen. Meddelandena är symmetrisk krypterade, d.v.s. krypteras och avkrypteras med sammaslumpmässigt genererade nyckel, och de lagras sedan krypterade i databasen. För att avkryptera med-delandena måste den slumpmässigt genererade nyckeln användas, och för att endast de behöriga skakunna läsa meddelandena, sparas denna nyckel lokalt i vardera enhet. För att säkerställa att användareendast kan skapa kontakt med personer de träffar i verkligheten, används QR-koder som måste skan-nas av den andra enheten. QR-koderna innehåller bland annat den chattspecifika krypteringsnyckeln,och genom att dela den kan båda parterna läsa varandras meddelanden.

Att skapa kontakt med en annan användare, sker i tre huvudsakliga steg. Låt personen som skaparchatten kallas för användare 1, och personen som ansluter till chatten för användare 2. Låt derasenheter benämnas som enhet 1, respektive enhet 2. Steg 1 innefattar skapandet av ett tomt chattfönsterhos användare 1, då hen klickar på ikonen med ett stort plustecken. Då görs ett anrop till servernatt skapa en ny chatt i databasen, samt att skicka tillbaka ID-numret som genereras vid skapandetav chatten. Chattens unika ID-nummer, namnet på användare 1, samt en slumpmässigt genereradkrypteringsnyckel skickas som en sträng till en komponent som konverterar innehållet till en QR-kod.Applikationen som är öppen i enhet 1 navigerar sedan till chattfönstret, och QR-koden visas i fältetdär meddelanden senare ska kunna skickas. Såhär långt är chatten ännu inte aktiverad och det går inteatt skicka meddelanden så länge det inte finns någon mottagare.

Steg 2 är en typ av handskakning, det innebär att användare 1 och 2 delar en krypteringsnyckel förframtida kommunikation. Det utförs från enhet 2 genom att användare 2 skannar QR-koden som visaspå enhet 1. Ett anrop går då ut till servern som talar om att chatten nu är aktiv. Att chatten blir aktivgör att det går att skriva i den, samt att QR-koden försvinner i enhet 1. Det är viktigt att QR-kodenförsvinner så att ingen annan ska kunna ta del av den. Den visas en gång och sedan är den gömdför alltid, vilket minimerar risken för att krypteringsnyckeln ska kunna delas vidare. Informationom chatten sparas nu lokalt i enheten med hjälp av biblioteket AsyncStorage, som beskrivs i detalji Kapitel 4.6. Informationen består av krypteringsnyckeln, namnet på användare 1, samt ID-numretsom är unikt för chatten. Krypteringsnyckeln sparas lokalt för att den endast ska kunna nås av de somhar chatten sparad lokalt på enheten. Namnet på den andra personen sparas för att det ska dyka uppi titelfältet i chattfönstret så att det blir tydligt vem som chattas med. ID-numret sparas lokalt för attden ska kunna mappas till vilka meddelanden som ska hämtas från databasen till den aktuella chatten.Efter att informationen har sparats i enhet 2, navigeras även användare 2 till chattfönstret där namnetpå användare 1 visas högst upp i fönstret. Ett sekvensdiagram för steg 2 visas i figur 6.1.

17

KAPITEL 6. TEKNISK REDOGÖRELSE 18

Figur 6.1: Sekvensdiagram som beskriver hur komponenterna kommunicerar då QR-koden skannas.

Steg 3 återgår till enhet 1. Efter att användare 2 har anslutit sig till chatten måste chatten sparas äveni enhet 1. Anledningen till att detta inte görs i steg 1 är för att det inte ska gå att spara chatter somsedan inte ansluts till. Om chatten hade sparats lokalt i steg 1 hade det funnits risk för att en tom ochej ansluten chatt hade legat kvar i enheten. Chatten sparas därför lokalt så fort enhet 1 får informationfrån servern om att enhet 2 har anslutit sig till chatten. I samma veva får enhet 1 ta del av namnetpå användare 2 så att titeln i chattfönstret kan ändras till namnet på den som chattas med. QR-kodenförsvinner även i och med att chatten har anslutits. Nu är båda personerna anslutna till samma kanaloch kan börja kommunicera med varandra utan intrång från oinbjudna parter, se figur 6.2.

Figur 6.2: Sekvensdiagram som beskriver hur komponenterna kommunicerar i enhet 1 efter att QR-koden har skannats av enhet 2.

6.1 Chatt

Det första användaren ser när hen har skapat en chatt är en QR-kod. För att generera QR-koden använ-des biblioteket react-native-qrcode. Biblioteket tar emot en sträng och med den strängen genererar enQR-kod. Informationen som skickas med i QR-koden är användarens namn, rummets ID och krypto-nyckeln. Eftersom biblioteket för generering av QR-kod endast tar emot en sträng måste ID-numretförst konverteras till en sträng och sedan måste de tre variablerna konkateneras till en enda sträng. Föratt underlätta för avläsningsalgoritmen i skannern finns en förutbestämd separator mellan variablerna.Detta gör att skannern enkelt kan dela upp strängen vid varje separator, och variablerna kan därförsparas som tre skilda strängar. Separatorn består av tre understreck, och valdes till dessa tre tecken dåde sällan förekommer i ett namn eller kryptonyckeln, och aldrig i ID-numret.

När användaren skickar iväg ett meddelande krypteras det först innan det skickas iväg. När medde-landet väl är skickat så skickas det inte direkt till personen som chattas med, utan den läggs upp på en

KAPITEL 6. TEKNISK REDOGÖRELSE 19

server. När meddelandet nått servern så hämtar personen som är länkad till samma chattrum medde-landet från servern ned till sin egen enhet. Innan meddelandet visas så avkrypteras det först med hjälpav kryptonyckeln.

6.2 Profilsida

Här kan användaren skriva in eget namn, favoritfärg och även ändra kameleont till profilen och väljavilken färg den ska vara. Denna information sparas lokalt på enheten för att sedan kunna användas vidgenerering och skanning av QR-kod. Då namnet på användaren kommer bli namnet på chattrummetbehöver variabeln skickas med antingen i QR-koden eller efter skanningen. Den unika profilbildensom användaren valt används i chattflödet bredvid varje meddelande som skickas. Användaren kanmodifiera sin egen kameleont genom att klicka på knappen ”ändra kameleont”. Där kommer en färg-palett upp i form av en cirkel och två reglage. Användaren använder paletten för att justera önskadfärg på kameleonten och reglagen för att justera hur mörk/ljus färgen ska vara. När hen känner signöjd med valet av färg klickar hen på den färgade cirkeln i mitten av paletten för att applicera färgenpå kameleonten. För färgpaletten används ett bibliotek för React Native kallat Color Picker.

6.3 QR-skanner

Skannern har en egen funktion för att separera alla variabler från QR-koden med hjälp av separatorn.Dessa variabler sparas sedan lokalt och används för att navigera korrekt till rätt chatt, där variablernaföljer med så att rätt chattnamn visas och rätt krypteringsnyckel appliceras på meddelanden. Efter attskanningen genomförts skickar enheten iväg sitt eget namn till servern så att personen som skapadeQR-koden kan på sin egen enhet veta vem det är som hen chattar med. När en QR-kod har blivitskannad skickas en notis till servern att det finns fler än en användare som är kopplad till chatten,därefter aktiveras chattrummet på servern. Skulle ett chattrum skapas men aldrig bli aktiverat så tasdet bort från servern efter en timme. Detta har implementerats för att inte mängder av tomma chatterskapas som sedan ligger på servern och aldrig används.

6.4 Kontaktlista

Kontaktlistan byggs upp av en lista med aktiva chatter, inaktiva chatter (chatter som aldrig mer änen person är med i) läggs aldrig till i listan. Längst ner i högra hörnet av vyn finns en knappt som ärfixerad och följer med i skrollningen av listan. Denna knapp är till för att skapa nya chatter.

6.5 Kryptering

Applikationen använder sig av symmetrisk kryptering, detta innebär att användarna som skriver tillvarandra använder sig av samma nyckel vid kryptering som avkryptering av data. Vid krypteringenanvändes AES kryptering. För detta har ett bibliotek i React-Native använts kallat react-native-aes.Vid krypteringen fanns alternativet att kryptera i olika antal bitar 128, 192 eller 256. För att göraapplikationen så säker som möjligt användes 256 bitar vid krypteringen.

KAPITEL 6. TEKNISK REDOGÖRELSE 20

6.6 Lokal datalagring

Informationslagringen som sker i applikationen lagras med hjälp av biblioteket Asyncstorage. Asyncsto-rage lagrar data okrypterat globalt på enheten vilket innebär att informationen som lagras i enheten äröppen för resten av telefonen. När information sparas lokalt använder sig Asyncstorage av ett nyckel-system där all information kopplas samman med en unik nyckel. När information sedan hämtas frånden lokala lagringen anges endast nyckeln till Asyncstorage och med hjälp av den returneras önskaddata [19].

6.7 Back-end

För att utföra de operationer som nämns ovan behöver applikationen kommunicera med en server. Tillen början användes ett fetch [20] API för att hämta data, problemet med detta är att det är en envägs-kommunikation mellan klient och server. Alltså måste klienten be om data för att få den, servern kaninte skicka information själv. En lösning på detta problem var Socket.IO. Genom att använda Soc-ket.IO blev det möjligt för tvåvägskommunikation och därmed kunde servern skicka meddelandenmellan klienterna direkt. Fetch API användes fortfarande för viss typ av back-end kommunikation dåtvåvägskommunikation ej var behövligt, till exempel för att skapa en chatt.

Databasen innehåller se tabell 6.1.

Tabell 6.1: Databas schema för mumblr.

chatts

roomID- Chattrummetsunika id (heltal)

connected- Är chattensammankopplad?(boolesk)

reg_date- tid då chatten re-gistrerats (datum)

connected_name- Namnet påanvändaren somskannar (sträng)

one_token- Token för an-vändaren somskapade chatten

two_token- Token föranvändarensom gick med ichatten

chatt_messages

roomID- Chattrummetsunika id (heltal)

message- Meddelan-det som skic-kats(sträng)

sentby- Vilken användersom skickat med-delandet (heltal)

send_time- Tiden då med-delandet skicka-des (date)

Varje gång en ny chatt startas så läggs det till i tabellen ”chatts” där parametrarna ”connectec_name”och ”roomID” är krypterade med chattens krypteringsnyckel. Om en användare skulle skapa en chattsom ingen annan användare kopplar till så försvinner chatten ur databasen efter 30 minuter. Närchatten är ihopkopplad sparas även ett token för båda användarna dessa används som adresser för attskicka notiser till användaren när ett meddelande skickas. Detta görs med hjälp av Expos notifikationsAPI [21].

När en användare skickar ett meddelande sparas det i tabellen ”chatt_messages” där parametrarna

KAPITEL 6. TEKNISK REDOGÖRELSE 21

”roomID” och ”message” är krypterade. Alla meddelanden som skickas i applikationen hamnar idenna tabell och de särskiljs med hjälp av ”roomID”. Det är av stor vikt att den information som kanvara identifierade eller känslig är krypterad på så sätt skyddas användaren från såväl utvecklar somdataintrång.

Kapitel 7

Resultat

Resultatet av projektet är en applikation som är avsedd för säker kommunikation mellan barn på nätet.Denna applikation ska vara ett alternativ till de tidigare nämnda applikationerna i kapitel 4.3. Grund-kraven för denna applikation lägger störst vikt på säkerhet och faktorer som skyddar användaren. Näranvändaren öppnar appen möts hen av list-vyn som visas i figur 7.2. Menyn som syns längst ner påskärmen erbjuder användaren möjligheten att navigera mellan de olika vyerna i figurerna 7.1, 7.2 och7.3 genom att, antingen trycka på de olika valen, eller genom att svepa med fingret över skärmen.

Figur 7.1: Profil-vyn. Figur 7.2: List-vyn med chatter. Figur 7.3: Skanner-vyn.

Om användaren klickar på någon av de befintliga chatterna som ligger i list-vyn i figur 7.2, förs henvidare till ett fönster som visar chattmeddelanden skrivna mellan de användare som är anslutna tillchatten. Klickar användaren på plustecknet skapas en ny chatt som en annan användare kan anslutasig till. Chattfönstret innehåller en QR-kod med den information som behöver skickas över till denanslutande användaren för att de ska kunna börja chatta med varandra. Personen som ska ansluta sigtill chatten använder sig av skannern, i figur 7.3, som öppnar kameran för att enheten ska kunna läsaav QR-koden och på så sätt skapa kontakt. Därefter kan användarna tryggt chatta med varandra.

22

KAPITEL 7. RESULTAT 23

7.1 List-vyn

Figur 7.2 visar den vy som är synlig när applikationen precis öppnats. Här möter användaren enkontaktlista av alla aktiva chatter, sorterade så att den senast använda chatten är placerad högst uppi vyn. Ovanför listan med chatter finns det en sökfunktion, som erbjuder användaren möjligheten attsöka efter en specifik chatt, vilket gör det lättare att få åtkomst till de chatter som har hamnat längrener i listan p.g.a. inaktivitet. Huvudsyftet med list-vyn är att få en överblick av de befintliga chatterna,att kunna gå in i valfri chatt, och att skapa en ny chatt.

7.2 Chattfönstret och skannern

En QR-kod genereras i samband med att användaren skapar en ny chatt, och skannas av en annananvändare för att etablera kontakt. Denna process resulterar i att varsitt chattfönster öppnas hos an-vändarna och de kan börja skriva till varandra.

Figur 7.4: Nyskapad, oaktiveradchatt.

Figur 7.5: Skanner-vyn då nychatt skannas.

Figur 7.6: Chatten när den är an-sluten.

Den tekniska beskrivningen för hur en ny chatt skapas och hur chatt-vyn och skannern samarbetar,finns i kapitel 6. Där omnämns skaparen av chatten som användare 1, och personen som ansluter tillchatten som användare 2. Deras enheter kallas för enhet 1, respektive enhet 2. Figur 7.4 visar hur detser ut i enhet 1 precis efter att chatten har skapats. Namnet på chatten är ännu inte fastställt och detgår heller inte att skriva något i chatten, då dessa funktioner kräver att en annan användare har anslutitsig till chatten. För att användare 2 ska kunna ansluta sig till chatten behöver hen öppna skanner-vynoch hålla sin enhet över enhet 1, som i figur 7.5, för att QR-koden ska kunna avläsas. Omedelbartefter att QR-koden har skannats av enhet 2, byts platshållaren för chattens namn ut till den anslutnaanvändarens namn i enhet 1, och enhet 2 navigeras till den instans av chattkomponenten som tillhörden nyskapade gemensamma chatten. Användarna kan nu chatta säkert med varandra.

KAPITEL 7. RESULTAT 24

7.3 Profilsida

Namnet på chattfönstret bestäms utifrån det namn som har skrivits in på profilsidan i den andra enhe-ten. Figur 7.7 visar vyn för profilsidan. Här kan användaren skriva in sitt namn och välja att redigerasin avatar. När användaren väljer alternativet ”Redigera avatar” nås sidan som visas i figur 7.8 därfärghjulet används för att välja färg och avatarens ansiktsuttryck kan varieras mellan tre ansikten vidett knapptryck.

Figur 7.7: Profil-vyn för applika-tionen.

Figur 7.8: Vyn som visas för attredigera avataren.

7.4 Välkomstguide

För att användaren enkelt ska komma igång och använda applikationen skapades en välkomstguide.Första gången användaren startar appen är enda gången som denna öppnas. Figurerna 7.9, 7.10 och7.11 visar olika delar av hur välkomstguiden ser ut. I välkomstguiden får användaren bekanta sig medhur de startar en chatt och hur de kopplar sig till en chatt, de får även fylla i sitt användarnamn ochredigera sin avatar. Det finns mer funktionalitet som ej beskrivs i välkomstguiden men gruppen valdeatt endast demonstrera det väsentliga så att användaren får utforska resterande funktionalitet själv.

KAPITEL 7. RESULTAT 25

Figur 7.9: En välkomstskärmsom användaren möter förstagången appen öppnas i enheten.

Figur 7.10: En vy som är del avvälkomstguiden, där användarenfår välja färg på avataren.

Figur 7.11: En vy som är del avvälkomstguiden, där användarenfår fylla i sitt namn.

Kapitel 8

Analys och diskussion

I detta kapitel diskuteras och analyseras utvecklingsprocesserna och det förväntade resultatet av pro-jektet. Frågor kring förbättring av resultat och tillvägagångssätt för detta kommer även tas upp.

8.1 Metod

Som utvecklingsmetodik valdes Scrum-metoden för att skapa de bästa möjliga förutsättningarna föreventuella förändringar i utvecklingskraven under projektets gång. I början av varje sprint finns detnämligen möjlighet att revidera lösningar som tillämpats i föregående sprint. Det ansågs också attScrum-metoden skulle maximera möjligheten till granskning och återkoppling från kunden, vilket isin tur skulle minimera risken för att produkten skulle avvika från önskemålen vid leverans. Tankenvar alltså att ett möte med kunden skulle äga rum i slutet av varje sprint. Den här idén följdes inte vidvarje sprint då det ofta ansågs överflödigt eftersom det redan, vid ett tidigare möte, diskuterades hurapplikationen skulle fungera och vad som skulle levereras i de senare sprintarna.

Inledningsvis hade projektgruppens medlemmar svårigheter att uppskatta hur lång tid uppgifterna i ensprint skulle ta. Detta eftersom gruppens medlemmar inte tidigare hade arbetat med applikationsut-veckling i ramverket React Native. Projektgruppen uppskattade t.ex. att den inledande sprintens målskulle ta betydligt längre att nå än det slutligen gjorde. Eftersom det var en överskattning och inteunderskattning löstes problemet enkelt genom att starta nästa sprint tidigare.

Backlogg-listan var inledningsvis tänkt att inte uppdateras särskilt frekvent utan endast för att beskrivanågon av posterna mer i detalj. Även om det hade varit önskvärt att ha en statisk backlogg att kunnahämta sprint-uppgifter ifrån under hela projektets gång visade det sig svårt i praktiken, då mycket avden önskade funktionaliteten i applikationen var tydlig först när gruppen var mitt i processen.

Eftersom projektgruppen valde att arbeta med agil systemutveckling fanns det möjlighet att flytta omde milstolpar som sattes ut om det var absolut nödvändigt. Det arbete som inte lyckades bli klartinom tidsramen för en sprint, valdes istället att placeras i nästkommande sprint, med högre prioritet.Detta gjorde att de nya uppgifterna kunde påbörjas så snabbt som möjligt i den nya sprinten. Dedagliga Scrum-mötena gav gruppen struktur i utvecklingsprocessen och en bra överblick för vilkauppgifter som utförts och vilka uppgifter som skulle göras. Det var även under Scrum-mötena somuppgifter förtydligades om det var något som behövdes tas upp, vilket gjorde att gruppen kunde arbetamer enhetligt. Sprint-återblickarna var värdefulla eftersom arbetsprocessen utvärderades och gruppenkunde lära sig från misstag i sprint-planeringen och optimera arbetet i nästa sprint.

26

KAPITEL 8. ANALYS OCH DISKUSSION 27

8.2 Resultat

Det förväntade resultatet var en simpel applikation med grundläggande funktionaliteter för ett så intui-tivt och enkelt användande som möjligt. Resultatet bemötte de förväntningar som gruppen hade införutvecklingen av applikationen, eftersom de primära funktionerna som önskades implementerades. Se-kundär funktionalitet valdes bort då gruppen ville lägga mer tid på att få de huvudsakliga funktionernaså klara och felfria som möjligt. Om tidsramen för projektet hade varit större skulle mer tid ha ägnatsåt att förbättra redan implementerade funktioner, samt lägga till ytterligare funktionalitet. Vid projek-tets början fanns det exempelvis planer på att appen skulle erbjuda grupp-konversationer, men dettaprioriterades snabbt bort då det blev tydligt att det skulle kräva att delningen av kryptonycklar skullebli mer avancerad och därmed alltför tidskrävande.

8.3 Källkritik

Majoriteten av de källor, som har använts för detta projekt, är hämtade från internet. Val av källorfrån webbsidor eller online-artiklar har baserats på trovärdighet hos författare, hur tidsaktuell käl-lan är, samt hur bred användarbas den eventuella hemsidan har. Gruppen har även försökt användautvecklingsspråkens egen dokumentation så mycket som möjligt.

Användning av bibliotek för React Native har varit en stor del av applikationsutvecklingen. Arbets-processen har innefattat att testa om det önskade biblioteket är kompatibelt med applikationen, vilkethar inneburit mycket trial and error. De programfel som uppstod vid programmeringen gick ofta attlösa med hjälp av andra utvecklare som stött på liknande problem genom olika programmeringsfo-rum. Det mest frekvent använda forumet var Stack Overflow, vilket är en mycket välanvänd plattformdär utvecklare hjälper varandra med vanligt förekommande programmeringsfel. Stack Overflow fun-gerar så att de mest uppskattade svaren röstas fram av andra användare, och på så sätt nås ofta välbetrodda lösningar.

8.4 Etiska aspekter

Då applikationen erbjuder en säker tjänst som inte ska kunna utsättas för dataintrång eller avlyssning,finns det risk för att detta kan komma att nyttjas för kriminella ändamål. Om gruppen skulle väljaatt skapa en bakdörr i krypteringsmetoden för att tillåta polis och annan myndighet att få tillgång tillen misstänkts information, skulle dock denna bakdörr kunna användas av andra intressenter. Dettascenario var en stor debatt år 2016, då FBI krävde att Apple skulle skapa en bakdörr i iOS enheter,vilket Apple vägrade göra, med stöd av några av de största teknikbolagen i världen[26]. Det someventuellt skulle kunna göras, vid samarbete med polis, är att ge ut IP-adresser från den misstänktesuppkoppling. Skulle den misstänkte använda sig av en VPN tunnel[27], vilket är en vanlig metod föratt skydda sin identitet på internet, skulle dessa IP-adresser dock inte vara till någon hjälp.

Om en användare skulle uppleva att någon beter sig oetiskt eller på något sätt skulle bryta mot lagenvore det fördelaktigt om det fanns möjlighet att blockera och anmäla användaren. Funktioner somsådana finns inte för tillfället men skulle kunna implementeras. Användaren skulle i så fall då avkryp-tera informationen åt den myndighet eller organisation som ska hantera ärendet. Problemet med dettaär att det kan anses strida mot principen att den data som anges i applikation endast kan läsas av desom de är ämnade till. Då funktionerna inte existerar i produkten i dagsläget är det inget problem,men ett etiskt dilemma som måste lösas i ett vidare sammanhang.

KAPITEL 8. ANALYS OCH DISKUSSION 28

8.5 Säkerhetshål i ”Web of Trust”

Originaltanken med ”Web of Trust” är att användarna måste dela krypteringsnyckel med de som devill kunna kommunicera med online, och att deras identitet ska verifieras på något sätt för att säker-ställa att nyckeln delas med rätt person. Det lämnar egentligen ett ansvar hos användaren att bedömaom personen som hen skapar kontakt med är godkänt verifierad. Det har diskuterats en del, i projek-tet, om det verkligen går att säkerställa helt och hållet att personen som användaren skapar kontaktmed verkligen är den som hen utger sig för att vara. I projektets implementation av ”Web of Trust”används QR-koder för att dela informationen, med fördelarna att det går snabbt att dela en flera bi-tar lång nyckel, samt att den inte är läslig för det mänskliga ögat, och kan på så sätt inte kopierasgenom att någon får syn på den. Meningen är också att QR-inläsningen ska tvinga användarna tillatt träffas i verkligheten för att lägga till varandra i appen. Med viss ansträngning kan QR-kodernadock teoretiskt sätt spridas till en obehörig tredje part, och skannas på avstånd. Detta kräver dock attpersonen som skannar QR-koden är en illvillig person som hjälper en obehörig person, genom attfotografera QR-koden för spridning. Det skulle också kräva att personen som delar sin chatt stannar iden öppnade chatten tills den illvilliga personen fått tag i och skannat QR-koden på avstånd. Chattenförsvinner nämligen om användaren går ut ur chatten innan den blivit skannad, och det är inte särskilttroligt att användaren går omkring med chatten öppen tillräckligt länge för att ett intrång efter sprid-ning av QR-koden skulle hinnas med. Skulle det dessutom vara så att användaren tvivlar på den andraanvändarens pålitlighet, kan personen radera chatten.

För att göra ”Web of Trust”-algoritmen ännu mindre genomträngbar skulle eventuellt animerade QR-koder kunna användas, som alltså ändras över tid. Detta skulle göra det omöjligt att skapa kontaktgenom att skanna ett foto av en QR-kod, eftersom den omedelbart förlorar sin giltighet.

En annat möjligt hål är att det går att ta en skärmdump av QR-koden, och eventuellt skicka vidareden till en obehörig person. För att förhindra denna typ av spridning skulle det gå att använda någotliknande ”FLAG_SECURE”, vilket är en befintlig funktion i Androids API, som hindrar användarenfrån att ta en skärmdump [24]. Detta implementerades dock inte eftersom användaren ändå skullebehöva gå ur den tomma chatten för att kunna skicka koden till någon, och så fort chatten stängs såraderas den ändå från enheten och QR-koden blir då ogiltig.

En möjlig alternativ lösning till QR-koder som diskuterades under projektet är NFC (Near Field Com-munication), som ofta används utbytbart med QR-koder i marknadsföringssyfte. Fördelen med NFC,i jämförelse med QR-koder, är att kommunikationen inte är visuell och kan därför inte spridas genomfotografi. NFC kommunicerar istället via radiovågor och antennen anpassas så att den endast tar emotinformation på väldigt kort avstånd, vilket gör att risken för avlyssning är liten [25]. Denna lösningimplementerades dock inte i projektet då NFC-läsare inte finns i alla smartphones, vilket hade gjortprodukten obruklig.

Informationen angående chatter och dess krypteringsnycklar lagras lokalt på enheten med AsyncSto-rage. Det finns en teoretisk risk att någon skulle ta sig in i mobilens lokala hårddisk och kopierakrypteringsnycklar. Har kryptonycklarna kopierats finns det inget som stoppar den som har nycklar-na från att läsa materialet i chatterna. Detta skulle kunna förhindras genom att använda ett säkrarelagringssystem än AsyncStorage. En annan teoretisk lösning är att också kryptera informationen somligger sparat på enheten, men det skapar å andra sidan en ny diskussion om om var den nya krypte-ringsnyckeln skulle sparas.

Att krypteringsnycklarna sparas lokalt i AsyncStorage är ett problem som är specifikt för denna ap-plikation men den visar ett problem med ”Web of Trust”-tekniken, krypteringsnycklarna måste sparasnågonstans. Applikationen blir därmed lika säker som det förvaringssystem som det använder.

KAPITEL 8. ANALYS OCH DISKUSSION 29

8.6 Arbetet i ett vidare sammanhang

Gränssnittet är avsett för barn, men kan användas av alla åldrar med en ny design som är mer pas-sande för ett professionellt och seriöst användande. Det kan vara t.ex. större företag som vill användaapplikationen för att försäkra sig om att allmänheten inte får ta del av klassificerad information.

Det som skulle vara bra att implementera i applikationen är en automatisk ökning av skärmstyrkan påanvändarens enhet när hen går in på skanning-vyn. Eftersom applikationens huvudmålgrupp är barnkan det inte antas att målgruppen ska vara medveten om att en låg ljusstyrka på enheten kan varaorsaken till att den optiska inläsningen inte fungerar.

Den applikation som utvecklats är avsedd att användas av barn för att ge dem skydd mot de faror somexisterar vid användning av internet. Men applikationen har även en destruktiv sida, den kan användasav kriminella för säker kommunikation gällande utförande av illegala aktiviteter. Detta var något somgruppen diskuterade i ett tidigt stadium av projektet. De chattloggar som sparas är krypterade men dehar en tillhörande IP-adress och den kommer alltid att finnas med oavsett krypteringssätt. Med dennainformation kan man lokalisera varifrån ett meddelande har skickats. Om polis på något sätt lyckas fåreda på att applikationen används för illegalt bruk, kommer ett fullt samarbete ske med polisen ochrelevanta IP-adresser kommer delas ut. Denna information kommer att finnas med i användarvillkorenför applikationen. Användarvillkoren uppstår i ett nytt fönster i samband med att man lägger till sinförsta kontakt i applikationen.

För att applikationen ska vara konkurrenskraftigt på marknaden finns det ett antal tilläggsfunktionersom användarna skulle kunna förvänta sig. Några sådana funktioner fick prioriteras bort på grund avtidsbrist, men är intressanta i ett vidareutvecklingsperspektiv. En av de funktionerna är möjlighetenatt dela filer så som bilder, videos och dokument. Eftersom applikationens fokus är säkerhet måsteäven dessa filer krypteras och hanteras på ett säkert sätt. För att hantera den mängden data som dettaskulle innebära skulle serverstrukturen behöva utvecklas, framförallt skulle större hårddiskar behövainstalleras för att lagra de filer som ska hanteras. En metod för att minska lagringen skulle vara attimplementera ett system där bilder och videos endast är tillgängliga i en viss tid, för att sedan kommaatt raderas från servern. Detta skulle även kunna bidra till en säkrare bild- och videodelning då deinte finns kvar i all framtid. En annan funktionalitet som användarna tar för givet är möjligheten tillgrupp konversationer vilket också är något som har diskuterats inom projektgruppen men valdes bortpå grund av tidsbrist.

Den här tekniken skulle kunna utvecklas för spelföretag och speldistributörer som t.ex. spelbiblio-tekstjänsten Steam[17] där användarna skulle kunna välja att endast göra vänförfrågningar om de fy-siskt träffas. Det kan vara ett bra alternativ för föräldrakontroll så att barn inte spelar med människorde ej känner. Enligt en studie gjord av organisationen Friends, år 2015, är mobbning och trakasseriöver spel ett allt vanligare problem. Inom spelvärlden är det inte ovanligt att det används en grovjargong som kan anses vara olämplig för barn och ungdomar [18]. Med hjälp av denna teknik skulleföräldrar och barn känna sig säkra på att de som de spelar med endast är folk som de faktiskt känner.

Kapitel 9

Slutsatser

Efter att ha genomfört utvecklingsprojektet kan samtliga frågeställningar som ställdes inför arbetetbesvaras. Frågeställningarna var följande:

1. Hur kan en säker chatt implementeras så att applikationen är användarvänlig för barn?

2. Vad för säkerhetshål kan uppstå i en chatt-applikation som är baserad på Web of Trust?

3. Hur kan man förhindra att systemet nyttjas för kriminella ändamål, utan att försämra använ-darvänligheten för den tänkta målgruppen?

9.1 Användarvänlighet och säkerhet

För att applikationen ska vara säker enligt de initiala kraven behöver två klienter träffas i verklighetenför att de ska kunna skapa en chatt. Vid jämförelse med t.ex. Facebook Messenger, som enligt använ-darstudien är en populär tjänst just på grund av hur smidigt det är att ta kontakt med någon, kräverdenna app fler steg för att lägga till kontakter. Om förväntan på appen är att det ska gå att söka uppvem som helst i appen för att skapa kontakt, kan denna app kännas svåranvänd. För att kompenseraför eventuell försämrad användarvänlighet, har ett stilrent och lättnavigerat gränssnitt implemente-rats. För att användaren ska anse att det är värt att utbyta en viss användbarhet mot säkerhet är det avstörsta vikt att processen är så enkel som möjligt för användaren. Därför spenderades mycket tid påatt göra funktionen för att lägga till en ny chatt så smidig som möjligt. Efter användartester utfördesblev det tydligt att målgruppen är vana mobilanvändare och om applikationen designas med vanligtförekommande element skulle användargränssnittet vara användarvänligt och passa målgruppen.

9.2 Säkerhetshål i ”Web of Trust”

Den största potentiella risken med ”Web of Trust” är att protokollet för att verifiera identiteten hosden andra användaren inte är tillräckligt säkert. En risk som upptäcktes i den projekt-specifika im-plementationen av ”Web of Trust” är att QR-koderna teoretiskt sätt kan spridas vidare till obehörigapersoner, och att kontakt då kan skapas utan att personerna träffas i verkligheten. Sannolikheten fördetta är dock liten då det kräver att användaren inte kan lita på personen som hen ska lägga till somkontakt, vilket är motsägelsefullt då personen antagligen endast vill lägga till pålitliga personer.

Då viss information om chatterna sparas lokalt i enheten med AsyncStorage, finns det risk för attintrång på den lokala enheten också ger tillgång till krypteringsnyckeln, vilket skulle ge förövaren

30

KAPITEL 9. SLUTSATSER 31

möjlighet att ta del av meddelanden. Detta skulle kunna förhindras genom att skapa ett säkrare lag-ringssystem än AsyncStorage.

9.3 Kriminella ändamål

Det är svårt att aktivt förhindra att detta system utnyttjas för kriminell aktivitet. En metod för attej försämra användarupplevelsen och bibehålla samma säkerhet är att endast ge ut IP-adressen aven misstänkt uppkoppling till servern, en IP-adress kan sällan bidra till en identitetsbeskrivning, detskulle därmed troligtvis inte vara speciellt hjälpsamt.

Litteraturförteckning

[1] GitHub, Inc., GitHub, Hämtad: 2018-05-25https://github.com/

[2] Ken Schwaber och Jeff Sutherland, Scrumguiden, Scrum.Org och ScrumInc, Publicerad:2013-06 Hämtad: 2018-06-18.http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-SE.pdf

[3] Morris J. Dworkin, Elaine B. Barker, James R. Nechvatal, et. al. Advanced Encryption Standard(AES) , Publicerad: 2001-11-26 Hämtad: 2018-02-14.https://www.nist.gov/publications/advanced-encryption-standard-aes

[4] William E. Burr, Selecting the Advanced Encryption Standard (AES): Raising the Bar forCryptography.,Publicerad: 2003-03-01 Hämtad: 2018-02-14.https://www.nist.gov/publications/selecting-advanced-encryption-standard-aes-raising-bar-cryptography

[5] Margaret Rouse, Advanced Encryption Standard (AES), Senast redigerad: 2017-03 Hämtad:2018-05-25.https://searchsecurity.techtarget.com/definition/Advanced-Encryption-Standard.

[6] Andrey Bogdanov, Dmitry Khovratovich and Christian Rechberger Biclique Cryptanalysis ofthe Full AES, Publicerad: 2017-08-31 Hämtad: 2018-05-25.https://eprint.iacr.org/2011/449.pdf.

[7] Sentor Vad är en Brute-force attack, Hämtad: 2018-05-25.https://www.sentor.se/kunskapsbank-it-sakerhet/losenord/vad-ar-en-brute-force-attack/.

[8] Radu Raicea How Pretty Good Privacy works, and how you can use it for secure communica-tion, Senast redigerad: 2017-10-08 Hämtad: 2018-05-25.https://medium.freecodecamp.org/how-does-pretty-good-privacy-work-3f5f75ecea97

[9] Facebook Inc. React Native Hämtad: 2018-05-10https://facebook.github.io/react-native/

[10] Charan Durai. Why do you go for Component-based UI Development? Senast redigerad:2017-03-19https://www.linkedin.com/pulse/why-do-you-go-component-based-ui-development-charan-durai/

[11] Node.js Foundation Node.js, Hämtad: 2018-05-10.https://nodejs.org/en/.

32

LITTERATURFÖRTECKNING 33

[12] Node.js Foundation Express, Hämtad: 2018-05-10.https://expressjs.com/.

[13] Open-Source Socket.IO, Hämtad: 2018-05-10.https://socket.io/.

[14] Oracle Corporation, Why MySQL?, Hämtad: 2018-05-10https://www.mysql.com/why-mysql/

[15] Sam Deering, Sitepoint Do you know what a REST API is?, Senast redigerad: 2018-03-05Hämtad: 2018-05-25.https://www.sitepoint.com/developers-rest-api/

[16] Gary Kessler Transmission Control Protocol, Senast redigerad: 2018-01-14 Hämtad: 2018-05-25.https://www.garykessler.net/library/tcpip.html

[17] Valve Steam, Hämtad: 2018-05-25.https://store.steampowered.com/about/?)

[18] Friends Friends, Senast redigerad: 2015-03-03 Hämtad: 2018-05-25.https://friends.se/2015/03/03/vanligt-med-krankningar-inom-spelvarlden/

[19] React Native. Asyncstorage, Hämtad: 2018-05-10.https://facebook.github.io/react-native/docs/asyncstorage.html

[20] Mozilla Fetch API, Hämtad: 2018-05-25.https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

[21] Expo Push Notifications, Hämtad 2018-05-25.https://docs.expo.io/versions/latest/guides/push-notifications

[22] Webbstrateg. Vad betyder egentligen att jobba agilt?, Publicerad 2013-05-15 Hämtad: 2018-05-25.http://www.webbstrateg.nu/vad-betyder-egentligen-att-jobba-agilt/

[23] Petter Ericson. 2013 Datasäkerhet, Hämtad: 2018-05-25.https://www8.cs.umu.se/kurser/5DV065/HT13/utdelat/sec1.pdf

[24] Android Developers. 2018 WindowManager.LayoutParams,Senast redigerad: 2018-05-08Hämtad: 2018-05-25.https://developer.android.com/reference/android/view/WindowManager.LayoutParams#flag_secure

[25] Kjell och Company. 2017 Närfältskommunikation, Senast redigerad: 2017-11-07 Hämtad:2018-05-25.https://www.kjell.com/se/fraga-kjell/hur-funkar-det/mobilt/anslutningsmojligheterna/narfaltskommunikation

[26] The New York times, Breaking Down Apple’s iPhone Fight With the U.S. Government, Senastredigerad: 2016-03-21 Hämtad: 2018-05-25.https://www.nytimes.com/interactive/2016/03/03/technology/apple-iphone-fbi-fight-explained.html

LITTERATURFÖRTECKNING 34

[27] Margaret Rouse, What is virtual private network (VPN), Senast redigerad: 2016-07 Hämtad:2018-05-25.https://searchnetworking.techtarget.com/definition/virtual-private-network

Bilaga A

Individuella prestationer

David ErikssonArbetade med gitrutiner för gruppen innan projektet drog igång, git rutiner för arbetet skapades ochpublicerades på github. Rutinerna användes genomgående i projektet. David arbetade med back-endför att sätta upp en RESTful webbservice som användes för att kommunicera mellan databas ochklienter. Utöver det behövde sockets integreras i back-end, detta gjordes tillsammans med JosefineFlügge för att chatt kommunikationen skulle ske i realtid. När chatten var implementerad med hjälpav sockets blev det uppenbart att denna teknik kunde utnyttjas för fler ändamål till exempel hur chat-ter sammankopplas efter att QR-koden har blivit skannad. David arbetade även med att kryptera ochavkryptera information med hjälp av krypteringsnycklar, att implementera kryptering visade sig intevara speciellt svårt, men att förstå vad som var gjort var desto svårare.

Josefine FlüggeHar agerat Scrummästare under projektet genom att se till att gruppen förhöll sig till riktlinjerna iScrum, att de dagliga sprintmötena hölls samt sprintåterblick- och sprintplaneringsmöten. Implemen-terat den mesta av funktionaliteten kopplad till chattvyn och realtidskommunikationen mellan använ-dare. Kommunikation med hjälp av sockets implementerades i klient- och serverkoden i samarbetemed David Erixon. Extra fokus lades på användargränssnittet och hur meddelandeobjekten renderasi vyn. Att implementera realtidsrenderingen var inledningsvis utmanande eftersom även den minstafördröjningen eller felrenderingen av chattmeddelandena försämrar användarupplevelsen ordentligt.Att integrera sockets i applikationen löste dock detta problem förvånansvärt väl.

Johnny MelinArbetade med profil-vyn och informationshantering. Informationshanteringen innefattar att spara datalokalt. Han har samarbetat med Andreas Siebmanns angående hantering av data vid QR-skanning/QR-generering och sökfunktionaliteten för kontaktlistan. Han har samarbetat med Emma Weberyd medöverföring av variabler mellan olika vyer. En utmanande del av navigeringen mellan list-vyn ochchatt-vyn var att optimera tiden det tog att byta vy vid skapandet av en ny chatt då QR-koden genere-rades. Detta visade sig senare bero på att biblioteket som användes för genereringen av QR-koder varför krävande för att QR-koden skulle genereras inom önskad tidsram.

Andreas SiebmannsHar arbetat med informationslagring och informationshantering av QR-koden. Detta innefattar attspara ner de variabler som används för att t.ex. kunna söka eller sortera bland chatterna. Dessa vari-abler sparades ner med hjälp av AsyncStorage som gör det möjligt att använda de olika variablernaglobalt i applikationen. Informationen i QR-koden innehåller ett flertal variabler som summeras tillen enda lång sträng, denna strängen används sedan för att få tillgång till information som t.ex. profil-

35

BILAGA A. INDIVIDUELLA PRESTATIONER 36

namn som sätts som namn på chattfönstret. Andreas har även arbetat med sökfunktionen för chatternai applikationen, detta var en av de uppgifter som han fann mest utmanande. Svårigheter kring sök-nycklar som är kopplade till indexeringen av objekten i databasen var något som inte fungerade påkorrekt sätt från början, detta gjorde att oavsett vilken sökfunktion som implementerades så kommerden inte fungera pga. att föremålen inte har något sök-index. Detta löstes genom att läsa in chatternasom kompletta objekt vilket gav en korrekt indexering.

Emma WeberydEmma har huvudsakligen jobbat med navigeringen i applikationen. Det innebär att hon har implemen-terat de två navigeringsmöjligheterna som finns i appen, d.v.s. att bläddra mellan de tre vyerna; list-vyn, profil-vyn och skanner-vyn, samt navigeringen som tar användaren från list-vyn till chatt-vyn.Den mest utmanande delen av Emmas arbete var att få chatt-vyn att rendera rätt innehåll beroende påvilken chatt som väljs i list-vyn. Detta gjordes genom att skicka med de parametrar som tillhör denspecifika chatten som klickas på. Av dessa parametrar skickas t.ex. chattens id med, vilket användsför att hämta och läsa in rätt meddelanden från databasen. När användaren skapar en ny chatt är na-vigeringen lite annorlunda. Då finns ingen instans av chatten innan utan den skapas först i databasenoch sedan navigeras användaren till chatt-vyn som inte ännu är aktiverad. Det går inte att skriva någotmeddelande förrän en annan person har anslutit sig till chatten. Därefter uppdateras informationensom visas i chatt-vyn, så att det blir tydlig vem som har anslutit sig till chatten.

Bilaga B

Resultat från användartester 1.0

Nedan följer resultatet från användartesterna som utfördes på studenter i åldersgruppen 20-25 år påden första prototypen för chattapplikationen.

37

BILAGA B. RESULTAT FRÅN ANVÄNDARTESTER 1.0 38

BILAGA B. RESULTAT FRÅN ANVÄNDARTESTER 1.0 39

BILAGA B. RESULTAT FRÅN ANVÄNDARTESTER 1.0 40

BILAGA B. RESULTAT FRÅN ANVÄNDARTESTER 1.0 41

Bilaga C

Resultat från användartester 2.0

Nedan följer resultatet från användartesterna som utfördes på 3 barn i åldersgruppen 10-12 år. För attförsäkra att all feedback skrevs ned antecknade två personer ur projektgruppen barnens svar, därav ärvissa av svaren nedan upprepningar.

42

BILAGA C. RESULTAT FRÅN ANVÄNDARTESTER 2.0 43

BILAGA C. RESULTAT FRÅN ANVÄNDARTESTER 2.0 44

Bilaga D

Det första utkastet av backloggen

Frontend• Skapa hem-vyn

– Designa knappar– Designa kontaktlistan

• Skapa chatt-vyn

– Designa knappar för att skicka meddelande

• Skapa vyn där man lägger till kontaker

– Designa knappar för att lägga till kontakt/(skapa gruppchatt)

Backend• Implementera skapandet av QR-kod

– Skapa och implementera QR-kod för 1:1 chatt– Skapa och implementera QR-kod för gruppchatt

• Skapa databas för chatthistorik och användare

• Implementera kryptering av QR-koder samt chattmeddelanden

– Kryptering av QR-kod– Dekryptering av QR-kod– Kryptering av chattmeddelanden– Dekryptering av chattmeddelanden

Övrigt• Design av app-ikon

• Namn på appen

• Emojis (ev. Egendesginade emojis)

• Lösenord för extra säkerhet (fyrsiffrig kod, mönster-kod eller touch-ID)

• Tillfälliga QR-koder

45

Bilaga E

Lista över ord och begrepp

Adobe XD - Programvara för att skapa klickbara prototyper.

Advanced Encryption Standard (AES) - En krypteringsalgoritm som överför text till en obegripligsamling tecken med hjälp av en krypteringsnyckel. Resultatet av krypteringen kan avkodas genom attanvända samma nyckel. Denna nyckel kan förekomma i form av 128, 192 eller 256 bitar [3].

Agil utveckling - En form av inkrementell utveckling där tvärfunktionella team jobbar med att brytaner kundkraven i delmål som spänns upp för att nås efter en bestämd tidsperiod [22].

Apache - Är en webbserver mjukvara som används av ungefär 67% av marknads webbservrar. Det ärmjukvaran som hanterar HTTP/TCP förfrågningar för servern.

AsyncStorage - Ett lagringssystem som lagrar information i JSON-format [19].

Biclique Attack - Är en variant av ”möt i mitten metoden”(meet-in-the-middle - MITM) av kryp-teringsanays. Den använder sig av en biclique struktur för att utöka antalet möjliga attacker av MITMattacken

Brute-force Attack - Används när andra metoder för att knäcka lösenord misslyckats. Det är enomfattande form av attack och är en omfattande form av attack och den är mycket tidskrävande föratt knäcka krypterade lösenord. Vid denna typ av attack testar ett program automatiskt kombinationerav stora mängder siffror för att hitta lösenordet genom ”trial and error”.

Blockchiffer - Är ett chiffer bestående av text av en viss längd (64 bitar) genom en funktion sombestäms av en nyckel som översätts till en lika lång krypterad text. Genom att ta inversen av denfunktionen kan den ursprungliga texten avläsas. [23]

Color Picker - Även kallat färg väljare på svenska. Är ett användargränssnitt som låter använda-ren välja bland ett antal färger med hjälp av ett reglage.

Commit-meddelanden - Ett meddelande som skickas med till GitHub när en teammedlem skic-kar ett bidrar till den gemensamma källkoden.

Express - Är en minimal och flexibel Node.js webb-applikation som tillhandahåller ett stort bibli-otek med funktioner för web och mobilapplikationer.

46

BILAGA E. LISTA ÖVER ORD OCH BEGREPP 47

FaceBook Messenger - En chattapplikation skapad av Facebook, med hjälp av React Native.

Fetch - Engelska ordet för hämta. Denna term kommer främst upp i samband med hämtning avinformation från databasen.

Flickr - En webbtjänst för att ladda upp bild- och videomaterial.

Git - Ett versionshanteringssystem.

GitHub - En plattform för att organisera projekt med versionshanteringssystemet Git.

git-repository - Är en datakatalog där projektet har förvarats och utvecklats genom. Är en samligav definitioner och beskrivningar av objekt och datatyper som bygger applikationen.

Instagram - En plattform för att ladda upp bilder.

Java - Ett objektorienterat programspråk.

Microsoft Office - Programvarupaket av Microsoft som innehåller Micfrosoft Word, Microsoft Exceloch Microsoft PowerPoint bland andra.

Mumble - Engelskt ord som innebär att mumla, d.v.s. att yttra någonting otydligt.

Mumblr - Namnet på applikationen som skapades i detta projekt.

MySQL - Är en databashanterare. Använder sig av frågespråket SQL. MySQL är en fri program-vara, licensierad under GNU(General Public License).

National Institute of Standards and Technology (NIST) - Är en organisation som drivs av USA:shandelsdepartement. Institutionen drivs i forskningssyfte inom olika teknologiska områden.

Near Field Communication (NFC) - En lösning för att kunna utbyta information på nära håll, somanvänds i liknande sammanhang där QR-koder används, för att med hjälp av en läsare i telefonenkunna hämta information [25].

Node Package Manager (NPM) - Är en pakethanterare för programmeringsspråket JavaScript.

Node.js - Är ett programsystem designat för att skapa skalbara internetapplikationer. Program skrivsi JavaScript-kod för att köras på systemet.

Objective-C - Är en objektorienterad påbyggnad på programeringsspråket C.

QR-kod - Även kallat Quick Response, är en tvådimensionell kod för optisk avläsning.

Pretty Good Privacy (PGP) - Är ett program som används för att kryptera och dekryptera e-pos,texter och filer.

Produkt-backlogg - Är en samlingsplats för alla önskemål om förändringar av applikationen. Ägsoch hanteras av produktägaren. Här används prioritering av vad som är mest relevant för att resultatetska bli så bra som möjligt.

BILAGA E. LISTA ÖVER ORD OCH BEGREPP 48

Raspberry Pi - Är en enkortsdator som har utvecklats av det brittiska företaget ”Raspberry Pi Founda-tion”. Kortet är ungefär lika stort som ett kreditkort. Används av många smarttelefoner.

React Native - Låter dig bygga mobil applikationer med JavaScript kod. React-native använder sam-ma design som react.

react-native-aes - AES kryptering och dekryptering i react native.

react-native-qrcode - En react-native komponent för att generera QR-koder.

RESTful - ÄR ett IT-akitekturbegrepp som beskriver hur tjänster för maskin till maskin kommu-nikation kan förses via webbteknologi.

Rijndael - Är ett nyckel-schema som används inom krypteringsmetoden AES. Nyckel-schemat an-vönds för att expandera en ”short key” till ett antal separata ”round keys”.

Scrum - En typ av agil utvecklingsmetod med väl utformade regler som ska följas under ett pro-jekt. Det kan läsas mer om i Scrumguiden [2].

Sha-256 - Är en krypteringsmetod som använder sig av 256-bitars säkerhet för kryptering och de-kryptering av text. Använder sig även av handskaknings-verifikation vid verifiering av den användanyckeln.

Snapchat - Är en fotodelnings och multimediaapp för smart-telefoner.

Socket - Är en exakt och definerad kommunikationsväg på internet. En socket består av ett protokollt.ex. TCP, en lokal ip-adress och ett portnummer som är kopplat till protokollet. Samt den mottagandekommunikatörens socketadress.

Socket.io - Är ett JavaScript bibliotek för realtids webb-applikationer. Det tillhandahåller realtid ochtvåvägskommunikation mellan web-klienter och server.

Sprint - Är en period då gruppen arbetar med ett antal förutbestämda uppgifter. En sprint är mel-lan 3 och 30 dagar lång beroende på uppgifterna.

Swift - är ett kompilerat, multi-paradigmatiskt programspråk utvecklat av Apple för programmeringi operativsystemen: iOS, OSX, Linux och watchOS.

Transmission Control Protocol (TCP) - Är ett förbindelseorienterat dataöverföringsprotokoll somanvänds för all form av kommunikation över nätet. TCP erbjuder en pålitlig dataström mellan tvådatorer och används för HTTP, e-post och FTP.

Trello - Detta är ett program för att hantera det administrativa kring projektering. I detta programstruktureras projektets uppgifter och delas ut till respektive projektmedlemmar med hjälp av pro-grammets taggnings-funktionalitet.

Trial and error - Även kallat: ”Försök och misstag” är en form av inlärning där felaktiga meto-der och ineffektiva angreppssätt elimineras om de inte leder till framgång eller önskat resultat.

BILAGA E. LISTA ÖVER ORD OCH BEGREPP 49

Tumblr - Är en bloggplattform där användare kan publicera material så som bilder, textutdrag, filmer,chatt och musik till sin sk. tumblelog. Användarna kan följa varandra och på så sätt bilda ett flöde meddet material som användaren är intresserad av.

Web of Trust - Web of trust ett koncept som används i PGP (Pretty good privacy), GnuPG (GNUPrivacy Guard) och andra OpenPGP-kompatibla system för att etablera autencitet av bindandet mel-lan användaren och den publika nyckeln som tillhör användaren.

WebSocket - Är en teknik som möjliggör full-duplex tvåvägskommunikationskanaler över en TCP(Transmission Controll Protocol) socket. Den är utformad för att implementeras i webbläsare samtwebbservrar, kan även användas av majoriteten av klient- och serverapplikationer.