Internetbeveiliging zonder privacycompromissen?

Universiteit Antwerpen Departement Wiskunde-Informatica

2001-2002

Internetbeveiliging zonder privacycompromissen? Andy Zaidman

Proefschrift ingediend tot het behalen van de graad van Licentiaat in de Wetenschappen.

Promotor: Prof. Dr. Serge Demeyer Begeleider: Bernard De Ruyck

Internetbeveiliging zonder privacycompromissen? Andy Zaidman

31 mei 2002

II

Woord van dank

Een eindwerk maken is een heel karwei en de afgelopen maanden hebben een heleboel mensen me hierbij enorm geholpen. Mensen die me een steuntje in de rug hebben gegeven wanneer ik er behoefte aan had en die nu zeker een schouderklopje verdienen. Ik wil mijn promotor, Professor Serge Demeyer, bedanken voor me op het goede pad te zetten en voor de lange babbels die me altijd terug op weg hebben geholpen. Ook Bernard De Ruyck en de mensen van Kava verdienen een bedankje voor de goede ontvangst en de mogelijkheden die ze Bart, Kris en mezelf hebben gegeven tijdens de stage. Mijn moeder en vader, Marion en Serge: alle lof voor jullie eindeloos geduld de laaste maanden. Jullie zijn ongelofelijk, echt waar! Mijn vriendin Wendy verdient een pluim: ze heeft ervoor gezorgd dat ik me goed in mijn vel voel en heeft me gestimuleerd om steeds weer net dat beetje verder te gaan in mijn thesis. Al mijn medestudenten en Kris, jij in het bijzonder, bedankt voor alle tips. Bedankt iedereen!

III

Inhoudstafel

Abstract.................................................................................................................................................. 1 Hoofdstuk 1 Inleiding............................................................................................................................ 2 1.1 Inleiding................................................................................................................................ 2 1.2 Het algemene beeld ............................................................................................................. 3 1.2.1 De situatie ............................................................................................................ 3 1.2.2 Mogelijke consequenties...................................................................................... 3 1.2.3 Wordt beveiliging als cruciaal ervaren? ............................................................... 4 1.3 Een haalbaarheidsstudie ..................................................................................................... 4 1.3.1 De omgeving ........................................................................................................ 4 1.3.2 De stage............................................................................................................... 5 1.3.3 De studie zelf ....................................................................................................... 5 1.4 De thesis .............................................................................................................................. 6 1.5 Een aantal inleidende begrippen ......................................................................................... 6 1.5.1 Privacy ................................................................................................................. 6 1.5.2 Beveiliging............................................................................................................ 6 Hoofdstuk 2 Ingrediënten voor veilige communicatie ...................................................................... 8 2.1 Inleiding................................................................................................................................ 8 2.2 Doel van beveiliging ............................................................................................................. 9 2.3 Encryptie gedecrypteerd .................................................................................................... 10 2.3.1 Inleiding.............................................................................................................. 10 2.3.2 Symmetrische encryptie..................................................................................... 11 2.3.3 Asymmetrische encryptie................................................................................... 13 2.3.4 Symmetrisch versus asymmetrisch ................................................................... 14 2.4 Message digest .................................................................................................................. 15 2.5 Digitale handtekening ........................................................................................................ 15 2.6 Message Authentication Code (MAC)................................................................................ 16 2.7 Een overzicht van de elementaire bouwstenen ................................................................. 17 Hoofdstuk 3 Technologie-overzicht .................................................................................................. 19 3.1 Inleiding.............................................................................................................................. 19 3.2 Secure Socket Layer (SSL) ............................................................................................... 20 3.2.1 Inleiding.............................................................................................................. 20 3.2.2 Secure Socket Layer.......................................................................................... 21 3.2.3 Private Communication Technology .................................................................. 21 3.2.4 Transport Layer Security.................................................................................... 21 3.2.5 Aanverwante protocollen ................................................................................... 21 3.2.6 Gebruiksscenario ............................................................................................... 22 3.2.7 SSL getoetst....................................................................................................... 23 3.3 Secure Electronic Transaction (SET)................................................................................. 24 3.3.1 Inleiding.............................................................................................................. 24 3.3.2 Gebruiksscenario ............................................................................................... 24

IV

3.3.3 SET getoetst ...................................................................................................... 25 3.4 Secure HTTP (S-HTTP) ..................................................................................................... 25 3.4.1 Inleiding.............................................................................................................. 25 3.4.2 Technisch........................................................................................................... 25 3.4.3 Afwegingen ........................................................................................................ 26 3.4.4 HTTP-S getoetst ................................................................................................ 26 3.5 IP Secure Protocol (IPSec) ................................................................................................ 27 3.5.1 Inleiding.............................................................................................................. 27 3.5.2 Structuur van IPSec ........................................................................................... 27 3.5.3 Security Association (SA) .................................................................................. 27 3.5.4 Sleutelmanagement en connectieparameters ................................................... 28 3.5.5 Authentication Header ....................................................................................... 28 3.5.6 Encapsulating Security Payload (ESP).............................................................. 29 3.5.7 Tunnel modus .................................................................................................... 29 3.5.8 IP Secure getoetst ............................................................................................. 30 3.6 Conclusie ........................................................................................................................... 31 Hoofdstuk 4 Inleiding tot Secure Socket Layer (SSL)..................................................................... 32 4.1 Inleiding.............................................................................................................................. 32 4.2 Handshake ......................................................................................................................... 34 4.2.1 Algemeen ........................................................................................................... 34 4.2.2 Downgrade to export.......................................................................................... 36 4.2.3 Replay attack ..................................................................................................... 36 4.3 SSL Record Protocol ......................................................................................................... 36 4.3.1 Algemeen ........................................................................................................... 36 4.3.2 Truncatie aanval ................................................................................................ 37 4.3.3 Replay aanval .................................................................................................... 38 4.4 Sleutel-afleidingsprincipes ................................................................................................. 38 4.5 Even recapituleren… ......................................................................................................... 40 4.6 Sessies hernemen ............................................................................................................. 40 4.6.1 Sessies versus connecties................................................................................. 40 4.6.2 In de praktijk....................................................................................................... 40 4.7 Client authenticatie............................................................................................................. 41 Hoofdstuk 5 SSL onder de loep genomen........................................................................................ 43 5.1 Inleiding.............................................................................................................................. 43 5.2 Wat verstaan we onder performantie van een beveiligingsprotocol? ................................ 44 5.2.1 Het netwerk ........................................................................................................ 44 5.2.2 De eindstations .................................................................................................. 45 5.3 Performantie van de handshake ........................................................................................ 46 5.3.1 Simpele handshake ........................................................................................... 46 5.3.2 Sessie hernemen handshake ............................................................................ 47 5.3.3 Handshake met client authenticatie ................................................................... 48 5.3.4 Overzicht ............................................................................................................ 49 5.4 Gegevenstransfer............................................................................................................... 49 5.5 Invloed van het netwerk ..................................................................................................... 50 5.5.1 Theoretisch standpunt ....................................................................................... 50 5.5.2 Het algoritme van Nagle .................................................................................... 51 5.6 Reële situatie ..................................................................................................................... 53 5.7 Wat weten we over beveiliging? ........................................................................................ 55 5.8 Veiligheid van de handshake ............................................................................................. 55 5.8.1 Ciphersuite rollback of downgrade to export aanvallen..................................... 56 5.8.2 ChangeCipherSpec wordt niet opgenomen in de MAC ............................... 57 5.9 Authenticatie: het Principe van Horton............................................................................... 57 5.9.1 Het record protocol ............................................................................................ 58 5.9.2 De hanshake: het ChangeCipherSpec bericht ............................................... 58 5.9.3 “Hortoniaans” genoeg? ...................................................................................... 59 5.10 Veiligheid van de gegevenstransfer................................................................................. 59 5.10.1 Luistervinken .................................................................................................... 59 5.10.2 Verkeersanalyse .............................................................................................. 60 5.10.3 Replay aanvallen ............................................................................................. 60

V

5.11 Halen we de vooropgestelde criteria?.............................................................................. 61 5.11.1 Performantie..................................................................................................... 61 5.11.2 Beveiliging........................................................................................................ 61 Hoofdstuk 6 Publieke Sleutel Infrastructuur .................................................................................... 62 6.1 Inleiding.............................................................................................................................. 62 6.2 Digitale certificaten............................................................................................................. 62 6.3 Certificaat Authoriteiten...................................................................................................... 65 6.4 Certificaat revocatie ........................................................................................................... 66 6.4.1 Certificate Revocation List (CRL)....................................................................... 67 6.4.2 CRL’s partitioneren ............................................................................................ 68 6.4.2.1 Delta Certificate Revocation List (Delta-CRL) ................................................ 68 6.4.2.2 CRL Distribution Points (CDP)........................................................................ 68 6.4.3 Online Certificate Status Protocol (OCSP) ........................................................ 69 6.4.4 Nieuwe mechanismen........................................................................................ 70 6.5 Conclusie ........................................................................................................................... 70 Hoofdstuk 7 Een kwestie van privacy............................................................................................... 71 7.1 Inleiding.............................................................................................................................. 71 7.2 Het kader............................................................................................................................ 72 7.2.1 Juridisch ............................................................................................................. 72 7.2.2 Zelfregulering ..................................................................................................... 72 7.2.3 De situatie in België ........................................................................................... 73 7.3 De keerzijde van digitale certificaten ................................................................................. 73 7.4 Privacy kwesties................................................................................................................. 74 7.5 In een ideale wereld… ....................................................................................................... 76 7.5.1 Anonimiteit ......................................................................................................... 76 7.5.2 Onverenigbaarheid ............................................................................................ 76 7.6 Integratie met smartcards .................................................................................................. 77 7.6.1 Smartcards......................................................................................................... 77 7.6.2 Smartcards integreren met software-oplossingen ............................................. 79 7.7 Privacy: welles of nietes?................................................................................................... 79 Hoofdstuk 8 Conclusie ....................................................................................................................... 80 Appendix A Performantiegegevens van cryptografische algoritmen ........................................... 82 A.1 Algemeen........................................................................................................................... 82 A.2 Performantie van symmetrische algoritmen ...................................................................... 83 A.3 Performantie van asymmetrische algoritmen .................................................................... 85 A.4 Performantie van message digest algoritmen ................................................................... 86 A.5 Opmerkingen ..................................................................................................................... 87 Appendix B SSL traces....................................................................................................................... 88 B.1 Algemeen........................................................................................................................... 88 B.2 Traces................................................................................................................................ 89 B.2.1 Simpele SSL handshake ................................................................................... 89 B.2.2 Handshake d.m.v. session resumption ............................................................. 91 B.2.3 SSL handshake met client authenticatie ........................................................... 92 Appendix C Beveiliging voor de IT manager.................................................................................... 95 C.1 Algemeen .......................................................................................................................... 95 C.2 Verschillen tussen regio’s.................................................................................................. 96 C.3 Verschillen per industrie .................................................................................................... 96 C.4 Privacy............................................................................................................................... 97 C.5 Beveiliging in het kader van e-business............................................................................ 97 C.6 Informatiebeveiliging: een “top issue”................................................................................ 97 Bibliografie .......................................................................................................................................... 99 Lijst van figuren ................................................................................................................................ 101 Aantekeningen .................................................................................................................................. 103

VI

Abstract

De huidige trend van verhoogde interconnectiviteit tussen individuen en bedrijven onderling enerzijds en tussen beide groepen anderzijds, heeft het elektronische berichtenverkeer de afgelopen jaren sterk doen stijgen. Parallel neemt de hoeveelheid privacygevoelige gegevens die over het Internet stroomt, enorm toe. Deze thesis bekijkt een aantal hedendaagse beveiligingstechnologieën: zo wordt Secure Socket Layer (SSL) getest op het gebied van performantie en geanalyseerd op mogelijke zwaktepunten voor hacks. Als tegengewicht wordt gekeken wat de mogelijke consequenties zijn van het overgebruik van een certificaatgebaseerd identificatiemechanisme met betrekking tot de privacy van de gebruikers van de infrastructuur.

1

Hoofdstuk 1 Inleiding “The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it.” — E. Hubbard

1.1 Inleiding De oorsprong van het Internet gaat terug tot 1968. Het Advanced Research Projects Agency (ARPA), een onderdeel van het Amerikaanse Department of Justice, liet onderzoek doen naar een netwerk dat communicatie zou blijven mogelijk maken als een aantal knooppunten verwoest zouden worden bij een (nucleaire) oorlog. In 1969 waren er welgeteld 4 computers met elkaar verbonden d.m.v. dit netwerk dat toen de naam ARPANET kreeg. Tijdens de jaren ’70 en ’80 werd het netwerk voornamelijk gebruikt voor militaire en academische doeleinden, het aantal gebruikers steeg gestaag, maar de grote doorbraak kwam er pas in de jaren 1990. In 1992, toen het Internet werd vrijgegeven voor het grote publiek, begon het aantal gebruikers explosief te stijgen. Sinds het begin van de jaren negentig is de manier waarop mensen het Internet beschouwen drastisch veranderd: van een puur informatief netwerk waar enkel techneuten hun weg op vinden tot een open forum dat voor iedereen toegankelijk is. Vandaag de dag wordt Internet gebruikt voor ontspanning, om in contact te blijven met vrienden en kennissen via email, voor het opzoeken van informatie, voor zakendoen, … Ondertussen zijn mensen die zich online wagen of bedrijven die hun goederen en diensten via het Internet verkopen al lang geen pioniers meer. Totzelfs het kopen van boeken en CD’s via Internet raakt ingeburgerd en ook het kopen van veel duurdere artikels begint door te breken. Bedrijven zien meer en meer de mogelijkheden van het Internet in: niet alleen proberen ze hun producten via het Internet te verkopen, hun informaticasystemen maken volop gebruik van Internet. Enterprise Resource Planning (ERP) pakketten worden aangepast voor e-business zodat werknemers en klanten via het Internet in contact kunnen komen met de databank van het bedrijf. De gigantische groei van het Internet maakt ook dat de hoeveelheid informatie die dagelijks over dit publieke netwerk vloeit, onvoorstelbaar groot is. Het grootste deel van deze informatie is redelijk banaal, een andere deel kan omschreven worden als gevoelige informatie, informatie die niet iedereen zomaar zou mogen inkijken. Als het over gevoelige informatie gaat, hebben we het enerzijds bijvoorbeeld over de klant van Amazon1 die met zijn kredietkaart een boek of CD bestelt, en anderzijds over vertrouwelijke informatie die bedrijven via het Internet doorsturen naar hun klanten en/of leveranciers. De enorme concentratie van – gevoelige – informatie maakt dat het Internet een geliefkoosd doel is voor individuen die op zoek zijn naar vertrouwelijke informatie.

1

Amazon, zie http://www.amazon.com

2

1.2 Het algemene beeld 1.2.1 De situatie Het laatste decennium heeft de informatietechnologie een hoge vlucht genomen: enerzijds door de steeds goedkoper wordende technologie, anderzijds door een steeds grotere drang tot interconnectiviteit. Informatie kan nu sneller dan ooit opgezocht en verstuurd worden. Niet enkel de snelheid waarmee gegevens verstuurd worden, maar ook de hoeveelheid data neemt voordien ongeziene proporties aan. De openbaarheid van Internet laat toe dat een groot deel van de bevolking van de westerse landen toegang heeft tot dit immense publieke netwerk. Maar niet alleen individuen hebben zich laten verleiden, ook bedrijven hebben hun weg gevonden naar het Internet. Als we het over de aanwezigheid van bedrijven op Internet hebben, is Amazon zeker een van de eerste bedrijven waar we aan denken. Het is immers het typische voorbeeld van e-commerce (electronic commerce of elektronisch zakendoen): een klant bestelt via Internet een boek of CD, betaalt m.b.v. zijn kredietkaart en ontvangt de goederen via een pakjesdienst. Niettemin hebben we ons ook allemaal wel eens afgevraagd of het zomaar vrijgeven van onze kredietkaartgegevens wel veilig is: “Kunnen de kredietkaartgegevens onderweg niet zomaar onderschept worden door derden, die dan de kredietkaart plunderen?” Bedrijven kunnen ook in een andere context aanwezig zijn op het Internet. Ze kunnen het Internet opnemen in hun bedrijfsstrategie en legacy systemen vervangen door nieuwe softwareproducten die gebruik maken van de mogelijkheden van het Internet. Klanten kunnen tegenwoordig inloggen op de systemen van een fabrikant en online bestellingen verrichten, hun orders opvolgen, etc. Werknemers kunnen over ter wereld in contact blijven met hun bedrijf d.m.v. het Internet. We mogen er dan ook vanuitgaan dat dit berichtenverkeer tussen gepriviligeerde partners gevoelige informatie bevat die niet zomaar ten prooi mag vallen aan derden. Bovendien zijn bedrijven in grote mate afhankelijk geworden van hun informatiesystemen. Misbruik van gegevens en/of de systemen van een organisatie kunnen aanleiding geven tot grote financiële verliezen en zelfs tot het failliet van de onderneming. 1.2.2 Mogelijke consequenties Computerbeveiliging is de wetenschap/kunst om kwaadaardige bedoelingen en kwaadaardig gedrag inzake informatie- en communicatietechnologie in kaart te brengen en te beperken. Wat moeten we nu echter verstaan onder kwaadaardige bedoelingen en kwaadaardig gedrag? Een aantal motieven: • Fraude en/of diefstal: individuen krijgen op onrechtmatige wijze toegang tot geld, goederen of diensten waarvoor zij geen vergoeding aanbieden. Ook buiten de informaticawereld worden producten hiertegen beschermd, denk maar aan geldkoffers, (on)zichtbare chips op CD’s of kleding, … • Vandalisme: het toebrengen van schade om persoonlijke redenen zoals frustratie, haat, wraak, negatief zelfbeeld, … Het zou hier bijvoorbeeld kunnen gaan om een ontslagen werknemer die wraak wil nemen op zijn voormalige werkgever. • Terrorisme: schade toebrengen en terreur zaaien voor politieke doeleinden. • Spionage: ongeoorloofde toegang proberen te krijgen tot informatie om een competitief voordeel te verkrijgen. • Sabotage: schade toebrengen aan een concurrent om een competitief voordeel te verkrijgen. En waarom is het nu zo belangrijk? • Op economisch vlak: verlies van competitief voordeel, juridische vervolging, verlies aan imago bij uitlekken van inbraak, verlies van intellectueel eigendom, … • Op medisch vlak: vertrouwelijkheid en integriteit van patiëntgegevens, … • Op sociaal vlak: het recht op vrije meningsuiting, het recht op privacy, … 3

1.2.3 Wordt beveiliging als cruciaal ervaren? Hoewel investeringen voor IT-beveiliging duur zijn en soms achterwege gelaten worden, is het ondertussen toch wel zo dat een heleboel mensen en ook IT-managers zich er terdege van bewust zijn. Tijdens een onderzoek van 1996 staat “IT beveiliging” zelfs op een 6de plaats qua IT-kernpunten voor IT-managers. [VanGrembergen1996]. Gartner Research, onderdeel van de Gartner Group [Gartner2002] specialiseert zich in het bestuderen van de meest kritieke problemen waar informatietechnologie mee geconfronteerd wordt. Elk jaar publiceren ze een top 10 van punten die IT-managers als essentieel beschouwen voor hun business. Security en privacy staan reeds enkele jaren in deze top 10 en bovendien schat Gartner in dat – mede door het verhoogde budget van de Amerikaanse diensten voor staatsveiligheid naar aanleiding van de terroristische aanslagen op 11 september 2001 –, security en privacy de komende jaren een steeds belangrijkere rol gaan spelen voor IT-managers. Appendix C geeft een samenvatting weer van het Critical Issues of Information Systems Management rapport, editie 2001. Hierin staat cijfermateriaal dat bevestigt dat beveiliging en privacy nog steeds belangrijke kwesties zijn voor IT-managers. Bovendien geeft het ook goed weer hoe de situatie veranderd is na de gebeurtenissen van 11 september 2001, hoe de aanpak van beveiliging verschilt tussen de werelddelen, …

1.3 Een haalbaarheidsstudie 1.3.1 De omgeving Deze thesis is begonnen als een haalbaarheidsstudie bij Kava (Koninklijke Apotekersvereniging van Antwerpen). Kava is de grootste beroepsvereniging voor apotheken in België. Bovendien biedt Kava de apothekers een tariferingsdienst aan. Tarifering is het principe waarbij apothekers verschillende prijzen aanrekenen voor medische producten, naargelang het sociale zekerheidsstatuut van de patiënt. De sociale verzekering voor een militair verschilt bijvoorbeeld drastisch van die van een arbeider of bediende. De apotheker moet op basis van de combinatie van product en patiënt onmiddellijk de tarifering kunnen toepassen. Bovendien moet de apotheek minstens 1 keer per maand zijn tariferingsgegevens doorsturen naar de tariferingsdienst, zodat deze kan instaan voor de verdere terugbetaling. Tarifering is typisch voor een apotheek en maakt dus dat de boekhouding van een apotheek moeilijk vergeleken kan worden met een klassieke boekhouding. Een groot percentage van de aangesloten apothekers heeft reeds een hoge informatiseringsgraad bereikt: de klassieke oplossing van een stand-alone PC-infrastructuur met specifieke apothekerssoftware is goed ingeburgerd. De tarifering gebeurt lokaal. De verkoopsprijs van een medicijn, waarvoor een doktersvoorschrift is ingediend, wordt in real-time bepaald aan de hand van de verzekerbaarheid van de persoon. De verzekerbaarheidsstatus wordt met behulp van een smartcardlezer uit de SIS (Sociaal Informatie Systeem) kaart gelezen. Een belangrijk nadeel van deze stand-alone architectuur is dat er regelmatig updates nodig zijn voor de software. Wekelijks komen er immers nieuwe producten op de markt en iedere maand kunnen de prijzen voor getarifeerde producten wijzigen. Ook het programma zelf moet af en toe worden geupdate. Bovendien moet op het einde van elke maand een grote hoeveelheid tariferingsgegevens naar de tariferingsdienst worden verzonden. Vaak gebeurt dit nog via het uitwisselen van een magnetische opslagdrager (diskette), hoewel meer en meer apothekers voor email kiezen. Wat wel duidelijk is: de manier van werken zorgt voor piekmomenten in de verwerking van de tariferingsgegevens door Kava.

4

Figuur 1.1: SIS-kaart zoals deze reeds enkele jaren is ingeburgerd in België

1.3.2 De stage De stage richt zich op de haalbaarheid van een systeem waarbij de tarifering via het Internet verloopt. De primaire opslagplaats van data zou niet meer de apotheek zelf zijn, maar de tariferingsdienst. De haalbaarheidsstudie kan je opsplitsen in 2 componenten: • de technische component waarbij gekeken moet worden naar factoren zoals performantie en veiligheid van een systeem dat via Internet werkt • een eerder functionele kant, waarbij de gebruikers van het systeem moeten overtuigd worden van een zekere meerwaarde van het systeem t.o.v. het klassieke systeem Uiteraard zijn we als informatici eerder geïnteresseerd in de technische kant, maar we mogen de functionele kant zeker niet uit het oog verliezen, daar we vertrekken vanuit een real-life situatie in een bedrijf. 1.3.3 De studie zelf Tijdens de studie werd al gauw duidelijk dat een systeem waarin het Internet een centrale rol speelt, moet voldoen aan een aantal criteria: • • •

de performantie van het systeem moet vergelijkbaar zijn met het klassieke stand-alone systeem. de infrastructuur voor de gebruiker moet minimaal zijn, een klassieke PC met minimale softwarevereisten moet de apotheker in staat stellen om te tariferen. beveiliging en privacy.

En het systeem moet door middel van zijn connectiviteit een meerwaarde zien te creëren… De huidige software laat toe om een patiëntenhistoriek bij te houden: de apotheker kan m.b.v. de software het geneesmiddelengebruik van een patiënt op korte termijn inkijken en op die manier visueel of d.m.v. de ingebouwde kennis in het systeem oordelen over de compatibiliteit van bepaalde medicijnen. Bestanddelen van een bepaald medicijn kunnen nevenwerkingen vertonen in combinatie met bestanddelen van een product dat de patiënt eerder heeft aangeschaft. Indien de historiek een gebruiksconfict weergeeft, kan de apotheek de patiënt inlichten om af te zien van het gebruik van één van beide producten. Momenteel blijft deze patiëntenhistoriek uiteraard apotheekgebonden. Een meerwaarde van een sterk geïntegreerd systeem zou uiteraard kunnen zijn om deze patiëntenhistoriek globaal te maken en dus beschikbaar te stellen voor alle apotheken waarbij de patiënt klant is. Evenwel… het is niet moeilijk om in te zien dat zowel de tarifering als het bijhouden van een globale patiëntenhistoriek leidt tot het versluizen van grote hoeveelheden gevoelige informatie. De wetgever schrijft dan ook duidelijk voor dat gezondheidsinformatie zeer goed beveiligd moet worden en er heel voorzichtig moet worden omgesprongen met dergelijke informatie. De Belgische overheid heeft daartoe de Kruispuntenbank2 opgericht, die deze informatiestroom voor het grootste deel beheert. Hiermee wordt onmiddellijk duidelijk dat beveiliging een topprioriteit vormt voor een dergelijk systeem… 2

De Belgische Kruispuntenbank: http://www.ksz-bcss.fgov.be/Project/Project2_1_nl.html

5

1.4 De thesis Deze thesis heeft als hoofddoel na te gaan wat de huidige stand van zaken is qua technieken om beveiligde communicatie over een publiek netwerk zoals het Internet mogelijk te maken. We bekijken welke protocollen er zijn en welke principes essentieel zijn om ons doel te bereiken. Als rode draad doorheen het verhaal gebruiken we Secure Socket Layer of SSL. Bovendien gaan we na hoe een efficiënte infrastructuur voor sleuteluitwisseling eruit ziet, welke mogelijke valkuilen er op het vlak van privacy ontstaan bij het op grote schaal toepassen van deze zogenaamde publieke sleutel infrastructuur. De hypothese waar deze thesis om draait, is: De huidige methoden voor Internetbeveiliging voldoen om adequate beveiliging en privacy aan te bieden.

1.5 Een aantal inleidende begrippen Hoewel deze thesis uitgaat van een aantal begrippen en technieken uit de informaticawereld, worden bepaalde principes getoetst aan minder strikt gedefinieerde begrippen zoals privacy en beveiliging: begrippen die buiten de informaticawereld soms een andere definitie krijgen, vandaar dat we ze hier even kort bespreken.

1.5.1 Privacy Definitie:

Privacy (van informatie) is het recht dat natuurlijke personen, groepen van personen of instituten hebben om voor zichzelf uit te maken wanneer, hoe en in welke mate informatie over de betrokken individuen overgedragen wordt aan derden.

Deze definitie van Alan Westin [Westin1967] wordt vaak geciteerd in de academische literatuur en in juridische documenten. Bovendien vormt ze de basis van de Privacy Act (1967) van de Verenigde Staten van Amerika. Niet enkel de Verenigde Staten vinden privacy belangrijk, want het recht op privacy werd ook opgenomen in: • artikel 22 van de Belgische Grondwet omschrijft privacy als een grondrecht van alle individuen. • artikel 8 van het Europees Verdrag ter Berscherming van de Rechten van de Mens. • artikel 17 van het Internationaal Verdrag Inzake Burgerrechten en Politieke Rechten. 1.5.2 Beveiliging Beveiliging wordt vaak als één groot monolitisch blok gezien, niettemin bestaat beveiliging uit een aantal afzonderlijke – maar soms sterk gerelateerde – concepten. Beveiliging van gegevens onder transmissie impliceert dat we volgende eigenschappen moeten kunnen garanderen [DeSchutter]: • • • •

Vertrouwelijkheid: berichten kunnen niet door onbevoegden worden ingekeken. Deze eigenschap noemen we ook wel confidentialiteit. Integriteit: gegevens kunnen onderweg niet – ongemerkt – aangepast worden. Continuïteit: berichten kunnen niet onopgemerkt verloren gaan of geheel of gedeeltelijk worden vernietigd. Authenticiteit: berichten die we ontvangen zijn afkomstig van diegene met wie gecommuniceerd wordt en berichten die we versturen komen aan bij de persoon met wie we wensen te communiceren.

6

Deze begrippen worden verder besproken in het volgende hoofdstuk. Dat beveiliging een hot topic is, bewijst de nieuwe wet op informaticacriminaliteit, die op 28 november 2000 in voege is getreden. Een fragment [PISA]: Hij die valsheid pleegt, door gegevens die worden opgeslagen, verwerkt of overgedragen door middel van een informaticasysteem, in te voeren in een informaticasysteem, te wijzigen, te wissen of met enig ander technologisch middel de mogelijke aanwending van gegevens in een informaticasysteem te veranderen, waardoor de juridische draagwijdte van dergelijke gegevens verandert, wordt gestraft met gevangenisstraf van zes maanden tot vijf jaar en met geldboete van zesentwintig frank tot honderdduizend frank of met een van die straffen alleen.

7

Hoofdstuk 2 Ingrediënten voor veilige communicatie “First, figure out what you are trying to do (this is good advice under most cirumstances, and it is especially apropos here)” — NNTP Installation Guide

2.1 Inleiding Om te kunnen redeneren over de stappen die je moet zetten om een informatica-architectuur te beveiligen, moet je je eerst bewust worden van de gevaren die op de loer liggen. Een eerste stap die je moet zetten is een zogenaamde risico-analyse uitvoeren, een opsomming van interne en externe risico’s met hun mogelijke impact op het systeem. Een volledige risico-analyse is veel te uitgebreid binnen het kader van de studie van een Internetprotocol dat beveiligde communicatie aanbiedt, maar we zijn wel geïnteresseerd in 1 onderdeeltje ervan, het threat model. Een cruciale fase voor een ontwikkelaar van beveiligde internetprotocols is het definiëren van mogelijke bedreigingen. Het threat model specifieert juist van welke types van inbraken we ‘s nachts wakker moeten liggen en welke types van inbraken we links mogen laten liggen. We moeten dus een aantal realistische scenario’s bekijken om te voorkomen dat de ontwikkelaars zich onnodig concentreren op situaties die weinig voorkomen of die een onredelijk groot aantal toevalligheden veronderstellen. Op die manier voorkomen we dat het protocol overdreven ingewikkeld wordt gemaakt, wat de begrijpbaarheid van het mechanisme en de (computationele) efficiëntie van het protocol ten goede komt. Een standaard informeel Internet Threat Model ziet er als volgt uit [Rescorla2000]: • We stellen dat de aanvaller quasi volledige toegang heeft tot het communicatiekanaal tussen eindstations: het netwerk is niet te vertrouwen. • We gaan ervan uit dat de eindsystemen waarop het protocol wordt toegepast veilig zijn: immers, beveiligen tegen een infrastructuur waar een eindsysteem onder de controle is van een aanvaller is extreem moeilijk. • Hierop zijn 2 uitzonderingen: 1) Eén enkel gecompromitteerd eindsysteem mag de beveiliging van de hele infrastructuur niet in het gedrang brengen. Als de beveiliging tussen A en B gecompromitteerd is, mag dit niet als gevolg hebben dat ook de beveiliging tussen B en C gevaar loopt, deze eigenschap noemt men no single point of failure. 2) Het systeem dat de aanvaller gebruikt kan zich voordoen als een legaal eindstation van het systeem, de aanvaller mag enkel niet over een legaal eindsysteem beschikken. We gaan er met andere woorden vanuit dat de aanvaller pakketjes kan injecteren in het netwerk (zich voordoende als de zender of de ontvanger), pakketjes uit de netwerkstroom kan halen en bovendien elk pakketje in de netwerkstroom kan inkijken.

8

Op basis van wat we nu weten, kunnen we een eerste onderscheid maken tussen aanvallen: • een actieve aanval is een bedreiging waarbij de aanvaller zelf informatie naar het netwerk schrijft. • een passieve aanval daarentegen houdt in dat de aanvaller enkel gegevens van het netwerk leest. Een heel bekende aanval is de denial-of-service (DOS) aanval. Voortbouwend op de veronderstelling dat de aanvaller de inhoud van berichten tussen 2 machines kan aanpassen, kan de aanvaller net zo goed alle pakketjes tussen 2 machines uit het netwerk verwijderen en daardoor de communicatie onmogelijk maken. Een andere vorm van denial-of-service aanval is dat de aanvaller op korte tijd een groot aantal connecties probeert te maken met een eindstation, waardoor deze een enorme hoeveelheid verwerkingskracht (CPU-tijd) moet besteden aan de inkomende connecties zodat de bereikbaarheid van het eindstation in het gedrang komt. Over het algemeen houden protocoldesigners geen rekening met denial-of-service aanvallen, niet omdat ze niet belangrijk zijn, maar omdat ze heel moeilijk te voorkomen zijn. Deze soort aanvallen komen dus meestal niet voor in een threat model. Een van de belangrijkste functies van een threat model is om ervoor te zorgen dat beveiliging niet duurder wordt dan ze eigenlijk waard is: beveiligingsmaatregelen moeten geïmplementeerd worden tot aan het punt waarop de implementatie ervan duurder wordt dan het risico van een inbraak. Een slechte afweging kan leiden tot een situatie waarbij geen enkel overgelaten risico aanvaardbaar lijkt en geen enkel acceptabel systeem kan geïmplementeerd worden. Bovendien is geen enkele vorm van beveiliging waterdicht voor elke mogelijke aanval. De functie van een threat model is juist te bepalen op welke aanvallen we ons moeten richten.

