Data Protection in Windows Phone 8.1

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN

CAMPUS GENT

Data Protection in WindowsPhone

Bram GOSSEYE

Promotor: Vincent Naessens Masterproef ingediend tot het behalen vande graad van master of Science in de

Co-promotoren: Faysal Boukayoua industriele wetenschappen: Elektronica-ICTAfstudeerrichting informatie- en

communicatietechnieken

Academiejaar 2014 - 2015

c©Copyright KU Leuven

Zonder voorafgaande schriftelijke toestemming van zowel de promotor(en) als de auteur(s) is over-nemen, kopieren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Vooraanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uitdeze publicatie, wend u tot KU Leuven campus Gent, Gebroeders De Smetstraat 1, B-9000 Gent,+32-9-2658610 of via e-mail [email protected].

Voorafgaande schriftelijke toestemming van de promotor(en) is eveneens vereist voor het aan-wenden van de in deze masterproef beschreven (originele) methoden, producten, schakelingenen programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie terdeelname aan wetenschappelijke prijzen of wedstrijden.

Dankwoord

Als masterstudent industriele ingenieurswetenschappen ICT ben ik zeer blij de kans te krijgen omeen masterproef te maken over informatiebeveiliging. Deze sector is voor mij een sterk interesse-gebied, hoewel mijn ervaring en kennis hierin minimaal is. Deze masterproef is gerealiseerd in hetacademiejaar 2014-2015 in opdracht van de onderzoeksgroep MSEC van KU Leuven.

Deze scriptie bespreekt de beveiliging van het mobiele platform van Microsoft. Het doelpubliek zijnmensen die geınteresseerd zijn in het beveiligen van informatie of/en in mobiele toestellen.

Allereerst bedank ik graag mijn promotor Vincent Naessens en mijn copromotor Faysal Boukay-oua om mij gedurende het hele academiejaar te ondersteunen. Eveneens bedank ik de volledigevakgroepen MSEC en CODeS voor hun bijstand.

iii

Abstract

De groeiende stroom van confidentele data en het toenemend gebruik van mobiele toestellen zorgtvoor steeds meer beveiligingsrisico’s. Verschillende opkomende trends zoals BYOD (Bring YourOwn Device) hebben een impact op de mogelijkheid voor bedrijven om hun gevoelige data te be-schermen.In deze thesis wordt data protection op het Windows Phone platform onderzocht. Deze studie leverteen vergelijking op met andere veelgebruikte mobiele besturingssystemen zoals Android en iOS.De focus wordt gelegd op het standpunt van de appontwikkelaar, vertrekkende vanuit bestaandesecuritybouwblokken. Een grondige analyse brengt aan het licht welke securitygaranties ze biedenen welke tekortkomingen ze vertonen. Er wordt vervolgens onderzocht hoe deze verholpen kunnenworden.Aan de hand van een bedrijfstoepassing voor mobiel bestandsbeheer wordt de werking van de be-schikbare beveiligingsmechanismen gedemonstreerd. Het resultaat wordt vervolgens geevalueerdop basis van criteria zoals security, usability, interoperability, performantie en administratiemoge-lijkheden.

Trefwoorden: Security – Mobiele toestellen – Windows Phone – Data protection – Information se-curity

iv

Inhoudsopgave

1 Inleiding 1

2 Case Study 3

2.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Securityvereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.3 Communicatiekanaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Achtergrondinformatie 7

3.1 Information security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.2 classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.3 The CIA Triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.4 Beveiligingsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.5 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.6 Beveiligen van mobiele toestellen . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Bestandsoverdracht protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 File Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 FTP v.s. WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Security in Windows Phone 16

4.1 Windows Phone 8.x Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 App distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 App isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Data and credential protection mechanisms . . . . . . . . . . . . . . . . . . . . . . 20

4.4.1 Internal Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.2 External Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.3 Data Protection API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

INHOUDSOPGAVE vi

4.4.4 CredentialLocker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Interprocess communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.1 File Extension Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.2 Protocol Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6 OEM Secure Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7 Exploit mitigation technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.7.1 Stack Canaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.7.2 Address Space Layout Randomization . . . . . . . . . . . . . . . . . . . . . 27

4.7.3 Data Execution Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.8 Certificate trust stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.9 Virtual smart cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.10 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Ontwerp van de toepassing 30

5.1 Functioneel overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Serverside ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.2 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.3 Bestandsoverdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.4 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Clientside ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3.1 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3.2 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3.3 Bestandsoverdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.4 Opslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Realisatie van de toepassing 36

6.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Serverside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.2 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.3 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.4 Policy voorzieningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.5 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3 Clientside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.2 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3.3 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3.4 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

INHOUDSOPGAVE vii

6.3.5 Omgang met bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4 Virtual smart cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Evaluatie van de toepassing 46

7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.3 Gebruiksvriendelijkheid en performantie . . . . . . . . . . . . . . . . . . . . . . . . 47

7.3.1 Gebruiksvriendelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.3.2 Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.4.1 Aanvalsmodel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.4.2 Aanvalsmodel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.4.3 Aanvalsmodel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.5 Vergelijking met andere applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.5.1 Vergelijking met andere Windows Phone applicaties . . . . . . . . . . . . . . 52

7.5.2 Vergelijking met Android en iOS applicaties . . . . . . . . . . . . . . . . . . 52

7.6 Beperkingen en mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . 53

7.7 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Besluit 58

8.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.2 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3 Verdere onderzoeksmogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A Performantietest 63

B Beschrijving van deze masterproef in de vorm van een wetenschappelijk artikel 66

C Poster 74

Lijst van figuren

1.1 Marktaandeel van verschillende mobiele besturingssystemen in 2015. . . . . . . . . 2

2.1 classificatie niveau’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Overzicht van de opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 CIA model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Windows Phone 8.1 App Development Platform [24] . . . . . . . . . . . . . . . . . 16

4.2 Windows Phone 8.x chamber architecture . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Windows Phone 8.x chamber architecture . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Windows Data Protection API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 Windows Phone OEM Secure Boot flowchart [19] . . . . . . . . . . . . . . . . . . . 26

4.6 De levenscyclus van een Virtual Smard Card [18] . . . . . . . . . . . . . . . . . . . 29

5.1 Functioneel overzicht van de opstelling . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Verschillende componenten in client en server . . . . . . . . . . . . . . . . . . . . 31

6.1 Overzicht van de PKI van de opstelling . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2 Het startscherm van de client applicatie. . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3 De loginpagina van de client applicatie. . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 De verkenner van de client applicatie. . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.5 Het gedownloade bestand wordt opgeslagen in de isolated storage. . . . . . . . . . 42

6.6 Het bestand wordt geopend door een externe applicatie. . . . . . . . . . . . . . . . 43

6.7 Het bestand wordt versleuteld opgeslagen op het externe geheugen. . . . . . . . . . 44

7.1 CPU performantietest (zie bijlage A voor grotere versie) . . . . . . . . . . . . . . . . 48

7.2 RAM geheugen performantietest (zie bijlage A voor grotere versie) . . . . . . . . . . 49

A.1 CPU performantietest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A.2 RAM geheugen performantietest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

viii

Lijst van tabellen

2.1 Vereisten classificatiesysteem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Overzicht doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Vergelijking tussen WebDAV en FTP . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Vergelijkende tabel app distribution [25] . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Vergelijkende tabel app isolation [25] . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 Verschillende constructors in DataProtectionProvider klasse . . . . . . . . . . . . . 22

4.4 Verschillende methodes in de DataProtectionProvider klasse . . . . . . . . . . . . . 23

4.5 Vergelijkende tabel data protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6 Vergelijkende tabel Secure Boot mechanisme . . . . . . . . . . . . . . . . . . . . . 27

4.7 Vergelijking tussen beide trust stores. . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 De verschillende classificaties en hun eigenschappen . . . . . . . . . . . . . . . . . 32

7.1 Vergelijking met andere Windows Phone applicaties . . . . . . . . . . . . . . . . . 55

7.2 Vergelijking met applicaties voor Android en iOS . . . . . . . . . . . . . . . . . . . 56

7.3 Overzicht van de doelstellingen en of ze al dan niet bereikt zijn. . . . . . . . . . . . 57

8.1 Wat biedt Windows Phone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

ix

Lijst van acroniemen

BYOD Bring Your Own DeviceWP Windows PhoneAES Advanced Encryption StandardEMP Electro magnetic pulseRAID Redundant Array of Independent DisksLDAP Lightweight Directory Access ProtocolSSO Single Sign-OnSSL Secure Socket LayerTLS Transport Layer SecurityTCP Transmission Control ProtocolMAC Message Authentication CodePKI Public Key InfrastructureCA Certificate AuthorityFTP File Transmission ProtocolWEBDAV Web-based Authoring And VersioningMDM Mobile Device ManagementACL Access Control ListLPC Least Privilege ChamberTCB Trusted Computing BaseUID Unique user IdentifierAPI Application Programming InterfaceTPM Trusted Platform ModuleDPAPI Data Protection APIIPC Inter Process CommunicationURI Uniform Resource IdentifierIRL Uniform Resource LocatorASLR Adress Space Layout RandomizationDEP Data Execution PreventionVSC Virtual Smart CardHTTP Hyper Text Transfer ProtocolGUID Global Unique IdentifierMITM Man In The Middle

x

Hoofdstuk 1

Inleiding

Het gebruik van mobiele platformen is de laatste jaren enorm toegenomen. Ook in de zakelijke we-reld worden mobiele toestellen meer en meer gebruikt ten goede van de efficientie en productiviteit.Met een mobiel toestel, voorzien van een internetverbinding, kan men de informatie raadplegendie men op dat moment en op die locatie nodig heeft. Een thuisverpleegster kan bijvoorbeeld depersoonlijke medische informatie opvragen van de patient bij wie ze op dat moment is. De bedrijfs-gevoelige data die opgevraagd wordt, mag enkel toegankelijk zijn voor bevoegde personen. Menbegrijpt dat het gebruik van mobiele toestellen de beveiliging van vertrouwelijke data bemoeilijkt.Een opkomende trend is Bring Your Own Device (BYOD) waarbij werknemers de mogelijkheidkrijgen om hun eigen toestel (laptop, smartphone, etc) mee te nemen naar het werk. Het grotevoordeel van deze policy is dat het de efficientie en flexibiliteit verhoogt omdat de werknemers ophun vertrouwd toestel kunnen werken [23]. BYOD zorgt ervoor dat werknemers, partners en klan-ten steeds meer vertrouwelijke informatie zullen benaderen met een toestel dat geen eigendom isvan de organisatie.BYOD is een typisch voorbeeld van het end node probleem. Dit probleem treedt op wanneer gevoe-lige data benaderd wordt door een onvertrouwd toestel of wanneer dat toestel (tijdelijk) vertrouwdwordt binnen het bedrijfsnetwerk en verbinding maakt met onveilige of openbare netwerken. Opdeze manier kan privacygevoelige data blootgesteld worden of kan een vertrouwd netwerk besmetgeraken met malware. Het raadplegen van de opgeslagen data door onbekende applicaties vormteveneens een probleem, net als onbevoegden die toegang verkrijgen tot het geheugen van eengestolen toestel. Naast het voorzien van de netwerkbeveiliging en de te gebruiken applicatie moetde organisatie in staat zijn de data te controleren nadat die opgevraagd is door een mobiel toestelvan een medewerker [33]. De administratiemogelijkheden bij BYOD verschillen immers van die bijeen bedrijfstoestel. Het is bijvoorbeeld ongepermitteerd om het privetoestel van een werknemerte wissen. Om de veiligheid van confidentiele informatie te verzekeren moet databeveiliging eentopprioriteit worden in de organisatie [23].

Het doel van deze thesis is het onderzoeken van databeveiliging in het meest recente mobiele be-sturingssysteem van Microsoft: Windows Phone 8.1. Dit onderzoek start vanuit het standpunt vande software ontwikkelaar. Volgens Gartner [10] draait Windows Phone op 14% van de toestellenen dit aantal blijf stijgen, vooral in de bedrijfswereld (zie figuur 4.1). Het is dus niet onbelangrijkom te weten in hoeverre confidentiele data kan beveiligd worden op dit mobiel platform en welkeverbeteringen kunnen aangebracht worden.Bedrijven bouwen vaak nieuwe software maar hebben niet altijd de expertise om security strate-

1

1 Inleiding 2

Figuur 1.1: Marktaandeel van verschillende mobiele besturingssystemen in 2015.

gieen te ontwerpen. Deze thesis is bedoeld om software ontwikkelaars een beeld te geven watnodig en mogelijk is om informatie op een vooruitstrevende manier te beveiligen. In hoofstuk 2wordt er op zoek gegaan naar een gepast scenario om het onderzoek te steunen. Men zal eenproof-of-concept applicatie trachten te ontwikkelen die voldoet aan de eisen die gesteld worden.Om deze eisen beter te begrijpen en om zich vertrouwd te voelen in de omgeving waarin gewerktwordt, biedt hoofdstuk 3 een literatuurstudie aan over information security en Windows Phone.Hierin worden ook kleine vergelijkingen gemaakt met andere mobiele platformen. In hoofdstuk 4en 5 wordt de toepassing uitgebreid besproken. Uit welke onderdelen ze bestaat, welke functies zeheeft en hoe het geheel tot stand gekomen is. Ten slotte zal hoofdstuk 6 de volledige opstelling eva-lueren aan de hand van verschillende aanvalsmodellen die toegepast worden op het uitgewerktescenario.

Hoofdstuk 2

Case Study

2.1 Overzicht

Om de beveiligingsmogelijkheden van Windows Phone aan te tonen, is er een gepast scenarioontworpen. We kiezen voor een bedrijfsomgeving waar gevoelige informatie benaderd wordt vanbuitenaf door een werknemer. Er kan verondersteld worden dat de werknemer bij een klant is enverbonden is met een niet vertrouwd netwerk. Er wordt geopteerd om een client-server verbindingmet bestandsoverdracht op te zetten. De opstelling bestaat enerzijds uit een mobiele client: eenpersoonlijk toestel van een werknemer. Anderzijds voorzien we de firma van een bestandsserver.De bedoeling is dat de werknemer bestanden kan downloaden, openen en eventueel kan opslaanop het externe geheugen van het toestel. Er wordt een vorm van classificatie ingebouwd: niet allewerknemers krijgen toegang tot alle bestanden. Ook de beveiligingsgraad en de authenticatiema-nier moet aangepast worden per niveau (zie figuur 2.1).

Figuur 2.1: classificatie niveau’s

2.2 Securityvereisten

We kunnen de opstelling opdelen in drie delen (zie figuur 2.2): Client, Server en Communicatieka-naal. Voor elk onderdeel kunnen we vereisten opstellen.

3

2 Case Study 4

Figuur 2.2: Overzicht van de opstelling

2.2.1 Server

De server die door de firma wordt voorzien, is een bestandsserver die vertrouwelijke informatiebewaart. Aangezien de werknemer van buiten het bedrijfsnetwerk deze informatie moet kunnenraadplegen, dient de server aangesloten te worden op het internet met een vast IP adres. Het be-drijfsnetwerk waarin de server zich bevindt, moet voorzien zijn van verschillende controlesystemenzoals firewalls, antimalwaresoftware en inbraakpreventiesystemen. De server mag in geen gevalgehacked worden of fysiek benaderd worden door onbevoegden en moet altijd wanneer nodig be-reikbaar zijn voor de client. Het besturingssysteem en de gebruikte software moet altijd up-to-datezijn.

Daarnaast moet de server in staat zijn een veilige verbinding op te zetten met de client zodat alleinformatie die uitgewisseld wordt vertrouwelijk is en niet kan onderschept worden door derden.

Niet zomaar iedereen (en elk toestel) mag de informatie op de server consulteren. Er moeteneen over meerdere authenticatiemogelijkheden voorzien worden door de bedrijfsserver. Er wordtgewerkt met een classificatiesysteem. De authenticatieen autorisatie-systemen zullen moetenvoldoen aan de eisen die gesteld worden in tabel 2.1.

2.2.2 Client

De client is een mobiel toestel van een werknemer. Hij is geautoriseerd om (delen van) de informa-tie op de bestandsserver te raadplegen. Niet alleen hij in persoon moet toegang krijgen, maar ookhet toestel dat daarvoor gebruikt wordt. De client (gebruiker en/of toestel) moet dus in staat zijn omzichzelf te authenticeren bij de server. Om vertrouwelijke informatieuitwisseling mogelijk te makenmoet het toestel in staat zijn om een veilige verbinding op te zetten met de server. We kunnen dusspreken van mutual authentication: zowel client en server moeten zich bij elkaar kenbaar makenen authenticeren.

Verder moet de omgang met bestanden en credentials op een beveiligde manier gebeuren. Mal-ware aanvallen moeten afgeweerd worden of mogen geen schade aanrichten of bestanden stelen.De software op het toestel (de applicatie en het besturingssysteem) mogen op geen enkele wijzegecompromiteerd worden. Wanneer het toestel zelf gestolen wordt, moet het onmogelijk zijn ominformatie te onttrekken of de vertrouwelijke bestanden op server te benaderen met dat toestel.

2 Case Study 5

2.2.3 Communicatiekanaal

Het communicatiekanaal moet ten allen tijden van confidentialiteit en integriteit voorzien zijn. Hetnetwerk langs de server zijde moet betrouwbaar en altijd beschikbaar zijn. De client verbindtmeestal met een onvertrouwd netwerk, hier kunnen geen securityvereisten worden vooropgesteld.De gehele opstelling moet hiermee rekening houden.

2.3 Doelstellingen

De doelstelligen van deze proof-of-concept applicatie zijn uiteenlopend. Enerzijds wordt er ge-streefd naar een veilige omgeving waarin omgegaan wordt met gevoelige informatie. Anderzijdsmoet de applicatie ook functioneel zijn. Een hoge graad van gebruiksvriendelijkheid is eveneenseen doelstelling van de opstelling. Het bedrijf moet eveneens de mogelijkheid hebben om hunsysteem uit te breiden of te voorzien van andere of extra functionaliteiten.

Samengevat moet de opstelling dus voldoen aan volgende eisen:

• Over de functionaliteit beschikken die bestandsoverdracht mogelijk maakt.

• Voldoen aan de security vereisten.

• Gebruiksvriendelijkheid in het achterhoofd houden: Het eenvoudig maken om bestanden ofmappen toe te voegen aan een bepaalde classificatie. Het zorgen voor een install-and-gopolicy, zodat de gebruiker geen ingewikkelde installatie moet doorlopen.

• Uitbreidbaarheid voorzien, zowel bij de server als bij de client: Het toevoegen van nieuweauthenticatiemogelijkheden, nieuwe classificatie niveau’s en nieuwe gebruikers.

Een volledig overzicht is te vinden in tabel 2.2.

Authenticatie Encryptie bij opslag op toestel SSLPublic Geen X XConfidential Gebruikersauthenticatie X XSecret Strong authentication X X

TopsecretGebruikersauthenticatie+ strong authentication

X X

Tabel 2.1: Vereisten classificatiesysteem.

2 Case Study 6

ClientFunctioneel zijn (bestandsoverdracht)Install-and-go policy hebbenUser en device authenticatie voorzienVeilige verbinding opzetten met serverAfweren van malware aanvallenOnmogelijk maken om vertrouwelijke informatie van het toestel te halen door onbevoegden.

ServerFunctionaliteit (fileserver)Bereikbaar wanneer nodigVoorzien van controlesystemenFysiek beveiligdVeilige verbinding opzetten met clientsVerschillende authenticatiemogelijkheden voorzienclassificatie niveau’s implementerenEenvoudig toevoegen van extra authenticatiemogelijkheden,classificaties, nieuwe gebruikers, bestanden en mappen

CommunicatiekanaalConfidentialiteitIntegriteit

Tabel 2.2: Overzicht doelstellingen

Hoofdstuk 3

Achtergrondinformatie

3.1 Information security

3.1.1 Inleiding

Vooraleer het over de aanpak van databeveiliging te hebben, moeten er enkele vragen gesteldworden: Wat proberen we te beschermen? Waarom proberen we dit te beschermen? Hoe gaanwe het beveiligen? In dit hoofdstuk gaan we op zoek een manier om deze vragen te kunnenbeantwoorden door enkele waarden en begrippen toe te lichten. Er komen verschillende aspectenvan beveiliging aan bod, maar de focus wordt gelegd op het standpunt van de softwareontwikkelaar.

3.1.2 classificatie

