Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Cursus informatiebeveiliging Eric Laermans – Tom Dhaene
Toegangscontrole Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Verschillende methodes
Toegangscontrole Verschillende methodes login + wachtwoord Kerberos X.509-certificaten Bedoeling authenticatie van entiteit die toegang aanvraagt tot systeem Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Meest gebruikte toegangscontrole
Wachtwoorden Meest gebruikte toegangscontrole toegang tot computer(systeem) toegang tot websites PIN-code voor betaalkaarten … zie ook boek H (online), p vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Wachtwoorden Voordelen eenvoud redelijke veiligheidsgraad
eenvoudigere implementatie dan ingewikkelde cryptografische protocols redelijke veiligheidsgraad met goed gekozen wachtwoorden met veilige implementatie opslag, communicatie,… met doordacht gebruik Een goed wachtwoord mag niet al te gemakkelijk geraden worden door een potentiële aanvaller. Een veilige implementatie impliceert onder andere dat een wachtwoord best niet in klare tekst opgeslagen of gecommuniceerd wordt (zeker niet over een slecht beveiligde draadloze verbinding). Een wachtwoord over een SSH- of SSL/TLS-verbinding versturen is echter wel aanvaardbaar. Een wachtwoord mag niet zo maar opgeschreven worden, al kan het beveiligd (bv. m.b.v. PGP) opslaan van wachtwoorden wel gerechtvaardigd worden. Bij het ingeven van wachtwoorden moet men er ook voor opletten dat niemand over uw schouder meekijkt (“shoulder surfing”). Gebruik ook geen wachtwoorden voor onbeveiligde toepassingen (ophalen bij uw ISP, aanmelden op niet-kritische websites,…) voor toepassingen waar de communicatie wel beveiligd (en betrouwbaar) is. Het systeem waarop men een wachtwoord gebruikt moet ook beveiligd zijn tegen andere bedreigingen zoals “keyloggers” (malware die de toetsaanslagen registreert), maar deze systeembeveiliging is ook een vereiste voor vele andere beveiligingstechnieken. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Wachtwoorden Nadelen ingewikkeld grote kwetsbaarheid
1 wachtwoord onthouden is redelijk eenvoudig, maar 10-tallen wachtwoorden is een helse opdracht af te raden voor alle toepassingen zelfde wachtwoord te gebruiken grote kwetsbaarheid met slecht gekozen wachtwoorden met onveilige implementatie opslag, communicatie,… met onzorgvuldig gebruik Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Wachtwoorden: Unix/Linux
Naast wachtwoord wordt ook “salt” gebruikt de “salt” is een vast aantal bits, waarvan de waarde bepaald is door het tijdstip waarop het wachtwoord aangemaakt werd Combinatie (“salt”, wachtwoord) geëncodeerd door eenrichtingsfunctie (“one way function”) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Worden opgeslagen in een wachtwoordbestand een identificatie van de gebruiker (User ID) de “salt” (niet geëncodeerd) de encodering van salt en wachtwoord Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Principiële werking salt wachtwoord 1-wegs- functie geëncodeerd wachtwoord Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Oorspronkelijke versie “salt” van 12 bits wachtwoord van 8 ASCII-karakters (56 bits) als eenrichtingsfunctie “crypt(3)” wordt gewijzigde versie van DES gebruikt, waarbij sleutel gegenereerd wordt uit “salt” en wachtwoord (als datablok worden 64 nulbits gebruikt) bekomen 64 bits worden omgezet tot 11 ASCII-karakters opslag hiervan in voor gewone gebruikers toegankelijk bestand “/etc/passwd” De bedoeling van deze “salt” is dat mogelijke identieke wachtwoorden niet op dezelfde manier opgeslagen worden in het systeem en dat wachtwoorden individueel moeten getest worden (zeker voor systemen met veel gebruikers is dit belangrijk). De wijziging aan het DES-algoritme maakt het gebruik van (snellere) hardware-implementaties van DES onmogelijk. Voor de eenrichtingsfunctie wordt geen zuivere DES gebruikt, maar zoals gezegd een gewijzigde versie. De DES-encryptie wordt 25 maal na elkaar toegepast. Dit verbetert fundamenteel erg weinig de beveiligingsgraad van DES, maar het zorgt er wel voor dat het algoritme een stuk trager werkt dan klassieke DES, wat het voor een kraker een stuk moeilijker maakt. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Zwakheden in oorspronkelijke versie beperkte lengte van het wachtwoord niet beter dan DES-versleuteling, zelfs bij goede keuze van een wachtwoord wachtwoordbestand gemakkelijk toegankelijk (ook voor gewone gebruikers) te gebruiken door kraakprogramma om zwakke wachtwoorden te vinden “salt” biedt geen verbetering voor individueel wachtwoord, want aanwezig in het bestand vereist wel dat elk wachtwoord afzonderlijk getest wordt geen verjaardagsaanval mogelijk op alle wachtwoorden tegelijk Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Wachtwoorden: Linux Verbeterde versie langere “salt”: tot 96 bits
langere wachtwoorden mogelijk oude eenrichtingsfunctie vervangen door hashfunctie (MD5) (herhaald toegepast) of andere eenrichtingsfunctie (Blowfish, SHA-256, SHA-512,…) wachtwoordbestand vervangen door schaduwbestand “/etc/shadow” alleen leesbaar voor “root”-gebruiker niet meer toegankelijk voor buitenstaanders De veel langere “salt” maakt het systeem ook geschikt voor een groot aantal gebruikers. Het grootste nadeel van een vrij toegankelijk wachtwoordbestand is dat bijna iedereen dit bestand kan gebruiken om wachtwoorden “off-line” te testen aan de hand van bestaande kraakprogramma’s (zoals “John The Ripper”, “Crack” of “Slurpie”). Dat het wachtwoordbestand niet meer leesbaar is heeft als voordeel dat de enige manier voor een aanvaller om wachtwoorden te testen zal zijn via een inlogpoging (via SSH of FTP), of door zich reeds op een andere manier toegang tot het systeem te verschaffen (bv. via een beveiligingslek). Dit is grootteordes minder handig dan het lokaal kunnen draaien van een kraakprogramma. Let wel dat de systeembeheerder nog altijd toegang heeft tot het wachtwoordbestand, zodat een interne aanval via een kraakprogramma nog altijd mogelijk is. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Overblijvende problemen
Wachtwoorden Overblijvende problemen zelfs met goed beveiligde opslag van wachtwoorden keuze van slechte wachtwoorden te kort login-naam woorden (ook in vreemde talen), namen, getallen persoonsgebonden informatie inversie van woorden, lichte variaties van woorden … gecompromitteerde wachtwoorden vergeten wachtwoorden Het is niet omdat een wachtwoord vandaag 15 karakters of meer kan tellen dat alle gebruikers deze maximale lengte ook benutten. Wachtwoorden van 2 of 3 karakters komen ook voor: de eeuwige tegenstelling tussen gebruiksgemak en beveiliging. Een wachtwoord kan gecompromitteerd worden als het in een niet of slecht beveiligde context gebruikt wordt. Daarom is het aangeraden verschillende wachtwoorden te gebruiken voor verschillende categorieën van toepassingen. Voor wachtwoorden waarmee men toegang als systeembeheerder tot een systeem bekomt, is het zelfs aangeraden telkens een verschillend wachtwoord te gebruiken. Voor meer onthutsende informatie over hoe slordig mensen met wachtwoorden omgaan: Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Keuze van goede wachtwoorden
voldoende lang meng kleine letters en hoofdletters meng letters en cijfers gebruik ook andere dan alfanumerieke karakters gebruik wachtwoorden die je kan onthouden via mnemotechnische middelen maar geef geen informatie prijs over deze technieken gebruik NOOIT een wachtwoord dat je ergens op een website gevonden hebt Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Bijkomende maatregelen
Wachtwoorden Bijkomende maatregelen leg politiek van sterke wachtwoorden op er bestaan programma’s om de sterkte van wachtwoorden te testen zijn niet onfeilbaar maar zijn wel stap in goede richting verplicht geregelde vervanging van wachtwoorden maar laat beveiligde opslag (bv. via PGP) eventueel toe Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Wachtwoorden Informatiebeveiliging
Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos Authenticatiedienst voor open gedistribueerde omgeving
gebruikers aan werkstations (PC’s) wensen toegang tot diensten op servers verdeeld over netwerk servers wensen toegangscontrole en authenticatie van aanvragen voor diensten werkstation is niet voldoende betrouwbaar om gebruikers te authentiseren voor diensten die via netwerk aangeboden worden zie ook boek H. 15.3, p. 476vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beveiliging vereist tegen
Kerberos Beveiliging vereist tegen vervalste identiteiten (“impersonation”) iemand geeft zich uit voor iemand anders door zich toegang te verschaffen tot werkstation van iemand anders iemand verandert netwerkadressen en communicatie gebeurt met ander werkstation dan oorspronkelijk voorzien terugspeelaanvallen (“replay”) afluisteren van inlogprocedure en achteraf terugspelen om zich frauduleus toegang tot het systeem te verschaffen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Gecentraliseerde authenticatieserver
Kerberos Gecentraliseerde authenticatieserver doelstelling: authentiseren van gebruikers t.a.v. servers authentiseren van servers t.a.v. gebruikers maakt uitsluitend gebruik van symmetrische encryptie ontwikkeld aan MIT Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos Vereisten veilig: mag niet het zwakke punt van de infrastructuur zijn; afluistering zou geen nuttige informatie moeten geven betrouwbaar: diensten worden immers onbereikbaar als Kerberos uitvalt; gedistribueerde architectuur kan nuttig zijn (opvang bij uitval van deel van systeem) transparant: voor gebruiker niet voelbaar buiten ingeven van wachtwoord schaalbaar: ook werkbaar voor groot aantal gebruikers en servers De Kerberos-server werkt als een “Trusted 3rd Party”. Voor de veiligheid van Kerberos is het ook nodig dat de Kerberos-server zelf zorgvuldig beveiligd is tegen ongeoorloofde toegang (zowel via elektronische als via fysische weg). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos Actoren gebruiker/client (C) server (V) Kerberos-systeem
authenticatieserver (AS) met gekoppelde databank voor verificatie van de toegangsrechten van de gebruiker “Ticket Granting Server” (TGS) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos: basiswerking
2. AS verifieert toegangsrechten gebruiker in DB, genereert TGT en sessiesleutel DB client AS eens per gebruikersessie eens per type dienst TGS eens per dienstsessie Kerberos 1. gebruiker meldt aan op werkstation en vraagt dienst aan 4. TGS verifieert TGT en genereert ticket voor aangevraagde server 3. stuurt TGT en authenticator naar TGS server 5. stuurt ticket en authenticator naar server AS: authenticatieserver DB: databank TGS: ticket-granting server TGT: ticket-granting ticket 6. server verifieert ticket, geeft toegang tot dienst en stuurt eventueel eigen authenticator Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Authenticatiedialoog
Kerberos versie 5 Authenticatiedialoog voor elke sessie van de gebruiker C → AS Opties || IDC || DomC || IDTGS || Tijd || N1 Opties: aanvraag voor opties in te ontvangen TGT IDC: identiteit van client DomC: Kerberos-domein van client IDTGS: identiteit van TGS Tijd: aanvraag voor tijdsinstellingen in te ontvangen TGT (start, geldigheid, nieuwe geldigheidsduur) N1: gelegenheidswoord (“nonce”) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos versie 5 Authenticatiedialoog AS → C
DomC || IDC || TGT || EKC[KC,TGS || Tijd || N1 || DomTGS || IDTGS] TGT = EKTGS[ Vlag || KC,TGS || DomC || IDC || ADC || Tijd ] ticket-granting ticket: bestemd voor TGS EKTGS[…]: versleuteld met KTGS (geheime sleutel voor TGS) Vlag: vlaggen voor functionele uitbreidingen op basis van aangevraagde Opties KC,TGS: sessiesleutel voor communicatie C↔TGS ADC: netwerkadres van client EKC[…]: versleuteld met KC (geheime sleutel voor client, afgeleid uit wachtwoord) DomTGS: Kerberos-domein van TGS Het TGT (ticket-granting ticket) kan alleen ontcijferd worden door de TGS (ticket-granting server), die de geheime sleutel KTGS deelt met de AS. De sessiesleutel KC,TGS is een sleutel voor eenmalig (zodat een vroeger gekraakte sleutel niet herbruikbaar is) gebruik voor de communicatie tussen de client en de TGS. Het toevoegen van het netwerkadres van de client aan het TGT zorgt ervoor dat de gebruiker gebonden wordt aan het netwerkadres van het werkstation dat hij gebruikt: het TGT is alleen geldig indien verstuurd vanuit het werkstation dat het TGT had aangevraagd. Merk op dat een onderschept TGT kan misbruikt worden tijdens de levensduur (bepaald door “Tijd”) van het ticket. Het zal echter slechts nuttig kunnen gebruikt worden als de aanvaller de TGS kan misleiden over zijn netwerkadres (ADC; wat haalbaar is) én de aanvaller over de sessiesleutel beschikt (zie ook verder). De client heeft de garantie dat dit bericht inderdaad van de AS komt dankzij het gelegenheidswoord (N1), dat alleen de AS (of hijzelf) kan versleutelen met KC. Kritische punten in dit protocol zijn de geheime sleutels KC en KTGS. Aangezien de sleutel KC afgeleid is uit het wachtwoord van de client is het essentieel dat de client hiervoor een sterk wachtwoord kiest. Aan de versleutelde tekst wordt het type gebruikte symmetrische encryptie toegevoegd, zodat men niet beperkt is tot DES (zoals in versie 4 het geval was). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