2.2 Doel van beveiliging Meestal wordt beveiliging als één monolitisch concept beschouwd, als één enkele eigenschap van een protocol. Maar afhankelijk van de mogelijkheden die aan de aanvaller geboden worden, kan je verschillende risico’s voor de data in transit onderscheiden. Communicatiebeveiliging bestaat uit een aantal verschillende, soms relateerde eigenschappen [Rescorla2000]: 1. Vertrouwelijkheid (confidentialiteit) De inhoud van berichten die onderschept worden, kan niet zomaar worden ingekeken door onbevoegden, m.a.w. de privacy van de gegevens wordt beschermd. 2. Integriteit De inhoud van een bericht kan onderweg niet onopgemerkt gewijzigd worden. 3. Authenticiteit Berichten die worden ontvangen zijn afkomstig van de partij waarmee men wenst te communiceren, m.a.w. we hebben zekerheid over de oorsprong van het bericht. 4. Continuïteit [DeSchutter] Berichten in transit kunnen niet onopgemerkt geheel of gedeeltelijk verloren gaan of vernietigd worden. 5. Onweerlegbaarheid [DeSchutter] In juridisch opzicht belangrijk omdat men ten aanzien van derden een aantal hoedanigheden van het bericht kan bewijzen. Deze eigenschap heeft o.a. tot gevolg dat een partij achteraf niet kan ontkennen iets verstuurd te hebben. Zoals blijkt, is de partitionering van de eigenschappen niet voor elke auteur eender. Eigenschappen 1 tot en met 4 zijn duidelijk technologische eigenschappen; sommige auteurs brengen eigenschap 4, continuïteit, onder bij de integriteit van een bericht, maar integriteit dekt niet helemaal de lading van een bericht dat geheel verloren gaat. Eigenschap 5, onweerlegbaarheid of non-repudiation is duidelijk niet van technische aard, maar heeft een sterke juridische connotatie. Onderstaande tabel probeert weer te geven hoe een klassiek systeem zoals De Post kan vergeleken worden met een beveiligd communicatiekanaal.

9

Confidentialiteit Integriteit Authenticiteit

De Post Briefgeheim Een zegel of handtekening op de sluiting van de enveloppe Handtekening onderaan de brief + eventueel handschrift bij handgeschreven tekst.

Continuïteit

Aangetekende brief

Onweerlegbaarheid

Aangetekende brief

Beveiligde verbinding Encryptie van de boodschap. “Echtheidsbewijs” (zie later bij Message Authentication Codes Certificaten, publieke en private sleutels. Wordt opgelost door TCP (Transmission Control Protocol) als we het hebben over SSL boven een TCP/IP verbinding. TCP vraagt een acknowledgement van ieder pakket. Juridische erkenning van digitale handtekeningen.

Figuur 2.1: Vergelijking De Post versus beveiligde verbinding (technische aspecten)

De overige paragrafen van dit hoofdstuk behandelen een aantal technische aspecten van encryptie. Begrippen zoals symmetrische encryptie, asymmetrische encryptie, message authentication codes (MAC’s) en digitale handtekeningen worden verder toegelicht. Lezers die op de hoogte zijn van deze begrippen kunnen de volgende paragrafen overslaan en terug inpikken bij sectie 2.7 genaamd Elementaire bouwstenen. Voor wat betreft de technische uitleg van volgende paragrafen hebben we ons gebaseerd op: [Rescorla2000], [OPT1997] en [DaviesEtAl1989].

2.3 Encryptie gedecrypteerd Cryptology is de theorie van het ontwerpen van algoritmen die we gebruiken voor beveiligingsdoeleinden. Cryptografie bestudeert het gebruik van deze algoritmen met als doel systemen en protocols te beveiligen. 2.3.1 Inleiding Het concept van het beveiligen van berichten door cryptografie bestaat al een hele tijd. Julius Caesar is een van de eersten die cryptografische beginselen toepaste om militaire gegevens naar zijn generaals te sturen. Het ging hier dan vaak over verschuivingen van letters: A B … Y Z

C D A B

(verschuiving van 2 letters)

Waarbij het geheim, “de sleutel”, dan voorstelde hoeveel plaatsen de letters in het alfabet opschuiven. Doorheen de geschiedenis staat één probleem centraal dat de mogelijkheden van cryptografie drastisch beperkt heeft, het zogenaamde sleutelmanagementprobleem: hoe kan je het geheim veilig overbrengen naar de communicerende partij? Publieke sleutel cryptografie, ook wel bekend als asymmetrische encryptie, biedt hier een aantal oplossingen voor aan. In moderne systemen staat de sleutel voor een numerieke waarde die door het algoritme gebruikt wordt om de informatie te “veranderen”, waardoor de informatie enkel leesbaar wordt voor mensen die een sleutel in hun bezit hebben. Deze situatie wordt afgebeeld in Figuur 2.2.

10

Een thesis geschreven in het kader van privacy & beveiliging.

##$*&@DSW@#$#@ #@#@#!#$KDWE=_# @~!<}||=)#$#@#$#)%+_# Ciphertext

Plaintext

Figuur 2.2: Plaintext versus ciphertext (geëncrypteerde data)

2.3.2 Symmetrische encryptie Symmetrische encryptie, ook wel geheime sleutel cryptografie (Secret Key Cryptography) genoemd, gebruikt dezelfde sleutel voor encryptie en decryptie. Het is dus belangrijk dat de sleutel enkel gekend is door gemachtigde gebruikers. Het idee is simpel: een encryptie-algoritme krijgt als input gegevens (de zgn. plaintext) en zet die om in ciphertext met behulp van een sleutel. De ciphertext ziet eruit als willekeurige data en op de lengte van de tekst na, kan je niks van de plaintext afleiden uit de ciphertext

Plaintext

Encrypteren met sleutel A

Ciphertext

Decrypteren met sleutel A

Plaintext

Figuur 2.3: Symmetrische encryptie

Om de ciphertext dan weer om te zetten in de plaintext, kan de bestemmeling gebruik maken van dezelfde sleutel. Er bestaan een aantal verschillende symmetrische encryptie algoritmen, die kunnen geclassificeerd worden in 2 groepen: •

Stream ciphers Deze algoritmen werken byte-geörienteerd. De encryptiesleutel wordt intern eerst omgezet tot een zogenaamde keystream. Daarna combineer je telkens 1 byte van de keystream met 1 byte van de plaintext en zo bekom je een byte ciphertext. De combinatie-operatie wordt in dit voorbeeld voorgesteld door de XOR-operatie ⊕. C[i] = KS[i] ⊕ M[i] Waarbij C[i] staat voor de i-de byte ciphertext, KS[i] staat voor de i-de byte uit de keystream (omdat de keystream vaak beperkt is in lengte moet de index i hier vaak modulo de lengte van de keystream worden gedaan) en M[i] staat voor de i-de byte van het bericht (de plaintext). De omgekeerde operatie ziet er dan uit als volgt: M[i] = KS[i] ⊕ C[i] Merk wel op dat bovenstaand voorbeeld een vereenvoudigde voorstelling is van een stream cipher: meestal hangt het resultaat van een bewerking af van de geschiedenis van de berichtstroom, m.a.w. de waarde van C[i] hangt niet enkel af van M[i], maar ook van bepaalde elementen uit de sequentie M[0,…,i-1]. RC4 is het meest verspreide stream cipher. De sleutellengte ervan mag variëren tussen 8 en 2048 bits. Ongeacht de lengte van de sleutel, wordt de sleutel intern omgezet naar een keystream aan de hand van een statetable. Dit zorgt ervoor dat – of je nu gebruik maakt van een sleutel van 40 bit (exporteerbaar) of van 128 bit – de snelheid van het algoritme niet verandert naargelang de sleutellengte.

11

•

Block ciphers Een block cipher daarentegen werkt met blokken data: 64 bits (8 bytes) plaintext worden geëncrypteerd tot 64 bits ciphertext. 8 bytes is een veel gebruikte blokgrootte, maar er bestaan ook blokgroottes van 64, 256, 1024 en 8192 bytes. Block ciphers kan je eenvoudig voorstellen d.m.v. 2 functies: een functie E (voor encryptie) en een D (voor decryptie). Elk van de 2 functies heeft 2 parameters: de sleutel (K) enerzijds en het te encrypteren/decrypteren datablok anderzijds (resp. voorgesteld door M en C). C = E(K, M) M = D(K, C) Meestal willen we echter berichten encrypteren die groter zijn dan 1 datablok. Vandaar dat we sequenties van datablokken gaan beschouwen. De meest eenvoudig manier om een sequentie datablokken te encrypteren is de zogenaamde Electronic Codebook (ECB) modus: C[i] = E(K, M[i]) M[i] = D(K, C[i]) Dit op zich is vrij eenvoudig, maar het heeft 1 groot nadeel: stel dat 2 datablokken M[j] en M[k] hetzelfde zijn (voor i ≠ j), dan zijn C[j] en C[k] eveneens hetzelfde. Als dit patroon vaak voorkomt, dan kan een aanvaller hieruit iets leren over de plaintext. Deze eigenschap zouden we liever niet hebben. Cipher Block Chaining (CBC) modus lost dit probleem op: de encryptie van een blokje plaintext hangt af van de ciphertext van het vorige geëncrypteerde blokje. C[i] = E(K, M[i] ⊕ C[i–1]) M[i] = D(K, C[i]) ⊕ C[i-1] Op deze manier zullen 2 identieke blokjes plaintext normaal gezien niet tot eenzelfde blokje ciphertext leiden. Wat moeten we nu echter doen met het eerste blokje plaintext dat we willen encrypteren? We kunnen hier immers niet terugvallen op C[i-1]… Om dit eerste blokje te encrypteren gebruiken we daarom een random gegenereerd datablokje, de zogenaamde initialization vector (IV). ECB en CBC zijn niet de enige modi voor gebruik met block ciphers. Enkele andere zijn: Output Feedback (OFB) en Cipher Feedback (CFB). Maar in het kader van de algoritmen die SSL ondersteunt, is CBC de meest relevante. Laten we nu nog even kort kijken naar een aantal veel gebruikte block ciphers: Veruit het meest gebruikte symmetrische cipher is de Data Encryption Standard (DES). Analytisch gezien zijn er geen zwakheden bekend voor DES, niettemin wordt DES vandaag de dag als vrij zwak beschouwd, in zekere zin door de beperkte sleutellengte (56 bit). Met een klein gedistribueerd systeem van commercieel beschikbare computers kan een DES sleutel vandaag te dag in minder dan 24 uur teruggevonden worden. Vandaar dat DES enkel gebruikt mag worden voor gegevens met een beperkte waarde of een beperkte levensduur. Omdat DES op zich geen zwakheden vertoonde, maar enkel de sleutellengte te beperkt werd geacht, dacht men eraan om de data meer dan 1 keer door het algoritme te sturen, een proces dat superencryptie heet. Echter, 2 keer DES toepassen bleek niet veel krachtiger te zijn dan DES één enkele keer toepassen, met als gevolg dat men ging kijken naar 3 keer DES toepassen. Triple DES (3DES) heeft een effectieve sleutellengte van 112 bits (de sleutel is wel 128 bits groot, maar voor elke 7 bits bestaat een parity check bit). In 1997 schreef het NIST (National Institute of Standards and Technology) een opdracht uit voor een nieuw symmetrisch encryptie-algoritme uit, dat op termijn de opvolger wordt van DES. Sindsdien is bekend geworden dat uit een tiental inzendingen het Rijndael algoritme

12

van Vincent Rijmen en Joan Daemen uitgekozen is. Deze nieuwe encryptiestandaard is bekend onder de naam Advanced Encryption Standard (AES). 2.3.3 Asymmetrische encryptie Het grootste probleem van symmetrische encryptie is dat voordat enige beveiligde verbinding tot stand kan komen, beide partijen eerst een gemeenschappelijke geheime sleutel moeten bekomen. Voor kleinschalige systemen (bv. binnen een organisatie) vormt dit geen probleem, maar in een publiek netwerk waar miljoenen mensen met elkaar willen communiceren is deze oplossing duidelijk ontoereikend. Een grote vooruitgang werd geboekt toen in 1976 de zogenaamde publieke sleutel cryptografie (Public Key Cryptografie) werd uitgevonden. Dit principe werd voor het eerst beschreven in “New Directions in Cryptography” [Diffie1976]. Het basisidee is dat je aparte sleutels gebruikt voor de encryptie en de decryptie van berichten. De sleutel waarmee je encrypteert stel je ter beschikking van iedereen – de publieke sleutel – terwijl je de decryptiesleutel geheim houdt – de private sleutel. Omdat je met 2 verschillende sleutels werkt, wordt deze vorm van cryptografie ook wel asymmetrische encryptie genoemd.

Publieke sleutel partij B

Plaintext

Encryptie

Private sleutel partij B

Ciphertext

Partij A

Decryptie

Plaintext

Partij B Figuur 2.4: Asymmetrische encryptie

Beschouwen we Figuur 2.4: als partij A met partij B wil communiceren, kan A de publieke sleutel van B opvragen en hiermee de berichten versleutelen. Verondersteld wordt dat B de enige is die in het bezit is van de private sleutel die aan hem werd toegekend: enkel partij B kan het bericht ontcijferen. Het gevolg hiervan is dat iedereen jou een versleuteld bericht kan versturen, zonder dat je de persoon in kwestie ooit hebt moeten ontmoeten (of er op een veilige manier een sleutel mee hebt moeten uitwisselen). Deze techniek lost het sleutelmanagementprobleem dus op. Een kleine anekdote over publieke sleutel cryptografie: In 1998 is bekend geworden dat een van de agentschappen van de Britse geheime dienst, meer bepaald de “Communications-Electronics Security Group” (CESG) tussen 1970 en 1974 onderzoek heeft gedaan naar publieke sleutel cryptografie. In 1974 hadden ze hun “non-secret encryption” of NSE op punt gesteld. De resultaten hiervan bleven tot 1998 geheim en de academische wereld heeft de technieken ‘heruitgevonden’ (New Directions in Cryptography verscheen in 1976 [Diffie1976]). Interessant is wel dat de technieken van NSE in grote mate overeenkomen met het Diffie-Hellman algoritme en een variant van RSA. Laten we nog even kort kijken welke asymmetrische algoritmen we zoal kunnen tegenkomen: RSA is ongetwijfeld het meest bekende asymmetriche algoritme. Het werd in 1977 uitgevonden door Ron Rivest, Adi Shamir en Len Adelman. Volgens het RSA systeem bestaan publieke sleutels uit 2 getallen: de modulus (n) en de publieke exponent (e). De modulus is het product van 2 heel grote priemgetallen, voorgesteld door p en q (p en q blijven allebei geheim). De veiligheid van RSA bestaat eruit dat het computationeel gezien heel moeilijk is om n te factoriseren in p en q. De private sleutel is een ander getal, aangeduid met d, dat enkel berekend kan worden als je p, q en e kent. Als we over de sleutellengte van de RSA sleutel spreken, dan hebben we het over de

13

lengte van de modulus. De RSA publieke exponent moet relatief priem zijn t.o.v. e en (p-1)(q-1). Gemakkelijkheidshalve wordt e meestal gekozen uit een beperkte aantal priemgetallen (3, 17 of 65637). Een kleine waarde voor e maakt de publieke sleutel operaties aanzienlijk sneller. Als e gekozen is, kan men d als volgt berekenen: d = e-1 mod ((p-1)(q-1)) Om

een

bericht

M

te

encrypteren

met

een

publieke

sleutel

(e, n),

bereken

je:

C = Me mod n Om de decrypteren: M = Ce mod n Afzender

Publiek

Bestemmeling Priemgetallen: p en q

n

n

n=pq

e

e

Sleutels: d, e (priem t.o.v. p-1 en q -1) d = e -1 mod ((p-1)(q-1))

Bericht M

Versleuteld

Ontcijferd

C = M e (mod n)

C

M = Ce (mod n)

Figuur 2.5: Overzicht van RSA

Volledigheidshalve vermelden we ook het 2de meest gebruikte asymmetrische algoritme, nl. Diffie-Hellman (DH). Dit was het eerste publieke sleutel algoritme dat ooit gepubliceerd werd [Diffie1976]. In het kader van onze technische analyse van SSL vallen we meestal terug op RSA, vandaar dat we geen technische details van DH zullen bespreken. 2.3.4 Symmetrisch versus asymmetrisch Asymmetrische encryptie wordt meestal in tandem gebruikt met symmetrische encryptie. Publieke sleutel cryptografie biedt het voordeel dat het een goede oplossing biedt voor het sleutelmanagementprobleem. Echter, enkel asymmetrische encryptie toepassen is duidelijk ook niet de oplossing, want symmetrische encryptie is veel efficiënter (computationeel gezien minder zwaar) [Rescorla2000, p.41]. Vaak wordt asymmetrische encryptie dan ook enkel gebruikt om een bepaald geheim over te brengen naar een correspondent met wie je geen gemeenschappelijke geheime sleutel hebt. Zodra dit geheim is overgebracht, kan er worden overgeschakeld op symmetrische encryptie. Een extra opmerking is hier misschien wel aan de orde: de sleutellengtes voor asymmetrische algoritmen zijn absoluut niet vergelijkbaar met die voor symmetrische encryptie. Sleutellengtes voor asymmetrische encryptie liggen typisch tussen 512 en 2048 bits, terwijl deze voor symmetrische encryptie algemeen genomen tussen 40 en 192 bit liggen. Dit wil zeker niet zeggen dat symmetrische algoritmen zwakker zijn, integendeel, asymmetrische algoritmen zijn over het algemeen zwakker. Voor een performantie-overzicht van symmetrische en asymmetrische algoritmen verwijzen we naar Appendix A.

14

2.4 Message digest Message digests worden voornamelijk gebruikt voor digitale handtekeningen en message authentication codes (MACs): deze 2 technieken bespreken we in de volgende 2 secties. Een message digest is een functie die een string van variabele lengte omzet in een string met constante lengte (= de message digest); meestal wordt getracht om de message digest redelijk kort te houden. De output van de functie noemt men karakteristiek voor het oorspronkelijke bericht. Een goed algoritme voor message digests voldoet aan de volgende 2 eigenschappen: • De belangrijkste eigenschap is onomkeerbaarheid. Hiermee wordt bedoeld dat het heel erg moeilijk moet zijn om het oorspronkelijke bericht terug te vinden als je enkel de message digest kent. Intuïtief begrijpen we dat de message digest niet genoeg informatie meer bevat om het oorspronkelijke bericht te recreëren (door de beperkte lengte van de digest). Een digest algoritme is veilig als het moeilijk is om eender welke van de oorspronkelijke berichten van een gegeven digest te achterhalen. • Een tweede kenmerk van een digest algoritme is dat het moeilijk moet zijn om 2 berichten M en M’ te vinden die resulteren in dezelfde digest: dit noemt men de botsweerstand van het algoritme. Algemeen genomen kan je stellen dat voor een 128-bit digest, er 264 operaties nodig zijn om een botsing tegen te komen. De meest gebruikte message digest algoritmen zijn Message Digest 5 (MD5) en Secure Hash Algorithm 1 (SHA-1), deze 2 algoritmen produceren een output die respectievelijk 128 bit en 160 bit lang is. De term hash algoritme wordt vaak in dezelfde context gebruikt als message digest algoritme: de 2 technieken zijn gelijkaardig.

2.5 Digitale handtekening In paragraaf 3 hebben we het verschil gezien tussen symmetrische en asymmetrische encryptie. Symmetrisch encryptie is gebaseerd op het feit dat de communicerende partijen op de hoogte zijn van een gemeenschappelijk geheim en daaruit volgt onmiddellijk dat ze elkaar dermate vertrouwen dat authenticatie eigenlijk geen probleem vormt. In het publieke sleutel cryptografie verhaal is er echter geen sprake van automatische authenticatie, immers iedereen kan over de publieke sleutel van een correspondent beschikken (het certificaat dat de publieke sleutel bevat, wordt immers gepubliceerd) en daarmee een bericht versleutelen… je hebt op die manier geen enkel idee van wie het bericht versleuteld heeft. Vreemd genoeg vormt asymmetrische encryptie toch het antwoord op het authenticatieprobleem! Laten we eens kijken hoe… In het normale schema wordt het bericht versleuteld m.b.v. de publieke sleutel, zodat enkel de bestemmeling – die beschikt over de corresponderende private sleutel – het bericht kan ontcijferen. Als het bericht nu echter versleuteld wordt d.m.v. de private sleutel, dan kan iedereen weliswaar het bericht ontcijferen m.b.v. de publieke sleutel, maar je kan wel vaststellen wie het bericht versleuteld heeft en op die manier onomstotelijk de authenticiteit van het bericht vaststellen.

15

Let op de volgorde!

Private sleutel partij A

Plaintext

Encryptie

Publieke sleutel partij A

Ciphertext

Partij A

Decryptie

Plaintext

Partij B

Figuur 2.6: Schematische voorstelling van een digitale handtekening

In bovenstaand denkproces zitten echter nog een aantal lacunes: • Als je enkel encrypteert met je private sleutel, dan kan iedereen het bericht lezen, want de overeenkomstige publieke sleutel is vrij verkrijgbaar. Als we Figuur 2.6 volgen zouden we eerst de publieke sleutel van Partij B moeten gebruiken om te encrypteren, waarna we nog eens encrypteren met de private sleutel van Partij A. Aangekomen bij Partij B kunnen we dan het bericht ontcijferen door de omgekeerde operaties uit te voeren op de ciphertext. • Bovendien zijn publieke sleutel cryptografische operaties duur: computationeel gezien zijn ze veel zwaarder dan symmetrische encryptie-operaties, vandaar dat we de grootte van de berichten die we wensen te encrypteren d.m.v. asymmetrische encryptie willen beperken… Wat betreft de gebruikte algoritmen kunnen we stellen dat RSA vaak gebruikt wordt, evenals de Digital Signature Standard (DSS; vroeger ook wel bekend onder Digital Signature Algorithm (DSA)). DSS is gebaseerd op Diffie-Hellman principes.

2.6 Message Authentication Code (MAC) Als 2 partijen op een beveiligde manier met elkaar willen communiceren, volstaat het niet om de gegevens simpelweg te encrypteren. Een geëncrypteerde gegevensstroom kan onderweg op redelijk eenvoudige wijze worden aangepast. Hierdoor verandert uiteraard ook de betekenis van de plaintext die de bestemmeling verkrijgt na decryptie van het verknoeide bericht. Wat we eigenlijk nodig hebben is zekerheid dat er onderweg niet met het bericht geknoeid werd, i.e. we willen de integriteit van het berichten verzekeren. Bovendien zouden we ook een efficiëntere manier willen voor digitale handtekeningen om de authenticiteit van het bericht te verzekeren. Een message authentication code of MAC is eigenlijk precies wat we zoeken. Een MAC combineert twee technieken die we net hebben besproken, namelijk de message digest en de digitale handtekening. de message digest zorgt ervoor dat het oorspronkelijke bericht verkleind wordt tot 128 of 160 bits. de digest kan je onversleuteld versturen, het is immers heel moeilijk om het oorspronkelijke bericht af te leiden als je enkel de digest kent. je kan de digest voorzien van een digitale handtekening, dit heeft als voordeel dat kostelijke private sleutel operatie beperkt blijft qua omvang (een digest is typisch 128 of 160 bits lang)

16

Afzender Bericht

Message Digest

Hash functie

Bericht

MAC

Bericht

MAC

Handteken functie

Private sleutel verzender

Verificatie functie

Publieke sleutel verzender

Bestemmeling

Hash functie

Message Digest

jk

Aanvaarden

gelijk

Niet aanvaarden

G eli Gelijk?

N i et

Figuur 2.7: Message authentication code (MAC) schema

Figuur 2.7 laat alle stappen zien van het MAC mechanisme. Aan de hand daarvan kunnen we duidelijk zien hoe de MAC zijn werk doet: • Als er onderweg geknoeid werd met het bericht en/of de MAC, dan zal aan de zijde van de bestemmeling de test falen, immers de message digest van het bericht en de message digest uit de MAC zullen verschillend zijn. Hiermee wordt de integriteit bevestigd. • Als het bericht niet van de bedoelde afzender komt, dan zal de gelijkheidstest ook falen, want de digest uit de MAC zal niet overeenkomen wegens het gebruik van een verkeerde publieke sleutel. Hiermee wordt de authenticiteit gegarandeerd.

2.7 Een overzicht van de elementaire bouwstenen In de vorige subsecties hebben we een aantal elementaire cryptografische technieken besproken. De vraag is nu: kunnen we met deze principes voldoen aan de 5 vereisten die we in sectie 2.2 voorop hebben gesteld? 1) Vertrouwelijkheid Aan deze eigenschap kunnen we voldoen door (a)symmetrische encryptie te gebruiken. Enkel de personen die op de hoogte zijn van de geheime (of private sleutel in het geval van asymmetrische encryptie) kunnen het bericht ontcijferen. 2) Integriteit Hier kan de MAC voor zorgen door na te gaan of de message digest van het verstuurde bericht en die van de MAC wel hetzelfde zijn. 3) Authenticiteit Ook dit kan de MAC verzorgen: is de message digest van het verzonden bericht identiek aan die van de MAC als we de juiste publieke sleutel toepassen voor verificatie? 4) Continuïteit Voor wat betreft de continuïteit hebben we geen specifieke techniek gezien. Als we ons

17

echter beperken tot het versturen van gegevens over TCP/IP, dan kan de transportlaag onder invloed van het Transmission Control Protocol (TCP) wel degelijk nagaan of er geen berichten verloren gaan (d.m.v. acknowledgments). 5) Onweerlegbaarheid Dit is uiteraard een juridische consequentie die verbonden moet worden aan de legale waarde van een digitale handtekening. De technologie ervoor is reeds enige tijd voorhanden, maar de wetgevende macht heeft nog geen beslissing genomen over de wettelijke draagkracht van de technologische mogelijkheden. Recentelijk, meer bepaald in juni 2001 keurde de Ministerraad van Belgie een wetsontwerp goed, waarbij een digitale handtekening dezelfde juridische waarde krijgt als een klassieke handtekening. Op 9 juli 2001 verscheen deze wet in het Staatsblad [SB29092001].

18

Hoofdstuk 3 Technologie-overzicht "It takes less time to do a thing right than to explain why you did it wrong." — Henry Wadsworth Longfellow

3.1 Inleiding In de vorige 2 hoofdstukken hebben we vastgelegd wat de krijtlijnen zijn van het onderzoek en welke basistechnologiën we tot onzer beschikking hebben om tot het gewenste doel te komen. Dit hoofdstuk poogt een overzicht te geven van enkele protocollen die vaak gebruikt worden (of toch tenminste vaak aangehaald worden in de literatuur) om tot het doel van een beveiligde Internetverbinding te komen die min of meer probeert de privacy te garanderen. De hamvraag blijft natuurlijk… welke criteria kunnen we gebruiken om te beslissen of een bepaald protocol past bij het type applicatie dat we wensen te ontwikkelen? • Toepasbaarheid? Is een protocol te specifiek om voor alle doeleinden gebruikt te kunnen worden? • Wordt het protocol reeds gebruikt in webrowsers, emailapplicaties, …? Of moet er apart een plugin voor geïnstalleerd worden? • Hoeveel kost de implementatie? Moet de applicatie en/of protocolstack herschreven worden? Is er veel configuratiewerk nodig? • Is het een eenvoudig protocol? De kwaliteit van een protocol wordt voornamelijk getoetst door analyse en veel minder d.m.v. proefondervindelijkheid; een eenvoudig, goed gestructureerd protocol is veel eenvoudiger te analyseren dan een ingewikkeld protocol met tal van opties. We verkiezen dus een eenvoudig protocol. We bespreken 6 protocollen: 1) Secure Socket Layer (SSL) • Transport Layer Security (TLS) • Private Communication Technology (PCT) 2) Secure Electronic Transaction (SET) 3) Secure HTTP (S-HTTP) 4) IP Secure (IP Sec) In de telecomwereld wordt vaak gebruik gemaakt van het ISO/OSI netwerklagenmodel. Dit model is ontwikkeld door de International Standards Organisation (ISO) en kreeg de naam Open Systems Interconnection (OSI) Reference Model omdat het beschrijft hoe open systemen, i.e. systemen die openstaan voor communicatie met andere types (open) systemen, met elkaar kunnen connecteren. Een eerste ruwe onderverdeling van bovenstaande protocollen kunnen we dus maken op basis van het niveau in het ISO/OSI netwerklagenmodel waarop ze betrekking hebben: • •

De eerste 5 protocollen werken op de applicatielaag (SSL, TLS, PCT, SET, S-HTTP). Dit type van protocol gebruikt vaak sockets als basis voor inter proces communicatie (IPC). IP Secure daarentegen werkt op de netwerklaag: rechtstreeks op het niveau van de IP pakketjes zelf.

19

Applicatie laag Transport laag

TCP

Netwerk laag

IP

Datalink laag Fysische laag 3

Figuur 3.1: ISO/OSI model toegepast op de TCP/IP protocolstack

We overlopen nu de protocollen een voor een. Maar omwille van de technische gelijkenissen groeperen we de bespreking van SSL, TLS en PCT.

3.2 Secure Socket Layer (SSL) 3.2.1 Inleiding

Applicatie laag Transport laag

TCP

Netwerk laag

IP

Datalink laag

Secure Socket Layer, Transport Layer Security en Private Fysische laag Communication Technology zijn protocollen die een beveiligd communicatiekanaal tussen 2 hosts aanbieden. Er zijn voorzieningen ingebouwd om de gegevens in transit te beschermen en je communicatiepartner te identificeren. De 3 protocollen zijn (technisch) verwant met elkaar, vandaar dat we ze onder 1 noemer bespreken.

Figuur 3.2: Familieboom van SSL varianten

3

Merk op dat het ISO/OSI model standaard 7 lagen bevat, maar in de context van TCP/IP worden de sessie- en presentatielaag meestal weggelaten wegens niet gebruikt.

20

3.2.2 Secure Socket Layer De geschiedenis van Secure Socket Layer gaat terug tot 1994 toen Netscape Communications versie 1 van SSL voorstelde. Versie 1 had ernstige ontwerpfouten en werd nooit in een commercieel product gebruikt. In de allereerste versie van Netscape Navigator, die eind 1994 werd gelanceerd, zat SSLv2. Pas in 1996, met het verschijnen van Netscape Navigator 3.0, kwam SSLv3 ten tonele. Versie 3 verschilt grondig van versie 2 en de beveiligingslekken die versie 2 karakteriseren, zijn in versie 3 weggewerkt. Een grondige bespreking van SSLv3 volgt in hoofdstukken 4 en 5. 3.2.3 Private Communication Technology In 1995 lanceerde Microsoft een groot Internetoffensief, speerpunt hiervan was Internet Explorer, Microsoft’s eerste webbrowser. Bijna tegelijkertijd ontwikkelde Microsoft ook Private Communication Technology, een concurrent voor SSL, dat door grote concurrent Netscape werd ontwikkeld. Op technisch vlak was PCT een grote verbetering t.o.v. SSLv2: een aantal beveiligingslekken waren op een elegant wijze gedicht en het protocol was flexibeler dan de tegenhanger van Netscape. PCT was volledig terugwaarts compatibel met SSLv2: een PCT client kan zonder problemen communiceren met een SSLv2 host. Bovendien is het recordformaat van PCT identiek aan dat van SSL. Het grootste verschil zit hem in de handshake fase – de fase waarin de parameters van de connectie worden vastgelegd –, waar de oplossing van Microsoft minder berichten nodig heeft voor het opzetten van een verbinding en meer mogelijkheden biedt wat betreft de keuze van (encryptie)algoritmen. In feite was PCT ook een politieke zet van Microsoft: op deze manier had Microsoft meer inspraak in het standaardisatieproces dat de IETF4 rond die tijd opstartte. 3.2.4 Transport Layer Security In 1996 startte de IETF een werkgroep op met de naam Transport Layer Security, die als taak had een protocol dat op SSL lijkt, te standardiseren. De ultieme bedoeling van de IETF was echter de ontwerpkeuzes van Netscape en Microsoft harmonisen in één protocol. Uiteindelijk is TLS grotendeels gebaseerd op SSLv3 en intern draagt TLS versienummer SSLv3.1. TLS biedt meer keuze wat betreft versleutelingsalgoritmen en gebruikt een ander MAC-algoritme dan SSLv3. Tijdens de grondige bespreking van SSL in Hoofdstuk 4 komen we nog terug op de verschillen tussen SSLv3 en TLS. 3.2.5 Aanverwante protocollen In Figuur 3.2 wordt ook STLP (Secure Transport Layer Protocol) vermeldt. Dit was in essentie een stijloefening van Microsoft om de IETF werkgroep te beïnvloeden. Grootste nieuwigheid hier was dat er nu ook ondersteuning voor UDP was voorzien (i.p.v. enkel TCP zoals de anderen protocollen in de familie). Voorts is er nu ook een wireless variant van TLS, WTLS genaamd, die bruikbaar is voor het beveiligen van WAP verkeer5.

4

IETF: de Internet Engineering Task Force, terug te vinden op http://www.ietf.org WAP of Wireless Application Protocol, een protocol dat toelaat vanaf mobiele telefoons bepaalde Internetdiensten te gebruiken. 5

21

3.2.6 Gebruiksscenario Bij de ontwikkeling van het protocol werd het paradigmatische gebruiksscenario van een online betaling met kredietkaart gehanteerd. Aan de hand daarvan werden aan aantal doelen vooropgesteld voor het protocol: • •

•

•

Vetrouwelijkheid De informatie kan niet (of toch heel moeilijk) ingekeken worden door luistervinken. Encryptie is hier de voor de hand liggende oplossing. Server authenticatie Als we een beveiligd communicatiekanaal opzetten, willen we zeker zijn dat we met de juiste persoon communiceren. Tijdens de initiatiefase van een SSL gesprek stuurt de server dan ook zijn certificaat op naar de partij die het gesprek initieert. De kredietkaarthouder wil immers zeker zijn dat hij zijn waardevolle gegevens niet aan de verkeerde persoon doorgeeft. Hoewel dit niet meteen paste in het kredietkaartscenario, werd tegelijkertijd ook client authenticatie voorzien. Transparantie Hoewel de ontwikkelaars als eerste doel beveiligd webverkeer (HTTP) voor ogen hadden, wilden ze dezelfde beveiligde communicatie ook aanbieden voor andere protocols, zonder aanpassingen aan SSL of aan het protocol dat gebruik wil maken van SSL. Spontaniteit Een communicerende partij zal vaak willen communiceren met een partij met wie hij/zij nog nooit eerder heeft gecommuniceerd. SSL moet het uitwisselen van certificaten mogelijk maken zonder (of met beperkte) gebruikerstussenkomst.