Informatie is in vele gevallen het belangrijkste bezit van een bedrijf. Informatie wordt meestal onder-verdeeld in verschillende klassen, afhankelijk van de belangrijkheid en kwetsbaarheid. De Britseoverheid bijvoorbeeld, gebruikt een 3-niveau classificatiesysteem dat gebasseerd is op de gevol-gen van het lekken van de informatie: OFFICIAL, SECRET en TOP SECRET [6]. Op elk niveauworden bepaalde securitymechanismen toegepast die de informatie van de nodige beveiliging voor-zien. Bedrijven kunnen vertrouwelijke informatie zoals rapporten, onderzoeken, procesinformatieen dergelijke bezitten. Deze informatie is vertrouwelijk en noodzakelijk voor de goede werking vanhet bedrijf. Diefstal of lekken van dit soort informatie kan de privacy schenden of de concurrentiepo-sitie verzwakken. Geheime informatie zoals productiedetails, formules, paswoorden en certificatenkunnen na diefstal voor nog grotere problemen zorgen. Deze bestanden kunnen meestal doorslechts enkele werknemers benaderd worden.

3.1.3 The CIA Triad

Wanneer men het heeft over information security wordt er meestal verwezen naar het behoudenvan Confidentiality (vertrouwelijkheid), Integrity (integriteit, betrouwbaarheid) en Availability (be-schikbaarheid). Deze begrippen vormen het drieletterwoord CIA. Het is een model dat bedoeld isom mensen te wijzen op de belangrijkste aspecten bij information security [3].

7


Figuur 3.1: CIA model

Confidentiality

De maatregelen die genomen worden om vertrouwelijkheid te verzekeren, zijn bedoeld om te voor-komen dat gevoelige informatie terecht komt in de verkeerde handen. Anders verwoord: enkel demensen met de juiste bevoegdheid hebben toegang tot de data. Confidentiality leunt dicht aantegen het begrip privacy, maar er is een belangrijk onderscheid: privacy duidt er meestal op datde toegang tot informatie beperkt is tot een persoon. Vertrouwelijkheid impliceert dat er meerderepartijen betrokken zijn tot de informatie [28]. Een paswoord bijvoorbeeld is privaat, maar medischegegevens zijn vertrouwelijk omdat zowel patient als dokter betrokken zijn.

Integrity

Integriteit is het behouden van de betrouwbaarheid van de data gedurende de gehele levenscy-clus. Informatie mag niet aangepast worden door onbevoegden, noch tijdens de communicatie (intransit), noch wanneer het opgeslagen is (at rest). We verwachten bijvoorbeeld dat onze medi-sche gegevens altijd en overal correct zijn. Permissies en toeganscontrole spelen een grote rolom ongeautoriseerde aanpassingen te voorkomen. Ook het voorzien van backups om data terugte kunnen herstellen naar de originele staat. Versiecontrole kan een manier zijn om onopzettelijkewijzigingen door geauthenticeerde gebruikers te voorkomen. Men moet eveneens voorbereid zijnop niet-menselijke aanpassingen van informatie zoals een elektromagnetische puls (EMP) of eenservercrash.

Availability

Availability verwijst naar het beschikbaar zijn van informatie en services wanneer nodig. Informa-tie die niet beschikbaar is wanneer ze opgevraagd wordt, is niet nuttig [3]. Het beschikbaar zijnvan informatie en processen wordt meestal verzekerd door het implementeren van high-availabilitycontrols op computers, netwerken en opslagsystemen. Voorbeelden hiervan zijn clustercomputers,redundante netwerkconnecties en RAID configuraties.


Alternatieven en uitbreidingen

Het CIA model is geen waterdicht model en kan in de praktijk op verschillende manieren omge-zet worden door verschillende securitybouwblokken te combineren. Er zijn vele alternatieven ofuitbreidingen op dit model. Hieronder enkele voorbeelden:

• Parkerian hexad. Een set van 6 elementen, waaronder het CIA-model. De andere 3 aspec-ten die Parker [26] aanhaalde zijn Possession of control, Authenticity en Utility.

• Five Pillars of Information Assurance. Het departement van defensie van de VerenigdeStaten (U.S. DoD) voegt nog 2 pijlers toe aan het CIA model, namelijk: Authenticity en Non-Repudiation [13].

Er zijn heel wat verschillende manieren om security principes te categoriseren. Het CIA model ishet meest eenvoudige.

3.1.4 Beveiligingsmechanismen

Nu rest ons nog de vraag hoe het beschermen van informatie mogelijk gemaakt kan worden. Hetspreekt voor zich dat er voor een optimale beveiliging veel meer nodig is dan het implementerenvan enkele programmeerbare mechanismen. Het gaat niet alleen over enkele bouwblokken, maarook de hardware, de fysieke toegang en het ontwerp van het netwerk zijn belangrijke aspecten. Indit onderzoek beperken we ons tot het standpunt van de ontwikkelaar. Er worden enkele algemenemechanismen besproken die de basis leggen van een veilige en betrouwbare professionele om-geving. We houden in het achterhoofd dat heel wat controlesystemen zoals firewalls en intrusiondetection and prevention systems noodzakelijk zijn om een veilige omgeving te vormen [28].

Encryptie en digitale handtekeningen

Door informatie te verstoppen of onleesbaar te maken, kan ze vertrouwelijk gehouden worden.Cryptografie bestaat al langer dan het computertijdperk, maar werd tijdens de digitale evolutie ineen modern jasje gestopt. Encrypteren van data kan confidentiality verzekeren.

Symmetrische cryptografie

”Bij symmetrische cryptografie bestaat de encryptie uit een reeks omkeerbare stappen, zoals hetoptellen van een bepaald getal of het verwisselen van bepaalde bits” [32]. De encryptiesleutel isdus gelijk aan de decryptiesleutel. Deze sleutel wordt de ’secret key’ genoemd en is een numeriekewaarde die een algoritme zal gebruiken om de leesbare informatie te versleutelen tot vercijferdedata. Op die manier wordt de informatie enkel zichtbaar voor diegene die in bezit is van de cor-recte sleutel. De moeilijkheid zit hem in het veilig verspreiden van de gebruikte sleutel. Dit kanenkel als er gecommuniceerd wordt met een klein aantal gebruikers, maar wordt moeilijk met eengrote groep systemen. Het verspreiden van de gebruikte sleutel gebeurt doorgaans met asymme-trische encryptie om vertrouwelijkheid te verzekeren. Een veel gebruikt symmetrisch algortime isAdvanced Encryption Standard (AES).

Asymmetrische cryptografie

Bij asymetrische encryptie worden operaties gebruikt die niet omkeerbaar zijn. Er worden tweeverschillende sleutels gebruikt: een publieke sleutel en een private sleutel. De publieke sleutelwordt gebruikt om de informatie (in de meeste gevallen een symmetrische sleutel) te encrypteren,


de private sleutel die enkel in het bezit is van de ontvanger, dient om de informatie te decrypteren.Omdat de actie onomkeerbaar is, is de ontvanger de enige die de informatie zal kunnen lezen.

Digitale handtekeningen

Digitale handtekeningen maken net zoals bij asymmetrische encryptie gebruik van een sleutelpaar.De hash (MD5 of SHA) van een bepaald bestand wordt versleuteld met de private sleutel vande eigenaar. Ontvangers kunnen met behulp van de publieke sleutel van de eigenaar de hashdecrypteren en nagaan of die overeenkomt met het orgineel. [27].

Het beveiligen van een communicatiekanaal kan verwezenlijkt worden door een combinatie vande 3 bovenstaande bouwblokken.

Authenticatie en autorisatie

De meest gebruikte manier om toegangscontrole te realiseren is om de persoon die het toestelbedient te identificeren, waarna beslist wordt tot welke gegevens die persoon toegang krijgt. Au-thenticatie is het verifieren van de echtheid van de persoon of het proces. Autoriseren is hetbeslissen wat de toegelaten gebruiker mag doen. Dit moet steeds gebeuren volgens het principevan de minste privileges [28]: elke gebruiker slechts de strikt nodige toegang geven om zijn functiegoed te kunnen uitvoeren. In dit onderzoek gaan we vooral dieper in op het begrip authenticatie.

Gebruikersnaam en paswoord

Op paswoord gebaseerde systemen verlenen toegang aan diegene die het correcte paswoordweet. De controle van het paswoord, hangt af van het type systeem. Paswoorden kunnen lo-kaal opgeslagen worden en vergeleken worden met het ingegeven paswoord. Vroeger was hetde gewoonte om paswoorden onversleuteld op te slaan. Later werden ze geencrypteerd opgesla-gen, maar de encryptiemechanismen konden bij nader inzien zeer gemakkelijk gekraakt worden.Vandaag gebruiken vele applicaties een gecentraliseerd authenticatiesysteem zoals LightweightDirectory Access Protocol (LDAP) of Active Directory. Single Sign-On (SSO) doet zowel het ge-bruiksgemak als de veiligheid ten goede. Wanneer paswoorden langs een onversleutelde verbin-ding verstuurd worden, kunnen ze zeer gemakkelijk achterhaald worden. Een mogelijke oplossingvoor dit probleem is het authenticeren met een challenge-response algoritme. Hierbij encrypteertde server een challenge, die door de client verstuurd is. Omdat de server het paswoord van declient gebruikt, en eveneens de enige server is die in het bezit is van dat paswoord, zullen client enserver zich onderling authenticeren.

Certificaat gebaseerde authenticatie

Een certificaat is een bestand met informatie die de identiteit van een gebruiker of computer linktaan een publieke en private sleutel. Wanneer certificaten gebruikt worden voor authenticatie, wordtde private sleutel gebruikt om een request of een challenge te ondertekenen. De bijhorende pu-blieke sleutel, beschikbaar in het certificaat, kan gebruikt worden door de server om het bericht tevalideren. Als het resultaat overeenkomt met het verwachte antwoord, is de identiteit bewezen.

Authenticatie over SSL/TLS

Secure Sockets Layer (SSL) is een certificaatgebaseerde technologie die serverauthenticatie eneen symmetrisch geencrypteerde verbinding voorziet. Clientauthenticatie kan ook verwezenlijktworden op voorwaarde dat de client voorzien wordt van een eigen certificaat en de server hiervoorcorrect geconfigureerd is.

Authenticatie met behulp van smart cards

Wanneer een aanvaller de private sleutel van een client kan bemachtigen, wordt het hele authenti-


catiesysteem ondermijnd. Als de sleutel op het toestel wordt bewaard, is er een potentieel gevaar.Een maatregel die hiervoor kan genomen worden, is de private sleutel los van het toestel bewaren.Smart cards kunnen gebruikt worden voor dit doeleinde. Een smart card die gebruikt wordt voorauthenticatie ziet eruit als een bankkaart. De private sleutel wordt op de chip opgeslagen. Metbehulp van een smart cardreader en een PIN code, kan de private sleutel opgeroepen wordenom bepaalde data te encrypteren of te ondertekenen. Smart cards lossen het probleem van de tebewaren private sleutel op, maar de gebruiker moet de PIN code en de smartcard veilig bewarenom de veiligheid te garanderen. We spreken hier van strong authentication.

Two-factor authenticatie

Bij two-factor authenticatie worden twee onafhankelijke factoren gebruikt om een gebruiker te au-thenticeren. De ene factor is iets dat de gebruiker weet, bijvoorbeeld een paswoord of een PINcode. Een tweede factor is iets dat de gebruiker heeft, bijvoorbeeld een smart card of een vin-gerafdruk. Beide factoren zijn noodzakelijk om de authenticatie te doen slagen. Wanneer singleauthentication onvoldoende veiligheid biedt voor een bepaalde applicatie, kan er geopteerd wordenvoor een strengere vorm van authenticatie zoals two-factor authenticatie. [30]

Veilige communicatie

Om een communicatiekanaal van confidentialiteit en integriteit te voorzien, wordt Secure SocketLayer (SSL) of diens opvolger Transport Layer Security (TLS) geımplementeerd. SSL bevindt zichtussen de TCP laag en de applicatielaag en wordt gebruikt voor TCP-gebaseerde toepassingente beveiligen. Dit gestandarizeerd protocol encrypteert de data tussen verzender en ontvanger enkan ook aan client- en serverauthenticatie doen. Belangrijk is dat het server-certificaat vertrouwdwordt door de client. Dit wordt meestal verwezenlijkt door het certificaat te laten tekenen dooreen Certificate Authority. Het client-toestel moet voorzien worden van de publieke sleutel van datcertificaat. Alle welgekende internetbrowsers zijn voorzien van deze publieke sleutels. Wanneer hetcertificaat geaccepteerd wordt door de client, spreken we van server-authenticatie. We spreken vanmutual authentication als client en server zich bij elkaar authenticeren. Na het authenticatieproceskan de sessionkey afgesproken worden tussen client en server voor de symmetrische encryptievan de te verzenden data.

Een SSL-connectie opzetten gebeurt in 2 fases: Handshake fase en Secure data transfer fase.Tijdens de handshake fase wordt er onderhandeld over encryptiealgoritmes, aan server (en client)authenticatie gedaan en er worden sleutels overeengekomen voor encrytie van data en MessageAuthentication Code (MAC).

Certificaten en PKI

Certificaten

Een certificaat is een bestand, uitgegeven door een bepaalde autoriteit, dat gebruikt wordt voorhet encrypteren van bepaalde informatie. In het bestand kan onder andere de publieke sleutel ende private sleutel van een partij worden opgeslagen. Wanneer een certificaat publiek toegankelijkis, zal er enkel een publieke sleutel aanwezig zijn. De private sleutel van een partij mag nooitvrijgegeven worden. Het gebruik van een certificaat kan verschillende doeleinden hebben. Digitalehandtekeningen, authenticatie, versleutelde communicatie,... X.509 is een ITU-T standaard vooreen Public Key Infrastructure. Deze certificaten bevatten heel wat attributen zoals versienummer,algoritme, geldigheidsduur, publieke sleutel, uniek ID van de instantie,... [29]


Public Key Infrastructure

Public Key Infrastructure (PKI) is een van de meest voorkomende vormen van encryptie in de mo-derne elektronische transacties volgens Rhodes Ousley [28]. Een bepaalde computer of servicewordt erkend door middel van een certificaat. Op die manier kan de gebruiker de echtheid nagaanvan de aangeboden dienst of website. Een certificate authority (CA) geeft certificaten uit, on-derhoudt, vernieuwt, en trekt cerfiticaten terug. Het is mogelijk om als particulier een certificaatte laten ondertekenen door een publieke CA. CA’s worden meestal hierarchisch gestructureerdwegens security, redundantie en geografische ligging [28].

Certificaten kunnen ook self-signed zijn, men spreekt dan van een root certificate. Er is geentussenkomst van een externe CA. Een self-signed certificaat kan toegepast worden wanneer ergeen openbare toegang tot diensten of websites is. Een voorbeeld hiervan is een medewerker diemet een vertrouwd toestel van buitenaf toegang wilt verktrijgen tot een server in het bedrijfsnetwerk.Het SSL-certificaat dat gebruikt wordt om de veilige verbinding op te zetten, kan en mag self-signedzijn op voorwaarde dat het toestel het certificaat expliciet vertrouwt.

3.1.5 Threats

Zonder bedreigingen zou niets beveiligd moeten worden. Helaas zullen er altijd individuen, groepe-ringen of zelfs bedrijven zijn die confidentiele data willen stelen. Digitale informatie is zeer kwets-baar, vooral omdat het stelen vanop afstand kan gebeuren. Er moet vanuit gegaan worden, dat elktoestel dat verbonden is met het internet aangevallen kan worden. Er zijn verschillende techniekenen strategieen om bits en bytes te stelen. Het is belangrijk om deze technieken onder de loep tenemen zodat de ontwikkelaar weet waar de zwaktes verborgen liggen. Als er geen maatregelenworden genomen en geen onderhoud wordt voorzien, zal het toestel gecompromiteerd worden [2].

Malware

Malware kan onderverdeeld worden in 3 groepen: virussen, wormen en Trojaanse paarden. Demeeste kwaadaardige programma’s bestaan uit een samenstelling van deze 3 componenten. Delevenscyclus van kwaadaardige code ziet eruit als volgt:

1. Find

2. Exploit

3. Infect

4. Repeat

Slechts wanneer alle kwetsbaarheden opgelost zijn, zal de kwaadaardige code geen effect meerhebben op het systeem. Actieve malware blijft zich wel verspreiden. Volgens Symantec’s SecurityResponse research centers, duiken er nog virussen, wormen en Trojaanse paarden op die al jarenoud zijn.

Het is dus zeer belangrijk dat malware geen toegang krijgt tot het systeem. Er zijn verschillendefactoren en componenten die een cruciale rol spelen hierin. Niet alleen het besturingssysteem,maar ook de distributie van software, de oplettendheid en kwalificatie van de gebruiker en de net-werkomgeving zijn cruciale factoren.


Fysieke aanval

Wanneer een toestel in de handen komt van een kwaadaardige persoon, heeft die meestal carteblanche: data en paswoorden stelen, malware installeren en het toestel fysiek beschadigen. Hoemobieler het toestel, hoe gevoeliger het is voor diefstal. Waar grote servers nagenoeg onmo-gelijk gestolen kunnen worden, kan dit bij smartphones binnen enkele seconden. Er wordt eenonderscheid gemaakt tussen een online en een offline aanval. Tijdens een offline attack zal hetbestandssyteem gedumpt worden en op een ander, krachtig systeem aanvallen uitgevoerd wordenom de data te ontcijferen. Bij een online attack heeft de aanvaller het toestel in bezit en zullener met tussenkomst van hard- of software pogingen ondernomen worden om paswoorden of de-cryptiesleutels te achterhalen. Tegen fysieke aanvallen bestaan er verschillende maatregelen diegenomen kunnen worden om diefstal van informatie te vertragen of onmogelijk te maken.

3.1.6 Beveiligen van mobiele toestellen

Het gebruik van mobiele toestellen is het laatste jaar sterk toegenomen. De mobiele platformenevolueren aan een razend tempo. De beveiliging ervan is dus genoodzaakt even snel te evolue-ren. Dit maakt het er voor software ontwikkelaars niet gemakkelijker op om veilige applicaties tebouwen. Deze toestellen zijn mobiel en gemakkelijk in gebruik, en dat maakt ze juist zo kwetsbaar.Het gebruik van een SD-kaart is zeer gebruiksvriendelijk, maar de data erop is vaak onbeveiligd.Een alfanumeriek paswoord van 10 karakters is veel omslachtiger dan een 4 cijferige PIN code.Een smartphone kan veel gemakkelijker verloren geraken of gestolen worden dan een laptop. Eensmartphone of tablet is een toestel dat zeer veel veiligheidsririso’s met zich meebrengt. Het bestu-ringssyteem speelt een zeer grote rol in het beveiligen van het toestel, maar even belangrijk zijn deimplementaties van de software ontwikkelaar.

Aanvallers zijn meestal geınteresseerd in slechts 1 ding: geld verdienen. Dit doen ze door per-soonlijke gegevens of confidentiele bedrijfsdata te stelen. Maar malware ontwikkelen en installerenkan ook een grote bron van inkomsten opleveren. Malware is de laatste jaren zeer sterk gegroeid[9]. De mogelijke threats kunnen we onderverdelen in 2 groepen: diefstal en malware. Een modernmobiel platform is voorzien van 4 technieken om bestanden en sleutels te beschermen tegen beidegevaren.

• Data en Credential Protection: Het veilig opslaan van bestanden en sleutels. Niet alleende manier waarop informatie geencrypteerd wordt, maar ook waar bestanden en sleutelsopgeslagen worden en wanneer ze de mechanismes in werking moeten treden.

• App Distribution: Hoe applicaties beschikbaar gesteld worden en op welke manier en doorwie ze goedgekeurd worden.

• App Isolation: Het scheiden van applicaties en hun data. (Sandboxing)

• Mobile Device Management: Een bedrijf kan het toestel beheren, policies en beperkingeninstellen. Het toestel kan vanop afstand gewist of opgespoord worden.

De meeste mobiele platformen (Android, iOS en Windows Phone) hebben minstens deze 4 voor-zieningen. Hoe ze geımplementeerd worden, verschilt van platform tot platform. Het gebruik vanhardware backed oplossingen is overigens een trend die we zien in alle opgesomde besturings-systemen.


In de volgende sectie wordt dieper ingegaan hoe Windows Phone zich weert tegen mogelijke aan-vallen.

3.2 Bestandsoverdracht protocollen

3.2.1 File Transfer Protocol

File Transfer Protocol (FTP) is een op TCP gebaseerd protocol 1 dat bestandsuitwisseling tussencomputers mogelijk maakt. FTP maakt typsch gebruik van een datachannel (poort 20) en eencommandchannel (poort 21) om de communicatie tussen client en server te verzorgen. Het dat-achannel maakt niet altijd gebruik van poort 20. FTP kan in 2 modes gebruikt worden: de activemode of de passive mode.

In de active mode connecteert de client vanop een willekeurige poort N met poort 21 van de server.Vervolgens luistert de client naar poort N+1 en verstuurt een commando naar de FTP server omdeze poort kenbaar te maken. Deze poort is de datapoort van de client. Op die manier zijn de 4gebruikte poorten kenbaar bij zowel client als server. Het grote probleem met Active FTP is datde client geen echte connectie maakt met de data poort van de server. Het geeft de server enkelmee naar welke poort er geluisterd wordt. Wanneer de server de connectie met de client via deopgegeven poort initialiseert, zal de firewall van de client dit meestal blokkeren.

