Bachelorproject Technisch Informatica. Onderzoeksverslag

Transcriptie

1 Bachelorproject Technisch Informatica Onderzoeksverslag Mark Hendrikx Olaf Schüsler 27 mei 2010

2 Inhoudsopgave 1 Inleiding 1 2 Encryptie lokale gegevens Probleem Beoordelingscriteria Mogelijke oplossingen Database Encryptie Object serializen Object serializen en versleutelen Oplossing Database-engine func tio na li teit Probleem Beoordelingscriteria Mogelijke oplossingen MyISAM InnoDB BerkeleyDB Oplossing Webtalen HTML PHP CSS JavaScript XML Transport Layer Security Opstellen van een TLS verbinding Certificaat verkrijgen Conclusie 15 A Serialization 16 i

3 Hoofdstuk 1 Inleiding Voor velen is het bachelorproject het de afsluiting van de bachelorstudie. In dit project wordt de kennis die de afgelopen jaren is verkregen, omgezet in hoogwaardige software. Om deze transitie tot stand te brengen is de kennis van de bachelor Technisch Informatica onvoldoende, er zijn immers verschillende onderwerpen die niet in de studie zijn behandeld. In dit document worden de problemen die tijdens het project ontstonden behandeld. Voor elk probleem worden verschillende oplossingen geëvalueerd. Uiteindelijk wordt aan de hand van de opgestelde criteria de beste oplossing gekozen. In hoofdstuk 2 zal de encryptie van lokale gegevens worden behandeld. Vervolgens zal in hoofdstuk 3 de keuze van de database-engine uiteen worden gezet. In hoofdstuk 4 zal een geschikte webtaal voor de applicatie worden besproken. Hierna zal in hoofdstuk 5 TLS worden behandeld. Tot slot zal voor elk probleem de gekozen oplossing worden weergegeven in hoofdstuk 6. In bijlage A is een implementatie van serialization van een object in Java gegeven. 1

4 Hoofdstuk 2 Encryptie lokale gegevens Dit hoofdstuk behandeld de encryptie van privacygevoelige informatie. Bij de initiële opdracht van het bachelorproject zou sprake zijn van de ontwikkeling van een expertsysteem wat zou functioneren met behulp van een online database. Sommige privacygevoelige gegevens zouden echter volgens het CBP niet online mogen worden opgeslagen. Versleutelde lokale opslag werd echter wel toegestaan. 2.1 Probleem Voor het realiseren van de software zullen privacygevoelige gegevens lokaal moeten worden opgeslagen. Deze gegevens mogen alleen door de gebruiker worden bekeken, en dienen niet door derden uitleesbaar te zijn. 2.2 Beoordelingscriteria Om de geschiktheid van een oplossing te bepalen worden in deze paragraaf enkele criteria besproken waaraan een oplossing moet voldoen. encoderen. De data moet binnen een paar seconden versleuteld opgeslagen kunnen worden decoderen. De data moet binnen een paar seconden ontcijfert kunnen worden veiligheid. De data moet niet binnen 50 jaar uitgelezen kunnen worden unieke sleutel. De sleutel tot gegevens moet voor elke gebruiker uniek zijn legaliteit. De opslagtechniek moet wettelijk zijn toegestaan geen extra software. Voor het proces moet geen extra software benodigd zijn 2

5 2.3. MOGELIJKE OPLOSSINGEN HOOFDSTUK 2. ENCRYPTIE LOKALE GEGEVENS 2.3 Mogelijke oplossingen In deze paragraaf worden mogelijke oplossingen voor het probleem beschreven. De oplossingen zullen behandeld worden aan de hand van de verschillende criteria zoals opgesteld in paragraaf Database Encryptie Encryptie van een lokale database lijkt een voor de hand liggende optie. Hierbij wordt de informatie in de database versleuteld aan de hand van een gedeelde sleutel [11]. Als een query wordt uitgevoerd om data op te vragen dan worden de gegevens door de databaseserver, die in dit geval lokaal draait, eerst gedecodeerd voordat ze verstuurd worden naar de gebruiker. Bij het opslaan van informatie in de database wordt de data door de server versleuteld voordat deze wordt opgeslagen. Er zijn twee mogelijke manier van opslag met elk zijn voor- en nadelen. De beoordelingsmatrix van database encryptie is weergegeven in figuur Versleutelen van individuele items in de database. Bij deze aanpak wordt elk item apart versleuteld. Dit houdt in dat bij elke update maar een item gecodeerd moet worden. Bij uitlezen hoeft ook maar een item te worden gedecodeerd. Het nadeel hiervan is echter wel dat het mogelijk is om te zien dat een bepaald item meerdere malen in de database voorkomt. Op basis hiervan zou de betekenis bepaald kunnen worden en wellicht de sleutel. 2. Versleutelen van de database als een geheel. Bij deze aanpak wordt de gehele database als een blok data behandeld. Het voordeel is dat bij encryptietechnieken zoals AES [3], het onmogelijk is om het aantal keer voorkomen van een woord te bekijken, omdat de gehele input invloed heeft op de string die als output wordt weggeschreven. Het nadeel is echter wel dat bij opvragen en updaten de gehele database wordt worden gedecodeerd, respectievelijk versleuteld [11]. Tabel 2.1: Beoordelingsmatrix database encryptie Criteria Beoordeling Beschrijving Encoderen + De eerste methode is het aantrekkelijkst voor opslag, gezien deze het minste performance verlies oplevert. Het aantal keer voorkomen van een element kan worden bepaald. Echter, in de context van de applicatie zullen elementen vaak uniek zijn. Decoderen + Zelfde reden als hierboven Veiligheid ++ Als de sleutel niet bekend is, dan wordt eenvoudig aan dit criteria voldaan. Het is namelijk mogelijk om allerlei verschillende encrypties te kiezen Unieke sleutel + Er is één gedeelde sleutel, maar de lokale database wordt door één persoon gebruikt. Dus dit vormt geen probleem Legaliteit +/- Voor 192 en 256 byte AES is een licentie vereist. Voor andere algoritmen bestaan vergelijkbare restricties Geen extra software - Voor de opslag van de data dient een database te worden geïnstalleerd De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/- 3