Niettemin… bovenstaande doelstellingen vertellen niet het hele verhaal. Een gegevensstroom waarvan de vertrouwelijkheid is gegarandeerd d.m.v. encryptie, is niet meteen veilig voor actieve aanvallen: een aanvaller kan de geëncrypteerde datastroom aanpassen en zodoende de betekenis van de ciphertext, die men na decryptie bekomt, veranderen. Daarom moet ook de integriteit van de data bewaakt worden. Van elk datafragment dat verstuurd wordt, moet dus ook een MAC worden gemaakt: deze verzekert de integriteit en biedt tegelijkertijd authenticiteit op een per pakket basis aan. Zie Hoofdstuk 4 voor meer technische details over SSL. In het kredietkaartscenario is men in de eerste plaats geïnteresseerd in het kredietkaartnummer van de klant; voor de Internethandelaar is de betaling uiteraard veel belangrijker dan de identiteit van de klant. Niettemin werd client authenticatie dus wel vanaf het begin voorzien in het protocol, omdat er dus wel degelijk situaties zijn waarin de identiteit van de client wel geweten moet zijn, bijvoorbeeld om toegang te krijgen tot bepaalde waardevolle informatiebronnen. Het prototype dat bij Kava werd uitgebouwd is een goed voorbeeld van een dergelijke situatie. De relatie tussen de tarificatiemaatschappij en de apotheek is een heel nauwe relatie en gezien de waarde van de gegevens die verstuurd worden groot is, lijkt het maar beter dat de identiteit van de apotheek gecontroleerd wordt met behulp van een certificaat, om zo onbevoegden buiten te sluiten. Bovenstaand scenario blijft een ruwe schets, want SSL is duidelijk bedoeld als general-purpose beveiligingsprotocol dat gebruikt kan worden door alle applicaties die gebruik maken van sockets als basis voor inter proces communicatie (IPC). SSL werkt op de applicatielaag en alle applicaties kunnen op een transparante manier gebruik maken van beveiligde sockets i.p.v. de standaard sockets die worden aangeboden door het besturingssysteem. Een aantal voorbeelden als bewijs voor het ruime toepassingsgebied van SSL: • File Transfer Protocol (FTP) • Simple Mail Transfer Protocol (SMTP) • Remote access protocols zoals Remote Method Invocation (RMI) en Corba • Lightweigth Directory Access Protocol (LDAP) • …

22

HTTP

SMTP

...

LDAP

Secure Socket Layer Applicatie laag Transport laag

TCP

Netwerk laag

IP

Datalink laag Fysische laag Figuur 3.3: SSL draait boven de TCP/IP laag en onder high-level applicatie-protocollen

3.2.7 SSL getoetst • •

• •

6 7

Toepasbaarheid? De transparantie van het protocol zorgt ervoor dat elke applicatie die gebruik maakt van sockets voor inter proces communicatie in principe gebruik kan maken van SSL. Ondersteuning? Quasi alle webbrowsers ondersteunen SSL en meer en meer applicaties ondersteunen ook de nieuwere variant – TLS. Voor de meeste programmeertalen zijn bovendien reeds toolkits beschikbaar voor SSL en/of TLS. De meest courante webservers, waaronder Apache, Microsoft Internet Information Server 5.0 en IBM Websphere ondersteunen SSL. Wat betreft Java kunnen we melden dat er sinds enige tijd een gratis toolkit beschikbaar wordt gesteld door Sun (de zogenaamde Java Secure Socket Extension of JSSE6). Vanaf Java 1.4 is deze API geïntegreerd in de standaard JDK. Deze toolkit werkt behoorlijk goed. Enkel client authentication, dat pas sinds versie 1.4 werd toegevoegd aan de API, werkte tijdens de tests niet naar behoren. Volgens Sun zou dit in de eerstvolgende update verholpen zijn. Een voorbeeld van een commerciële API die SSL en TLS ondersteunt, is SSLava van Phaos Technology7. Jammer genoeg was er geen evaluatieversie hiervan verkrijgbaar voor dit onderzoek. Implementatie? Omwille van de mooi gelaagde structuur waarin SSL zich nestelt zijn er weinig of geen problemen om bestaande applicaties te laten overschakelen op SSL. Eenvoud? Zoals uit de volgende hoofdstukken zal blijken, is SSL een goed gestructureerd protocol, dat eenvoudig, maar zeer robuust in elkaar zit.

Voor de Java Secure Socket Extension, zie: http://java.sun.com/products/jsse/ Phaos Technology, zie: http://www.phaos.com

23

3.3 Secure Electronic Transaction (SET)

Applicatie laag

3.3.1 Inleiding

Transport laag

TCP

Netwerk laag

IP

Datalink laag

In oktober 1995 stelden MasterCard, Netscape Corporation en Fysische laag IBM het Secure Electronic Payment Protocol (SEPP) voor; slechts enkele dagen na de aankondiging van een consortium onder leiding van Microsoft en VISA, dat Secure Transaction Technology (STT) had ontwikkeld. Op die manier onstond er een situatie waarbij de 2 grootste kredietkaartmaatschappijen ieder een aparte technologie ondersteunden voor Internetbetaalverkeer. Pas in januari 1996 kondigden beide partijen aan dat ze een geünificeerd systeem met de naam Secure Electronic Transactions (SET) gingen ontwikkelen. 3.3.2 Gebruiksscenario In tegenstelling tot de protocollen die we hierboven beschrijven, is de scope van SET veel nauwer: vanaf de ontwikkeling is het enkel bedoeld geweest als een protocol voor betaalverkeer via het Internet. De onderhandeling tussen klant en handelaar over de prijs, de methode van betaling en/of levering wordt niet ondersteund door SET. Hiervoor moet je een beroep doen op een ander protocol. SET gaat er duidelijk vanuit dat er een beveiligde infrastructuur bestaat tussen financiële instellingen, want vanuit het standpunt van de hele transactie beschrijft SET slechts de subset van de dialogen die tussen de klant en de handelaar enerzijds en de handelaar en de payment gateway anderzijds plaatsvinden. De payment gateway is een soort ‘schakelcentrale’ die op basis van het type kredietkaart contact zal opnemen met de juiste kredietkaartmaatschappij: het is een interface tussen het klassieke financiële netwerk en de infrastructuur voor veilige betaling op Internet, gecreëerd door SET.

Financieel netwerk

Nie t-S ET

ET t- S e i N Kredietkaart maatschappij

Payment Gateway

Kaart houder

SET (fase 2)

(fase 3)

SET (fase 1)

Handelaar

Figuur 3.4: Fasen van kredietkaartbetalingsmechanismen met SET ondersteuning

Werking van SET: 1) De kaarthouder voert de betaling met de handelaar uit door middel van SET. 2) De handelaar maakt ook gebruik van SET om de betaling te laten goedkeuren bij de payment gateway. 3) De rest van de transactie valt terug op bestaande (bancaire) systemen. Figuur 3.4 maakt duidelijk dat SET niet bedoeld is als general-purpose (betalings) protocol. Enkel financiële transacties die gebeuren via kredietkaart kunnen ermee beveiligd worden.

24

Dit alles zorgt er wel voor dat SET in dit overzicht een buitenbeentje is wat betreft toepasbaarheid. De application range is te beperkt en de gehanteerde principes zijn te weinig vernieuwend t.o.v. bovenvermelde protocollen. Voor meer informatie omtrent SET, zie [OPT1997, blz.101]. 3.3.3 SET getoetst • •

•

Toepasbaarheid? SET kent slechts een zeer beperkte toepasbaarheid: enkel betalingen via kredietkaart kunnen ermee beveiligd worden. Ondersteuning + implementatie? In de literatuur is sprake van een aantal toolkits die ter beschikking worden gesteld door o.a. VISA en Mastercard (de 2 grootste kredietkaartmaatschappijen). Deze toolkits zijn echter niet vrij verkrijgbaar en we hebben deze dus ook niet kunnen testen. Een aantal webservers zoals IBM Websphere ondersteunen SET, maar er is geen spoor terug te vinden van commercieel verkrijgbare client-applicaties die SET ondersteunen. Eenvoud? De gebruikte principes lijken op die van SSL en het protocol zit vrij eenvoudig in elkaar. T.o.v. SSL hebben de gebruikte records een ingewikkelder formaat. Niettemin lijkt alles mooi gestructureerd en eenvoudig genoeg.

3.4 Secure HTTP (S-HTTP) 3.4.1 Inleiding

Applicatie laag Transport laag

TCP

Netwerk laag

IP

Datalink laag

In de context van SSL wordt ook wel eens gesproken over Fysische laag HTTPS, zijnde een HTTP connectie die gebruik maakt van SSL. HTTPS verschilt grondig van het protocol dat we hier bespreken, namelijk S-HTTP. Als je tijdens het surfen overschakelt van een gewone verbinding (HTTP) naar een verbinding beveiligd door SSL (HTTPS), dan verandert de URL van http://www.eensite.be naar https://www.eensite.be. Deze “naamsverandering” heeft voornamelijk te maken met het veranderen van poort 80 (voor HTTP), naar poort 443 voor HTTPS. S-HTTP daarentegen biedt ook bescherming voor gegevens die via het web worden verstuurd, maar op een record-gebaseerde manier i.p.v. op de connectie-georiënteerde wijze van SSL. 3.4.2 Technisch S-HTTP behandelt elke HTTP request of response als een aparte eenheid en beschermt deze afzonderlijk. Dit laat S-HTTP toe om verscheidene berichten tussen client en server op een verschillende manier te beveiligen. HTTPS daarentegen vormt bij het surfen naar een beveiligde webserver een connectie, die gedurende langere tijd kan blijven bestaan: zolang de gebruiker binnen dezelfde site surft kunnen dezelfde beveiligingsparameters gebruikt worden. Voor meer informatie over S-HTTP, zie [Rescorla1999].

25

3.4.3 Afwegingen Deze manier van werken maakt Secure HTTP wel meer flexibel dan HTTPS. Verschillende resources kunnen naargelang hun “informatiewaarde” op een andere manier worden beveiligd. De implementatie daarentegen voor S-HTTP is minder eenvoudig: • De webserver moet in staat zijn om HTML pagina’s te herschrijven door cryptografische syntax toe te voegen aan de HTML. • Bij het gebruik van HTTPS moeten hooguit manueel de URL’s die in de HTML voorkomen veranderd worden in https i.p.v. http. • Ook aan de clientzijde moet de HTML parser aangepast worden om overweg te kunnen met de cryptografische elementen die in de HTML zijn toegevoegd. 3.4.4 HTTP-S getoetst • •

•

•

Toepasbaarheid? De toepasbaarheid van S-HTTP beperkt zich tot het HTTP protocol. Ondersteuning? Rond 1995 was het nog niet duidelijk welke techniek de dominante webbeveiligingsstandaard zou worden. Ondertussen is HTTPS geïntegreerd in quasi elke webbrowser, terwijl S-HTTP in geen enkele terug te vinden is. Implementatie? S-HTTP is duidelijk meer verweven met de software, tewijl HTTPS gebruik kan maken van een veel mooier gelaagd model. Er zijn aanpassingen aan de webbrowser nodig om S-HTTP tags te kunnen begrijpen. Bovendien moet de webserver in staat zijn deze tags te kunnen toevoegen aan HTML pagina’s. Dit maakt dat het toevoegen van S-HTTP aan bestaande applicaties moeilijker is dan voor bijvoorbeeld SSL. Eenvoud? Ondanks zijn eenvoud biedt het protocol enorm veel flexibiliteit: elke webpagina kan met een aparte beveiligingssterkte worden overgebracht, naar gelang de graad van belangrijkheid van de informatie. Dit is een eigenschap die bij geen enkel ander protocol wordt teruggevonden. De keerzijde van de medaille wat betreft dit punt is uiteraard de hogere kost van implementatie.

26

3.5 IP Secure Protocol (IPSec) 3.5.1 Inleiding

Applicatie laag Transport laag

TCP

Netwerk laag

IP

Datalink laag

De term IPSec wijst op een verzameling van mechanismen die Fysische laag ontwikkeld werden om netwerkverkeer te beveiligen op de netwerk laag. De werkgroep rond IPSec werd in 1992 bijeengebracht en in 1995 werden de eerste documenten rond deze technologie vrijgegeven. Pas in 1998 werden ook mechanismen toegevoegd voor sleutelmanagement. De beveiliging wordt aangeboden op de IP laag en biedt dus beveiliging aan voor de IP laag en alle bovenliggende lagen. Je kan IPSec optioneel gebruiken voor IPv4, terwijl het standaard geïntegreerd zit in IPv6. Eens IPv6 wijdverspreid is, wordt het voor iedere gebruiker mogelijk om op een beveiligde manier te communiceren via IP. Het grote verschil met de protocollen die we tot nog toe besproken hebben, is natuurlijk het actiegebied. Alle voorgaande protocollen werken op de applicatielaag, terwijl IPSec op de netwerklaag werkt. Terwijl een protocol zoals SSL enkel de inhoud van een TCP datagram kan beveiligen, kan IPSec ook de IP (en TCP) headers van authenticatie voorzien. [Labouret2000] biedt een goed overzicht van de IPSec technologiën. 3.5.2 Structuur van IPSec Zoals gezegd is IPSec een verzameling van protocollen die beveiligd verkeer mogelijk maken… Centraal staat het concept van een Security Association (SA), dat de overige protocollen als het ware aan elkaar lijmt. Internet Security Association and Key Management Protocol (ISAKMP) en Internet Key Exchange (IKE) worden gebruikt voor het sleutel management en voor het vaststellen van de parameters voor de connectie. De parameters van de connectie worden opgeslagen in 1 of meerdere associaties. Protocollen zoals Authentication Header (AH) en Encapsulating Security Payload (ESP) gebruiken die associaties op hun beurt om de connectie zelf te voorzien van vetrouwelijkheid (d.m.v. encryptie) en integriteit (d.m.v. berichtauthenticatie). 3.5.3 Security Association (SA) Een Security Association is een overeenkomst tussen 2 hosts waarin beschreven staat welke vorm van beveiliging wordt gebruikt als deze 2 hosts op een beveiligde manier met elkaar willen communiceren. Je kan een SA beschouwen als een contract dat beschrijft welke algoritmen, welk sleutelmateriaal en welk protocol (ESP of AH) gebruikt gaat worden. Een SA beschrijft deze parameters voor één richting: als Host 1 met Host 2 beveiligd wil communiceren is er 1 SA nodig; als Host 2 ook iets wil terugsturen op beveiligde wijze, dan moet er ook een SA bestaan voor dit pad. Bovendien kunnen er tussen 2 hosts meerdere SA’s bestaan. Niet enkel voor bidirectioneel berichtenverkeer, maar ook om aan te duiden dat meerdere protocollen worden gebruikt om de verbinding te beveiligen. Een verbinding tussen Host 1 en Host 2 – zoals in Figuur 3.5 – kan voorzien worden van 2 beveiligingsmechanismen: AH en ESP. Voor elk van deze protocollen is één SA nodig per richting. Als je bijvoorbeeld zowel AH als ESP op hetzelfde verkeer tussen 2 hosts toepast, dan heb je 2 SA’s nodig: dit noemt men een SA bundel.

27

Richting 1 SA 1 (ESP transport) SA 2 (AH transport)

Publiek netwerk (bv. Internet)

Host 1

Host 2

SA 3 (ESP transport) SA 4 (AH transport)

Richting 2 Figuur 3.5: Twee Security Association bundels tussen 2 hosts

De hele verzameling SA’s wordt in de Security Policy Database (SPD) gestopt: een databank waarin de behandeling van inkomende en uitgaande pakketten staat. De werking ervan is vrij gelijkaardig aan die van een firewall, maar wel met toevoeging van IPSec principes. 3.5.4 Sleutelmanagement en connectieparameters Voordat er data kan verstuurd worden door gebruik te maken van protocollen zoals Authentication Header en/of Encapsulating Security Payload (ESP), moet er minstens 1 SA worden opgesteld. Om een SA te kunnen instellen moet je beschikken over de nodige sleutels en een afspraak omtrent de algoritmen die gebruikt gaan worden. Dit kan manueel gebeuren, een procedure die men manual keying noemt. Echter, deze manier van werken houdt ook wel in dat het sleutelmanagement probleem weer brandend actueel wordt: de (sleutel)geheimen moeten op een verantwoorde manier overgebracht worden tussen de te beveiligen eindpunten. In de meeste courante situaties gaan we er vanuit dat de SA’s dynamisch worden ingesteld en dat de sessie sleutels worden uitgewisseld. Het protocol waarmee SA’s worden onderhandeld is het Internet Security Association and Key Management Protocol (ISAKMP). Het is in feite geen echt protocol, het is een soort framework: verschillende sleuteluitwisselingsprotocollen kunnen ingeplugd worden en het is niet louter bruikbaar voor IPSec (ook andere beveiligingsmechanismen kunnen er gebruik van maken). In het kader van de standardisatie van IP Secure wordt ISAKAMP gecombineerd met het Internet Key Echange (IKE) protocol. 3.5.5 Authentication Header Het idee achter het AH protocol is dat bepaalde velden van de IP header mee worden opgenomen in de MAC die ook de payload authenticeert. Sommige velden van de header veranderen op een hopper-hop basis, daarom worden deze velden niet opgenomen in de MAC: de authenticatie gebeurt dus duidelijk op een end-to-end basis.

Originele IP Header

Originele IP Header

Data (bovenliggend protocol)

AH

Data (bovenliggend protocol)

Geauthenticeerd (op mutable velden zoals TTL na (Time To Live), die op een per hop basis kunnen veranderen) Figuur 3.6: Authentication Header

28

De AH header bevat ook een sequentienummer, dat ook als input dient voor de MAC, om replay bescherming te bieden. Replay aanvallen worden in Hoofdstuk 5 besproken. 3.5.6 Encapsulating Security Payload (ESP) ESP heeft als voornaamste functie de vertrouwelijkheid van de payload te voorzien, m.a.w. de data vervat in het IP pakket te encrypteren. Optioneel is er ook authenticatie voorzien. In tegenstelling tot AH, biedt ESP geen bescherming voor de header aan.

Originele IP Header

Originele IP Header

Data (bovenliggend protocol)

ESP Header

Data (bovenliggend protocol) Geëncrypteerd (

ESP Trailer

Authentication Data

vertrouwelijkheid)

Geauthenticeerd Figuur 3.7: Encapsulating Security Payload

In Figuur 3.7 authenticeert ESP dus duidelijk de data van de payload, maar biedt geen bescherming voor de IP Header. Het AH protocol daarentegen beschermt de header wel. Een mogelijke aanval zou eruit kunnen bestaan het IP adres van de bron of de bestemming aan te passen. De authenticatiemogelijkheden van AH lossen dit probleem op en dit is dus een goede reden om ESP en AH te combineren om het berichtenverkeer te beschermen. In dit geval zijn er dus 2 SA’s nodig (1 voor AH en 1 voor ESP) en dan spreken we over een SA bundel. 3.5.7 Tunnel modus Om het verhaal nog wat ingewikkelder te maken, kent IPSec ook nog 2 zogenaamde modi, enerzijds transport modus en anderzijds tunnel modus. Tot nog toe zijn we ervan uitgegaan dat het eindstation dat het pakket verstuurt, ook het station is dat de IPSec-mogelijkheden aanwendt: deze situatie is ideaal voor transport modus. De bescherming gebeurt m.a.w. op een end-to-end basis. In bedrijven komt het echter vaak voor dat 2 vestigingen van een bedrijf met elkaar verbonden moeten worden via netwerk. Dit kan d.m.v. een privaat netwerk, waarbij de communicatiekanalen gekocht of voor langere termijn gehuurd worden, of d.m.v. een zogenaamd Virtual Private Network (VPN). Een VPN biedt een geëncrypteerd communicatiekanaal aan dat via een publiek netwerk zoals het Internet loopt. Beschouwen we Figuur 3.8: als Host 1 een pakketje stuurt naar Host 2, dan hoeft Host 1 niet te weten dat Host 2 zich aan de andere kant van het VPN bevindt, Host 1 mag er vanuit gaan dat Host 2 zich op hetzelfde netwerk bevindt. Als het pakketje aankomt bij de security gateway om verstuurd te worden over een publiek netwerk, dan kan de IPSec Security Gateway beslissen om het pakketje naar de overeenkomstige gateway op de andere locatie te sturen m.b.v. de principes van IPSec. Maar deze keer “verpakt” de router het pakketje door een nieuwe IP Header te maken die aan het pakketje verbonden blijft tot het einde van de tunnel (= de overeenkomstige router op de andere locatie) bereikt wordt. Vandaar dat men in dit geval spreekt van tunnel modus.

29

SA 1 (ESP tunnel) SA 2 (AH tunnel)

Host 1 Intern netwerk locatie 1

Host 2

Publiek netwerk (bv. Internet)

Intern netwerk locatie 2

IPSec Security Gateway

IPSec Security Gateway 8

Figuur 3.8: Een voorbeeld van tunnel modus

Figuur 3.9 laat zien dat in tunnel modus de oorspronkelijk IP header nu wel in het gedeelte valt dat ESP encrypteert en authenticeert. De security gateway voegt nu een nieuwe IP header toe aan het pakket, dat de bestemmingscoördinaten bevat van het eindpunt van de tunnel, de security gateway aan de andere kant van het VPN.

Nieuwe IP Header

ESP Header

Originele IP Header

Data (bovenliggend protocol)

Originele IP Header

Data (bovenliggend protocol)

Geëncrypteerd (

ESP Trailer

Authentication Data

vertrouwelijkheid)

Geauthenticeerd Figuur 3.9: ESP toegepast in tunnel modus

3.5.8 IP Secure getoetst •

•

•

Toepasbaarheid? Rest nog een groot vraagteken… waarvoor kunnen we IPSec gebruiken? De summiere documentatie die verkrijgbaar is over het protocol schept hier weinig licht op. De complexiteit van het protocol maakt dat het niet overal even inzetbaar is. Volgende doeleinden lijken het meest logisch: Virtual Private Networks Extranet Het grote verschil tussen een extranet en een VPN schuilt erin dat bij een VPN de communicerende hosts vast zijn, i.e. veranderen fysisch niet van plaats, terwijl bij een extranet de werknemer die wil inloggen of de klant die informatie wil opvragen wel van locatie kunnen veranderen. Toegang tot hoog-beveiligde server Toepasbaarheid + implementatie? IP Secure is optioneel beschikbaar voor IPv4 en zal standaard voorzien zijn in IPv6. De grote doorbraak voor IPSec is waarschijnlijk gekoppeld aan de toepassing op grote schaal van IPv6. Om ten volle gebruik te maken van de mogelijkheden moet de TCP/IP protocol stack aangepast worden en een deel van de netwerkapparatuur (bv. routers) aangepast worden. Eenvoud? Een kenmerk van een goed beveiligingsprotocol is zijn eenvoud. Complexe systemen zijn immers moeilijker te doorgronden en daardoor is het ook moeilijker om zwakheden in het systeem te ontdekken tijdens de ontwerpfase. Uit bovenstaande bondige uitleg blijkt wel meteen dat IP Secure een vrij complex protocol is.

8

Figuur 3.8 laat zien hoe tunnel modus gebruikt kan worden in combinatie met Security Gateways, tunnel modus kan echter ook op een end-to-end basis gebruikt worden. Bovenstaande tekening geeft voornamelijk de toepasbaarheid m.b.t. VPN’s weer, maar is dus zeker niet de enige mogelijke setup!

30

Niet alleen valt het eigenlijke recordprotocol uiteen in 2 subprotocollen, i.e. AH en ESP, er bestaan ook nog eens 2 operationele modi, i.e. transport en tunnel modus. Bovendien kan transport modus makkelijk gesimuleerd worden d.m.v. tunnel modus (door simpelweg het oorspronkelijke pakket in de payload van het getunnelde pakket te stoppen en de originele IP header te hergebruiken). De enige keerzijde aan het weglaten van transportmode is dat de pakketjes iets groter worden en er in sommige gevallen dus minder efficiënt wordt omgegaan met bandbreedte. Hoewel IPSec een totaaloplossing wil zijn die alle aspecten van beveiligde communicatiekanalen aanpakt, is dit misschien toch een beetje teveel van het goede.

3.6 Conclusie Uit het overzicht kunnen we duidelijk afleiden dat SSL en langzamerhand ook TLS de beste technieken vormen voor hedendaagse applicaties. De ondersteuning is zeer goed, zowel in bestaande applicaties als onder de vorm van het aanbod van toolkits voor verschillende programmeertalen en platforms. Het protocol kent een eenvoudige structuur en is bovendien voor een groot aantal doeleinden geschikt. Vandaar de de volgende 2 hoofdstukken gewijd zijn aan Secure Socket Layer.

31

Hoofdstuk 4 Inleiding tot Secure Socket Layer (SSL) And now for a new rule of thumb: ”The Complexity Trap: Security's worst enemy is complexity.” — Niels Ferguson and Bruce Schneier

4.1 Inleiding Nu we alle ingrediënten hebben om een beveiligd protocol uit te werken, gaan we eens kijken hoe SSL versie 3 deze technieken in de praktijk brengt. Hoewel SSLv3 op het eerste zicht misschien ingewikkeld lijkt, moeten we ons wel realiseren dat elk protocol ontworpen voor beveiligde communicatie wordt opgebouwd aan de hand van dezelfde primitieve bouwstenen, nl: • • • •

(Geheime sleutel) encryptie Digest algoritmen Publieke sleutel encryptie Digitale handtekening algoritmen

Zoals we in Hoofdstuk 2 reeds hebben gezien zijn publieke sleutel methoden bijvoorbeeld veel minder efficiënt dan geheime sleutel methoden, dus houdt het steek om de 2 technieken te combineren. Publieke sleutel encryptie kunnen we gebruiken om het sleutelmanagementprobleem op te lossen en de vrij korte sessiesleutels mee te encrypteren. Het bericht dat we willen versturen is over het algemeen omvangrijker dan de sessiesleutels en hiervoor gebruiken we dan geheime sleutel encryptie. Voor wat betreft het vervolg van deze inleiding vallen we terug op het prototype dat we bij Kava hebben ontwikkeld. In dit eenvoudige voorbeeldje gaan we ervan uit dat de apotheek op een beveiligde manier wil communiceren met de tariferingsdienst van Kava. Om een bericht te versleutelen kan de apotheek een random geheime sleutel genereren, een zogenaamde sessiesleutel (of session key), en encrypteert die sessiesleutel gebruik makend van Kava’s publieke sleutel, die te vinden is op het certificaat van Kava. Het eigenlijke bericht dat de apotheek naar Kava wil versturen wordt geëncrypteerd m.b.v. de sessiesleutel (d.m.v. geheime sleutel cryptografie). Deze combinatie van symmetrische en asymmetrische encryptie zorgt voor snelle encryptie/decryptie van het eigenlijke bericht, terwijl er ook kan teruggevallen worden op de voordelen van certificaat-gebaseerd sleutel management. Bovenstaand mechanisme werkt goed voor een statisch systeem waarbij de apotheek en Kava emails met elkaar willen uitwisselen. Het beschrijft een soort enveloppe mechanisme waaraan geen real-time constraints verbonden zijn en waarbij de (met de publieke sleutel van Kava versleutelde) sessie sleutel en het versleutelde bericht in één totaalbericht worden doorgestuurd. Deze situatie wordt afgebeeld in Figuur 4.1.

32

Apotheek

Bericht

Symmetrische encryptie

Sessie sleutel

Asymmetrische encryptie

Geëncrypteerd bericht

Geëncrypteerde sessiesleutel

Kava’s publieke sleutel

Kava Asymmetrische encryptie

Kava’s private sleutel

Geëncrypteerd bericht

Symmetrische encryptie Sessie Sleutel

Bericht Figuur 4.1: Enveloppe mechanisme

Een meer interactief systeem, waarbij meerdere berichtjes in beide richtingen vloeien, zou volgens bovenstaand principe een te grote overhead met zich meebrengen. We willen immers niet voor elk berichtje een nieuwe sessie sleutel opstellen en deze dan moeten versleutelen met de publieke sleutel van Kava. Dit zou leiden tot dure publieke sleutel operaties voor elk pakketje dat we willen versturen. Een design voor een meer dynamisch protocol bestaat erin dat de communicerende partijen tijdens een handshake fase een aantal afspraken maken: eerst authenticeert de apotheek Kava m.b.v. een digitaal certificaat, waarna ze een paar (sessie)sleutels uitwisselen. Dan wordt er overgegaan tot een gegevens transfer fase waarbij ze de sleutels die ze hebben uitgewisseld, gebruiken om de gegevens die ze versturen te versleutelen. Een vereenvoudigd overzichtje van een typische connectie (afgebeeld in Figuur 4.2): 1) Handshake Kava en de apotheek gebruiken hun certificaten en private sleutels om elkaar te authenticeren en een gemeenschappelijk geheim uit te wisselen. 2) Sleutel afleiding (“Key Derivation”) Kava en de apotheek gebruiken hun gemeenschappelijk geheim om een paar cryptografische sleutels af te leiden die ze kunnen gebruiken voor het versleutelen van hun berichtenverkeer. 3) Gegevenstransfer De gegevensstroom die ze willen uitwisselen wordt opgebroken in een reeks van records; elk record wordt individueel beschermd. Deze manier van werken heeft als voordeel dat gegevens onmiddellijk na het beschikbaar komen, verstuurd kunnen worden en ook zo snel mogelijk verwerkt kunnen worden aan de zijde van de bestemmeling. 4) Sluiting Speciale berichten worden verstuurd om op een veilige manier aan te geven dat de gegevensstroom ten einde is. Dit voorkomt dat een aanvaller de gegevensstroom voortijdig kan afsluiten en zodoende het bericht ergens middenin kan afbreken.

33

Client

Server Hallo

Ce rt ifi caa

t

(1)

G eheim

Sleutelafleiding

Sleutelafleiding G eë ncr y

ptee rde ge g

(2)

eve ns

gev ens pte er de ge Ge ëncry Al er t: Clo se

(3)

(4)

Figuur 4.2: Een overzicht van de SSL fases

SSL is een goed voorbeeld van zo’n dynamisch protocol: op een connectie georiënteerde wijze worden beveiligde verbindingen mogelijk gemaakt. In de volgende secties bespreken we SSL in detail. SSL valt uiteen in 2 grote delen: de handshake en de gegevenstransfer. Deze 2 onderdelen komen eerst aan bod. Daarna bespreken we de sleutelafleiding (zoals we zullen zien is dit bij SSL geen aparte fase, maar een onderdeel van de handshake). Bovendien bespreken we 2 opties wat betreft de SSL handshake, namelijk: client authenticatie en het hernemen van een sessie.

4.2 Handshake 4.2.1 Algemeen De SSL handshake heeft 3 doelen: • • •

De client en de server moeten het allereerst zien eens te worden over welke algoritmen ze gaan gebruiken om de gegevens in transit te beschermen. Er moeten cryptografische sleutels worden vastgesteld, die gebruikt gaan worden door de algoritmen die gekozen werden. De client wordt geauthenticeerd.(optioneel)

Een schematisch overzicht van de SSL handshake (zie Figuur 4.3): 1. De client stuurt de server een lijst met algoritmen die langs de clientzijde ondersteund worden, samen met een random waarde, die gebruikt wordt tijdens het berekenen van de sleutels. 2. De server kiest een cipher uit het lijstje en stuurt het terug. De server stuurt ook zijn certificaat op, dat gebruikt kan worden voor authenticatie van de server. Ook de server levert een random waarde. 3. De client controleert het servercertificaat en extraheert de publieke sleutel. De client genereert dan een random geheime string, de zogenaamde pre_master_secret en versleutelt die met de publieke sleutel van de server. De versleutelde versie van de pre_master_secret wordt naar de server gestuurd. 4. De client en de server berekenen onafhankelijk van elkaar de encryptie en MAC sleutels. 5. De client deelt d.m.v. de ChangeCipherSpec aan de server mee dat alle volgende berichten beveiligd zullen worden met de net vastgestelde algoritmen en sleutelparameters.

34

6. In het Handshake Finished bericht van de client, wordt een MAC van alle handshakeberichten die naar de server gestuurd werden, gemaakt en doorgestuurd naar de server. 7. Op zijn beurt bericht de server de client dat er vanaf nu gebruik wordt gemaakt van de net vastgestelde algoritmen en sleutelparameters. 8. In het Handshake Finished bericht van de server, wordt een MAC van alle handshakeberichten die naar de client gestuurd werden, gemaakt en doorgestuurd naar de client.

Client

Server

C lientHello: ondersteunde

ciphers; random waarde

er, ra ndom waa rde ServerHello: gek ozen ciph ServerHello: certi ficaat ServerHelloDone

Cl ientK eyEx change: G eëncr

Sleutels berekenen

ypteerde PreMaster Secre t

Ch angeCipherSpec

Sleutels berekenen

Hands hake Finis hed

ChangeCiphe rSpec H ands hake Finished

Figuur 4.3: overzicht van een simpele SSL handshake