De passive mode gaat op een andere manier te werk om dit probleem op te lossen. De client zetnamelijk de connectie op voor zowel het datachannel als het commandchannel. Ook in deze modusduiken er enkele problemen op: Het datachannel van de server is niet meer poort 20, maar wordtrandom gegenereerd en is meestal een hoog genummerde poort. De server moet dan uitgaandeverbindingen op deze poort toelaten.

Ook het overdragen en het representeren van de data kan in verschillende modi gebeuren. Be-langrijk is dat server en client op voorhand afspraken maken welke modi gebruikt zullen worden.

Standaard voorziet FTP geen encryptie, waardoor de gegevens zeer gemakkelijk onderschept kun-nen worden. FTP over SSL (FTPS) daarentegen voorziet een extra encryptielaag. FTP biedt ge-bruikersnaam/paswoord authenticatie aan.

Er is geen API voor FTP te vinden in de Windows Runtime, de ontwikkelaar zal dus op zoek moetengaan naar een bestaande FTP library voor WinRT of zelf een ontwikkelen.

3.2.2 WebDAV

Web-based Distributed Authoring and Versioning (WebDAV) is een uitbreiding van het HTTP Pro-tocol. HTTP gebruikt gestandariseerde poortnummers, waardoor firewalls geen moeite hebben omverkeerd door te laten in beide richtingen. De fileserver is een webserver waar lezen en schrijvenvan bestanden en mappen op mogelijk gemaakt wordt. Het protocol maakt gebruik van XML omopdrachten en antwoorden uit te wisselen. De aanvraag die de client verstuurt bevat altijd het typebericht (XML in dit geval), de lengte ervan en de WebDAV methode met de nodige parameters.Het antwoord van de server bevat naast het type en de lengte een status code. Aan de handvan de status code kan meteen gezien worden of de aanvraag succesvol was of waarom de actieafgebroken werd. Hieronder de belangrijkste methodes van WebDAV [22]:

1FTP is gedefinieerd in RFC 959.


• PROPFIND: vraagt eigenschappen op van een locatie op de server in XML-formaat. Dit kanzowel van een map als van een specifiek bestand zijn. Het antwoord van de server bevat eenlijst van aanwezig bestanden en eigenschappen zoals naam, extensie en datum van creatie.

• PROPPATCH: veranderen of verwijderen van bepaalde eigenschappen van de opgegevenresource.

• MKCOL: aanmaken van een map.

• COPY: kopieren van een bron van de ene URI naar de andere.

• MOVE: verplaatsen van een bron van de ene URI naar de andere.

Ook het WebDAV protocol zit niet in de Windows Runtime. De ontwikkelaar zal net zoals bij FTPop zoek moeten gaan naar bestaande libaries of zelf een maken.

3.2.3 FTP v.s. WebDAV

Beide protocollen verschillen op het eerste zicht sterk van elkaar. Onderstaande tabel geeft eenoverzicht met de verschillen tussen beide protocollen.

FTP WebDAVVaste poortnummer Niet altijd JaAuthenticatiemogelijkheden Gebruikersnaam/paswoord Uitgebreide keuzeBestandsoverdracht 1 connectie per overdracht Meerdere transfers met 1 connectie mogelijkOverhead bij data/commando’s Zeer weinig (7 bytes) Relatief veel (370 bytes)

command/response communicatieUitgebreidEenvoudig te lezen en op te stellen

BeperktXML parser nodig

Protocol afspraken Veel afspraken nodig bij opzetten van channels Geen afspraken nodigSSL FTPS maar niet zonder problemen HTTPSAbstactie voor developer Niveau van sockets Standaard aanwezige API’s voor HTTP

Tabel 3.1: Vergelijking tussen WebDAV en FTP

Hoofdstuk 4

Security in Windows Phone

4.1 Windows Phone 8.x Architectuur

Door het toenemend gebruik van mobiele apparaten heeft Microsoft Windows een lichtgewicht va-riant van Windows ontworpen. Windows CE eiste minder resources en werd gebruikt op PDA’s,GPS-systemen, handhelds,. . . Hieruit groeide Windows Mobile, een mobiel besturingssysteemdat gebaseerd was op Windows CE. Windows Mobile voorzag verschillende functionaliteiten diede basis legden voor een besturingssysteem voor smartphones. In 2010 werd de opvolger vanWindows Mobile gepresenteerd: Windows Phone. De eerste versie, versie 7, behoorde nog steedstot de Windows CE-familie, maar was geheel vanaf de grond opnieuw opgebouwd [17]. SindsWindows Phone 8 is Microsofts mobiel OS gebaseerd op de stabielere Windows NT kernel tech-nologie. Windows NT is de verzamelnaam voor Microsoft’s besturingssystemen met een hybridekernel. Windows 8.1 (Pro en RT), alle versies van Server 2012 R2 en Windows Phone 8.1 behorentot NT-versie 6.3 [19].Windows Phone maakte tot en met versie 7.5 gebruik van de het .NET Compact Framework en Sil-verlight runtime. Vanaf versie 8.1 krijgen ontwikkelaars de mogelijkheid om de Windows Runtime(WinRT) te gebruiken. Deze applicaties worden onder de noemer Windows Phone Store apps ge-bracht en maken het mogelijk om cross-device applicaties (universal applications) te ontwikkelen.Zowel Silverlight als WinRT zijn gebaseerd op C# en XAML maar ze voorzien verschillende API’s.Silverlight wordt nog steeds ondersteund in Windows Phone 8.1 zodat backward compatibility ge-garandeerd wordt. Een andere nieuwe toevoeging aan Windows Phone 8.1 was Windows Libraryfor JavaScript (WinJS). Dit laat ontwikkelaars toe om gebruik te maken van HTML5, javascript encss in hun applicaties.

Figuur 4.1: Windows Phone 8.1 App Development Platform [24]

16


Het valt op dat Microsoft streeft naar een gemeenschappelijk platform voor alle toestellen. Nietalleen de core is nagenoeg identiek, maar ook de runtime voor de applicaties vormt een gemeen-schappelijke uitvalsbasis voor ontwikkelaars. WinRT biedt zeer goede mogelijkheden op vlak vanveiligheid en betrouwbaarheid. Heel wat securityfeatures zijn immers gelijkaardig met de anderebesturingssystemen die behoren tot Windows NT 6.3. Laat ons niet te veel veralgemenen: Win-dows Phone is niet gewoon een Windows op een smartphone. Het is een zeer gesloten besturings-systeem en de applicaties die erop draaien hebben veel meer restricties dan de desktopversie.

Windows Phone 8.1 biedt veel mogelijkheden voor managed devices. Deze toestellen worden danvolledig beheerd door het bedrijf. Via een Mobile Device Management (MDM) systeem, kunnenpolicies en credentials verspreid worden. Ook kan het toestel vanop afstand volledig of gedeeltelijkleeggemaakt worden. Deze thesis legt immers de focus op BYOD toestellen. Toestellen die nietbeheerd worden door het bedrijf, maar enkel en alleen door de gebruiker. Er wordt dieper ingegaanop de security features die Windows Phone biedt en die de software ontwikkelaar kan gebruiken.Microsoft voorziet enkele standaard ingebakken security features die altijd actief zijn in het systeem.Daarnaast zijn er API’s die verschillende bouwblokken bevatten voor de ontwikkelaar.

4.2 App distribution

Windows Phone 8 is een zeer gesloten besturingssysteem. Het spreekt dan ook voor zich dat,naast het voorzien van isolatiemechanismen (zie 4.3) en veilige opstarttechnieken (zie 4.6), Mi-crosoft alle applicaties controleert alvorens ze publiek beschikbaar komen in de Windows PhoneStore. Microsoft analyseert de code van de applicatie. Een lijn code die volgens Microsoft kwaad-aardig is, zorgt ervoor dat de applicatie geweigerd wordt. Niet alleen malafide code, maar eveneensbedenkelijk of ongewenst gedrag van de applicatie, kan leiden tot het afwijzen ervan. Wanneer eenapplicatie een bestand probeert uit te lezen buiten zijn sandbox, zal die hoogstwaarschijnlijk nietaanvaard worden, ook al zal deze actie niet slagen in haar opzet (zie 4.3). Het aanpassen vande applicatie nadat ze goedgekeurd is en gecertificeerd is in de WP Store (door bijvoorbeeld hetdownloaden van een uitvoerbaar stuk code), wordt bij Microsoft ook gezien als verdacht gedrag.Naast het opsporen van malware, onderzoekt Microsoft ook de beveiliging van de applicatie. Erwordt gecontroleerd of paswoorden al dan niet in plaintext worden opgeslagen en of er binary pro-tections (zie 4.7) aanwezig zijn. De hele lijst van voorwaarden en tips kan geraadpleegd wordenop https://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx.

We kunnen besluiten dat Microsoft een zeer strenge selectieprocedure heeft. De Play Store vanGoogle is zeer open en Microsoft is zelfs iets strenger dan Apple [7]. In tabel 4.1 een vergelijkingtussen de Windows Phone Store, de App Store van Apple en de Google Play Store.

Windows Phone iOS AndroidApp vetting Zeer strenge controle Strenge controle Zwakke controleApps Downloaden Windows Phone Store Apple App Store Google Play Store, third-parties

Developer programIndividual e14Company e75

e99 e25

Tabel 4.1: Vergelijkende tabel app distribution [25]


4.3 App isolation

Elke applicatie draait in zijn eigen sandbox, genaamd AppContainer. Een AppContainer is eenproces-isolatie mechanisme dat zeer klein opgedeelde security persmissies voorziet. Dit mecha-nisme komt de beveiliging ten goede; het beperkt de read/write mogelijkheden van een applicatie.De security policy van een AppContainer wordt bepaald door de software ontwikkelaar en wordtafgehandeld door het OS. Door verschillende capabilities te activeren (zoals GPS, camera, net-working, certificaten, ...) kunnen de processen in die sandbox toegang verkrijgen tot de gedefini-eerde Windows Phone resources. De verschillende capabilities kunnen gespecifieerd worden inhet Package.appxmanifest bestand.

Een AppContainer heeft volgende eigenschappen:

• Naam. Een unieke naam voor de AppContainer.

• SID (Security Identifier). De Appcontainer SID is gegenereerd op basis van de naam vande sandbox.

• Capabilities. De lijst met wat de processen in de AppContainer kunnen doen of benaderen.

De toegagnscontrole van de processen wordt verzorgd door de NT kernel. Met behulp van het SIDvan de AppContainers wordt gecontroleerd in Access Control Lists (ACL’s) of de applicatie toegangheeft tot de gevraagde actie.

De werking van de AppContainer wordt hieronder afgetoetst op het gebruik van verschillende map-pen en bestanden.

• Een applicatie zonder capabilities kan enkel toegang verkrijgen tot de AppData-map (local-, roaming- en temp-mappen). Deze map bevat alleen bestanden die tot de applicatie zelfhoren: instellingen, voorkeuren, runtime states en app-specifieke bestanden geschikt voorverschillende doeleinden. De levenscyclus van de appdata-map is gebonden aan die van deapplicatie: Ze wordt verwijderd wanneer de gebruiker de applicatie deınstalleert. De functiesvan de verschillende submappen zijn:

– Local: data, bestaande op het toestel en wordt gebackupt naar de cloud.

– Roaming: data, bestaande op alle toestellen van de gebruiker waar die applicatiegeınstalleerd is.

– Temp: data dat door het systeem op eender welk moment kan verwijderd worden.

• Om een andere locatie zoals mediabibliotheken of documenten te benaderen, moet de ap-plicatie beschikken over de bijhorende capabilities. Indien dit niet het geval is, zal de API nietaangesproken kunnen worden. Eveneens is het onmogelijk voor een applicatie om te lezenof schrijven in het register 1 en toegang te krijgen tot de appdata-map van andere applicaties.

Volgens Microsoft [20] biedt de AppContainer de volgende voordelen:

• Reduceren van aanvalsmogelijkheden. Applicaties krijgen enkel en alleen toegang tot de,in de code, aangegeven capabilities.

1Enkele delen van het register zijn wel toegankelijk om de werking van de applicaties mogelijk te maken.


Figuur 4.2: Windows Phone 8.x chamber architecture

• Gebruikerstoestemming en controle. De capabilities die de applicatie gebruikt, wordenvermeld in de detailpagina in de Windows Phone Store. Wanneer een capability gevoeligeinformatie betreft, zoals locatie, wordt de gebruiker gevraagd toestemming te geven.

• Isolatie. Applicaties kunnen enkel met elkaar communiceren via voorgedefineerde commu-nicatietunnels en data types.

Het Windows Phone 8.x security model is gebaseerd op het principe van least privilege. Applica-ties verkrijgen de minimale capabilities om hun legitieme taken te kunnen uitvoeren. Er zijn tweekamers beschikbaar: de Least Privilege Chamber (LPC) en de Trusted Computing Base (TCB).Alle applicaties draaien in de LPC kamer, onafhankelijk of ze Windows Store apps zijn, MicrosoftOEM services of third-party applicaties. Er zijn zelfs enkele drivers die in deze kamer draaien ([7]).De enige code die draait in de TCB kamer, zijn kernelcomponenten. Wanneer de applicatie gecom-promiteerd wordt, is de schade die een aanvaller kan aanrichten beperkt tot de voorgedefineerdesandbox.

Figuur 4.3: Windows Phone 8.x chamber architecture

Het unlocken van Windows Phone 8 en 8.1 toestellen wordt nagenoeg onmogelijk gemaakt doorMicrosoft en de fabrikanten. Dit komt door het opstartmechanisme (zie 4.6) en door de gesloten-heid van het systeem. Hackers zijn er immers wel in geslaagd om bepaalde toestellen (SamsungAtiv, Huawei Ascend W1) te unlocken. Door het unlocken van het toestel, worden verschillendebeperkingen doorbroken:

• Toegang tot het volledige bestandsysteem.


• Het volledige register lezen en aanpassen.

• Sideloaden van applicaties.

• Alle capabilities beschikbaar maken.

Het unlocken van een Windows Phone toestel ondermijnt dus alle vormen van de beveiliging. Mi-crosoft bestrijdt het unlocken van Windows Phone toestellen actief en lijkt daar redelijk goed in teslagen.Ook in Android en iOS wordt er aan sandboxing gedaan. De sandbox in iOS is vergelijkbaar methet model van Windows Phone: er wordt een sandbox aangemaakt bij installatie van de applica-tie. Elke applicatie heeft zijn eigen homedirectory die niet toegankelijk is voor andere applicaties.Het jailbreaken van een Iphone zorgt ervoor dat bepaalde restricties die Apple opgelegd heeft,te niet gedaan worden. Op die manier kunnen applicaties die niet getekend zijn door Apple, tochgeınstalleerd en gebruikt worden. Elke applicatie draait wel nog in zijn sandbox, hoewel een kwaad-aardige applicatie buiten de sandbox zou kunnen gaan werken. Het jailbreaken van een iOS toestelwordt vrijwel direct mogelijk gemaakt door hackers na de release van het toestel.

Bij Android wordt sandboxing gerealiseerd op procesniveau. Enkel processen met dezelfde UID(Unique User Identifier) kunnen elkaars resources benaderen. Elke app krijgt een ander UID wan-neer ze opgestart wordt. Voor bepaalde resources zoals locatie, moet de gebruiker globale toe-stemming geven. Het rooten van een Android toestel zorgt ervoor dat applicaties root rechtenkunnen krijgen. Op deze manier wordt de sandbox doorbroken. Het rooten van een Androidtoestel, geeft de gebruiker (of een applicatie) zo goed als volledige controle over het besturings-systeem. Het rooten van een Android toestel is eenvoudig en wordt zelfs soms ondersteund doorde fabrikant.

Windows Phone iOS AndroidApp sandbox Least Privilege Least Privilege Meer permissies dan nodigToegelaten apps Enkel getekende Enkel getekende Geen beperkingJailbreaking & Rooting Nagenoeg onmogelijk Actief bestreden Unlocking soms ondersteundPermissies At runtime of bij installatie At runtime Bij installatie

Tabel 4.2: Vergelijkende tabel app isolation [25]

4.4 Data and credential protection mechanisms

Het is zeer nuttig voor een app ontwikkelaar om te weten hoe en wat geencrypteerd wordt inWindows Phone. Wanneer het toestel gestolen is en de aanvaller probeert data te verkrijgen, ishet belangrijk te weten hoe goed de application data beveiligd is. In deze sectie wordt besprokenhoe Windows Phone omgaat met device encryptie en externe opslag zoals een SD-kaart.

4.4.1 Internal Storage

Op het moment van schrijven, is bestandsversleuteling op Windows Phone 8 en 8.1 niet standaardgeactiveerd. Er is zelfs geen publieke API beschikbaar om encryptie op filesystem niveau mogelijkte maken bij unmanaged devices. Toestellen die beheerd worden door het bedrijf, kunnen hun


intern geheugen laten encrypteren via een policy. Dit gebeurt dan met Bitlocker. Volgens Micro-soft maakt Bitlocker gebruik van Andvanced Encryption Standard (AES) in Chained Block Cipher(CBC) mode. Bitlocker maakt eveneens gebruik van een TPM (Trusted Platform Module) waar-door we kunnen spreken over hardware backed encryption. Op een persoonlijk toestel wordt dusalle informatie ongeencrypteerd opgeslagen. Gelukkig biedt de sandbox een vorm van isolatie enkunnen bestanden op het interne geheugen niet zomaar in de verkeerde handen komen.

4.4.2 External Storage

Wanneer Bitlocker geactiveerd is, wordt de SD-kaart niet geencrypteerd. In Windows Phone 8kunnen Store applicaties geen data wegschrijven naar de SD-kaart; ze hebben enkel leesrechten.OEM- en Microsoft-applicaties daarentegen, hebben zowel lees- als schrijfrechten op het externgeheugen. In Windows Phone 8.1 is daar verandering in gekomen: applicaties kunnen met deremovableStorage capability schrijven naar het extern geheugen (enkel extensies die door de ap-plicatie geregistreerd zijn) Eveneens kunnen applicatiebestanden op de SD kaart gezet worden.Het gaat dan over een verborgen partitie waar ook sandboxing in wordt toegepast.

4.4.3 Data Protection API

Ontwikkelaars kunnen natuurlijk wel gebruik maken van bestandsencryptie in hun applicatie. Win-dows voorziet een eenvoudige API om bestandsencryptie mogelijk te maken. Data Protection API(DPAPI) is beschikbaar in de desktop versies van Windows en in Windows Phone. In figuur 4.4wordt de relatie van de verschillende sleutels weergegeven. De Master Key Encryption Key wordtafgeleid van het wachtwoord van de gebruiker. Deze MK Encryption Key wordt gebruikt om deMaster Key te versleutelen. De Master Key wordt op zijn beurt gebruikt om een symmetrischesleutel af te leiden die de data encrypteert [15].

DPAPI heeft 2 interfaces die elke een methode voorzien: CryptProtectData met Protect() en Cryp-tUnprotectData met UnProtect(). Beiden geven de vercijferde, respectievelijk ontcijferde data terug.We moeten immers verschil maken tussen de verschillende namespaces:

Namespace System.Security.Cryptography.ProtectedData

Pub l i c s t a t i c byte [ ] P ro tec t (byte [ ] userData ,byte [ ] op t i ona lEn t ropy

)

Pub l i c s t a t i c byte [ ] Unprotect (byte [ ] encryptedData ,byte [ ] op t i ona lEn t ropy

)

DPAPI zorgt voor een master key per gebruiker, zodat applicaties van de ene gebruiker geen toe-gang hebben tot beschermde data van een andere applicatie. Dit is zeer nuttig in het geval vande desktop- en serverversies van Windows. In Windows Phone draaien alle applicaties immersonder dezelfde gebruiker. Alle data, beschermd door DPAPI op Windows Phone, is versleuteld metdezelfde key voor alle applicaties. Dit zorgt voor zwakheden in de beveiliging. De extra parameter


Figuur 4.4: Windows Data Protection API

zorgt hier voor een oplossing. OptionalEntropy is een extra parameter die gebruikt wordt om dedata te encrypteren en decrypteren. Zonder deze parameter kan data dus niet ontcijferd worden.Helaas is deze namespace enkel beschikbaar in het .NET Framework en in Windows Phone Siler-light 8 en niet in de Windows Runtime.

Namespace Windows.Security.Cryptography.DataProtection

Constructor BeschrijvingDataProtectionProvider() Constructor used for decryption operations.DataProtectionProvider(String) Constructor used for encryption operations.

Tabel 4.3: Verschillende constructors in DataProtectionProvider klasse

