Cursus informatiebeveiliging Eric Laermans – Tom Dhaene Basistoepassingen Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

Tot nu toe: basisalgoritmen Stand van zaken Tot nu toe: basisalgoritmen symmetrische encryptie asymmetrische encryptie hashfuncties berichtauthenticatiecodes sleuteluitwisseling m.b.v. DH digitale handtekening tussen basisalgoritme en toepassing Nu toepassen van basisalgoritmen voor beveiliging Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Tijdsstempel (“Time Stamp”) tijdwaarde wordt aan bericht gelinkt m.b.v. digitale handtekening of MAC geen geknoei achteraf mogelijk beveiliging tegen replay aanvaard alleen berichten met voldoende verse tijdsstempel kan als dienst aangeboden worden door trusted third party basisschema Alice leesbaar bericht + tijd Als de tijdsstempel in een communicatie wordt gebruikt (bv. om de versheid van een bericht te garanderen) kan hiermee replay vermeden worden, op voorwaarde dat er enige synchronisatie tussen de klokken van de communicerende partijen bestaat. dig. sign. Alice Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Probleem met basisschema Tijdsstempel Probleem met basisschema als vertrouwelijke sleutel van Alice gecompromitteerd is aanvaller die over deze sleutel beschikt kan eigen bericht tekenen in naam van Alice aanvaller kan vervalst tijdstip aanbrengen (ook in het verleden) ongeschikt voor digitale documenten onweerlegbaarheid vervalt op ogenblik dat tekenende partij haar vertrouwelijke sleutel laat compromitteren ook geldigheid van vroegere documenten komt dan immers in het gedrang Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Probleem met basisschema Tijdsstempel Probleem met basisschema als vertrouwelijke sleutel van Alice gecompromitteerd is wel voldoende geschikt voor controle van versheid van communicatie herroepen van gecompromitteerde sleutel volstaat als mechanisme Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Mogelijke (verbeterde) implementatie Tijdsstempel Mogelijke (verbeterde) implementatie (vertrouwde) Server voor tijdsstempel Alice tijd tijd leesbaar bericht leesbaar bericht dig. sign. Alice dig. sign. Alice Alice tekent bericht (m.b.v. eigen vertrouwelijke sleutel) Alice stuurt getekend bericht naar (vertrouwde) server voor tijdsstempel Server voor tijdsstempel voegt tijdstip toe aan getekend bericht Server linkt tijdstip aan getekend bericht door (getekend bericht + tijdstip) te tekenen (m.b.v. vertrouwelijke sleutel van server) Server stuurt geheel terug naar Alice Tijdstip van bericht wordt gegarandeerd door server. Server voor tijdsstempel heeft hier een rol van TTP (Trusted Third Party). Het belang van de tijdsstempel is inderdaad voor Alice en Bob (de ontvanger van het bericht). Voor Bob zorgt dit voor de onweerlegbaarheid van het bericht dat hij van Alice ontvangen heeft. Voor Alice is het een zekerheid dat als haar sleutel gestolen wordt, die niet met “terugwerkende kracht” kan misbruikt worden. dig. sign. tijdserver dig. sign. tijdserver Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Te gebruiken als authenticatiemechanisme Challenge/response Te gebruiken als authenticatiemechanisme alternatief voor tijdsstempel tegen replay basiswerking Alice stuurt gelegenheidswoord (“nonce”) naar Bob: challenge Bobs (geauthentiseerd) antwoord bevat gelegenheidswoord van Alice: response 1) N1 Alice Bob De authenticatie van Bobs antwoord kan gebeuren m.b.v. een vertrouwelijke sleutel (KRB) en een asymmetrisch versleutelingsmechanisme of een digitale handtekening, of m.b.v. een geheime sleutel (KAB), die hij met Alice deelt en een symmetrisch versleutelingsmechanisme of een MAC. Na deze uitwisseling heeft Alice de garantie dat ze met Bob communiceert, aangezien alleen Bob een dergelijk geauthentiseerd antwoord kan genereren (op voorwaarde natuurlijk dat de vertrouwelijke of geheime sleutel van Bob niet gecompromitteerd is en dat het gebruikte beveiligingsmechanisme niet kwetsbaar is; een tegenvoorbeeld van deze laatste voorwaarde is WEP-authenticatie voor draadloze communicatie). Een aanvaller kan in dit geval geen replay van een vroeger bericht gebruiken, aangezien het in dit geval niet zal overeenkomen met de (vers) uitgestuurde challenge. Met dit basisschema is de entiteit Alice echter nog niet geauthentiseerd t.a.v. Bob. 2) EKRB [N1] of EKAB [N1] Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Uitwisseling (geheime) sleutels (“key exchange”) Sleuteluitwisseling Uitwisseling (geheime) sleutels (“key exchange”) m.b.v. DH cf. hiervoor m.b.v. symmetrische encryptie sleutelverdelingscentrum (“key distribution centre”; KDC) te vertrouwen door beide gebruikers die willen communiceren (TTP) m.b.v. asymmetrische encryptie geen TTP nodig (?) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