Voor meer details over deze handshake, zie Appendix B, Figuur B.2. Hebben we nu onze doelen bereikt? Stappen 1 en 2 zorgen er inderdaad voor dat er een algoritme wordt bepaald waarmee de verdere beveiligde communicatie zal plaatsvinden. De client krijgt de kans om te zeggen welke algoritmen ondersteund worden en op basis daarvan zal de server een algoritme uitkiezen. Het 2de doel, het uitwisselen van cryptografische sleutels, wordt ook gehaald tijdens de stappen 1 t/m 4. De client krijgt de kans om een geheime string, de pre_master_secret, versleuteld door te sturen naar de server. Nu hebben client en server de pre_master_secret en samen met de random waarden van zowel de client als de server, kan er in stap 4 met behulp van een Key Generator Functie een paar cryptografische sleutels worden gevormd (zie later, sectie 4.4). De meest cruciale stap van het handshakeproces is duidelijk stap 3. De beveiliging van alle gegevens die verstuurd zullen worden, hangt af van de zekerheid waarmee de veiligheid van de pre_master_secret kan worden gegarandeerd. Niet alle stappen die hierboven beschreven worden zijn even evident… Waarom voegen beide partijen bijvoorbeeld random waardes toe aan de handshake? Daarom dat we nu in het kort even 2 aanvallen beschrijven die licht zullen werpen op bepaalde ontwerpkeuzes.

35

4.2.2 Downgrade to export De stappen 5 t/m 8 hebben als functie de handshake zelf te beschermen. Stel je maar eens voor dat de aanvaller de algoritmen, die de client en server in stappen 1 en 2 afspreken om te communiceren, wenst te beïnvloeden. Het is immers vrij normaal dat de client een aantal verschillende algoritmen voorstelt, sommige zwak, andere sterk, om ook communicatie mogelijk te maken met servers die enkel over zwakke ciphers beschikken. De aanvaller zou al deze sterke ciphers kunnen wissen uit de eerste boodschap en de server zo verplichten om een zwak algoritme te gebruiken. Daarom bevatten berichten 6 en 8 een MAC van alle handshakeberichten: bericht 6 bevat een MAC van alle berichten die de client naar de server heeft gestuurd; bericht 8 bevat een MAC van berichten die van de server naar de client gingen. Als een aanvaller geknoeid zou hebben met de beschikbare algoritmen, dan zou dit opvallen bij het vergelijken van de MAC’s. Deze aanval wordt nog uitgebreid besproken in Hoofdstuk 5, sectie 8. 4.2.3 Replay attack Een aanval, waarbij de aanvaller hoopt met parameters van vorige connecties, een nieuwe connectie aan te gaan, noemt met een replay attack. Een aanvaller zou kunnen proberen om met de pre_master_secret van een vorige connectie, een nieuwe connectie aan te gaan, in de hoop dat de cryptografische sleutels die de Key Generator Functie berekent, identiek zijn aan die van de vorige connectie. Vermits de pre_master_secret de basis vormt voor het sleutelmateriaal is dit nog niet zo’n gek idee… Echter, tijdens de handshake wisselen de client en de server ook random getallen uit, en hoewel de aanvaller eventueel de random waarde van een van beide partijen zou kunnen replayen, is het vrijwel onmogelijk om beide random waardes opnieuw hetzelfde te krijgen. De Key Generator Functie gebruikt buiten de pre_master_secret ook deze 2 random waardes om het sleutelmateriaal te genereren. Dit type van aanval wordt dus ook vrijwel uitgesloten.

4.3 SSL Record Protocol 4.3.1 Algemeen Wat we tot nog toe bereikt hebben is de server authenticeren en het vaststellen van sleutelmateriaal. Het hoofddoel van SSL is echter het uitwisselen van geëncrypteerde en geauthenticeerde gegevens. De handshake zorgt ervoor dat beide communicerende partijen zich een een state bevinden waarbij het mogelijk wordt om beveiligde data te versturen en te ontvangen. De eigenlijke gegevenstransfer wordt bij SSL verzorgt door het SSL Record Protocol. Het protocol werkt door de datastroom op te splitsen in fragmenten. Elk indivueel fragment wordt beschermd en dan doorgestuurd. Aan de zijde van de bestemmeling wordt elk individueel record gedecrypteerd en geverifieerd. Deze aanpak maakt het mogelijk dat data verstuurd wordt van zodra ze beschikbaar is en verwerkt kan worden zodra ze aankomt. Maar voor een fragment verzonden kan worden, moet het beschermd worden tegen aanvallen: • Om de integriteit te waarborgen wordt er een MAC berekend over de gegevens van het fragment. De MAC wordt mee verstuurd met het fragment en moet geverifieerd worden door de ontvangende partij. • Het datafragment en de MAC worden dan geconcateneerd en samen geëncrypteerd om de encrypted payload te vormen. • Er wordt nog een header voorzien voor de payload dit samen noemt men het record.

36

Datastroom

Data fragment

Record Header

MAC

Geëncrypteerde data en MAC = encrypted payload Record

Data fragment

...

Record Header

MAC

Geëncrypteerde data en MAC

Figuur 4.4: SSL record, data fragmentatie en data bescherming

De record header zorgt voor extra informatie die de implementatie langs de zijde van de bestemmeling kan gebruiken bij het verwerken van het record. In de praktijk betekent dit hetvolgende: • De content type • De lengte: laat toe aan de implementatie om te weten hoeveel bytes er nog gelezen moeten worden vooraleer er aan de verwerking van het record kan begonnen worden. • SSL versie (redundant) De content type identificeert het soort bericht. We willen immers niet enkel de gegevens zelf beveiligd kunnen doorsturen, maar ook beschermde berichten als er fouten optreden of als we de connectie willen beëindigen. SSL ondersteunt 4 content types: • application_data Alle gegevens die de bovenliggende applicatie via SSL wil versturen vallen in deze categorie. • alert Meestal gebruikt om fouten die optreden tijdens de handshake te melden, maar bijvoorbeeld ook tijdens de data transfer fase als er iets misloopt met het decrypteren of het verifiëren van de MAC. Een alert bericht speelt ook een grote rol bij het sluiten van een connectie. Het feit dat het om een beveiligd bericht gaat, sluit een truncatie aanval uit. • handshake Handshake berichten worden ook in het SSL Record Protocol formaat gegoten. • change_cipher_spec Zodra de handshake het algoritme dat gebruikt gaat worden en de sleutels voor de huidige sessie heeft vastgesteld, wordt dit bericht gebruikt om aan te duiden dat alle volgende berichtgeving gebruik zal maken van deze net vastgelegde parameters. 4.3.2 Truncatie aanval Als we in TCP/IP termen spreken, is het genoeg dat een van beide communicerende partijen een pakketje stuurt met een FIN vlag erin om de connectie (in 1 richting) af te breken. Vermits we er vanuit gaan dat de aanvaller de mogelijkheid heeft om nieuwe pakketjes in het netwerk te injecteren, is het voor een aanvaller dus niet moeilijk om de TCP/IP connectie te verbreken en de gegevensstroom voortijdig af te breken (trunceren). Als de bestemmeling een FIN zou ontvangen zonder een close_notify alert bericht te hebben verwerkt, dan mag de implementatie langs de zijde van de bestemmeling ervan uitgaan dat de verbinding op een abnormale manier is afgesloten. Omdat een alert bericht ook beschermd is d.m.v. een MAC, mag je ervan uitgaan dat als je een close_notify alert ontvangt, deze ook daadwerkelijk afkomstig is van de juiste communicerende partij.

37

4.3.3 Replay aanval Net zoals tijdens de handshake fase moeten we hier ook rekening houden met een mogelijke replay aanval. Tijdens de handshake fase ging het erom dat de aanvaller m.b.v. eenzelfde geëncrypteerde pre_master_secret een nieuwe connectie zou kunnen opzetten. Tijdens de data transfer fase moeten we erop toezien dat de aanvaller geen pakketjes dupliceert. Het TCP protocol voegt zelf al een sequentienummer toe aan de pakketjes, maar een aanvaller zou heel eenvoudig de (geëncrypteerde) inhoud van een vorig pakketje kunnen nemen en dit in een nieuwe pakketje stoppen met een verhoogd sequentienummer en dit nieuwe pakketje in het netwerk injecteren. Als de SSL implementatie deze duplicatie niet zou kunnen opmerken, dan kan de plaintext die de bestemmeling na decryptie verkrijgt, grondig verschillen van de oorspronkelijke plaintext. Om dit fenomeen te voorkomen wordt aan de MAC een sequentienummer toegevoegd, dat er voor SSLv3 als volgt uitziet: SSLv3 MAC = hash(MAC_write_secret + padding2 + hash(MAC_write_secret + padding1 + seq_num + lengh + content)) Voor TLS: TLS MAC = HMAC_hash(MAC_write_secret, seq_num + type + version + length + content) Nu we het toch over MAC’s hebben… Het grootste verschil tussen beide versies is dat er voor TLS is overgeschakeld op HMAC, een gestandardiseerd MAC-algortime, terwijl er voor SSLv3 gebruik wordt gemaakt van een ad-hoc oplossing (die weliswaar erg lijkt op HMAC). seq_num is een 64-bit sequentienummer dat onafhankelijk is voor de client en de server (het eerste bericht van zowel de client als de server hebben dus sequentienummer 0). Als de bestemmeling de ciphertext dus decrypteert en de verkregen plaintext MAC’ed met het juiste sequentienummer, dan pas zal de verificatie van de MAC juist kunnen zijn. Sectie 5.10.3 bespreekt deze aanval in meer detail.

4.4 Sleutel-afleidingsprincipes Zodra de pre_master_secret uitgewisseld is, moet elk van beide partijen deze string omzetten naar de cryptografische sleutels die gebruikt zullen worden voor encryptie en authenticatie. Deze afleiding gebeurt d.m.v. een Key Generator Functie. Deze functie verschilt lichtjes naargelang we spreken over SSLv3 of TLS. We bespreken hier enkel SSLv3. De eerste stap in het sleutel-afleidingsproces is het omvormen van de pre_master_secret in de master_secret. In tweede instantie gebruiken we de master_secret als basis voor het key_block, door een gelijkaardige reeks bewerkingen uit te voeren. Zoals uit Figuur 4.5 blijkt, bestaat de Key Generator Functie uit het herhaaldelijk toepassen van de MD5 en SHA-1 hash-algoritmen.

38

master_secret = MD5(pre_master_secret client_random + MD5(pre_master_secret client_random + MD5(pre_master_secret client_random + key_block = MD5(master_secret + server_random MD5(master_secret + server_random MD5(master_secret + server_random

+ SHA-1(“A” + pre_master_secret + server_random)) + + SHA-1(“BB” + pre_master_secret + server_random)) + + SHA-1(“CCC” + pre_master_secret + server_random)) +

SHA-1(“A” + master_secret + + client_random)) + SHA-1(“BB” + master_secret + + client_random)) + SHA-1(“CCC” + master_secret + + client_random)) +

Figuur 4.5: SSLv3 sleutelafleiding

Merk op: − de volgorde van de random waardes voor client en server worden soms omgedraaid, wat erop wijst dat het gaat om de concatenatie van stringwaarden en niet om de numerieke som. − De constanten “A”, “BB”, … die gebruikt worden, zorgen ervoor dat de output van elke digest anders is, ook al is de input hetzelfde. Uit het key_block worden dan de sleutels voor de huidige connectie gehaald. Afhankelijk van de gebruikte algoritmen hebben we soms wel 3 paar sleutels nodig (telkens een voor de server en een voor de client): • Encryptie sleutels • MAC sleutels • Initializatie vectoren (IV) Random waarde client

Random waarde server

Pre-Master Secret

Master Secret

Key Block

Client MAC

Server MAC

Client symm. key

Server symm. key

Client IV

Server IV

Figuur 4.6: Sleutelafleidingsprincipe

39

4.5 Even recapituleren… Tot nog toe hebben we gezien dat SSL d.m.v. een handshake een stel cryptografische algoritmen overeenkomt en sleutelmateriaal tussen client en server uitwisselt. Zodra deze fase voorbij is, gaan beide partijen over tot de uitwisseling van gegevens: de gegevensstroom wordt gefragmenteerd, de fragmentjes worden geëncrypteerd en er wordt een MAC van het fragmentje mee verstuurd in het SSL Record Protocol: dit zorgt voor de vetrouwelijkheid en de integriteit van de gegevens. We hebben ook het belang gezien van de connectie netjes af te sluiten om een truncatie-aanval uit te sluiten. Voor we ons gaan buigen over de performantie en de effectieve beveiligingskracht van SSL, snijden we nog 2 onderwerpen aan die niet altijd voorkomen bij standaard SSL connecties: • Het hernemen van SSL sessies • Het authenticeren van de client

4.6 Sessies hernemen Verderop, bij het bespreken van de performantie van SSL, zullen we zien dat een volledige SSL handshake vrij duur is, zowel wat betreft de CPU tijd als wat betreft het aantal round trip times nodig voor het bepalen van de parameters (zie ook Figuur 4.3). Om deze kost enigszins te beperken, biedt SSL de mogelijkheid om een vorige sessie te hernemen. Twee partijen die recent nog met elkaar gecommuniceerd hebben, krijgen nu de kans om een groot deel van de handshake over te slaan en veel eerder te beginnen met het verstruren van de gegevens. Het duurste aspect van de handshake is het bepalen van de pre_master_secret en het encrypteren ervan, je valt hiervoor immers terug op publieke sleutel cryptografie, wat computationeel beduidend intensiever is dan symmetrische encryptie. Als je zou toelaten dat een nieuwe connectie dezelfde pre_master_secret mag gebruiken als die van een recente vorige connectie, dan kan je de duurste stap in het handshake proces uitschakelen. 4.6.1 Sessies versus connecties SSL maakt een onderscheid tussen een sessie en een connectie. Een connectie stelt een specifiek communicatiekanaal voor (dat typisch kan teruggebracht worden tot een TCP connectie), samen met de sleutels, de keuzes wat betreft algoritmen, sequentienummerstaat, … Een sessie daarentegen is een virtuele constructie die de gekozen algoritmen en de master_secret voorstelt. Een nieuwe sessie wordt gecreëerd elke keer dat client en server een volledige handshake doorlopen en een nieuwe master_secret vaststellen. Verschillende connecties kunnen geassocieerd zijn met slechts 1 sessie. Alle connecties binnen dezelfde sessie delen dezelfde master_secret, maar hebben wel elk hun eigen encryptiesleutels, MAC sleutels en initializatie vectoren. Het opstellen van nieuwe sleutels voor een nieuwe connectie is absoluut noodzakelijk, want het veelvuldig (her)gebruik van hetzelfde symmetrisch encryptiemateriaal is niet aan te raden: op die manier wordt het voor een cryptanalyst makkelijker om patronen te herkennen in de ciphertext. Het uiteindelijke resultaat hiervan kan zijn dat de plaintext achterhaald wordt. Daarom worden bij het hernemen van een sessie nieuwe sleutels gemaakt op basis van de master_secret en de nieuwe random waardes die bij de ClientHello en ServerHello berichten zaten. 4.6.2 In de praktijk De eerste keer dat een client en een server met elkaar in aanraking komen, creëren ze beide een nieuwe connectie en een nieuwe sessie. Als de server bereid is om sessies te hernemen, dan geeft het de client een session_id mee in de ServerHello boodschap en slaat de master_secret op

40

in een cache voor later gebruik. Als de client dan op een later tijdstip opnieuw wil communiceren met de server, dan wordt de session_id meegegeven in de ClientHello boodschap. De server bevestigt het hergebruik van de sessie door in zijn ServerHello opnieuw de sessie_id te vermelden. Vanaf dit punt wordt een groot deel van de handshake overgeslagen en wordt de master_secret gebruikt om de cryptografische sleutels te berekenen voor de huidige connectie. Client

Server ClientH ello

Serv erHe llo ChangeCip herSpec Han dshake Fi nished

ChangeCiphe rSpe c Hands hake Finis hed

Figuur 4.7: Tijdslijn bij het hernemen van een SSL sessie

Voor een gedetailleerd overzicht van een handshake met sessie-hername, zie Appendix B, Figuur B.4.

4.7 Client authenticatie Tot nog toe hebben we enkel handshakes gezien waarbij enkel de server geauthenticeerd wordt. SSL biedt ook de mogelijkheid om de client cryptografisch te authenticeren. Dit kan bijvoorbeeld handig zijn als bepaalde diensten enkel toegankelijk mogen zijn voor bevoegde individuen. Het idee is dat de client iets tekent met zijn private sleutel en op die manier bewijst dat hij in het bezit is van de private sleutel die overeenkomt met zijn certificaat. De server vraagt aan de client om zich te “legitimeren” door een CertificateRequest bericht te versturen. De client antwoordt hierop met een Certificate bericht (hetzelfde dat de server ook gebruikt om zijn certificaat naar de client over te brengen) en een CertificateVerify bericht. Dat laatste bericht is een string die getekend wordt met de private sleutel, die overeenkomt met het certificaat dat net verstuurd werd. Client authenticatie wordt altijd door de server aangevraagd; het is niet mogelijk dat de client aanbiedt om zichzelf te authenticeren. Het handshakeproces wordt schematisch afgebeeld in Figuur 4.8. Voor een volledige trace en meer details over het handshakemechanisme, zie Appendix B, Figuur B.6. De meest voor de hand liggende vorm van client authenticatie is de combinatie van gebruikersnaam/paswoord. Het feit dat een gebruiker een geldige gebruikersnaam/paswoordcombinatie bezit, duidt aan dat er een zekere vorm van vertrouwen is tussen beide partijen. Het invoeren en verifiëren van deze combinatie vormt hier dus de authenticatie-actie. Authenticatie d.m.v. een certificaat heeft een aantal voordelen t.o.v. de gebruikersnaam/paswoordoplossing: • Paswoorden worden vaak heel slecht gekozen door de gebruiker. Combinaties van initialen, geboortedata van leden van het gezin, straatnamen, telefoonnummers, … worden gekozen omdat ze makkelijk te onthouden zijn.

41

• • •

Vaak worden paswoorden hergebruikt voor verschillende accounts. Paswoorden worden vaak ergens opgeschreven – voor het geval dat… – en op een onveilige plaats bewaard. …

Bovenstaande problemen worden grotendeels weggewerkt bij het gebruik van een certificaat voor client authenticatie. Een groot probleem blijft de verdeling van de certificaten en de rechtsgeldige vaststelling van de identiteit van een certificaathouder. Hier wordt dieper op ingegaan in Hoofdstuk 6.

Client

Server ClientH ello

Serv erHe llo Certificaat CertificateReques t Serv erHelloDo ne

Certifi cate ClientKeyExc hange Certificat eVeri fy ChangeCiphe rSpe c Finish ed

Ch ange CipherSpec Finis hed

Figuur 4.8: Tijdslijn bij client authenticatie

Voor wat betreft het prototype bij Kava hebben we duidelijk wel voor client authenticatie gekozen, als aanvulling op de klassieke gebruikersnaam/paswoord-combinatie. De aard van de gegevens vragen om de best mogelijke bescherming en gezien de magere veiligheidsvoorzorgen die sommige apotheken nemen (o.a. in verband met het maken van backups van zeer gevoelige informatie – die zonder enige beveiliging – open en bloot op de toonbank liggen), leek een dubbel systeem ons hier aangewezen. Het grootste nadeel van certificaten, nl. het vaststellen van de identiteit en het verdelen van de certificaten zelf, is door de vrij beperkte en hechte gebruikersgemeenschap van Kava niet zozeer een probleem.

42

Hoofdstuk 5 SSL onder de loep genomen "If you tell the truth you don't have to remember anything." — Mark Twain

5.1 Inleiding In hoofdstuk 4 hebben we de algemene architectuur van SSL bekeken. We zijn nu op de hoogte van basismechanismen van SSL zoals de handshake en het record protocol. Ook optionele elementen zoals client authenticatie en het hernemen van sessies hebben we aangeraakt. Om nu de effectieve kracht van SSL uit te drukken, moeten we een aantal criteria opstellen waarop we SSL kunnen beoordelen. De 2 voornaamste criteria voor beveiligingsprotocols zijn: 1) Performantie Hoeveel trager zijn SSL connecties t.o.v. gewone connecties die rechtstreeks gebruik maken van TCP? Wat zijn de factoren die de performantie kunnen beïnvloeden, zijn er specifieke bottlenecks, … ? In welke mate wordt de infrastructuur extra belast door de veiligheidsvoorzieningen? 2) Beveiliging Een beveiligingsprotocol zal inherent bepaalde eigenschappen bezitten waardoor de gegevens veilig overgebracht kunnen worden. Niettemin kunnen er, enerzijds door bepaalde ontwerpkeuzes voor het protocol en anderzijds door een gebrekkige installatie en toepassing van de mogelijkheden van het systeem, zwakke punten ontstaan in het beveiligingsmechanisme… Het eerste deel van dit hoofdstuk kaart de performantie van SSL aan. We maken hierbij gebruik van performantiegegevens die we hebben verzameld in een real life situatie tijdens de ontwikkeling van het prototype voor Kava, maar ook van performantiegegevens verzameld in een ideale netwerksituatie (i.e. waarbij de performantie van het netwerk zoveel mogelijk uitgeschakeld wordt). In het 2de deel bekijken we een aantal categoriën van mogelijke aanvallen tegen het protocol. Hierna bespreken we ook een aantal heel specifieke hacks, waaronder de downgrade to export hack die we eerder al hebben aangehaald.

43

Deel I: het performantie-criterium

5.2 Wat verstaan we onder performantie van een beveiligingsprotocol? De meest voorkomende klacht van zowel systeembeheerders als gebruikers is dat SSL traag is. Deze kritiek is uiteraard niet helemaal ongegrond, want afhankelijk van welke algoritmen precies gebruikt worden en afhankelijk van de netwerkomgeving, kan een SSL connectie zowaar 2 tot 100 keer trager zijn dan een klassieke TCP connectie [Rescorla2000]. De performantie van een protocol zoals SSL nagaan is een ingewikkelde zaak. We zouden één groot experiment kunnen maken, een realistische situatie, maar de conclusies die we daaruit kunnen trekken zijn beperkt, er zijn immers te veel factoren waar we rekening mee moeten houden en die we – zeker in het geval van een publiek netwerk – niet altijd onder controle kunnen houden tijdens het experiment. Om die reden bespreken we de performantie van SSL in stukjes: • De handshake (sectie 5.3) We zetten een experiment op waarbij we de performantie van de handshake kunnen bestuderen zonder de invloed van het netwerk. • De gegevenstranfserfase (sectie 5.4) We bekijken welke factoren de snelheid van de gegevenstransferfase kunnen beïnvloeden. Ook deze fase bekijken we los van het netwerk. • Invloed van het netwerk (sectie 5.5) We gaan na welke parameters van het netwerk de performantie van SSL beïnvloeden. Dit doen we aan de hand van een theoretisch model. • Reële situatie (sectie 5.6) Tenslotte interpreteren we een aantal resultaten van performantiegegevens die we hebben verzameld tijdens een real-life situatie tijdens onze stage op Kava. Voordat we ons echter aan bovenvermelde tests wagen, bespreken we kort de 2 belangrijkste factoren die een rol spelen voor wat betreft de performantie van SSL: 1) De parameters en de toestand van het netwerk, vooral de begrippen bandbreedte en latency zijn belangrijk (zie sectie 5.2.1). 2) De performantie en de belasting van de eindstations. We maken ook nog een onderscheid tussen de client en de server (soms gaat het in het geval van de server zelfs over een cluster van werkstations als het om een vaak geraadpleegde bron van informatie gaat) (zie sectie 5.2.2). 5.2.1 Het netwerk Intuïtief weten we dat netwerksystemen bestaan uit veel clients en een paar servers. Bij dergelijke systemen wordt traagheid langs de clientside gekenmerkt door een verhoogde latency, terwijl aan de zijde van de server vertraging verklaard kan worden door verhoogde latency en verlaagde doorvoer. Een anekdote: “Never underestimate the bandwidth of a station wagon full of tapes.” – Dr. Warren Jackson Stel dat we een bestand van 100 MB willen doorsturen. Een klassieke analoge verbinding (met compressie) heeft hier ongeveer 3 uur voor nodig. Dezelfde file op een tape zetten duurt ongeveer 10 minuten. Als we deze tape dan versturen via de post dan duurt het ongeveer 3 dagen eer de informatie is overgebracht. Op zich zou je zeggen dat dit vreselijk lang is, maar stel je voor dat je een heleboel van die 100MB-files moet versturen. Met een modem kan je er maar 8 per dag versturen, maar je kan er wel een hondertal per dag op tape zetten. Toegegeven, de eerste file komt dan pas 3 dagen later aan, maar ze komen wel allemaal tegelijk aan.

44

Dit voorbeeld duidt het verschil aan tussen latency en bandbreedte. Latency is de hoeveelheid tijd tussen het begin en het einde van een bepaalde transactie. Bandbreedte is het totaal aantal transacties dat je kan ondersteunen tijdens een bepaalde periode. Laten we deze begrippen nu eens bekijken aan de hand van het netwerkvoorbeeldje van Figuur 5.1:

/s Kb 8 . 28

1.5 Mb/s Server

Internet

IBM Compatible

28 28.8 Kb/s .8 Kb /s

Laptop computer

iMac Figuur 5.1: Basisnetwerk

•

•

• •

Geval 1: In bovenstaande omgeving (Figuur 5.1) kan de server ongeveer 50 clients bedienen (netwerkconnecties volledig benut aan de kant van de client). Elke 1 MB file versturen duurt ongeveer 300s (1 MB ∗ 1024 ∗ 8 / 28.8 Kb/s). De doorvoer is dus ongeveer 1.5 Mb/s, terwijl de latency 300s bedraagt. Geval 2: Als we het aantal clients verdubbelen, probeert de server nog steeds om ze allemaal op gelijke voet te behandelen, met als gevolg dat ze ieder maar de helft van de data krijgen op dezelfde tijdspanne. De latency verdubbelt dus naar 600s. De bandbreedte blijft identiek, want we bedienen 2 keer zoveel clients aan halve snelheid. Geval 3: Reduceren we de snelheid van de clients tot 14.4 Kb/s, dan verhoogt de latency tot 600s, maar het aantal clients dat we kunnen bedienen verdubbelt, dus de bandbreedte blijft onaangetast. Geval 4: Halveren we de snelheid van de serverconnectie en houden we het aantal clients constant, dan halveert de bandbreedte en verdubbelt de latency.

Dit effect treedt ook op als de bottleneck de CPU is i.p.v. de netwerk-I/O en dit is juist een situatie die kan onstaan als de CPU belast wordt met cryptografische operaties zoals duidelijk het geval is bij SSL. We concluderen dat langzame clients ruimte vrijlaten voor andere clients die willen connecteren. Langzame servers daarentegen vertragen het hele systeem. 5.2.2 De eindstations Nu we een zicht hebben op het netwerkgedeelte van de performantie, moeten we ons nog afvragen in welke mate de snelheid van de eindstations het geheel beïnvloedt. Het loont de moeite om de 2 fasen van een SSL connectie – de handshake en het eigenlijke versturen van gegevens – apart te beschouwen. De handshake gebeurt maar 1 keer per connectie, maar is relatief gezien duur. En hoewel er heel wat meer SSL records moeten geëncrypteerd worden, is deze operatie een stuk goedkoper.

45

5.3 Performantie van de handshake In deze sectie bestuderen we de performantie van de 3 types van handshakes. We gaan na welke stappen in het handshakeproces het meest kostelijk zijn. Hiervoor hebben we een experiment opgezet, waarvoor we slechts één werkstation gebruiken. Hiermee bereiken we 2 doelen: • We schakelen het netwerk uit: alle netwerkcommunicatie verloopt nu via de kernel van het besturingssysteem van het werkstation. • We kunnen de kost van de handshake voor de client en de server tegen elkaar afwegen: we zijn er immers zeker van dat de performantie van client en server hetzelfde zijn. Het werkstation dat we gebruiken, heeft volgende kenmerken: Intel Pentium 200 MHz (zonder MMX) Linux Redhat 7.1 (kernel 2.4.2-2) 40 MB EDO RAM We kiezen expliciet voor Linux om gebruik te kunnen maken van SSLDump, een programma dat toelaat zeer gedetailleerde traces van SSL connecties te maken. Voor de SSL client en server gebruiken we OpenSSL, versie 0.9.6. Voor meer informatie omtrent deze 2 softwarepakketten verwijzen we naar Appendix B. We maken bovendien een onderscheid tussen de client en de server: het gros van de handshakes zijn immers asymmetrisch. Asymmetrisch omdat de client de pre_master_secret moet encrypteren met de publieke (RSA) sleutel (teruggevonden op het servercertificaat), terwijl de server deze moet decrypteren met zijn private sleutel. Handshakes waarin client authenticatie wordt toegepast, kunnen we als symmetrisch bestempelen: hier moeten client en server ieder één publieke en één private sleutel-operatie uitvoeren. Figuur A.6 van Appendix A (met een comparatieve kost van RSA operaties op 3 platforms) laat duidelijk zien dat publieke operaties veel goedkoper uitvallen dan private operaties. M.a.w. de client wordt beduidend minder zwaar belast met het encrypteren van de pre_master_secret, dan de server met het decrypteren ervan. We gaan nu de performantie na van de 3 handshakes die we in het vorig hoofdstuk hebben geïntroduceerd. 5.3.1 Simpele handshake New TCP connection #1: pentium200(1034) <-> pentium200(443) 1 1 1 1 1 1 1 1 1

1 2 3 4 5 6 7 8 9

0.0100 0.0200 0.0200 0.0200 0.0300 0.0300 0.0300 0.3300 0.3300

(0.0100) (0.0100) (0.0000) (0.0000) (0.0100) (0.0000) (0.0000) (0.3000) (0.0000)

C>S S>C S>C S>C C>S C>S C>S S>C S>C

SSLv2 compatible client hello Handshake ServerHello Handshake Certificate Handshake ServerHelloDone Handshake ClientKeyExchange ChangeCipherSpec Handshake Finished ChangeCipherSpec Handshake Finished

Client

Server ClientHello ServerHello Certificate one ServerHelloD ClientKeyE xchange ChangeCip herSpec Handshake Finished herSpec ChangeCip Finished Handshake

Figuur 5.2: Tijdsverloop simpele SSL handshake (client + server op 1 machine; tijd in seconden)

46

Figuur 5.2 laat een trace zien van een simpele SSL handshake. Zoals we zien geeft de 5de kolom van de trace aan in welke richting het bericht vloeit: van C>S betekent van de client naar de server, S>C wijst op het omgekeerde traject. Twee waarden zijn in het grijs aangestreept: de eerste waarde geeft aan hoeveel tijd een 200 MHz (client)machine besteedt aan het versleutelen van de pre_master_secret met een publieke sleuteloperatie; de 2de waarde geeft de overeenkomstige private sleuteloperatie weer die door de server moet worden uitgevoerd. De decryptie-operatie m.b.v. de private sleutel aan de kant van de server is duidelijk de meest intensieve operatie in het hele proces. In een systeem waarbij veel clients een beveiligde connectie willen opzetten, maakt dit de server uiterst gevoelig voor bottlenecks. Opmerking: Bovenstaande trace houdt echter geen rekening met het verifiëren van het servercertificaat, i.e. de client zal vaak willen vaststellen of het aangeboden servercertificaat van een gekende uitgever (Certificate Authority of kort CA) komt, deze operatie neemt een extra 100ms in beslag langs de zijde van de client. 5.3.2 Sessie hernemen handshake We kunnen ons nu afvragen hoe de performantie beïnvloed wordt als we gebruik maken van session resumption. In het vorige hoofdstuk hebben we gezien dat bij het opzetten van een nieuwe connectie binnen dezelfde sessie, er geen pre_master_secret moet worden uitgewisseld: de pre_master_secret wordt hergebruikt en dus moet er geen geheim worden overgebracht. Als er geen pre_master_secret wordt uitgewisseld, is er ook geen nood aan – asymmetrische – encryptie tijdens de handshake, waarmee we dus de meest kostelijke stap gewoon uitschakelen… New TCP connection #37: pentium200(3945) <-> pentium200(443) 37 37 37 37 37 37

1 2 3 4 5 6

0.0100 0.0100 0.0100 0.0100 0.0100 0.0100

(0.0100) (0.0000) (0.0000) (0.0000) (0.0000) (0.0000)

C>S S>C S>C S>C C>S C>S

Client

Handshake ClientHello Handshake ServerHello ChangeCipherSpec Handshake Finished ChangeCipherSpec Handshake Finished

Server ClientHello ServerHello herSpec ChangeCip Finished Handshake ChangeCip herSpec Handshake Finished

Figuur 5.3: Tijdsverloop handshake met hernomen sessie (client + server op 1 machine; tijd in seconden)

Zoals duidelijk blijkt uit de trace, is deze handshake veel goedkoper. Maar bij deze techniek kan de performantie wel op een andere manier beïnvloed worden… Zowel client als server moeten een cache bijhouden van sessies die ze recentelijk hebben gebruikt. Aan de clientside lijkt dit niet zo’n groot probleem, omdat een client niet met honderden servers zal praten, maar een server daarentegen moet een enorm grote cache bijhouden om, per client die hem recentelijk heeft gecontacteerd, gegevens bij te houden over de sessie. Het doorzoeken van een overdreven grote sessiecache kan duidelijk een negatieve invloed uitoefenen op de performantie en de tijd die stap 2 (grijs opgelicht) nodig heeft, vergroten. Daarom worden entries in de sessiecache, die een bepaalde tijd niet meer gebruikt werden, na verloop van tijd verwijderd.

47