Er zijn twee constructors beschikbaar om een DataProtectionProvider [16] aan te maken: eenencryptor en een decryptor. De encryptor is voorzien van een extra parameter. Hier kan bepaald


worden wie de data beschermt. Om lokale data op te slaan, zijn er 2 mogelijkheden:

• LOCAL=user: De gebruikte sleutel is gebruikerafhankelijk.

• LOCAL=machine: De gebruikte sleutel is toestel-afhankelijk. Elke gebruiker op het toestelkan data encrypteren en decrypteren.

Er is dus geen mogelijkheid om een extra parameter mee te geven die het encryptieproces applicatie-afhankelijk maakt zoals hierboven. Microsoft voorziet wel een mogelijkheid om streams meteen teencrypteren.

Methode BeschrijvingProtectAsync Asynchronously protects static data.ProtectStreamAsync Asynchronously protects a data stream.UnprotectAsync Asynchronously decrypts static data.UnprotectStreamAsync Asynchronously decrypts a data stream.

Tabel 4.4: Verschillende methodes in de DataProtectionProvider klasse

Hoewel de parameter optionalEntropy eigenlijk wel noodzakelijk is om een optimale beschermingte hebben, wordt dit niet voorzien in de Windows Runtime. Voor intern geheugen is dit minderbelangrijk omdat er een sandbox aanwezig is, maar wanneer bestanden opgeslagen worden ophet externe geheugen, kunnen alle applicaties deze benaderen.

4.4.4 CredentialLocker

Paswoorden van de gebruiker kunnen allemaal opgeslagen worden in Windows Phone. Wanneergebruik gemaakt wordt van de PasswordVault klasse, worden wachtwoorden opgeslagen in eendatabase. Deze database is beschermd door de DPAPI. Applicaties kunnen enkel credentialsopvragen die opgeslagen zijn door de applicatie zelf; niet die van andere.

Ten slotte nog een vergelijkende tabel met iOS en Android. iOS beschikt eveneens over eensoortgelijke Data protection API, maar er zijn meer mogelijkheden voor de ontwikkelaar. Bij iOSgebeurt encryptie op bestandssysteemniveau automatisch en is eveneens hardware backed. Pasvanaf versie 5.0 Lollipop gebeurt deze encryptie automatisch bij Android 2. Android voorziet geenspeciale API om snel een bestand te encrypteren. De ontwikkelaar moet gebruik maken van deverschillende cryptografische klasses om bestandsencryptie mogelijk te maken.

Windows Phone 8.x iOS Android

File system encryptieBitLockerEnkel managedhardware backed

Keychain Data ProtectionAutomatischhardware backed

dm-cryptAutomatisch vanaf v. 5.0hardware backed

BestandsencryptieDPAPI, user of deviceafhankelijk

Data Protection ClassesUitgebreide functieshardware backed

Geen speciaal voorzieneAPI

Tabel 4.5: Vergelijkende tabel data protection

2Ekel op toestellen met voldoende resources zoals de recente Nexus 5 en 6.


4.5 Interprocess communication

Interprocess communication (IPC) mechanismes zorgen voor de communicatie en samenwerkingtussen verschillende applicaties. Het gebruik ervan laat toe om vanuit de ene applicatie een andereop te starten en informatie uit te wisselen. In Windows Phone zijn er twee types IPC: file extensionhandlers en protocol handlers. In dit gedeelte worden beide types kort besproken.

4.5.1 File Extension Handlers

Applicaties kunnen geassocieerd worden met bepaalde extensies. Deze associatie moet in hetmanifest-bestand van de applicatie beschreven staan. Een applicatie kan een bestand hebbenin zijn isolated storage en het laten openen door een andere applicatie die geassocieerd is metde extensie ervan. De applicatie krijgt dan toestemming om het bestand in de sandbox van deapplicatie te lezen.

StorageFolder l o c a l =Windows . Storage . App l i ca t ionData . Current . Loca lFo lder ;

S to rageF i le t e s t f i l e = awai t l o c a l . GetFi leAsync ( ” f i lename . extens ion ” ) ;

/ / Launch the f i l eWindows . System . Launcher . LaunchFileAsync ( t e s t f i l e ) ;

We maken nog enkele bedenkingen: De gebruiker wordt niet gevraagd om toestemming te gevenbij:

• een webpagina die geopend wordt met Internet Explorer vanuit een applicatie.

• het openen van een bijlage van een email.

• het openen van een bestand door een andere applicatie (zoals in bovenstaande code).

We zien hier 2 gevaren:

• De applicatie kan een kwaadaardig bestand of link openen zonder dat de gebruiker dit kantegenhouden.

• Wanneer een kwaadaardige applicatie een associatie maakt met een bekende extensie (bij-voorbeeld .pdf ), kan die misbruik maken van het bestand en de inhoud ervan.

Gelukkig is er de strenge app distribution (4.2) van Microsoft die de kans op kwaadaardige appli-caties drastisch vermindert.

4.5.2 Protocol Handlers

Protocol Handlers werken met Uniform Resource Identifiers (URI) en Uniform Resource Locators(URL). Ook hier wordt een applicatie geassocieerd met de te openen link. Het verschil met exten-sion handlers zit hem eigenlijk volledig in de functionaliteit. Met Protocol Handlers kan bijvoorbeeldeen telefoonnummer doorgegeven worden aan de applicatie die daarvoor geschikt is en er naar kanbellen. Ook hier moet de gebruiker nooit toestemming geven (wel wanneer er verbinding gelegdwordt met een NFC toestel).


4.6 OEM Secure Boot

Het opstartproces van een Windows Phone bestaat uit 3 fases: Secure boot, Trusted Boot enSystem and app integrity check. Wanneer een Windows Phone toestel start, zal de firmware(UEFI) de bootloader enkel opstarten als de digitale handtekening van de bootloader goedgekeurdwordt. Zo wordt de integriteit van de bootloader gecontroleerd. Secure Boot kan op WindowsPhone en Windows RT niet uitgeschakeld worden. Hieruit kan afgeleid worden dat het onmogelijkwordt om de bootloader te unlocken of te vervangen zoals bij Android of iOS.

In de tweede fase van het opstartproces worden alle Windows opstartbestanden gecontroleerdop integriteit. De bootloader verifieert de digitale handtekening van de Windows Phone kernel,die op zijn beurt alle andere componenten zoals drivers en opstartbestanden controleert. Nadatde Trusted Boot fase voltooid is, zullen de systeembestanden en de applicaties die automatischstarten gecontroleerd worden. Ook deze componenten moeten een digitale handtekening hebbenalvorens ze opgestart worden. Ongetekende of aangepaste applicaties kunnen onmogelijk gestartworden op Windows Phone. Het handtekenen van applicaties gebeurt door Windows zelf. Meerinfo hierover in deel 4.2 3. Omdat alle componenten en applicaties getekend moeten worden, is hetzeer moeilijk voor aanvallers om malware te installeren op het toestel.

3Wanneer het toestel in ’Developer mode’ staat, kunnen applicaties gesideload worden. Deze applicaties moetenniet getekend worden.


Figuur 4.5: Windows Phone OEM Secure Boot flowchart [19]

iOS beschikt over een gelijkaardig systeem wanneer het toestel opstart, genaamd Secure BootChain. Android beschikt sinds versie 4.4 KitKat over Verified Boot [11]. Dit systeem zorgt voor eenwaarschuwing wanneer de opstartprocedure niet geverifieerd kon worden. De tussenkomst van degebruiker zorgt dat het toestel wel opgestart kan worden. Verified Boot beperkt zich wel tot hetcontroleren van de kernel en de systeembestanden, er worden geen applicaties geverifieerd.


Windows Phone 8.x iOS AndroidSecure Boot Ja Ja Ja, vanaf 4.4 (opstarten blijft sowieso mogelijk)

Tabel 4.6: Vergelijkende tabel Secure Boot mechanisme

4.7 Exploit mitigation technologies

Net zoals alle moderne besturingssystemen biedt het Windows Phone 8 en 8.1 platform enkeletechnieken om het uitbuiten van kwetsbaarheden in het geheugen tegen te gaan. Aanvallers ofmalware kunnen bepaalde bits naar het geheugen schrijven. Door eigen code op een correctedoordachte plaats te plaatsen in de stack, kan de controle van een programma of besturingssys-teem overgenomen worden. Dit soort aanvallen worden in Windows Phone bemoeilijkt door on-derstaande drie technologieen. Zowel iOS als Android zijn voorzien van gelijkaardige technieken[25].

4.7.1 Stack Canaries

Stack Canaries zijn willekeurige waarden die geplaatst worden voor de kritische stack-data (bijvoor-beeld een return address). Wanneer de functie aan het return-statement komt, zal die de waardeeerst vergelijken met de eerder geplaatse waarde. Komt die overeen, dan gaat het programmaverder; indien niet, dan duidt dit erop dat de stack overschreven is en zal het programma onmidde-lijk stoppen. Wanneer een buffer overrun plaatsvindt, zal de canarie overschreven worden. SindsVisual Studio 2002 wordt deze optie voorzien in de compiler. Ondertussen wordt deze techniekautomatisch voorzien in het programma door de compiler van Visual Studio. Stack canaries biedenimmers geen volledige bescherming tegen dit soort aanvallen: De stack kan overschreven wordenalvorens de canary geplaats wordt [5].

4.7.2 Address Space Layout Randomization

ASLR zorgt ervoor dat geheugenlocaties willekeurig worden toegekend. Het base-address van eenmodule of een applicatie zal niet constant blijven gedurende de levenscyclus. Het doel van ASLRis het voorspellen van de geheugenstructuur nagenoeg onmogelijk te maken. Sinds WindowsVista voorziet de compiler van Visual Studio ASLR automatisch. Sterker nog, Windows Phone 8.1applicaties moeten ASLR geactiveerd hebben om gecertificieerd te worden. Helaas biedt ASLRook geen volledige garantie en bestaan er technieken om dit te omzeilen [35].

4.7.3 Data Execution Prevention

DEP zorgt ervoor dat de processor geen code uitvoert die zich bevindt op geheugenlocaties diebestemd zijn door data in plaats van uitvoerbare code. Dit is een gunstige techniek, want veel mal-ware of aanvallers injecteren uitvoerbare code in de stack. Uitvoerbare code bevindt zich normaalgezien niet in die geheugenlocaties [4].


4.8 Certificate trust stores

In Windows Phone bevinden zich 2 certificate trust stores: een applicatiespecifieke trust store eneen gedeelde, systeem trust store. Alle certificaten die vertrouwd worden door het OS bevindenzich in het tweede. Het gaat dan over standaard certificaten die beheerd worden door Windows.De ontwikkelaar kan een certificaat laten vertrouwen door een applicatie. Het certificaat wordt dantoegevoegd aan de trust store van de applicatie en bevindt zich dan in de sandbox. In tabel 4.7een korte vergelijking tussen beide.

Trust store App specifiek GedeeldScope App Container SystemCapability Geen sharedUserCertificatesInitieel Leeg Door het OS vertrouwde certificaten

Tabel 4.7: Vergelijking tussen beide trust stores.

4.9 Virtual smart cards

Virtual smart cards spelen in op de sterkere vormen van authenticatie: Strong Authentication enTwo Factor Authentication. Virtual smart cards zijn beschikbaar sinds de desktop versie van Win-dows 8 en Windows Phone 8.1. Ze maken gebruik van de Trusted Platform Module (TPM) in hettoestel en hebben volgende functies:

• Geisoleerde cryptografische operaties uitvoeren.

• Het genereren van non-exportable sleutels.

• Afweren van brute force aanvallen.

Virtual smart cards kunnen op veel gebieden ingezet worden [31]. Zo kunnen ze certificaten bevat-ten om in te loggen op services, een SSL verbinding of VPN op te zetten. Ze kunnen in combinatiemet BitLcker gebruikt worden om data volumes te encrypteren. Virtual smart cards kunnen zowelmanaged als unmanaged zijn. De verschillen zijn vooral te vinden in op vlak van beheersmoge-lijkheden vanop afstand en met policies. Sinds Windows 8.1 zijn er nieuwe API’s beschikbaar omsmart cards te beheren op een desktop, server of mobiel toestel. Virtual smart cards zijn vooralinteressant voor toestellen die beheerd worden door het bedrijf, maar ze kunnen eveneens ingezetworden voor BYOD toestellen.

De levenscyclus van een VSC wordt in figuur 4.6 voorgesteld. Bij het aanmaken van een VSC moetde gebruiker een PIN code instellen. De ontwikkelaar of het bedrijf kan een PIN policy opgevenwaaraan de PIN code moet voldoen. Provisioning is het inladen van specifieke credentials. Erkunnen maximaal 30 certificaten ingeladen worden in 1 VSC. Vanaf een geldig certificaat op dekaart staat en een private sleutel gegenereerd is, kan de VSC gebruikt worden. De gebruiker moettelkens zijn PIN code invoeren bij het gebruik ervan.


Figuur 4.6: De levenscyclus van een Virtual Smard Card [18]

4.10 Besluit

In theorie merken we dat Microsoft een zeer stabiel en veilig mobiel besturingssysteem aan hetontwikkelen is. Ondanks de vele jaren ervaring met computers en servers, zien we dat er tochnog verbeteringen mogelijk zijn. Zo zou de Data Protection API in de Windows Runtime uitge-breider mogen zijn. Het ontbreken van encryptie op filesystem niveau bij unmanaged toestellen iseveneens een werkpunt. App distribution en App Isolation kunnen wel de pareltjes van het bestu-ringssysteem genoemd worden. Virtual smart cards zijn een belovende toegevoegde waarde, maarstaan nog in de kinderschoenen. Er is naar mijn ondervinden weinig documentatie over te vindenen de implementatiemogelijkheden voor unmanaged cards zijn beperkt. Zonder tussenkomst vaneen CA, kunnen Virtual smart cards niet worden gebruikt in Windows Phone.

Hoofdstuk 5

Ontwerp van de toepassing

Alvorens er dieper ingegaan wordt op de beveiligingsmechanismen in de applicatie, wordt een over-zicht van de opstelling en de functionaliteit geschetst in 5.1. Vervolgens worden de verschillendecomponenten in de serverside (5.2) en clientside (5.3) toegelicht. De focus ligt op de clientside.

5.1 Functioneel overzicht

Om het gebruikte scenario te verwezenlijken in de praktijk is er nood aan een client, een server eneen communicatiekanaal tussen beide. Client en server authenticeren zich bij elkaar waarna declient in staat is om bestanden te downloaden, te openen en op te slaan op het externe geheugenvan het toestel.

Figuur 5.1: Functioneel overzicht van de opstelling

Server en client bestaan uit verschillende componenten (zie figuur A.2). De server beschikt overeen functionele unit die het bestandsoverdracht protocol voorziet en bestanden toegangelijk maaktvoor de client. Een authenticatieen policy component bepalen wie toegang verkrijgt tot deze be-standen. Een communicatie component vervolledigt de serverinfrastructuur. Op de client zien weeen gelijkaardige opbouw: een communicatie-, authenticatie-, en transfer-component. Een bijko-

30


mend element op de client verzorgt de omgang met bestanden wanneer die gedownload zijn: deopslagcomponent. Het protocol dat de bestandsoverdracht mogelijk maakt is WebDAV. WebDAVbiedt in dit geval meer voordelen dan FTP: (1) Geen problemen met firewall; (2) het standaardondersteunde HTTP protocol in WinRT biedt de developer een extra vorm van abstractie aan waar-door een beveiligde verbinding vlot kan worden opgezet en (3) voor WebDAV moeten op voorhandgeen afspraken met betrekking tot het protocol gemaakt worden, terwijl de mogelijkheden volledigvoldoen aan de functionele eisen van deze applicatie.

Figuur 5.2: Verschillende componenten in client en server

5.2 Serverside ontwerp

De server bestaat uit 4 verschillende componenten: Communicatie, Authenticatie, Bestandsbeheeren Policy specificaties.

5.2.1 Communicatie

De server moet overal bereikbaar zijn, dus beschikt over een publiek IP-adres om communicatiemet de buitenwereld mogelijk te maken. De webserver heeft een certificaat zodat een veilige ver-binding kan opgezet worden met de client. Er wordt gebruik gemaakt van Public Key Infrastructure


(PKI) om dit te verwezenlijken. Een SSL-verbinding is altijd vereist, voor elk niveau van classifi-catie: er is altijd confidentialiteit en integriteit in het kanaal voorzien. De webserver dwingt dusHTTPS verkeer af. De reden dat er gekozen is om elke verbinding, ook op het PUBLIC niveau,te beveiligen met SSL is om meteen vertrouwen te creeeren tussen client en server en om geenomslachtige omleidingen te moeten voorzien wanneer de gebruiker zich authenticeert in een ho-gere classificatie. Door SSL te gebruiken kan de client altijd zeker weten dat het om de correcteoriginele server gaat.

5.2.2 Authenticatie

De server authenticeert zich bij de client. Dit gebeurt bij het opzetten van de SSL-connectie metbehulp van PKI. Het certificaat wordt getekend door een CA en de client kan vervolgens de serverauthenticeren aan de hand van het certificaat van de CA.

5.2.3 Bestandsoverdracht

De webserver beschikt over een DAV-module die bestandsoverdracht met WebDAV mogelijk maakt.Bestanden moeten beschikbaar gemaakt worden en verdeeld worden in verschillende classifica-ties. Welke bestanden en mappen toegankelijk zijn voor de client, hangt af tot welke classificatie diebehoort. Het eenvoudig toevoegen van bestanden, gebruikers en klassen verhoogt de gebruiks-vriendelijkheid en de uitbreidbaarheid van het systeem.

5.2.4 Policies

Er wordt een onderscheid gemaakt tussen PUBLIC, CONFIDENTIAL, SECRET en TOP SECRET.Deze niveau’s stijgen respectievelijk in mate van vertrouwelijkheid. De policy component op deserver zorgt ervoor dat de bestanden verdeeld worden in deze klassen. De bestanden mogenpas zichtbaar en downloadbaar zijn voor geautoriseerde gebruikers. De 4 klassen leggen elkandere eisen op om toestemming te krijgen tot de bestanden die tot dat niveau behoren. Deserver verifieert ten slotte of aan de policies voldaan is wanneer een client de server benadert.Tabel 5.1 geeft een overzicht van de verschillende niveau’s met hun eisen.

PUBLIC CONFIDENTIAL SECRET TOP SECRETGebruikers authenticatie X XToestel authenticatie X XBestandsencryptie op extern geheugen X X XSSL verbinding X X X X

Tabel 5.1: De verschillende classificaties en hun eigenschappen

Er wordt wel enige vorm van autorisatie voorzien: een gebruiker die eerst behoort tot het niveauCONFIDENTIAL en later toegang krijgt tot het niveau SECRET, beschikt dus over beide authen-ticatiemechanismen om toegang te krijgen tot TOP SECRET. Gebruikers van het niveau CONFI-DENTIAL mogen dus niet geautoriseerd zijn voor TOP SECRET.


5.3 Clientside ontwerp

De client bestaat eveneens uit 4 componenten: Communicatie, Authenticatie, Bestandsoverdrachten Opslag.

5.3.1 Communicatie

Het gebruik van een communicatiekanaal over HTTPS wordt door de server afgedwongen. Declient is eveneens zo opgebouwd dat die enkel kan werken met beveiligde verbindingen. In hetgeval van een self-signed certificate of het gebruik van een niet erkende CA, wordt de client zogeconfigureerd dat de verbinding vertrouweljk is: De client bezit het certificaat van de CA, waardooraan serverauthenticatie gedaan kan worden. Voor de classificatie SECRET en TOP SECRET moetde client zich ook authentiseren op SSL niveau.

5.3.2 Authenticatie

Naast serverauthenticatie, moet ook de client zich authenticeren bij de server. De manier waaropdat gebeurt is afhankelijk van het classificatieniveau waarin de gebruiker zich wil aanmelden.

PUBLIC: geen authenticatie

Het niveau PUBLIC vereist geen client authenticatie. Iedereen kan toegang verkrijgen tot dezebestanden. Deze bestanden kunnen openbare informatie bevatten zoals persberichten, vacatures,uitgebrachte artikels, etc.

CONFIDENTIAL: Gebruikersnaam/paswoord

De gebruiker moet enkel gebruikersnaam en paswoord ingeven. Het classificatie niveau CONFI-DENTIAL bevat gevoelige informatie die alle medewerkers van het bedrijf kunnen consulteren.

SECRET: toestelauthenticatie

Omdat de opstelling altijd over een SSL verbinding beschikt, wordt er altijd aan serverauthentica-tie gedaan. Deze verbinding kan ook zo geconfigureerd worden dat client authenticatie ook eenvereiste is. We spreken dan van mutual authentication, two-way authentication of strong authenti-cation. Aangezien het client certificaat eigen is aan het toestel kan device authentication hier ookin zekere mate als bruikbare term beschouwd worden. De server vraagt het clientcertificaat op encontroleert of het getekend is door de opgegeven vertrouwde CA.