TGS-dialoog (voor elke type dienst)
Kerberos versie 5 TGS-dialoog (voor elke type dienst) C → TGS Opties || IDV || Tijd || N2 || TGT || AuthC IDV: identiteit van server N2: gelegenheidswoord (“nonce”) Tijd: aanvraag voor tijdsinstellingen in te ontvangen SGT (start, geldigheid, nieuwe geldigheidsduur) AuthC= EKC,TGS[ IDC || DomC || TS1 ] authenticator voor client EKC,TGS[…]: versleuteld met KC,TGS (sessiesleutel) TS1: tijdsstempel De authenticator heeft een zeer korte levensduur, veel korter dan die van het TGT. De TGS kan de authenticator ontcijferen door eerst het TGT te ontcijferen (waaruit hij dan de sessiesleutel KC,TGS kan halen waarmee de authenticator versleuteld is). Het TGT garandeert hem dat de gebruiker van de sessiesleutel alleen C kan zijn (dit ticket zorgt voor een beveiligde sleuteluitwisseling). De authenticator garandeert dat op tijdstip TS1 de gebruiker de sessiesleutel heeft gebruikt (wat de client C authentiseert). Wegens de korte levensduur van de authenticator kan een “replay”-aanval vermeden worden. Als een aanvaller een TGT tracht te misbruiken, maar niet beschikt over de sessiesleutel KC,TGS, zal het hem onmogelijk zijn een geschikte authenticator te genereren. Let wel, de aangevraagde tijdsinstellingen zullen verschillen van deze voor de TGT (typisch een kortere geldigheidsduur voor de SGT). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kerberos versie 5 TGS-dialoog TGS → C
DomC || IDC || SGT || EKC,TGS[KC,V || Tijd || N2 || DomV || IDV ] SGT = EKV[ Vlag || KC,V || DomC || IDC || ADC || Tijd ] service-granting ticket: bestemd voor server EKV[…]: versleuteld met KV (geheime sleutel voor server) KC,V: sessiesleutel voor communicatie C↔V DomV: Kerberos-domein voor server Het SGT (service-granting ticket) kan alleen ontcijferd worden door de server, die de geheime sleutel KV deelt met de TGS. Het toevoegen van het netwerkadres van de client aan het SGT zorgt er opnieuw voor dat de gebruiker gebonden wordt aan het netwerkadres van het werkstation dat hij gebruikt: het SGT is alleen geldig indien verstuurd vanuit het werkstation dat het SGT (en TGT) had aangevraagd. Merk op dat een onderschept SGT kan misbruikt worden tijdens de levensduur (bepaald door “Tijd”) van het ticket. Het zal echter slechts nuttig kunnen gebruikt worden als de aanvaller de server kan misleiden over zijn netwerkadres (ADC; wat haalbaar is) én de aanvaller over de sessiesleutel KC,V beschikt. De client heeft de garantie dat dit bericht inderdaad van de TGS komt dankzij het gelegenheidswoord (N2), dat alleen de TGS (of hijzelf) kan versleutelen met KC,TGS. Een nieuw kritische punt in dit protocol is de geheime sleutel KV. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Client/server-dialoog
Kerberos versie 5 Client/server-dialoog voor elke sessie van een dienst C → V Opties || SGT || AuthC AuthC= EKC,V[ IDC || DomC || TS2 || SKC,V || Seq# ] authenticator voor client EKC,V[…]: versleuteld met KC,V (sessiesleutel) TS2: tijdsstempel SKC,V: hulpsleutel specifiek voor deze applicatiesessie Seq#: sequentiegetal voor berichten binnen sessie Het beveiligingsmechanisme is vrij gelijkaardig aan dat voor de dialoog tussen client en TGS. Opnieuw heeft de authenticator een zeer korte levensduur, veel korter dan die van het SGT. De server kan de authenticator ontcijferen door eerst het SGT te ontcijferen (waaruit hij dan de sessiesleutel KC,V kan halen waarmee de authenticator versleuteld is). Het SGT garandeert hem dat de gebruiker van de sessiesleutel alleen C kan zijn (dit ticket zorgt voor een beveiligde sleuteluitwisseling). De authenticator garandeert dat op tijdstip TS2 de gebruiker de sessiesleutel heeft gebruikt (wat de client C authentiseert). Wegens de korte levensduur van de authenticator kan een “replay”-aanval vermeden worden. Als een aanvaller een SGT tracht te misbruiken, maar niet beschikt over de sessiesleutel KC,V, zal het hem onmogelijk zijn een geschikte authenticator te genereren. Er kan ook een hulpsleutel (“subkey”; SKC,V) gespecifieerd worden voor de specifieke applicatiesessie, anders wordt de gewone sessiesleutel KC,V gebruikt. Het (enveneens optionele) sequentiegetal kan gebruikt als initialisatie voor een telsequentie van de berichten in de sessie (om “replay”-aanvallen te vermijden). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Client/server-dialoog
Kerberos versie 5 Client/server-dialoog V → C indien mutuele authenticatie vereist is EKC,V[ TS2 || SKC,V || Seq# ] Hiermee authentiseert de server zich t.a.v. de client. Alleen de server (of de TGS) bezit immers de sleutel KV en kan dan ook het SGT ontcijferen. Deze ontcijfering is nodig om hieruit de sessiesleutel KC,V (die anders alleen door de client of de TGS gekend zijn) te halen, wat toelaat de verzonden authenticator te ontcijferen en er de nodige elementen uit te halen om ze (versleuteld) terug te sturen naar de client. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-authenticatie X.509 deel van X.500 ITU-T-aanbevelingenreeks voor “directory services” “directory” = verzameling servers die databank beheert met informatie over gebruikers raamwerk voor aanbieden van authenticatiediensten van directory t.a.v. gebruikers als opslag voor certificaten van publieke sleutels definieert authenticatieprotocols op basis van certificaten Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-authenticatie X.509 oorsprong: 1988
intussen versie 3 in 1995 (herzien in 2000) gebruikt in S/MIME, IPSec, TLS/SSL,… steunt op: asymmetrische cryptografie (RSA aanbevolen) digitale handtekening (met hashfunctie) zie ook boek, H. 14.4, p. 453vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-certificaat Version Certificate serial number Algorithm
Signature algorithm identifier Algorithm Parameters Issuer name v.1+ v.2+ v.3 Period of validity Not before Not after Subject name Subject’s public-key info Algorithm Parameters Key v.2+ v.3 Issuer unique identifier Subject unique identifier v.3 Het serienummer (“serial number”) is verschillend voor elk certificaat uitgegeven door eenzelfde CA. De identificatie van het signatuuralgoritme is eigenlijk een overbodig veld, aangezien het algoritme opnieuw beschreven is in het signatuurveld. De naam van de uitgever van het certificaat (“issuer name”) is de X.500-naam van de CA die het certificaat uitgegeven heeft. De geldigheidsduur (“period of validity”) geeft het tijdstip aan vanaf wanneer het certificaat geldig is en het tijdstip vanaf wanneer het als vervallen mag beschouwd worden. De “subject name” is de X.500-naam van de gebruiker van het certificaat. Het certificaat bindt zijn naam aan de publieke sleutel, die in het volgende veld beschreven wordt (identificatie van het gebruikte algoritme, parameters en de sleutel zelf). De extensies uit versie 2 (“Issuer unique identifier” en “subject unique identifier”) worden zelden gebruikt. Het principe van de extensies uit versie 3 worden even verder besproken. De digitale handtekening wordt aangebracht over (de hashwaarde van) alle andere velden van het certificaat m.b.v. de vertrouwelijke sleutel van de CA. Het veld voor de digitale handtekening bevat ook de nodige informatie over het gebruikte algoritme. De handtekening zelf is opgeslagen in het deelveld “Encrypted”. Extensions v.1+ v.2+ v.3 Signature Algorithm Parameters Encrypted Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-certificaat: voorbeeld
Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-certificaat Notaties Eigenschappen
CA<<A>>: certificaat van gebruiker A uitgegeven door CA CA{V,SN,AI,CA,TA,A,Ap,…}: digitale handtekening door CA van velden {V,SN,AI,CA,TA,A,Ap,…} Eigenschappen wie toegang heeft tot publieke sleutel van CA kan certificaat uitgegeven door CA verifiëren niemand behalve CA kan dit certificaat vervalsen kan dus publiek opgeslagen worden Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kettingen van X.509-certificaten
Vertrouwen van sleutels verschillende CA’s: probleem dat A certificaat van B niet kan vertrouwen A kent alleen CA1 nood aan certificaat van CA2 dat A wel zou kunnen vertrouwen CA1 CA2 CA1<<A>> A B CA2<<B>> Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Kettingen van X.509-certificaten
Vertrouwen van sleutels CA3 CA3<<CA1>> CA1 CA2 CA3<<CA2>> CA1<<CA3>> CA2<<CA3>> Bij gebruik van traditionele X.509v1-certificaten, waar geen beperkingen staan op het gebruik van certificaten is deze ketting maar zo sterk als haar zwakste schakel. Een kwaadaardige of onzorgvuldige CA in de keten zorgt voor een onbetrouwbare relatie. Dit is gedeeltelijk opgelost in versie 3. CA1<<A>> A B CA2<<B>> CA1<<CA3>> CA3<<CA2>> CA2<<B>> CA2<<CA3>> CA3<<CA1>> CA1<<A>> Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Herroepen van X.509-certificaten
Soms nodig vóór afloop geldigheidsduur als vertrouwelijke sleutel gebruiker gecompromitteerd certificatie door CA gecompromitteerd gebruiker niet langer door deze CA gecertifieerd “Certificate Revocation List” (CRL) bijgehouden en regelmatig bijgewerkt door elke CA lijst van herroepen certificaten lijst van serienummers getekend door CA via directory op te vragen, lokale cache mogelijk Praktisch blijkt het herroepen van certificaten vaak vrij problematisch, zeker als niet binnen een strikt kader wordt gewerkt. Als er geen toegang is tot de certificatie-autoriteiten, zoals vaak het geval is bij het gebruik van certificaten voor beveiligd internetverkeer, is deze methode van CRL’s ongeveer onwerkbaar. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Authenticatie met X.509-certificaten
3 mogelijke authenticatieprocedures in X.509 1-richtingsauthenticatie authentiseert volgende elementen: 1) identiteit van A + oorsprong van gegevens (A) 2) bericht bedoeld voor B 3) data-integriteit (wijziging en replay uit te sluiten) 1. A{tA, rA, IDB, sgnData, EKUB[KAB]} A B Hierin is tA een tijdsstempel, die het tijdstip van de aanmaak van het bericht en het vervaltijdstip van het bericht aangeeft. Verder is rA een gelegenheidswoord (“nonce”), dat uniek moet zijn binnen de periode van de geldigheidsduur van het bericht. Als B deze waarde opslaat tot het einde van de geldigheidsduur van het bericht, maakt dit een “replay”-aanval onmogelijk. De procedure laat ook toe verdere gegevens (“sgnData”) te versturen, waarbij authenticatie- en data-integriteitsfuncties gerealiseerd worden. De procedure maakt ook de beveiligde overdracht van een sessiesleutel (KAB) mogelijk. De identiteit van B wordt hier niet geauthentiseerd. Deze procedure vereist het gebruik van gesynchroniseerde klokken (wegens de tijdsstempels). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