6 2.3. MOGELIJKE OPLOSSINGEN HOOFDSTUK 2. ENCRYPTIE LOKALE GEGEVENS Object serializen Bij veel programmeertalen, waaronder Java [1], is het mogelijk om een object te serializen. Hierbij wordt een object omgezet in een tekstuele representatie. De tekstuele representatie kan op een later tijdstip weer worden omgezet in een object. Om serialization als oplossing te beschouwen, is een java klasse geschreven die de benodigde methodes implementeert. De klasse zoals beschreven in bijlage A slaat een String ArrayList geserialized op, eenmaal met, en eenmaal zonder, encryptie. Andere objecten zijn met vergelijkbare methodes mogelijk. De beoordelingsmatrix van serialization zonder encryptie is weergegeven in figuur 2.2. Tabel 2.2: Beoordelingsmatrix object serialization Criteria Beoordeling Beschrijving Encoderen ++ Het object kan in een paar milliseconden worden omgezet in een bestand Decoderen ++ Het bestand kan in een paar milliseconden worden omgezet in een object Veiligheid - - De inhoud van het object kan direct uit worden gelezen als deze niet van te voren versleuteld is Unieke sleutel - - Iedereen kan het object (de)serializen als de structuur van object bekend is Legaliteit ++ Er zijn geen wettelijke beperkingen Geen extra software ++ Er is geen extra software benodigd De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/ Object serializen en versleutelen De zwaktes van serializen zonder encryptie zijn de gemeenschappelijke mogelijkheid to decoderen, en het nauwelijks versleutelen van de gegevens in het object. Beide zwaktes kunnen worden verbeterd door het object, alvorens het op te slaan in een bestand, te versleutelen met behulp van encryptie. In tegenstelling tot hashing, moet het object ook weer gedecodeerd kunnen worden. Echter, ieder persoon moet wel een unieke sleutel hebben. Dit kan bereikt worden door met accounts te werken, en het paswoord waarmee versleuteld wordt te baseren op de username en het paswoord. Een paswoord moet een bepaalde lengte hebben, dus eerst een hashing toegepast worden om het bestand een bepaald aantal letters te krijgen. In bijlage A staat een klasse beschreven die een String ArrayList object op kan slaan in een bestand. Hiervoor wordt AES-encryptie gebruikt, omdat deze wordt gezien als een van de sterkste beveiligingen, en een bestand zeker niet binnen 100 jaar te ontcijferen is [3]. Er is gebruik gemaakt van de 128 byte key variant, omdat 192 en 256 in sommige landen niet is toegestaan, en een aparte license vereist. De beoordelingsmatrix van serialization met encryptie is weergegeven in figuur

7 2.4. OPLOSSING HOOFDSTUK 2. ENCRYPTIE LOKALE GEGEVENS Tabel 2.3: Beoordelingsmatrix object serialization met encryptie Criteria Beoordeling Beschrijving Encoderen + Het object kan binnen een seconde worden omgezet in een bestand Decoderen + Het bestand kan binnen een seconde worden omgezet in een object Veiligheid ++ De inhoud van het object het bestand is niet uit te lezen zonder de key Unieke sleutel ++ De sleutel kan gebaseerd worden op een combinatie van de username en paswoord Legaliteit +/- Voor 192 en 256 byte AES is een licentie vereist Geen extra software ++ Er is geen extra software benodigd De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/- 2.4 Oplossing In de voorgaande paragrafen zijn verschillende oplossingen voor het probleem onderzocht. Uit de evaluatie van deze oplossingen zijn een aantal conclusies te trekken: 1. Encryptie van de database is aantrekkelijk, maar vereist extra software om de lokale op te zetten 2. Serialization zonder encryptie levert een snelle toegang tot de informatie, maar de sleutel is uniform, en de data is eenvoudig uit te lezen 3. Serialization met encryptie kost bij het wegschrijven en ophalen van de data meer tijd dan zonder encryptie, maar werkt snel genoeg. Deze oplossing vereist geen extra software Zoals weergegeven in figuur 2.4, is serialization met encryptie de beste oplossing. In de tweede versie van het programma was een lokale database echter niet meer vereist, en praktisch, omdat met een website zou worden gewerkt. Uiteindelijk is de oplossing dus niet uitgewerkt tot een deel van de applicatie. Tabel 2.4: Beoordelingsmatrix oplossingen Criteria Database Serialization Encrypted serialization Encoderen Decoderen Veiligheid Unieke sleutel Legaliteit +/- ++ +/- Geen extra software De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/- 5

8 Hoofdstuk 3 Database-engine func tio na li teit Dit hoofdstuk behandeld de keuze van de database-engine. Voor de applicatie zal data moeten worden opgeslagen in een database die voor iedereen toegankelijk is. Om deze database te realiseren moet voor elke tabel een engine zijn gedefinieerd. 3.1 Probleem De TU Delft biedt aan studenten verschillende database-engines aan [4]. Het probleem is om een engine te kiezen die voldoet aan de criteria die in de volgende paragraaf worden gesteld. De volgende database-engines, die gebruik maken van een harde schijf, en geen MERGE functionaliteit bevatten [15], worden door de TU Delft aangeboden: 1. MyISAM 2. InnoDB 3. BerkeleyDB 3.2 Beoordelingscriteria Om de geschiktheid van een oplossing te bepalen worden in deze paragraaf enkele criteria besproken waaraan een oplossing moet voldoen. Beschikbaarheid. De engine moet standaard bij MySQL worden geleverd, en er moeten indicaties zijn dat dit de komende versies zo blijft Primary key/foreign key constraints. De engine moet de mogelijkheid hebben om primary key/foreign key constraints te bekrachtigen [12]. Hierdoor is het mogelijk dat als er wat gebeurt met een record met de primary key, dat er automatisch een actie wordt ondernomen om de gerelateerde record(s), met de primary key als foreign key, te updaten. Hierdoor wordt de integriteit van de database beschermd Transacties. De engine moet werken met transacties [14], waardoor het mogelijk is voor een gebruiker om meerdere queries in een keer uit te voeren, en het resultaat te bekijken, zonder dat de database direct wordt geüpdate voor de overige gebruikers. Pas als de gebruiker het commit commando heeft uitgevoerd, worden de wijzigingen voor iedereen zichtbaar. Als bijkomend voordeel kan een transactie automatisch worden teruggedraaid 6

9 3.3. MOGELIJKE OPLOSSINGEN HOOFDSTUK 3. DATABASE-ENGINE FUNC TIO NA LI TEIT Fulltext index. De engine moet fulltext index ondersteunen [13]. Dit houdt in dat elk textveld (VARCHAR, CHAR, TEXT) wordt gezien als een veld wat een text bevat. Deze text kan bestaan uit verschillende woorden. Voor elk woord dat langer is dan drie characters wordt een speciale index aangemaakt, zodat deze snel kan worden gevonden. Met behulp van speciale queries is het mogelijk om naar een woord te zoeken dat deel is van een record. Het gezochte woord moet wel minimaal vier letters bevatten, want elke substring van drie characters of minder wordt automatisch genegeerd. Hierdoor is het mogelijk om in een grote hoeveelheid text zeer snel te zoeken 3.3 Mogelijke oplossingen In deze paragraaf wordt elke engine besproken aan de hand van de gestelde criteria in paragraaf 3.2. Om de hoeveelheid gegevens enigszins te beperken, is de vergelijking van de engines beperkt tot een bespreking van de criteria. Andere criteria worden buiten beschouwing gelaten, behalve als deze grote voor- of nadelen opleveren wat betreft het gebruik in de applicatie MyISAM MyISAM is de standaard database-engine van MySQL. MyISAM is zijn populariteit vooral te danken aan zijn eenvoudige ontwerp en uitgebreide documentatie. Wat betreft de functionaliteit doet MyISAM onder voor engines zoals InnoDB, maar de functionaliteit die wordt aangeboden sluit wel aan bij de eisen van een groot deel van de gebruikers. Naar verwachting zal MyISAM de komende jaren de standaard database blijven. Echter, met MyISAM is het niet mogelijk om primary key/foreign key constraints [12] te gebruiken. Hierdoor moet bij aanpassing van records met de primary key, de records met de foreign key met een algoritme in de applicatie worden aangepast. Voor grote databases kan dit tot onnodig complexe algoritmes in de applicatie leiden. Ook zijn transacties met MyISAM niet mogelijk [14]. Hierdoor is het onmogelijk om database bewerkingen ongedaan te laten maken door de engine. Echter, met MyISAM is het wel mogelijk om gebruik te maken van fulltext index [13]. Dit maakt MyISAM dus zeer geschikt voor databases die vooral gericht zijn op het zoeken in grote hoeveelheden tekstuele data. Tabel 3.1: Beoordelingsmatrix database-engine MyISAM Criteria Beoordeling Beschrijving Beschikbaarheid ++ MyISAM is de populairste MySQL database-engine PK/FK constraints - - De applicatie moet deze zelf forceren Transacties - - De applicatie moet zelf bijhouden hoe een verandering ongedaan worden gemaakt Fulltext index ++ MyISAM biedt standaard support voor fulltext index De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/- 7

10 3.3. MOGELIJKE OPLOSSINGEN HOOFDSTUK 3. DATABASE-ENGINE FUNC TIO NA LI TEIT InnoDB InnoDB is een van de database-engines in MySQL. InnoDB is minder populair dan MyISAM, maar levert meer functionaliteit. Historisch gezien was MyISAM sneller met de afhandeling van SELECT-statements dan InnoDB, dus had in het verleden vaak de voorkeur. Tegenwoordig is InnoDB sneller, en begint door zijn functionaliteit steeds populairder te worden. Naar verwachting zal InnoDB de komende jaren in populariteit toenemen. Met InnoDB is het mogelijk om gebruik te maken van primary key/foreign key constraints [12]. Hierdoor is het mogelijk om bij het bestaan van een persoon-tabel, en verschillende gerelateerde ondergeschikte tabellen, dat als de record van een persoon wordt verwijderd, de records in de gerelateerde tabellen ook verdwijnen. Hierdoor blijft de database consistent, zonder dat de applicatie dit zelf hoeft te forceren. Tevens is het mogelijk om met InnoDB transacties [14] uit te voeren. Hierdoor kan bijvoorbeeld een UPDATE-query worden uitgevoerd, en ziet alleen de gebruiker het resultaat. De wijzigingen worden in de database opgeslagen als de gebruiker de query commit. Ook is het mogelijk om een bewerking terug te draaien, een zogenaamde ROLLBACK. Echter, met InnoDB is het niet mogelijk om fulltext index te gebruiken [13]. Als deze functionaliteit gewenst is, dan kan een enkele tabel ook op MyISAM worden gezet, of kan elk record apart worden opgehaald en geparsed voor het gezochte woord. In dat geval zullen de primary key/foreign key constraints met die tabel wel door een applicatie moeten worden geforceerd. Tabel 3.2: Beoordelingsmatrix database-engine InnoDB Criteria Beoordeling Beschrijving Beschikbaarheid + InnoDB is een populaire MySQL database-engine PK/FK constraints ++ De constraints worden door de engine geforceerd Transacties ++ InnoDB ondersteunt transacties Fulltext index - - InnoDB ondersteunt geen fulltext index De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/ BerkeleyDB BerkeleyDB is een van de database-engines in veel versies van MySQL. Wat betreft de functionaliteit is deze beter dan MyISAM, maar minder dan InnoDB. Sinds versie van MySQL, is BerkeleyDB uit het pakket verwijderd [10]. Om geen constraints op te leggen aan de versie van MySQL op de server waarop de database komt te draaien, is besloten BerkeleyDB niet te gebruiken. 8