Hoe de client voorzien wordt van zijn private sleutel, getekend door de vertrouwde CA, kan opverschillende manieren mogelijk gemaakt worden:

• Er kan gewerkt worden met een registratieprocedure. Tijdens de registratie kan de servereen certificaat uitreiken waarmee de gebruiker toegang kan krijgen tot zijn account. Wanneerhet registratieproces afgelopen is en de administrator de gebruiker toestemming geeft om deserver te benaderen, is het clientcertificaat geldig om zich te authenticeren.


• Een andere mogelijkheid is dat de gebruiker zich met gebruikersnaam en paswoord zoukunnen inloggen op de server (classificatie CONFIDENTIAL) waarna de administrator dezeeen certificaat toereikt. Vanaf dat moment kan de gebruiker zich aanmelden met zijn privatesleutel en certificaat in de classificatie SECRET. Om dit op een beveiligde manier mogelijkte maken is een strenge vorm van autorisatie noodzakelijk: niet iedereen die zich aanmeldtop CONFIDENTIAL niveau, mag een certificaat uitgereikt krijgen.

• Een derde mogelijkheid is het genereren van een certificate request op de client. De attribu-ten in het certificaat kunnen dan gecontroleerd worden door de CA. Er kan gewerkt wordenmet een verificatie email of met een SMS-code. Er kunnen ook andere credentials opge-vraagd worden om bepaalde attributen te bewijzen tijdens het aanvragen van een certificaat:er kan bijvoorbeeld gevraagd worden om zich te authenticeren met de eID. Een bijkomendvoordeel om te werken met certificate requests, is dat certificaten beheert kunnen wordendoor Virtual smart cards (VSC) in Windows Phone. Wanneer de private sleutel en het cer-tificaat request gegenereerd worden door de VSC, is men zeker dat de private sleutel nooitbuiten het toestel zal geraken. Op deze manier realiseert men de strikte vorm van deviceauthentication.

• In een kleine omgeving of in een demo-opstelling kan het clientcertificaat op voorhand gege-nereerd en getekend worden door de client CA. Wanneer de gebruiker de applicatie voor deeerste keer opstart, kan het sleutelpaar ingeladen worden vanop de SD kaart.

TOP SECRET: Toestel- en gebruikersauthenticatie

De classificatie TOP SECRET eist zowel gebruiker- als toestelauthenticatie. Dit is een combinatievan beide, eerder reeds beschreven mechanismen.

5.3.3 Bestandsoverdracht

De WebDAV module in de client zorgt ervoor dat de gebruiker zich kan aanmelden en de bestandenop de server kan verkennen en downloaden. Het aanmelden op niveau van WebDAV gebeurt enkelmet gebruikersnaam en paswoord; device authentication gebeurt tijdens de SSL handshake. Hetopvragen van de eigenschappen van een resource gebeurt met PROPFIND, bestanden downloa-den gebeurt met de GET methode. Deze module maakt (uitsluitend) gebruik van HTTPS verkeeren bestaat uit volgende onderdelen:

• Connectie component: Connectie maken met de server en eventuele credentials doorgeven.

• Opdrachten component: Eigenschappen opvragen, locaties verkennen en bestanden down-loaden.

• XML parser: Zorgt voor de correcte opbouw van te verzenden opdrachten of aanvragen enverwerkt de ontvangen antwoorden van de server. Deze structuur van XML voldoet aan hetWebDAV protocol, gespecifieerd in RFC 4918.

Deze componenten worden voorzien van de mogelijkheid om overweg te kunnen met het classifi-catiesysteem.


5.3.4 Opslag

Waar beveiligde communicatie zorgt voor encryptie bij data in transfer, moet er ook encryptie voordata at rest voorzien worden door de applicatie. Zoals beschreven in tabel 5.1 moet er voor be-paalde niveau’s encryptie voorzien worden wanneer bestanden op het externe geheugen opgesla-gen worden.

De omgang met bestanden wordt voorgesteld in onderstaande 3 mogelijke scenario’s:

1. Het bestand wordt gedownload en geencrypteerd opgeslagen binnenin de App Container.

2. Het bestand wordt gedecrypteerd en geopend door een externe applicatie.

3. Het bestand wordt door de gebruiker op de SD kaart opgeslagen voor later gebruik.

Scenario 1 en 2 worden altijd toegepast, bij scenario 3 worden bestanden geencrypteerd opgesla-gen op de SD kaart vanaf het niveau CONFIDENTIAL.

Het externe geheugen wordt in Windows Phone 8.1 niet standaard geencrypteerd. Het gebruikvan de Data Protection API zorgt wel dat de bestanden versleuteld worden opgeslagen, maaraangezien deze gebruikersafhankelijk is en alle applicaties onder dezelfde gebruiker draaien (zie4.3), moet er nagedacht worden over een andere oplossing.

Een mogelijke werkwijze is het gebruiken van een paswoord. De gebruiker kan dan een paswoordinstellen waarmee een symmetrische sleutel afgeleid wordt die op zijn beurt de bestanden encryp-teert. Het paswoord moet lang genoeg zijn en de gebruiker moet het bij elke encryptie of decryptieinvoeren. Dit komt de gebruiksvriendelijkheid niet ten goede.

Een andere oplossing is het voorzien van een sandbox-effect op het externe geheugen en hetversleutelen van bestanden volledig transparant maken voor de gebruiker. Hoe dit sandbox-effectgerealiseerd wordt, is beschreven in Hoofdstuk 5.

5.4 Conclusie

Wanneer alle componenten samengevoegd worden, krijgen we een systeem dat voldoet aan devooropgestelde eisen. De server voorziet de bestandsoverdracht functionaliteit, client authenticatieen beschikt over een classificatiesysteem. De client speelt perfect in op de mogelijkheden vande server. Tussen beiden bevindt zich een communicatiekanaal dat confidentialiteit en integriteitverzekert.

We kunnen de volledige use case opbouwen en beschrijven aan de hand van de verschillendecomponenten: Client en server zetten een beveiligde verbinding op en authenticeren zich volgensde gepaste manier. De gebruiker kan nu bladeren door de bestanden op de server. Een bestanddownloaden kan gevolgd worden door het bestand te openen of op het extern geheugen op teslaan voor later gebruik. De gebruiker kan nu terug de server verkennen en een ander bestanddownloaden of hij kan zich afmelden. Een bestand dat opgeslagen is op het extern geheugen kanmet behulp van de applicatie worden opgevraagd en geopend.

Hoofdstuk 6

Realisatie van de toepassing

6.1 Inleiding

Om het ontwerp om te zetten in de praktijk worden verschillende mechanismes gebruikt die Micro-soft aanbiedt in de standaard aanwezige API’s. Voor bepaalde componenten zoals WebDAV moetde ontwikkelaar zelf een API voorzien. In dit hoofdstuk komen de implementaties op de server ende client aan bod. De server vereist vooral configuratie van bestaande modules. De nadruk wordtop de clientside gelegd: hoe elke component verwezenlijkt wordt en welke API’s aangesprokenworden. Ten slotte wordt een korte uitleg gegeven hoe omgegaan kan worden met Virtual smartcards.

6.2 Serverside

6.2.1 Algemeen

Het besturingssysteem van de server is Ubuntu 14.04 en de webserver functionaliteit wordt mo-gelijk gemaakt door Apache versie 2.4.7. De combinatie van een Linuxdistributie en Apache biedtde developer veel flexibiliteit en documentatie. We nemen aan dat de server zich bevindt in eenbeveiligd netwerk en een vertrouwde omgeving.

6.2.2 Communicatie

Er wordt enkel en alleen gewerkt met een beveiligde verbinding. Apache is zodanig geconfigureerddat de webserver enkel te bereiken is op poort 443 en de SSLEngine vereist SSL met server-authenticatie. Met behulp van PKI wordt er een hierarchisch geheel gevormd. Client en servermoeten zich bij elkaar kunnen authenticeren en moeten over certificaten beschikken die getekendzijn door een Certificate Authority binnen of buiten het bedrijf. De opstelling beschikt over 1 rootCA die een Server CA en een Client CA onder zich heeft. Deze CA’s tekenen respectievelijk hetserver certificaat en het client certificaat. De PKI van de applicatie wordt weergegeven in figuur 6.1en werd gerealiseerd met OpenSSL.

De server beschikt nu over de juiste sleutels en certificaten om de SSLEngine van Apache teconfigureren: SSLCertificateFile is het certificaat van de server, SSLCertificateKeyFile stelt deprivate sleutel van de server voor.

36


Figuur 6.1: Overzicht van de PKI van de opstelling

6.2.3 Authenticatie

Server authenticatie wordt verzorgd door de SSLEngine van Apache en de PKI. De client hoeftenkel het root CA certificaat te vertrouwen (zie 6.3.2) om de server correct te kunnen authenticeren.

6.2.4 Policy voorzieningen

De verschillende classificaties zorgen voor een uitgebreide configuratie van Apache. Het in real-time veranderen van niveau en controleren of gebruikers geauthenticeerd zijn per bestand zou deideale sitatie zijn. Het gerealiseerd vereenvoudigd model voert authenticatie uit op map-niveau. Opde server bevinden zich 4 mappen met bestanden in:

• /webdav/public

• /webdav/confidential

• /webdav/secret

• /webdav/topsecret

Voor elk van deze mappen worden in Apache andere authenticatiemethodes ingesteld. De SS-LEngine en het type authenticatie kan per locatie aangepast worden. Voor het aanmelden metgebruikersnaam/paswoord wordt geopteerd voor Authentication Digest : paswoorden worden ge-hashed opgeslagen in een paswoordbestand. Om ervoor te zorgen dat de credentials van gebrui-kers die behoren tot het niveau CONFIDENTIAL niet dezelfde zijn als het niveau SECRET, werdeen verschillend realm (een gebied/locatie/groep waarin de credentials van toepassing zijn) inge-steld. Toestelauthenticatie wordt afgehandeld door de SSLEngine die client authenticatie vereist(SSLVerifyClient require) op het niveau van SECRET en TOP SECRET. Deze instellingen wordt inhet configuratiebestand van Apache opgeslagen.


6.2.5 WebDAV

Apache mag dan wel verschillende authenticatiemogelijkheden voorzien en SSL opzetten, de web-server moet in staat zijn om aan bestandsoverdracht te doen via het WebDAV protocol. Om ditmogelijk te maken werd de DAV module voor Apache geınstalleerd en geactiveerd voor de 4 map-pen. WebDAV en het authenticatiesysteem werken samen op niveau van locaties.

6.3 Clientside

6.3.1 Algemeen

De clientapplicatie is ontworpen voor een Windows Phone 8.1 toestel. De applicatie bestaat uitverschillende pagina’s die elk hun specifieke functionaliteit implementeren. Al deze pagina’s kun-nen de gebruikte WebDAV library aanspreken wanneer nodig. Er werd een zeer eenvoudige userinterface gekozen en een install-and-go policy voorzien. Wanneer de applicatie opgestart wordt,kan de gebruiker kiezen tussen 4 modules:

• New Server: Verbinding maken met een (nieuwe) server.

• Choose Server: Verbinding maken met een opgeslagen server.

• Certificate Manager: Het toevoegen van client-certificaten met behulp van een Virtual smartcard of door deze te importeren vanuit het externe geheugen.

• Open saved file: De gebruiker kan een op het externe geheugen opgeslagen bestand selec-teren. Dit wordt gedecrypteerd en geopend door de geassocieerde applicatie.

Figuur 6.2: Het startscherm van de client applicatie.

Na de pagina’s New Server (en login gegevens verstrekt te hebben) en Choose Server komt degebruiker terecht in de Verkenner. Deze laat de gebruiker toe om te browsen in de bestandenen mappen op de server. Bij het aanklikken van een bestand, wordt er naar de Transfer-paginagenavigeerd, waar het bestand gedownload wordt. Vanaf dan kan het bestand geopend worden enopgeslagen worden op het externe geheugen of SD-kaart. Vervolgens kan de gebruiker terugkerennaar de Verkenner of zich afmelden.


Figuur 6.3: De loginpagina van de client applicatie.

Figuur 6.4: De verkenner van de client applicatie.

6.3.2 Communicatie

Tussen client en server zal een HTTPS-verbinding opgezet worden. De server moet hiervoor voor-zien zijn van het geldige certificaat, getekend door de Server CA. In het geval van een self-signedcertificate of het gebruik van een niet erkende CA, moet de client geconfigureerd worden zodat hetom een vertrouwd certificaat gaat. Om dit te verwezelijken is er een beduidend verschil in Micro-soft Visual Studio tussen een Windows Phone 8.1 project en een Universal (Desktop applicatie)8.1 project.

Bij een Universal app kan in Package.appxmanifest de declaration ”Certificates” toegevoegd wor-den. De ontwikkelaar selecteert het Root CA certificaat en het systeem zal de nodige acties on-dernemen om het toe te voegen aan de Trusted Root Certification Store van de applicatie. 1

Om dit mogelijk te maken bij een Windows Phone 8.1 project, komt er wat complexiteit bij kijken. Inhet Package.appxmanifest is er immers geen mogelijkheid voorzien om te vertrouwen certificatentoe te voegen. Ten eerste moet het certificaat toegevoegd worden aan het project en de Build

1Dus niet de Trusted Root certification store van Current User of Local Computer.


Action moet ingesteld zijn op ”Content”. Vervolgens moet een stuk programmeerwerk het certificaatinladen en uitlezen. Dit gebeurt best bij het opstarten van de applicatie of alvorens de eersteHTTPS verbinding opgezet wordt. In dit geval wordt het certificaat toegevoegd bij het opstartenvan de applicatie. Er wordt geen foutmelding gegeven wanneer het certificaat meerdere kerentoegevoegd wordt, maar het wordt slechts eenmaal bewaard.

Eenmaal het root CA certificaat geınstalleerd is, kan een HTTPS aanvraag verstuurd worden metde Windows.Web.Http.HttpClient klasse. Het servercertificaat zal goedgekeurd worden en de SSLverbinding wordt opgezet. Wanneer er gewerkt wordt op het niveau van Sockets (zoals bij FTPhet geval zou zijn), moet het certificaat op dezelfde manier toegevoegd worden aan de appli-catie. Het opzetten van een SSL verbinding gebeurt dan met de klasse StreamSocket in Win-dows.Networking.Sockets.

6.3.3 Authenticatie

De manier van authenticeren hangt af van de classificatie. Serverauthenticatie is een vereistein alle gevallen en wordt uitgevoerd tijdens het opzetten van een HTTPS verbinding. Bij de Loginpagina kan de gebruiker de gewenste classificatie selecteren en zich, indien gevraagd, aanmelden.

PUBLIC: geen authenticatie vereist

De gebruiker moet enkel het serveradres opgeven. Daarna wordt een WebDAV client geınitialiseerdzonder login-gegevens en vereist de server geen SSL client authenticatie. De gebruiker kan inlog-gen en de publieke map verkennen.

COMPANY: Gebruikersnaam/paswoord

De gebruiker moet enkel gebruikersnaam en paswoord ingeven. De classificatie COMPANY laattoe om de server met de bijhorende credentials op te slaan. Het serveradres komt terecht in deLocalSettings van de applicatie. Het bijhorende wachtwoord en de gebruikersnaam worden in dePasswordVault (CredentialLocker) 2 geplaatst. Bij de volgende aanmelding kan de gebruiker zichdus aanmelden op de server via de pagina Choose Server zonder zijn gegevens opnieuw in tevoeren.

SECRET: Device authentication

De client moet beschikken over een private sleutel en een bijhorend certificaat om zich te kunnenauthenticeren bij de server. De server vertrouwt het client certificaat omdat het getekend is door declient CA en de root CA. Hoe de client kan voorzien worden van een private sleutel, getekend engecontroleerd door de CA, werd in voorgaand hoofdstuk besproken. De meest aangewezen manieris door gebruik te maken van een CA en een Virtual smart card. Deze laatste mogelijkheid werdin deze thesis onderzocht, maar is helaas niet haalbaar om te realiseren in de demo-opstelling omvolgende redenen:

• Er is geen echte CA server voorzien, de certificaten zijn op voorhand gegenereerd en zijnself-signed.

2Namespace: Windows.Security.Credentials.PasswordVault


• Het implementeren van een controlesysteem op basis van email, sms of eID is een onder-zoekswerk op zich.

In deze demo-opstelling wordt het clientcertificaat op voorhand gegenereerd en getekend door declient CA. De PKCS #12 Key Store, voorzien van een sterk wachtwoord, wordt op het externegeheugen van het toestel gezet. Wanneer de gebruiker zich wil authenticeren met de server, kanhet bestand ingeladen worden met de Certificate Mananger. Het certificaat wordt dan geımporteerden toegevoegd aan de App Container met de CertificateEnrollmentManager3. Dit is een eenmaligeactie en kan daarom gebruikt worden in demonstratiedoeleinden. Het certificaat bevindt zich nu inde Certificate Store van het toestel en mag verwijderd worden van het externe geheugen.

TOP SECRET: Device- en userauthentication

De classificatie TOP SECRET eist zowel gebruiker- als toestelauthenticatie. Dit is een combinatievan beide, eerder reeds beschreven mechanismen.

6.3.4 WebDAV

De WebDAV library waar de applicatie gebruik van maakt, is een port van een bestaande thirdparty libary, geschreven in C# en nog steeds in opbouw 4. De aanpassingen zorgen ervoor datde library compatibel is met WinRT; de runtime die Windows Phone 8.1 gebruikt. Zo werd bijvoor-beeld de klasse HttpUtility uit System.Web vervangen door de WebUtility klasse in System.Net. Defunctionaliteit van de library is voorlopig beperkt tot bestanden opvragen, downloaden, uploaden,verwijderen en mappen aanmaken. Ze is wel stabiel en gestructureerd opgebouwd wat uitbreidin-gen mogelijk maken. De aanwezige XML-parser werkt naar behoren conform de standaard RFC4918.

6.3.5 Omgang met bestanden

Hoe de applicatie omgaat met de gedownloade bestanden, wordt besproken aan de hand van ver-schillende scenario’s. De werking van bepaalde mechanismes wordt verduidelijkt aan de hand vanfiguren. We bekijken de levenscyclus van een bestand en de gebruikte technologieen in onder-staande 3 mogelijke scenario’s:

1. Het bestand wordt gedownload en geencrypteerd opgeslagen in de Temporary folder bin-nenin de App Container.

2. Het bestand wordt gedecrypteerd en geopend door een externe applicatie.

3. Het bestand wordt door de gebruiker op de SD kaart opgeslagen voor later gebruik.

Scenario 1

HET BESTAND WORDT GEDOWNLOAD EN GEENCRYPTEERD OPGESLAGEN IN DE TEM-PORARY FOLDER IN DE ISOLATED STORAGE.

3Namespace: Windows.Security.Cryptography.Certificates4https://github.com/saguiitay/WebDAVClient


Het bestand wordt via een beveiligde verbinding naar de client gestuurd. De inkomende streamwordt meteen geencrypteerd met de Data Protection API (zie 4.4) en weggeschreven naar eenbestand in de isolated storage (zie 4.3).

Aangezien de Local folder geback-upt wordt en de roaming folder gedeeld wordt met andere toe-stellen, wat in deze opstelling niet nodig is, worden bestanden opgeslagen in de temporary folder.Omdat het besturingssysteem deze map ook af en toe verwijdert, is dit de meest veilige locatie ombestanden in op te slaan. De bestanden zijn immers ook tijdelijk, dus het gebruik van de temporaryfolder is hier volledig verantwoord. Figuur 6.5 verduidelijkt dit proces.

Figuur 6.5: Het gedownloade bestand wordt opgeslagen in de isolated storage.

Scenario 2

HET BESTAND WORDT GEDECRYPTEERD EN GEOPEND DOOR EEN EXTERNE APPLICA-TIE.Wanneer de gebruiker het gedownloade bestand wilt openen, moet het eerst gedecrypteerd wor-den. Dit gebeurt eveneens met de Data Protection API. Er wordt een gedecrypteerde kopie van hetbestand opgeslagen op dezelfde locatie: de temporary folder. Hierna wordt het bestand geopendmet de bijhorende applicatie door gebruik te maken van een Protocol Handler (zie 4.5). Het openenvan het bestand wordt gevisualiseerd in figuur 6.6.

Aangezien het in Windows Phone onmogelijk is om te detecteren of de opgeroepen applicatiegesloten is of het bestand niet meer in gebruik is, blijft het onversleuteld bestand op het toestelstaan tot de besturingssysteem de Temporary folder leegmaakt of tot als de gebruiker zich afmeldt.

Scenario 3