M.b.v. symmetrische encryptie Sleuteluitwisseling M.b.v. symmetrische encryptie elke gebruiker bezit geheime sleutel waarmee hij kan communiceren met sleutelverdelingscentrum (KDC) sleutelverdelingscentrum bezit sleutel van elke gebruiker die met hem willen communiceren Alice KDC Bob X KA-KDC KB-KDC KX-KDC KB-KDC KA-KDC KX-KDC Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling: KDC 1) IDA || IDB || N1 Alice KDC 2) EKA-KDC[KS || IDB || N1 || EKB-KDC(KS || IDA)] 3) EKB-KDC(KS || IDA) 4) EKS[N2] 5) EKS[f(N2)] Needham-Schroeder-protocol cf. boek H. 14, p. 439vv. cf. boek H. 15, p. 473vv. N1: “nonce”, d.w.z. gelegenheidswoord, dat slechts eenmalig gebruikt wordt. IDA, IDB: identiteiten van Alice, resp. Bob Alice vraagt KDC om communicatie met Bob en stuurt “nonce” N1 KDC antwoordt met versleuteld (met sleutel van Alice, KA-KDC, wat KDC t.a.v. Alice authentiseert en vertrouwelijkheid garandeert) bericht bestaande uit sessiesleutel, identiteit van Bob, “nonce” N1 (wat replay uitsluit), versleuteld (met sleutel van Bob, KB-KDC) bericht (sessiesleutel en identiteit van Alice); alleen Alice kan dit bericht en dus de sessiesleutel ontcijferen Alice stuurt sessiesleutel en eigen identiteit, versleuteld met sleutel van Bob (zoals ontvangen van KDC), waarna ook Bob (en niemand anders) sessiesleutel kan ontcijferen Bob antwoordt met tweede “nonce” N2, versleuteld met sessiesleutel, waarmee hij zichzelf authentiseert t.a.v. Alice (door kennis van KS) Alice antwoordt met verwerkte (bv. 1 optellen bij N2) “nonce” N2, versleuteld met sessiesleutel, waarmee ze zichzelf t.a.v. Bob authentiseert (via challenge-response-mechanisme) Bob Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling: KDC Needham-Schroeder-protocol beveiliging hangt af van: geheime sleutel KA-KDC geheime sleutel KB-KDC geheime sessiesleutel KS ook na afloop sessie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling: KDC Needham-Schroeder-protocol aanval met gecompromitteerde KS tegen Bob Carol voert replay uit van stap 3 met gecompromitteerde KS (vereist slechts afluisteren voordien) Carol kan challenge van Bob beantwoorden dankzij gecompromitteerde sleutel KS Bob denkt dat hij met Alice communiceert, maar communiceert eigenlijk met Carol OPM. 1: waarschijnlijkheid dat dergelijke aanval slaagt, is beperkt OPM. 2: er bestaan verbeteringen voor dit protocol Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling: KDC (verbeterd) 3) IDA || IDB || N1 || EKB-KDC(IDA || N2) Alice KDC 4) EKA-KDC[KS || IDB || N1 || EKB-KDC(KS || N2 || IDA)] 1) IDA 2) EKB-KDC(IDA || N2) 5) EKB-KDC(KS || N2 || IDA) 6) EKS[N2] 7) EKS[f(N2)] verbetering van het Needham-Schroeder protocol N1, N2: “nonce”, d.w.z. gelegenheidswoord, dat slechts eenmalig gebruikt wordt. IDA, IDB: identiteiten van Alice, resp. Bob Alice informeert Bob over communicatie Bob antwoordt met versleutelde “nonce” (alleen leesbaar voor Bob en KDC) Alice vraagt KDC om communicatie met Bob en stuurt “nonce” N1 samen met versleutelde nonce N2 KDC antwoordt met versleuteld (met sleutel van Alice, KA-KDC, wat KDC t.a.v. Alice authentiseert en vertrouwelijkheid garandeert) bericht bestaande uit sessiesleutel, identiteit van Bob, “nonce” N1 (wat replay uitsluit), versleuteld (met sleutel van Bob, KB-KDC) bericht (sessiesleutel, “nonce” N2 en identiteit van Alice); alleen Alice kan dit bericht en dus de sessiesleutel ontcijferen Alice stuurt sessiesleutel N2 en eigen identiteit, versleuteld met sleutel van Bob (zoals ontvangen van KDC), waarna ook Bob (en niemand anders) sessiesleutel kan ontcijferen (“nonce” N2 garandeert versheid van sleutel KS) Bob antwoordt met tweede “nonce” N2, versleuteld met sessiesleutel, waarmee hij zichzelf authentiseert t.a.v. Alice (door kennis van KS) Alice antwoordt met verwerkte (bv. 1 optellen bij N2) “nonce” N2, versleuteld met sessiesleutel, waarmee ze zichzelf t.a.v. Bob authentiseert (via challenge-response-mechanisme) Bob correcte beveiliging blijkt soms erg subtiel… Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling met asymmetrische encryptie Eerste poging indien Bob publieke sleutel van Alice niet kan herkennen risico voor “man-in-the-middle”-aanval (cf. DH) geen authenticatie van communicerende partijen alleen bescherming tegen (passieve) afluistering 1) KUA, IDA Alice Bob 2) EKUA [KS] cf. boek H. 14.2, p. 446vv. IDA is de identiteit van Alice Alice stuurt publieke sleutel en identiteit aan Bob Bob genereert sessiesleutel en verstuurt die naar Alice, versleuteld met publieke sleutel van Alice, zodat alleen Alice deze sessiesleutel kan ontcijferen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Sleuteluitwisseling met asymmetrische encryptie Verbeterde versie verondersteld: Alice en Bob hebben publieke sleutels reeds uitgewisseld 1) EKUB [N1, IDA] 2) EKUA [N1, N2, IDB] Alice Bob 3) EKUB [N2] N1 (evenals N2) is een “nonce”, d.w.z. een gelegenheidswoord, dat slechts eenmalig gebruikt wordt. IDA is de identiteit van Alice Alice stuurt eerste “nonce” en identiteit aan Bob, versleuteld met publieke sleutel van Bob (alleen te ontcijferen door Bob dus) Bob stuurt eerste “nonce” terug, samen met tweede “nonce” en eigen identiteit, samen versleuteld met publieke sleutel van Alice (en dus alleen leesbaar voor Alice nu; alleen Bob kan dit bericht versturen, niemand anders had deze “nonce” kunnen gebruiken: geen replay-aanval mogelijk) Nu weet Alice dat ze met Bob communiceert. 3)Alice stuurt tweede “nonce” terug aan Bob, versleuteld met publieke sleutel van Bob (alleen Alice kan dit, want niemand anders kan deze “nonce” gebruiken) Nu weet Bob dat hij met Alice communiceert 4)Alice genereert sessiesleutel die ze versleutelt met eigen vertrouwelijke sleutel en met publieke sleutel van Bob (alleen Bob kan sessiesleutel achterhalen, en alleen Alice kan dit bericht gegenereerd hebben) 4) EKUB[EKRA(KS)] licht verschillend versie van p. 447 uit handboek (vermijdt speciale replay-aanval) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels Beheer publieke sleutels (“public key management”) probleem: hoe weet men tot wie publieke sleutel behoort? opbouwen van vertrouwensrelatie (“trust relationship”) oplossing eenvoudige methode PKI (“Public Key Infrastructure”) cf. boek H. 14.3, p. 448vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels Eenvoudig systeem uitwisselen van publieke sleutels via parallel kanaal bv. via niet-elektronische weg publieke sleutels van anderen digitaal tekenen aanvaarden van publieke sleutels, die digitaal getekend zijn door mensen die men voldoende vertrouwt OK voor kennissenkring minder geschikt voor grote organisaties Dit is grosso modo het basisprincipe achter het systeem dat in PGP (Pretty Good Privacy) gebruikt wordt. Zie ook verder. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels PKI (“Public Key Infrastructure”) centrale directory met publieke sleutels elke deelnemer registreert publieke sleutel bij beheerder van directory mogelijke publicatie van lijst publieke sleutels voordeel: eenvoud (zeker binnen 1 organisatie) nadelen: 1 centraal punt onhandig voor communicatie tussen bedrijven Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels PKI m.b.v. certificatie-autoriteit (“certification authority”, CA) garandeert identiteit gebruiker van publieke sleutel entiteit registreert publieke sleutel bij CA, waarbij entiteit haar identiteit bewijst CA levert certificaat af die identiteit van entiteit bindt aan publieke sleutel met certificaat kan entiteit bewijzen dat publieke sleutel van haar is met garantie van CA voor meer over certificaten, zie ook verder (X.509) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels: certificaten 1) KUA, IDA CA Alice 2) CertA = EKRCA [T1, IDA, KUA] CA KUA IDA: identiteit van Alice Alice registreert publieke sleutel bij CA en bewijst haar identiteit CA creëert een certificaat dat publieke sleutel van Alice bindt aan haar identiteit, samen met zekere tijdwaarde (geldigheid van certificaat), via digitale handtekening. Certificaat is verifieerbaar aan de hand van publieke sleutel van CA (KUCA). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels: certificaten KUA 1) CertA Alice Bob 2) CertB CA KUB Alice stuurt certificaat, dat ze verkregen heeft van CA naar Bob, zodat Bob (m.b.v. publieke sleutel van CA) kan verifiëren dat de publieke sleutel die Alice gebruikt werkelijk tot Alice behoort Bob stuurt zijn certificaat terug naar Alice ter verificatie Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels PKI m.b.v. certificatie-autoriteit (“certification authority”, CA) blijft probleem van publieke sleutel van CA 1 grootteorde kleiner, want er zijn veel minder CA’s dan gebruikers oplossing: laat publieke sleutel van CA tekenen door belangrijkere CA opbouwen van hiërarchie van CA’s zie ook verder over X.509 Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

Beheer publieke sleutels: CA-hiërarchie  Publieke sleutels van Alice en Bob worden getekend door CA1 Publieke sleutel van CA1 wordt getekend door CA2 Publieke sleutel van CA2 wordt getekend door CA3 Tot aantal CA’s voldoende beperkt is, zodat beperkte lijst met te vertrouwen publieke sleutels bestaat (bv. VeriSign, Belgische overheid,) 4)CA2 kan ook publieke sleutels van andere CA’s (zoals CA5) tekenen, die op hun beurt de sleutels van andere gebruikers/CA’s kunnen tekenen 5)Ook CA3 op een hoger niveau in de hiërarchie kan op zijn beurt de publieke sleutels van andere CA’s tekenen (zoals CA4), enz. Alice Bob  Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans