Privacy versterkende applicatie voor Smartphones

Transcriptie

1 Privacy versterkende applicatie voor Smartphones Cédric Remande Thesis voorgedragen tot het behalen van de graad van Master of Science in de ingenieurswetenschappen: elektrotechniek, optie Multimedia en signaalverwerking Promotoren: Prof. Dr. Ir. Bart Preneel Prof. Dr. Ir. Ingrid Verbauwhede Assessoren: Dr. Ir. Danny De Cock Dr. Ir. Andreas Pashalidis Prof. Dr. Ir. Luc Van Eycken Begeleiders: Ir. Jens Hermans Ir. Filipe Ramos Araújo Beato Academiejaar

2 c Copyright KU Leuven Zonder voorafgaande schriftelijke toestemming van zowel de promotoren als de auteur is overnemen, kopiëren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor aanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie, wend u tot ESAT, Kasteelpark Arenberg 10 postbus 2440, B-3001 Heverlee, of via info@esat.kuleuven.be. Voorafgaande schriftelijke toestemming van de promotoren is eveneens vereist voor het aanwenden van de in deze masterproef beschreven (originele) methoden, producten, schakelingen en programma s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter deelname aan wetenschappelijke prijzen of wedstrijden.

3 Voorwoord Bijzondere dank gaat uit naar mijn promoter, Prof. Dr.Ir.Bart Preneel, voor interesse op te wekken in het uitdagende domein van de cryptografie. Ik zou ook mijn dagelijkse begeleiders ir. Filipe Ramos Araújo Beato en ir. Jens Hermans willen bedanken voor het verstrekken van onontbeerlijke informatie en het kritisch evalueren van mijn werk. Deze samenwerking heeft bijgedragen tot een visie op de wereld van de praktijk die de doelstellingen van dit werk ver overstijgen. Tenslotte wil ik mijn vrienden, kennissen en vooral mijn ouders en vriendin willen bedanken voor hun niet aflatende morele steun gedurende het voorbije jaar. Cédric Remande i

4 Inhoudsopgave Voorwoord Samenvatting Lijst van figuren en tabellen Lijst van afkortingen en symbolen 1 Inleiding 1 2 Doelstelling Inleiding OpenPGP Basisblokken OpenPGP Encryptie Digitale handtekeningen Certificaten Kwetsbaarheden Cloud Storage OCB Mode Veilige geheugenkaart Gebruikerservaring Use Cases Besluit Architecturen Android Componenten Intent Beveiliging op Android Cryptografie op Android Cloud storage via Dropbox JavaCard Java card technologie APDU Seek for Android Implementatie Cryptografie ii i iv v vi

5 Inhoudsopgave 4.2 Contacten Synchronisatie SyncAdapter Sleutelbeheer Gebruikservaring Herzien van de Use Cases Java Card Hoe JavaCard gebuiken Implementatiestrategie De Applet Resultaten Applicatie Dropbox Android Implementatie via Use Cases Het Verzenden van een Geëncrypteerd Bestand Het opslaan van een gëncrypteerd bestand op dropbox Verzenden van een publieke sleutel JavaCard Mogelijke Uitbreidingen Vermijden van Denial Of Service Gerbuik van Meerdere Smartphones Betere Contacten Synchronisatie Besluit 49 Bibliografie 51 iii