11 3.4. OPLOSSING HOOFDSTUK 3. DATABASE-ENGINE FUNC TIO NA LI TEIT 3.4 Oplossing In de voorgaande paragrafen zijn verschillende engines onderzocht. Uit de evaluatie van deze engines zijn een aantal conclusies te trekken: 1. MyISAM is een standaardoplossing, die in de meerderheid van de gevallen voldoet. Echter voor de applicatie zijn primary key/foreign key constraints vereist, en voor MyISAM zouden deze dan via de applicatie moeten worden geforceerd 2. InnoDB biedt scoort op bijna alle fronten maximaal. Fulltext index is in InnoDB echter niet mogelijk. In de applicatie zal niet vaak een substring van een record worden gezocht, dus het ophalen van elk record om hierachter te komen vormt geen probleem 3. BerkeleyDB wordt al enkele jaren niet meer ondersteund, en zit sinds release niet meer in het MySQL pakket Het gebruik van InnoDB voor de applicatie is aan de hand van de criteria de beste oplossing, zoals weergegeven in figuur 3.3. In deze vergelijking is BerkeleyDb buiten beschouwing gelaten, omdat hiervoor door MySQL geen support meer wordt gegeven. Tabel 3.3: Beoordelingsmatrix oplossingen Criteria MyISAM InnoDB Beschikbaarheid ++ + PK/FK constraints Transacties Fulltext index De schaal van de beoordeling loopt van - - tot ++. Neutraal wordt aangegeven met +/- 9

12 Hoofdstuk 4 Webtalen Voor dit project wordt er gebruik van een variëteit aan webtalen. Er us gekozen voor HTML5, PHP, CSS, JavaScript en XML. Om tot deze keuze te komen zijn er een aantal afwegingen gemaakt, zoals moet het programma op een server draaien, of op de computer zelf?. De verschillende afwegingen zullen hieronder worden behandeld. 4.1 HTML5 In 2007 was er een strijd over de opvolger van HTML 4. Hiervoor werd door de W3C gekozen voor XHTML en door de WHATWG voor HTML5. Deze laatste is inmiddels geaccepteerd door de W3C en is inmiddels gekozen tot de opvolger van HTML4 [17]. Voor dit project is gekozen voor HTML5. Aangezien de site waarschijnlijk langere tijd in de lucht zal moeten blijven, wordt er gebruik gemaakt van de nieuwste standaard. De reden dat er gekozen is voor HTML heeft te maken met het feit dat HTML een goed gedocumenteerde taal is, waarin eenvoudig een website te structureren is, en beide programmeurs hebben al ervaring met deze taal. 4.2 PHP Voor PHP is gekozen omdat deze taal het mogelijk maakt dynamisch websites te generen. Via PHP is het mogelijk om gegevens uit een database te lezen en deze vervolgens op de site te verwerken. Daarnaast kunnen formulieren etc. ook per direct verwerkt worden. Hierdoor is het mogelijk om direct en dynamisch met gegevens te werken. Er zit echter wel een nadeel aan PHP. Aangezien de de compiler op een server draait en niet lokaal, kunnen bewerkingen alleen gedaan worden als er een nieuwe request bij de server gedaan wordt. Een request vindt bijvoorbeeld plaats als een gebruiker de verzend-knop indrukt. Hierdoor zullen gegevens alleen verwerkt kunnen worden bij het aanroepen van een nieuwe pagina, en niet werkelijk on-the-fly. Voor de meeste situaties is dit niet nodig, maar voor bijvoorbeeld het checken van de invoer kan dit onnodig gebruik van resources opleveren. Om dit probleem te ondervangen wordt JavaScript gebruikt om PHP aan te vullen. 10

13 4.3. CSS HOOFDSTUK 4. WEBTALEN 4.3 CSS In de oudere versies van HTML bestond de mogelijkheid om de opmaak ook meteen in de HTML files te verwerken. Dit leverde echter problemen op bij hergebruik van code [2], omdat opmaakcode in de files kwam te staan. Vanwege deze reden wordt CSS gebruikt. Deze sheets bevatten de informatie voor de verschillende HTML elementen, zoals bijvoorbeeld de breedte, border-width. Door deze sheets te gebruiken hoeft in dit project maar een beperkt aantal externe stylesheet gemaakt te worden, waardoor de site een universele uitstraling heeft, en de overige programmeercode beter hergebruikt kan worden. 4.4 JavaScript Om de formulieren die gebruikt worden bij het invullen van gegevens tijdig te kunnen controleren, en directe feedback te kunnen geven aan de gebruiker, wordt gebruik gemaakt van JavaScript. Dit is een scripttaal die op de computer van de gebruiker wordt uitgevoerd. Hierdoor kunnen acties per direct worden uitgevoerd. Er kan bijvoorbeeld gekeken worden naar toetsaanslagen, en op basis daarvan acties worden ondernomen. JavaScript dient echter alleen gebruikt te worden om het gebruik van de PHP-server te verlichten. JavaScript kan namelijk worden uitgeschakeld, wat zou kunnen leiden tot beveiligingsrisico s. Deze functionaliteit zal dus voornamelijk gebruikt gaan worden voor het controleren of de invoer in een veld niet te lang is en hierover feedback teruggeven naar de gebruiker. 4.5 XML Voor sommige gegevens zal geen gebruik gemaakt kunnen, of hoeven, worden van de database. In dit soort gevallen kan gebruik gemaakt worden van XML files. Dit zijn kleine bestanden die in principe in plain text op de server staan. De informatie die in deze file staan zijn bijvoorbeeld universiteiten die meedoen aan het project en hun logo s etc. Het voordeel van XML in vergelijking met plain text, is dat XML een vastgestelde structuur heeft. Elk element krijgt een bepaalde tag mee. Hierdoor is het eenvoudiger, en minder foutgevoelig, om data terug te vinden. Men kan immers nieuwe informatie toevoegen, zonder dat de structuur verloren gaat. 11