HET BESTAND WORDT DOOR DE GEBRUIKER OPGESLAGEN OP HET EXTERNE GEHEU-GEN. De applicatie voorziet de mogelijkheid voor de gebruiker om bestand op te slaan op hetexterne geheugen. Op die manier moeten veelgebruikte bestanden niet telkens opnieuw gedown-load worden.

Ook de manier van opslaan is afhankelijk van de classificatie (zie tabel 5.1). Voor bestandendie behoren tot PUBLIC is er geen encryptie nodig wanneer een bestand opgeslagen wordt ophet externe geheugen; voor de classificatie’s CONFIDENTIAL, SECRET TOP SECRET wel. Omhet externe geheugen toegankelijk te maken voor de applicatie, moet deze capability geactiveerdworden. We bespreken dit scenario in de veronderstelling dat de gebruiker geklassificeerd is alsCONFIDENTIAL of hoger.


Figuur 6.6: Het bestand wordt geopend door een externe applicatie.

Het externe geheugen wordt in Windows Phone 8.1 niet standaard geencrypteerd. Het gebruikvan de Data Protection API zorgt wel dat de bestanden versleuteld worden opgeslagen, maaraangezien deze gebruikersafhankelijk is en alle applicaties onder dezelfde gebruiker draaien (zie4.3), werd er geopteerd om een sandbox-effect op het externe geheugen te realiseren.

De applicatie beschikt op het interne geheugen over een isolated storage. Daar kan een symme-trische sleutel worden in opgeslagen. Deze wordt geencrypteerd met de Data Protection API, netzoals de gedownloade bestanden. De sleutel kan dus niet benaderd worden door andere appli-caties en wordt niet in plain text opgeslagen. De enige bedenking die gemaakt kan worden is inwelke map hij opgeslagen wordt: Local, Temporary of Roaming. Aangezien de Temporary mapregelmatig gewist wordt door het OS, is dit geen optie. De sleutel is geencrypteerd met een toestel-(en gebruiker-) afhankelijke technologie, dus is niet te gebruiken buiten het toestel. Het backuppenof het delen met een ander toestel heeft dus geen nut, maar een van beiden moet wel gekozenworden. In dit geval werd geopteerd voor de Local folder. De gebruikte versleuteltechnologie isAES met een sleutellengte van 128 bit. Wanneer voor het eerst een bestand geencrypteerd wordt,zal de symmetrische sleutel aangemaakt worden en opgeslagen worden op het toestel. Bij de vol-gende encrypties en decrypties zal dezelfde sleutel gebruikt worden. Figuur 6.7 verduidelijkt dezeoplossing. Het versleutelen van bestanden is dus volledig transparant voor de gebruiker.

De gebruiker kan via de applicatie het bestand op het externe geheugen opvragen, decrypteren enopenen. Het gedecrypteerde bestand komt dan in de isolated storage van de applicatie, meerbe-paald in de Temporary folder.

6.4 Virtual smart cards

Omdat we niet beschikken over een echt CA server, kon er geen gebruik gemaakt worden vanVirtual smart cards. Niettemin hebben VSC’s een meerwaarde op vlak van information security.Ze zorgen ervoor dat een private sleutel gegenereerd wordt en nooit geexporteerd zal worden. Zezijn gebruiksvriendelijk en kunnen zeer gemakkelijk beheerd worden door een bedrijf (in geval het


Figuur 6.7: Het bestand wordt versleuteld opgeslagen op het externe geheugen.

toestel ook beheerd wordt door de firma). Er is daarom toch een poging ondernomen om virtualsmart cards te implementeren in de demo.

Om VSC’s te gebruiken, moet ook deze capability geactiveerd worden in het App manifest. Hetaanmaken van een VSC is mogelijk gemaakt en zal hieronder beschreven staan. Het gebruikenvan de kaart kan enkel als er een certificaat op geınstalleerd is, wat in deze demo niet het geval is.

Om een VSC aan te maken, moet er eerst een AdminKey aangemaakt worden. Deze sleutel is 24bytes lang en wordt in dit geval pseudo random gegenereerd met behulp van een secure randomgenerator. Vervolgens kan een PIN policy aangemaakt worden. Hier kunnen vereisten ingesteldworden die zich richten tot de keuze van de PIN code van de VSC. Hier kan onder andere de lengte,het gebruik van hoofdletters, cijfers en symbolen worden ingesteld. Een VSC wordt gekenmerktmet een Globally Unique Identifier (GUID), hiermee kunnen VSC opgeroepen worden door deapplicatie. Het is belangrijk dat de GUID goed bewaard wordt door de applicatie.

Op basis van deze 3 elementen (adminKey, Pin policy en GUID) kan een Virtual smart card aange-maakt worden door de SmartCardProvisioning. Wanneer een VSC aangemaakt word, is deze ookmeteen provisioned en kan er meteen een sleutelpaar en een certificaterequest op gegenereerdworden.

6.5 Conclusie

We kunnen besluiten dat er een werkende applicatie opgeleverd is. De communicatiecomponentlangs server en clientside zet een veilige verbinding op. Het WebDAV protocol zorgt ervoor datde bestanden op de server gedownload kunnen worden. Een vereenvoudigde vorm van het clas-sificatiesysteem werd geımplemteerd, maar voldoet wel aan de securityeisen die gesteld werden.Zo zorgt de authenticatiecomponent voor de verschillende types authenticatie. Het encrypteren enopslaan van bestanden op het externe geheugen van de client werd eveneens gerealiseerd. Dezecomponenten zijn niet letterlijk de verschillende klassen in de applicatie, maar worden stuk voorstuk in de verschillende pagina’s geımplementeerd.


In het volgende hoofdstuk wordt de realisatie geevalueerd. De applicatie wordt onderworpen aanenkele aanvalsmodellen. Ook performantietesten en een evaluatie naar gebruikersvriendelijkheiden uitbreidbaarheid komen aan bod.

Hoofdstuk 7

Evaluatie van de toepassing

7.1 Inleiding

In dit hoofdstuk wordt de gehele applicatie geevalueerd en getest. Er wordt nagegaan of ze vol-doet aan de eisen, opgesteld in Hoofstuk 2. We kunnen de evaluatie opdelen in verschillendeonderdelen:

• Functionaliteit: Er wordt nagegaan of de applicatie over voldoende functionaliteit beschikt enof er nood en/of ruimte is voor uitbreiding of verbetering.

• Gebruiksvriendelijkheid en performantie: We evalueren de gebruikservaring met de applica-tie vanaf het eerste contact. Performantietesten ondersteunen deze resultaten.

• Security: De applicatie wordt onderworpen aan verschillende aanvalsmodellen.

– Een aanvaller kan het netwerk verkeer afluisteren en aanpassen.

– Een aanvaller heeft het toestel in zijn fysieke vorm in bezit.

– Er bevindt zich actieve malware op het toestel.

• Andere applicaties en andere besturingssystemen: De applicatie wordt vergeleken met be-staande applicaties voor Windows Phone, Android en iOS.

Vervolgens wordt er verder ingegaan op de mogelijke verbeteringen en uitbreidingen van de appli-catie. Dit hoofdstuk eindigt met een concreet en kritisch besluit.

7.2 Functionaliteit

De functionaliteit van de applicatie is minimaal, maar voldoet wel aan de vooropgestelde eisen.De gebruiker kan bestanden op een server raadplegen vanop een Windows Phone toestel. Dezebestanden kunnen geopend worden en opgeslagen worden voor later gebruik.

Ook het classificatiesysteem werkt naar behoren, hoewel daar nog ruimte voor uitbreiding en ver-betering is. De niveau’s bevinden zich immers niet onder elkaar, maar naast elkaar. Een geau-thenticeerde gebruiker van een hoger niveau heeft geen toegang tot een lager niveau (tenzij diezich expliciet aanmeldt op dat lager niveau). Ook het navigeren naar een hoger niveau en zichauthenticeren wanneer nodig, is niet voorzien.

46


7.3 Gebruiksvriendelijkheid en performantie

7.3.1 Gebruiksvriendelijkheid

Gebruiksvriendelijkheid is het zo eenvoudig mogelijk aanbieden van noodzakelijke functionaliteitmet zo weinig mogelijk tussenkomst van de gebruiker. Gebruiksvriendelijkheid gaat soms ten kostevan veiligheid.

Het design van de applicatie is gebruiksvriendelijk genoeg voor demodoeleinden. Ze heeft eenduidelijke structuur en flow. De gebruiker ziet meteen wat hij moet en kan doen op elke pagina.

De gerealiseerde methode om bestanden geencrypteerd op te slaan op het extern geheugen vraagtgeen tussenkomst van de gebruiker. Dit bevordert de gebruiksvriendelijkheid: de gebruiker moetgeen paswoorden ingeven en onthouden.

Er is een install-and-go policy voorzien: De applicatie wordt geınstalleerd en de gebruiker kan zichmeteen aanmelden. Het enige wat moet gebeuren is een private sleutel genereren of toevoegenals de gebruiker zich in de classificatie SECRET of TOP SECRET bevindt. Er werden enkelemogelijke werkwijzen voorgesteld. De ene is gebruiksvriendelijker dan de andere, maar ook in hetopzicht van gebruiksvriendelijkheid krijgen de Virtual Smart Cards de voorkeur.

Het automatisch wissen van tijdelijke bestanden, moet deels handmatig gebeuren. Dit zorgt ervoordat de applicatie over een extra knop beschikt. Deze imperfectie gaat samen met een beveiligings-probleem, wat verder besproken wordt.

Servers kunnen opgeslagen worden samen met de aanmeldgegevens ervan. Op die manier moetde gebruiker niet altijd gebruikersnaam en paswoord ingeven. Er wordt wel verwacht dat de gebrui-ker zijn toestel beveiligt met een code.

7.3.2 Performantie

Het toestel waarop gewerkt werd is een Nokia Lumia 925. Dit toestel is ongeveer 2 jaar oud, maarwel een high-end toestel. Het beschikt over 1 GB RAM geheugen en een dual-core processor diegeklokt is op 1.5 Ghz.

De volgende stappen worden uitgevoerd terwijl het systeem de resources monitort.

1. Applicatie opstarten.

2. Aanmelden op de server en de lijst van bestanden opvragen.

3. Bestand selecteren en downloaden.

4. Het gedownloade bestand decrypteren met de Data Protection API en openen.

5. Het gedownloade bestand encrypteren met AES-128 en opslaan op het externe geheugen.

6. Tijdelijke bestanden wissen.

7. Filepicker openen en bestand op externe geheugen selecteren.

8. Bestand openen.

Tijdens de test werd een tekstbestand van 3 MB gedownload.


De blauwe grafiek (figuur 7.1) is totale CPU gebruik op het toestel, de oranje grafiek stelt hetCPU gebruik voor van de applicatie. De applicatie zelf gebruikt zeer weinig processortijd. Bij hetopstarten, aanmelden en opvragen van de bestanden verschijnen er enkele korte pieken met eenmaximum processortijd van 50%. Het encrypteren en decrypteren van het bestand gebeurt snel,maar vereist wel wat rekenkracht. Wat als traag kan beschouwd worden, is het openen van hetbestand met Office. We zien dat vanaf de 23ste seconde en vanaf de 65 seconde, het totale CPUgebruik de lucht in schiet. Ook het gebruik van de Filepicker vraagt eveneens rekenkracht van deCPU. We kunnen hieruit besluiten dat beveiligingsmechanismen een duidelijke invloed hebben ophet totale CPU gebruik, maar aangezien deze pieken van zeer korte duur zijn, merkt de gebruikergeen vertraging. Wanneer het bestand groter is, zullen de pieken iets meer uitgestrekt worden.Wat eveneens opvalt is dat de Data Protection API meer rekenkracht nodig heeft dan de AES-128encryptie. Het RAM-geheugen (figuur 7.2) blijft stabiel; de applicatie (gele grafiek) gebruikt nooit

Figuur 7.1: CPU performantietest (zie bijlage A voor grotere versie)

meer dan 50 MB. Bij het downloaden van een groter bestand, zal dit vanzelfsprekend ook stijgen.Het hoogtepunt wordt bereikt wanneer het bestand geopend wordt.

7.4 Security

Een applicatie evalueren op vlak van beveiliging zal nooit een waterdicht resultaat opleveren. Erzullen altijd wel zwaktes gevonden worden die op het moment van evalueren niet bekend waren.Ook deze analyse zal daarom geen sluitend antwoord geven op de vraag of de applicatie veilig is.De analyse en evaluatie van de applicatie is volledig theoretisch uitgevoerd en opgebouwd. Er isgeen hacking uitgevoerd.

Om de applicatie op een realistische manier te kunnen evalueren, nemen we enkele veronderstel-lingen aan:


Figuur 7.2: RAM geheugen performantietest (zie bijlage A voor grotere versie)

• Het toestel is niet unlocked en bevat enkel originele software.

• Het bedrijfsnetwerk is beveiligd en biedt bescherming tegen aanvallen.

• Men gaat ervan uit dat de Trust in de PKI niet geschonden is.

• De server is altijd bereikbaar wanneer nodig.

• De gebruiker heeft een PIN-code ingesteld op het toestel, tenzij anders vermeld.

• Het toestel is vrij van malware, tenzij anders vermeld.

7.4.1 Aanvalsmodel 1

Het afluisteren van netwerkverkeer kan altijd onopgemerkt uitgevoerd worden, maar aangezien deapplicatie alleen maar SSL verbindingen toelaat, zal de aanvaller geen enkele leesbare informatiekunnen bemachtigen. Alle ontvangen en verzonden data is geencrypteerd. Wanneer de aanvallerde data in transit aanpast of opslaat en doorstuurt naar de ontvanger, spreken we over een man-in-the-middle aanval. Ook een aanval van zulke aard is in principe onmogelijk wanneer gebruikgemaakt wordt van SSL en PKI om een beveiligde verbindingen op te zetten.

Een onbeveiligde verbinding toelaten op het publieke niveau kan aanvallers aanzetten tot het opzet-ten van een vervalste kopie van de server. Wanneer de gebruiker zich dan aanmeldt op een hogerniveau tijdens het verkennen van bestanden, kunnen de aanmeldgegevens onderschept worden.

Omdat een SSL verbinding altijd vereist is, zal dit aanvalsmodel nooit succes hebben op de gerea-liseerde applicatie. Deze stelling geldt enkel als er Trust aanwezig is in het gehele certificatensys-teem.



Waneer een toestel verloren gaat of gestolen wordt kunnen kwaadwilligen buit maken van de per-soonlijke data zoals foto’s en e-mails. In vele gevallen is het dan zelfs mogelijk om zich voor te doenals de eigenaar van het toestel. In deze analyse gaan we ervan uit dat het toestel in de handenkomt van een kwaadwillige persoon die enkel geınteresseerd is in de bedrijfsgegevens die via deontwikkelde applicatie toegankelijk zijn. Er zijn verschillende scenario’s die zich kunnen voordoenwanneer het toestel in de handen van een aanvaller komt.

Private sleutel op SD kaart

In de demo opstelling wordt de private sleutel van de client ingeladen via de SD kaart van hettoestel. Dit is, zoals eerder besproken, in de praktijk geen goede werkwijze. Wanneer de keystoreniet verwijderd wordt na het importeren, kan de aanvaller de private sleutel achterhalen. De key-store is weliswaar beveiligd met een paswoord. Het gebruik van paswoorden is eigenlijk niet meerverantwoord wanneer de aanvaller oneindig veel keer kan en mag raden. Dit is het geval bij eenkeystore, waardoor de aanvaller een brute force aanval kan uitvoeren. Hoe langer en complexer hetpaswoord, hoe langer het zal duren alvorens de aanvaller de private sleutel bemachtigt. Een lang(minimaal 12 tekens) en complex (alfanumeriek, symbolen en hoofdletters) paswoord zal ervoorzorgen dat de aanvaller er jaren over doet om het te kraken.

De keystore verwijderen is niet genoeg. Het bestand moet overschreven worden om te garanderendat het niet meer gerecupereerd kan worden.

Bestanden in isolated storage

De bestanden worden tijdens het opslaan meteen geencrypteerd met de DPAPI. Wanneer de ge-bruiker ze wilt openen, worden ze gedecrypteerd en opgeslagen in plain text op het toestel. Eenexterne applicatie krijgt dan toegang tot dat bestand. Wanneer deze applicatie niet meer actief is,zou het bestand verwijderd moeten worden. Helaas biedt Microsoft Windows Phone geen moge-lijkheid hiertoe. Het bestand staat dus in plain text op de telefoon tot wanneer de gebruiker hetbestand wist of het besturingssysteem de tijdelijke bestanden opschoont. Wanneer de gebruikerdeze bestanden niet gewist heeft en de aanvaller een dump van de isolated storage kan maken,komen de onversleutelde bestanden in de handen van de aanvaller. De voorwaarden om isolatedstorage te kunnen dumpen zijn:

• De applicatie moet geınstalleerd zijn op het toestel.

• Het toestel mag niet beveiligd zijn met een PIN code of moet ontgrendeld zijn.

• De applicatie mag niet geınstalleerd zijn via de Windows Phone Store.

Wanneer een van deze voorwaarden niet voldaan is, kan er dus geen dump gemaakt worden vande isolated storage. We veronderstellen dat de gebruiker een PIN code heeft en de applicatiegeınstalleerd heeft via de Windows Phone Store.

Bestanden op SD kaart

De bestanden die de gebruiker heeft opgeslagen op het externe geheugen zijn geencrypteerdmet AES en een sleutellengte van 128 bit. Deze encryptietechniek biedt 3,4 � 1038 verschillende


combinaties. Het brute force kraken van een dergelijke sleutel duurt onmenselijk lang (grootteordevan 1038 jaren). De sleutel wordt opgeslagen op het toestel, geencrypteerd met de Data ProtectionAPI van Microsoft. In voorgaande sectie is besloten dat de isolated storage niet gedumpt kanworden. Daarbij is de sleutel nog eens beveiligd met de DPAPI. Het achterhalen van de sleutel isdus een nagenoeg onmogelijke opgave.

De applicatie gebruiken als aanvaller

Wanneer de aanvaller in bezit is van het toestel, zou hij de applicatie ook kunnen gebruiken. Ookhier kunnen zich verschillende scenario’s voordoen. Wanneer de gebruiker geen PIN code heeftingesteld op het toestel, kan de aanvaller de applicatie opstarten en aanmelden op het PUBLICniveau. Wanneer het toestel beschikt over een geldige private sleutel, kan de gebruiker aanmeldenop het SECRET niveau. Wanneer Virtual smart cards gebruikt worden om de private sleutels tegenereren en te gebruiken, zal de gebruiker een PIN code moeten ingeven. Dit heeft een impact opde gebruiksvriendelijkheid, maar lost dat beveiligingsprobleem op. Ook wanneer gebruikersnaamen paswoord opgeslagen worden in de applicatie, zal de aanvaller zich kunnen aanmelden op hetniveau CONFIDENTIAL. Voor de klasse TOP SECRET wordt het opslaan van gebruikersnaam enpaswoord niet toegestaan.

Aangezien het aantal pogingen om aan te melden op de server ook niet gelimiteerd is, zal deaanvaller oneindig veel pogingen kunnen ondernemen om de gebruikersnaam en paswoord teraden.

De gebruiker moet een PIN code gebruiken. Wanneer het toestel vergrendeld is, zal de aanvallerhet toestel niet zomaar kunnen gebruiken. Het foutief intypen van een PIN code, triggert eenvertragingselement en het toestel wordt geblokkeerd.

Het toestel is unlocked/gejailbreaked

Wanneer het toestel unlocked is, wat slechts bij bepaalde toestellen mogelijk is, kan het internegeheugen volledig uitgelezen worden. Op dat moment verliest men alle vormen van beveiliging.De sandbox stelt niets meer voor en alle bestanden kunnen uitgelezen worden. Bij een offlineattack zal de aanvaller nog moeite ondervinden met bestanden die beveiligd zijn met de DPAPI,maar wanneer de tijdelijke bestanden niet gewist zijn, zullen er zich nog onbeveiligde bestandenop het geheugen bevinden.


Door de strenge controle van Microsoft om applicaties toe te laten in de Windows Phone Store isde kans op malware zeer klein. Toch gaan we dieper in op de zwaktes van de applicatie waarvanmisbruik kan gemaakt worden door malware.

Wanneer opdracht gegeven wordt om een bestand te openen, wordt de geassocieerde applicatieopgestart en krijgt deze leesrechten tot het bestand in de sandbox van de opdrachtgever. Wanneerdeze geassocieerde applicatie geen legitieme applicatie is en zich voordoet als een eenvoudigepdf-reader of tekstverwerker, krijgt die toegang tot de inhoud van het bestand. De inhoud kopierennaar een externe server is geen moeilijke opgave. Een oplossing voor dit probleem is het gebruikvan een in-app viewer. Wanneer bijvoorbeeld enkel PDF documenten gedownload worden, kan de