3 mogelijke authenticatieprocedures in X.509 2-richtingsauthenticatie authentiseert volgende bijkomende elementen: 4) identiteit van B + oorsprong van antwoord (B) 5) bericht bedoeld voor A 6) data-integriteit antwoord (wijziging en replay uitgesloten) 1. A{tA, rA, IDB, sgnData, EKUB[KAB]} 2. B{tB, rB, IDA, rA, sgnData, EKUA[KBA]} A B Hierin is tB een nieuwe tijdsstempel, die het tijdstip van de aanmaak van het antwoord van B en het vervaltijdstip van dit antwoord aangeeft. Verder is rB een nieuw gelegenheidswoord (“nonce”), dat uniek moet zijn binnen de periode van de geldigheidsduur van het antwoord. Als A deze waarde opslaat tot het einde van de geldigheidsduur van het bericht, maakt dit een “replay”-aanval onmogelijk. Het includeren van het gelegenheidswoord van A (rA) valideert het antwoord (geeft aan dat het niet om een “replay” kan gaan, zonder de tijdsstempel tB te moeten controleren). Deze 2-richtingsauthenticatie laat toe dat beide communicerende partijen zich t.o.v. elkaar authentiseren. De procedure laat ook toe verdere gegevens (“sgnData”) te versturen, waarbij authenticatie- en data-integriteitsfuncties gerealiseerd worden. De procedure maakt ook de beveiligde overdracht van een sessiesleutel (KBA) mogelijk. Deze procedure vereist het gebruik van gesynchroniseerde klokken (wegens de tijdsstempels). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