14 Hoofdstuk 5 Transport Layer Security Bij het gebruik van de applicatie, zal privacygevoelige informatie worden verzonden door de gebruiker. Om te voorkomen dat deze in verkeerde handen valt, is het noodzakelijk dat de verbinding beveiligd is. Transport Layer Security (TLS) biedt hierbij de uitkomst. TLS is de opvolger van Secure Socket Layer (SSL). Met behulp van TLSl is het mogelijk om een beveiligde verbinding op te stellen tussen een client en server met behulp van cryptographie. Voor encryptie wordt gebruik gemaakt van het RSA algoritme met een key van 1024 of 2048 bit [21]. Bij SSL was het alleen mogelijk dat de server zich valideerde met behulp van een certifaat [22]. De client werd echter niet gevalideerd. In TLS zijn zowel verbindingen met, en zonder, clientverificatie mogelijk. In onze applicatie hoeft alleen de server te worden gevalideerd. 5.1 Opstellen van een TLS verbinding Om een TLS, of SSL, verbinding te gebruiken, moet deze eerst worden opgesteld. Als de verbinding eenmaal is gemaakt, dan is alle data die wordt verzonden via de verbinding automatisch versleuteld [19]. Het opstellen van de verbinding bestaat uit vier fases. Hieronder wordt een vereenvoudigde versie van het protocol besproken. Hierbij is de resumed handshake [9] weggelaten, en wordt er vanuit gegaan dat alleen de server geauthenticeerd hoeft te worden, en de server voorkeur heeft voor een beveiligde en geauthenticeerde verbinding. 1. Onderhandelingsfase Hierbij stuurt de client een zogenaamd ClientHello bericht [6] met de volgende informatie: Hoogste versie van TLS die ondersteund wordt door de client Een lijst van CipherSuites [8]. Een cipher suite is combinatie van encryptie, authenticatie, en een algoritme om een bericht te valideren. Mogelijke compressie-algoritmen. De server stuurt een ServerHello bericht [6] met zijn voorkeur voor de items in de ClientHello message. De server zendt een certificaat, dat geverifieerd is via een keten van geauthoriseerde websites, om zijn identiteit aan te tonen. 12

15 5.2. CERTIFICAAT VERKRIJGEN HOOFDSTUK 5. TRANSPORT LAYER SECURITY De server zent een ServerHelloDone bericht [6] om aan te tonen dat de onderhandeling voorbij is. De client antwoord met een pakket met een PreMasterSecret [6], public key, of niets, afhankelijk van de gekozen cipher. De PreMasterSecret wordt gebruikt door de client en server om eenzelfde key af te leiden, zonder dat deze daadwerkelijk verstuurd wordt. Om deze key af te leiden wordt het Diffie-Hellman algoritme [5] gebruikt. 2. Client zendt ChangeCipherSpec Het verzenden van de ChangeCipherSpec [7] houdt in dat alles vanaf dat moment geauthenticeerd en versleuteld verloopt. De client verzendt een geauthenticeerd en versleuteld bericht met een hash en een code om het bericht te valideren (Message Authentication Code [7]) op basis van de vorige berichten van de handshake. De server ontvangt het bericht en probeert het bericht te ontcijferen. Vervolgens worden de hash en MAC geverifieerd. Als de server hierin niet slaagt, dan is er iets fout gegaan tijdens het opstellen van de connectie, en zal dus opnieuw moeten worden opgesteld door de client. 3. Server zendt ChangeCipherSpec Hierbij worden dezelfde stappen als bij Client zendt ChangeCipherSpec [7] uitgevoerd, alleen zijn de rol van de client en server omgedraaid. 4. Verbinding opgesteld Beide partijen zijn op de hoogte dat er een beveiligde, en geauthenticeerde, verbinding is opgesteld. De communicatie die vervolgens plaats zal vinden zal automatisch geauthenticeerd en beveiligd verlopen. De applicatie hoeft na het opstellen van de connectie dus geen speciale handelingen uit te voeren voor het verzenden van informatie. 5.2 Certificaat verkrijgen Het certificaat wat bij SSL en TLS gebruikt wordt, moet van een betrouwbare bron komen. Het idee achter SSL en TLS is dat er enkele servers zijn die inherent betrouwbaar zijn, de zogenaamde certificate roots [20]. Deze certificate roots verkopen het recht om certificaten uit te delen aan andere servers. Deze servers verkopen op hun beurt ook weer de rechten, of de certificaten zelf. Het gevolg is een keten van servers die elkaar verifiëren. Hoe verder men van de root af gaat, hoe onbetrouwbaarder de server. Een certificaat is essentieel voor het opstellen van een SSL of TLS verbinding, omdat deze aantoont dat de site betrouwbaar is. Het is mogelijk om zelf een certificaat te maken, zogenaamde self-signed certificaten [16], maar dit is equivalent aan een persoon die van zichzelf zegt dat hij betrouwbaar is. Het gevolg is dat de gebruikers van de website bij het opstarten van de site een melding krijgen dat het certificaat niet betrouwbaar is. Als een SSL of TLS website door een persoon wordt bezocht, dan controleert de browser van deze persoon de keten van certificaten. Dit is mogelijk, omdat browsers initieel de adressen van vele certificate roots bezitten, maar ook omdat de server de certificaten van alle bovenstaande servers dient te bevatten. Het gevolg is een web van betrouwbare servers. 13