ontwikkelaar een PDF-reader voorzien die ingebouwd zit in de bestandsbeheersapplicatie. Op diemanier wordt er geen gebruik gemaakt van externe applicaties om de bestanden te lezen.

Malware die toetsaanslagen registreert kan de gebruikersnaam en het bijhorend paswoord stelenwanneer een gebruiker zich aanmeldt op de server.

Malware die de SD kaart uitleest, zal geen toegang verkrijgen tot de inhoud van de bestandenzonder de symmetrische sleutel te bezitten.

De kans op malware is immers zeer klein, wat de beste bescherming is voor dit aanvalsmodel.De gebruiker wordt aangeraden om zeer alert om te gaan met het installeren en gebruiken vanapplicaties.

7.5 Vergelijking met andere applicaties

In het landschap van File managers die protocollen zoals WebDAV en FTP ondersteunen is opzoek gegaan naar soortgelijke applicaties. Ze werden vergeleken op vlak van functionaliteit enbeveiliging. Bij vele applicatie’s werden verschillende beveiligingsspecificaties echter niet vermeld.Eerst werd een vergelijking gemaakt tussen Windows Phone applicaties; vervolgens werden ookapplicaties voor Android en iOS vergeleken.

7.5.1 Vergelijking met andere Windows Phone applicaties

In tabel 7.1 vindt u een overzicht van de vergelijking. Wat meteen opvalt is dat er nergens gebruikgemaakt wordt van strong authentication, of het althans niet vermeld wordt. Sommige applicatiesondersteunen encryptie van bestanden, maar met tussenkomst van de gebruiker. Slechts 1 appli-catie maakt gebruik van de Data Protection API. Ook build-in document viewers staan in WindowsPhone duidelijk nog in de kinderschoenen. De eigen gerealiseerde applicatie heeft op vlak vanbeveiliging een grote voorsprong op de andere Windows Phone applicaties. Qua functionaliteit iser nog ruimte en mogelijkheid tot uitbreiding.

7.5.2 Vergelijking met Android en iOS applicaties

In de Play Store van Google en de App Store van Apple leveren de zoektermen ’webdav’, ’ftp’,’secure file manager’, en ’filemanager’ een groot aantal resultaten op. In tabel 7.2 een vergelijkingmet 4 andere applicaties. Er zijn verbazingwekkend weinig applicaties die sterke beveiligings-maatregelen voorzien. De meeste applicaties voorzien SSL en encryptie van bestanden op deSD kaart/externe geheugen. Maar ook hier is er tussenkomst van de gebruiker en een paswoordnoodzakelijk. In dezelfde lijn met de applicaties voor Windows Phone, merken we op dat strongauthentication toch nog niet ingeburgerd is voor fileservers. Build-in document viewers komen dui-delijk vaker voor in Android en iOS dan in Windows Phone. Er zijn 2 applicaties die een groot aantalbestandsformaten ondersteunen. Ook hier moet er vermeld worden dat de functionaliteit van devergeleken applicaties veel uitgebreider is dan de eigen ontwikkelde applicatie.


7.6 Beperkingen en mogelijke uitbreidingen

In vergelijking met andere applicaties valt het op dat de applicatie een meerwaarde biedt op vlakvan beveiliging, maar ze tekort schiet op vlak van functionaliteit om op de markt te komen. Watnu bestandsoverdracht is, zou bestandsbeheer moeten worden. Het uploaden en beheren vanbestanden op de server kan een meerwaarde bieden. Er zou ook een onderscheid kunnen gemaaktworden tussen de classificatieniveau’s. Sommige niveau’s kunnen read-only zijn, in andere kunnende bestanden bewerkt worden. Dit geeft meteen de mogelijkheid tot een andere uitbreiding.

Het classificatiesysteem werkt nu op map-niveau en de gebruiker moet van bij het begin meteenhet niveau selecteren. De gebruiker zou de mogelijkheid kunnen hebben om zich te authenticerenwanneer nodig. Bestanden worden dan getagd en met gebruikersrechten en policies. Om dit terealiseren moet de webserver meer functionaliteit aanbieden. Er moet nagekeken worden of hetmogelijk is op dit met Apache te realiseren of er nood is aan een eigen creatie. Het implementerenvan een revocation service zou ook een pluspunt vormen. Wanneer een toestel gecompromiteerdof gestolen is, moeten de credentials van de gebruiker en het toestel ingetrokken worden zodat deaanvaller geen misbruik kan maken van de applicatie.

Op de client kan er naast extra functionaliteit met betrekking tot bestanden ook gezorgd wordenvoor een in-app document reader. Op die manier beperkt men de kans op ongewenste applicatiesdie gevoelige bestanden lezen. Het nadeel hiervan is, dat de applicatie dan slechts met een beperktaantal soorten bestanden overweg kan. Voor bestanden waarvoor geen in-app reader voorzienwordt, zal een externe applicatie opgeroepen worden.

Eveneens kunnen enkele knoppen weggewerkt worden in de client applicatie. Deze zijn er voorna-melijk geplaats voor demodoeleinden. Het downloaden van een bestand kan automatisch gevolgdworden door het openen ervan. Wanneer de gebruiker het bestand opslaat op de SD kaart, mogende tijdelijke bestanden in de local storage in principe gewist worden.

7.7 Conclusie

De ontwikkelde applicatie voldoet aan de basisfunctionaliteiten die geeist worden. Helaas merkenwe wel op dat die functionaliteit zeer beperkt is tegenover de applicaties die vandaag te verkrijgenzijn. Vele applicaties bieden verschillende protocollen (webDAV, FTP, SMB) aan en beschikkenover volledige bestandsbeheersmogelijkheden. Voor gebruiksvriendelijkheid scoort de applicatiezeker niet slecht. Er is enkel gebruikersinteractie wanneer nodig. De gebruiker moet zich geenzorgen maken over encryptie en geen paswoorden ingeven (uitgezonderd bij het aanmelden). Degebruiker krijgt eveneens de mogelijkheid om servers met hun credentials op te slaan.

De performantieresultaten zijn zeer positief en zorgen eveneens voor een goede gebruikerserva-ring. We kunnen dus besluiten dat de gebruikte beveiligingsmaatregelen bijna geen invloed hebbenop de performantie.

De ontwikkelde client applicatie beschikt over enkele unieke beveiligingsmechanismen die niet tevinden zijn in andere openbare applicaties. Zo werd een sterke en voor de gebruiker transpa-rante manier gevonden om bestanden veilig op te slaan op het onbeveiligde externe geheugen.Eveneens is client authenticatie op SSL niveau iets dat voor mobiele toestellen nagenoeg nietbeschikbaar is op de openbare markt.

Om de evaluatie af te sluiten, wordt naar tabel 7.3 verwezen. Aan alle voorwaarden is voldaan.Sommige voorwaarden zoals ’Afweren van malware aanvallen’ en ’Onmogelijk maken om vertrou-


welijke informatie van het toestel te halen door onbevoegden’ zijn nagenoeg onmogelijk te realise-ren. Men kan nooit zeker zijn dat de applicatie geen zwaktes meer bezit. Toch werd al het mogelijkegedaan om zo dicht mogelijk aan te leunen bij de ideale situatie.


Web

DA

VN

AV

Web

DA

VFi

leFi

leE

xplo

rer

File

soft

Con

nect

orS

ecur

eD

AV

clie

ntU

sern

ame/

pass

wor

dJa

JaJa

JaJa

JaS

tron

gau

then

ticat

ion

Nee

nN

ietv

erm

eld

Nie

tver

mel

dN

ietv

erm

eld

Nee

nJa

Enc

rypt

iein

tern

gehe

ugen

Nie

tvem

eld

Nie

tver

mel

dJa

aJa

ab

Nie

tver

mel

dJa

b

Enc

rypt

ieop

SD

kaar

tN

ietv

erm

eld

Nie

tver

mel

dJa

aJa

ab

Nie

tvem

eld

Jac

SS

LN

ietv

erm

eld

JaJa

Nie

tver

mel

dja

JaB

uild

-indo

cum

entv

iew

erN

een

Nee

nB

eper

ktd

Nee

nB

eper

kte

Nee

n

Tabe

l7.1

:Ve

rgel

ijkin

gm

etan

dere

Win

dow

sP

hone

appl

icat

ies

aA

dhv

een

opge

geve

npa

swoo

rdva

nde

gebr

uike

rbM

etD

PAP

Ic A

ES

128

dE

nkel

voor

muz

iek,

vide

oen

afbe

eldi

ngen

eE

nkel

voor

Offi

ce20

07be

stan

den


ES

File

Exp

lore

rFi

leM

anag

erFi

leE

xplo

rer

iSto

rage

App

Sec

ure

File

box

Eig

enap

pO

SA

ndro

idA

ndro

idiO

SiO

SW

P8.

1U

sern

ame/

pass

wor

dJa

JaJa

Nee

nJa

Str

ong

auth

entic

atio

nN

ietv

erm

eld

Nie

tver

mel

dN

ietv

erm

eld

Nee

nJa

Enc

rypt

ieva

nbe

stan

den

Nee

nJa

ab

Jac

Jaa

Jad

b

SS

LJa

JaJa

Nee

nJa

Bui

ld-in

docu

men

tvie

wer

Nee

nB

eper

kte

JaJa

Nee

n

Tabe

l7.2

:Ve

rgel

ijkin

gm

etap

plic

atie

svo

orA

ndro

iden

iOS

aA

ES

-256

bA

ES

-128

c Adh

vop

gege

ven

pasw

oord

van

gebr

uike

rdA

dhv

DPA

PI

eE

nkel

teks

tbes

tand

en,Z

IPen

med

ia


Onderdeel VoldaanClient

Functioneel zijn (bestandsoverdracht) XInstall-and-go policy hebben XUser en device authenticatie voorzien XVeilige verbinding opzetten met server XAfweren van malware aanvallen XOnmogelijk maken om vertrouwelijke informatie vanhet toestel te halen door onbevoegden.

X

ServerFunctionaliteit (fileserver) XBereikbaar wanneer nodig assumptieVoorzien van controlesystemen assumptieFysiek beveiligd assumptieVeilige verbinding opzetten met clients XVerschillende authenticatiemogelijkheden voorzien Xclassificatie niveau’s implementeren XEenvoudig toevoegen van extra authenticatiemogelijkheden, Xclassificaties, nieuwe gebruikers, bestanden en mappen X

CommunicatiekanaalConfidentialiteit XIntegriteit X

Tabel 7.3: Overzicht van de doelstellingen en of ze al dan niet bereikt zijn.

Hoofdstuk 8

Besluit

8.1 Overzicht

Deze thesis begon met een onderzoek naar information security om het project te kunnen situerenin het informaticalandschap. Vervolgens werd een scenario uitgewerkt dat de leidraad voorstelt vande volledige realisatie. Om een oplossing te vinden voor deze case study werd een grondige studiegemaakt van Windows Phone 8.x. Tijdens dit onderzoek werden bepaalde mechanismen kortvergeleken met de twee meest courante mobiele besturingssystemen van vandaag: Android eniOS. Als laatste werd onderzoek gedaan naar verschillende bestandsoverdracht protocollen: FTPen WebDAV. Om het ontwerp overzichtelijk en gestructureerd te maken, werden server en clientonderverdeeld in verschillende componenten. Elk onderdeel bezit verschillende eigenschappenen moet aan bepaalde voorwaarden voldoen. In deze fase werden enkele ontwerpbeslissingengenomen. Er werd gekozen voor WebDAV, uitsluitend HTTPS-verbindingen, het gebruik van PKI,het opslaan van bestanden op het externe geheugen, etc. De realisatie van de applicatie was eencombinatie van ontwikkelen en configureren. Op de server werd gebruik gemaakt van bestaandeplatformen en modules die geconfigureerd werden naar de noden van het ontwerp. De clientapplicatie werd vanaf nul ontwikkeld en maakt gebruik van een port van een bestaande WebDAVlibrary. Aan verschillende beveiligingseisen kon voldaan worden door gebruik te maken van doorWindows voorziene API’s. Voor andere eisen, zoals de veilige opslag op de SD kaart, moestde ontwikkelaar op zoek gaan naar een creatieve oplossing. De evaluatie van de gerealiseerdeoplossing sluit dit onderzoek naar information security in Windows Phone af.

Er werd een functionele bestandsoverdrachtsapplicatie gerealiseerd, gebruik makend van het Web-DAV protocol. Deze heeft volgende specificaties:

• Een classificatiesysteem met 4 niveau’s.

• Verschillende authenticatietechnieken: gebruikersnaam/paswoord en SSL mutual authenti-cation.

• Altijd een beveiligde verbinding.

• Veilige opslag van bestanden.

• Het openen van bestanden door externe applicaties.

58

8 Besluit 59

Tijdens de realisatie werden sommige toegevingen gedaan zoals het classificatiesysteem dat opniveau van mappen werkt en niet van bestanden. Er kan eventueel gewerkt worden met context-awareness. Hierbij kunnen verschillende factoren zoals locatie, tijd en omgeving een rol spelen[34]. Ook het wijzigen van niveau en de toegang tot lagere niveau’s zonder zich expliciet daarinte authenticeren is een toegeving. Deze toegevingen waren vooral te wijten aan de technischebarieres aan de serverside. Er is niet in geslaagd om dit mogelijk te maken met Apache.

Deze thesis geeft de geınteresseerde lezer een beeld van wat mogelijk is met een persoonlijkWindows Phone 8.1 toestel op vlak van beveiliging.

8.2 Conclusie

Windows Phone 8.1 is een besturingssysteem dat enerzijds nog in zijn kinderschoenen staat, maaranderzijds gebaseerd is op bestaande technologieen die voortkomen uit de desktopversies vanWindows. Microsoft gaf security naar eigen zeggen prioriteit tijdens de ontwikkeling van Windows(Phone) 8.1. En, hoewel ik geen ervaring heb met vorige versies van Windows Phone, kan ikzeggen dat een developer in staat is om een veilige applicatie te bouwen op het mobiele platformvan Microsoft. Er zijn voldoende API’s beschikbaar om veiligheidsmaatregelen te treffen in elkeapplicatie. Windows Phone is eveneens voorzien van veel ingebouwde mechanismes die misbruiken malware tegenhouden. De strenge controle op applicaties vooraleer die in de Windows PhoneStore komen, zorgt ervoor dat de kans op malware zeer klein is. Of Windows Phone een goedekeuze is voor een BYOD-toestel, is een andere vraag. Wanneer het toestel niet beheerd wordt dooreen bedrijf, is er geen file-system encryptie aanwezig en kan de gebruiker niet verplicht worden hettoestel te vergrendelen met een PIN code. Om als ontwikkelaar een oplossing te vinden voor dezetekortkomingen, moet er creatief uit de hoek gekomen worden. Een PIN code verplicht makenis immers niet mogelijk. Een code instellen op de applicatie zelf kan wel een mogelijkheid zijn,maar dit komt de gebruiksvriendelijkheid niet ten goede. Windows Phone is net zoals iOS eenzeer gesloten besturingssysteem. Als gebruiker en ontwikkelaar beschik je niet over de vrijheiddie Android biedt, maar dit maakt Windows Phone een veilig OS. Wat Windows Phone biedt enwaartegen deze technieken beschermen, wordt opgesomd in tabel 8.1.

Wat Techniek Beschermt tegen

CredentialsExclusive trust MITM aanvallenData Protection API Offline aanvallenVirtual Smart Cards Online en offline aanvallen

ApplicatiesTrusted Boot MalwareApp Container MalwarePin-code Niet-geautoriseerd gebruik

DataData Protecion API Offline aanvallenIndien managed: Bitlocker Offline aanvallenPin-code Online aanvallen

Tabel 8.1: Wat biedt Windows Phone.

De sterke punten van Windows Phone worden hieronder opgesomd.

• Zeer strenge controle in de Windows Phone Store; zeer kleine kans op malware.

8 Besluit 60

• Gesloten en strenge app isolation. De ontwikkelaar moet op voorhand de gaten (=declarati-ons en capabilities) in de sandbox opgeven.

• Veilige opslag van credentials en bestanden met behulp van de Data Protection API.

• Streng gecontroleerd opstartproces.

• De aanwezigheid van Exploit mitigation technologies.

• Virtual smart cards.

De zwakke punten, die tijdens dit onderzoek boven water zijn gekomen, zijn:

• Geen file system encryptie bij unmanaged toestel.

• Onveilige interprocess communication: de gebruiker wordt niet op de hoogte gebracht enmoet geen toestemming geven wanneer een externe applicatie opgestart moet worden. Deapplicatie die opgestart wordt, is niet meer te beheren door de opdrachtgevende applicatie:men kan niet detecteren wanneer ze terug afgesloten wordt.

• Virtual smart cards kunnen enkel gebruikt worden wanneer een CA server voorzien wordt.

• Er is geen mogelijkheid om als developer een PIN-code te eisen of na te gaan of er eeningesteld is om het toestel te ontgrendelen.

8.3 Verdere onderzoeksmogelijkheden

Deze thesis is een onderzoek naar de beveiligingsmogelijkheden van een onbeheerd WindowsPhone 8.x toestel. Het lijkt interessant om volgende onderwerpen nog bijkomend te onderzoeken:

• Virtual smart cards: Virtual Smart cards werden geıntroduceerd in WP 8.1. Deze biedeneen zeer uitgebreid gamma aan op vlak van beveiligingsmogelijkheden. In dit onderzoekwerd een introductie gegeven van VSC’s maar verder onderzoek is vereist om ze wel degelijkte gaan gebruiken.

• Context awareness: Het classificatiesysteem gebeurt momenteel op map-niveau. Er kanonderzoek gedaan worden naar de mogelijkheid om dit op bestandsniveau te doen. Hetbegrip context kan hier ook een meerwaarde betekenen.

• Managed devices: Ten slotte zou het interessant zijn om de mogelijkheden van een per-soonlijk toestel te vergelijken met een toestel dat beheerd wordt door het bedrijf. Wat MDMbiedt, welke policies gepushed kunnen worden en wat de meerwaarden zijn op vlak vanbeveiliging.

Bibliografie

[1] S. M. A. Whitechapel. Windows Phone 8 Development Internals. Pearson Education, preview1 edition, 2013.

[2] Addison-Wesley. Threats, The Honeynet Project. Know Your Enemy: Learning about Security.2 edition, 2004.

[3] M. Agrawal. NATION TECHNOLOGIES. 1(1043919):1–19, 2012.

[4] S. Andersen and V. Abella. Data execution prevention. changes to functionality in microsoftwindows xp service pack 2, part 3: Memory protection technologies, 2004.

[5] A. Baratloo, N. Singh, T. K. Tsai, et al. Transparent run-time defense against stack-smashingattacks. In USENIX Annual Technical Conference, General Track, pages 251–262, 2000.

[6] U. Cabinet Office. Government Security Classifications. Technical report, UK Cabinet Office,2014.

[7] D. Chell, T. Erasmus, J. Lindsay, S. Colley, and O. Whitehouse. The Mobile Application Hac-ker’s Handbook. John Wiley & Sons, 2015.

[8] G. S. Dardick. Cyber Forensics Assurance. 2010.

[9] Fortinet. Threat Landscape Report 2014, 2014.

[10] Gartner. Forecast: PCs, Ultramobiles, and Mobile Phones, Worldwide, 2011-2018, 2Q14Update. Technical report, 2014.

[11] Google. Verifying Boot — Android Developers, 2013.

[12] T. Immutable, L. Of, M. Security, I. Laws, and L. Law. Ten Immutable Laws Of Security (Version 2 . 0 ). 278941:0–3, 2014.

[13] IWS. NSA Information Assurance Frequently Asked Questions, 2010.

[14] L. R. Knudsen and G. Leander. Encyclopedia of Cryptography and Security. Springer, 2011.

[15] Microsoft. Windows Data Protection, 2001.

[16] Microsoft. DataProtectionProvider class - Windows app development, 2012.

[17] Microsoft. Een geschiedenis van Windows, 2013.

[18] Microsoft. Deploy Virtual Smart Cards, 2014.

61

BIBLIOGRAFIE 62

[19] Microsoft. Lesson 2 - Windows NT System Overview, 2014.

[20] Microsoft. Windows Phone 8.1 Security Overview. Technical Report April, 2014.

[21] Microsoft. Microsoft by the Numbers, 2015.

[22] Microsoft, Y. Goland, E. Whitehead, U. Irvine, A. Faizi, Netscape, S. Carter, Novell, D. Jensen,and Novell. RFC 2518: HTTP Extensions for Distributed Authoring – WEBDAV, 1999.

[23] B. Morrow. BYOD security challenges: control and protect your most sensitive data. NetworkSecurity, 2012(12):5–8, Dec. 2012.

[24] S. Muller. Windows Phone 8 . 1 – platform concepts and app development models. 2014.

[25] N. Mylle. Context-aware resource protection in ios, 2014.