3 mogelijke authenticatieprocedures in X.509 3-richtingsauthenticatie maakt tijdsstempels overbodig althans dit was toch de bedoeling 1. A{tA, rA, IDB, sgnData, EKUB[KAB]} 2. B{tB, rB, IDA, rA, sgnData, EKUA[KBA]} A B 3. A{rB} Doordat A het gelegenheidswoord van B (rB) getekend terugstuurt, garandeert hij dat zijn oorspronkelijk bericht geen “replay” was. Als het oorspronkelijke bericht immers een “replay” was door bv. C, dan zou C niet in staat zijn (met de handtekening van A) het gelegenheidswoord van B terug te sturen. Althans dit was de oorspronkelijke bedoeling. Stel dat de tijdsstempels niet gebruikt worden. C kan dan een oud bericht 1 (in een vroegere sessie uitgewisseld tussen A en B) naar B sturen en zich voordoen als A (gewone replay). Als antwoord ontvangt C dan een nieuw bericht 2 van B met een nieuwe “nonce” r’B. Als C ervoor kan zorgen dat A op dat ogenblik een sessie opstart met C, dan kan C de “nonce” r’B gebruiken voor zijn eigen antwoord aan A, dat A zal beantwoorden door r’B te tekenen. Als C dit antwoord naar B doorstuurt, vormt dit een geldig bericht 3, waarna B denkt met A te communiceren terwijl B in werkelijkheid met C communiceert. Een eenvoudige oplossing hierop zou zijn de identiteit van B opnieuw te includeren in bericht 3. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beperkingen X.509v1-certificaten
“subject”-veld niet altijd geschikt voor bepaling identiteit gebruiker (X.500-namen vaak vrij kort) “subject”-veld ongeschikt voor toepassingen die entiteiten erkennen o.b.v. adres, URL,… nood aan informatie over beveiligingsbeleid (“security policy”), bv. voor IPSec nood aan beperking schade door kwaadaardige of onzorgvuldige CA nood aan identificatie van verschillende sleutels voor zelfde gebruiker op verschillende tijdstippen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Extensies in X.509v3 Flexibele extensies
voor elke extensie: identificatie van extensie + indicatie of extensie kritisch is als een implementatie een kritische extensie niet herkent, moet certificaat als ongeldig beschouwd worden 3 categorieën informatie over sleutel en beveiligingsbeleid attributen van gebruiker (“subject”) en uitgever (“issuer”) beperkingen op het certificatiepad Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Extensies in X.509v3 Enkele voorbeelden
informatie over sleutel en beveiligingsbeleid geldigheidsduur voor vertrouwelijke sleutel, sleutelgebruik, identificatie van sleutel van CA/gebruiker,… attributen van gebruiker en uitgever alternatieve naam voor gebruiker (voor , IPSec,…),… beperkingen op het certificatiepad verhinderen dat gebruiker zelf als CA kan optreden, maximale lengte voor het certificatiepad, beperkingen op de naamruimte voor volgende certificaten … De geldigheidsduur voor een vertrouwelijke sleutel is typisch korter dan de geldigheidsduur voor de bijhorende publieke sleutel. De vertrouwelijke sleutel dient immers om een digitale handtekening te genereren, terwijl de publieke sleutel ook later nog moet kunnen gebruikt worden voor de verificatie van deze digitale handtekening. Het sleutelgebruik kan eventueel beperkt worden tot zekere toepassingen: digitale handtekening, sleutelencryptie, dataversleuteling,… Een extensie voor de identificatie van de sleutel van de CA (of van de gebruiker) laat toe dat deze verschillende sleutels bezit. Dit kan handig zijn voor het updaten van sleutelparen, of om afzonderlijke sleutels te kunnen gebruiken voor encryptie en voor digitale handtekeningen. Het beperken van de naamruimte waarin een gebruiker zelf nieuwe certificaten kan uitgeven betekent dat hij bv. alleen nog in staat is om certificaten te genereren voor onderdelen van zijn eigen bedrijf, maar geen certificaat kan uitbrengen voor een ander bedrijf. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

X.509-certificaat: voorbeeld extensies
Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Verwante presentaties

Presentatie over: "Cursus informatiebeveiliging Eric Laermans – Tom Dhaene"— Transcript van de presentatie:

Verwante presentaties

Over het project

Feedback

Inloggen

Inloggen via een sociaal netwerk:

Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Verwante presentaties

Presentatie over: "Cursus informatiebeveiliging Eric Laermans – Tom Dhaene"— Transcript van de presentatie:

Verwante presentaties

Over het project

Feedback