16 5.2. CERTIFICAAT VERKRIJGEN HOOFDSTUK 5. TRANSPORT LAYER SECURITY Voor de applicatie is een SSL of TLS verbinding vereist, omdat paswoorden worden verzonden, en de encryptie serverside plaatsvindt met PHP (SHA1). Het is geen probleem als een paswoord van een kandidaat wordt verkregen, gezien de mogelijkheden van de kandidaat beperkt zijn, maar het verkrijgen van een paswoord van een commissie kan grote schade veroorzaken. Na het vergelijken van verschillende aanbieders van certificaten, waaronder VeriSign, GoDaddy, en Comodo, is besloten dat er een keuzemenu moet worden opgesteld, zodat de partners van het project kunnen selecteren. Echter, aan de hand van commentaar op het blog, bleek dat de SURFnet aangesloten is bij Terena, en het recht heeft om abonnementen op het aanvragen van certificaten te verstrekken [18]. De TU Delft is hierbij ook aangesloten, waardoor deze voor een relatief klein bedrag per maand, onbeperkt certificaten mag aanvragen. Daarom is geprobeerd een testserver via de TU Delft aan te vragen. Dit bleek echter niet mogelijk, omdat een certificaat voor slechts een paar maanden niet gebruikelijk is. Momenteel moet nog bepaald worden waar de server uiteindelijk komt te draaien, echter als men wil profiteren van de SURFnet-regeling, dan zal dit moeten bij SURFnet zelf, of bij een van zijn leden (de meeste universiteiten en hogescholen in Nederland). 14

17 Hoofdstuk 6 Conclusie Bij het creëren van de applicatie traden verschillende problemen op. In dit document zijn de verschillende mogelijke oplossingen geanalyseerd. In tabel 6.1 worden de verschillende problemen en de gekozen oplossingen weergegeven. Probleem Encryptie lokale gegevens Tabel 6.1: Gekozen oplossing voor elk probleem Oplossing Encrypted serialization, hierbij wordt een object versleuteld met een key die gebaseerd is op de loginname en paswoord, en vervolgens opgeslagen op de harde schijf. Het object kan opnieuw bekeken worden door deze te decoderen met behulp van de sleutel Database-engine InnoDB, deze database-engine is de enige engine die niet deprecated is in het MySQL pakket aan de TU Delft, en PK/FK constraints mogelijk maakt. Ook kan gebruik gemaakt worden van transacties en is de engine populair Webtalen Om correct te functioneren met toekomstige browsers, zal gebruik worden gemaakt van standaard webtalen HTML5, PHP, CSS, JavaScript en XML Transport Layer Security TLS zal gebruikt worden om een beveiligde verbinding op te stellen. Hiervoor zal een certificaat moeten worden aangevraagd 15