6 Samenvatting Beveiliging van gegevens en communicatie op android 2.2 froyo. Implementatie van het OpenPGP protocol via het pakket Spongy Castle dat voor een up-to-date cryptografische implementatie zorgt. Synchronisatie met Dropbox voor uitwisseling sleutels en contacten tussen meerdere android systemen of bij verlies van gegevens. Verplaatsing van het cryptografisch werk naar een Java Card voor betere efficiëntie en veiligheid. Doel: beveiligde (data integriteit berichten sturen naar contacten In dit abstract environment wordt een al dan niet uitgebreide samenvatting van het werk gegeven. De bedoeling is wel dat dit tot 1 bladzijde beperkt blijft. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viverra metus rhoncus sem. Nulla et lectus vestibulum urna fringilla ultrices. Phasellus eu tellus sit amet tortor gravida placerat. Integer sapien est, iaculis in, pretium quis, viverra ac, nunc. Praesent eget sem vel leo ultrices bibendum. Aenean faucibus. Morbi dolor nulla, malesuada eu, pulvinar at, mollis ac, nulla. Curabitur auctor semper nulla. Donec varius orci eget risus. Duis nibh mi, congue eu, accumsan eleifend, sagittis quis, diam. Duis eget orci sit amet orci dignissim rutrum. iv

7 Lijst van figuren en tabellen Lijst van figuren 2.1 Electronic Code Book (ECB) mode Cipher Feedback (CFB) mode OpenPGP Use case Verzenden van een een publieke via sms of (of oplsaan als bestand) Verzenden van een een publieke via sms of (of oplsaan als bestand) Ontvangen van een publieke sleutel via sms of Ontwerp van interactie tussen architecturen in de applicatie Apdu formaat Kwaadaardige applicatie probeert ongeoorloofde toegang te krijgen tot een Smart Card Use case Resultaat Dropbox Lijst van tabellen 5.1 Tijdsanalyse (nanosec) v

8 Lijst van afkortingen en symbolen Afkortingen AES APDU API CFB DSA MAC OCB PBE PGP RSA SDK Advanced Encryption Standard Application Protocol Data Unit Application Programming Interface Cipher feedback mode Digital Signature Algorithm Message Authentication Code Offset Codebook Mode Password Based encryption Pretty Good Privacy asymmetrisch encryptiealgoritme ontworpen door Ron Rivest, Adi Shamir en Len Adleman Software Development Kit Symbolen vi

9 Hoofdstuk 1 Inleiding Gentlemen do not read each others mail Henry Lewis Stimson De bescherming van de persoonlijke levenssfeer is een burgerrecht en een mensenrecht. Met de opkomst van smartphones in de huidige maatschappij, is het voor gebruikers steeds makkelijker om informatie en gegevens te delen en op te slaan op het internet via hun mobiel toestel. Hierdoor kan de gebruiker op verschillende manieren allerhande taken uitvoeren en informatie uitwisselen via onder andere , sociale netwerken, telefonie en blogs. Deze toepassingen veronderstellen weliswaar dat de gebruiker zowel het mobiele toestel als de serviceprovider vertrouwt. Dit is niet steeds het geval en kan mogelijk leiden tot inbreuk op de privacy van deze gebruiker. Vaak gaan mensen ervan uit dat er voldoende privacy geboden wordt via een smartphone. Met dit in het achterhoofd ontwikkelen we een applicatie voor een smartphone. Om de inbreuk op de privacy tegen te gaan, gebruikt de applicatie cryptografische protocollen die al meer dan tien jaar hun werking hebben bewezen in de beveiligingswereld. De opkomst van smartphones zal ook voor een toename in aanvallen zorgen, zoals bijvoorbeeld bij virussen. Om te vermijden dat de gebruiker alle beveiliging verliest met een virusinfectie zal een microsd-geheugenkaart gebruikt worden. Deze geheugenkaart is niet zoals de geheugenkaart die u in de winkel koopt, maar kan vergeleken worden met de chip in een bankkaart. Deze kaart kan cryptografische berekeningen op een veel efficientere wijze uitvoeren dan de smartphone. Kritische gegevens kunnen ook op deze kaart veilig afgeschermd worden van kwaadwillige applicaties. In de volgende hoofdstukken wordt zowel de theoretische als praktische achtergrond voor het ontwikkelen van deze applicatie besproken en uiteindelijk worden de verwezenlijkte resultaten getoont. In het hoofdstuk 2 is de doelstelling van de applicatie met theoretische achtergrond verduidelijkt. Hierna wordt in hoofdstuk 3 een overzicht van de gebruikte architecturen gegeven. Hoofdstuk 4 bespreekt we de meest uitdagende problemen van de implementatie hebben opgelost. Hierbij geven we ook enkele tips indien u wenst zich verder te verdiepen in het ontwikkelen van soortgelijke functionaliteiten. De verwezenlijkte doelstellingen worden getoond in hoofdstuk 5. Hoofdstuk 6 beschrijft enkele mogelijke uitbreidingen. Uiteindelijk is er nog een een samenvattend besluit in hoofdstuk 7. 1

10

11 Hoofdstuk 2 Doelstelling 2.1 Inleiding Het implementeren van een Android applicatie die, gebruik makend van cryptografische protocollen volgens de OpenPGP standaard, het mogelijk maakt om data en informatie op de mobiele telefoon en gedeeld door deze telefoon te beveiligen (zoals foto s, telefoon gesprekken, en facebook posts) is het doel van deze thesis. Om dit te bekomen moet een systeem ontwikkeld worden dat gebruik kan maken van een veilige geheugenkaart in het mobiel toestel. Deze veilige kaart zal ervoor zorgen dat het cryptografisch rekenwerk van de smartphone naar de kaart verplaatst wordt. De opslag van gevoelige gegevens zoals sleutels kunnen ook voor extra veiligheid zorgen. Sleutelbeheer met een samenhorende contactenlijst moet ook aanwezig zijn in de applicatie. Met de opkomst van interconnectiviteit in de huidige maatschappij, is het ook interessant om te kijken welke mogelijkheden cloud storage kan toevoegen. Ook zou de thesis een evaluatie van de veiligheid en de efficiëntie van de gebruikte algoritmes moeten bevatten en moet het uiteindelijke resultaat gebruiksvriendelijk genoeg zijn voor dagdagelijkse gebruikers. Uiteindelijk zal het uitmonden in een open source project dat beschikbaar is op google code [1] [2]. Zo kan de beveiliging die deze applicatie levert beter vertrouwd worden door de gewone gebruiker indien experts de code goedkeuren. Dit hoofdstuk zal een betere beschrijving bieden van de probleemstelling verdeeld over de OpenPGP standaard, cloud storage, veilige geheugenkaart en de gebruikerservaring/use-cases ten gevolge van de minimale vereiste voorkennis van de gebruiker.pgp 2.2 OpenPGP OpenPGP [3] is de meest gebruikte standaard voor ondertekenen, encrypteren en decrypteren van teksten, s en bestanden voor communicatie. Het is gebaseerd op de standaard RFC 4880 [4] en werd door Phil Zimmermann gecreëerd in It s personal. It s private. And it s no one s business but yours. You may be planning a political campaign, discussing your taxes, or having a secret 3

12 2. Doelstelling romance. Or you may be communicating with a political dissident in a repressive country... There s nothing wrong with asserting your privacy... Senate Bill 266, a 1991 omnibus anticrime bill, had an unsettling measure buried in it. If this non-binding resolution had become real law, it would have forced manufacturers of secure communications equipment to insert special trap doors in their products, so that the government could read anyone s encrypted messages... It was this bill that led me to publish PGP electronically for free that year. Phil Zimmermann [5, p. 39,40] OpenPGP gebruikt een combinatie van cryptografische basisblokken zoals hashfuncties, symmetrische en asymmetrische cryptografie. Deze combinatie zorgt voor confidentialiteit en integriteit. Confidentialiteit zorgt ervoor dat niemand de gegevens kan lezen terwijl integriteit zorgt voor zekerheid dat niemand de gegevens heeft aangepast. In cryptografie wordt de afkorting CIA(Confidantiality Integrity Availability) vaak gebruikt als de doelstelling voor een veilig systeem. Availability staat voor beschikbaarheid van de dienst die door het systeem geleverd is voor de gebruikers Basisblokken Symmetrisch cryptografie In symmetrische cryptografie wordt één sleutel gebruikt voor het vercijferen en ontcijferen. Het grootste voordeel is dat het heel snel is, terwijl de sleuteldistributie een onoverbrugbaar probleem vormt. Hoe kan op een veilige wijze de sleutel overgedragen worden van zender naar ontvanger zonder dat dit op voorhand is afgesproken? Er is een veilig communicatiekanaal nodig om deze overdracht te verwezenlijken. In realiteit bestaat deze niet en dus houdt symmetrische cryptografie zich niet bezig met het probleem van sleuteldistributie omdat dit opgelost wordt door asymmetrische cryptografie. Symmetrische cryptografie wordt ook wel blokcijfers genoemd omdat de te coderen tekst opgesplitst wordt in blokken van gelijke lengte. Het symmetrisch algoritme kan enkel werken met inputs van precies deze lengte, ook blokgrootte van het algoritme genoemd. De grootte van de output is ook gelijk aan deze blokgrootte. Als de in blokken gesplitste boodschap rechtstreeks naar de ingang van een blokcijfer symmetrisch algoritme wordt gestuurd, is dit Electronic Code Book (ECB) mode, zie figuur 2.1. Tussen de blokken wordt geen informatie uitgewisseld en dit maakt deze mode onveilig omdat het geen patronen verbergt. Andere modes zoals CBC (Cipher Block Chaining) [6] en CFB (Cipher Feedback) lossen dit probleem op door blokken onderling afhankelijk van elkaar te maken. Figuur 2.2 toont dat elke uitgang van een blok bitsgewijs modulo 2 wordt opgeteld met de plaintext. Deze optelling is de ciphertekst en wordt als ingang van de volgende blok gebruikt. Zo is elke ciphertext van een blok afhankelijk van alle blokken uitgevoerd tot dat punt. Bij de eerste blok wordt een IV(initialisatie vector) gebruikt. Als hiervoor een unieke waarde wordt gekozen, zal de encryptie ook de eigenschap indistinguishability hebben. Dit betekent dat twee dezelfde 4

13 2.2. OpenPGP Figuur 2.1: Electronic Code Book(ECB) mode. Source: org/wiki/file:ecb_encryption.png boodschappen na encryptie een verschillende ciphertext geven waardoor een aanvaller geen informatie kan halen uit het observeren van ciphertexts. Cipher Feedback heeft enkele interessante eigenschappen. Ten eerste verwacht deze mode geen padding. ECB en CBC verwachten wel dat de input een veelvoud is van de blokgrootte. Padding zorgt ervoor dat elke tekst een veelvoud wordt van de blokgrootte door een aantal extra bytes aan het einde toe te voegen. Na decryptie wordt deze padding verwijderd. Ten tweede bij encryptie zorgt een fout in de plaintext voor een eeuwig propagerende fout in de ciphertext. Het decryptie proces kan geparallelliseerd worden, bij encryptie kan dit niet. Een fout bij decryptie zal enkel twee blokken beïnvloeden. In de OpenPGP standaard wordt OpenPGPCFB-mode gebruikt [4, p. 78,79]. Dit is een variant op de normale CFB mode. De IV wordt geïnitialiseerd met een reeks nullen. Hierna worden een x aantal bytes gegenereerd waar x gelijk is aan de blokgrootte plus twee. Deze twee laatste bytes zijn herhalingen van de twee vorige en dienen voor synchronisatie volgens [4, p. 78,79]. Het arikel [7] haalt aan dat dit eerder een integriteitscontrole is op het eerste blok bytes. In het artikel wordt ook een mogelijke aanval op deze aangepaste CFB-mode geïllustreerd. Tegenwoordig wordt AES (Advanced Encryption Standard) [8] gebruikt als standaard algoritme voor symmetrische encryptie. In 1997 REF lanceerde het Nationaal Instituut voor Standaardisatie en Technologie (NIST) [9] in Amerika een wereldwijde wedstrijd om een nieuwe standaard te maken voor symmetrische encryptie die een opvolger zou zijn voor het DES (Data Encryption Standard) [10] algoritme. Het Rijndael algoritme won deze wedstrijd en werd als standaard door NIST gepubliceerd [11] REFFIPS??. De blokgrootte van AES is 128 bits terwijl de sleutelgrootte 128, 192 of 256 bits kan zijn voor respectievelijk AES-128, AES-192 of AES-256. Asymmetrisch cryptografie Asymmetrische cryptografie ook publieke sleutel cryptografie genoemd lost de problemen van sleuteldistributie op dankzij het concept geïntroduceerd door Whitfield 5

14 2. Doelstelling Figuur 2.2: Cipher Feedback (CFB) mode. Source: org/wiki/file:cfb_encryption.png, Cfb_decryption.png Diffie en Martin Hellman [12]. Publieke sleutel cryptografie maakt gebruik van één paar sleutels: een publieke en een samenhorende private sleutel. De publieke sleutel wordt beschikbaar gesteld voor de hele wereld terwijl de private sleutel ten alle tijde geheim blijft. De publieke sleutel dient voor vercijfering van gegevens terwijl er met de bijhorende private sleutel deze boodschap ontcijfert kan worden. Het is computationeel zo goed als onmogelijk om uit de publieke sleutel de private sleutel te berekenen. Het grootste voordeel is dat personen die nog nooit op voorhand een sleutel hebben afgesproken op een eenvoudige manier veilig boodschappen kunnen versturen. Het enige dat de verzender nodig heeft is de publieke sleutel van de ontvanger. De nood aan een veilig communicatiekanaal waarover de zender en ontvanger een geheime sleutel afspreken zoals bij symmetrische cryptografie valt dan weg. Daarentegen is de snelheid veel trager dan symmetrische algoritmes (ongeveer 1000 keer). Asymmetrische cryptografie kan ook gebruikt worden voor het maken van digitale handtekeningen. Hierbij gebruiken we hetzelfde algoritme maar in plaats van te encrypteren met de publieke sleutel van de ontvanger gebruikt de verzender zijn eigen private sleutel. Om een digitale handtekening te verifiëren gebruiken we dan de publieke sleutel van de ondertekende. Veel gebruikte algoritmes zijn RSA [13] en Elgamal [14]. Elliptic Curve Diffie- 6

15 2.2. OpenPGP Hellman(ECDH) wordt momenteel aangeraden door de NSA [15]. DSA en RSA worden veel gebruikt voor digitale handtekeningen. Cryptografische Hashfuncties Een cryptografische hashfunctie is een algortime die een input van willekeurige lengte krijgt en een output produceert met een vaste lengte. De ouput van een cryptografische hashfuntie wordt vaak message digest genoemd. Een cryptografisch hash algoritme moet aan de volgende voorwaarden voldoen: 1. Het is computationeel zeer moeilijk om een input te vinden met een gegeven hash output. 2. Het is computationeel zeer moeilijk om een verschillende input te vinden met dezelfde hash ouput als de gegeven input. 3. Het is computationeel zeer moeilijk om twee verschillende inputs te vinden die dezelfde hash output produceren. De eerste eigenschap zorgt ervoor dat de hashfunctie oninverteerbaar is. De tweede eigenschap geeft de mogelijkheid om hashfuncties te gebruiken als een controle op de integriteit van informatie. Als het onmogelijk is om de boodschap te veranderen zonder dat de digest verandert kan deze digest bewijzen dat de boodschap ongewijzigd is als de digest van de ontvanger overeenkomt met diegene van de verzender. De derde en laatste eigenschap zorgt ervoor dat de hashfunctie resistent is tegen outputbotsingen. Om dit te bereiken zou het algoritme een unieke output moeten geven voor elke verschillende input. Natuurlijk is dit onmogelijk omdat we een output hebben van vaste lengte waardoor de verzameling van mogelijke ouputs beperkt is. Deze functies worden gebruikt bij digitale handtekeningen om te vermijden dat een grote hoeveelheid gegevens moet verwerkt worden door het asymmetrische algoritme. SHA-2 [16] is een set cryptografische hashfuncties ontworpen door de NSA. Deze set bevat vier hash functies met verschillende output lengte namelijk 224, 256, 384 en 512 bits. MD5 (Message Digest)REF?? ontworpen door Ronald Rivest wordt ook nog veel gebruikt, alhoewel in 2004 serieuze fouten ontdekt zijn die het gebruik van dit algoritme in twijfel trekken OpenPGP Encryptie OpenPGP is een hybride cryptosysteem. Een combinatie van van hashfuncties, gegevens compressie, symmetrische en asymmetrische cryptografie zorgt ervoor dat de voordelen van elke basisblok maximaal wordt benut/tot hun recht komen, zie figuur 2.3. De eerste stap is compressie. Dit zorgt voor minder transmissietijd, minder geheugengebruik en versterkt de cryptografische beveiliging. De meeste cryptoanalyse technieken maken misbruik van het feit dat er patronen zitten in de te encrypteren gegevens. Compressie vermindert deze patronen aanzienlijk, waardoor de weerstand verhoogt tegen cryptanalyse. De volgende stap is het genereren van 7

16 2. Doelstelling Figuur 2.3: OpenPGP. Source: diagram.svg een sessiesleutel. Deze sessiesleutel wordt maar éénmaal gebruikt. Een random algoritme genereert deze sleutel. Het symmetrisch algoritme zal dan met deze sleutel de boodschap vercijferen. Het asymmetrisch algoritme zal de sessiesleutel vercijferen met de publieke sleutel(s) van de ontvanger(s). Deze twee outputs worden samengevoegd en verzonden naar de ontvanger. Decryptie daarentegen werkt omgekeerd. Bij aankomst van de boodschap wordt deze in twee gesplitst. Uit het eerste deel wordt de sessiesleutel gehaald door ontcijfering met de private sleutel van de ontvanger. Met deze sessiesleutel kan nu de boodschap ontcijferd worden. Tenslotte wordt de boodschap gedecomprimeerd. OpenPGP ondersteunt bij elke stap meerdere algoritmes waartussen gekozen kan worden. Met de beschreven stappen kunnen boodschappen confidentieel verzonden worden. De integriteit van deze boodschappen kan niet verzekerd worden zonder het gebruik van digitale handtekeningen Digitale handtekeningen Digitale handtekeningen laten de ontvanger van informatie de authenticiteit van de oorsprong en de integriteit van deze informatie nakijken. De digitale handtekening geeft ook onweerlegbaarheid wat betekent dat de zender niet kan ontkennen dat hij deze informatie heeft getekend. Een geschreven handtekening is eenvoudig te vervalsen terwijl het voor een digitale handtekening bijna onmogelijk is met als bijkomende voordelen integriteit en identiteit. Om een tekst te ondertekenen wordt een asymmetrisch algoritme gebruikt. Het enige verschil is dat bij het encrypteren de private sleutel van de ondertekenaar wordt gebruikt. Iedereen kan deze handtekening nakijken door te decrypteren met 8

17 2.2. OpenPGP de publieke sleutel van de ondertekenaar. Zoals eerder vermeld, zijn asymmetrische algoritmes traag bij het verwerken van een grote hoeveelheid tekst. Om dit probleem te vermijden wordt eerst een message digest berekend met een cryptografische hashfunctie van de te ondertekenen tekst. Het algoritme berekent de digitale handtekening met deze message digest van korte lengte in plaats van de volledige boodschap. Bij ontvangst van een getekende boodschap berekent de ontvanger de message digest van de boodschap opnieuw. Uit de digitale handtekening wordt de message digest gehaald met de publieke sleutel van de ondertekende. Als de message digests overeenkomen heeft de ontvanger zekerheid over de integriteit, authenticiteit en onweerlegbaarheid van de boodschap. Als een digitale handtekening en de encryptie, die in het vorige deel besproken is, combineren in één boodschap is er zowel confidentialiteit, integriteit, authenticiteit als onweerlegbaarheid Certificaten Een probleem bij publieke cryptosytemenen is dat gebruikers continu waakzaam moeten zijn dat de publieke sleutel waarmee ze encrypteren wel tot de correcte persoon behoort. Bij man-in-the-middle aanval is er een aanvaller die berichten tussen communicerende partijen kan afluisteren, wijzigen, verwijderen of eigen berichten kan doorsturen. Dergelijke aanvallen kunnen een valse publieke sleutel verbinden met een identiteit. Data geëncrypteerd voor deze identiteit met de valse sleutel kan gelezen worden door de aanvaller mits onderschepping van de boodschap. Digitale certificaten lossen dit probleem op door te bevestigen dat de publieke sleutel wel degelijk behoort tot de eigenaar weergegeven op het certificaat. Een digitaal certificaat bestaat uit drie onderdelen: een publieke sleutel, certifiërende informatie en digitale handtekeningen. Het doel van deze digitale handtekeningen is om de correctheid van de informatie op het certificaat te bekrachtigen. De handtekeningen bewijzen echter niet de correctheid van de informatie op het certificaat maar tonen aan dat de tekenaars de informatie als correct beschouwen Kwetsbaarheden Er bestaat geen beveiliging die onbreekbaar is. De vraag is natuurlijk of informatie voor de aanvaller meer waarde heeft dan de kost van de aanval. Cryptanalyse is mogelijk zoals Phil Zimmermann zelf beschrijft: An expensive and formidable cryptanalytic attack could possibly be mounted by someone with vast supercomputer resources, such as a government intelligence agency. They might crack your public key by using some new secret mathematical breakthrough. But civilian academia has been intensively attacking public key cryptography without success since Phil Zimmermann [5, p. 65] De beveiliging van OpenPGP kan op de volgende wijzen omzeild worden. 9

18 2. Doelstelling Gestolen paswoord en private sleutel Als iemand in het bezit is van je private sleutel en paswoord, kan hij de boodschappen die voor jou bestemd zijn lezen en digitale handtekeningen in jouw naam aanmaken. Wijziging publieke sleutel Een van de meest cruciale kwetsbaarheden is het geknoei met publieke sleutels. Zoals eerder vermeld kan een aanvaller zijn slachtoffer overtuigen dat zijn publieke sleutel de sleutel is van een kennis van het slachtoffer. Bij gebruik van een valse publieke sleutel zal de ontvanger deze boodschap niet kunnen ontcijferen. De aanvaller die knoeide met de publieke sleutel kan dit wel ontcijferen indien hij de bijhorende private sleutel heeft. Bij elk gebruik van een publieke sleutel moet er nagekeken worden of er niet mee geknoeid is. Een nieuwe publieke sleutel kan enkel vertrouwd worden indien het rechtstreeks afkomstig is van de eigenaar of als het gehandtekend is door een betrouwbare persoon. Nog niet verwijderde bestanden Een veelgemaakte foute veronderstelling is dat wanneer men het originele bestand verwijdert na encryptie dit bestand volledig verwijderd is. De meeste besturingssystemen zullen het bestand niet letterlijk verwijderen maar het bestand markeren als overschrijfbaar. Ook tijdelijke versies die nog overblijven bij het inbrengen van de informatie vormen een gevaar. De enige oplossing hiervoor is zorgen dat deze oorspronkelijke gegevens worden overschreven. Virussen en trojaanse paarden Een virus kan een paswoord, private sleutel of ontcijferde boodschappen stelen. Deze informatie kan dan doorgestuurd worden naar de eigenaar van het virus. PGP heeft geen beveiliging tegen virussen en gaat ervan uit dat de gebruiker zijn eigen computer een veilige omgeving is. Een andere aanval is het maken van een slimme imitatie van PGP. Deze imitatie kan zich gedragen zoals PGP op de meeste vlakken. Dit trojaans paard in PGP zou dus dankzij kleine aanpassingen een achterdeur vormen voor de kwaadwillige maker van deze imitatie. Werkgeheugen Het besturingssysteem gebruikt de harde schijf om een deel van de software, dat momenteel niet gebruikt wordt, op te slaan. Dit kan als gevolg hebben dat informatie zoals paswoorden of nog niet gecodeerde teksten zonder dat de ontwerper hiervan weet heeft naar de harde schijf geschreven worden. PGP gebruikt deze gevoelige informatie niet langer dan nodig is maar dit probleem kan toch nog voorkomen. Valse tijdsregistratie Oneerlijke gebruikers kunnen de datum en de tijd van het systeem aanpassen zo- 10

19 2.3. Cloud Storage dat ze handtekeningen aanmaken op een gekozen tijdstip. Dit kan bijvoorbeeld legale of financiële voordelen hebben. Dit probleem is echter niet erger dan bij geschreven handtekeningen omdat ook hier de datum niet correct vermeld kan zijn. Trafiek analyse Door observaties van het transmissiekanaal kan een aanvaller zien wie de communicerende partijen zijn, het aantal berichten, het tijdstip van communicatie, enz. Deze informatie wordt niet door PGP beschermd. Dit probleem oplossen zou een gespecialiseerd communicatie protocol eisen. Voor meer informatie,???? zie. 2.3 Cloud Storage Cloud storage is in onze samenleving meer en meer aanwezig. Het voordeel dat men van eender waar zijn gegevens kan raadplegen, is voor veel individuen onmisbaar geworden. Dit brengt natuurlijk een hele hoop beveiligingsproblemen met zich mee waar de meeste individuen niet bij stilstaan. Worden mijn gegevens beveiligd bij het versturen naar de server of bij het ontvangen van de server? Is het bedrijf dat deze servers beheert wel te vertrouwen? Is de beveiliging die men publiceert op de website wel op een correcte wijze geïmplementeerd? Dit laatste is vaak heel moeilijk na te gaan. Grote bedrijven houden graag de broncode geheim om verlies van knowhow te vermijden. Door uit te gaan van het standpunt dat de beveiliging niet te vertrouwen is zal de applicatie zorgen voor zijn eigen beveiliging. Waarom is deze beveiliging dan wel te vertrouwen? De voornaamste reden is het feit dat de broncode vrij beschikbaar is op het internet. Als er gewenste of ongewenste beveiligingsfouten aanwezig zijn, kunnen experts die deze code inkijken dit aanhalen. Cloud storage geeft de mogelijkheid om gegevens uit te wisselen tussen meerdere apparaten zoals smartphones maar ook computers. Hiermee kan de gebruiker zonder veel moeite veranderen van smartphone. Om dit doel te bereiken wordt er een synchronisatie algoritme voorzien. Daar de cloud storage beschouwd wordt als onveilig medium zal het algoritme confidentialiteit en integriteit moeten verwezenlijken. Beschikbaarheid is via cloud storage niet controleerbaar. Toch zijn er enkele mogelijke oplossingen die beschreven worden in het hoofdstuk??. Het synchronisatie algoritme zal de contactpersonen samen met hun publieke sleutels opslaan op de cloud storage. Deze publieke sleutelring zal automatisch gesynchroniseerd worden bij het aanmaken, verwijderen en wijzigen van contacten. Bij gebruik van een nieuw toestel zullen deze contacten automatisch associëren aan de applicatie. Deze functionaliteit zorgt zowel voor back up als synchronisatie tussen verschillende toestellen. De voorgestelde synchronisatie bevat nog een probleem. Bij het gebruik van meerdere toestellen moet het mogelijk zijn om inkomende boodschappen op elk toestel te decrypteren. Dit vereist dat de private sleutel aanwezig is op elk toestel. 11

20 2. Doelstelling De richtlijnen voor OpenPGP vermelden dat de private sleutel ten alle tijde bij zich moet gehouden worden, wat een probleem vormt voor de functionaliteit die we willen verwezenlijken. Om de doelstelling voor het eenvoudig gebruik van meerdere toestellen te bereiken zal de private sleutel op een veilige wijze via cloud storage verstuurd moeten worden van het ene naar het andere toestel. Om dit te verwezenlijken gebruiken we een geauthenticeerd-encryptie schema. Een andere oplossing voor dit probleem kan u vinden in hoofdstuk?? OCB Mode AES-OCB is een voorbeeld van een authenticated-encryption schema, uitgevonden door Phil Rogaway [17]. Offset Code Book (OCB) [18] is een mode voor blokcijfer algoritmes die zowel confidentialiteit, authentificatie als integriteit verzekert. De vermelde modes ECB en CFB bieden enkel confidentialiteit. In het verleden werd dit gerealiseerd door apart te encrypteren en een MAC (Message authentication code) te berekenen. De kost voor het encryptie algoritme en het MAC algoritme is ongeveer tweemaal die van enkel encryptie. Het OCB-algoritme lost dit probleem op door zowel confidentialiteit, authentificatie als integriteit te bereiken met dezelfde kost als een algoritme dat enkel confidentialiteit geeft. Een MAC algoritme is een cryptografische hash function met sleutel. De inputs zijn een geheime sleutel en een boodschap van arbitraire lengte. De output van het algoritme is een MAC en verzekert zowel de authentificatie als de integriteit. OCB heeft nog enkele interessante eigenschappen. OCB heeft een beveiliging die wiskundig bewijsbaar is. Het is volledig parallelliseerbaar. Het vermijdt gebruik van een IV door een nonce te gebruiken. Bij definitie is een nonce een getal dat maar één keer gebruikt wordt. Deze nonce is nodig voor het decrypteren. Het hoeft niet willekeurig of geheim te zijn. De enige voorwaarde is dat het uniek moet zijn. Bij modes die IV s gebruiken zoals CBC, CFB,... moet deze IV onvoorspelbaar zijn voor een aanvaller om een sterke beveiling te verwezenlijken. De generatie van een IV is dus ingewikkelder en heeft een grotere kost. Zoals bij CFB mode is er geen padding noodzakelijk van de plaintext en zijn de lengtes ciphertext en plaintext gelijk. De OCB mode zal gebruikt worden om de private sleutel tussen verschillende toestellen te delen. Deze mode werd gekozen omwille van zijn lage kost om zowel confidentialiteit, authentificatie als integriteit te bereiken. Voor meer informatie [19] [20]. 2.4 Veilige geheugenkaart De veilige geheugenkaart zal de toekomst zijn voor beveiliging op smartphones. Het zorgt voor extra beveiliging. Ten eerste is er hardware implementatie voor basis cryptografie algoritmes zoals AES, RSA, Elliptische Curven,... Ten tweede is er mogelijkheid om gevoelige informatie zoals de private sleutel en de sessiesleutel op te slaan in een veilige omgeving. Deze gevoelige informatie zou de kaart nooit mogen verlaten. Als veilige geheugenkaart zal hier Java Card [21] technologie gebruikt worden. Java Cards hebben als voordeel de portabiliteit, compatibiliteit 12

21 2.5. Gebruikerservaring en eenvoudig programmeren van Java applets. De communicatie tussen applets en Android applicaties kan worden gecontroleerd door een access controller die ervoor zorgt dat alleen toegelaten applicaties met de applet kunnen communiceren. Ook bevat het beveiliging tegen kwaadaardige codes die op een lager niveau met de applet proberen te communiceren. Dit zal verder uitgelegd worden in hoofdstuk 3.4. De cryptografische algoritmes in OpenPGP zouden op de Java Card moeten worden uitgevoerd in plaats van de smart phone. Dit brengt zowel meer veiligheid als een versnelling in tijd. De generatie van het publieke en private sleutelpaar en de generatie van de sessiesleutel voor het symmetrische algoritme zouden ook op deze Java Card moeten worden uitgevoerd. De publieke sleutel kan worden geëxporteerd terwijl de private sleutel en de sessiesleutel nooit de kaart verlaten. Om ondersteuning te bieden voor het synchronizeren van de private sleutel tussen verschillende toestellen moet ook het de OCB mode voor AES geïmplementeerd worden. Zo zal de private sleutel enkel de Java Card verlaten onder versleutelde vorm. 2.5 Gebruikerservaring Op de huidige markt verwachten analoge applicaties veel voorkennis in het domein van cryptografie en laten ze veel over aan de gebruiker. Voor de grootste groep van gebruikers is dit niet erg gebruiksvriendelijk. Als de nodige stappen om veilige transmissie te bereiken te talrijk of ingewikkeld zijn, zullen de meeste gebruikers deze stappen overslaan. Het doel is met een eenvoudige gebruikersinterface de zo veel mogelijk beveiliging te garanderen zonder dat de gebruikerservaring hierop achteruit gaat. Iedereen met een kleine basiskennis van cryptografie zou deze applicatie moeten kunnen gebruiken. Dit evenwicht tussen gebruiksvriendelijkheid en veiligheid is complex. "Security is orthogonal to functionality - just because a security product functions properly does not mean it s secure" Bruce Schneier Use Cases Het gebruik van de applicatie kan beschreven worden met behulp van enkele belangrijke use cases die we willen bereiken. In hoofdstuk?? vergelijken we deze use cases met de verwezenlijkte implementatie. 13

22 u w w w u w w w u u w w w 2. Doelstelling USE CASE 1: Het verzenden van een geëncrypteerd bestand via sms of of opslaan op dropbox. Gebruiker selecteert Gebruiker typt tekst selecteert Bestand <bytes> O <bytes> O O OQ klikt start Gebruiker Encrypt knop OpenP GP selecteert opent lijst Contact O O O O O O O<publickey> O O verzend als <ciphertext> Gebruiker opties SM S/ Figuur 2.4: Use Case 1:Verzenden van een geëncrypteerd bestand via sms of of opslaan op dropbox. USE CASE 2: Verzenden van een een publieke via sms of (of oplsaan als bestand) Gebruiker klikt Sleutel verzenden opent typt in Gebruiker popup SM S Data Gebruiker telefoonnummer A AAA A AAAA publieke sleutel verzend Figuur 2.5: Verzenden van een een publieke via sms of (of oplsaan als bestand) 14 USE CASE 3: Ontvangen van een publieke sleutel via sms of

23 w u w u u u u w 2.6. Besluit klikt Gebruiker Sleutel verzenden typt opties verwerking SM S Saveasf ile Figuur 2.6: Verzenden van een een publieke via sms of (of oplsaan als bestand) Bestand ' '' Contactenlijst ' ''') Sms w F ilter w V erwerking w M elding u w Gebruiker [ [[ [ [[[] Contactviatel/ weetni Figuur 2.7: Ontvangen van een publieke sleutel via sms of 2.6 Besluit De doelstelling van deze thesis is het implementeren van een Android applicatie. Deze applicatie zal de OpenPGP standaard implementeren om confidentialiteit en integriteit te verzekeren van data en informatie die op de mobiele telefoon aanwezig is of gedeeld wordt door deze telefoon (zoals foto s, telefoon gesprekken, en facebook posts). 15

24 2. Doelstelling Cloud storage geeft de mogelijkheid om gegevens op het internet op te slaan. Hiermee kunnen meerdere functionaliteiten bereikt worden: het synchronizeren van de publieke sleutels van de contactpersonen, het uitwisselen van de private sleutel tussen toestellen en het delen van bestanden. Met de veilige geheugenkaart kan de gebruiker van de applicatie s nachts op beide oren slapen. Virusinfecties of andere aanvallen zullen dankzij de veilige geheugenkaart zo goed als onmogelijk zijn en voor de aanvaller te veel moeite vergen. Het veilig bewaren van de gevoelige informatie is niet het enige voordeel. De veilige geheugenkaart zal ervoor zorgen dat het cryptografisch rekenwerk van de smartphone naar de veilige geheugenkaart verplaatst wordt. Dankzij de hardware implementatie op de veilige geheugenkaart zal zowel performantie als veiligheid verhogen. De applicatie is ontworpen voor een zo groot mogelijke doelgroep. Er is veel aandacht besteed aan de eenvoudige gebruikersinterface. De code van de applicatie is open source en vrij beschikbaar op REFS. In het volgend hoofdstuk wordt er dieper ingegaan op de architecturen die het mogelijk hebben gemaakt om deze doelstelling te bereiken. 16

25 Hoofdstuk 3 Architecturen Dit hoofdstuk beschrijft de gebruikte architecturen en hun interactie om de doelstelling van hoofdstuk 2 te realiseren. Figuur 5.1 toont een schematisch overzicht van het ontwerp. Figuur 3.1: Ontwerp van interactie tussen architecturen in de applicatie. Als smartphone hebben we gekozen voor een android systeem omdat het minder restricties oplegt aan de ontwerper en zeer duidelijke documentatie heeft. Om de cryptografie te verwezenlijken op een mobiele applicatie als android gebruiken we de open source pakket Spongy Castle. Deze biedt een up-to date security provider voor het android systeem. Een veilige microsd-geheugenkaart kan aanwezig zijn in het Android systeem. Op deze geheugenkaart is de Java Card technologie aanwezig. Deze kaart zullen we gebruiken voor opslag van gevoelige informatie en cryptografische berekeningen. Dropbox wordt gebruikt voor cloud storage. 17

26 3. Architecturen Een verduidelijking van de verschillende architecturen volgt nu. 3.1 Android Android REF applicaties zijn geschreven in de programmeertaal Java [22]. De Android [23] onderdelen compileren de code in een archief bestand met.apk als suffix. Bij het installeren van een.apk bestand op het mobiele apparaat gaat de applicatie zoals alle andere applicaties uitvoeren in zijn eigen sandbox voor beveiligingsredenen. Een sandbox is een afgeschermde ruimte waarin de applicatie kan werken zonder andere applicaties te beïnvloeden. 1. Het Android besturingssysteem is een multi-gebruiker linux systeem waarin elke applicatie een verschillende gebruiker is. 2. Standaard kent het systeem elke applicatie een unieke gebruikers-id toe. Deze id kan enkel gebruikt worden door het systeem en is onbekend voor de applicatie. Het systeem bepaalt de toegangsrechten voor alle bestanden in een applicatie zodat enkel de gebruikers id van deze applicatie toegang heeft tot deze bestanden. 3. Elk proces heeft zijn eigen virtuele machine zodat de code onafhankelijk van andere applicaties wordt uitgevoerd. 4. Elke applicatie heeft zijn eigen linux proces. Bij het uitvoeren van één van de onderdelen van een applicatie start Android een proces op. Wanneer dit proces niet langer meer nodig is of wanneer het geheugen beschikbaar moet zijn voor andere applicaties, sluit Android het proces af. Op deze manier past Android het systeem toe van het principe van minimaal privilege. Dit wil zeggen dat elke standaard toepassing alleen toegang heeft tot de onderdelen die nodig zijn om zijn functionaliteit te verwezenlijken. Dit creëert een veilige omgeving waarin een applicatie geen toegang kan krijgen tot onderdelen van het systeem waar het geen rechten voor heeft Componenten Er zijn vier verschillende componenten die elk een essentieel bouwblok zijn voor een Android applicatie. Elk van deze componenten heeft een verschillende wijze waarop het systeem de applicatie kan aanroepen. Activity Een activiteit stelt één enkel scherm voor met een corresponderende gebruikersinterface. Alhoewel elke activiteit onafhankelijk is, zorgt de samenwerking van verschillende activiteiten voor een samenhorende gebruikservaring. Een applicatie kan een activiteit opstarten van een andere applicatie als dit voorzien is. 18

27 3.1. Android Service Een service is een component dat op de achtergrond draait en geen gebruikersinterface voorziet. Een voorbeeld hiervan is een service die zorgt voor een synchronisatie procedure met het internet zonder de gebruiker te blokkeren in zijn interactie met het Androidsysteem. Een service voorziet twee opstartmechanismen. Ten eerste kan een activiteit, die iets wil doen op de achtergrond, een service opstarten en deze laten uitvoeren. De service blijft actief zelfs als de activiteit die hem opstarte verdwenen is en wordt zo dus niet gebruikt in een context waar de opstartende acitiveit een antwoord verwacht. De service stopt zichzelf éénmaal zijn procedure voltooid is. Voorbeeld hiervan is een bestand uploaden of downloaden. Ten tweede kan een activiteit binden met een service. Dit voorziet een langdurige connectie met deze service voor interactie en biedt zo een deel van zijn functionaliteit aan aan andere applicaties. Meerdere componenten kunnen tegelijkertijd binden met de service. De service stopt zichzelf wanneer alle componenten hun verbinding verbreken. Services draaien in dezelfde thread van het proces van de applicatie waarin de service gemaakt is. Als de service processor intensief of blokkerend is, is het beter dit proces op te starten in zijn eigen thread. Hierdoor wordt het risico op ANR (Application Not Responding) uitzonderingen verkleind en wordt de basis thread van de applicatie die gebruikersinteractie voorziet niet geblokkeerd door de service. Content providers Een content provider beheert de gedeelde databank van de applicatie. Deze data kan opgeslagen worden in het bestandssysteem, SQLite database [24] of het internet. Via deze content provider kunnen andere applicaties deze data opvragen en aanpassen als de content provider dit toelaat. Het Android systeem voorziet een standaard content provider voor het beheer van de contactpersonen. Elke applicatie met de nodige rechten kan deze informatie uitlezen, aanpassen en nieuwe informatie ernaartoe schrijven. Het voordeel van deze standaard content provider is dat de informatie die toegevoegd wordt in de standaard contactenlijst van het Anroid systeem zichtbaar is. Broadcast receivers Een broadcast receiver is een component die reageert op een broadcast melding. Deze meldingen worden vaak door het systeem opgeroepen, bijvoorbeeld het ontvangen van een sms, lege batterij,... Applicaties kunnen ook zelf broadcasts genereren. Deze kunnen zelf gedefiniëerd of standaard aanwezig zijn in het systeem. Een applicatie definieert een broadcast filter voor elk van zijn eigen broadcast receivers die enkel de gewenste broadcasts doorgeeft. Een broadcastreciever biedt geen gebruikersinterface aan maar kan wel een melding in de statusbalk van Android weergeven. De gebruiker kan deze melding dan 19

28 3. Architecturen aanklikken waardoor de applicatie verder de broadcast kan verwerken. De melding dat een sms is ontvangen, is een voorbeeld hiervan. De gebruiker kan dan de sms openen door op de melding te klikken. Uniek aan de Android architectuur is dat elke applicatie een component van een andere applicatie kan starten. Bijvoorbeeld als een gebruiker een sms wil verzenden, bestaat er waarschijnlijk een andere applicatie die dit kan. De applicatie kan deze gebruiken in plaats van zelf de functionaliteit te implementeren. Voor de gebruiker oogt het alsof deze functionaliteit deel uitmaakt van de applicatie. Een applicatie kan niet zelf een component van een andere applicatie oproepen. De applicatie moet een boodschap, die intent heet, geven aan het Android systeem dat specifieert welke specifieke component nodig is. Het Android systeem zal deze component voor de gebruiker activeren. Als er meerdere applicaties een gewenste component bevatten opent het Android systeem een lijst van deze mogelijkheden. De gebruiker kan dan zelf selecteren welke applicatie hij verkiest. Activities, services en broadcast receivers kunnen opgeroepen worden door zo een asynchrone intent Intent Een intent verbindt individuele componenten, die bij dezelfde of verschillende applicaties behoren, met mekaar tijdens de uitvoering. In een activiteit kan een intent gedefinieerd worden die een andere activiteit oproept. Deze intent kan een bundel extra primitieve datatypes als parameters meekrijgen. Bij het uitvoeren van de intent kan er meegegeven worden dat we een resultaat verwachten. De opgeroepen activiteit kan de status van het resultaat en het resultaat zelf terugspelen als parameters naar de oproepende activiteit. In de oproepende activiteit zal automatisch een methode opgeroepen worden die het resultaat verwerkt. Zoals eerder vermeld kunnen activiteiten services starten of ermee verbinden. De activiteit zal dit doen via een intent. Een broadcast uitzenden wordt ook geïnitieerd door een intent. Deze intent definieert enkel de melding die gebroadcast wordt, bijvoorbeeld dat de batterij bijna leeg is. De content provider wordt niet geactiveerd door intents. Het wordt geactiveerd door een verzoek van de content resolver die alle transacties met de content provider behandelt. Zo hebben componenten geen rechtstreekse toegang tot de content provider maar roepen ze methodes op via hun eigen content resolver. Dit zorgt voor extra beveiliging dankzij een abstractielaag tussen de content provider en de componenten die informatie opvragen Beveiliging op Android Het mobiele platform Android werd ontwikkeld met een robuust beveiligingsmodel om een evenwichtig ecosysteem van applicaties te verwezenlijken. het android platform is gedurende zijn hele ontwikkelingscyclus getest door beveiligingsexperts. De code van Android is vrij beschikbaar en dit maakt inspectie van deze code door een grote aantal individuen mogelijk. Het Android systeem voorziet volgende beveiligingshoofdkenmerken: 20

29 3.1. Android 1. Robuuste beveiliging op het besturingssysteemsniveau 2. Verplichte applicatie sandbox voor alle applicaties 3. Veilige interproces communicatie 4. Ondertekenen van een applicatie 5. Rechten gedefiëerd door applicaties en goedgekeurd door de gebruiker Enkel een klein deel van het Android besturingssyteem, de Linux Kernel, heeft root access. Alle andere applicaties hebben een eigen unieke gebruikersid met hun eigen rechten. Deze gebruiker wordt enkel door het besturingssysteem gebruikt. De applicatie wordt uitgevoerd als deze gebruiker in een apart proces. OPGELET Dit is niet de gebruiker van de smartphone zelf! IS DIT DUIDELIJK? JA/NEE. De sandbox zorgt ervoor dat elk applicatie proces geïsoleerd is van andere processen. Voor communicatie tussen processen is een een veilig IPC(inter-process communication) aanwezig. Dit vermijdt dat een kwaadaardige applicatie andere applicaties of het Android systeem zelf schade berokkent. Geheugen corruptie brengt bij de meeste systemen de volledige beveiliging van het systeem in gevaar. Bij Android is dit niet het geval omdat elke applicatie met zijn resources geïsoleerd wordt in een sandbox op het niveau van het besturingssysteem. Een geheugen corruptie kan enkel leiden tot het uitvoeren van arbitraire code binnen de rechten van deze applicatie. Enkel de kernel en kleine subsets van kernapplicaties worden uitgevoerd met root rechten. In Android wordt een applicatie intentioneel beperkt in zijn bewerkingen met systeemonderdelen. De Android API bevat geen directe manipulaties met de SIM kaart. Systeemonderdelen zoals camera, GPS, Bluetooth, telefonie, SMS en netwerk zijn enkel toegankelijk via het besturingssysteem met de Android API. Een applicatie dient expliciet aan te geven als een van deze systeemonderdelen wordt gebruikt. De gebruiker zal hiervan op de hoogte gebracht worden bij de installatie van de applicatie. Proecessen kunnen enkel communiceren via traditionele UNIX mechanismen. Android voorziet hier enkele nieuwe IPC mechanismen. Een binder maakt voor elke applicatie een verschillend proces aan met eigen bestandsrechten die de toegang van andere applicaties beperkt. Android is een multiprocessysteem waarbij elke applicatie, en elk deel van het systeem, in zijn eigen proces uitgevoerd wordt. De beveiliging tussen applicaties wordt opgelegd door het systeem op het niveau van processen via standaard Linux functionaliteiten zoals gebruikers en identificatienummers die aan elke applicatie gekoppeld worden. Android voorziet ook een fijnere beveiliging via een rechtenmechanisme. Dit rechtenmechanisme zorgt ervoor dat bepaalde operaties van een proces kunnen uitgevoerd worden en Android is een besturingssysteem waarin elke applicatie wordt uitgevoerd met een uniek identificatienummer voor het systeem. Het systeem verdeelt zich aan de 21

30 3. Architecturen hand van deze identificatie en isoleert zo de applicaties van elkaar. Een specifiekere beveiliging kan bereikt worden door het rechtenmechanisme. Deze rechten specifiëren wat een proces wel of niet mag doen. Een ad hoc recht uri Standaard heeft geen enkele applicatie rechten om operaties uit te voeren die een schadelijke impact kunnen hebben op andere applicaties, het besturingssysteem of de gebruiker. Dit bevat het lezen of schrijven van private gebruikersinformatie, van bestanden behorende tot andere applicaties, netwerktoegang... Bij installatie van een applicatie wordt de gebruiker gevraagd om akkoord te gaan met alle rechten die de applicatie nodig heeft. Android bevat geen mechanisme om dynamisch rechten toe te staan omdat dit nadelig is voor de veiligheid door een verstoorde gebruikerservaring. Om zich te beveiligen, isoleert Android de applicaties van elkaar in een sandbox. Via expliciete vermelding van rechten die een applicatie nodig heeft om functionaliteiten of informatie te gebruiken, kan deze isolatie. Voor installatie van Android applicaties moeten ze getekend worden met een certificaat van de ontwikkelaar. Het certificaat heeft als doel de ontwikkelaar te identificeren. Het hoeft echter niet ondertekend te worden door een certifiërende autoriteit en kan zelf ondertekend zijn. Hierdoor is er geen zekerheid van de identiteit maar kan er nog wel een onderscheid gemaakt worden tussen verschillende ontwikkelaars. Android dwingt de beveiliging op het niveau van processen af waardoor twee applicaties niet in hetzelfde proces kunnen uitgevoerd worden. Een Voor meer informatie [25] Het Android systeem maakt voor elke applicatie een verschillend proces aan met eigen bestandsrechten die de toegang van andere applicaties beperkt. Android is een multiprocessysteem waarbij elke applicatie, en elk deel van het systeem, in zijn eigen proces uitgevoerd wordt. De beveiliging tussen applicaties wordt opgelegd door het systeem op het niveau van processen via standaard Linux functionaliteiten zoals gebruikers en identificatienummers die aan elke applicatie gekoppeld worden. Android voorziet ook een fijnere beveiliging via een rechtenmechanisme. Dit rechtenmechanisme zorgt ervoor dat bepaalde operaties van een proces kunnen uitgevoerd worden en Voor meer informatie [25] 3.2 Cryptografie op Android In het besturingssysteem van Android zit er een verminkte security provider van het type Bouncy Castle [26]. Een security provider is een verzameling van bibliotheken die concrete implementatie kan voorzien van cryptografische basisalgoritmes, zoals RSA, AES, SHA-1,... en sleutelbeheer voor de Java Securtity API REF. Deze bevat enkel een deel van de functionaliteit die Bouncy Castle voorziet wegens geheugen beperkingen. De versie van deze verminkte Bouncy Castle (1.34) is meer dan vijf jaar oudref. Enkel sinds de nieuwste versie van Android 4.0, is een verminkte Bouncy Castle met versie 1.46 meegeleverd. Deze bevat ook een subset van de 22

31 3.3. Cloud storage via Dropbox functionaliteiten. De laatste versie van Bouncy Castle, 1.47, werd uitgebracht op 23 maart Omdat Bouncy Castle (BC) in Android een beperkt aantal bibliotheken incorporeert en bij het installeren van een up-to-date versie van de bibliotheken er conflicten zijn ten gevolge van de klassenlader werd het project gecrëeerd. Spongy Castle (SC) heeft als doel de laatste versie van Bouncy Castle te kunnen gebruiken in Android applicaties. Spongy Castle veranderde kleine zaken om deze conflicten te vermijden. De naam van de bibliotheek werd veranderd en de naam van de Java security API provider werd veranderd van BC naar SC. 3.3 Cloud storage via Dropbox Met meer dan vijftig miljoen gebruikers en ondersteuning tussen meerdere platforms is Dropbox gekozen om de cloud storage te verwezenlijken. Dropbox biedt gratis een API aan die op een eenvoudige wijze kan geïntegreerd worden aan een Android applicatie. Met de toevoeging van enkele bibliotheken aan het programma kunnen eenvoudige instructies een verbinding opzetten naar Dropbox, een bestand uploaden, een bestand downloaden, versiebeheer, een bestand beschikbaar maken voor iedereen. De bibliotheken hebben een goede documentatie die verduidelijkt wordt met enkele voorbeelden. Door het gebruik van Dropbox als server is er een groot verschil met de typische server client structuur. Ten eerste kan de Dropboxserver geen logica uitvoeren. Het synchronisatiealgoritme van contactpersonen wordt hierdoor lokaal op het Androidsysteem uitgevoerd. De Android architectuur bevat echter een veel minder krachtige processor dan typische servers. Deze factoren zorgen voor extra complexiteit bij het ontwerp van het synchronisatiealgoritme. Hoofdstuk gaat hierop dieper in. Het tweede verschil is dat elke gebruiker niet verbindt met één grote opslagruimte. Elke gebruiker verbindt met zijn eigen account op Dropbox met een individuele opslagruimte. Hierdoor delen meerdere gebruikers nooit dezelfde geheugenruimte wat het het synchronisatiealgoritme eenvoudiger maakt. Dit is een groot contrast met de typische server client structuur waar de server vele gebruikers deelt in zijn opslagruimte. Vereist is dat elke gebruiker een Dropbox account heeft. De Dropbox applicatie moet echter niet geïnstalleerd zijn op zijn gsm maar kan via de web browser aangesproken worden. De applicatie maakt folder aan in de Dropbox van de gebruiker. Over deze folder heeft de applicatie volledige controle. Cloud storage voegt nog enkele andere interessante functionaliteiten toe zoals het publiceren van bestanden die men wil delen met andere personen zoals: de publieke sleutel, gecodeerde bestanden die te groot zijn om via sms of te verzenden. Bij het publiceren maakt Dropbox een unieke en volgens Dropbox moeilijk te voorspellen link aan die verwijst naar het gepubliceerde bestand. Indien achteraf de applicatie nogmaals een link naar hetzelfde bestand aanvraagt, zal Dropbox een nieuwe unieke link genereren. Door deze link te versturen dan kan de verzonden sms of 23

32 3. Architecturen compact gehouden worden. Het maken van een link naar een bestand zorgt er voor dat enkel dit bestand toegankelijk is en niet de andere bestanden die aanwezig zijn in dezelfde folder. De eerste stap voor als ontwikkelaar is de applicatie online registreren. Tijdens de ontwikkeling kunnen vijf gebruikers de hun Dropbox koppelen met de applicatie. Eenmaal de ontwikkeling van de applicatie voltooid is en kan verdeeld worden over de google play markt, is het nodig om extra informatie door te spelen over de functionaliteit van de applicatie aan Dropbox. De applicatie zal dan door Dropbox nagekekeken worden en met hun goedkeuring mag de applicatie verdeeld worden. De beveiling van Dropbox zoals vermeld op hun website voor het verzenden en opslaan van gegevens is een SSL (Secure Sockets Layer) [27] verbinding en AES-256 encryptie. Omdat de applicatie ervan uitgaat dat deze beveiliging niet aanwezig is en er zelf voor zorgt. 3.4 JavaCard opzoeken, lezen vertalen!!! Javacard technologie biedt een precieze subset van Java aan voor het programmeren van applets. Deze applets kunne op een veilige wijze uitvoeren en een zeer kleine geheugen verbruik eisen. Het hoofddoel van Java Card technology zijn draagbaarheid(portability?) en veiligheid. Dezelfde Java Card Applet kan op verschillende smart cards uitgevoerd worden. Dit is mogelijk gemaakt door Java Card Virtual Machine en een welgedefinieerde runtime bibliotheek. Draagbaarheid wordt enigszins beperkt door problemen zoals grootte van het geheugen, performantie en ondersteuning van de runtime bibliotheek. Java Card technologie zorgt op verschillende aspecten voor de beveiliging van gevoelige informatie. Gegevens Encapsulatie De gegevens die van de applicatie worden door een geisoleerde omgeving, de Java Card Virtual machine, gebruikt. Dit is volledig gescheiden van het Android systeem. Applet Firewall De Java Card VM zorgt ervoor dat verschillende applicaties met elk hun eigen gevoelige informatie gescheiden blijven. De applet firewall beperkt de toegang van gegevens van een andere applicatie. Cryptografie De meest gebruikte cryptografische algoritmes worden ondersteund. Persistence With Java Card, objects are by default stored in persistent memory (RAM is very scarce on smart cards, and it is only used for temporary or securitysensitive objects). The runtime environment as well as the bytecode have therefore been adapted to manage persistent objects. Atomicity As smart cards are externally powered and rely on persistent memory, persistent updates must be atomic. The 24

33 3.4. JavaCard individual write operations performed by individual bytecode instructions and API methods are therefore guaranteed atomic, and the Java Card Runtime includes a limited transaction mechanism. Applet isolation The Java Card firewall is a mechanism that isolates the different applets present on a card from each other. It also includes a sharing mechanism that allows an applet to explicitly make an object available to other applets. Javacard heeft als voordeel dat de basisblokken van de cryptografie zoals AES en RSA volledig in de hardware zijn geimplementeerd waardooor deze veel performanter uitgevoerd worden dan op een niet dedicated systeem zoals Android. De card kan beschermd worden door een pincode, zo kunnen de kritsiche gegevens zoals een sessiesleutel of de private sleutel van het assymetrsch cryptografisch algoritme op een veiligere manier bewaard worden. IK heb een vermoeden dat in de toekomst internet banking ook op gsm zal kunnen plaatsvinden dankzij het gebruik van zo een securitycard zoals de javacard. In dit project is de javacard gebruikt (Giesecke en Devrient) die u terugvindt in bijlage... In de volgende subsecties worden de mogelijkheden beschreven van de javacard, de communicatie, de structuur van de pakketten die verzonden worden en hoe Android deze paketten kan interpreteren Java card technologie Bij het ontwerp van de Java Card implementatie moet correcte aandacht besteed worden aan welke variabelen we in het werkgeheugen steken of in het permanent geheugen (EEPROME Electrically erasable programmable read-only memory) In de Java Card API wordt ondersteuning gegeven voor eenvoudige implementatie van een pincode APDU Dit zijn de pakketten die verstuurd worden voor de communicatie tussen de smartcard en het Android systeem. De structuur van het APDU-protocol is gedefinieerd in ISO7816 [28] en dit pakket ziet er als volgt uit( 3.2) De interface tussen de applet en de applicatie is een reeks van APDU instructies die op voorhand overeengekomen zijn. Deze communicatie gebeurt telkens in paren. Elk paar bevat een instructie APDU dat beantwoord wordt met een antwoord APDU; hetgeen het resultaat bevat en de status van executie. Java Cards kunnen beschouwd worden als reactieve communicators. Met de SELECT APDU instructie kan de correcte applet op de Java Card geselecteerd worden. Eenmaal de applet geselecteerd is kunnen instructies uitgevoerd worden op deze applet. Elke instructie heeft een voorgedefinieerde code en kan twee parameters van het type byte meegegeven worden. Ook kan er een dataveld meegegeven worden van maximum 256 bytes. Dit vereist extra implementatie voor het verzenden van grote hoeveelheden data naar de Java Card. Voor het verzenden van grote hoeveelheden data van de Java Card naar het Android systeem kan de architectuur die wij gebruiken block chaining gebruiken voor het aaneenkoppelen van 25

34 3. Architecturen Figuur 3.2: Apdu formaat. meerdere APDU s. Dit voordeel vermindert de complexiteit van de implementatie van de applet op de Java Card. De grootste moeilijkheid met deze APDU s is dat het data pakket maar 256 bytes kan bevatten. Er moet dus een buffer geschreven worden om grote hoeveelheden data naar de smart Card te sturen Seek for Android Het project seek for Android probeert de communicatie van Android met Java Card te vergemakkelijken. De voorgestelde oplossing is een Smart Card API die de nodige modules toevoegt aan het Android platform. Deze biedt een flexibele toegang tot veilige elementen voor een applicatie. Deze veilige elementen kunnen USIM card zijn, secure µsd card, of een geïntegreerd veilig element enz. De Smart Card API voorziet voor de ontwikkelaars toegang tot beveiligde elementen op een zo open mogelijke wijze zonder standaard certificaat. De Smart Card API voorziet twee mechanismen om te voorkomen dat ongeoorloofde toegang tot de Smart Card voorkomt. Het eerste mechanisme, zie figuur 3.3, beschermt tegen het rechtstreeks aanspreken van componenten van lager niveau. Het proces van de Smart Card API is geïnstalleerd en geregistreerd met een unieke UID/GID (userid/groupid). Bij het aanspreken van een component of oproepen van een methode van laag niveau wordt de UID van de oproeper nagekeken. Als deze niet correct is wordt er een uitzondering gegooid. Het tweede mechanisme verzekert dat enkel toegelaten of gecertifieerde Android applicaties toegang hebben tot een specifiek applet van de Java Card., er worden meerdere oplossingen voorgesteld op hun website. 26

35 3.4. JavaCard Figuur 3.3: Kwaadaardige applicatie probeert ongeoorloofde toegang te krijgen tot een Smart Card. De meeste!? oplossingen verwachten root access tot het Android besturingssysteem. Dit betekent dat enkel gebruikers die root access hebben een applicatie kunnen gebruiken die deze oplossing gebruikt heeft. Dit zal in 99 procent van de gevallen niet zo zijn. Het rooten van een gsm heeft als gevolg dat de garantie wegvalt en dat al het gebruikersgeheugen wordt gewist. De gekozen oplossing vereist dit niet. maar heeft nadelen???? Dit ligt in de lijn van de doelstellingen van deze thesis om een werkende applicatie op de markt te publiceren die voor iedereen toegankelijk is. 27

36

37 Hoofdstuk 4 Implementatie Dit hoofdstuk beschrijft de gekozen oplossingen voor meest uitdagende problemen van de implementatie. De architecturen van hoofdstuk 3 worden nu gecombineerd om de doelstelling van hoofdstuk 2 te realiseren. Stap voor stap zullen we de applicatie opbouwen. Het eerste onderdeel toont aan hoe cryptografie verwezenlijkt wordt. Daarna komt het contactenbeheer aan bod met het synchronisatieprobleem en de sleutelverdeling. Hierop kan een gebruikersinterface gebouwd worden. Uiteindelijk kan de applet van de Java Card aan de applicatie gekoppeld worden. 4.1 Cryptografie Cryptografie op Android kan het best verwezenlijkt worden dankzij het Spongy Castle pakket. Zoals vermeld in hoofdstuk 3 zorgt Spongy Castle voor een up to date security provider. Werken met het Bouncy Castle pakket kan tot conflicten leiden wegens verschillende versies van de ingeladen bibliotheek en de aanwezige bibliotheek. Spongy Castle zit echter nog in zijn beta-fase en heeft dus nog niet de tijd gehad om alle klasses te converteren. Sommige bibliotheken waaronder de OpenPGP bibliotheek, zijn dus nog niet meegenomen omdat de ontwerper nog geen tijd heeft gehad om deze code volledig na te kijkenref. Het gebruik van deze code is natuurlijk essentieel om de gewenste cryptografie te bereiken in onze applicatie voor Android. Het aanpassen van Spongy Castle is niet mogelijk want bij compilatie moet deze ondertekend worden door Google of Java sun wat een hele procedure teweegbrengt en teveel werk vereistref. Dit is natuurlijk om te voorkomen dat eender wie een security provider op de markt brengt en beweert dat deze veilig is. Een programma dat deze security provider met trojaans paard zou gebruiken, kan in werkelijkheid een achterpoortje openzetten die kritische gegevens toegankelijk maakt voor de onbetrouwbare ontwerper. Dit probleem is uiteindelijk opgelost geraakt door de bibliotheek OpenPGP van Bouncy Castle te kopiëren in de code met veel foutmeldingen door verwijzingen naar Bouncy Castle klassen die niet aanwezig zijn. Al deze verwijzingen zijn veranderd naar 29

38 4. Implementatie de Spongy Castle provider waar dezelfde klassen aanwezig zijn. Het resultaat is dat de basisblokken van een symmetrische en asymmetrische cryptografie door de bibliotheek van Spongy Castle verwezenlijkt worden. De omhullende PGP architectuur zit nu rechtstreeks in de code van de applicatie. Dit heeft als bijkomend voordeel dat deze code eenvoudig aangepast kan worden voor integratie met de Java Card zoals beschreven wordt in??. Aan de hand van voorbeelden aanwezig in de bibliotheek zijn functies aangemaakt voor het genereren van sleutelparen, vercijfering, digitale handtekeningen enz. De meeste tijd voor het ontwerpen van deze cryptografische functionaliteit werd gestoken in het analyseren van het correct gebruik van de gegeven functies in het pakket Spongy Castle. Het vercijferen en ondertekenen kan toegepast worden op eender welk bestand dat leesbaar is van het Android systeem of op een ingegeven boodschap. BUFFER PROBLEEM BIJ LARGE FILES. Er is echter nog een probleem aanwezig bij het vercijferen van bestanden die teveel megabytes groot zijn een :(:(:(. Buffer is ni af De OCB-mode voor blokcijfers is niet aanwezig in het Spongy Castle pakket en moet dus geïmplementeerd worden. Op de website van Phil Rogaway REF, de uitvinder van OCB-mode, is een implementatie aanwezig in Java samen met testvectoren. Deze implementatie bevat echter een zelf geschreven AES algoritme. Spongy Castle bevat ook de implementatie van het AES algoritme. De code is aangepast om redundantie te vermijden zodat enkel nog het algoritme voor de OCBmode overblijft. Aan de hand van de testvectoren is de correcte werking getest. Deze aanpassing geeft nog een extra voordeel zoals beschreven wordt in het deel 4.4 Java Card. Er zijn meerdere problemen die aan bod komen bij het gebruik van deze mode in de applicatie. Een eerste is er een nonce nodig voor initialisatie. Zoals reeds vermeld in hoofdstuk 2 is een nonce een getal dat maar ëën keer gebruikt wordt. Het hoeft niet onvoorspelbaar te zijn zoals de IV bij modes zoals CBC en CFB. Het probleem is dat we meerdere toestellen van dezelfde gerbuiker dit algoritme gebruiken met dezelfde te encrypteren data en sleutel.????????? Een tweede probleem is de sleutel voor het AES algoritme. Omdat aan de gebruiker een paswoord is gekoppelt is het logisch om dit paswoord te gebruiken. Dit paswoord heeft natuurlijk niet de lengte dat het AES algoritme verwacht. Dit probleem kan opgeslost worden door een key stretching algoritme. ZIN SECURITY WIKI Eén van de problemen is PBE(Password Based Encryption) waarbij een speudo random generation algoritme nodig is om het paswoord naar een groter verwachte lengte te brengen?????. WIKI BLACKBARY 1 iteration 2008 fips raadplegen correct implementatie. Op stack overflow staat er een implementatie voor dit probleem. Deze implementatie heb ik nagegeken in de fibs... om te kijken of de gekozen waarden overeenstemmen in een veilige implementatie van het algoritme.op wikipedia staat er dat in 2008 blackberry een fout heeft gemaakt en hier maar 1 iteratie gebruikte. spongycastle gebruikt hetzelfde algoritme voor private sleutels te beveiligen. Die iteraties zijn echter maar 64 wat veel te weinig is!!!code 30

39 4.2. Contacten 4.2 Contacten Een contactenbeheer wordt voorzien in de applicatie om Synchronisatie In de android applicatie is het mogelijk om een gebruikersaccount aan te maken. Bij dit proces worden de persoonlijke, publieke en private sleutels gegenereerd voor encryptie en handtekeningen. De publieke sleutel wordt op dropbox bijgehouden, via een eenvoudige klik kan een link verzonden worden naar de gewenste telefoonnummer of adres. De publieke code kan ook geexporteerd worden als een bestand. Als dit type bestand met een publieke sleutel wordt geopend op android zal de applicatie automatisch vragen bij welke contactpersoon dit moet worden toegevoegd. De private sleutel zou ten alle tijde prive/beschermd moeten worden voor ongeautoriseerd gebruik. Men zou ze dus moeten opslaan in een beveilgd stuk geheugen. OpenPGP??SC verwacht bij elke gebruik van de private sleutel een paswoord. In deze zin is de private sleutel op zich een beetje beschermd. Het paswoord moeten we dus zien te beschermen. Android biedt meerdere mogelijkheden om gegevens op te slaan zoals besproken in vorige hoofdstuk 3. De meeste mogeljkheden hebben optie MODE PRIVATE die ervoor zorgt dat enkel de applicatie zelf deze gegevens kan lezen. Natuurlijk als deze ge-root is of met een virus geinfecteerd, kan deze beveiliging niet verzekerd worden. Een veel gebruikte oplossing is het passwoord niet bij te houden in plane text maar de hash en salt bij te houden. Het nadeel hiervan is dat bij elk gebruik van de private sleutel dit paswoord opnieuw gevraagt dient te worden. Hierdoor daalt de gebruiksvriendlijkheid drastisch. Om de gebruiksvriendlijkheid aanvaardbaar te houden zouden we dit paswoord even in het werk geheugen kunnen steken voor éé gebruikers sessie. In android werkt dit werkgeheugen als volgt er wordt een file in MODE PRIVATE aangemaakt waarin de gegevens worden opgeslagen Uiteindelijk als het systeem geinfecteerd is door virus of rootacces heeft kunnen we dit zonder Java card technologie niet op een veilige manier verwezelijken. In het geval dat de gegevens van de gsm verloren gaan of bij het gebruik van meerdere toestellen is het natuurlijk interessant om dezelfde geëncrypteerde boodschappen te kunnen raadplegen. Om dit te verwezelijen moet de private sleutel van toestel naar toestel op een veilige manier worden overgezet. De methode die we hiervoor gekozen hebben gaat een beetje in tegen de crytografische gedachtengang. We hebben gekozen om de private sleutel op dropbox te zetten met een AES-OCB beveiliging. Deze beveiliging biedt zowel databeveilging, confidentialiteit, integriteit en autentificatie SyncAdapter Content provider atribute android:exported=false Contacts provider opzoeken op Android site zin quote je Mag niets veranderen ven iemand anders -> Integritchecks 31

40 4. Implementatie Google Android gebruikt de syncadapter als structuur voor het implementeren van contactpersonen. Deze algemene structuur is een database die door elk programma op een uniforme manier kan aangesproken worden. Zonder gebruik van syncadapter en account authenticator is het niet mogelijk dat de contactpersonen van de applicatie voorkomen in de contactpersonenlijst van de gsm. Deze functionaliteit werd als doelstelling opgelegd omdat het door Google aanbevolen wijze van implementeren is. Het nadeel is dat elk programma deze database zowel kan uitlezen als aanpassen. Een kwaadaardig programma zou hiervan gebruik kunnen maken om de integriteit van een publieke sleutel aan te passen. Als oplossing is er een extra beveiliging toegevoegd, het programma heeft een private sql database waarin de unieke contactidentificatienummers met een corresponderende salted MAC worden bijgehouden. Het SHA-512 algoritme, samen met een willekeurige en unieke salt berekent deze MAC met het identificatienummer samengevoegd met de publieke sleutel van deze contactpersoon. Hiermee worden applicaties tegengehouden bij het wijzigen van gegevens van de contactpersonen op de standaardwijze. Virussen of applicaties die root access hebben zullen deze lokale database toch nog kunnen aanpassen en de beveiliging omzeilen. Deze voorgestelde structuur is op het eerste zicht complex maar eenmaal deze begrepen is kan men er op een gemakkelijke manier geavanceerde constructies mee realiseren. Een voorbeeld hiervan is het synchroniseren van verwijderde contacten. Als men de delete contactpersoon functie oproept, met als optie dat deze oproep lokaal is, dan zal de contactpersoon niet volledig verwijderd worden maar aangevinkt worden als moet verwijderd worden bij volgend synchronisatieproces. Bij de volgende synchronisatie zal deze delete contactpersoon functie terug opgeroepen worden met de optie dat de oproep deel uitmaakt van het synchronisatieproces. Hierna zal de contactpersoon volledig verwijderd zijn van het systeem. Dit zou veel programmeerwerk vereisen als deze complexe structuur niet bestond. De applicatie heeft als functionaliteiten het toevoegen, aanpassen en verwijderen van contactpersonen. De contactpersonen zijn automatisch gesynchroniseerd met drop box die de meest recente lijst bijhoudt. Om de confidentialiteit en integriteit van deze gegevens te bewaren zijn deze geencrypteerd met OpenPGP gebruikmakend van je eigen publieke sleutel. De beschikbaarheid kan niet gegarandeerd worden omdat we geen controle hebben over dropbox. Het synchronisatie algoritme werkt als volgt: Het tijdstip van de laatste synchronisatie wordt gedownload. 2. Dit tijdstip wordt vergeleken met het laatste tijdstip van synchronisatie dat lokaal bijgehouden wordt. 3. Als deze tijdstippen gelijk zijn: De lijst van drop box wordt gedownload. dan worden de lokale contactpersonen met wijzigingen aangepast, de nieuwe toegevoegd en de verwijderde worden verwijderd uit de lijst van drop box als ze aanwezig zijn.

41 4.3. Gebruikservaring Uiteindelijk worden de nieuwe, aangepaste lokale contactpersonen als upto-date aangevinkt tov het synchronisatieproces. De verwijderde worden nu volledig verwijderd van het systeem. 4. Als het gedownloade tijdstip groter is dan het lokale: dan betekent dit dat de lijst van drop box een recentere versie bevat van de contactpersonen. De lijst van drop box wordt gedownload. Elke contactpersoon die zowel in deze lijst van drop box als lokaal aanwezig is wordt lokaal verwijderd 5. Als het gedownloade tijdstip kleiner is dan het lokale: Voor de symmetrische-sleutel encryptie gebruiken we Advanced Encryption Standard-256 (AES-256) met een sleutelgrootte van 256bit. We gebruiken deze omdat deze ook gebruikt wordt door National Security Information (NSA) suite B. [15], Sleutelbeheer SMS + DROPBOX combo wijziging pub key + hack DB vermijd stelen dankzij integrity check niet aanwezig in contentporvider van android 4.3 Gebruikservaring Na encryptie of toevoegingen van handtekeningen kan de beveiligde boodschap verzonden worden via sms, applicatie aanwezig op android, gesaved naar file, opgeslagen op dropbox of geshared worden via programma s die dit ondersteunen zoals twitter en facebook. Het doel van deze thesis was volledige sms en integratie. Sms integratie is door android mogelijk gemaakt door het versturen van intents bij het verzenden en ontvangen van een sms. De applicatie kan dus een sms verzenden zonder dat de gebruiker dit opmerkt. Bij het ontvangen van een sms wordt de applicatie wakker geroepen door een sms ontvangen intent (action received). Het programma kijkt naar de boodschap, indien deze begint met een welbepaald formaat zal de applicatie een poging doen tot decryptatie en/of verifieren van handtekeningen van de sms. Bij is dezelfde integratie in het android systeem niet aanwezig. Men kan een verzenden intent geven aan het android systeem met als type en dit zorgt ervoor dat er een lijst open springt van programma s die s kunnen verwerken, de gebruikers selecteert hier 1 uit en dan wordt automatisch de gegevens zoals adres, booschap en bijlage ingevuld. Bij het ontvangen van een wordt geen intent door het operation system van android gegenereerd omdat deze integratie er niet is. Eigenlijk zouden de aplicatie deze ontvangen intent moeten doorgeven zodat applicaties de boodschap kunnen bekijken en verwerken indien nodig. Daar er weinig applicaties zijn die dit nodig hebben doet geen enkel programma dit. Besluit: Voor het verzenden van een 33

42 4. Implementatie kan alles automatisch gebeuren, bij het ontvangen van een dienen er meerdere stappen te gebeuren. Een ander probleem is dat het verzenden van geëncrytpeerde bestanden een hele lange tekst kan zijn. Bij kunnen we dit oplossen door dit in een bestand te steken en toe te voegen in bijlage. Als deze bijlage geopend wordt zal mijn applicatie automatisch openspringen om het te verwerken. Bij sms is dit natuurlijk niet mogelijk. De oplossing die we hiervoor gekozen hebben is niet het encrypteerde bestand door te sturen, maar het geëncrytpeerde bestand op dropbox te zetten en de link hiernaar door te sturen. Bij ontvangst van zo een sms zal het programma een notificatie geven. Indien deze notificaite aangeklikt word door de gebruiker zal deze automatisch gedownload en verwerkt worden. Indien de gebruiker dit niet wenst kan hij nog altijd achteraf handmatig downloaden door op de linkt te klikken; bij het openen van deze download zal het programma het gedownloade bestand verwerken. Het genereren van deze link via de dropbox API zorgt ervoor dat enkel dit bestand publiek is, de overige bestanden worden niet publiek gemaakt. Deze linkt wordt gegenereerd via de unieke code/ per gegeratie???? Herzien van de Use Cases Aanpassingen owille van doelstellingen die niet realiseerbaar waren 4.4 Java Card De implementatie van de Java Card was de moeilijkste. Wegens moeilijke testomstandigheden is het debuggen van de code vrij omslachtig. Omdat de Java Card enkel output kan produceren via APDU s, waardoor het moeilijk is om de fout te lokaliseren binnen ëën functie. Er moet veel extra code geschreven worden om bijvoorbeeld om alle verschillende uitzonderingen te converteren naar verschillende APDU s. Java Card ondersteunt maar een subset van de Java programmeertaal waardoor het implementeren van algoritmes complexer wordt. Bijvoorbeeld: enkel de primitieve types short byte worden ondersteund, terwijl int de meest gebruikt representatie is voor getallen in standaard Java programma s Hoe JavaCard gebuiken De ontwikkelings omgeving blalbla De rechten die de applicatie moet hebben in de manifest van de applicatie voor het communiceren met een Smart Card is de volgende: android.permission.smartcard Het uiteindelijke doel is open PGP te verwezenlijken via deze Java Card om een vergelijking te maken in het geval dat de encryptie enkel op het Android systeem gebeurt. Een volledige implantatie van open PGP op de Java Card zou onmogelijk zijn. De oplossing die toegepast is, maakt een splitsing in de code van de bibliotheken van open PGP van Spongy Castle wanneer cryptografische basisprotocolen worden gebruikt. Dit zorgt dat alle omringende functies die de standaard open PGP protocol implementeren, behandeld worden door de bibliotheken van Spongy Castle. 34

43 u w w w w w w u w w u 4.4. Java Card Gebruiker opent A AAAC A AAA opent Contactenlijst Gebruiker Bestandsverkenner Bestand typt tekst [ [[[ typt selecteert [ [[[ selecteert [ [[[ <bytes> O O [ [[[] Contact O O O O O O O O <publickey> O O <bytes> O O OQ klikt start produceert Gebruiker Encryptknop OpenP GP ciphertext opent lijst BD selecteert verzend Gebruiker opties SM S/ opslaan op B <link ciphertext> B B B B B Dropbox Figuur 4.1: Use Case 1:Verzenden van een geëncrypteerd bestand via sms of of opslaan op dropbox. Er zijn vier punten waar de code opsplitst naar Java Card indien deze aanwezig is. Het eerste punt is bij de generatie van het sleutelbaar voor encryptie en decryptie. Deze worden gegenereerd op de Java Card en enkel de publieke sleutel kan uit de kaart geëxporteerd worden. Omwille van functionaliteit wordt ook de exportatie van de private sleutel gebruikt. Dit is nodig om te zorgen dat er zowel met als zonder Java Card kan gewerkt worden. Deze methode kan gemakkelijk gedesactiveerd worden maar dan is de gebruiker verplicht om een Java Card te bezitten. Het tweede punt is de asymmetrische encryptie van het sessiepakket. Hier wordt op de kaart een sessiesleutel gegenereerd waarbij de algoritmecode en checksum worden toegevoegd. Dit vormt dan een pakket dat geëncrypteerd wordt met de publieke sleutel van de ontvanger. Deze publieke sleutel wordt ingeladen via een methode op de Java Card. Eenmaal de encryptie van dit sessiepakket voltooid is, 35

44 4. Implementatie wordt dit van de Java Card teruggegeven aan de bibliotheken van Spongy Castle voor verdere verwerking. Het derde punt is de symmetrische encryptie van de boodschap. In Spongy Castle wordt een CipherOutputStream gebruikt voor encryptie en CipherInputStream voor decryptie. Door overerving zijn de klassen herschreven zodat er een splitsingspunt ontstaat bij aanwezigheid van de Java Card. Als de Java Card aanwezig is, zal de boodschap versleuteld worden op de Java Card met de gegenereerde sessiesleutel die al aanwezig is op de Java Card. Het vierde en laatste punt is de synchronisatie van de private sleutel met Dropbox. Het algoritme dat op de OCB website te vinden is, is aangepast om de standaardbibliotheken te gebruiken. Dit algoritme is ook aanwezig op de Java Card voor extractie op een veilige wijze van de private sleutel. De moeilijkste stap voor het oplossen van deze problemen was het lokaliseren van de splitsingspunten waar informatie naar Java Card wordt gestuurd. Deze zullen nu in detail getoond worden. Eenmaal deze splitsing geïdentificeerd zijn, is er een structuur gemaakt om deze methodes te vertalen naar APDU s en het ontvangen van ADPU s te verwerken. De applet op de Java Card Exeptions in javacard Booschappen naar javacard kunnen maximaal 512bytes bevatten. Voor verzending van een grotere hoeveelheid data moet er een buffer structuur opgebouwd worden voor opslplitsing van deze data in meerdere APDU s. In de andere richting, van de javacar naar het android system, kan een soortgelijk strucuur geimplementeerd worden. Bij de gebruikte javacard wordt block chaining ondersteunt. Dit betekent dat één instructie APDU naar de javacard meerdere antwoord APDU s kan terug beantwoorden. Dit werkt via een uitzondering die aangeeft dat er nog meer bytes aanwezig zijn op de javacard. Die javacard zal dan zelf een voorgedëfineerde instructie oproepen. Het implementatie werkt kan beperkt worden tot een methode die door deze instrucies wordt opgeroepen Zoals bij elke implementatie komen fouten vaak voor, omdat javacard geen eenvoudige methoden heeft om moment opnames in de methode te isprecteren dient het uitzonderings mechanisme correct begrepen te zijn. Tijdens de code kunnen we een uitzondering gooien waarvan we de code zelf hebben gekozen. Hiermee kunnen we dan de reden van deze uitzondering optellen. bij ontvangngt van een APDU s ziet men dan geen 9000, wat succesvol executie betekent maar het zelfgekozen getal opgetald met de reden van de uitzondering, bijvoorbeeld een crypto-uitzondering definieren we als 0x62A0. In de crypto-uitzondering klasse wordt niet geinitialiseerde sleutel met het getal 2 aangeduid, dus als het antwoord 0x62A2 verkrijgen betekent dit een crypto-uitzondering met als reden ongeinitialiseerde sleutel. Bij het ontwerp van een applet voor javacard dienen volgende regels gevolgt te worden Gebruik bestaande algoritmes 2. Sla sesiedata op in een RAM. Operaties in het RAM geheugen zijn sneller en veiliger tegen vermogen analyses

45 4.4. Java Card 3. Sla sleutel en pincodes mogen nooit in primitieve errays opgeslagen worden maar gebruik de gespecialiseerde objecten. 4. Verwijder met gespecialiseerde methodes ongebruikte sleutels en errays met gevoelige informatie 5. Gebruik transacties om te vezekeren dat de operaties atomair zijn 6. Gebruik geen... De applet bevat volgende functionalitieten voor het verwezerlijken van de OpenPGP encytptie/decryptie op de javacard. De applet op de javacard kan plublieke sleutels inladen waarmee het sessiepakket geincrypteerd wordt. Dit sessiepakket is gemaakt volgens OpenPGP en bestaat uit de sessiesleutel voorafgegaan met symetrische algoritmenummer waarna een controlecijfer berekent wordt en achteraan wordt toegevoegd. Dit versleutelde sessiepakket wordt dan teruggestuurd naar het android systeem. Bij decryptie kan een private sleutel ingeladen worden of de private sleutel gebruikt worden die gegenereerd is op de javacard. Na decryptie wordt algoritmenummer en controlecijfer nagekeken volgens OpenPGP standaarden. De javacard bezit nu de informatie om het symetrisch algoritme uit te voeren. Met de sessiesleutel wordt het symetrische algoritme inintialiseerd. De OpenPGP buiblotheken gebruiken het symetrische algoritme in CFB mode. De mode wordt niet ondersteund door de javacard. ECB en CBC zijn wel ondersteunt. In de implementatie wordt CFB gemaakt met behulp van het ECB algoritme. CFB heef als eigenschap dat de versleutelde booschap even lang is al de originele boodschap. Dit is mogelijk omdat het laatse gebruik van het ECB algoritme afhankelijk is van de cijfertekst van de vorige blok als invoer gebruik zoals weergegeven wordt op FIGUUR... De lengte van de uitang van dit ECB algoritme is de standaard blokgrootte. De originele booschap kan een kleinere lengte hebben dan deze blokgrootte. Bij het CFB algoritme gebruikt men dan de meest sygnificate bytes van de uitgang. De OpenPGP biblotheek versleutelt de data via cipher-stream klasse. Dit geeft als extra moeilijkheid dat de te verwerken data in blokken aankomt van onbepaalde groottes. Dit is een groot contract met de encryptie met de sessiesleutel. Om dit de verwezelijken zijn er 3 methodes aanwezig. De eerste methode zorgt voor de initialisatie van het symetrisch algoritme in CFB mode. De initialisatievector wordt op dit moment aangemaakt en geencrypteerd. De tweede methode zorgt voor functionaliteit die analoog is met de uptdate functie van de ciper klasse. Deze functie aanvaard een willekeurge hoeveelheid data en produceert een output indien er genoeg data aanwezig is voor het symetrisch algoritme uit te voeren. De laatste Een pincode is ook aanwezig in de implementatie en wordt telkens gevraagd bij een bewerking die de private sleutel gebruikt. Dit is enkel bij het decrypteren van een booschap omdat handtekeningen nog niet zijn geimplementeerd. De vraag voor een pincode bij encryptie is nutteloos omdat wanneer met iets encrypteer bezit men het originele bestand. Het kan dus geen kwaad dat een persoon die over jou gsm beschikt 37

46 4. Implementatie bestanden encrypteerd. Bij handtekeningen die wel een private sleutel gebruiken is er gevaar dat documenten getekend worden met jou ideniteit. AES OCB algoritme op javacard Implementatiestrategie De Applet 38

47 Hoofdstuk 5 Resultaten 5.1 Applicatie De mogelijkheden van de applicatie worden kort samengevat: 1. Inlogsysteem waarbij gerbuikersnaam gerbuikt wordt als identificatie voor het eigen sleutelpaar 2. OpenPGP vercijfer Dropbox De volgende functionaliteiten zijn dankzij Dropbox in de implementatie aanwezig. Synchronisatie contacten Op dropbox zijn de contactpersonen met hun publieke sleutels aanwezig. Voor de beveiliging van het bestand wordt OpenPGP gebruikt met de publieke sleutel van de gebruiker zelf. Dankzij het synchronisatie algoritme, dat beschreven wordt in REF, zullen de publieke sleutels van de contactpersonen automatisch gesynchroniseerd worden tussen verschillende Android toestellen. Bij het verwijderen van de applicatie worden alle contactpersonen die bij deze applicatie behoren ook verwijdert. Het synchronisatie algoritme kan dan bij herinstallatie van de applicatie de contactpersonen terug aanmaken. Mogelijkheid om private sleutel te delen over meerder Android systemen Omdat Delen van publieke sleutel Tijdens de implementatie bleek het omslachtig te zijn de publieke sleutel via een sms te verzenden. Een sms is bepoerkt in lengte en door de grootte van de publieke sleutel wordt de informatie over meerdere sms en verdeeld wat ongebruiksvriendelijk is en duur kan uitvallen voor de gebruiker. Dropbox biedt de mogelijkheid om bestanden te delen. De implementatie stuurt nu een 39

48 5. Resultaten sms met de link naar het publieke sleutel bestand. In deze sms zit ook nog een message digest van de publieke sleutel om de integriteit hiervan na te gaan. Delen van boodschappen Hetzelde probleem als bij delen van een publieke sleutel is aanwezig. De sms bevat dus ook de link naar het vercijferde bestand. De message digest is echter niet nodig omdat het OpenPGP automatisch integriteit toevoegt bij zowel vercijfering als bij vercijfering en ondertekenen. Opslagruimte Figuur 5.1: Resultaat Dropbox. 5.2 Android Implementatie via Use Cases Het Verzenden van een Geëncrypteerd Bestand 1. Open het tabblad Encrypt 40

49 5.2. Android Implementatie via Use Cases 2. Gewenste contactpersoon selecteren, er wordt een lijst geopend van mogelijke contactpersonen waaruit eventueel meerdere personen kunnen geselecteerd worden. 3. De boodschap intypen 4. Klik op de knop Encrypt. De boodschap in het inputvenster wordt ingelezen en geëncrypteerd met de gegeneerde sessiesleutel. De publieke sleutels van de geslecteerde contactpersonen zullen elk de sessiesleutel encrypteren. Bij succesvolle encryptie zal er een boodschap verschijnen van confirmatie. 41

50 5. Resultaten 5. Selecteer de gewenste outputmethode. De applicatie gaat een intent aanmaken die voor de verwerking van de geslecteerd output methode. Het adres, telefoonnummer van de contactpersoon wordt meegegeven alook als boodschap de vercijferde input. 6. Ontvangstrapport verschijnt afhankelijk van de inputmethode Het opslaan van een gëncrypteerd bestand op dropbox 1. Open het tabblad Encrypt. 42

51 5.2. Android Implementatie via Use Cases 2. Open Browser. 3. Bestand selecteren na zoeken in de bestandsverkenner 4. Klik op de knop Encrypt. 43

52 5. Resultaten 5. Selecteer de gewenste outputmethode Save on Dropbox. 6. Confirmatie succesvolle opslag op dropbox. 7. a) Het tabblad Settings openen 44

53 5.2. Android Implementatie via Use Cases Verzenden van een publieke sleutel 1. Het tabblad Settings openen 2. Klik op Send/export Key 3. Gewenste output methode slecteren 45

54 5. Resultaten 4. Gewenste contactpersoon selecteren, er wordt een lijst geopend van mogelijke contactpersonen waaruit eventueel meerdere personen kunnen geselecteerd worden. 5. Confirmatie sms verzonden 5.3 JavaCard Het vorige hoofdstuk beschrijft de problemen en oplossingen van de implementatie van de JavaCard. Uiteindelijk is het volgende volledig geïmplementeerd. De JavaCard genereert een sessiesleutel van 256 bits voor het symmetrische algoritme, AES-256. Dit wordt expliciet opgeslagen in een tijdelijk geheugen. Met deze sessiesleutel wordt een sessiepakket gecrëerd. Het sessiepakket bestaat uit de sessiesleutel en enkele extra bytes voor conformatie met de OpenPGP standaard. Daarna wordt het vercijferd met de publieke sleutels van de geadresseerde contactpersonen. Deze In deze implementatie werd een sleutelgrootte van 2048 bits voorzien voor de publieke sleutels. We kozen deze grootte om een stap verder te gaan ten opzichte van de meest courante grootte op het moment van schrijven, namelijk 1024 bit RSA-sleutels. Het verschil in de tijdsanalyses zou hierdoor ook duidelijker moeten zijn omdat een vergroting in sleutelgrootte meer rekenwerk vergt. De s Met behulp van tijdsanalyses geven we de JavaCard resultaten weer. Deze tijdsanalyses tonen het verschil in executietijd tussen een verwerking van cryptografische algoritme enekel op droid of same met jc RSA with generated Sessionkey AES of Boodschap Android x y JavaCard z a Tabel 5.1: Tijdsanalyse (nanosec) 46