Niettemin kunnen we stellen dat het hernemen van sessies de performantie wel degelijk ten goede kan komen, zeker in situaties waar clients op korte tijd vaak contact opnemen met een server. 5.3.3 Handshake met client authenticatie Om ons performantie-overzicht wat betreft de handshakefase compleet te maken, moeten we het enkel nog hebben over de handshake met client authenticatie. De berichten die werden aangepast t.o.v. van de klassieke handshake, zijn grijs gemarkeerd in Figuur 5.4: • Bericht 4: De ServerHelloDone werd lichtjes aangepast en bevat nu ook een verzoek aan de client om een certificaat op te sturen. Deze aanpassing heeft weinig invloed op het tijdschema. • Bericht 5: De client stuurt zijn certificaat naar de server. Het controleren van het clientcertificaat t.o.v. de de door de server gekende CA-certificaten is hier de vertragende factor. • Bericht 7: De client tekent een kort berichtje m.b.v. zijn private sleutel en stuurt dit door naar de server. De client moet hier dus een dure private sleuteloperatie uitvoeren. M.b.v. de publieke sleutel die de server heeft verkregen in bericht 5, kan de server nagaan of het wel degelijk de client is die deze string heeft getekend. De kost van deze verificatie bedraagt dus 1 publieke sleutel-operatie. Het probleem van de trace in Figuur 5.4 is dat de exacte kost van de individuele operaties moeilijk in te schatten valt. Bericht 9, het Finished bericht, duurt bijvoorbeeld enorm lang. We vinden geen “normale” verklaring binnen het SSL schema voor deze vertraging. Een mogelijke verklaring voor deze vreemde timings is het Principe van Nagle dat in sectie 5.5.2 wordt besproken. New TCP connection #1: pentium200(3950) <-> pentium200(443) 1 1 1 1

1 2 3 4

0.0100 0.0200 0.0200 0.0200

(0.0100) (0.0100) (0.0000) (0.0000)

C>S S>C S>C S>C

1 1 1 1 1 1 1

5 6 7 8 9 10 11

0.1800 0.1800 0.1800 0.1800 0.4000 0.4200 0.4200

(0.1600) (0.0000) (0.0000) (0.0000) (0.2200) (0.0200) (0.0000)

C>S C>S C>S C>S C>S S>C S>C

SSLv2 compatible client hello Handshake ServerHello Handshake Certificate Handshake CertificateRequest ServerHelloDone Handshake Certificate Handshake ClientKeyExchange Handshake CertificateVerify ChangeCipherSpec Handshake Finished ChangeCipherSpec Handshake Finished

Client

Server ClientHello o ServerHell Certificate Request Certificate oDone ServerHell Certificate ClientKeyE xchange Certificate Verify ChangeCip herSpec Finished herSpec ChangeCip Finished

Figuur 5.4: Tijdsverloop SSL handshake met client authenticatie (client + server op 1 machine; tijd in seconden)

Een conclusie die we wel kunnen trekken is dat de handshake met client authenticatie beduidend langer duurt door de extra publieke sleutel operaties… Bovendien wordt de client nu ook duidelijk zwaarder belast, omwille van de private sleuteloperatie die vereist is voor het zetten van de handtekening.

48

Als referentiepunt kunnen we de totale duur van deze handshake vergelijken met die voor de klassieke handshake, respectievelijk 420 ms t.o.v. 330 ms. 5.3.4 Overzicht Figuur 5.5 geeft in het kort weer wat de performantieverschillen zijn tussen de verschillende handshakes. Het is duidelijk dat de handshake die een vorige sessie herneemt en zodoende gespaard blijft van de dure cryptografische operaties, het minst kostelijk is. De handshake met client authenticatie is slechts een klein beetje langzamer, maar dit ligt binnen de verwachtingen: deze performantiehandicap is toe te schrijven aan de extra publieke sleutel operaties. Type handshake Klassiek Sessie hernemen Client authenticatie

Totale duur handshake 330 ms 10 ms 420 ms

Figuur 5.5: Overzicht performantie van 3 verschillende SSL handshakes

5.4 Gegevenstransfer Als de handshake is afgelopen, wordt overgegaan tot het versturen van de eigenlijke data van de applicatie. Zoals we in het vorige hoofdstuk hebben gezien wordt de datastroom opgesplits in datafragmenten. Zo’n datafragment vormt de basis voor het SSL record. Op de data worden 2 operaties uitgevoerd: • Er wordt een MAC gemaakt van het datafragment. • Het datafragment geconcateneerd met de MAC wordt versleuteld d.m.v. een symmetrisch versleutelingsalgoritme. Encryptie-algoritme/hash-algoritme RC4-MD5 RC4-SHA DES-CBC-SHA DES-CBC3-SHA

KB/s 15034 10831 4758 2068

Figuur 5.6: SSL record verwerkingssnelheid op een Pentium 2 300 MHz (bron: [Rescorla2000], p. 198)

Merk op dat volgens Figuur 5.6 totzelfs de traagste combinatie – Triple DES met Cipher Block Chaining voor versleuteling en SHA als hash algoritme – op een Pentium 2 300 MHz nog steeds meer dan 2MB per seconde kan verwerken. Dit is ruim voldoende om een 10Mbit link te verzadigen (immers 2MB/s = 16Mb/s). Tenzij bijvoorbeeld de server overspoeld wordt met connecties, kan een moderne computer deze operaties wel aan. Het is echter de combinatie van: • Symmetrische encryptie operaties tijdens de gegevenstransfer • Asymmetrische encryptie operaties tijdens de handshake • Sleutelafleidingsproces voor het maken van nieuw sleutelmateriaal • Behandelen van netwerkverkeer • Het ophalen van (dynamische) webpagina’s …die ervoor kan zorgen dat de server de bottleneck wordt in het SSL schema. Druk bezette servers zijn dan ook meestal multiprocessormachines of clusters van werkstations, vaak elk met een specifieke functie (één machine voor encryptie, één machine als webserver, …). Opmerking: Zoals we ook al in ons overzicht van de cryptografische algoritmen hebben aangehaald, is er geen echt performantievoordeel bij het gebruik van exporteerbare sleutellengtes voor symmetrische

49

algoritmen. Er wordt immers altijd gebruik gemaakt van hetzelfde algoritme voor korte of lange sleutels: de sleutel wordt intern toch omgezet tot een keystream, waardoor de sleutellengte geen invloed heeft op de snelheid van het encryptie- en/of decryptieproces.

5.5 Invloed van het netwerk Nu we een idee hebben van de belasting van het handshake proces en de gegevenstransfer fase, bekijken we in welke mate de conditie van het netwerk een rol kan spelen voor SSL. De gegevens die we tot nog toe hebben gebruikt, komen van programma’s die op dezefde computer lopen en die rechtstreeks met elkaar communiceren via de kernel van het besturingssysteem, zonder dat er zich dus een reëel netwerk tussen bevindt. We moeten er echter rekening mee houden dat er in een netwerk wel degelijk vertragingen kunnen optreden, in deze paragraaf gaan we na welke factoren een rol spelen. 5.5.1 Theoretisch standpunt Client

Server

Cl ien tH

st

nse

c onne c tion

ell o

Hello S erv er ate Cer tific one rHell oD Se rv e

RTT

r espo

Setup T CP

RTT

HTTP

r eque

Server

RTT

HT T P

Client

RTT

T CP c onn ec ti on

Tijd

S etup

Cl ientK ey Ex c han ge Chang e Ciphe rS pec HandS hake F i nishe d

HTTP

req ues t

se r es pon

RTT

HT T P

RTT

erSpe c eCiph g n a h C inishe d hak e F Hands

Figuur 5.7: Timing van een HTTP connectie versus HTTPS connectie

In de literatuur over SSL wordt de performantiehandicap van SSL altijd in verband gebracht met de latency van het netwerk. Door de timings van een gewone HTTP connectie en een HTTP connectie via SSL (HTTPS) naast elkaar af te beelden in Figuur 5.7, hebben we getracht om na te gaan waarom precies de latency zo’n belangrijke rol speelt. Centraal in onze bespreking van de invloed van het netwerk stellen we het begrip Round Trip Time (RTT). Een RTT is de tijd die nodig is om 1 berichtje van de client naar de server te sturen en terug. Aan de hand van het verschil in RTT’s tussen een HTTP en een HTTPS connectie kunnen we dan nagaan welke invloed de latency heeft. Immers, de waarde van 1 RTT is sterk gerelateerd aan de latency van het netwerk.

50

In de literatuur hebben we nergens opgemerkt dat de performantiehandicap die toegeschreven wordt aan SSL, veroorzaakt wordt door een verhoogd aantal RTT’s. Niettemin maakt Figuur 5.7 onmiddellijk duidelijk dat een HTTP connectie toekomt met 2 RTT’s voor het opvragen van een kleine HTML pagina, terwijl een HTTPS connectie daar 4 RTT’s voor nodig heeft. Als we nu bijvoorbeeld zouden stellen dat de RTT tussen 2 eindstations op een bepaald netwerk 100 ms bedraagt, dan zien we onmiddellijk dat: • HTTP: 2 RTT’s 200ms • HTTPS: 4 RTT’s 400ms We kunnen dus duidelijk stellen dat het opzetten van een beveiligde verbinding beduidend langer duurt. Bovendien houden we in bovenstaand schema enkel rekening met de latency van het netwerk, want als de bandbreedte ook in rekening wordt gebracht, dan zal HTTPS hier duidelijk ook minder goed uitkomen, omdat de berichten vaak ook langer zijn (een bericht dat een certificaat bevat neemt over het algemeen meer plaats in dan een HTTP request). Merk op dat we het hier uitsluitend over de handshake fase hebben gehad. Wat betreft de gegevenstransfer fase zijn de verschillen met gewone HTTP verwaarloosbaar. De pakketjes worden weliswaar groter door de overhead gecreëerd door het encryptieproces en de authenticatiedata, maar niettemin is de invloed hiervan op het netwerk zeer beperkt. 5.5.2 Het algoritme van Nagle Bron: [Rescorla2000], blz. 212 Onder bepaalde omstandigheden interageert SSL slecht met de verschillende congestion control mechanismen van TCP. Zowel client als server kunnen in een wachttoestand terechtkomen, terwijl ze eigenlijk verder willen handshaken. De oorzaak hiervan is het algoritme van Nagle [RFC0896]. Het doel van het algoritme van Nagle is het verminderen van het aantal tinygrams: kleine pakketjes die verstuurd worden. Het probleem is de TCP header: TCP segmenten hebben een minimum packetgrootte van 40 bytes. Als er slechts 1 karakter per segment wordt verstuurd, worden er steeds 41 bytes op de draad gezet. Dit kan snel tot een opeenhoping in het netwerk leiden. Onder normale omstandigheden stuurt de kernel een pakket uit voor elke aanroep van write(), een situatie die er snel toe kan leiden dat het netwerk verzadigd raakt met kleine pakketten. Het Nagle algoritme vermijdt dit op een heel simpele manier: als er uitstaande data is, die verstuurd maar niet bevestigd (geacknowledged of kortweg ge’ACK’ed) werd, dan laat de TCP implementatie niet toe dat er kleine pakketten worden verstuurd. In deze situatie wordt de data gebufferd en wordt de gehele buffer verstuurd bij ontvangst van een ACK. Normaal gezien werkt dit zeer goed, maar zoals we zo meteen zullen zien, zorgt dit voor problemen in combinatie met SSL. Een 2de oorzaak van het probleem is een techniek die delayed ACK heet. In plaats van een ACK te genereren zodra het pakket wordt ontvangen, wacht de TCP implementatie vaak en probeert om de bevestiging mee te sturen met een bericht dat in de andere richting reist: dit heet piggybacking. Het principe is als volgt: de TCP implementatie wacht 200 ms; als er binnen die tijd een pakket opduikt, dan wordt er piggybacking toegepast, anders wordt er na het verstrijken van de tijd alsnog een ACK naar het netwerk geschreven. Een goed voorbeeld hiervan is de situatie die onstaat als een SSL sessie hernomen worden. Figuur 5.8 laat een netwerktrace zien van een dergelijke connectie. Het meest interessante aan deze trace is de 148 ms vertraging die optreedt tussen het Finished bericht en de application_data. Deze 148 ms zijn veel langer dan de tijd die nodig is om het te versturen record klaar te maken!

51

New TCP connection: 1 0.0003 (0.0003) 2 0.0028 (0.0024) 3 0.0028 (0.0000) 4 0.0028 (0.0000) 5 0.0039 (0.0011) 6 0.0039 (0.0000) TCP ACK komt 7 0.1517 (0.14777) 8 0.1530 (0.0014)

localhost(2830) <-> localhost(4433) C>S Handshake ClientHello S>C Handshake ServerHello S>C ChangeCipherSpec S>C Handshake Finished C>S ChangeCipherSpec C>S Handshake Finished aan op tijdstip 0.1516 C>S application_data S>C application_data

Figuur 5.8: Het Nagle algoritme in combinatie met session resumption

Wat is er dan onderweg wel gebeurd? • De client TCP stack wacht op de ACK van het Finished bericht, vooraleer het eerste SSL record te versturen dat application_data bevat (een gevolg van het Nagle algoritme). • De server TCP stack wacht met het versturen van de ACK, omdat de implementatie delayed ACK ondersteunt. deadlock! De deadlock wordt doorbroken als de delayed ACK timer van de server verloopt en de server alsnog een ACK stuurt. Zodra de client deze ACK ontvangt, stuurt deze het eerste SSL record met application_data. Het is mogelijk om het Nagle algoritme uit te schakelen, via de zogenaamde TCP_NODELAY optie in de sockets API. Met deze optie uitgeschakeld worden de gegevens wel onmiddellijk naar het netwerk geschreven door de TCP stack (zolang er uiteraard plaats is in het TCP window.). New TCP connection: 1 0.0006 (0.0060) 2 0.0016 (0.0010) 3 0.0016 (0.0000) 4 0.0016 (0.0000) 5 0.0028 (0.0012) 6 0.0028 (0.0000) 7 0.0046 (0.0018) 8 0.0059 (0.0013)

localhost(2850) <-> localhost(4433) C>S Handshake ClientHello S>C Handshake ServerHello S>C ChangeCipherSpec S>C Handshake Finished C>S ChangeCipherSpec C>S Handshake Finished C>S application_data S>C application_data

Figuur 5.9: Session resumption met het Nagle algoritme uitgeschakeld

Deze situatie wordt geschetst in Figuur 5.9: de client stuurt de application_data onmiddellijk na het Finished bericht, waardoor de tijd nodig om de handshake uit te voeren drastisch beperkt wordt.

52

5.6 Reële situatie Bovenstaande cijfers zijn allemaal goed en wel, maar het blijft allemaal vanuit een theoretisch standpunt bekeken. Tijdens de ontwikkeling van het prototype voor Kava hebben we daarom een tweede experiment uitgevoerd. Dit experiment had niet tot doel een exacte performantie-analyse toe te laten, maar diende eerder tot het bekomen van realistisch cijfermateriaal. Een aantal onderdelen van het experiment zijn vast, met name de snelheid van de client werkstations (AMD Athlon 800 MHz) en de snelheid waarmee de server (Pentium 733) verbonden is met het Internet (128 Kb/s ISDN lijn). Enkel de snelheid waarmee de client verbindt met het Internet laten we variëren: 1) ADSL9 lijn: deze lijn wordt gekenmerkt door zijn hoge doorvoer en beperkte latency. 2) PSTN10 lijn: deze lijn heeft een beperkte doorvoercapaciteit en een veel hogere latency. Merk op dat beide lijnen asymmetrisch zijn: de snelheden voor stroomopwaarts en stroomneerwaarts verschillen. Zie Figuur 5.10 voor de exacte testsetup.

PS

Standaard werkstation met Java programma om tijd van verbindingen te meten.

TN 56Kb/ sd 33,6K ownstream , b/s up stream

Internet

128Kb/s ISDN Pentium 733

DSL

Standaard werkstation met Java programma om tijd van verbindingen te meten.

A m, nstrea /s dow m 1 M b /s upstrea b 12 8K

Intel Pentium 3 733 MHz Redhat 7.1 (kernel 2.4.2-2) 256 MB SDRAM Apache webserver met SSL

Figuur 5.10: Test-setup voor het prototype bij Kava

De test bestaat eruit dat we 4 gevallen creëren: 1) ADSL in combinatie met gewone HTTP 2) PSTN in combinatie met gewone HTTP 3) ADSL in combinatie met HTTPS 4) PSTN in combinatie met HTTPS Voor elk van de 4 gevallen laten we een client 10 kleine webpagina’s opvragen en berekenen we hoe lang het gemiddeld duurt om 1 pagina op te vragen. Let er wel op dat er bij SSL een gemiddelde wordt genomen van 1 nieuwe sessie en 9 hernomen sessies. Deze test probeert een reële situatie na te bootsen, vandaar het expliciete gebruik van session resumption. (Voor de volledigheid: we gebruiken in dit geval géén client authenticatie). Als we Figuur 5.11 beschouwen, moeten we ons wel realiseren dat de resultaten een combinatie zijn van een groot aantal parameters, sommige bekend, de meeste onbekend. We kennen de snelheden van de eindstations, de snelheden van de connecties naar het Internet toe, maar de belasting van het netwerk, eventueel vertragingen en/of pannes zijn onbekende factoren. Bovendien brengt zo’n concrete test ook vertragingen die kunnen ontstaan bij de eindpunten door encryptie/decryptie, het opzoeken van de webpagina, … in rekening. De basisgevallen voor wat betreft ons onderzoek zijn de gewone HTTP connecties, enerzijds via ADSL, anderzijds via PSTN. Onmiddellijk blijkt dat er een behoorlijke performantiekost bestaat voor HTTPS t.o.v. HTTP. 9

ADSL: Asymmetric Digital Subscriber Line PSTN: Public Switched Telephone Network

10

53

SSL in netwerkomgeving 2500 2210.1

2000

Tijd (ms)

1500

999.6

1000

905.3

500 317.5

0 HTTP via ADSL

HTTPS via ADSL

HTTP via PSTN

HTTPS via PSTN

Type connectie

Figuur 5.11: Performantiegegevens van SSL in netwerkomgeving

De eindstations blijven in de test-setup constant, dus kunnen we er vanuitgaan dat de verwerkingstijden min of meer hetzelfde zijn ongeacht het type verbinding. Wat meteen opvalt is dat een PSTN verbinding 1,2 s trager is dan een ADSL verbinding voor wat betreft SSL verbindingen, terwijl dit verschil voor gewone HTTP slechts uitkomt op 0,59 s, ongeveer de helft dus. Dit is dus voornamelijk toe te schrijven aan de extra RTT’s die nodig zijn voor SSL. Voor een onbelaste server blijkt de toestand van het netwerk dus een grote rol te kunnen spelen: de latency is cruciaal voor de performantie van verbindingen beveiligd d.m.v. SSL.

54

Deel II: het beveiligingscriterium

5.7 Wat weten we over beveiliging? In hoofdstuk 3 – tijdens het overzicht van een aantal protocollen – hebben we duidelijk gesteld dat we op zoek zijn naar eenvoudige, goed gestructureerde protocollen. Als je immers de effectieve beveiligingskracht van een beveiligingsmechanisme wil nagaan doe je dit in de eerste plaats door een grondige analyse en niet zozeer door proefondervindelijkheid. In de volgende paragrafen gaan we op zoek naar een aantal zwakke punten in het SSL mechanisme. We bekijken een aantal gevallen: niet om aan te duiden hoe goed of hoe slecht SSL wel is, maar om aan te geven dat mogelijke aanvallers zoeken naar structurele gebreken van het mechanisme. We zullen zien dat totzelfs de meest voor de hand liggende aanvallen van zoveel factoren afhangen, dat de kans op een geslaagde aanval zo klein wordt dat we er eigenlijk niet meteen wakker van moeten liggen. Met een goede configuratie van de server zijn de meeste problemen trouwens perfect op te lossen. Maar laten we eerst even recapituleren… In hoofdstuk 2 hebben we tijdens het opstellen van het threat model gezien dat aanvallen onderverdeeld kunnen worden in 2 categoriën: • die van de actieve aanvallen waarbij de aanvaller probeert pakketjes in het netwerk te injecteren. Het kan gaan om geheel nieuwe pakketjes, maar ook om bestaande pakketjes die de aanvaller heeft aangepast. • die van de passieve aanvallen waarbij de aanvaller enkel de inhoud van de pakketjes inkijkt, maar zelf geen veranderingen aanbrengt. Bovendien weten we meer specifiek over SSL dat het protocol uiteenvalt in 2 delen: de handshakefase waarin een aantal afspraken over algoritmen worden gemaakt en een basisgeheim wordt uitgewisseld en de gegevenstransferfase waarin de eigenlijke data verstuurd wordt. Net zoals bij de bespreking van de performantie, bekijken we ook voor wat betreft de beveiliging deze 2 fasen apart. Verder bestuderen we ook of de verschillende mechanismen wel juist worden toegepast. Zo gaan we in op het aspect van authenticatie en kijken of dit juist in de praktijk wordt gebracht. Opmerking: Onderstaande bespreking is uiteraard verre van volledig en dient voornamelijk ter illustratie van zowel de sterke als de zwakke kanten van SSL. De beschrijvingen van aanvallen komen uit: [WagnerEtAl1997], [Rescorla2000].

5.8 Veiligheid van de handshake De handshake bestaat eruit dat client en server het eens worden over een voor beide partijen aanvaardbaar encryptie-algoritme, dat ze random waarden uitwisselen en dat de client de pre_master_secret geëncrypteerd doorstuurt. Beide eindpunten kunnen dan overgaan tot het afleiden van de master_secret en cryptografische sleutels waaronder de sessiesleutels. Twee kritieke punten kunnen onderscheiden worden tijdens het handshakeproces: • Een eventueel compromis van de pre_master_secret: indien de aanvaller op de hoogte is van de pre_master_secret, dan is de aanvaller ook op de hoogte van alle gebruikte sleutels tijdens de datatransferfase. M.a.w. confidentialiteit en integriteit kunnen niet meer gegarandeerd worden.

55

•

Het vaststellen van de algoritmen die gebruikt gaan worden tijdens de datatransferfase: we proberen algoritmen te selecteren die krachtig genoeg zijn voor de gevoeligheid van de data die we wensen te versturen.

5.8.1 Ciphersuite rollback of downgrade to export aanvallen Een goed voorbeeld van een actieve aanval is er eentje waarbij de aanvaller probeert de beveiligde verbinding een export cipher te laten gebruiken. Tot voor kort waren bepaalde sterke encryptiealgoritmen immers voorbehouden voor gebruik binnen de Verenigde Staten van Amerika en mochten deze niet uitgevoerd worden (de zogenaamde domestic ciphers). Vandaar dat SSL de mogelijkheid gaf om voor zwakkere encryptie-algoritmen te kiezen tijdens de handshake. Als echter zowel de client als de server beschikken over 128-bit encryptie-algoritmen, dan zal de server in principe voor zo’n sterke cipher kiezen. C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA Figuur 5.12: Ciphersuite rollback of downgrade to export

Als de aanvaller echter het Hello bericht van de client onderschept en zoals in Figuur 5.12 de sterke vormen van encryptie schrapt uit het lijstje, dan wordt de server wel verplicht om te kiezen voor een zwakkere vorm van encryptie. Vandaar de naam van dit type aanval: downgrade to export of ciphersuite rollback (afhankelijk van de auteur: respectievelijk [Rescorla2000] en [WagnerEtAl1997]). SSLv3 voorkomt dit door over de anders onbeschermde handshakeberichten een MAC te nemen met de master_secret als sleutel.11 In het Handshake Finished bericht stuurt de client een MAC van alle ontvangen berichten naar de server; de server vergelijkt deze MAC met de berichten die verstuurd werden naar de client. In omgekeerde richting gebeurt uiteraard hetzelfde. Als er onderweg geknoeid zou zijn met de handshakeberichten komt dit tijdens deze test aan het licht. Hierdoor is SSLv3 immuun voor deze bedreiging. Waarom vermelden we deze aanval nu eigenlijk? We hebben immers net gezegd dat SSLv3 komaf heeft gemaakt met deze soort aanval! Wel… om compatibiliteitsproblemen met oudere webbrowsers te voorkomen, stellen systeembeheerders hun webservers meestal in met de mogelijkheid om SSLv2 connecties te aanvaarden. Bovendien laten een heleboel systeembeheerders toe om export ciphers te gebruiken in combinatie met SSLv2… De aanvaller kan nu het versienummer van SSL – grijs opgelicht op Figuur 5.12 – veranderen in 2.0 en dan gebruik maken van dit zwaktepunt (het versienummer van de ClientHello aanpassen naar 2.0 gaat, want dit is ook niet meer beschermd door een MAC). SecuritySpace12, een consulting firma gespecialiseerd in het auditen van de beveiliging van systemen, heeft zeer recent een onderzoek gedaan naar de configuratie van webservers. Hiervoor hebben ze internationaal 82890 webservers gecontroleerd. Het onderzoek dateert van begin 2002 en is vrijge-geven op 1 mei 2002, hieronder volgen enkele gegevens: 82890 webservers voorzien een of andere vorm van SSL Versie Percentage SSLv2 96,43% SSLv3 95,70% TLSv1 85,73% Figuur 5.13: Toepassing van verschillende versies van SSL door webservers

11

Volledigheidshalve moeten we er op wijzen dat een MAC genomen met een geheime sleutel (symmetrisch) door de meeste auteurs een MIC (Message Integrity Check) wordt genoemd, vanuit de veronderstelling dat de authenticiteit is vastgesteld en we enkel de integriteit willen nagaan. 12 SecuritySpace, zie http://www.securityspace.com

56

Van de 79930 webservers die SSLv2 ondersteunen: Type algoritme Enkel export algoritmen Enkel domestic algoritmen Domestic & export algoritmen

Aantal 2323 840 76767

Percentage 2,91% 1,05% 96,04%

Figuur 5.14: Ondersteuning van encryptie-algoritmen bij SSLv2 webservers.

Wat leren deze cijfers ons? Het grootste deel van de webservers laat SSLv2 connecties toe. Van de groep die SSLv2 ondersteunt laat bovendien 98,95% het gebruik van export ciphers toe! Hoewel we er dus vanuit gaan dat deze aanval opgelost is met de introductie van SSLv3, moeten we vaststellen dat in de praktijk deze aanval nog steeds courant is omwille van de nog steeds wijdverspreide ondersteuning van SSLv2. Hoewel deze aanval niet rechtstreeks leidt tot het compromis van de gegevens, kan de aanvaller nu wel de sterkte van de encryptie zelf bepalen en dusdanig afzwakken dat de gegevens makkelijker ten prooi vallen voor een post-mortem brute-force aanval op de ciphertext. 5.8.2 ChangeCipherSpec wordt niet opgenomen in de MAC Een heel vreemd aspect van de SSL handshake is dat het ChangeCipherSpec bericht niet wordt opgenomen in de MAC van de handshakeberichten (onderdeel van het Handshake Finished bericht). We herbekijken dit probleem in het kader van het Principe van Horton in subsectie 5.9.2

5.9 Authenticatie: het Principe van Horton Laten we onze aandacht even terug richten op de authenticatie-eigenschap. SSL biedt integriteit van de application_data aan door elk record te beschermen (d.m.v. een MAC). De integriteit wordt bewaakt door de implementatie aan de zijde van de bestemmeling: enkel data waarvan de MAC bevestigt dat de betekenis van de gegevens hetzelfde is gebleven tussen beide eindpunten, wordt doorgegeven naar de bovenliggende applicatie. De vraag is nu enkel: wordt genoeg van de data geauthenticeerd? Om hierop een antwoord te kunnen geven, bekijken we eerst het Principe van Horton [WagnerEtAl1997]. “Authenticeer wat er bedoeld werd, niet enkel wat er gezegd werd.” M.a.w. we mogen geen data niet-authenticeren die - hoewel niet belangrijk voor de betekenis van de het gezegde - belangrijk is voor het verwerken en/of interpreteren ervan. Laten we eens zien hoe goed SSLv3 zich houdt aan dit principe…

57

5.9.1 Het record protocol

Record Header content type

lengte

Data fragment

protocol versie

MAC

Geëncrypteerde data en MAC = encrypted payload

Record Header

Record dat verstuurd wordt Figuur 5.15: MAC van het SSL record protocol

Uit Figuur 5.15 kunnen we afleiden dat het protocol versie veld niet mee wordt opgenomen in de MAC. Dit druist in tegen het principe van Horton. Echter, in hoofdstuk 4 hebben we gezien dat dit veld eigenlijk redundant is: volgens de standaard wordt het niet gebruikt. Dus hoewel SSLv3 op dit vlak afwijkt van de regels die Horton voorschrijft, blijft de schade beperkt. Niettemin had het beter geweest dit redundante veld ofwel op te nemen in de MAC ofwel geheel weg te laten uit de header. De situatie die nu ontstaat is dubbelzinnig en bepaalde – “slechte” – implementaties zouden dit veld toch kunnen gebruiken. 5.9.2 De hanshake: het ChangeCipherSpec bericht Zoals we even eerder al hebben aangegeven, wordt het ChangeCipherSpec bericht niet opgenomen in de MAC’s van de handshakeberichten (die worden meegestuurd in de Handshake Finished berichten). Figuur 5.16 maakt duidelijk om welke berichten het juist gaat.

Client

Server C lientH ello lo ServerH el ate Certific ServerHell

oD one

ClientKeyE xchange ChangeC ip herSpec Handshake Finis hed herSpec C hangeCip Finished Handshake

Niet opgenomen in MAC Figuur 5.16: ChangeCipherSpec berichten wordt niet opgenomen in de MAC’s die de handshake berschermen

Uiteraard voldoet deze situatie niet aan het principe van Horton, maar laten we eerst nog eens bekijken waarvoor het bericht ook alweer precies dient. Het ChangeCipherSpec is het teken voor de

58

communicerende partij om over te schakelen op beveiligde communicatie, m.a.w. de net vastgestelde algoritmen worden gebruikt voor alle berichten volgend op ChangeCipherSpec. Er zijn 2 mogelijke (gekende) gevolgen voor het niet-toepassen van de MAC: • Stel nu even dat een aanvaller het ChangeCipherSpec bericht dat de client naar de server stuurt onderschept en niet meer doorstuurt. De application_data die de client naar de server stuurt, is dan versleuteld, maar de server kan deze gegevens niet interpreteren, want de server heeft de juiste algoritmen nog niet ingesteld. Het communicatiekanaal zal verbroken worden d.m.v. een alert bericht. • Indien de algoritmen die client en server afspreken enkel zouden bestaan uit het toepassen van een MAC zonder encryptie, dan ontstaat een ander soort probleem: als een aanvaller nu het ChangeCipherSpec bericht dat de client naar de server stuurt laat vallen, dan zal de server nooit overgaan tot het nakijken van de MAC, waardoor ook de garantie op integriteit verloren gaat. Bovendien kan de aanvaller de MAC gewoon van de berichtjes knippen en de inhoud van de berichtjes aanpassen. Immers, de berichten zijn niet geëncrypteerd en omdat de server nooit verwittigd is dat er wordt overgegaan op beveiligde communicatie, verwacht de server ook geen MACaanhangsel. In dit geval heeft de aanvaller quasi vrij spel om de berichten onderweg aan te passen: zie Figuur 5.17.

Record Header

Data fragment

MAC

Aanvaller verwijdert MAC, past Data Fragment aan, past eventueel lengte aan in Record Header Record Header (lengte-veld aangepast)

Data fragment (aangepast)

Figuur 5.17: Mogelijke aanval als ChangeCipherSpec bericht verdwijnt

De meest courante implementaties laten echter niet toe dat zonder encryptie wordt gewerkt, dus deze aanval wordt erg onwaarschijnlijk. De gevolgen van het niet-opnemen van het ChangeCipherSpec bericht in de MAC van de handshakeberichten blijven beperkt. Niettemin kunnen de problemen die zo ontstaan, vermeden worden door het principe van Horton strikt te volgen. 5.9.3 “Hortoniaans” genoeg? We kunnen stellen dat de kleine afwijkingen van SSLv3 t.o.v. het principe van Horton geen noemenswaardige invloed hebben op de effectieve beveiligingskracht van het protocol.

5.10 Veiligheid van de gegevenstransfer 5.10.1 Luistervinken Zoals we in het vorige hoofdstuk hebben gezien, zorgt het SSL Record Protocol ervoor dat alle applicatiedata geëncrypteerd wordt en bovendien geauthenticeerd wordt d.m.v. een MAC. Als we ervan uitgaan dat de handshakefase succesvol verlopen is, dan zijn de gegevens in transit goed beschermd.

59

Uiteraard zijn passieve aanvallen die post-mortem (i.e. achteraf, al lang nadat de gegevens verstuurd werden) de gebruikte sleutel en/of de plaintext proberen de achterhalen niet uit te sluiten. Als je echter een encryptie-algoritme gebruikt dat sterk genoeg is, dan zal een brute force poging om de sleutel te achterhalen onmenselijk lang duren. Vandaar dat we onze aandacht nu op een aantal andere methodes richten. 5.10.2 Verkeersanalyse Als standaardaanvallen mislukken, is het tijd om de wat meer obscure aanvallen te beschouwen: bijvoorbeeld verkeersanalyse (traffic analysis). Deze techniek heeft als doel informatie te bekomen over communicatiekanalen aan de hand van niet-geëncrypteerde veldjes van datapakketjes. Zo kan je in het geval van SSL makkelijk het oorsprong- en bestemmings-IP-adres en het volume van het netwerkverkeer achterhalen. Je kan zo zien wie met wie communiceert, welke type services gebruikt worden (TCP of UDP, bijgestaan door het poortnummer dat veel weeggeeft over welke applicatie gebruikt wordt). In de praktijk echter wordt er niet stilgestaan bij het lekken van dit soort informatie: de informatie die verloren gaat, is te vaag en je kan er niet genoeg informatie uit extraheren om de veiligheid en/of privacy in het gedrang te brengen. Niettemin zijn er wat betreft SSL wel een aantal bijzondere informatiedeeltjes die je kan achterhalen. Als je de ciphertekst op lengte onderzoekt kan je de lengte van URL’s afleiden. De URL die je probeert te bereiken, maakt duidelijk deel uit van de vertrouwelijkheid van een bepaalde communicatie, want als de URL bekend is, dan wordt het voor de aanvaller kinderspel om die pagina op te vragen en waarschijnlijk staat die pagina vol met gegevens die het daglicht eigenlijk niet mogen zien. Nu zou je zeggen: je hebt enkel nog maar de lengte van de URL, toch nog niet de hele URL! Toegegeven, maar je hebt al wel het IP adres van de webserver (dit zit niet-geëncrypteerd in het IP pakketje) en de rest van de URL achterhalen is met search-engine-technologie kinderspel: er bestaat specifieke software die alle webpagina’s van een webserver met een URL van een bepaalde lengte kan achterhalen. Dit soort informatie kan echter enkel achterhaald worden als er gebruik wordt gemaakt van streamciphers (die geen padding toepassen), want blockciphers maskeren de lengte (er moet immers naar boven afgerond worden, naar het dichtsbij gelegen veelvoud van de blokgrootte van het algoritme). Moeten we echt wakker liggen van dit type aanvallen? Niet echt… het achterhalen van de URL blijft een heel karwei en biedt bovendien geen garantie op succes. Bovendien kunnen we het de aanvaller nog moeilijker maken door te werken met blockciphers of streamciphers die de lengte van de plaintext maskeren door padding toe te voegen. 5.10.3 Replay aanvallen In het vorige hoofdstuk hebben we dit type aanval al even aangehaald. We zijn bezorgd dat een aanvaller de inhoud van oude pakketjes van eenzelfde connectie in nieuwere pakketjes wil stoppen, Figuur 5.18 maakt dit duidelijk. Hiermee kan de aanvaller de communicatie tussen 2 partijen danig in de war sturen: de bestemmeling krijgt immers steeds weer hetzelfde stukje gegevens toegestuurd.