[26] D. B. Parker. Fighting computer crime: A new framework for protecting information. Wiley NewYork, NY, 1998.

[27] F. Piessens. Developing Secure Software Applications. 2005.

[28] M. Rhodes-Ousley. The Complete Information Security Second Edition. The McGraw-HillCompanies, 2 edition, 2013.

[29] S. Sector and O. F. Itu. ITU-T. 2008.

[30] M. D. Soete. Two-Factor Authentication, 2011.

[31] H. Soni. Strong Authentication: Building Apps That Leverage Virtual Smart Cards in Enter-prise, BYOD, and Consumer Environments. 2013.

[32] G. Tel. Cryptografie - Beveiliging van de digitale maatschappij. Technical report, UniversiteitUtrecht, 2006.

[33] B. Tokuyoshi. The security implications of BYOD. Network Security, 2013(4):12–13, Apr.2013.

[34] Y.-K. Wang. Context awareness and adaptation in mobile learning. In Wireless and MobileTechnologies in Education, 2004. Proceedings. The 2nd IEEE International Workshop on,pages 154–158. IEEE, 2004.

[35] O. Whitehouse. An analysis of address space layout randomization on windows vista. Sy-mantec advanced threat research, pages 1–14, 2007.

Bijlage A

Performantietest

63


Figu

urA

.1:

CP

Upe

rform

antie

test


Figu

urA

.2:

RA

Mge

heug

enpe

rform

antie

test

Bijlage B

Beschrijving van deze masterproef in devorm van een wetenschappelijk artikel

66

11/05/2015

Data protection in Windows PhoneBram Gosseye1

AbstractToday’s ever growing amounts of confidential data and the increasing use of mobile devices are causing highersecurity risks. Several ongoing trends such as BYOD (Bring Your Own Device) are having an impact onorganisations’ ability to protect their sensitive data. The present dissertation presents research on data protectionfor the Windows Phone Platform. The study provides a comparison with other widely-used mobile operatingsystems such as Android and iOS. The focus lies on the app developer’s perspective, starting from existingsecurity building blocks. A thorough analysis sheds light on the security guarantees as well as on the remainingshortcomings while exploring how these can be resolved. A prototype of an enterprise application for mobile filemanagement demonstrates the workings of the security mechanisms. This proof of concept application is thenevaluated on criteria such as security, interoperability, performance and administrative features.

KeywordsSecurity — Mobile devices — Windows Phone —Data protection — Information security

1Master student Industrial Ingeneering ICT, KU Leuven

Contents

1 Introduction 1

2 Background Research 1

3 Realization of the application 3

4 Evaluation of the application 4

5 Conclusion 5

References 5

1. IntroductionBYOD (Bring Your Own Device) is an ongoing trend in manyenterprises. BYOD means that employees use their personallyowned device for work-related functions [1]. It is a typical ex-ample of the end node problem, occurring when sensitive datais accessed by an untrusted device. Therefore, it is possiblethat company owned information is stolen and accessed by anunauthorized person. When the device is infected by malware,information can get lost or stolen. According to Tokuyoshi,2013 the organisation has to provide the application and to beable to control the data after being downloaded by the mobileclient. This leads to research on how to protect sensitive dataon a personal mobile device.

Android and iOS are the two most popular mobile plat-forms. They have been studied and documented widely. How-ever, Microsoft’s mobile operating system, Windows Phone,is with a 14% market share the third most used platform [2].The use of the Windows Phone is increasing and since version8.1, Microsoft recommends developers to work with the re-cent WinRT (Windows Runtime) whose security features havenot been investigated previously. Some companies build theirown software, but not always do they have the expertise to

provide security features, especially when a newly designedoperating system is used.

By developing an enterprise application for mobile filemanagement, the functionality of the available security mech-anisms is demonstrated. These mechanisms are evaluatedagainst criteria such as security, interoperability, performanceand administrative features. In the second section, a back-ground research about the Windows Phone is given. Then, theapplication design is shown and the used security techniquesare explained. The application will be evaluated and a briefreport is included in section 4. Finally, after the conclusion ,some future research directions are suggested.

2. Background Research

2.1 IntroductionThe first version of Windows Phone, WP 7, was a member ofthe Windows-CE family. Since Windows Phone 8, the operat-ing system is based on the more stable Windows NT kernel.Windows 8.1, Windows Server 2012 R2 and Windows Phone8.1 belong to NT version 6.3 [3]. Microsoft recommends todevelop applications in the new Windows Runtime. WinRTincludes a lot of new API’s (e.g. Virtual Smart Cards) andmakes it possible to create cross-device applications [4].

When talking about security in mobile devices, the usedtechniques can be divided in 4 groups:

• App Distribution: To test and approve submitted appli-cations and make them available to the public by addingthem to the application store.

• Data and credential Protection: when, how and wherefiles and keys are stored.

Data protection in Windows Phone — 2/7

• App Isolation: The separation of the running applica-tions and their data. (Sandboxing)

• Mobile Device Management: A device can be managedby a company. The firm can push updates, policies andexecute a remote wipe when the device is stolen or lost.

This research is focused on personal devices, hence MDMdoes not apply here. We take a closer look to the securityfeatures Microsoft offers developers in Windows Phone.

2.2 App distributionMicrosoft analyses all the applications submitted to the Win-dows Phone Store. One line of malicious code, ensures thatthe application is refused. Not only the malicious code, butalso questionable or unwanted behaviour of the applicationcan lead the rejection. When an application tries to read afile outside its own sandbox, it will not likely be accepted. Inaddition to detecting malware, Microsoft also examines the se-curity of the application: Passwords may not be stored in plaintext and binary protection mechanisms to be present. The en-tire list of conditions and guide lines can be found on https://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx

Concluding, Microsoft has a very severe selection process.The Play Store from Google is a very open and Microsoftis even slightly tougher than Apple [5]. Table 1 shows acomparison between the Windows Phone Store, the AppleStore and the Google Play Store.

2.3 App isolationEach application runs in its own sandbox, called AppCon-tainer. An AppContainer is a process-isolation mechanismthat provides very fine-grained security policies. It limits theread/write capabilities of an application. The security policyis determined by the software developer and handled by theoperating system. By activating different capabilities (e.g.GPS, Camera, Certificates, Removable storage,. . . ), processeswithin the sandbox obtain access to the defined WindowsPhone resources.

According to Microsoft, the AppContainer offers follow-ing benefits [4]:

• Reduce attack possibilities. Applications only get ac-cess to the indicated capabilities.

• Users consent and control. The capabilities used by theapplication are stated in the details page in the WindowsPhone Store. When an application asks for sensitiveinformation such as location, the user is prompted togive permission.

• Isolation: Applications can only communicate witheach other through predefined communication tunnelsand data types.

The Windows Phone 8.x security model is based on theprinciple of least privilege. Applications obtain the minimum

capabilities to execute their legitimate tasks. Sandboxing isa well-used technique and applied in most mobile operatingsystems [5]. The Windows Phone sandbox model is similarin iOS: A sandbox is created when installing the application.Each application has its own home directory that is not acces-sible to other applications. In Android, sandboxing is realizedat the process level. Only processes with the same UniqueUser Identifier (UID) can access each others’ resources. Eachapp gets a different UID when booting. For certain resourcessuch as location the user must give global permission. Table 2gives a comparisation of Windows Phone, Android and iOS.

2.4 Data and credential protectionIt is very helpful for a developer to know how and what isencrypted in Windows Phone. When the device is stolen andan attacker tries to obtain data, it is important to know howconfidential files can be secured.

At the time of writing, file system encryption is not ac-tivated in Windows Phone. There is not even a public APIavailable for encryption on the file system level. However,in managed devices, a policy can activate encryption withBitLocker. According to Microsoft, BitLocker makes use ofAdvanced Encyption Standard (AES) in Chained Block Ci-pher (CBC) mode. BitLocker also uses the Trusted PlatformModule (TPM), so the encryption is hardware backed. On apersonal device, all stored data is unencrypted. Fortunately,the sandbox provides a form of isolation and files in the inter-nal memory cannot be accessed by malicious applications.

Of course, developers can use file encryption in their ownapplications. Windows provides a simple API to allow fileencryption. The Data Protection API (DPAPI) is available aswell in desktop versions of Windows as in Windows Phone.DPAPI utilizes a Master Key, which is encrypted with theMaster Key (MK) Encryption Key. The Master Key is usedto derive a symmetric key to encrypt the data. The DataProtection API creates a master key for each user. In WindowsPhone all applications run in the same user account, so allprotected data stored on the device is encrypted with the samekey. This causes weaknesses in the security: all applicationsdispose of this key and can decrypt all files [6].

User passwords can be stored in Windows Phone. Whenthe PasswordVault is used, passwords can be stored in adatabase. This database is protected with the DPAPI andis application specific: applications cannot retrieve passwordsfrom other applications.

iOS also has a similar Data Protection API, but offersmore possibilities (table 3). File system encryption is donefully automatically and hardware-backed in iOS. Android pro-vides no special API to quickly encrypt a file. The developerneeds to make use of the different cryptographic classes toencrypt a file. Since Android v 5.0, file system encryptionis automatically enabled in Android. When the device has aTPM, it’s also hardware-backed.


3. Realization of the application

The scenario consists of a mobile client, a personal device ofan employee, and a file server of a company. The employeeis able to download files from the server, open them and savethem on the external storage. A classification model is built:not all employees have access to all files. The level of securityand authentication is adjusted at each level. There are 4 levels:PUBLIC, CONFIDENTIAL, SECRET and TOP SECRET.

Server and client consist of several components. Theserver features a functional unit that provides the file transferprotocol and makes files accessible for the client. An authen-tication and policy component determines who gains accessto these files. On the client side, there is a similar structure.The additional storage component manages the files whendownloaded. The protocol which makes file transfer possibleis WebDAV. WebDAV is an HTTP extension, which makesis easy for the developer to create a secure connection. Thecommunication component on both sides provides an SSLsecured connection between client and server.

3.1 CommunicationThe use of a secure channel over HTTPS is enforced by serverand client. Server authentication is always required and isrealised with Public Key Infrastructure (PKI).

3.2 Authentication and policiesIn addition to server authentication, the client must also au-thenticate to the server. This procedure depends on the classi-fication the user want access to.

3.2.1 PUBLICThe PUBLIC level does not require client authentication. Any-one can access these files. This level can contain public infor-mation such as press releases, job postings, articles, etc.

3.2.2 CONFIDENTIALThe user can enter this level by username/password authenti-cation. This level contains sensitive information that can beaccessed by anyone with a correct username and password.The user can save his credentials in de application with thePasswordVault.

3.2.3 SECRETThis level requires device authentication or strong authenti-cation. This is done by client authentication during the SSLHandshake. The server can verify the clients’ certificate byusing the PKI.

3.2.4 TOP SECRETThe TOP SECRET classification requires both user- and de-vice authentication. This is a combination of the two, previ-ously described mechanisms.

Table 4 gives a summary of the different classificationlevels and their policies.

3.3 File transferThe WebDAV module in the client ensures that the user canlog in and download files. The retrieval of the properties of aresource is done with the PROPFIND command, downloadingfiles happens with the GET method. This module is onlyusing HTTPS traffic and consists of a connection component,a command component and an XML parser.

3.4 StorageWhere secure communication encrypts data in transfer, theapplication must provide encryption for data at rest. As de-scribed in table 2, for certain levels encryption is neededwhen files are saves to the external storage. Dealing files ispresented in the following 3 scenario’s.

• The downloaded file is protected with the DPAPI andstored inside the App Container.

• The file is decrypted an opened with an external appli-cation. A decrypted copy of the file is saved in the samelocation, thereafter the associated application starts andopens the file.

• The file is encrypted and stored on the removable stor-age for later use. The external storage is not encryptedin Windows Phone 8.1. The use of the DPAPI does pro-vide encryption, but since all applications are runningunder the same user, all applications can decrypt thesefiles. We realized another, user transparent and secureway to save files to the external storage. In the isolatedstorage of the application, an 128 bit encryption key isstored and protected with the DPAPI. This key is usedto encrypt the files, saved on the external memory bythe user. This application is the only one which canaccess the symmetric key and decrypt these files. Atfirst use, the symmetric key will be created and storedon the device. At the next encryption and decryption,the application will use the same key.


4. Evaluation of the applicationThe evaluation is divided into different parts:

• Functionality: determining whether the application hassufficient functionality and features.

• Usability and performance: the user experience will bereviewed; a performance test will support these result.

• Security: the application is subjected to different attackmodels.

• Other applications: the application will be compared toexisting applications.

4.1 FunctionalityThe functionality of the application is minimal, but does meetthe stated requirements. The user can access files on a serverfrom a Windows Phone device. These files can be openedwith an external application and stored for later use.

The classification system is working properly, althoughthere is still room for expansion and improvement.

4.2 UsabilityThe achieved method for saving encrypted files on the externalstorage requires no intervention by the user. This improvesthe usability: the user does not need to enter passwords. Aninstall-and-go policy is provided: When the application isinstalled, the user can log in immediately. Servers can besaved along with their credentials. In this way, the user doesnot always have to enter his username and password.

4.3 PerformanceThe security mechanism has a clear impact on the total CPUuse. However, the does not notice a striking delay. Thememory usage remains stable and is proportional to the sizeof the downloaded file.

4.4 SecurityThe analysis and evaluation of the application is only theo-retical, no hacking was performed. In order to evaluate theapplication realistically, some assumptions have been made:

• The phone is not unlocked and contains only genuinesoftware.

• The corporate network is protected against cyberat-tacks.

• The server is always available when needed.

• The user has a PIN code on the lockscreen of the device.

• The device is free from malware, unless otherwisestated.

An attacker can be an eavesdropper and adjust thenetwork traffic

Eavesdropping can always be performed unnoticed, butas the applications only allows SSL connections, the attackerwill be unable to retrieve readable information. All data intransit is encrypted. A man-in-the-middle attack will neversucceed, unless the PKI trust has been violated.

An attacker has unlimited physical access to the de-vice

Downloaded files are encrypted immediately with theDPAPI. When the user wants to open them, they are decryptedand stored in plain text. The attacker could dump the internalstorage and get access to the decrypted files. The conditionsfor dumping the isolated storage of an application are:

• The application must be installed on the device

• The phone is not protected with a PIN code and is notjailbroken/unlocked.

• The application may not be installed through the Win-dows Phone Store.

When one of these conditions is not met, no dump can bemade of the isolated storage. We assume that the user had aPIN code and the application is installed through the WindowsPhone Store.

The files, stored on the external storage, are encryptedwith AES-128. This encryption technique offers 3,4E38 dif-ferent combinations. The cracking such key takes more thana lifetime when using a powerful computer.

If the attacker has physical access to the device, he couldalso use the application. If the device is not locked with aPIN code, the attacker can launch the application and log onto the PUBLIC level. When the device has a valid privatekey installed, the user can log on to the SECRET level. Theuse of Virtual Smart Cards prevents this: the private key isprotected with a PIN code. If the username and the pass-word are stored in the application, the attacker will be able tolog on to the CONFIDENTIAL level. Storing username andpassword for the classification TOP SECRET is not permitted.

There is active malware on the deviceDue to the strict application vetting of Microsoft, the

probability of malware in the Windows Phone Store is verysmall. When the order is given to open a file, the associatedapplication is started and retrieves read access to the file in desandbox. When this associated application is not a genuineapplication but poses as a simple pdf-reader or word processor,it’s get access to the contents of the file. A solution for thisproblem is the use of an build-in document viewer.


4.5 Other applicationsIn table 5 a comparison between 4 other Windows Phoneapplications is given. Remarkably, no use is made of strongauthentication, whether it is at least not mentioned. Someapplications support file encryption, but user interaction isessential. Only a single application makes use of the DataProtection API. Also, build-in document viewers for WindowsPhone are at an early stage development. The realized appli-cation offers big advantages for security, but it lacks a bit offunctionality for daily use.

5. Conclusion5.1 GeneralPlenty of API’s are available to take safety measures in eachapplication. Windows Phone is also equipped with manybuilt-in mechanisms to prevent abuse and malware attacks.The strict application vetting guarantees that the probabilityof malware is very small. When a Windows Phone deviceis not managed by the company, file system encryption isnot available and the user can not be forced to use a PINcode. In order to find a solution for these shortcomings, thedeveloper must be creative. Windows Phone is, just like iOS,a very closed operating system. It does not offer the freedomAndroid offers, but this makes Windows Phone a secure OS.

Finally, the strengths of Windows Phone are listed below:

• Very strict app vetting

• Closed and strict application isolation

• Secure storage of credentials and files using the DataProtection API

• Strictly protected boot process

• The presence of exploit mitigation technologies.

• Virtual Smart Cards

The weaknesses identified during this research are:

• No file system encryption with unmanaged devices

• Unsafe interprocess communication: the user is not no-tified and should not give permission when an externalapplication is launched.

• Virtual smart cards can only be used when a (firm) CAserver is provided.

• It is not possible as developer to oblige the user to set aPIN code.

5.2 Further reasearchThis study handles the security capabilities of an unmanagedWindows Phone 8.x device. It seems interesting to investigatethe following topics:

• Virtual Smart cards: VCS’s were introduces in WP 8.1and offer a wide range of security features.

• Context awareness: the classification can be done atfile-level and expanded with context.

• Managed devices: It would be interesting to evaluatethe capabilities of a device, managed by the company.What MDM offers, which policies can be pushed andwhat the gains are for security.

References[1] Bill Morrow. BYOD security challenges: control and

protect your most sensitive data. Network Security,2012(12):5–8, December 2012.

[2] Gartner. Forecast: PCs, Ultramobiles, and Mobile Phones,Worldwide, 2011-2018, 2Q14 Update. Technical report,2014.

[3] Microsoft. Lesson 2 - Windows NT System Overview,2014.

[4] Microsoft. Windows Phone 8.1 Security Overview. Tech-nical Report April, 2014.

[5] Dominic Chell, Tyrone Erasmus, Jon Lindsay, ShaunColley, and Ollie Whitehouse. The Mobile ApplicationHacker’s Handbook. John Wiley & Sons, 2015.

[6] Microsoft. Windows Data Protection, 2001.[7] N. Mylle. Context-aware resource protection in ios, 2014.


Windows Phone iOS AndroidApp vetting Very strict inspection Strict inspection Weak inspectionApps downloading Windows Phone Store Apple App Store Google Play Store, third-parties

Developer programIndividual e14Company e75

e99 e25

Table 1. Comparing table application distribution

Windows Phone iOS AndroidApp sandbox Least Privilege Least Privilege More permissions than neededPermissions At runtime or at installation At runtime At installation

Capabilities Fine-grained Fine-grainedCoarse-grainedAll or nothing policy

Table 2. Comparing table app isolation.

Windows Phone 8.x iOS Android

File system encryptieBitLockerOnlymanagedHardware-backed

Keychain Data ProtectionAutomaticHardware-backed

dm-cryptAutomatic since v. 5.0Hardware-backed

Bestandsencryptie DPAPIuser or device dependent

Data Protection ClassesUitgebreide functieshardware-backed

no special privoded API

Table 3. Comparing table data and credential protection [7].

PUBLIC CONFIDENTIAL SECRET TOP SECRETUsername/passwordauthentication X X

Strong authenticatie X XFile encryption on externalstorage X X X

SSL connection X X X XTable 4. Overview of the classification levels.


Web

DAV

File

File

Exp

lore

rFi

leso

ftC

onne

ctor

Secu

reD

AVcl

ient

Use

rnam

e/pa

ssw

ord

Yes

Yes

Yes

Yes

Yes

Stro

ngau

then

ticat

ion

Not

liste

dN

otlis

ted

Not

liste

dN

een

Yes

Enc

rypt

ion

inte

rnal

stor

age

Not

liste

dY

esa

Yes

bN

otlis

ted

Yes

b

Enc

rypt

ion

exte

rnal

stor

age

Not

liste

dY

esa

Yes

bN

otlis

ted

Yes

c

SSL

Yes

Yes

Not

liste

dY

esY

esB

uild

-indo

cum

entv

iew

erN

oL

imite

dd

No

Lim

ited

eN

oTa

ble

5.C

ompa

ring

tabl

eW

indo

ws

Phon

eap

plic

atio

ns

a With

apa

ssw

ord

ofth

eus

erb W

ithD

PAPI

c AE

S-12

8d O

nly

form

usic

,vid

eoan

dim

ages

e Onl

yO

ffice

2007

files

Bijlage C

Poster

74

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN CAMPUS GENT (@KAHO Sint-Lieven)

Gebroeders De Smetstraat 1 9000 GENT, België

tel. + 32 9 265 86 10 fax + 32 9 225 62 69

[email protected] www.iiw.kuleuven.be

Date post:	28-Nov-2023
Category:	Documents
Upload:	kuleuven
View:	0 times
Download:	0 times

Data Protection in Windows Phone 8.1

Documents