1
We wensen een met de eID ondertekende mail te versturen; in dit geval een mail van een @skynet.be account naar een @cevi.be account en daarna omgekeerd. Na het opstellen van de mail (+) activeren we de knop Ondertekenen en (+) verzenden we de mail. De Outlook client komt dan de eID vragen en tenslotte de (+) PIN code om de mail effectief te kunnen ondertekenen. So far so good, maar wat ziet de ontvanger?
2
Als alles goed gaat, ziet de ontvanger dit bericht (scenario van @skynet.be naar @cevi.be). Wat nieuw is t.o.v. een normale mail (+) is de regel “Ondertekend door”. Meer details omtrent de ondertekening kan je vinden door (+) het certificaat symbool rechts aan te klikken. Door nu alsmaar verder in te zoomen op de details (+) kan je nog meer gegevens bekomen.
3
Als er nu een kink in de kabel zit, ziet de ontvanger dit bericht (scenario van @cevi.be naar @skynet.be). (+) In de regel “Ondertekend door” zal je dan een eerste indicatie vinden van wat er fout gegaan is. Meer details omtrent het probleem kan je vinden door (+) het alarm symbool rechts aan te klikken. Door nu alsmaar verder in te zoomen op de details (+) kan je nog meer gegevens bekomen.
4
We wensen aan te melden aan het Microsoft Partner Network en worden hiertoe omgeleid naar de Windows Live ID aanmeldpagina. Om nu de eindgebruiker de best mogelijke zekerheid te geven dat hij zich wel degelijk zal aanmelden op Windows Live ID, heeft Microsoft gezorgd dat de aanmeldpagina beveiligd is met een geldig “Extended Validation SSL Certificate”. (+) Dit wordt door Internet Explorer gevisualiseerd met een groene achtergrondkleur voor de adresbalk, de functie domeinmarkering en een duidelijke vermelding van de geregistreerde bedrijfsnaam. De functie domeinmarkering zorgt er voor dat de domeinnaam op de adresbalk zwart wordt weergegeven, terwijl de rest van de URL grijs is. Hierdoor is de ware identiteit van de website gemakkelijker te achterhalen.
(+) Door nu te klikken op het beveiligingsveld kan je nog aanvullende informatie over het certificaat opvragen.
5
In dit scenario wensen we aan te melden aan de Outlook Web Access van Cevi. Deze is gepubliceerd doorheen een Microsoft ISA 2006 server. Om nu de eindgebruiker enige zekerheid te geven dat hij zich wel degelijk zal aanmelden op de ISA server van Cevi, heeft Cevi gezorgd dat de aanmeldpagina beveiligd is met een geldig “SSL Certificate”. (+) Dit wordt door Internet Explorer gevisualiseerd met een witte achtergrondkleur voor de adresbalk en de functie domeinmarkering. Er is hier geen vermelding van de geregistreerde bedrijfsnaam. (+) Door nu te klikken op het beveiligingsveld kan je nog aanvullende informatie over het certificaat opvragen.
6
Tenslotte raadplegen we nog eens een dossier in het Rijksregister. We surfen naar de website maar Internet Explorer geeft ons een eerste waarschuwing dat er iets mis is met het server certificaat. Niettemin zouden we mogen verwachten dat de webserver een geldig “SSL Certificaat” bezit. We negeren deze waarschuwing en (+) de website vraagt om ons te authenticeren met een eID. Eens dat achter de rug (+) komen we hopelijk op de gevraagde website terecht. (+) Het certificaatprobleem wordt door Internet Explorer gevisualiseerd met een rode achtergrondkleur voor de adresbalk en de functie domeinmarkering. (+) Door nu te klikken op het beveiligingsveld kan je nog aanvullende informatie over het certificaat en het vastgestelde probleem opvragen.
7
In voorgaande slides hebben we vanuit het standpunt van de gebruiker enkele belangrijke aspecten van “de geheimen van het web” aangehaald. Uiteraard zijn er nog andere toepassingen die gebruik maken van certificaten zoals web services, VPN, Server & Domain Isolation (SDI), DirectAccess, 802.1X AuthN voor LAN & WLAN, Network Access Protection (NAP), etc.. Anders uitgedrukt, certificaten zijn niet meer weg te denken. In deze sessie willen we het vooral hebben over de onderliggende mechanieken, weliswaar nog altijd vanuit een helikopter. De bedoeling is om jullie de samenhang van de diverse componenten beter te laten begrijpen. Dit zullen we doen aan de hand van de volgende agenda...
8
9
... Bespreken figuur. De term “symmetrisch” slaat op het feit dat dezelfde sleutel gebruikt wordt bij zowel het coderen als het decoderen. De symmetrische cryptografie, ook wel klassieke cryptografie genoemd, gaat terug tot in de tijd van Caesar. Het algoritme was toen simpelweg het vervangen van letters: bv A door D, B door E, C door F, etc.. De sleutel was de offset (in het voorbeeld 3). Op vandaag zijn de meest gebruikte versleutelingsalgoritmen: - DES: gestandaardiseerd in 1977, is een 64-bit blokcijfer, sedert 1995 niet meer als veilig te beschouwen (slechts 56-bit sleutel). - 3DES (triple DES): vervangt DES maar wordt op vandaag ook reeds wat veiligheid betreft als twijfelachtig beschouwd (112/168 bit sleutel). - AES (Advanced Encryption Standard): gestandaardiseerd in oktober 2000 en gebaseerd op het Rijndael algoritme. Het is een 128-bit blokcijfer met een sleutel van 128 of 256 bit lang. De ontwikkelaars van Rijndael zijn de twee Belgen Vincent Rijmen (KUL) en Joan Daemen (Proton). AES is in Windows beschikbaar vanaf Windows Vista & 2008 (cfr Suite B Crypto System).
10
Een andere manier om het symmetrisch crypto gebeuren visueel weer te geven is: - Alice, Bob & Carol, Eve de luistervink en Mallet de actieve aanvaller, zijn de typische persona gebruikt in de crypto wereld. - de letter E staat voor de functie encryptie, H voor de functie hash en S voor de functie signeren. - de sleutel wordt weergegeven door een symbool (vierkant, cirkel, ruit, driehoek, etc..) met een soort staart. - het symbool van een harde schijf wordt gebruikt als een beveiligde opslag voor de “permanente” sleutels. (+) ... Rijndael is bovendien zodanig ontworpen dat het heel goed in hardware kan geïmplementeerd worden. Dit levert een supersnelle en zelfs een wat beter beveiligde implementatie op.
11
... Bespreken figuur. Deze werkwijze wordt ook nog “Asymmetric Key Cryptography” genoemd. De term “asymmetrisch” slaat op het feit dat een verschillende sleutel gebruikt wordt bij het coderen en het decoderen. In 1978 werd voor het eerst een asymmetrisch encryptie algoritme gepubliceerd door Ron Rivest, Adi Shamir en Len Adleman. Het is dan ook gekend onder de naam RSA. De veiligheid van RSA steunt op het wiskundig probleem van de ontbinding in priemfactoren bij heel grote getallen. Op dit moment is het nog steeds bijna onmogelijk de twee oorspronkelijke priemgetallen p en q te achterhalen als alleen p*q bekend is en p en q groot genoeg zijn; het zou te veel tijd in beslag nemen. RSA is nog steeds heel populair maar vereist op vandaag toch wel een sleutellengte van minstens 2048 bits. Note: de Belgium eID gebruikt op vandaag nog steeds RSA 1024 bits. Recentere ontwikkelingen zijn ondermeer gebaseerd op de wiskundige problemen “Discrete Logaritme” en “Elliptic Curve”. Zij bieden een veel performantere oplossing dan de populaire RSA en bovendien volstaan veel kleinere sleutellengtes voor eenzelfde graad van veiligheid.
12
Een andere manier om het crypto gebeuren visueel weer te geven is: - Alice, Bob & Carol, Eve de luistervink en Mallet de actieve aanvaller, zijn de typische persona gebruikt in de crypto wereld. - de letter E staat voor de functie encryptie, H voor de functie hash en S voor de functie signeren. - de publieke en private sleutel worden weergegeven door hetzelfde symbool (vierkant, cirkel, ruit, driehoek, etc..) met een soort staart. Echter de private sleutel zit ingesloten in een rechthoek. - het symbool van een harde schijf wordt gebruikt als een beveiligde opslag voor de “permanente” sleutels. (+)
PKI == Public Key Infrastructure
13
Door nu het beste van de symmetrische en de asymmetrische wereld te combineren, bekomen we een hybrid systeem dat in de praktijk heel veel gebruikt wordt. Symmetrische encryptie voor de bulk van de data en asymmetrische encryptie voor het uitwisselen van de symmetrische sleutel. Dit gaat als volgt: (+) ... (+) ... (+) ... Na ontvangst van beide “berichten” zal de ontvanger eerst de symmetrische sleutel bekomen door het eerste bericht te decoderen met zijn private sleutel. Eens dat gebeurd is kan met de aldus bekomen symmetrische sleutel het tweede bericht, dit is de bulk van de data, ontcijferd worden.
14
Het doel van deze algoritmen is het berekenen van een verkorte versie van een reeks tekens, een "samenvatting" (digest), die met een hoge mate van waarschijnlijkheid uniek is voor een gegeven tekenreeks, de "boodschap" (message). (+) Deze algoritmen heten "veilig", in de bewoordingen van de standaard: "voor een gegeven algoritme is het berekeningstechnisch onuitvoerbaar om een boodschap te vinden die een gegeven samenvatting oplevert, of twee verschillende boodschappen te vinden die dezelfde samenvatting opleveren. Elke willekeurige verandering van de boodschap zal bovendien met een hoge mate van waarschijnlijkheid een andere samenvatting opleveren." De bekenste cryptografische hash functies zijn MD-4, MD-5, SHA-0, SHA-1 en SHA-2. Op vandaag zijn MD-4, MD-5 en SHA-0 gekraakt. SHA-1 biedt nog een twijfelachtige veiligheid. Hieruit volgt dat voorlopig enkel nog de SHA-2 varianten (SHA-224, SHA256, SHA-384, SHA-512) als aanvaardbaar beschouwd kunnen worden. Het is in de cryptografische wereld alom bekend dat er dringend werk moet gemaakt worden van betere en veiliger hash functies.
15
... Bespreken figuur. (+) De eigenlijke berekening ziet er als volgt uit... Om de digitale handtekening te controleren zal de ontvanger de volgende bewerkingen moeten uitvoeren: • Bereken zelf de hash van de ontvangen data. • Ontcijfer de door de zender berekende hash uit de digitale handtekening aan de hand van de publieke sleutel van de zender. • Vergelijk beide hashes. Zijn ze identiek dan is de ontvangen data niet gewijzigd en is ook meteen de afzender “bewezen”. Zijn ze evenwel verschillend, negeer de ontvangen data.
16
We hebben daarnet gezien dat Alice de publieke sleutel van Bob gebruikt voor de geheimhouding en dat Bob de publieke sleutel van Alice gebruikt voor het verifiëren van de digitale handtekening. Hoe kunnen we nu Alice overtuigen dat een bepaalde publieke sleutel wel degelijk aan Bob toebehoort (en omgekeerd)? Eén mogelijkheid is dat beide partijen vooraf elkaar fysiek ontmoeten en na verificatie van elkaars identiteit hun publieke sleutels uitwisselen. Hmm... niet erg schaalbaar. Een andere werkwijze is een derde partij in te schakelen die zowel door Alice als door Bob op een of andere manier vertrouwd wordt.
17
Een eerste belangrijke stap is de introductie van het concept van een digitaal certificaat (kortweg certificaat genoemd). (+) Een certificaat is een digitaal ondertekende verklaring dat een bepaalde publieke sleutel toebehoort aan een bepaalde entiteit; ... (+) In de fysieke wereld zijn er talrijke gelijkenissen te vinden; ... In de fysieke wereld vertrouwen we dergelijke “certificaten” omdat: • we geloven dat zij moeilijk te vervalsen zijn. • we de uitgevers ervan vertrouwen. In de digitale wereld moeten we exact dezelfde eigenschappen nastreven.
18
Een certificaat moet je dus normaal gezien aanvragen. Je gaat hiervoor naar een Certificate Authority (CA), je overhandigt je publieke sleutel en wat documenten die de rechtmatigheid van het onderwerp bewijzen. Na verificatie krijg je dan een certificaat terug met ondermeer de drie belangrijke velden: • (+) de uitgever (Issuer) • (+) het onderwerp (Subject) • (+) de publieke sleutel (Public key) Afhankelijk van het onderwerp en de verificatie procedure door de CA krijg je een certificaat met een andere “geloofwaardigheid”. Enkele voorbeelden: • een mailadres: je hebt toegang tot het mailadres. Niet meer en niet minder. • een FQDN (Fully Qualified Domain Name): je bent eigenaar van dat domein. Indien een “extended validation” certificaat aangevraagd wordt is er een internationeel overeengekomen validatie procedure van kracht (eigendomsbewijs van het domein, officiële documenten die de identiteit van de aanvragende organisatie bewijzen, alsook de identiteit van de fysieke persoon die de aanvraag doet en het bewijs dat hij hiertoe gemachtigd is, etc..). • natuurlijke persoon (bv eID): fysieke presentatie met officiële identiteitsdocumenten.
19
Nu Bob een certificaat bezit, hebben we dan het probleem opgelost? (+) Eigenlijk niet want Alice zal Bob’s publieke sleutel enkel vertrouwen indien zij de uitgever van Bob’s certificaat kan vertrouwen. (+) Dus zitten we opnieuw met eenzelfde vraag als voorheen: hoe overtuigen we Alice om de uitgever van Bob’s certificaat te vertrouwen? Eén mogelijkheid is dat Alice en Bob’s uitgever vooraf elkaar fysiek ontmoeten en na verificatie van de identiteit van Bob’s uitgever, deze zijn publieke sleutel aan Alice overhandigt. Hmm... is al iets beter maar nog steeds niet erg schaalbaar. Een andere werkwijze is om opnieuw een derde partij in te schakelen die zowel door Alice als door Bob’s uitgever op een of andere manier vertrouwd wordt. Dit kan natuurlijk niet oneindig doorgaan. (+) Bijgevolg zal Alice op een gegeven ogenblik impliciet een beperkte verzameling van publieke sleutels moeten vertrouwen. Deze beperkte verzameling van publieke sleutels vormt dan de basis om na te gaan of andere nog niet gekende publieke sleutels al of niet te vertrouwen zijn (hierarchisch model).
20
Dit brengt ons naadloos tot de introductie van een PKI (Public Key Infrastructure). (+) Een CA garandeert dat een publieke sleutel toebehoort aan een welbepaalde CA of een “eind entiteit”. Enkele voorbeelden van entiteiten zijn: • Een persoon of gebruikersnaam • Een rol (bv burgemeester, secretaris, ambtenaar burgerlijke stand,...) • Een organisatie of klant • Een pseudonym • Een hardware of een software component (+) Het hierarchisch trust model ziet er dan als volgt uit... Er zijn wereldwijd meerdere Root CA’s: dit zijn self-signed certificaten (uitgever == onderwerp). Het is die beperkte verzameling van publieke sleutels die iedereen impliciet moet vertrouwen (waarvan sprake in de vorige slide).
21
Op het moment van deze schermafdruk waren er een 319 geldige root certificaten aanwezig in de “Local Computer Certificate Store” op een volledig up-to-date Windows XP SP3 machine. In de praktijk worden de root certificaten aangeleverd en up-to-date gehouden door twee bronnen: • Zij zijn ingebakken in het OS of de web browser (cfr Windows Update). • Zij worden door een enterprise beheerstool (bv een AD Group Policy) gepusht naar de beheerde werkstations. Bijgevolg, indien je geen administratieve controle hebt over de werkstations die je diensten wensen aan te spreken, dan is het sterk aangewezen om hiervoor enkel certificaten te gebruiken die vertrouwd worden door de OS/Browser ingebakken root certificaten, dit om allerlei problemen te vermijden en tevens gebruikersvriendelijk te zijn. Dergelijke certificaten noemen we gemakshalve publieke certificaten. Merk op dat er ook nog andere folders zijn die ondermeer tussenliggende certificaten bevatten. Zij worden op eenzelfde manier aangeleverd en up-to-date gehouden.
22
Nu Bob een certificaat bezit en Alice impliciet een verzameling van Root CA’s vertrouwt, hebben we dan het probleem eindelijk opgelost?
(+) Ja, op voorwaarde dat Alice het certificaat van Bob cryptografisch kan valideren tot op het niveau van een door Alice vertrouwde Root CA. Een eerste belangrijke stap hierin is het opstellen van een “certificaat-boom”. (+) Heel simpel uitgelegd, het startpunt is het certificaat van de eind entiteit. Hieruit halen we de uitgever (issuer). Daarna zoeken we een certificaat op dat als onderwerp (subject) dezelfde waarde heeft als de uitgever van het “lagere” certificaat in de boom. Dit proces herhalen we tot we een certificaat ontmoeten waarbij de uitgever dezelfde waarde bevat als het onderwerp. Dit is dan het certificaat van een Root CA. (+) Via de eigenschappen van het certificaat kan men de gevonden certificaat-boom visualiseren. Het opstellen van een certificaat-boom lijkt een vrij eenvoudig probleem maar is in feite een aartsmoeilijke problematiek geworden. Enerzijds omdat men bij het definiëren van deze mechaniek (jaren 1980) er nog vanuit ging dat er een wereldwijde X.500 Directory zou komen waarbij elk onderwerp (subject) een node was in een strikt hierarchisch model, anderzijds omdat het oorspronkelijk idee van “name matching” nagenoeg onoplosbaar geworden is met al de huidige verschillende charactersets en hun coderingsmethoden.
23
De laatste versie 3 van de X509 certificaat standaard bevat dan ook heel wat uitbreidingen zoals de “Subject Key Identifier” (SKI) en de “Authority Key Identifier” (AKI) om het opstellen van de certificaat-boom sterk te vereenvoudigen. Uiteraard is het opstellen van een certificaat-boom niet de enige verificatie. Zij is wel noodzakelijk want enkel zo kan men de publieke sleutel van de uitgever bekomen om de handtekening op het certificaat te controleren. Andere belangrijke velden die moeten gevalideerd worden zijn: • (+) De geldigheidstermijn van het certificaat (van –> tot). • (+) Een cryptografisch geldig certificaat kan ook ongeldig zijn omdat het door de uitgever om een of andere reden ingetrokken is. Waar de lijst van ingetrokken certificaten kan opgehaald worden is vermeld in het CRL distributiepunt. Hieruit volgt dat het werkstation/server die de validering doet Internet connectiviteit naar het CRL distributiepunt moet hebben. • (+) Het ophalen van de lijst van ingetrokken certificaten is niet vrij efficiënt. Men heeft dan ook een nieuwere methode Online Certification Status Protocol (OCSP) ontwikkeld. Hierbij wordt de “revocation status” van een specifiek certificaat opgevraagd. Vanaf Windows Vista/2008 is dit de standaard methode met de CRL check als backup oplossing. Ook hier vereist dit uiteraard Internet connectiviteit naar het OCSP distributiepunt. Goed om weten is ook dat vanaf Windows Vista/2008 de OCSP/CRL check standaard ingeschakeld is. Zorg dan ook dat er steeds Internet connectiviteit is naar die distributiepunten.
24
Een aandachtige toehoorder heeft wellicht reeds opgemerkt dat de certificaatvelden “onderwerp” en “uitgever” een complexe structuur hebben. Om dit te begrijpen moeten we een zijsprongetje maken. Het idee van een wereldwijde X.500 Directory hield in dat elke entiteit een unieke plaats had in een strikt hierarchisch model. Hierdoor kon men aan een entiteit een globaal unieke naam geven om naar die specifieke entiteit te verwijzen. Deze globaal unieke naam werd “distinguished name” genoemd en had een heel specifiek formaat. Alhoewel een wereldwijde X.500 Directory om allerlei redenen nooit echt gerealiseerd werd, vindt men op vandaag nog ettelijke sporen van deze naamgeving ondermeer in certificaten, maar ook in Active Directory. (+) Als voorbeeld nemen we het veld “onderwerp” (subject) in dit certificaat...
25
In een bericht geörienteerd protocol kunnen we niet rekenen op de mogelijkheid om diverse parameters te negotiëren. Anders uitgedrukt, elk bericht verstuurd door de afzender moet op zichzelf voldoende informatie bevatten zodat de ontvanger zijn ding kan doen.
26
27
“Separation of duty” - De regelgeving in vele bedrijven/landen vereist dat onder bepaalde voorwaarden het sleutelpaar (publieke en private sleutel) gebruikt voor de geheimhouding centraal moet “gearchiveerd” worden zodat de data steeds gerecupereerd kan worden. Daarentegen is het normaal verboden zich uit te geven voor een ander (impersoneren) en bijgevolg is er geen enkele reden om het sleutelpaar gebruikt voor de handtekening aan dezelfde regels te onderwerpen. In ons voorbeeld tonen we enkel voor Alice het sleutelpaar gebruikt voor de handtekening, en voor Bob & Carol het sleutelpaar voor de geheimhouding. De werking is dan als volgt: (+) ... (+) ... (+) ... De S/MIME norm ondersteunt diverse aanvullende scenario’s voor digitale handtekening zoals: • Meerdere personen die elk een deel van een bericht ondertekenen. • Meerdere personen die samen een bericht ondertekenen (co-signing == in parallel). • Eén persoon ondertekend een bericht en de andere ondertekend de vorige handtekening (counter-signing == in serie).
28
Tot nu zijn we er vanuit gegaan dat het sleutelbeheer geen probleem vormt: • Als ik een versleuteld bericht naar jullie wens te versturen dan heb ik nood aan toegang tot jullie publieke sleutel voor geheimhouding die ik bovendien moet vertrouwen. • Als jullie een gehandtekend bericht van mij willen verifiëren dan hebben jullie nood aan toegang tot mijn publieke sleutel voor authenticiteit die jullie bovendien moeten vertrouwen. We weten ook reeds dat een wereldwijde X.500 Directory er nooit gekomen is en er nooit zal komen. Hoe kunnen we dan voor elke bestemmeling de publieke sleutel voor geheimhouding vinden? Zonder out-of-band contacten is dat onmogelijk. Bijgevolg is in de praktijk een implementatie van geheimhouding enkel mogelijk in een peer-to-peer en een gesloten omgeving (bv enterprise, tussen partners). Met de Belgische eID kan je enkel een handtekening plaatsen en dus niet versleutelen. Bovendien is er geen enkele binding tussen de Belgische eID en het mailadres van de afzender. Dit zijn dus twee totaal verschillende identiteiten.
29
Waarom is er een probleem met de digitale handtekening in de mail van de @cevi.be account naar de @skynet.be ? (+) De Cevi disclaimer is toegevoegd door de mail server en niet door de client. Bijgevolg is deze niet inbegrepen in de digitale handtekening en is dus de inhoud van het bericht gewijzigd.
30
31
32
TLS is de opvolger van SSL. Op een paar details na is TLS v1.0 == SSL v3. De meest recente versie is momenteel TLS v1.2 (Augustus 2008). (+) De wellicht meest bekende toepassing van het SSL/TLS protocol is “HTTP over SSL/TLS” of kortweg HTTPS genoemd. HTTPS heeft als voornaamste doelstelling om op een veilige manier allerlei webdiensten te kunnen aanbieden, en moet dus ondermeer verhinderen dat MITM (man-in-the-middle) aanvallen mogelijk zijn. (+) Dit hebben we hier visueel weergegeven door Mallet de actieve aanvaller tussen onze reeds bekende persona Alice en Bob te plaatsen. Hierbij speelt Alice de rol van client en Bob de rol van de web server. Mallet kan hierbij de web server Bob spelen tov van de client Alice, en ook de client Alice tov de web server Bob.
33
De “Secure Socket layer” nestelt zich tussen de applicatie en de transport laag in het TCP/IP model (Transport == TCP, Network == IP en Data Link == Ethernet). Het SSL/TLS protocol draait dus op een laag onder de applicatieprotocollen als HTTP, FTP, SMTP, POP3, IMAP4, etc.. en boven het transportprotocol TCP, dat deel uitmaakt van de protocolsuite TCP/IP. Hieruit volgt dat zowel SSL als TLS veiligheid kan bieden aan elk protocol dat gebruik maakt van TCP; de overeenkomstige protocollen noemen dan HTTPS, FTPS, SMTPS, POP3S, IMAP4S, etc... De S moet dus gelezen worden als “over SSL/TLS”. SSL/TLS zelf is samengesteld uit 2 interne lagen: • Onderste laag: Record Protocol wordt gebruikt om alle gegevens van de bovenste laag over te brengen (gegevens van applicatie laag en bovenste laag van SSL/TLS). Eenvoudig gezegd, het Record Protocol zorgt voor de verpakking, de briefomslag als je wil. • Bovenste laag: Bestaat uit 3 verschillende sub-protocollen: Handshake Protocol, Change Cipher Protocol en Alert Protocol. Zij zorgen voor het tot stand brengen en het beheer van de veilige verbindingen tussen de client en de server.
34
De 3 belangrijkste beveiligingseigenschappen van het SSL/TLS protocol zijn authenticatie, confidentialiteit en integriteit.
(+) Authenticatie: het proces waarbij iemand, een computer of applicatie nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. Voor de authenticatie van de server tov de client wordt door SSL/TLS steeds X.509v3 certificaten gebruikt. Alhoewel deze authenticatie volgens de protocol specificaties optioneel is, wordt deze op vandaag steeds uitgevoerd. De authenticatie van de client tov de server op SSL/TLS niveau, ook wel mutuele authenticatie genoemd, is optioneel en wordt, als je het wereldwijd bekijkt, zelden gebruikt omwille van heel wat praktische problemen. Ook hier worden dan X.509v3 certificaten gebruikt. (+) Confidentialiteit: de geheimhouding of vertrouwelijkheid wordt gerealiseerd door het Record Protocol en dat maakt gebruik van symmetrische cryptografie. De sleutel voor de symmetrische encryptie is uniek voor elke connectie en wordt afgeleid van een sleutel genegotiëerd door het Handshake Protocol. De protocol specificatie voorziet optioneel ook dat er geen encryptie gebeurt. Er wordt dan een zogenaamde ‘Null Cipher” onderhandeld. (+) Integriteit: in de context van SSL/TLS wil dit zeggen dat de berichten niet gewijzigd zijn van bron tot bestemming. Om dit te garanderen gebruikt het SSL/TLS protocol een HMAC (Hash-based Message Authenticity Code) algoritme. Een HMAC algoritme is niets anders dan een klassieke hash functie maar toegepast op de combinatie van een bericht *en* een symmetrische geheime sleutel. Anders uitgedrukt, iedereen die de symmetrische geheime sleutel kent of kan bemachtigen kan een geldige HMAC genereren en/of verifiëren. Bijgevolg kan je een HMAC nooit gebruiken voor authenticatie en/of handtekening. Daarentegen is een HMAC typisch kleiner en sneller te berekenen dan een digitale handtekening die gebruikt maakt van een asymmetrisch encryptie algoritme.
35
Het opzetten van een SSL/TLS beveiligde connectie kunnen we in een 5-tal stappen opdelen. ... Pas *na* deze 5 stappen kan er op applicatie niveau data uitgewisseld worden.
36
Opdat de client de server zou kunnen vertrouwen dient in het veld onderwerp van het server certificaat de “Common Name” (CN) gelijk te zijn aan de “Fully Qualified Domain Name” (FQDN) van de server zoals vermeld in de URL. Tevens herhalen we dat indien je geen administratieve controle hebt over de clients die je server wensen aan te spreken, het sterk aangewezen is om een server certificaat te gebruiken dat vertrouwd wordt door de OS/Browser ingebakken root certificaten (cfvr publiek certificaat). Tenslotte, om voor de client het opbouwen van de certificaat-boom te vereenvoudigen, is het aan te bevelen om ook alle tussenliggende certificaten op de server te installeren. Tijdens de “Server AuthN” fase zal de server dan de volledige certificaat-boom, behalve het root certificaat zelf, opsturen om de client te overtuigen van de geldigheid van zijn certificaat.
37
Zoals reeds aangehaald, de authenticatie op SSL/TLS niveau van de client tov de server, ook wel mutuele authenticatie genoemd, is optioneel. Omwille van heel wat praktische implementatie- en beheersproblemen wordt dit wereldwijd gezien zelden gebruikt, tenzij in een gesloten omgeving (bv enterprise, tussen partners). De server zal de client duidelijk maken dat authenticatie vereist is door een “Certificate Request” te sturen. Deze bevat een lijst van de door de server vertrouwde root certificaten voor client authenticatie. Voor zover ons bekend gebruikt IIS voor het opstellen van deze lijst de “Trusted Root Certification Authorities” uit de “Local Computer Certificate Store” . Wil je deze lijst zelf ‘controleren’ dan zal je bijgevolg de root certificaten in de “Trusted Root Certification Authorities” van de “Local Computer Certificate Store” moeten manipuleren. Dit kan evenwel voor problemen zorgen in de rol van client. Binnen IIS kan je wel via het concept van Certificate Trust List (CTL) bepalen van welke client root certificate authorities je finaal client certificaten wil aanvaarden *maar* deze moeten steeds een subset zijn van de “Trusted Root Certification Authorities” uit de “Local Computer Certificate Store”. De CTL bepaalt dus *niet* welke root CA’s aan de client voorgelegd worden.
38
Waarom ziet de browser een probleem bij het certificaat van de website “mijndossier.rrn.fgov.be”? Volgens de foutmelding kan hij blijkbaar geen geldige certificaat-boom opstellen. (+) Dit is de door de browser gevonden certificaat-boom. Bekijken we nu meer in detail het certificaat “Government CA” (+) dan zien we dat de uitgever hiervan de “Belgium Root CA2” is. Deze uitgever is evenwel standaard *niet* aanwezig in de lijst van de OS/Browser ingebakken root certificaten. (+) Bekijken we nu een ander certificaat uitgegeven door dezelfde PKI instantie, in dit scenario FedICT, dan zien we dat er wel een geldige certificaat-boom kan opgesteld worden.
Waarom dan dit verschil? Om dit te begrijpen moeten we wat dieper graven in de topology van de FedICT PKI. Dit doen we in het volgende hoofdstuk.
39
Het implementeren van de eID als middel voor sterke authenticatie is niet altijd evident. Naast de meer filosofische bezwaren zoals het gebruik van een persoonlijk bezit voor beroepsdoeleinden, zijn er ook operationele en puur technische obstakels (Wat te doen als eID vergeten, verloren of stuk is. Is men dan technisch werkloos?) . De eID wordt uitgegeven door de FedICT PKI instantie. Hierbij is het goed om weten dat openbare besturen ook van dezelfde FedICT PKI instantie gebruik kunnen maken om gratis publieke SSL Server certificaten te bekomen (zie http://www.fedict.belgium.be/nl/service_catalogue/infrastructuur/). Met de term publiek SSL Server certificaat bedoelen we dat dit certificaat gevalideerd kan worden door de standaard OS/Browser ingebakken root certificaten.
40
Bekijken we de mogelijke certificaat-bomen voor de eID (AuthN Cert) dan zien we dat er momenteel 2 root CA’s zijn die verantwoordelijk zijn voor *alle* eID’s. Elk van deze root CA’s certifiëert een aantal Citizen CA’s; iedere maand (YYYYMM) wordt een nieuwe Citizen CA opgezet. Elk van deze Citizen CA’s certifiëert op zijn beurt een aantal eID’s gebaseerd op het jaar & de maand van uitgifte. (+) Onderzoeken we nu de mogelijke certificaat-bomen voor de SSL Server certificaten (SSL Cert) dan zien we dat er 1 root CA van Globalsign verantwoordelijk is voor *alle* SSL Cert’s. Gezien dit Globalsign root certificaat standaard in alle OS/Browser ingebakken zit, zou dit steeds een publiek server certificaat moeten opleveren. Het Globalsign root certificaat valideert de Belgium Root CA 2, in dit geval echter als tussenliggende CA, die op zijn beurt een aantal Government CA’s certifiëert. Ieder jaar (YYYY) wordt een nieuwe Government CA opgezet. Elk van deze Government CA’s certifiëert een aantal SSL Cert’s gebaseerd op het jaar van uitgifte. (+) Niet alleen zitten we dus met een gespleten persoonlijkheid voor de “Belgium Root CA 2” maar bovendien wordt hiervoor hetzelfde sleutelpaar gebruikt. Dit heeft als gevolg dat tov de onderliggende certificaten deze als identiek beschouwd worden. Anders uitgedrukt, (+) er zijn potentiëel alternatieve paden beschikbaar voor het opstellen van de certificaat-boom; in het geval van de SSL Cert zelfs een korter pad. Wanneer we nu voor de client authenticatie op SSL/TLS niveau met de eID werken, (+) dienen we op de webserver beide Belgium Root CA cert’s als root CA’s te installeren. Hieruit volgt dat IIS het kortere pad zal kiezen in de “Server AuthN” fase met als resultaat dat alle clients die niet beschikken over de “Belgium Root CA 2” cert als root CA, geen geldige certificaat-boom kunnen opbouwen.
41
In het scenario met de eID als client authenticatie op SSL/TLS niveau zijn er nog meer beperkingen. In een simpele configuratie zijn de eindpunten in de vertrouwensrelatie de client Alice en de server Bob. Door de mutuele authenticatie zijn beide partijen zeker dat ze met de juiste partner communiceren. (+) Plaatsen we nu een klassieke firewall tussen de beide eindpunten Alice en Bob dan wijzigt er niets zolang de firewall enkel port forwarding doet. In dit geval komt hij niet tussen op SSL/TLS niveau maar enkel tot op transport niveau (cfr SUFBP). (+) Plaatsen we echter een reverse proxy firewall Carol tussen de beide eindpunten Alice en Bob dan verandert de situatie compleet. De end-to-end vertrouwensrelatie wordt opgebroken in twee losstaande vertrouwensrelaties: Alice -> Carol en Carol -> Bob. Hierdoor doen zich een aantal nieuwe problemen voor zoals: hoe moet Carol zich authenticeren tov van Bob, hoe kan Bob op een cryptografische betrouwbare manier vernemen dat Alice de eigenlijke bron is zodat de correcte authorisatie kan gebeuren, etc..? Een klassieke oplossing is hierbij gebruik maken van impersonatie, dwz Carol doet zich voor als Alice, (+) maar wat is dan nog het verschil met een MITM (man-in-themiddle) scenario? Anders uitgedrukt, we hebben nood aan een betere en veel flexibeler standaardoplossing.
42
Het moet inmiddels duidelijk zijn dat het gebruik van de eID als client cert op SSL/TLS niveau niet langer houdbaar is. De “Client AuthN” moet dus losgekoppeld worden van de “Secure Socket layer” en opschuiven naar de applicatie laag in het TCP/IP model. Aan de “Server AuthN” moet er niets veranderen. Gelukkig is er de laatste jaren industrie-wijd zeer zwaar geïnvesteerd in een nieuw authenticatie model, “claims based authentication” genoemd. Hierbij is de interoperabiliteit tussen de producten van verschillende fabrikanten een top prioriteit en de enige manier opdat dit nieuw model ook effectief zou slagen. In een viertal slides zullen we proberen de essentie van het nieuwe model uit te doeken te doen. Daar gaan we. (+) ... (+) ... (+) ... (+) ...
43
In de Microsoft wereld is de STS de Windows component “AD FS 2.0” (Active Directory Federation Service). De “Account Attribute Store” is uiteraard Active Directory maar kan ook een SQL database zijn of een combinatie van beiden. Note: “AD FS 2.0” is een server rol in Windows 2008 en hoger en vereist bijgevolg geen extra licentie. (+) Om een token te krijgen zal de gebruiker zich eerst moeten authenticeren. Dit kan op velerlei manieren (gebruikersnaam/wachtwoord, windows logon, smart card, etc..) . In een Intranet omgeving zal dit meestal Kerberos zijn (Windows Integrated AuthN). (+) Eens geauthenticeerd wordt de nodige informatie opgehaald uit de “Account Attribute Store” en (+) wordt een token aangemaakt en naar de aanvrager verstuurd. (+) Goed om weten is dat de ontwikkeling van een eID IdP (Identity Provider) bij FedICT bijna gefinaliseerd is. Deze heeft de volgende drie belangrijkste eigenschappen....
44
In een claims based model hebben we steeds minimum 3 partijen: de gebruiker (User), de applicatie (Relying Party) en de authoriteit verantwoordelijk voor de authenticatie en het uitgeven van de tokens (Identity Provider). (+) Microsoft heeft de applicatie ontwikkelaar het leven gemakkelijk gemaakt door een dotNET extensie te creëren die instaat voor al de complexe protocol & crypto verwerking van de tokens. Het resultaat is dat de applicatie de claims op een presenteerblaadje krijgt. Deze extensie heet WIF (Windows Identity Foundation) en wordt “dub i f” uitgesproken. De algemene werkwijze is als volgt: ... 5 * (+). Het is belangrijk om te onthouden dat voor elke (+) individuele applicatie een vertrouwensrelatie moet bestaan naar alle vertrouwde identity providers.
Het mooie van het claims based model is nu dat de 3 partijen volledig losstaan van elkaar en dus tot 3 totaal verschillende administratieve domeinen mogen behoren. Een heel concreet voorbeeld met (+) het Internet als transportmiddel: • De applicatie is cobra@home ontwikkeld in een Microsoft omgeving en is op het Internet gepubliceerd. • De gebruiker is een schepen die geen lid is van het Intranet van het bestuur en hij wenst Firefox als browser te gebruiken. • Het bestuur wenst de eID te gebruiken voor de AuthN. Hier ligt het gebruik van de FedICT eID Java Applet en Idp (identity Provider) voor de hand. De eID IdP is in Java geschreven en draait op een Linux variant bij FedICT. • Het resultaat is dat de applicatie cobra@home als één van de claims het RRNR zal krijgen waarna de gebruikelijke authorisatie stap kan aanvatten.
45
Een andere belangrijke toepassing van het claims based model is federatie. In een samenwerkingsverband tussen twee organisaties (bv een bestuur en de Cevi Extranet diensten) plaatsen we zowel een STS bij de identity provider (het bestuur) als de relying party (de Cevi Extranet diensten). Dit maakt dat de applicaties (diensten) enkel hun relying party STS moeten vertrouwen en dat alle externe vertrouwensrelaties centraal beheerd kunnen worden op de RP-STS. De “protocol dans” is dan als volgt: ... 7 * (+) Het netto effect is dat de gebruiker een SSO (Single Sign On) ervaring zal hebben, niet alleen binnen zijn Intranet omgeving maar ook voor al de diensten aangeboden door de relying party. Immers, de authenticatie kan via Kerberos verlopen (standaard Windows Logon). Bovendien is dit vanuit beveiligingsoogpunt ook positief; het vermijdt immers “zwevende accounts” bij de relying party. Let wel, de authenticatie is de verantwoordelijkheid van de organisatie die de accounts beheert, de authorisatie blijft de verantwoordelijkheid van de organisatie die de applicaties uitbaat. Uiteraard zullen claims vaak informatie bevatten nuttig voor de authorisatie. Note: de vertrouwensrelatie tussen beide STSen wordt gerealiseerd door middel van certificaten.
46
Stel dat in het vorig “federation scenario” de RP-STS een claim vereist dat de gebruiker sterk geauthenticeerd moet zijn. Welke opties hebben we dan? De goedkoopste en beste oplossing in een Intranet omgeving is het gebruik van een Smart Card. Dit is sedert Windows 2000 ingebakken in het OS. Vanaf Windows 7 (als het echt moet ook Vista SP1) is het gebruik van de eID als Smart Card voor Windows Logon een haalbare kaart geworden. De FedICT eID minidriver is hierbij een vereiste en wordt normaal reeds via Windows Update verspreid. Dit vereist wel minimaal een Windows 2008 domain controller. De magie bestaat erin een eID expliciet te koppelen aan een Active Directory gebruikersaccount.
47
Kerberos uitgelegd in één slide... KDC == Key Distribution Center is running 2 services: • AS == Authentication Service • TGS == Ticket Granting Service TGT == Ticket Granting Ticket ST == Service Ticket Aanloggen met de eID wijzigt enkel stap 1.
48
De uitdaging is om een eID te koppelen of bij hernieuwing van de eID te herkoppelen aan een Active Directory gebruikersaccount. Er moeten hiervoor nogal wat updates gebeuren in diverse “certificate stores” zoals... (+) We zijn dan ook van mening dat dit in de praktijk enkel vlot haalbaar is indien hiervoor een specifieke tool voorhanden is. Indien interesse, laat het ons weten. Bij voldoende vraag kunnen we lobbyen bij de ontwikkeling om zo’n specifieke tool te ontwerpen.
49
50