TCP/IP headers Pakketje nr. 1

SSL Record pakketje 1

TCP/IP headers Pakketje nr. 3

SSL Record pakketje 3

TCP/IP headers Pakketje nr. 3

SSL Record pakketje 1

Figuur 5.18: Replay aanval

60

SSL voorkomt dit door aan het MAC-proces een sequentienummer toe te voegen. In Hoofdstuk 4, sectie 4.3 hebben we gezien hoe SSL een sequentienummer betrekt bij het maken van de MAC. Stel dat een aanvaller de inhoud van pakketje 1 in pakketje 3 zou stoppen. Als pakketje 3 aankomt, decrypteert de implementatie langs de zijde van de bestemmeling de encrypted payload. Dan wordt er een MAC genomen van de verkregen plaintext en deze wordt vergeleken met de MAC die aanwezig is in de payload. De bestemmeling verwacht echter pakketje 3, dus gebruikt de implementatie sequentienummer 3 bij het maken van de MAC, terwijl het eigenlijk om pakketje 1 gaat: de MAC die in het pakketje zit is gemaakt met sequentienummer 1. Als de 2 MAC’s vergeleken worden zal de test falen en het pakketje zal niet aanvaard worden. Door toevoeging van sequentienummers zorgt SSL er dus voor dat het ongevoelig blijft voor replay aanvallen.

5.11 Halen we de vooropgestelde criteria? Na een lang en vrij technisch hoofdstuk rest ons nog om na te gaan in hoeverre SSL voldoet aan de 2 criteria – performantie en beveiliging - die we in het begin van het hoofdstuk voorop hebben gesteld. 5.11.1 Performantie Wat betreft de performantie hebben we gezien dat het vooral de server is die zwaar belast wordt door de SSL connectie. De client blijft gespaard van de duurste operaties, tenzij er client authenticatie wordt toegepast. Bovendien moeten we er vanuit gaan dat een server meerdere SSL connecties tegelijk moet verwerken en we kunnen ons dus voorstellen dat de belasting voor de server hoog is. Vanuit het netwerk-standpunt onthouden we ook dat het aantal RTT’s dat nodig is voor het opzetten van een connectie 2 keer zo hoog ligt bij SSL dan voor een gewone TCP connectie. Vooral de handshake beïnvloedt de performantie van SSL dus. De eigenlijke gegevenstransfer vertoont een lichte overhead door het SSL Record Protocol (toevoeging van header en MAC), maar deze overhead is niet noemenswaardig om de performantie echt te beïnvloeden. In de praktijk is de performantie van SSL acceptabel te noemen. Bij snelle verbindingen, gekenmerkt door een beperkte latency, is de vertraging door SSL minimaal. Tragere verbindingen, bijvoorbeeld de klassieke PSTN-lijnen, ondervinden meer last. De meerprijs die je moet betalen voor beveiligde communicatie is meer dan redelijk. 5.11.2 Beveiliging Maar… wat hebben we aan bovenstaande conclusie als de waarde van die beveiliging ter discussie zou staan? Gelukkig is dit niet het geval. SSL biedt een zéér redelijke bescherming. We hebben een aantal zwakke punten van SSL besproken en telkens weer gezien dat, om misbruik te maken van deze zwakheden, er moet voldaan zijn aan een groot aantal randvoorwaarden. Deze randvoorwaarden maken de aanvallen onrealistisch. Een aanval zoals downgrade to export is dan misschien weer wat meer reëel, maar het enige effect dat de aanvaller hiermee bekomt is een zwakkere vorm van encryptie. Op die manier is de sessiesleutel en de ciphertext sneller te achterhalen d.m.v. een brute-force aanval, maar niettemin blijven de gegevens beschermd – hoewel minder goed dan oorspronkelijk gewenst. Een goed geconfigureerde server die het gebruik van SSLv2 en/of export-ciphers niet toelaat is immuun voor deze aanval. Zoals blijkt is SSL voldoende gewapend en mogen we er vanuit gaan dat SSL duidelijk een meerwaarde kan zijn voor beveiligde verbindingen op een publiek netwerk zoals het Internet.

61

Hoofdstuk 6 Publieke Sleutel Infrastructuur "Nothing happens by itself... it all will come your way, once you understand that you have to make it come your way, by your own exertions." — Ben Stein

6.1 Inleiding Publieke-sleutel cryptografie is gebaseerd op het idee dat een individu of organisatie beschikt over een sleutelpaar: een publieke sleutel en een private sleutel. De private sleutel wordt angstvallig geheimgehouden, terwijl de publieke sleutel gepubliceerd wordt: andere gebruikers van het netwerk moeten immers in staat zijn om deze publieke sleutel op te vragen om berichten te kunnen decrypteren en authenticeren. Dit hoofdstuk bespreekt een aantal concepten die betrekking hebben tot de infrastructuur die nodig is om een efficiënte en betrouwbare verdeling van publieke sleutels mogelijk te maken. Een aantal van deze concepten zijn we in de voorgaande hoofdstukken reeds tegengekomen, bijvoorbeeld het digitaal certificaat en de verificatie van certificaten. Intuïtief begrijpen we wel wat er bedoeld werd, maar dit hoofdstuk probeert een beter overzicht te geven van de de mechanismen. Een aantal thema’s die we aansnijden zijn: Public Key Infrastructures (PKI’s), Certificaat Authoriteiten (CA’s), en revocatiemechanismen. Een goede leidraad bij dit hoofdstuk vormt “Public Key Infrastructure Study: Final Report”, een studie die het NIST (National Institute of Standards and Technology) liet uitvoeren door The Mitre Corporation in 1994. Het doel van deze studie was de haalbaarheid nagaan van een geautomatiseerd systeem voor het management van publieke sleutels voor de verschillende instellingen van de Amerikaanse federale overheid. De resultaten van dit zogenaamde “Mitre Report” bevatten eveneens aanbevelingen voor een een (inter)nationale structuur voor dergelijke geautomatiseerde systemen. Zie ook [Mitre1994].

6.2 Digitale certificaten De meest gebruikte manier om een associatie te vormen tussen een publieke sleutel en een individu of organisatie is de hulp inroepen van een Trusted Third Party (TTP). Dit is een organisatie die alle gebruikers van het systeem kunnen vertrouwen. Afhankelijk van de omstandigheden kan het gaan om een overheidsinstantie, een financiële instelling (in het geval van een bancair netwerk), de hoofdzetel van een bedrijf (in het geval van een gesloten systeem), een commerciële instelling, … Het concept van een TTP kennen we al uit het dagelijks leven. De overheid – via de bevolkingsdienst van de gemeenten - geeft identiteitskaarten uit: dit zijn officiële documenten die de identiteit van een natuurlijk persoon vastleggen. Deze identiteitskaarten worden algemeen aanvaard en dusdanig kan de overheid gezien worden als een TTP.

62

“OK”

Individu

Vertrouwenspersoon = bevolkingsdienst van de gemeenten

Kenmerken Naam Voornaam Nationaliteit Geboortedatum Geboorteplaats Geslacht Foto Handtekening

Figuur 6.1: De overheid is ook een TTP bij de uitgifte van de klassieke identiteitskaart

De Trusted Third Party zal een certificaat opstellen, een verbintenis tussen de publieke sleutel en de identiteit van een individu of organisatie. Een TTP die certificaten uitgeeft noemt men een Certificaat Authoriteit (CA). In feite kan de werking van een certificaat authoriteit ook vergeleken worden met die van een notaris: deze bekrachtigt bepaalde documenten op een rechtsgeldige manier door er zijn handtekening en stempel onder te zetten en het document te bewaren ter referentie. De CA gebruikt geen stempel en handtekening, maar gebruikt haar private sleutel om een digitale handtekening te zetten. 1. Het serienummer van het certificaat: vooral belangrijk voor revocatiedoeleinden.

Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) 2. Gegevens van de Signature Algorithm: md5WithRSAEncryption Certificaat Authoriteit Issuer: Country=BE (CA) State/Province=Antwerp Locality=Antwerp Organisation=Kava Organisational Unit=Kava’s Certificate Authority Common Name=Andy Zaidman [email protected] Validity Not Before: Apr 26 13:52:13 2002 GMT Not After : May 26 13:52:13 2002 GMT Subject: 3. Gegevens van de Country=BE houder van het State/Province=Antwerp certificaat. Locality=Antwerp Organisation=Personal Certificate Organisational Unit=Personal Certificate Common Name=Andy Zaidman 4. Publieke sleutel [email protected] van het individu of de Subject Public Key Info: organisatie. Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a5:96:b3:2e:c3:d1:0d:11:16:8f:89:13:c5:6f: 28:8f:a5:d2:8e:a4:cb:a8:bc:c0:8f:f5:28:a4:d3: 0c:1e:ae:76:2d:b6:48:39:0e:2a:6b:93:25:e2:bf: 45:a1:f7:a0:d9:77:b5:c4:5a:60:24:87:1d:b7:6b: c7:ec:84:7b:67:81:7b:42:90:9c:7f:a9:0e:b7:cd:

63

3d:0f:02:05:a7:de:af:81:bc:27:a6:2d:03:53:cf: 62:95:f0:7b:82:9d:61:5f:aa:fd:66:78:ff:bb:d3: b9:d9:e0:f7:8a:db:d0:86:85:7f:a0:7b:bb:5c:be: ca:14:c9:e9:23:1b:e3:ac:8b Exponent: 65537 (0x10001) 5. Digitale Signature Algorithm: md5WithRSAEncryption handtekening 98:df:76:bd:f9:2a:cd:95:c7:b0:09:d6:52:ea:6f:fa:b8:04: van de CA 72:3c:7e:e8:c6:f2:2d:3b:c5:e0:79:f4:c2:e9:6c:f6:53:50: (gebruik9a:43:d0:2c:5f:4b:ab:ed:9f:91:74:29:0b:5f:ee:39:cc:bb: makende van c0:e0:c5:17:ad:6b:9a:dc:2f:0b:0a:f9:b7:42:64:5c:31:f1: de private f3:4e:ab:72:fc:91:81:04:93:e2:85:9e:85:c1:e0:d5:63:bf: cf:cb:80:26:42:0b:64:11:10:39:50:5d:84:9c:13:e6:83:c0: sleutel van de d0:21:c1:d6:58:82:22:2b:9d:4b:cc:e8:fa:04:82:0a:8b:26: CA) 8b:c4 Figuur 6.2: Voorstelling van een digitaal certificaat

Figuur 6.2 geeft een goed idee van hoe een certificaat eruit ziet. De belangrijkste componenten staan aangeduid op het schema: 1) Het serienummer van het certificaat. Elk certificaat dat een CA tekent met zijn private sleutel krijgt een serienummer, voor latere referentie. Het serienummer speelt een belangrijke rol bij certificaatrevocatie (zie sectie 6.4). 2) De gegevens van de CA. Belangrijk om de publieke sleutel van de CA te kunnen opvragen om de digitale handtekening van de CA na te gaan. 3) De gegevens van het individu of de organisatie aan wie het certificaat toebehoort. 4) De RSA publieke sleutel geassocieerd met het individu of de organisatie. 5) Een MAC van het certificaat dat getekend werd door de CA (met zijn private sleutel), m.a.w. een digitale handtekening over het certificaat. Wat opvalt is dat een certificaat zeer goed gestructureerd is. De International Telecommunications Union (ITU) heeft de X.509 standaard voor digitale certificaten ontwikkeld, deze standaard beschrijft op een formele manier hoe de structuur van een certificaat eruit kan zien aan de hand van ASN.1 (Abstract Syntax Notation). Zie ook [RFC2459].13 Er bestaan een aantal versies van X.509 certificaten, de oorspronkelijke versie dateert van 1988, terwijl de meest recente incarnatie versie 3 (1996) is. Versie 3 introduceert het concept van extensies: je kan een aantal attributen specifiëren. Zo kan je eigenschappen van de eigenaar van het certificaat vermelden of een beperking aan het gebruik van het certificaat opleggen. Je kan bijvoorbeeld een alias voor een server kunnen vermelden (bv. niet enkel de DNS naam, maar ook het IP adres) of expliciet vermelden dat een certificaat enkel voor het tekenen van emails dient en niet voor SSL connecties.

13

Sindsdien is de verdere ontwikkeling en standardisering van X.509 toevertrouwd aan de PKIX werkgroep van de Internet Engineering Task Force (IETF). Voor meer informatie omtrent de PKIX werkgroep, zie: http://www.ietf.org/html.charters/pkix-charter.html

64

6.3 Certificaat Authoriteiten Een Public Key Infrastructure kan je nog het beste vergelijken met een confederale staat. Een Certificaat Authoriteit is dan een een staatje in de grotere confederatie. Aan het hoofd van de confederatie staan organen zoals: • Policy Approval Authority (PAA) Heeft als doel het superviseren van andere organen binnen de PKI. Het houdt zich geenszins bezig met het uitstippelen van details, enkel de grote richtlijnen worden hier benaderd. De functie van de PAA is vergelijkbaar met deze van een senaat. • Policy Certification Authority (PCA) Deze entiteit is dan weer vergelijkbaar met een kamer van volksvertegenwoordigers. Ze beslist over zaken zoals de minimale sleutellengte in het systeem, de maximale levensduur van een certificaat, etc. Figuur 6.3 geeft een idee van deze confederale structuur. We hebben daarstraks al de belangrijkste taak van een CA aangeraakt: het uitgeven van certificaten. Een CA heeft echter nog meer taken: • Het verdelen van certificaten aan gebruikers die op een beveiligde manier willen communiceren met een van de klanten van de CA. Het verdelen van certificaten gebeurt meestal d.m.v. een Lightweight Directory Access Protocol (LDAP) server. • Certificaten revoceren. • Informatie omtrent de revocatiestatus verdelen (zie sectie 6.4) • … Policy Approval Authority

Policy Certification Authority

CA

CA

CA CA

CA CA

Figuur 6.3: Confederale structuur PKI

We weten nu ongeveer welke functies een CA heeft, maar we hebben nog niet stilgestaan bij de wijze waarop een CA haar werk kan verrichten. Hoe kunnen we er bijvoorbeeld zeker van zijn of we een CA wel kunnen vertrouwen? Om die reden wordt binnen een PKI een vertrouwenshiërarchie – in het Engels een hierarchy of trust – opgebouwd. Binnen de hiërarchie spreekt de entiteit die bovenaan staat zijn vertrouwen uit over organisaties die een niveau lager liggen. Deze kunnen dan op hun beurt hun vertrouwen geven aan entiteiten die nog een niveau lager liggen. Deze ketting van vertrouwen is uiteraard wel eindig, want anders is de organisatie binnen een PKI uiteraard zoek. Het geven van vertrouwen aan een organisatie is dus een uiterst delicate zaak, want deze organisatie moet op een oordeelkundige manier haar vertrouwen geven aan andere instanties en/of individuen. Hoe zit het nu eigenlijk in de praktijk? Hoe kunnen we erop vertrouwen dat een gebruiker wel werkelijk is wie dat hij zegt ? Door af te gaan op het certificaat dat die gebruiker heeft bij een CA. Maar op welke basis kunnen we die CA dan weer vertrouwen? Door het feit dat hij beschikt over een certificaat van een hoger gelegen instantie, die de CA vertrouwenswaardig vindt.

65

Het Mitre-rapport [Mitre1994] stelt bovendien dat de functie van root in het schema kan waargenomen worden door de Policy Certification Authority, in de praktijk echter blijkt dat een aantal commerciële CA’s genoeg vertrouwen genieten om zelf als root-element van de hiërarchie op te treden… denken we maar aan VeriSign, Baltimore Technologies, Entrust Technologies, Thawte Consulting (tegenwoordig ondergebracht bij VeriSign), … CA 1

CA 2

User 1

User 2

CA ...

User ...

CA x

User ...

User n-1

User n

Figuur 6.4: Hiërarchische vertrouwensstructuur binnen een PKI

In de praktijk missen we echter nog wel een aantal elementen om deze vertrouwenshiërarchie ten volle te kunnen benutten. Als je je bij een commerciële CA wil inschrijven voor een digitaal certificaat heb je meestal slechts 2 zaken nodig: een emailadres en een kredietkaart. Een emailadres aanmaken met een valse naam kan iedereen; als je daarbij nog een kredietkaart van iemand leent is er niks meer dat jouw identiteit op een wettelijke manier verbindt aan het aangevraagde certificaat. Dit vormt uiteraard een probleem, want op deze manier wordt het mogelijk op een anonieme manier een certificaat aan te vragen, terwijl een certificaat juist een identificerende funtie heeft! Niettemin bestaan er formules voor de aankoop van een certificaat waarbij er een identificatieplicht is. Ook is er een trend merkbaar waarbij overheden zich actief gaan bezighouden met het verdelen van digitale certificaten. Enkele voorbeelden: • Er loopt sinds november 1999 een project in Hong Kong waarbij de 6,5 miljoen inwoners van deze stadstaat een digitaal certificaat (X.509v3) krijgen via het postkantoor [Brands2000]. • De Belgische post is onlangs ook gestart met een pilootproject, PostBox14 genaamd, dat beveiligde email aanbiedt. Het digitale certificaat voor deze postbox wordt ook enkel overhandigd na persoonlijke identificatie op een postkantoor.

6.4 Certificaat revocatie Het Validity-veld van het certificaat bepaalt de geldigheidsduur van een certificaat: een soort houdbaarheidsdatum dus, die meestal een periode van 6, 12 of 24 maanden betreft. Er zijn echter een veelheid aan redenen om het certificaat voor de vervaldatum uit omloop te halen: • Gecompromitteerde private sleutel • Overlijden van de eigenaar (in het geval van een individu) • Stopzetting van activiteiten (van een organisatie) • Ontslag binnen een organisatie • … Maar, het is uiteraard niet altijd mogelijk om alle certificaten die reeds in omloop zijn ineens ongeldig te maken. Vandaar dat er een mechanisme nodig is om de revocatiestatus van een certificaat na te gaan, i.e. kijken of certificaten binnen hun normale geldigheidsduur nog geldig zijn.

14

Voor meer informatie zie: http://www.postbox.be

66

6.4.1 Certificate Revocation List (CRL) De klassieke manier van werken binnen een PKI is het gebruik van een Certificate Revocation List (CRL), een soort zwarte lijst van gerevoceerde certificaten. Een CRL bevat alle gerevoceerde certificaten die nog binnen de huidige geldigheidsduur vallen (certificaten die buiten hun geldigheidsduur zijn, moeten door de implementatie zelf geweigerd worden). De structuur van een CRL is ook vastgelegd binnen de X.509 standaard. Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: md2WithRSAEncryption Issuer: Organisation=European ICE-TEL Project Organisational Unit=Certification Authority Last Update: Jun 9 14:42:43 1997 GMT Next Update: Jul 9 14:42:43 1997 GMT Revoked Certificates: Serial Number: 0A Revocation Date: Mar 3 14:42:54 1997 GMT Serial Number: 09 Revocation Date: Oct 2 12:29:27 1996 GMT Signature Algorithm: md2WithRSAEncryption 7e:2f:81:6a:36:4d:e8:ff:8b:b9:1b:8b:0e:08:99:dd:f4:21: ff:75:8a:8b:23:0a:53:69:04:5c:2f:c1:40:c1:72:53:c4:78: cb:98:8a:61:db:2c:e9:38:1f:c3:68:7d:cd:1f:c3:5d:7e:53: f2:0e:29:23:68:b9:40:dc:a8:6e:c1:eb:8a:18:ed:ce:12:5c: a9:fe:8b:53:16:39:be:4e:26:25:9e:a1:d5:f7:4d:e8:47:8c: 19:72:5b:3a:0d:31:60:a7:60:0f:17:a8:53:f5:98:e2:a9:f0: 99:5a:d4:18:9b:11:97:f5:e3:ef:c7:a8:28:b6:86:76:54:88: 45:e1 Figuur 6.5: Voorbeeld van een CRL (X.509 formaat)

Een aantal typische kenmerken voor een CRL zijn: • De revocatielijst bestaat uit een opsomming van serienummers van certificaten, er worden geen namen van individuen of organisaties vernoemd. • Een CRL bevat een digitale handtekening van de uitgever. Meestal is deze uitgever de CA zelf, maar deze taak wordt ook wel eens uitbesteed. • Het Last Update veld geeft de versiedatum aan van de huidige CRL. • Next Update verwijst naar het tijdstip waarop de volgende versie van de CRL wordt verwacht. Wat jammer genoeg niet zichtbaar is op Figuur 6.5 is dat bij een certificaatrevocatie optioneel ook de revocatiereden kan vermeld worden: • unused : het certificaat wordt niet meer gebruikt • keyCompromise : private sleutel is gecompromitteerd • cACompromise : de (private sleutel van de) CA is gecompromitteerd • affiliationChanged : bv. overgeschakeld van CA • superseded : er bestaat een nieuwere versie van het certificaat • cessationOfOperation : eigenaar/organisatie van het certificaat bestaat niet meer • certificateHold : een tijdelijke toestand van revocatie Het systeem van CRL’s bevat echter ook een aantal tekortkomingen: •

Versheid (“freshness”) De periodes tussen 2 uitgaves van een CRL kan variëren. Sommige CA’s kunnen bijvoorbeeld elke dag een CRL publiceren, terwijl andere omstandigheden een veel minder frequent update-gedrag vereisen. Niettemin vragen een aantal situaties om realtime informatie omtrent de revocatiestatus van een certificaat. Hiervoor zijn CRL’s duidelijk niet geschikt.

67

•

•

•

Bandbreedte probleem Figuur 6.5 bevat slechts 2 gerevoceerde certificaten, maar we kunnen ons voorstellen dat er binnen een PKI met veel gebruikers CA’s zijn die veel grotere CRL’s hebben. Dit kan zeker voor individuen met beperkte bandbreedte een probleem vormen, want een CRL van enkele MB’s downloaden, kan voor hen al een obstakel vormen. Bandbreedte piekmomenten Bovendien wordt de server van de CA ook zwaar belast door de downloads van grote CRL’s. Het probleem wordt nog acuter door het feit dat CRL-downloads vaak geautomatiseerd zijn en op het moment van het verstrijken van de huidige CRL (aangeduid door het Next Update veld), gaan alle systemen tegelijkertijd de nieuwe CRL downloaden. Vaak lost de CA dit op door het Next Update veld lichtjes te laten variëren, zodat bij de volgende download niet iedereen zich tegelijkertijd aanbiedt. Echter deze oplossing zou ervoor zorgen dat de download steeds meer in de tijd wordt gespreid en dit komt de versheid van de gegevens duidelijk ook niet ten goede. Aantal CRL’s (van verschillende CA’s) Een andere vraag is ook: hoeveel CRL’s moet je downloaden? Als iedereen CA zijn eigen CRL opstelt, dan moet je in principe om met iedereen op het Internet te kunnen communiceren beschikken over elk van die CRL’s om zeker te zijn over de revocatiestatus…

6.4.2 CRL’s partitioneren Om het versheids- en bandbreedteprobleem op te lossen zijn een aantal technieken gedefinieerd om CRL’s te partitioneren. Er wordt wel vanuit gegaan dat volledige CRL’s blijven bestaan: als basis voor de gepartitioneerde versies, maar ook als backup mechanisme. 6.4.2.1 Delta Certificate Revocation List (Delta-CRL) Delta-CRL’s worden gebruikt om revocatielijsten in de tijd te partitioneren. Een delta-CRL wordt uitgegeven t.o.v. van een bepaalde basis CRL en bevat alle updates sinds de uitgifte van die basis CRL. Een delta-CRL kan dus het best beschouwd worden als een tussentijdse update, in afwachting van de volgende volledige CRL. Wat de implementatie betreft is een delta-CRL gelijkaardig aan een gewone CRL, met als enige belangrijke toevoeging een verwijzing naar de basis CRL. Als deze delta-CRL’s frequent genoeg worden uitgegeven kunnen ze uiteraard een beter antwoord geven op de versheidsproblematiek dan klassieke CRL’s. Ook wat betreft bandbreedte kunnen we ervan uitgaan dat een delta-CRL minder bandbreedte-intensief is dan een klassieke CRL. 6.4.2.2 CRL Distribution Points (CDP) CRL distribution points laten toe om een CRL in kleinere verzamelingen te partitioneren aan de hand van verschillende strategiën: • Een bepaalde range van serienummers van certificaten. • Vervaldatum van het certificaat • Landcode van het certificaat • Revocatiereden • … Het is dus geen partitionering in de tijd (zoals een delta-CRL), maar eerder een partitionering op basis van meta-eigenschappen van het certificaat. Een CDP is vooral een antwoord op het bandbreedteprobleem en niet zozeer op het versheidsprobleem. Vaak worden beide technieken – delta-CRL’s en CDP’s – gecombineerd toegepast.

68

6.4.3 Online Certificate Status Protocol (OCSP) Als je je betaalkaart verliest, is het uiteraard niet aanvaardbaar dat de blokkering van je kaart pas de volgende dag ingaat. Je veronderstelt gewoon dat de blokkering onmiddellijk in werking treedt, m.a.w. de versheid van de informatie waarover een handelaar beschikt bij een betaalkaarttransactie moet real-time zijn. In sommige omstandigheden – zoals bij financiële transacties – verwachten we hetzelfde van een PKI systeem. Om die reden werd het Online Certificate Status Protocol (OCSP) ontwikkeld: de realtime revocatiestatus van een certificaat nagaan. Een zogenaamde OCSP responder houdt de status van certificaten bij door rechtstreeks in contact te staan met de CA’s of door het verzamelen van CRL’s van de CA’s.

Internet

Client

Server Certificaat gerevoceerd?

OCSP Responder

Antwoord

Figuur 6.6: OCSP responder

Een verzoek aan de OCSP responder levert een gesigneerd antwoord op met de status van het opgevraagde certificaat. Er zijn 3 types antwoorden mogelijk: • GOOD : het certificaat staat niet op de zwarte lijst • REVOKED : het certificaat staat wel op de zwarte lijst • UNKNOWN : dit kan bv. zijn als de CA niet bekend is bij de OCSP responder Het systeem van de 3 typische antwoorden is echter verre van volmaakt. De Internet Draft van OCSP [RFC2560, blz. 3] wijst er duidelijk op dat het antwoord GOOD kan zijn, terwijl we met een ongeldig certificaat te maken hebben (bv. buiten de houdbaarheidsdatum of met een valse handtekening). Dit zwaktepunt is net zo goed kenmerkend voor CRL’s en de implementatie mag er dus niet van uitgaan dat een niet-gerevoceerd certificaat ook daadwerkelijk goed is, hiervoor moet ook de vertrouwenshierarchie nagekeken worden. Een ander punt waarover de literatuur niet duidelijk is, is het versheidsprobleem. De OCSP responder kan zich baseren op CRL’s of kan rechtstreeks in contact staan met de CA voor wat betreft de informatie omtrent de revocatiestatus van een certificaat. Maar als de OCSP responder zich baseert op CRL’s, in hoeverre in het versheidsprobleem dan opgelost? Als de periode tussen 2 opeenvolgende CRL’s groot is, dan blijft het versheidsprobleem actueel. Wat betreft de bandbreedte kunnen we zeggen dat OCSP een duidelijke meerwaarde kan vormen voor de eindgebruiker van het PKI systeem: het is nu niet meer nodig om (van elke CA) een CRL te downloaden. Het is nu perfect mogelijk om enkel de status op te vragen van die certificaten waarin we echt geïnteresseerd zijn. Wat betreft het bandbreedtegebruik van de OCSP responder zitten we hier duidelijk terug bij af: piekmomenten kunnen een groot probleem vormen. Maar ook computationeel wordt de OCSP responder zwaar belast, ieder antwoord moet immers gehandtekend worden en hiervoor is een – CPU intensieve – private sleutel operatie nodig. Om aan dit probleem te verhelpen mag de OCSP responder antwoorden pre-produceren: de responder mag een voorraad aanleggen van kant-en-klare (gesigneerde) antwoorden, dit om de CPU te ontlasten tijdens piekmomenten. De draft zegt echter niks over de versheid van de revocatie-informatie van gepreproduceerde antwoorden, waardoor dit wel weer eens een kritiek punt zou kunnen worden.

69

6.4.4 Nieuwe mechanismen In het kader van de X.509 standardisatie wordt er nog steeds gezocht naar efficiënte mechanismen voor certificaatrevocatie. Verschillende voorstellen die door het IETF worden bekeken vormen een mix van bovenstaande technieken. Het is duidelijk dat er hier nog mogelijkheden voor onderzoek zijn.

6.5 Conclusie De Public Key Infrastructure verzorgt een heel belangrijke functie in het hedendaagse landschap van beveiligingstechnieken in een groot publiek netwerk. De Certificaat Authoriteiten vervullen een belangrijke rol in het opstellen, verdelen en revoceren van de certificaten die publieke sleutels binden aan een individu. Revocatiemechanismen vormen duidelijk nog een probleem en verder onderzoek naar efficiëntere technieken lijkt hier aangewezen.

70

Hoofdstuk 7 Een kwestie van privacy ”Privacy is the right to be alone - the most comprehensive of rights, and the right most valued by civilized man.” — Louis D. Brandeis

7.1 Inleiding In de voorgaande hoofdstukken hebben we een aantal technieken gezien waarmee gegevens op een veilige manier kunnen overgebracht worden tussen 2 correspondenten op een publiek netwerk. Het vertrouwelijkheidsprincipe garandeert de privacy van de verstuurde gegevens. In dit hoofdstuk gaan we op zoek naar wat privacy van individuen in de praktijk betekent en welke gevaren er op de loer liggen bij het grootschalig gebruik van PKI systemen. Maar vooraleer we overgaan tot een bespreking van de huidige stand van zaken, raken we eerst nog een aantal begrippen aan die om wat meer uitleg vragen: In het inleidend hoofdstuk hebben we reeds gekeken naar de definitie van privacy van Alan Westin [Westin1967]: Privacy (van informatie) is het recht dat natuurlijke personen, groepen van personen of instituten hebben om voor zichzelf uit te maken wanneer, hoe en in welke mate informatie over de betrokken individuen overgedragen wordt aan derden. In deze definitie wordt impliciet gebruik gemaakt van het begrip persoonsgegevens, ook dit vergt misschien enige verklaring: Onder persoonsgegevens wordt iedere informatie betreffende een geïdentificeerd of identificeerbaar natuurlijk persoon verstaan. Het kan gaan om de naam van een persoon, een foto, een telefoonnummer (zelfs een telefoonnummer op het werk), een code, een bankrekeningnummer, een e-mailadres, een vingerafdruk, … Het begrip beperkt zich niet tot gegevens die de persoonlijke levenssfeer van personen betreffen. Zelfs de gegevens die betrekking hebben op het professionele of openbare leven van een persoon worden als "persoonsgegevens" beschouwd. [Persoonsgegevens2001]

71

De vraag die nu rijst is: zijn deze persoonsgegevens nu eigenlijke gevoelige gegevens? Bepaalde persoonsgegevens zijn van meer gevoelige aard dan andere. De naam en het adres van een persoon zijn eigenlijk onschuldige gegevens maar dit geldt niet voor zijn politieke overtuigingen, seksuele voorkeuren of zijn gerechtelijk verleden. De wet regelt de registratie en het gebruik van deze gevoelige gegevens op veel striktere wijze. Het gaat om gegevens betreffende ras, politieke opvattingen, godsdienstige of levensbeschouwelijke overtuigingen, lidmaatschap van een vakvereniging, gezondheid, seksuele leven, verdenkingen, vervolgingen of strafrechtelijke of bestuurlijke veroordelingen. [Persoonsgegevens2001]. Is het verboden deze gegevens te verzamelen? Het is in beginsel verboden de hierboven omschreven gegevens te verzamelen, te registreren of te vragen ze mee te delen. Personen die dat doen, kunnen worden gestraft met een boete van 500 tot 500.000 euro (20.000 BEF tot 20 miljoen BEF) en in geval van herhaling met een gevangenisstraf van 3 maanden tot 2 jaar. [Persoonsgegevens2001] Volledigheidshalve vermelden we er wel bij dat de Belgische wetgeving uitzonderingen voorziet op bovenstaande bepaling. In bepaalde welomschreven gevallen is het dus wel toegestaan om onder strikte voorwaarden gevoelige gegevens te verzamelen, zolang er op een voorzichtige manier mee wordt omgesprongen en de kwaliteit van de gegevens gewaarborgd blijft. We houden de spanning er niet langer in en gaan nu bovenstaande weetjes in context plaatsen. (Als leidraad bij dit hoofdstuk werd [Brands2000, hoofdstukken 1, 2 en het epiloog] gebruikt.)