18 Bijlage A Serialization 1 import java. i o. ByteArrayOutputStream ; 2 import java. i o. F i l e ; 3 import java. i o. FileInputStream ; 4 import java. i o. FileOutputStream ; 5 import java. i o. IOException ; 6 import java. i o. ObjectInputStream ; 7 import java. i o. ObjectOutputStream ; 8 import java. s e c u r i t y. InvalidKeyException ; 9 import java. s e c u r i t y. NoSuchAlgorithmException ; 10 import java. u t i l. ArrayList ; 11 import javax. crypto. Cipher ; 12 import javax. crypto. NoSuchPaddingException ; 13 import javax. crypto. spec. SecretKeySpec ; / 16 Code i s f o r t e s t i n g and e x p l i n a t i o n purposes, so no s p e c i a l a t t e n t i o n 17 was paid to t h e s t r u c t u r e. 18 Mark Hendrikx 20 / 21 public class Main { / 24 Main c l a s s w r i t t e n to t e s t a l l t h e o b j e c t s e r i a l i z a t i o n methods. 25 These t e s t are f o c u s s e d on an ArrayList<String > o b j e c t, but i t could 26 have been any t y p e o f o b j e c t. 27 / 28 public s t a t i c void main ( S t r i n g [ ] a r g s ) throws IOException { 29 ArrayList<String > t e s t Array = new ArrayList<String >(); 30 t e s t A r r a y. add ( t e s t 1 ) ; 31 t e s t A r r a y. add ( t e s t 2 ) ; 32 t e s t A r r a y. add ( t e s t 3 ) ; 33 S t r i n g f i l e n a m e = t e s t. t x t ; System. out. p r i n t l n ( Test : o b j e c t > f i l e ) ; 36 s e r i a l i z e A n d W r i t e T o F i l e ( testarray, f i l e n a m e ) ; 37 F i l e t e s t = new F i l e ( t e s t. t x t ) ; 16

19 BIJLAGE A. SERIALIZATION 38 i f ( t e s t. e x i s t s ( ) ) 39 System. out. p r i n t l n ( PASS\n ) ; 40 else 41 System. out. p r i n t l n ( FAIL\n ) ; System. out. p r i n t l n ( Test : f i l e > o b j e c t ) ; 44 ArrayList<String > testarray2 = u n s e r i a l i z e F r o m F i l e ( f i l e n a m e ) ; 45 i f ( testarray2. e q u a l s ( t e s tarray ) ) 46 System. out. p r i n t l n ( PASS\n ) ; 47 else 48 System. out. p r i n t l n ( FAIL\n ) ; byte [ ] bytes = s e r i a l i z e T o B y t e s ( t estarray ) ; 51 byte [ ] bytes2 = null ; 52 System. out. p r i n t l n ( Test : o b j e c t > bytearray > encrypt AES > + 53 decrypt AES ) ; 54 try { 55 bytes2 = dodecrypt ( docrypto ( bytes, t e s t t e s t t e s t t e s t ), 56 t e s t t e s t t e s t t e s t ) ; 57 } catch ( Exception ex ){ ex. printstacktrace ( ) ; } 58 i f (new S t r i n g ( bytes ). e q u a l s (new S t r i n g ( bytes2 ) ) ) 59 System. out. p r i n t l n ( PASS! \ n ) ; 60 else 61 System. out. p r i n t l n ( FAIL! \ n ) ; ArrayList<String > testarray3 = ( ArrayList<String >)toobject ( bytes2 ) ; 64 System. out. p r i n t l n ( Test : o b j e c t > bytearray > encrypt AES > + 65 decrypt AES > o b j e c t ) ; 66 i f ( testarray3. e q u a l s ( t e s tarray ) ) 67 System. out. p r i n t l n ( PASS! \ n ) ; 68 else 69 System. out. p r i n t l n ( FAIL! \ n ) ; 70 } / 73 Method t h a t u n s e r i a l i z e s an o b j e c t t h a t i s read from a 74 s u p p l i e d f i l e n a m e. The method i s w r i t t e n so t h a t i t r e t u r n 75 an ArrayList<String >, but i t could have been any t y p e o f o b j e c t. f i l e n a m e name o f t h e s u p p l i e d t e x t f i l e u n s e r i a l i z e d ArrayList<String > 78 / 79 public s t a t i c ArrayList<String > u n s e r i a l i z e F r o m F i l e ( S t r i n g f i l e n a m e ) 80 { 81 ArrayList<String > l i s t = new ArrayList<String >(); 82 try { 83 FileInputStream f i n = new FileInputStream ( f i l e n a m e ) ; 84 ObjectInputStream o i s = new ObjectInputStream ( f i n ) ; 85 l i s t = ( ArrayList<String >) o i s. readobject ( ) ; 86 o i s. c l o s e ( ) ; 87 } catch ( Exception e ) { e. printstacktrace ( ) ; } 88 return l i s t ; 89 } 90 17

20 BIJLAGE A. SERIALIZATION 91 / 92 S e r i a l i z e a ArrayList o b j e c t t h a t i s g i v e n as input, and 93 w r i t e t h e output to f i l e. The A r r a y l i s t i s used as an example, 94 but i t c ould have been any t y p e o f o b j e c t. l i s t t h e l i s t t h a t i s s e r i a l i z e d f i l e n a m e name o f t h e f i l e to which t h e s e r i a l i z e d o b j e c t 97 i s w r i t t e n IOException 99 / 100 public s t a t i c void s e r i a l i z e A n d W r i t e T o F i l e ( ArrayList<String > l i s t, 101 S t r i n g f i l e n a m e ) throws IOException 102 { 103 FileOutputStream f o u t = null ; 104 try { 105 f o u t = new FileOutputStream ( f i l e n a m e ) ; 106 } catch ( Exception e ) { e. printstacktrace ( ) ; } ObjectOutputStream oos = null ; 109 try { 110 oos = new ObjectOutputStream ( f o u t ) ; 111 } catch ( Exception e ) { e. printstacktrace ( ) ; } oos. w r i t e O bject ( l i s t ) ; 114 oos. c l o s e ( ) ; 115 } / 118 This method s e r i a l i z e s an o b j e c t an c o n v e r t s i t i n t o raw b y t e s. l i s t t h e l i s t t h a t i s s e r i a l i z e d t h e l i s t s e r i a l i z e d and c o n v e r t e d i n t o b y t e s IOException 122 / 123 public s t a t i c byte [ ] s e r i a l i z e T o B y t e s ( ArrayList<String > l i s t ) 124 throws IOException 125 { 126 ByteArrayOutputStream f o u t = null ; 127 try { 128 f o u t = new ByteArrayOutputStream ( ) ; 129 } catch ( Exception e ) { e. printstacktrace ( ) ; } ObjectOutputStream oos = null ; 132 try { 133 oos = new ObjectOutputStream ( f o u t ) ; 134 } catch ( Exception e ) { e. printstacktrace ( ) ; } oos. w r i t e O bject ( l i s t ) ; 137 oos. c l o s e ( ) ; 138 return f o u t. tobytearray ( ) ; 139 } / 142 Encrypt a g i v e n b y t e a r r a y. message what i s to be encrypted 18

21 BIJLAGE A. SERIALIZATION password t h e key used to encrypt t h e message encrypted message NoSuchAlgorithmException InvalidKeyException 148 / 149 public s t a t i c byte [ ] docrypto ( byte [ ] message, S t r i n g password ) 150 throws NoSuchAlgorithmException, InvalidKeyException { // Generate a key, t h i s a random key. Use 128 b y t e as key, 153 // because 192 and 256 are not a l l o w e d everywhere. 154 // h t t p :// j a v a. sun. com/ d e v e l o p e r / 155 // t e c h n i c a l A r t i c l e s / S e c u r i t y /AES/AES v1. html 156 byte [ ] raw = null ; 157 i f ( password. l e n g t h ()==16){ 158 raw = password. getbytes ( ) ; } 159 else { 160 System. out. p r i n t l n ( F a ilure, password should be 16 l e t t e r s. ) ; 161 return null ; 162 } // SecretKeySpec i s a c o n t a i n e r o b j e c t to s t o r e t h e key 165 // combined with a t y p e o f e n c r y p t i o n 166 SecretKeySpec skeyspec = new SecretKeySpec ( raw, AES ) ; // I n s t a n t i a t e t h e c i p h e r 169 Cipher c i p h e r = null ; 170 try { 171 c i p h e r = Cipher. g e t I n s t a n c e ( AES ) ; 172 } catch ( NoSuchPaddingException ex ) { ex. printstacktrace ( ) ; } c i p h e r. i n i t ( Cipher.ENCRYPT MODE, skeyspec ) ; byte [ ] encrypted = null ; 177 try { encrypted = c i p h e r. dofinal ( message ) ; } 178 catch ( Exception ex ) { ex. printstacktrace ( ) ; } return encrypted ; 181 } / 184 Decrypt a message s t o r e d in a b y t e a r r a y g i v e n t h e key. encryptedmessage t h e message t h a t i s encrypted password t h e password used to d e c r y p t t h e message t h e d e c r y p t e d message 188 / 189 public s t a t i c byte [ ] dodecrypt ( byte [ ] encryptedmessage, S t r i n g password ) 190 { 191 byte [ ] raw = null ; 192 i f ( password. l e n g t h ()==16){ 193 raw = password. getbytes ( ) ; } 194 else { 195 System. out. p r i n t l n ( F a ilure, password should be 16 l e t t e r s. ) ; 196 return null ; 19

22 BIJLAGE A. SERIALIZATION 197 } SecretKeySpec skeyspec = new SecretKeySpec ( raw, AES ) ; 200 Cipher c i p h e r = null ; 201 try { c i p h e r = Cipher. g e t I n s t a n c e ( AES ) ; 202 } catch ( Exception ex ) { ex. printstacktrace ( ) ; } try { c i p h e r. i n i t ( Cipher.DECRYPT MODE, skeyspec ) ; 205 } catch ( Exception ex ) { ex. printstacktrace ( ) ; } byte [ ] o r i g i n a l = null ; 208 try { o r i g i n a l = c i p h e r. dofinal ( encryptedmessage ) ; 209 } catch ( Exception ex ) { ex. printstacktrace ( ) ; } return o r i g i n a l ; 212 } / 215 Method to c o n v e r t a b y t e a r r a y to an o b j e c t b y t e s b y t e a r r a y t h a t s y m b o l i z e s an o b j e c t o b j e c t c r e a t e d from b y t e a r r a y 218 / 219 public s t a t i c Object toobject ( byte [ ] bytes ){ 220 Object o b j e c t = null ; 221 try{ 222 o b j e c t = new java. i o. ObjectInputStream (new 223 java. i o. ByteArrayInputStream ( bytes ) ). readobject ( ) ; 224 }catch ( Exception ex ){ ex. printstacktrace ( ) ; } return o b j e c t ; 227 } 228 } 20