7.2 Het kader 7.2.1 Juridisch In een aantal landen, voornamelijk in Europa, is de wet de meest courante manier van privacybescherming. Wettelijke middelen kunnen ervoor zorgen dat systematisch misbruik door de privesector wordt voorkomen, maar zijn niet altijd voldoende: •

•

•

Het sleutelidee achter een wetgeving is om van onwenselijke daden een misdaad te maken en overtreders te vervolgen. Dit houdt criminelen achter hun computer nauwelijks tegen, want vandaag de dag kunnen ze met hun computer over een fysisch grote afstand inbreken en op die manier bijna onvindbaar blijven. Een tweede aspect dat hier nauw mee gerelateerd is, is dat individuen vandaag de dag communiceren en transacties uitvoeren via een globaal netwerk en niet overal te wereld staat de wetgeving op hetzelfde punt (de wetgeving in het algemeen en de privacywetgeving in het bijzonder). Door de culturele verschillen is het zelfs maar zeer de vraag of er ooit een geharmoniseerde privacy-wetgeving komt. Nieuwe technologie ontwikkelt zich veel sneller dan de rechtspraak. Voor een nieuwe technologie duurt het soms jaren vooraleer de implicaties ervan op het gebied van privacy zijn onderzocht. Een regulerend kader errond opstellen kan dus jaren duren.

7.2.2 Zelfregulering Zelfregulering, het in ere houden van een bepaalde beroepscode opgesteld door een beroeps- of belangenvereniging, blijkt in het kader van privacy nog minder effectief te zijn dan een wettelijk kader. Marketeers en datamining specialisten hebben er groot financieel voordeel bij om persoonsgegevens die ze al verzameld hebben te hergebruiken voor andere doeleinden: er kunnen immers grote winsten worden gemaakt met het gebruiken en/of doorverkopen van profielen van individuen. Bovendien

72

worden organisaties maar zeer zelden verantwoordelijk gesteld voor het misbruik van persoonlijke gegevens, niet in het minste omdat individuen maar zeer zelden een idee hebben waar de oorsprong van de gegevenslek zich bevindt, m.a.w. welke organisatie hebben ze hun gegevens wel toevertrouwd. Organisaties blijven daarom ook continu op de rand leven van wat wettelijk is toegestaan. Bovendien vergt zelfregulering het onderschrijven van het charter door de hele industrie(tak). Dit is vaak een onrealistisch doel: nieuwe bedrijven schrijven zich niet altijd in, andere bedrijven onderschrijven het charter maar houden zich er niet aan, … er zullen altijd wel redenen zijn voor organisaties om het charter te ondermijnen. Een goed voorbeeld van een dergelijk charter is TRUSTe15, maar we zullen meteen zien dat TRUSTe vaak gebruikt wordt als een rookgordijn: • In 1998 kwam de U.S. Federal Trade Commission erachter dat webportal GeoCities16 demografische informatie verkocht van zijn leden aan de adverteerders. Niettemin had Geocities een privacylabel gekregen van TRUSTe. • In maart 1999 besliste TRUSTe om Microsoft17 (een van de grote sponsors van TRUSTe) niet te auditen toen bekend werd dat Microsoft aan elk Word of Excel document een serienummer vasthechtte waarmee de gebruiker perfect identificeerbaar was. • In november 1999 werd bekend dat RealNetworks18 in het geheim gegevens verzamelde over het luistergedrag van gebruikers van de RealPlayer en dat deze gegevens werden opgeslagen in een grote centrale databank. TRUSTe heeft het privacylabel van RealNetworks echter niet ingetrokken. • … Sinds haar ontstaan in 1996 heeft de TRUSTe honderden privacy-doorlichtingen uitgevoerd en geen enkel privacylabel gerevoceerd… Moeten we Scott McNealy, CEO van Sun Microsystems dan toch maar geloven als hij zegt: “You have zero privacy anyway. Get over it”? 7.2.3 De situatie in België Op 24 oktober 1995 is een Europese richtlijn goedgekeurd met het oog op de harmonisatie van de regels inzake de bescherming van persoonsgegevens op het volledige grondgebied van de Europese Unie. Net zoals alle andere lidstaten moest België de beginselen van die richtlijn in Belgisch recht omzetten. De wet van 8 december 1992 (Belgische Staatsblad 18 maart 1993) werd daardoor grondig gewijzigd en resulteerde in de wet van 11 december 1998 (Belgisch Staatsblad 3 februari 2001) [Privacy1998].

7.3 De keerzijde van digitale certificaten In de vorige hoofdstukken hebben we een aantal technieken bekeken die beveiligde verbindingen over Internet mogelijk maken. Deze verbindingen verzorgen in eerste instantie de vertrouwelijkheid en de integriteit van de gegevens die verstuurd worden; de gegevens die verstuurd worden zijn ontoegankelijk voor derden en daarmee wordt in grote mate voldaan aan het aspect van privacy: enkel de bestemmeling kan de gegevens daadwerkelijk lezen, derden zijn niet in staat de gegevens te interpreteren. Zoals we dadelijk zullen zien, liggen er ook nog andere gevaren op de loer… Digitale certificaten spelen een grote rol in het tot stand komen van een goed gefundeerde publieke sleutel infrastructuur, nodig voor beveiligde verbindingen op grote schaal zoals we in het vorige hoofdstuk hebben gezien. Maar tenzij er drastische maatregelen genomen worden, zal het niet lang 15

TRUSTe, zie http://www.TRUSTe.com GeoCities maakt ondertussen deel uit van de webportal Yahoo!, zie http://geocities.yahoo.com 17 Microsoft, zie http://www.microsoft.com 18 RealNetworks, zie http://www.real.com 16

73

meer duren vooraleer miljoenen mensen met elkaar communiceren en transacties uitvoeren via het meest geavanceerde en doortastende elektronische surveillancesysteem dat ooit werd geschapen. Met surveillance bedoelen we het systematisch volgen en evalueren van de daden van een individu. Elk digitaal certificaat kan immers op een unieke manier teruggebracht worden tot zijn eigenaar. Tegelijkertijd kan het certificaat automatisch gevolgd worden bij de verschillende interacties van zijn eigenaar met het systeem. Zelfs digitale certificaten die geen expliciete verwijzing naar de eigenaar bevatten, bieden geen soelaas, want de string van nulletjes en eentjes waaruit een certificaat bestaat, is uniek; door deze uniekheid bieden dit soort “anonieme” certificaten amper meer privacy dan een rijksregisternummer, een kredietkaartnummer, … Op basis van deze unieke serienummers is het perfect mogelijk om een volledig profiel te genereren en zodra er toch eenmaal – per ongeluk – wordt overgegaan tot het vrijgeven van meer details (bv. de naam), dan is het profiel compleet. Merk wel op dat dit hoofdstuk er duidelijk van uitgaan dat client authenticatie een belangrijke rol gaat spelen en dat meer en meer individuen het hanteren bij hun online communicaties en/of transacties.

7.4 Privacy kwesties Stefan A. Brands [Brands2000] postuleert dat als de huidige vorm van PKI’s wordt aangehouden, iedereen gedwongen zal worden om te communiceren in het meest geavanceerde en doortastende elektronisch surveillancesysteem dat ooit gecreëerd werd. Volgende puntjes moeten de omvang van deze bedreiging voor de privacy verduidelijken: •

Alle communicaties en transacties van een individu binnen een PKI kunnen aan elkaar gelinkt worden op basis van zijn of haar certificaten. Op deze manier kunnen hele dossiers over een individu worden aangelegd betreffende de gewoonten, het gedrag, de voorkeuren, … van een gebruiker van certificaten. De vraag is nu: welke spelers in het PKI schema zijn in staat om deze gegevens te verzamelen? Het is logisch om te stellen dat de certificaat authoriteit het certificaat ziet op het moment dat het wordt uitgegeven; op dit moment start het “dossier”. Typisch ziet de CA het certificaat terug bij elke verificatie-actie bij een online verificatiesysteem zoals OCSP. Bovendien kan het OCSP-systeem ook het bronadres van de OCSPaanvrager registreren.

Certificaat Authoriteit OCSP responder

OC S P OCS P

Klant met certificaat

requ e

reson

T rans

st

se

Instelling (bv. bank)

actie

Figuur 7.1: Privacy probleem met OCSP

Als we Figuur 7.1 even beschouwen: de OCSP responder kan zeer eenvoudig aan het dossier van de certificaathouder toevoegen: Dit druist uiteraard in tegen elk idee dat we van privacy hebben! Temeer daar de CA zich in de uniek positie bevindt om toegang te hebben tot de identiteit van de

74

certificaathouder, m.a.w. de informatieconcentratie bij een CA kan duizelingwekkende properties aannemen. In de eerste plaats denk je aan de privacy van de certificaathouder, maar ook de privacy van de organisatie die het certificaat wenst te verifiëren komt op deze manier in het gedrang. Immers, een organisatie die niks met een bepaalde CA te maken heeft, moet het certificaat van een correspondent daar laten verifiëren en vanaf dat ogenblik beschikt die CA ook over informatie over het correspondentiegedrag van de organisatie. Elke organisatie die certificaten ontvangt van een correspondent is in staat om deze certificaten op te slaan. De organisatie kan deze opgeslagen informatie enkel binnen de organisatie gebruiken, maar kan deze databank ook uitwisselen met andere organisaties via protocollen zoals Information Content & Exchange19 protocol (ICE) en Customer Profile Exchange20 (CPEX, recentelijk omgedoopt tot CPExchange, zie ook Figuur 7.2).

Customer Profile Exchange

Organisatie 1

Organisatie 2

Ko op te en b

Bestelt concerttickets oe k

Organisatie 3

ek Bo

en te

s rei

Klant Figuur 7.2: Customer Profile Exchange

CPExchange automatiseert het uitwisselen van profielen en kan ondertussen rekenen op een 70-tal leden. De leden verbinden zich ertoe hun (klanten)informatie door te sturen naar de centrale CPExchange server. In de database die zo gevormd wordt, kunnen de leden dan op zoek gaan naar profielen van individuen die ze wensen te bereiken. Hoewel beide netwerken – ICE en CPExchange – privacy hoog in het vaandel voeren, lijkt het ons moeilijk om een dergelijk doortastend systeem privacybewarend te noemen. De twee voorgaande beschrijvingen sluiten echter in geen geval uit dat een luistervink die op genoeg plaatsen in het netwerk zijn oor te luisteren kan leggen over dezelfde informatie kan beschikken als bovenvermelde partijen. Maar zowel de CA als de leden van een systeem zoals CPExchange beschikken over een systematische vorm van surveillance, wat niet altijd het geval is voor een ad hoc oplossing. •

19 20

Revocatiemechanismen vormen ook een privacyprobleem. CRL’s worden door de CA opgestuurd naar iedereen die zich inschrijft op een CRL-distributie. Een CRL is uiteindelijk niks meer dan een grote lijst van certificaatserienummes van een bepaalde

Information Content & Exchange, zie http://www.icestandard.org Customer Profile Exchange, zie http://www.cpexchange.org/

75

CA en de combinatie kan opnieuw het begin vormen van een dossier. •

Het gebruik van smartcards kan het privacyprobleem nog vergroten, maar dit bespreken we in een volgende paragraaf.

Bovenstaande technieken kunnen resulteren in het jarenlang heimelijk verzamelen van persoonsinformatie; periodiek kunnen deze gegevens dan geprofileerd worden om een totaalbeeld te bekomen. De privacygevaren blijven dus jarenlang latent aanwezig. Dit temporele aspect wordt deels bevestigd door de rol van CA’s. In het vorige hoofdstuk hebben we de parallel getrokken met notarissen; deze vergelijking is best treffend als je beseft dat een notaris aktes archiveert voor latere referentie en de CA vervallen certificaten archiveert. De CA is immers verplicht om deze sleutels te archiveren, want dit is de enige manier om jaren na het signeren een digitale handtekening te bekrachtigen (hiervoor is immers de publieke sleutel van het certificaat nodig). Het feit dat de CA certificaten doorheen de tijd blijft archiveren, maakt het enkel maar eenvoudiger voor organisaties om post-mortem gegevens aan elkaar te blijven linken en het profiel van een individu te vervolledigen. Als we het temporele aspect er dan toch bij betrekken, moeten we ons ook realiseren dat de de computationele privacy die we bekomen door gebruik te maken van allerlei vormen van encryptie over een aantal jaren – neem 20 jaar – waarschijnlijk verloren gaat door de vooruitgang geboekt op het vlak van computationele kracht, zowel op het vlak van algoritmen als op het vlak van pure processorsnelheid.

7.5 In een ideale wereld… Verbazingwekkend genoeg is er tot op heden betrekkelijk weinig aandacht besteed aan privacy in PKI systemen. De meeste certificaattechnologieën en/of standardisatiewerkgroepen besteden er zelfs geen aandacht aan en richten zich geheel op het encryptie- en authenticatie-aspect. Vetrouwelijkheid is echter een zwak criterium voor privacy! Het grootste gevaar schuilt hem immers niet in de gegevens die we angstvallig geheim willen houden (deze zijn redelijk veilig d.m.v. encryptie), maar wel in de gegevens die we zonder verpinken wel openbaren. Deze aanvallen op onze privacy moeten we zien te beperken, maar deze taak is niet weggelegd voor encryptie. Encryptie kan immers niet beschermen tegen het misbruik van data die je vrijwillig overdraagt. 7.5.1 Anonimiteit In veel situaties is het niet nodig om je identiteit bekend te maken. Bij een verkeerscontrole is de agent immers niet geïnteresseerd in wie je bent, maar wel in het feit of je beschikt over een rijbewijs. Zonder de mogelijkheid om anoniem te blijven krijgen individuen niet de kans om te beschikken over hun eigen privacy. Anonimiteit vormt de basis voor privacy. Maar anderzijds… individuen dwingen om anoniem door het leven te gaan is net zo goed een inbreuk op iemands privacy. Bovendien zijn er situaties waarin anonimiteit ongewenst is (bv. bij transacties met een bank). Met deze ideeën in het achterhoofd willen we eigenlijk een oplossing waarbij de eigenschap van anonimiteit variant is, m.a.w. ieder individu moet zelf kunnen beslissen in welke mate gegevens over zichzelf worden vrijgegeven in een bepaalde transactie. Dit noemt men het selective disclosure paradigma. 7.5.2 Onverenigbaarheid Anonimiteit op een transactie-basis is nodig, maar op zich niet voldoende om het linken van 2 afzonderlijke transacties te vermijden; enige correlatie die tussen 2 transacties bestaat, bv. een publieke sleutel, is op zich voldoende om een link te leggen.

76

De eigenschap die we toekennen aan een aantal transacties die onderling niet te linken zijn, noemen we onverenigbaarheid (of in het Engels unlinkability). Zonder deze eigenschap kunnen individuen zelf niet bepalen welke gegevens ze uiteindelijk vrijgeven, want de gecombineerde informatie – bekomen uit de afzonderlijke transacties – is in principe aanzienlijk groter dan de afzonderlijke delen. Zonder controle over de onverenigbaarheid boet het selective disclosure paradigma met iedere nieuwe transactie aan kracht in. Deze eigenschap is dus nodig om de langzame erosie van de privacy te voorkomen. De huidige generatie van PKI systemen voldoet duidelijk niet aan deze vereisten. Niettemin is er onderzoek dat nieuwe mechanismen voorstelt, die beter aan deze eisen voldoen. Het doctoraat van Steven A. Brands [Brands2000] doet een aantal voorstellen in deze richting. De exacte – vaak heel wiskundige – principes hiervan zijn buiten de scope van deze thesis.

7.6 Integratie met smartcards Tot op heden hebben we het in het kader van digitale certificaten nog steeds gehad over softwareonly oplossingen. Software-only oplossingen dragen echter niet altijd de voorkeur weg, want bij deze manier van werken vormt diefstal een groot probleem. Als de geheime sleutel van een certificaat gegenereerd en/of bewaard wordt op een gewone PC, dan is het vrijwel onmogelijk om te vermijden dat de sleutel gecompromitteerd, gewijzigd, vrijgegeven of verkeerdelijk gebruikt wordt. Onder de zeer toepasselijke naam “Where do your encryption keys want to go today?” 21 publiceerde Peter Gutmann [Gutmann1997] een paper waarin hij een aantal technieken beschrijft om private sleutels in een mum van tijd te stelen van een standaard Windows PC, ook al bevinden deze private sleutels zich in een geëncrypteerde file op de harde schijf. Een jaar eerder had Gutmann de Netscape producten op het rooster gelegd en ook Netscape’s web server moest eraan geloven, want ook hier werd de private sleutel redelijk eenvoudig ontvreemd [Gutmann1996]. 7.6.1 Smartcards Eén manier om je te beveiligen tegen deze en andere risico’s is je geheime sleutel opslaan in een smartcard. Een smartcard is een kaartje ter grote van een bankkaart met een geïntegreerd circuit (integrated circuit of IC) erop (zie Figuur 7.3). De term smartcard wordt echter gebruikt voor elke soort “chipkaart”, terwijl er eigenlijk 3 duidelijk te onderscheiden categorieën smartcards zijn, ingedeeld volgens functionaliteit [Everett2002]: 1) Enkel geheugen 2) Geheugen met beveiligingslogica tegen inbraak (klasse van resistente smartcards) 3) Geheugen en verwerkingseenheid (CPU) (behoren ook tot de klasse van resistente smartcards) In onze bespreking beperken we ons tot smartcards van type 2 en 3. Resistente smartcards kenmerken zich door beveiligde toegang tot het geheugen en de input/output. Zo kan de kaart zich blokkeren na een aantal keer een verkeerd ingevoerde PIN22 code te hebben ontvangen. Bovendien deactiveren ze zichzelf en/of wissen ze hun geheugen bij een poging tot inbraak.

21

Deze sarcastische titel van de paper van Peter Gutmann [Gutmann1997] is bedacht naar aanleiding van de reclameslogan van Microsoft: “Where Do You Want To Go Today?” 22 PIN = Personal Information Number, een numerieke string van lengte 4 of 5.

77

10,25 mm

19,23 mm

53 ,98 mm

85,6 mm

Figuur 7.3: Formfactor van een smartcard

Implementaties die gebaseerd zijn op resistente smartcards bieden volgende voordelen: • Smartcards zijn eenvoudig te beschermen tegen virusen en Trojaanse paarden die de bedoeling hebben de geheime sleutel te stelen. • Als de smartcard een toegangscontrolemechanisme heeft (bijvoorbeeld een PIN code), dan kan een eventuele dief de kaart niet gebruiken zonder de PIN code. Nog meer geavanceerde smartcards kunnen zelfs beveiligd worden d.m.v. biometrische eigenschappen, bijvoorbeeld een vingeradruk. • De resistentie-eigenschap gecombineerd met het feit dat de geheime data de kaart nooit verlaat, maakt dat de smartcards (en dus het sleutelmateriaal) niet te dupliceren zijn; deze eigenschap geldt uiteraard enkel voor klasse 3, de smartcards met CPU. • Als een resistente smartcard bovendien voorzien is van een interne klok, dan kan de kaart uit zichzelf dienst weigeren als de uiterste houdbaarheidsdatum van het certificaat (en dus de sleutel) verstreken is (in principe ook dus enkel klasse 3). • Je kan op een veilige manier je certificaat overal mee naartoe nemen portabiliteit. • Nu het onrechtmatig gebruik van het geheime sleutemateriaal na verlies of diefstal drastisch beperkt is – de kaart is immers beveiligd d.m.v. een PIN-code en is bovendien resistent –, vermindert de afhankelijkheid van certificaatrevocatie, want net diefstal en verlies maken het gros van de gerevoceerde certificaten uit. • Smartcards bieden ook een psychologisch voordeel voor de gebruiker. De gebruiker kan zijn smartcard inzetten waar en wanneer hij/zij dat wil en moet niet afgaan op de computer die zijn sleutelmateriaal automatisch gebruikt. De gebruiker heeft het gevoel controle te hebben over zijn/haar sleutels d.m.v. zijn/haar smartcard. Er zijn ook een aantal belangrijke nadelen verbonden aan smartcards: • Misschien wel het belangrijkste nadeel van smardcardtechnologie is de snelheid. Als een certificaat op een smartcard wordt bewaard, kan de opslagruimte een van de kritieke factoren zijn, immers elk certificaat vergt ten minste één handtekening. De grootte van een handtekening hangt af van het gebruikte algoritme; in het geval van 1024-bit RSA is de handtekening 128 bytes groot. Tellen we daar de andere datavelden en nog wat overhead door de ASN.1 structuur bij op en elk certificaat is een paar honderd bytes groot. Veel smartcardlezers hebben echter maar een beperkte doorvoer van 9600 bps, waardoor de grootte van het certificaat van groot belang is als we de snelheid van de smartcardapplicatie aanvaardbaar willen houden. Tijdens de ontwikkeling van het Kava-prototype hebben we een plug-in geschreven voor Netscape Navigator om de SIS-kaart van een patiënt te kunnen uitlezen. Hiervoor hebben we een Java programmaatje geschreven dat via Javascript en LiveConnect aan de browser verbonden is. De veldjes van een HTML formulier kunnen zo ingevuld worden met de gegevens van de patiënt die rechtstreeks uit de SIS-kaart werden gehaald. Wat opviel bij het testen van het prototype was dat het uitlezen van slechts enkele korte veldjes reeds redelijk lang in beslag nam: ettelijke seconden. Vermits we geen gegevens hebben van andere smartcardlezers, kunnen we moeilijk veralgemenen. De kaartlezer die we gebruikt hebben was beperkt tot 9600 bps.

78

Sommige modellen halen snelheden van 9600 tot 115200 bps en zijn verbonden d.m.v. een seriële interface die een snelheid van 76800 bps haalt. Nieuwere modellen hebben een USB23 aansluiting, waardoor de connectiesnelheid naar de PC toe geen rol meer speelt. •

Roland Moreno, een onafhankelijker onderzoeker die in 1974 de eerste smartcard uitvond, wijst erop dat smartcards het potentieel hebben om “Big Brother’s little helper” te worden. De resistentie van smartcards verbergt namelijk de interne werking van de kaart voor zijn houder. Op die manier wordt het moeilijk – om niet te zeggen onmogelijk – om na te gaan of de smartcard geen persoonlijke gegevens lekt. Een gegevenslek kan geforceerd worden door gebruik te maken van het zogenaamde Van Eck effect, door bepaalde radiosignalen uit te zenden, door bepaalde informatie in de kaart proberen te schrijven, door de verschillende acties die je op een smartcard kan verrichten te timen, … Onder het Van Eck effect verstaan we hetvolgende: microprocessoren, toetsenborden, computerschermen, seriële kabels, printers en bijna alle andere toebehoren geven elektromagnetische straling af. Deze signalen kunnen vanop enige afstand opgevangen en geanalyseerd worden. Wim Van Eck beschrijft de mogelijkheden van luistervinken m.b.v. het opvangen van elektromagnetische straling in zijn paper [VanEck1985].

7.6.2 Smartcards integreren met software-oplossingen Laat het duidelijk zijn dat een smartcard geen oplossing op zich is. Omwille van zijn concept kan het enkel functioneren in combinatie met een ander toestel: de meeste smartcards hebben immers geen eigen energiebron, dus hiervoor zijn ze totaal afhankelijk van andere apparatuur. Als we smartcards kaderen in de grotere problematiek van het veilig opslaan van certificaten, dan begrijpen we intuitief dat we m.b.v. een smartcardlezer de smartcard in contact gaan brengen met een desktop computer, een notebook, een PDA (Personal Digital Assistent), … Uiteraard moet er ook zorg besteed worden aan de software die gebruik maakt van de smartcard, want als deze software zwakheden vertoont, dan blijft diefstal van het sleutelmateriaal uiteraard een gevaar. De 3de categorie van smartcards – die met verwerkingseenheid aan boord – zorgt ervoor dat het geheime sleutelmateriaal de smartcard nooit moet verlaten. Alle handtekenopdrachten kunnen door de smartcard zelf worden uitgevoerd. Hoewel dit te koste gaat van de snelheid van de opdracht (we nemen aan dat een smartcard over een minder krachtige CPU beschikt dan een standaard computer), is dit zeer interessant vanuit het standpunt van de veiligheid van het sleutelmateriaal.

7.7 Privacy: welles of nietes? Uit voorgaande paragrafen is duidelijk geworden dat het privacy probleem dat vandaag de dag reeds bestaat d.m.v. digitale certificaten verergerd kan worden. Individuen zullen meer en meer verplicht worden om digitale certificaten te gebruiken om zich te identificeren bij online transacties. En net het woordje identificatie is het centrale probleem als we het over privacy hebben. Bepaalde transacties moeten in gehele anonimiteit uitgevoerd kunnen worden. De eigenschappen, inherent aan een PKI systeem gebaseerd op de huidige generatie van certificaten, maken dit niet mogelijk. Smartcards kunnen een rol spelen bij het verbeteren van de veiligheid van het sleutelmateriaal. Bovendien hebben ze ook een psychologische functie: ze geven hun gebruikers het gevoel dat ze in staat zijn om hun sleutelmateriaal beter onder controle te houden. Vooral de smartcards met CPU lijken interessant: ze garanderen immers dat het sleutelmateriaal de kaart nooit hoeft te verlaten. Jammer genoeg zijn de meest courante implementaties hier niet op gebaseerd wegens te kostelijk. Er wordt momenteel nog onderzoek verricht naar nieuwe vormen van digitale certificaten die de privacy van individuen beter kunnen beschermen.

23

USB = Universal Serial Bus. Een USB interface heeft een basissnelheid van 1,5 Mbps.

79

Hoofdstuk 8 Conclusie “An idealist believes the short run doesn't count. A cynic believes the long run doesn't matter. A realist believes that what is done or left undone in the short run determines the long run.” — Sydney J. Harris

De verhaallijn van de afgelopen hoofdstukken heeft ons langs een heleboel aspecten geleid die betrekking hebben op het tot stand brengen van beveiligde communicatiekanalen op het Internet. We hebben echter niet enkel de protocols voor beveiligde verbindingen zelf aangeraakt, maar ook de grotere problematiek rond de publieke sleutel infrastructuren bekeken en ons afgevraagd wat de gevolgen zijn van het veelvuldig gebruik van beveiligde verbindingen op de privacy. Nu we al deze facetten bestudeerd hebben, kunnen we teruggrijpen naar onze hypothese: De huidige methoden voor Internetbeveiliging voldoen om adequate beveiliging en privacy aan te bieden. Er bestaat echter geen – eenvoudige – eenduidige conclusie, daar er verschillende aspecten beschouwd moeten worden… Laat ons meteen duidelijk stellen dat de huidige generatie van beveiligingsprotocols voor beveiligde communicatie via het Internet op een overtuigende manier voldoen. De de facto standaard, Secure Socket Layer, beantwoordt volledig aan de criteria van performantie en beveiliging. De performantiehandicap van het protocol situeert zich vooral ter hoogte van de handshakefase. Netwerkverbindingen met een beperkte latency ondervinden echter weinig last van deze handicap. Bij veelvuldig gebruik van een connectie maakt het mechanisme van het hernemen van een sessie de performantie vergelijkbaar met gewone – niet-beveiligde – socketverbindingen. Wat betreft de beveiliging kunnen we zeggen dat de aanvallen die gekend zijn onrealistisch zijn: ze hangen immers van te veel parameters af. Om beveiligde verbindingen mogelijk te maken is er nood aan een goed uitgebouwde publieke sleutel infrastructuur. De certificaat authoriteit speelt een essentiële rol bij de verdeling, opslag en revocatie van certificaten. Geen van de huidige revocatiemechanismen biedt echter een goed antwoord op de eis van versheid van informatie omtrent de revocatiestatus van een certificaat. Dit is dus ook duidelijk nog een gebied voor verder onderzoek. Nu we de beveiligingsaspecten hebben overlopen, richten we ons op het privacy-aspect. We kunnen duidelijk stellen dat de huidige generatie van digitale certificaten de privacy van individuen en organisaties niet ten goede komt. Een certificaat identificeert zijn eigenaar immers op onomstotelijke wijze en alle acties binnen de publieke sleutel infrastructuur kunnen op een eenvoudige manier gevolgd worden. Selectieve anonimiteit van een individu en onverenigbaarheid van transacties zijn de 2 criteria die we zoeken in een privacybewarend mechanisme en hier voldoen de huidige certificaten niet aan. Ook hier is verder onderzoek nog volop bezig.

80

Digitale certificaten opslaan op resistente smartcards die bovendien beschikken over een interne verwerkingseenheid, komt de veiligheid van de certificaten ten goede en werkt privacy-bevorderend. Resistente smartcards hebben immers het voordeel dat ze zichzelf deactiveren bij het herhaaldelijk invoeren van een verkeerde identificatie. Beschikt de smartcard bovendien over een interne verwerkingseenheid, dan moet het sleutelmateriaal de kaart nooit verlaten. Jammer genoeg zijn smartcards met geïntegreerde CPU zeldzaam wegens – voorlopig – te kostelijk. Bovendien bieden smartcards een psychologisch voordeel: ze geven gebruikers het gevoel meer controle te hebben over hun certificaten. Welke eindconclusie kunnen we nu trekken? Beveiligde communicatie aanbieden via een publiek netwerk zoals het Internet is duidelijk perfect mogelijk. Het zijn echter de “randfenomen” zoals de publieke sleutel infrastructuur en de privacy van een dergelijk systeem, die steken laten vallen. Ook deze laatste conclusie moeten we in perspectief plaatsen… De privacy van gegevens – de vertrouwelijkheid – wordt quasi perfect gegarandeerd. De privacy van individuen vormt echter een heikel punt in de meeste geautomatiseerde (persoonsgegevensverwerkende) systemen. Waarschijnlijk is de combinatie van een wettelijke regelgeving en een technologische bijsturing de beste kans om dit probleem – in de mate van het mogelijke – te overkomen.

81

Appendix A Performantiegegevens van cryptografische algoritmen

A.1 Algemeen Onderstaande tests werden uitgevoerd met OpenSSL24, een freeware pakket dat ter beschikking wordt gesteld voor een groot aantal platformen. Het pakket is in eerste instantie bedoeld voor het testen van SSL omgevingen, bijvoorbeeld de configuratie nagaan van een met SSL geconfigureerde webserver. Het pakket biedt echter ook de mogelijkheid om de performantie van de gebruikte (encryptie)algoritmen te testen. Buiten het feit dat we de absolute waarden weergeven waarmee een bepaald algoritme kan (de)crypteren, geven we ook een tabelletje mee waarin we een vergelijking maken tussen 3 standaard computerconfiguraties. Twee configuraties bevatten dezelfde hardware maar een andere besturingssysteem, dit laat ons toe om ook eens te kijken naar de invloed van het operating system. Deze computerconfiguraties zien er als volgt uit: • Pentium 200 (Linux) Intel Pentium 200 MHz (zonder MMX) 40 MB EDO RAM Red Hat Linux 7.1 (kernel 2.4.2-2) • Pentium 200 (Windows) Intel Pentium 200 MHz (zonder MMX) 40 MB EDO RAM Microsoft Windows 98 Second Edition (build 4.10.2222 A) • Athlon 800 AMD Athlon 800 MHz 384 MB SDRAM (133 MHz) Microsoft Windows 2000 Service Pack 2 (build 2.00.2195) In het kader van deze test maken we op de 3 platforms gebruik van OpenSSL versie 0.9.6, gedateerd 24/09/2000. Voor wat betreft de windows omgevingen maken we gebruik van Cygwin25 om OpenSSL op te draaien.

24

OpenSSL is terug te vinden op http://www.openssl.org Cygwin is een UNIX omgeving voor Windows 9x/NT/2000/XP en bevat een emulatielaag voor Windows waardoor een heleboel van de UNIX functionaliteit onder Windows kan aangeboden worden. Een heleboel klassieke UNIX tools worden standaard meegeleverd. Mede-ontwikkeld door Red Hat, is deze omgeving terug te vinden op: http://sources.redhat.com/cygwin/

25

82

A.2 Performantie van symmetrische algoritmen Vergelijking van 4 symmetrische ciphers met een constante blokgrootte Overzicht courant gebruikte algoritm en (doorvoer m et bloklengte van 8 KB) 70000 60000 Doorvoer KB/s

50000 40000 30000 20000 10000 0 RC2 CBC (128 bit)

RC4 (128 bit)

DES-CBC (56 bit)

Triple DES EDE (168 bit)

Athlon 800

7661.52

64643.77

14827.14

5487.87

Pentium 200 (Linux)

1246.97

6936.64

1431.5

495.9

Pentium 200 (Window s)

1303.27

10401.08

2000.03

747.87

Algoritm en

Figuur A.1: Overzicht van symmetrische encryptie-algoritmen

RC2 met 128 bit sleutel en verschillende blokgrootte 128 bit sleutel RC2 CBC 9000 8000 Doorvoer in KB/s

7000 6000 5000 4000 3000 2000 1000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

7382.47

7691.58

7764.66

7775.3

7661.52

Pentium 200 (Linux)

1051.66

1168.02

1222.77

1249.69

1246.97

Pentium 200 (Window s)

1193.47

1295.81

1310.03

1310.76

1303.27

bloklengte

Figuur A.2: RC2

83

RC4 met 128 bit sleutel en verschillende blokgrootte 128 bit sleutel RC4 encryptie 70000 60000 Doorvoer KB/s

50000 40000 30000 20000 10000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

50782.9

62023.99

64071.93

63986.54

64643.77

Pentium 200 (Linux)

6006.55

6832.99

6971.24

6936.92

6936.64

Pentium 200 (Window s)

8834.52

10383.47

10583.79

10691.01

10401.08

bloklengte

Figuur A.3: RC4

DES (Cipher Block Chaining) met effectieve 56 bit sleutel en verschillende blokgrootte 56 bit sleutel DES CBC 16000 14000 Doorvoer KB/s

12000 10000 8000 6000 4000 2000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

12945.16

14854.3

14908.46

14959.03

14827.14

Pentium 200 (Linux)

1143.83

1333.18

1410.45

1434.62

1431.5

Pentium 200 (Window s)

1745.64

1984.97

2022.47

2013.03

2000.03

bloklengte

Figuur A.4: DES

84

Triple DES met 168 bit sleutel (168 bit effectief, 192 bit totaal) en verschillende blokgrootte 168 bit sleutel Triple DES (Encryption-Decryption-Encryption) 6000 5000 Doorvoer KB/s

4000 3000 2000 1000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

5292.34

5488.48

5525.26

5577.77

5487.87

Pentium 200 (Linux)

438.75

475.3

491.61

495.22

495.9

Pentium 200 (Window s)

686.51

746.53

751.81

750.41

747.87

bloklengte

Figuur A.5: Triple DES

A.3 Performantie van asymmetrische algoritmen RSA

Aantal operaties per seconde

5000 4000 3000 2000 1000 0

private

public

private

512

512

1024

Athlon 800

373.6

4684.1

Pentium 200 (Linux)

53.6

504.1

Pentium 200 (Window s)

58.9

673.7

public

private

public

1024

2048

2048

71.6

1451

11.9

441.8

8.9

166.4

1.4

48.1

11.5

229.9

2

69.3

Sleutelgrootte + type operatie

Figuur A.6: RSA

85

A.4 Performantie van message digest algoritmen SHA 1 SHA 1 45000 40000 35000 Doorvoer KB/s

30000 25000 20000 15000 10000 5000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

5326.45

21200.13

34587.2

40718.49

42418.96

Pentium 200 (Linux)

521.86

1496.7

3370.84

4858.74

5602.99

Pentium 200 (Window s)

691.82

1454.32

3505

5408

6331.42

bloklengte

Figuur A.7: SHA 1

HMAC HMAC (MD5) 120000 100000 Doorvoer KB/s

80000 60000 40000 20000 0

8 bytes

64 bytes

256 bytes

1024 bytes

8192 bytes

Athlon 800

3496.9

22050.77

52462.22

81352.07

96620.98

Pentium 200 (Linux)

484.04

3124.16

7964.92

13088.77

15796.86

Pentium 200 (Window s)

627.49

4115.19

10487.19

17123.07

20470.57

blokgrootte

Figuur A.8: HMAC

86

A.5 Opmerkingen •

Helemaal tot onze verbazing brengt een Windows PC het er beter vanaf dan een PC met Linux. Onze verbazing is des te groter als we beseffen dat de Windows PC gebruik maakt van Cygwin, wat uiteindelijk een soort emulatie-omgeving is voor Linux/UNIX, om OpenSSL te draaien (i.e. OpenSSL draait niet eens in native modus).

•

Bovendien moeten we vaststellen dat de blokgrootte van de te encrypteren plaintext een rol kan spelen wat betreft de efficiëntie. Dit kan belangrijk zijn voor wat betreft het bepalen van de ideale grootte van een SSL record.

87

Appendix B SSL traces

B.1 Algemeen Zowel in hoofdstuk 4 als in hoofdstuk 5 doen we vaak beroep op schema’s en/of traces van SSL verbindingen. Steeds gaat het hier om vereenvoudigde modellen, die enkel laten zien wat strikt noodzakelijk is voor de context. Deze appendix, laat enkele volledige traces zien, waarbij alle details worden weergegeven. Deze traces werden bekomen door op één computer een SSL client en een SSL server op te starten d.m.v. OpenSSL. Met behulp van SSLDump werd het communicatiekanaal tussen client en server onderschept en ingekeken. De gebruikte computerconfiguratie kan als volgt samengevat worden: •

Pentium 200 Intel Pentium 200 MHz (zonder MMX) Red Hat Linux 7.1 (kernel 2.4.2-2) 40 MB EDO RAM

•

Er wordt gebruik gemaakt van OpenSSL versie 0.9.6 (versiedatum 24/09/2000). OpenSSL is terug te vinden op: http://www.openssl.org

•

In het kader van deze tests wordt SSLDump 0.9b2 gehanteerd. Dit programma is terug te vinden op http://www.rtfm.com/ssldump

Opmerkingen: • • • •

SSLDump geeft niet van elk handshakerecord de exacte inhoud weer. Zo ontbreekt in alle traces bijvoorbeeld de random[32]die de client naar de server stuurt. Bij elk bericht staan 2 tijden genoteerd: - Een absolute tijd sinds het begin van de connectie - Tussen haakjes: een relatieve tijd die aangeeft hoe lang een bepaalde stap duurt. Berichten van client naar server worden genoteerd d.m.v. S>C, berichten in de andere zin staan aangeduid met C>S. Enkel bij de trace van de klassieke SSL handshake wordt ook de gegevenstransfer fase en de sluitingsberichtgeving weergegeven.

88

B.2 Traces B.2.1 Simpele SSL handshake

Client

Server ClientHello ServerHello Certificaat Done ServerHello ClientKeyE xchange ChangeCip herSpec Handshake Finished herSpec ChangeCip Finished Handshake

Figuur B.1: Schema simpele SSL handshake

New TCP connection #1: pentium200(1028) <-> pentium200(443) 1 1 0.0300 (0.0300) C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_3DES TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_RC2 SSL2_CK_RC4 SSL2_CK_RC464 TLS_DHE_DSS_WITH_RC2_56_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA SSL2_CK_DES TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 SSL2_CK_RC2_EXPORT40 SSL2_CK_RC4_EXPORT40

De algoritmen die de client ondersteund

89

De random waarde die de server bijdraagt. O.a. gebruikt bij het maken van de cryptografische sleutels. 1 2

1 3 1 4 1 5

1 6 1 7

1 8 1 9

0.0300 (0.0000) S>CV3.1(74) Handshake ServerHello Version 3.1 random[32]= 3c bc 14 8d d5 5d 0f 48 e2 87 61 71 d3 01 85 48 0a a7 fd 56 a5 49 cc 0a 84 2e 93 ff 84 32 0a 44 session_id[32]= 1c 12 c5 d2 67 c1 15 f4 a9 4d 00 78 6e 13 e3 f0 09 b5 1f a4 c8 fc bd 8d 61 e3 db e3 19 08 7a 28 cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 0.0300 (0.0000) S>CV3.1(709) Handshake Certificate 0.0300 (0.0000) S>CV3.1(4) Handshake ServerHelloDone 0.1200 (0.0900) C>SV3.1(134) Handshake ClientKeyExchange EncryptedPreMasterSecret[128]= 04 54 4a 5e 22 d6 b7 ba ba 43 98 7c 08 60 ed 86 96 3f 6c 50 73 33 33 55 c2 fb e1 e4 ec 7b 08 75 48 59 23 0b bc 7d 61 26 73 d9 2c c6 c2 97 2b 74 e3 28 4f 92 3a 77 1d 66 56 b1 02 a9 0c 8f b0 c1 5b 9d 4b 54 a5 77 5d 3c 88 e9 a7 9c 8a 48 68 a7 e9 43 1f f1 f8 39 7d 99 0d e6 80 f4 a6 ce fd a2 a9 47 62 08 39 b1 46 f6 4e ee 1a ef 6c 12 90 2b 21 b0 8b 74 9f 60 e6 c8 af 81 d6 20 af 77 29 e8 0.1200 (0.0000) C>SV3.1(1) ChangeCipherSpec 0.1200 (0.0000) C>SV3.1(40) Handshake Finished verify_data[12]= 8b b0 50 a6 52 a4 9e 66 da 0e 2d 32 0.3400 (0.2200) S>CV3.1(1) ChangeCipherSpec 0.3400 (0.0000) S>CV3.1(40) Handshake Finished verify_data[12]= f7 85 19 80 30 e0 2f 84 0d 68 f2 90

session_id, gebruikt bij het hernemen van sessies

Het algoritme dat de server heeft uitgekozen voor verdere communnicatie.

128-byte pre_master_secret (geencrypteerd)

In het Finished bericht staat een MAC die alle gegevens verifieert die de client naar de server heeft gestuuurd. Idem, maar nu voor het berichtenverkeer van server naar client.

1 10 5.6800 (5.3400) C>SV3.1(32) application_data --------------------------------------------------------------GET / --------------------------------------------------------------1 11 5.6900 (0.0100) S>CV3.1(2696) application_data --------------------------------------------------------------HTTP/1.0 200 ok Content-type: text/html body weggelaten

Een HTTP GET request.

Een (ingekorte) HTML pagina als antwoord op de GET.

--------------------------------------------------------------1 5.7300 (0.0400) S>C TCP FIN Een Alert om het 1 12 5.7500 (0.0200) C>SV3.1(24) Alert level warning einde van de connectie value close_notify aan te duiden. Figuur B.2: Trace simpele SSL handshake

90

B.2.2 Handshake d.m.v. session resumption

Client

Server ClientHello ServerHello herSpec ChangeCip Finished Handshake ChangeCip herSpec Handshake Finished

Figuur B.3: Schema handshake hernomen sessie

New TCP connection #2: pentium200(1039) <-> pentium200(443) 2 1 0.0000 (0.0000) C>SV3.1(115) Handshake ClientHello Version 3.1 random[32]= 3c bc 14 e2 14 b5 03 45 7c 8c 62 32 05 af 7d 1c fe 26 b0 f0 d2 a5 09 47 2f 65 73 c5 f7 e7 d3 1e resume [32]= 17 0c 56 e5 8f f4 a4 5f 61 17 d4 b5 4d 35 67 25 60 81 53 08 0f 29 e5 9d 66 48 55 fc db b1 34 2b cipher suites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_DHE_DSS_WITH_RC2_56_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 compression methods NULL 2 2 0.0200 (0.0200) S>CV3.1(74) Handshake ServerHello Version 3.1 random[32]= 3c bc 14 e2 ac 91 77 89 6d 00 f9 b8 65 6b 47 31 02 f4 9c 77 d2 70 6b 97 6c b1 9a cf f3 41 e5 37 session_id[32]= 17 0c 56 e5 8f f4 a4 5f 61 17 d4 b5 4d 35 67 25 60 81 53 08 0f 29 e5 9d 66 48 55 fc db b1 34 2b cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL

91

2 3 2 4

0.0200 (0.0000) S>CV3.1(1) ChangeCipherSpec 0.0200 (0.0000) S>CV3.1(40) Handshake Finished verify_data[12]= f6 64 9b e4 47 82 46 95 bb 2d 92 cb

2 5 2 6

0.0300 (0.0100) C>SV3.1(1) ChangeCipherSpec 0.0300 (0.0000) C>SV3.1(40) Handshake Finished verify_data[12]= 8f 6b 5d 87 a1 ed 32 eb 61 f7 bc d7 Figuur B.4: Trace handshake hernomen sessie

B.2.3 SSL handshake met client authenticatie

Client

Server ClientHello o ServerHell Certificate Request Certificate Done ServerHello Certificate ClientKeyE xchange Certificate Verify ChangeCip herSpec Finished herSpec ChangeCip Finished

Figuur B.5: Schema handshake met client authenticatie

New TCP connection #1: pentium200(2645) <-> pentium200(443) 1 1 0.0300 (0.0300) C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_3DES TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_RC2 SSL2_CK_RC4 SSL2_CK_RC464 TLS_DHE_DSS_WITH_RC2_56_CBC_SHA

92

1

1 1

1 1

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA SSL2_CK_DES TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 SSL2_CK_RC2_EXPORT40 SSL2_CK_RC4_EXPORT40 2 0.4400 (0.4100) S>CV3.1(74) Handshake ServerHello Version 3.1 random[32]= 3c bc 24 e3 4c 3e 96 42 c3 ad 53 2b 29 37 1d bb 2f c3 52 1e 42 71 95 6d 7a 33 b6 e7 a7 92 ee 76 session_id[32]= 7b 9c 86 29 53 1a 2d c3 aa 8a 18 30 25 72 8a 8d 58 af fa cf de e8 5b cb c2 2b a8 05 f2 e1 bf 59 cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 3 0.4400 (0.0000) S>CV3.1(1683) Handshake Certificate 4 0.4400 (0.0000) S>CV3.1(182) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_authority 30 81 a4 31 0b 30 09 06 03 55 04 06 13 02 42 45 31 10 30 0e 06 03 55 04 08 13 07 41 6e 74 77 65 72 70 31 10 30 0e 06 03 55 04 07 13 07 41 6e 74 77 65 72 70 31 17 30 15 06 03 55 04 0a 13 0e 41 5a 20 50 72 6f 64 75 63 74 69 6f 6e 73 31 17 30 15 06 03 55 04 0b 13 0e 64 65 76 65 6c 6f 70 65 72 20 74 65 61 6d 31 18 30 16 06 03 55 04 03 13 0f 41 6e 64 79 20 5a 61 69 64 6d 61 6e 20 43 41 31 25 30 23 06 09 2a 86 48 86 f7 0d 01 09 01 16 16 41 6e 64 79 2e 5a 61 69 64 6d 61 6e 40 53 6b 79 6e 65 74 2e 62 65 ServerHelloDone 5 0.5300 (0.0900) C>SV3.1(1677) Handshake Certificate 6 0.6800 (0.1500) C>SV3.1(134) Handshake ClientKeyExchange EncryptedPreMasterSecret[128]= 18 11 cc 3a 4f 26 01 02 53 0a e3 79 a3 9e c9 f7 e8 59 58 b4 85 24 c7 10 0f 03 71 fb a5 7f e3 bc c8 b7 e8 54 d2 73 bc 94 be ff b0 9a 46 e7 f1 fb fb 85 39 12 24 4a 00 7a 42 3b f9 d7 03 2c ac ad 04 1f dc 65 b9 c9 53 17 6d 08 a1 8a 1d 02 13 bc 96 9c 59 23 9d 98 32 ec 2c 3d 20 31 b0 29 fa f9 dc 3d 15 b1 41 99 46 89 43 3e 83 bd 03 78 38 6c 86 c5 e9 d3 66 bc 18 da 6c c8 36 a3 59 cb 01 bc

Van welke uitgevers (CA’s) client certificaten verwacht worden.

93

1 7

0.6800 (0.0000) C>SV3.1(134) Handshake CertificateVerify Signature[128]= 9e cd 1f f9 25 d9 b6 4d d4 5c 00 08 91 e2 5c b3 d0 7c 7b dc d2 3f d1 7e e1 df be 4f 8a c1 45 0c f7 de a7 19 f0 e8 0f 37 4f 30 a4 a9 ad c2 6e 96 7a 19 53 ed aa 84 33 d5 3e f1 97 cc 10 09 38 ec 57 55 18 10 b9 67 87 68 ca 88 98 37 75 fb 66 97 6e 0e 2e c5 b8 28 30 a3 c8 13 bf 7a 47 43 e3 05 fb fe d0 5c 8f d3 13 16 28 f5 84 c4 a3 5f d2 51 1 8 0.6800 (0.0000) C>SV3.1(1) ChangeCipherSpec 1 9 0.6800 (0.0000) C>SV3.1(40) Handshake Finished verify_data[12]= e7 44 fc 30 66 e9 b9 f6 9a c2 c9 08 1 10 0.9100 (0.2300) S>CV3.1(1) ChangeCipherSpec 1 11 0.9100 (0.0000) S>CV3.1(40) Handshake Finished verify_data[12]= 74 ae 3e 34 6a 04 40 7d 6d 5c 11 e0

83 1e 0b c2 a7 49 e4 1e

c4 2f 9f df c4 82 ae c0

String versleuteld met private sleutel van client digitale handtekening. Server kan deze handtekening verifieren aan de hand van de publieke sleutel van de client.

Figuur B.6: Trace handshake met client authenticatie

94

Appendix C Beveiliging voor de IT manager

C.1 Algemeen De Computer Science Corporation26 publiceert jaarlijks het verslag van een enquête die ze wereldwijd onder IT managers houdt. Het doel van dit zogenaamde Critical Issues of Information Systems Management rapport is weer te geven welke kwesties IT managers het afgelopen jaar als kritiek hebben ervaren. Het rapport voor 2001 is op 16 mei 2002 gepubliceerd. De enquête werd afgenomen na de terroristische aanslagen van 11 september 2001, dit kan zeker een invloed hebben op sommige resultaten. O.a. Professor Van Grembergen verwijst vaak naar dit verslag in zijn cursus beleidsaspecten van computersystemen. In deze appendix overlopen we kort een aantal resultaten van deze enquête. We zijn uiteraard in de eerste plaats geïnteresseerd in hoe belangrijk IT managers het Internet vinden en in hoeverre mate IT managers belang hechten aan beveiliging. Figuur C.1 geeft een overzicht van 15 kwesties die IT managers als belangrijkste beschouwen voor 2001. 15 belangrijkste IT kwesties van 2001 (wereldwijd) Rang

Kwestie

1 2 3 4

Optimizing Enterprise-wide IS Services Optimizing Organizational Effectiveness Organizing and Utilizing Data Connecting to Customers, Suppliers, and/or Partners Electronically Protecting and Securing Information Systems (beveiliging) Updating Obsolete Systems Aligning IS and Corporate Goals Instituting Cross-Functional Information Systems Implementing Business Transformation Initiatives Improving the Systems Application Process Using IT for Competitive Breakthroughs Developing an Electronic Business Strategy (e-business) Integrating Systems with the Internet (integratie met Internet) Cutting IS Costs Capitalizing on Advances in IT

5 6 7 8 9 10 11 12 13 14 15

% aantal respondenten die kwestie als belangrijk ervaren

64,8 % 62,6 % 61,4 % 57,2 % 55,3 % 54,2 % 54,2 % 52,4 % 49,5 % 48,0 % 46.1% 44,9 % 42,4 % 41,4 % 40,2 %

Figuur C.1: 15 belangrijkste IT kwesties van 2001 (Engelse benamingen) 26

Computer Science Corporation, zie http://www.csc.com

95

Wat meteen opvalt is dat beveiliging de 5de plaats inneemt: meer dan de helft van de respondenten ervaart beveiliging dus als een kritiek punt. Deze beveiliging moet echter ruim genomen worden en richt zich dus zeker niet enkel tot het beveiligen van communicatie en/of transacties op Internet. Bovendien zien we ook dat op plaatsen 12 en 13 de concepten van e-business en integratie met Internet voorkomen. Vorig jaar stond e-business nog op de 5de plaats, maar door de economische recessie was deze terugval te te verwachten.

C.2 Verschillen tussen regio’s We zijn echter ook wel geïnteresseerd in hoe bovenstaande kwesties verschillend worden ervaren in volgende regio’s: • Noord-Amerika • Europa • Azië • Australië We bekijken hoe de belangrijkheid van beveiliging, e-business en integratie met Internet verschilt per regio. De situatie bekijken we aan de hand van Figuur C.2: de cijfers geven de plaats aan in de rangschikking van IT-kwesties.

Wereldwijd

NoordAmerika

Europa

Azië

Australië

Protecting and Securing Information Systems Developing an Electronic Business Strategy Integrating Systems with the Internet

5 12 13

2 13 10

10 11 18

7 12 13

6 9 7

Figuur C.2: Verschil qua regio betreffende de belangrijkheid van e-business, Internet en beveiliging

Deze gegevens zijn zeker interessant, want de uitschieter is het beveiligingsaspect in Noord-Amerika. Dit fenomeen kan perfect verklaard worden door de gebeurtenissen van 11 september 2001.

C.3 Verschillen per industrie We kunnen bovendien ook eens gaan kijken hoe verschillende industrieën staan t.o.v. beveiliging van hun informaticasystemen, dit wordt uitgebeeld in Figuur C.3. Industrie Consumentengoederen Financiële instellingen Overheidheidsinstellingen Gezondheidszorg Productie Olie en energie Kleinhandel

Plaats van beveiliging in top 10 van belangrijke IT kwesties 5 1 4 2 9 10 -

Figuur C.3: Verschil qua industrie betreffende de belangrijkheid van beveiliging

96

Het is geen verrassing om te moeten vaststellen dat financiële instellingen zeer veel belang hechten aan de beveiligingsaspecten van hun systemen. Bovendien valt op dat ook de gezondheidszorg zich ten zeerste bekommert om beveiliging. Eens te meer wordt de relevantie van onze stage bij Kava duidelijk.

C.4 Privacy Op de vraag aan IT-managers of privacy voor hun een onderdeel vormt van de beveiligingsaspecten binnen hun organisatie, antwoordt: • 82,1 % JA • 17,9 % NEE

C.5 Beveiliging in het kader van e-business Welke technologisch en/of business factoren e-business belemmeren in de ogen van IT-managers, staat afgebeeld in figuur C.4.

Rang (wereldwijd)

Wereldwijd

NoordAmerika

Europa

Azië

Australië

Unclear Return on Investment Difficulty in Aligning the Organization on Course of Action Lack of Interest among User Community Difficulty/Expense of Integration with Existing System Unresolved Security Issues Difficulty of Enacting Required Organizational Process Change Lack of Appropriate Funding Channel Conflicts Lack of Appropriate Technology Solutions Other

1 2

49,3% 39,6%

51,7% 34,5%

49,1% 44,3%

50,4% 36,1%

45,2% 43,3%

3 4

36,4% 35,7%

30,9% 42,0%

48,1% 22,3%

31,9% 50,4%

31,7% 35,6%

5 6

33,3% 27,6%

33,0% 34,2%

24,7% 13,6%

27,7% 34,5%

48,6% 32,2%

7 8 9 10

22,9% 21,8% 20,7% 4.4%

26,4% 16,2% 14,1% 7,2%

25,4% 33,4% 25,8% 2,4%

24,4% 12,6% 16,0% 2,5%

13,0% 19,7% 26,9% 3,8%

Figuur C.4: Belemmerende factoren voor e-business (Engelse benamingen)

Blijkt dat internationaal gezien 33,3% van de respondenten problemen met de beveiliging aanhalen als een belemmerende factor voor e-business applicaties. Op de vraag of e-business belemmerd wordt door gebrekkig beveiligingsexpertise binnen de organisatie en/of een gebrek aan geschikte technologiën, antwoorden de IT-managers: • 53,6 % JA • 46,4 % NEE

C.6 Informatiebeveiliging: een “top issue” Beveiliging staat al een tijdje op de agenda van de IT manager, zeker met de explosie van businessto-business en business-to-consumer systemen de afgelopen jaren. De mate van aandacht en van investeringen hangt echter af van de regio en ook van de bedrijfstak waarin we ons begeven.

97

Zo hebben we in de vorige sectie gezien dat beveiliging in Noord-Amerika enorm belangrijk is geworden door de terroristische bedreigingen, maar de vraag blijft: is dit een tijdelijk verschijnsel of blijft beveiliging een belangrijk punt? Naar alle waarschijnlijkheid is het een “blijver”. Als we beseffen dat 85% van de systemen die vandaag de dag nieuw ontwikkeld worden (dus geen aanpassing van een bestaand systeem), integraal gebruik maken van Internet, dan kunnen we ons voorstellen dat beveiliging de komende jaren belangrijk blijft. Of het daarbij een “kwestie” blijft zal niet alleen afhangen van de technologische evolutie, maar ook van de beschikbaarheid van voldoende beveiligingsexperts.

98

Bibliografie

[Ankney2000]

Richard C. Ankney Certificate Revocation Mechanisms 2000, http://www.certco.com

[Brands2000]

Stefan A. Brands Rethinking public key infrastructures and digital certificates: building in privacy 2000, The MIT Press ISBN 0226024918

[DaviesEtAl1989]

D.W. Davies; W.L. Price Security for Computer Networks, Second Edition: An Introduction to Data Security in Teleprocessing and Electronic Funds Transfer 1989, John Wiley & Sonds ISBN 0471921378

[DeSchutter]

Prof. B. De Schutter Juridische aspecten van informatica Vrije Universiteit Antwerpen, dienst uitgaven

[Diffie1976]

W. Diffie, M.E. Hellman New directions in cryptograpy 1976, IEEE Transactions on Information Theory, 22, 6, p 655

[Everett2002]

Dr. David B Everett Smart Card Technology: Introduction To Smart Cards http://www.smartcard.co.uk/resources/articles/intro2sc.html

[Ferguson1999]

Niels Ferguson & Bruce Schneier A Crypographic Evaluation of IPSec 1999, Counterpane Internet Security Inc (http://www.counterpane.com)

[Gartner2002]

Security in a world without secrets Gartner Research, verschillende auteurs. http://security.gartner.com

[Gutmann1996]

Peter Gutmann Beschrijving van het ontvreemden van de private sleutel in Netscape webservers (nieuwsgroep post) 1996, http://www.cs.auckland.ac.nz/~pgut001/pubs/netscape.txt

[Gutmann1997]

Peter Gutmann How to recover private keys for Microsoft Internet Explorer, Internet Information Server, Outlook Express and many others. 1997, http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt

[Krywaniuk]

Andrew Krywaniuk (Alcatel) Security Properties of the IPSec protocol

99

21/11/2001, http://www.ietf.org [Labouret2000]

Ghislaine Labouret ([email protected]) IPSec: a technical overview http://www.hsc.fr/ressources/articles/ipsec-tech/index.html.en

[Mitre1994]

Shimshon Berkovits, Santosh Chokhani, Judith A. Furlong, Jisoo A. Geiter, and Jonathan C. Guild. Public Key Infrastructure Study: Final Report. Produced by the MITRE Corporation for NIST, April 1994. Zie http://csrc.nist.gov/pki/documents/mitre.ps en http://www.nist.gov

[RFC0896]

J. Nagle Congestion Control in IP/TCP Internetworks http://www.ietf.org

[Persoonsgegevens2001] Bescherming van persoonsgegevens in België http://www.privacy.fgov.be/publicaties/nota_info_NL.pdf [PISA]

PISA: Providing Information About Internet Security Aspects Wet van 28 november 2000 inzake informaticacriminaliteit. http://cwisdb.cc.kuleuven.ac.be/pisa/nl/juridisch/infocrimewet.htm

[Privacy1998]

Wet van 8 december 1992 tot bescherming van de persoonlijke levenssfeer ten opzichte van de verwerking van persoonsgegevens. Gecoördineerde versie (1998) http://www.privacy.fgov.be/normatieve_teksten/gecoordineerde_versie.pdf

[RCF1825]

R. Atkinson Security Architecture for the Internet Protocol http://www.ietf.org

[Rescorla1999]

E. Rescorla, A. Schiffman The Secure HyperText Transfer Protocol 1999, http://www.ietf.org

[Rescorla2000]

Eric Rescorla SSL and TLS: Designing and Buidling Secure Systems 2000, Addison Wesley ISBN 0201615983

[RFC2411]

R. Yhayer, N. Doraswamy, R. Glenn IP Security: Document Roadmap http://www.ietf.org

[RFC2459]

R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile 1999, http://www.ietf.org

[SB29092001]

Het Belgisch Staatsblad van 29 september 2001 Terug te vinden op http://just.fgov.be

[VanEck1985]

Wim van Eck Electromagnetic Radiation from Video Display Units: An Eavesdropping Risk? Computers & Security, 1985 Vol. 4. Online versie: http://jya.com/emr.pdf

[VanGrembergen1996]

Prof. Dr. Wim Van Grembergen Economische en Sociaal Tijdschrift, 1996/4, blz 593-616

[WagnerEtAl1997]

David Wagner (University of California, Berkely), Bruce Schneier (Counterpane Systems) Analysis of the SSL 3.0 Protocol The Second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp. 29-40. http://www.counterpane.com/ssl.html

[Westin1967]

Alan Westin Privacy and Freedom New York: Atheneum, 1967

100

Lijst van figuren

Figuur 1.1: SIS-kaart zoals deze reeds enkele jaren is ingeburgerd in België ....................................... 5 Figuur 2.1: Vergelijking De Post versus beveiligde verbinding (technische aspecten) ........................ 10 Figuur 2.2: Plaintext versus ciphertext (geëncrypteerde data) ............................................................. 11 Figuur 2.3: Symmetrische encryptie ..................................................................................................... 11 Figuur 2.4: Asymmetrische encryptie.................................................................................................... 13 Figuur 2.5: Overzicht van RSA ............................................................................................................. 14 Figuur 2.6: Schematische voorstelling van een digitale handtekening................................................. 16 Figuur 2.7: Message authentication code (MAC) schema.................................................................... 17 Figuur 3.1: ISO/OSI model toegepast op de TCP/IP protocolstack...................................................... 20 Figuur 3.2: Familieboom van SSL varianten......................................................................................... 20 Figuur 3.3: SSL draait boven de TCP/IP laag en onder high-level applicatie-protocollen.................... 23 Figuur 3.4: Fasen van kredietkaartbetalingsmechanismen met SET ondersteuning ........................... 24 Figuur 3.5: Twee Security Association bundels tussen 2 hosts............................................................ 28 Figuur 3.6: Authentication Header ........................................................................................................ 28 Figuur 3.8: Een voorbeeld van tunnel modus ....................................................................................... 30 Figuur 3.9: ESP toegepast in tunnel modus ......................................................................................... 30 Figuur 4.1: Enveloppe mechanisme ..................................................................................................... 33 Figuur 4.2: Een overzicht van de SSL fases......................................................................................... 34 Figuur 4.3: overzicht van een simpele SSL handshake........................................................................ 35 Figuur 4.4: SSL record, data fragmentatie en data bescherming ......................................................... 37 Figuur 4.5: SSLv3 sleutelafleiding ........................................................................................................ 39 Figuur 4.6: Sleutelafleidingsprincipe ..................................................................................................... 39 Figuur 4.7: Tijdslijn bij het hernemen van een SSL sessie ................................................................... 41 Figuur 4.8: Tijdslijn bij client authenticatie ............................................................................................ 42 Figuur 5.1: Basisnetwerk....................................................................................................................... 45 Figuur 5.2: Tijdsverloop simpele SSL handshake (client + server op 1 machine; tijd in seconden) .... 46 Figuur 5.3: Tijdsverloop handshake met hernomen sessie (client + server op 1 machine; tijd in seconden) ...................................................................................................................................... 47 Figuur 5.4: Tijdsverloop SSL handshake met client authenticatie (client + server op 1 machine; tijd in seconden) ...................................................................................................................................... 48 Figuur 5.5: Overzicht performantie van 3 verschillende SSL handshakes ........................................... 49 Figuur 5.6: SSL record verwerkingssnelheid op een Pentium 2 300 MHz (bron: [Rescorla2000], p. 198) ................................................................................................................................................ 49 Figuur 5.7: Timing van een HTTP connectie versus HTTPS connectie ............................................... 50 Figuur 5.8: Het Nagle algoritme in combinatie met session resumption .............................................. 52 Figuur 5.9: Session resumption met het Nagle algoritme uitgeschakeld.............................................. 52 Figuur 5.10: Test-setup voor het prototype bij Kava............................................................................. 53 Figuur 5.11: Performantiegegevens van SSL in netwerkomgeving...................................................... 54 Figuur 5.12: Ciphersuite rollback of downgrade to export .................................................................... 56 Figuur 5.13: Toepassing van verschillende versies van SSL door webservers ................................... 56 Figuur 5.14: Ondersteuning van encryptie-algoritmen bij SSLv2 webservers...................................... 57

101

Figuur 5.15: MAC van het SSL record protocol .................................................................................... 58 Figuur 5.16: ChangeCipherSpec berichten wordt niet opgenomen in de MAC’s die de handshake berschermen .................................................................................................................................. 58 Figuur 5.17: Mogelijke aanval als ChangeCipherSpec bericht verdwijnt.............................................. 59 Figuur 5.18: Replay aanval ................................................................................................................... 60 Figuur 6.1: De overheid is ook een TTP bij de uitgifte van de klassieke identiteitskaart...................... 63 Figuur 6.2: Voorstelling van een digitaal certificaat .............................................................................. 64 Figuur 6.3: Confederale structuur PKI .................................................................................................. 65 Figuur 6.4: Hiërarchische vertrouwensstructuur binnen een PKI ......................................................... 66 Figuur 6.5: Voorbeeld van een CRL (X.509 formaat) ........................................................................... 67 Figuur 6.6: OCSP responder................................................................................................................. 69 Figuur 7.1: Privacy probleem met OCSP.............................................................................................. 74 Figuur 7.2: Customer Profile Exchange ................................................................................................ 75 Figuur 7.3: Formfactor van een smartcard............................................................................................ 78 Figuur A.1: Overzicht van symmetrische encryptie-algoritmen ............................................................ 83 Figuur A.2: RC2 .................................................................................................................................... 83 Figuur A.3: RC4 .................................................................................................................................... 84 Figuur A.4: DES .................................................................................................................................... 84 Figuur A.5: Triple DES .......................................................................................................................... 85 Figuur A.6: RSA .................................................................................................................................... 85 Figuur A.7: SHA 1 ................................................................................................................................. 86 Figuur A.8: HMAC ................................................................................................................................. 86 Figuur B.1: Schema simpele SSL handshake ...................................................................................... 89 Figuur B.2: Trace simpele SSL handshake .......................................................................................... 90 Figuur B.3: Schema handshake hernomen sessie ............................................................................... 91 Figuur B.4: Trace handshake hernomen sessie ................................................................................... 92 Figuur B.5: Schema handshake met client authenticatie...................................................................... 92 Figuur B.6: Trace handshake met client authenticatie.......................................................................... 94 Figuur C.1: 15 belangrijkste IT kwesties van 2001 (Engelse benamingen).......................................... 95 Figuur C.2: Verschil qua regio betreffende de belangrijkheid van e-business, Internet en beveiliging 96 Figuur C.3: Verschil qua industrie betreffende de belangrijkheid van beveiliging ................................ 96 Figuur C.4: Belemmerende factoren voor e-business (Engelse benamingen)..................................... 97

102

Aantekeningen

103

104