23 Literatuur [1] Java API. Discover the secrets of the java serialization api. developer/technicalarticles/programming/serialization/. Geraadpleegd op: 21 februari [2] A. Clarke and M.E. Holzschlag. Transcending CSS: The Fine Art of Web Design (Voices That Matter). New Riders Publishing Thousand Oaks, CA, USA, [3] Joan Daemen and Vincent Rijmen. The design of Rijndael: AES - the advanced encryption standard (p 1-8) [4] EWI. Aanmaken van een sql database via de tu delft. Geraadpleegd op: 21 februari [5] RSA laboratories. What is diffie-hellman? Geraadpleegd op: 26 maart [6] Tony McGregor. Secure socket layer. articles/ssl/ssl.html. Geraadpleegd op: 26 maart [7] Till Meyer. About ssl/tls. security/students/ss8a/ssltls.html. Geraadpleegd op: 26 maart [8] MSDN. Cipher suites in schannel. aa374757(vs.85).aspx. Geraadpleegd op: 26 maart [9] MSDN. Tls handshake protocol. aa380513(vs.85).aspx. Geraadpleegd op: 26 maart [10] MySQL News. Changes in mysql (24 october 2006). refman/5.1/en/news html. Geraadpleegd op: 26 mei [11] Oracle. Database encryption in oracle9i. oracle/pdf/f5crypt.pdf. Geraadpleegd op: 20 februari [12] MySQL Reference. Foreign key constraints. innodb-foreign-key-constraints.html. Geraadpleegd op: 17 maart [13] MySQL Reference. Full-text search functions. en/fulltext-search.html. Geraadpleegd op: 17 maart [14] MySQL Reference. The innodb transaction model and locking. doc/refman/5.1/en/innodb-transaction-model.html. Geraadpleegd op: 17 maart

24 LITERATUUR LITERATUUR [15] MySQL Reference. The merge storage engine. en/merge-storage-engine.html. Geraadpleegd op: 17 maart [16] SIAL. Openssl self-signed test certificates. self-signed/. Geraadpleegd op: 27 maart [17] Michael Smith. Html5 and xhtml2. html5-and-xhtml2. Geraadpleegd op: 26 mei [18] Surfnet. Aanmeldproces surfcertificaten. authenticatie/pages/aanmeldensurfcertificate.aspx. Geraadpleegd op: 27 maart [19] Andrew Tanenbaum. Computer Networks. Prentice Hall Professional Technical Reference, [20] Microsoft TechNet. Microsoft root certificate program. en-us/library/cc aspx. Geraadpleegd op: 27 maart [21] Microsoft TechNet. Tls/ssl cryptographic enhancements. com/en-us/library/cc766285(ws.10).aspx. Geraadpleegd op: 26 maart [22] Microsoft TechNet. What is tls/ssl? cc784450(ws.10).aspx. Geraadpleegd op: 26 maart