Key management.pdf

# Sleutelverdeling bij symmetrische encryptie Sleutelverdeling bij symmetrische encryptie behandelt de uitdagingen en technieken voor het veilig distribueren van symmetrische cryptografische sleutels tussen partijen, inclusief de noodzaak van sleutelcentra en hiërarchische structuren. ### 1.1 De uitdaging van sleutelbeheer bij symmetrische encryptie Bij symmetrische encryptie moeten beide communicerende partijen dezelfde geheime sleutel bezitten. Deze sleutel moet te allen tijde beschermd zijn tegen inzage door onbevoegden. Voor een verhoogde veiligheid is het vaak wenselijk om sleutels frequent te wisselen om de hoeveelheid data die gecompromitteerd kan worden bij een sleutelverlies te beperken. De effectiviteit van cryptografische systemen hangt sterk af van de gebruikte sleutelverdelingstechniek, wat verwijst naar de methode om een sleutel te bezorgen aan twee partijen die data willen uitwisselen zonder dat anderen de sleutel kunnen onderscheppen [2](#page=2). #### 1.1.1 Benodigde sleutelhoeveelheid Het aantal benodigde sleutels neemt exponentieel toe met het aantal deelnemers in een netwerk. Om twee willekeurige knooppunten (uit een set van $N$ knooppunten) met elkaar te laten communiceren, is een sleutel per paar vereist, wat resulteert in een totaal van $\frac{N(N-1)}{2}$ sleutels [2](#page=2). > **Tip:** Dit getal illustreert de schaal van de sleutelverdelingstaak voor end-to-end encryptie. Een netwerk met 1000 knooppunten zou bijna een half miljoen sleutels nodig hebben, en bij 10.000 applicaties kunnen dit er wel 50 miljoen zijn. #### 1.1.2 Grafische weergave van sleutelbehoeften *Figure 14.1* op pagina 2 toont de significante groei van het aantal benodigde symmetrische sleutels in relatie tot het aantal eindpunten dat 1-op-1 communicatie ondersteunt. ### 1.2 De rol van een sleutelverdelingscentrum (KDC) Om de complexiteit van sleutelbeheer te verminderen, wordt vaak een sleutelverdelingscentrum (KDC) ingezet. De KDC is verantwoordelijk voor het distribueren van sleutels aan paren van gebruikers (hosts, processen, applicaties) op aanvraag [3](#page=3). #### 1.2.1 Hiërarchie van sleutels Het gebruik van een KDC is gebaseerd op een sleutelhiërarchie. Minimaal worden twee sleutelniveaus gebruikt [3](#page=3): * **Sessiesleutel:** Deze tijdelijke sleutel wordt gebruikt voor de duur van een logische verbinding en versleutelt de communicatie tussen eindsystemen. Sessiesleutels worden verkregen van de KDC en via dezelfde netwerkfaciliteiten getransporteerd als de eindgebruikerscommunicatie. Daarom worden sessiesleutels versleuteld verzonden met behulp van een mastersleutel [3](#page=3). * **Mastersleutel:** Elke eindgebruiker deelt een unieke mastersleutel met de KDC. Deze mastersleutels moeten op een veilige manier worden gedistribueerd, maar de schaal van dit probleem is aanzienlijk kleiner. Als er $N$ entiteiten zijn die onderling willen communiceren, zijn slechts $N$ mastersleutels nodig (één per entiteit). Deze kunnen bijvoorbeeld via fysieke levering worden verspreid [3](#page=3). #### 1.2.2 Implementatievoorbeelden Het sleuteldistributieconcept kan op diverse manieren worden toegepast, zoals via varianten van het Needham/Schroeder protocol. Het Kerberos-systeem is een bekend voorbeeld van een KDC die functies opsplitst in authenticatie en ticketuitgifte [3](#page=3). > **Example:** *Figure 14.3* op pagina 3 toont een scenario voor sleutelverdeling met een KDC, waarbij de communicatie stappen omvat zoals het uitwisselen van identificatiegegevens en het versleuteld verzenden van sessiesleutels. ### 1.3 Gedeconcentreerde en hiërarchische KDC-structuren Voor zeer grote netwerken kan het onpraktisch zijn om één enkele KDC te gebruiken. In dergelijke gevallen kan een hiërarchie van KDC's worden opgezet [4](#page=4). #### 1.3.1 Lokale en globale KDC's Een mogelijke hiërarchische structuur omvat lokale KDC's die verantwoordelijk zijn voor een kleiner domein binnen het netwerk, zoals een Local Area Network (LAN) of een specifiek gebouw. Voor communicatie binnen hetzelfde lokale domein beheert de lokale KDC de sleutelverdeling [4](#page=4). #### 1.3.2 Communicatie tussen domeinen Wanneer twee entiteiten uit verschillende domeinen een gedeelde sleutel nodig hebben, kunnen de bijbehorende lokale KDC's communiceren via een globale KDC. In deze opzet kan een van de drie betrokken KDC's de sleutel selecteren. Deze hiërarchische structuur kan worden uitgebreid naar drie of meer lagen, afhankelijk van de grootte van de gebruikerspopulatie en het geografische bereik van het internetwerk [4](#page=4). > **Tip:** Een hiërarchisch schema minimaliseert de inspanning voor mastersleuteldistributie, aangezien de meeste mastersleutels worden gedeeld tussen een lokale KDC en zijn lokale entiteiten [4](#page=4). #### 1.3.3 Vereiste van vertrouwen Het gebruik van een KDC brengt de eis met zich mee dat de KDC betrouwbaar moet zijn en beschermd moet worden tegen ondermijning. Dit vereiste kan worden vermeden als de sleutelverdeling volledig gedecentraliseerd is [4](#page=4). --- # Technieken voor openbare sleuteldistributie Dit onderwerp verkent diverse methoden voor het verspreiden van publieke sleutels, waarbij de nadruk ligt op het belang van betrouwbaarheid en veiligheid bij deze distributie. ### 2.1 Algemene uitgangspunten voor openbare sleuteldistributie De kern van publieke sleutelcryptografie ligt in het feit dat de publieke sleutel daadwerkelijk publiek is. Dit betekent dat elke deelnemer zijn of haar publieke sleutel naar andere deelnemers kan sturen of deze breed kan verspreiden binnen een gemeenschap [5](#page=5). ### 2.2 Methode 1: Publieke aankondiging Bij deze methode kan elke deelnemer zijn publieke sleutel naar elke andere deelnemer sturen of deze publiekelijk aankondigen [5](#page=5). * **Voordeel:** Gemakkelijk in gebruik [5](#page=5). * **Nadeel:** Kwetsbaar voor vervalsing. Een aanvaller kan zich voordoen als een legitieme gebruiker en een valse publieke sleutel verspreiden. Totdat de echte gebruiker de vervalsing ontdekt en anderen waarschuwt, kan de aanvaller versleutelde berichten onderscheppen en valse authenticaties uitvoeren [5](#page=5). > **Tip:** Publieke aankondiging biedt een fundamenteel gebrek aan beveiliging tegen kwaadwillende actoren. ### 2.3 Methode 2: Publiek toegankelijke directory Een grotere mate van beveiliging kan worden bereikt door een publiek toegankelijke, dynamische directory van publieke sleutels te onderhouden [5](#page=5). * **Werking:** * De directory bevat een lijst met {naam, publieke sleutel} koppelingen voor elke deelnemer [6](#page=6). * Elke deelnemer registreert zijn publieke sleutel bij de directory-autoriteit, bij voorkeur persoonlijk of via beveiligde, geauthenticeerde communicatie [6](#page=6). * Deelnemers kunnen hun bestaande sleutel op elk moment vervangen, bijvoorbeeld als de sleutel voor veel data is gebruikt of als de corresponderende privésleutel gecompromitteerd is [6](#page=6). * Toegang tot de directory kan elektronisch plaatsvinden, waarbij beveiligde, geauthenticeerde communicatie van de autoriteit naar de deelnemer verplicht is [6](#page=6). * **Beveiliging:** Deze methode is veiliger dan individuele publieke aankondigingen [6](#page=6). * **Nadelen:** * Als een aanvaller de privésleutel van de directory-autoriteit bemachtigt of berekent, kan deze autoriteit vervalste publieke sleutels uitgeven en elke deelnemer impersoneren [6](#page=6). * Het aanpassen van de gegevens in de directory door een aanvaller is ook een mogelijkheid [6](#page=6). > **Tip:** Hoewel beter dan publieke aankondigingen, blijft een publieke directory kwetsbaar voor aanvallen op de integriteit van de autoriteit zelf. ### 2.4 Methode 3: Publieke sleutelautoriteit Sterkere beveiliging wordt verkregen door striktere controle uit te oefenen op de distributie van publieke sleutels vanuit de directory, wat leidt tot het concept van een publieke sleutelautoriteit [6](#page=6). * **Werking:** * Een centrale autoriteit beheert een dynamische directory van publieke sleutels van alle deelnemers [6](#page=6). * Elke deelnemer kent betrouwbaar een publieke sleutel van de autoriteit, en alleen de autoriteit kent de bijbehorende privésleutel, aangeduid als $PR_{auth}$ [6](#page=6). * Het uitwisselen van publieke sleutels kan via een uitwisseling van zeven berichten verlopen, waarbij de eerste vijf berichten slechts infrequent nodig zijn door het cachen van publieke sleutels van correspondenten. Periodiek moeten gebruikers nieuwe kopieën van publieke sleutels van correspondenten opvragen om de actualiteit te waarborgen [6](#page=6). * **Voordelen:** Biedt sterkere beveiliging dan de voorgaande methoden [6](#page=6). * **Nadelen:** * De autoriteit kan een knelpunt worden, aangezien gebruikers de autoriteit moeten benaderen voor de publieke sleutel van elke andere gebruiker waarmee ze willen communiceren [6](#page=6). * De directory van namen en publieke sleutels die door de autoriteit wordt beheerd, blijft kwetsbaar voor manipulatie [6](#page=6). > **Tip:** De efficiëntie van het systeem kan afnemen door de centrale rol van de autoriteit. ### 2.5 Methode 4: Publieke sleutelcertificaten Een alternatieve benadering maakt gebruik van certificaten, waardoor deelnemers sleutels kunnen uitwisselen zonder direct contact met een publieke sleutelautoriteit, op een betrouwbare manier [7](#page=7). * **Structuur van een certificaat:** Een certificaat bestaat uit: * Een publieke sleutel [7](#page=7). * Een identificatie van de eigenaar van de publieke sleutel [7](#page=7). * Het geheel is ondertekend door een vertrouwde derde partij (de certificeringsautoriteit of CA) [7](#page=7). * **Werking:** * Een gebruiker kan zijn publieke sleutel op een veilige manier presenteren aan de autoriteit en een certificaat verkrijgen [7](#page=7). * De gebruiker kan dit certificaat vervolgens publiceren [7](#page=7). * Iedereen die de publieke sleutel van deze gebruiker nodig heeft, kan het certificaat verkrijgen en de geldigheid ervan verifiëren via de aangehechte vertrouwde handtekening [7](#page=7). * Een deelnemer kan zijn sleutelinformatie ook overdragen aan een ander door zijn certificaat te versturen [7](#page=7). * **Garanties geboden door certificaten:** * Elke deelnemer kan een certificaat lezen om de naam en publieke sleutel van de eigenaar te achterhalen [7](#page=7). * Elke deelnemer kan verifiëren dat het certificaat afkomstig is van de certificeringsautoriteit en niet vervalst is [7](#page=7). * Alleen de certificeringsautoriteit kan certificaten aanmaken en bijwerken [7](#page=7). * Elke deelnemer kan de actualiteit van het certificaat controleren [7](#page=7). * **Certificeringsaanvraag:** Elke deelnemer vraagt een certificaat aan bij de certificeringsautoriteit, waarbij een publieke sleutel wordt verstrekt. Deze aanvraag moet persoonlijk of via een beveiligde, geauthenticeerde communicatie plaatsvinden [7](#page=7). #### 2.5.1 X.509 standaard X.509 is onderdeel van de X.500-serie van aanbevelingen die een directoryservice definiëren. Het definieert een kader voor authenticatiediensten via de X.500-directory, gebaseerd op publieke sleutelcryptografie en digitale handtekeningen, zonder een specifieke digitale handtekening- of hash-algoritme voor te schrijven [8](#page=8). * **Inhoud van een X.509 certificaat:** Elk certificaat bevat de publieke sleutel van een gebruiker en is ondertekend met de privésleutel van een vertrouwde certificeringsautoriteit. X.509 definieert alternatieve authenticatieprotocollen gebaseerd op het gebruik van publieke sleutelcertificaten [8](#page=8). * **Certificate Signing Request (CSR):** Een CSR bevat de identiteit van de aanvrager, het bewijs van identiteit, de publieke sleutel en het bewijs dat de aanvrager in bezit is van de bijpassende privésleutel [8](#page=8). * **Certificaat als ondertekend document:** Een certificaat is een ondertekend document dat stelt dat een bepaalde publieke sleutel toebehoort aan een bepaalde organisatie; dit document is ondertekend door de certificeringsautoriteit die de identiteit van de aanvrager heeft geverifieerd [8](#page=8). * **Hiërarchie van certificeringsautoriteiten:** Er is een hiërarchie tussen certificeringsautoriteiten, die eindigt met zogenaamde root-certificaten, bekend bij alle browsers [8](#page=8). > **Tip:** De betrouwbaarheid van een certificaat hangt volledig af van de betrouwbaarheid van de ondertekenende certificeringsautoriteit. #### 2.5.2 Verificatieproces van een certificaat Het proces omvat het genereren van een hashcode van het onondertekende certificaat, het versleutelen van deze hashcode met de privésleutel van de CA om de digitale handtekening te vormen, en het creëren van het ondertekende digitale certificaat. De ontvanger kan de handtekening verifiëren door de ontvangen hashcode (na decryptie met de publieke sleutel van de CA) te vergelijken met de hashcode van het ontvangen certificaat [8](#page=8). > **Voorbeeld:** > 1. Bob stuurt zijn publieke sleutel naar de CA [7](#page=7). > 2. De CA creëert een certificaat met Bobs ID en publieke sleutel, en ondertekent dit met zijn privésleutel [8](#page=8). > 3. Bob stuurt dit certificaat naar Alice [7](#page=7). > 4. Alice gebruikt de publieke sleutel van de CA om de handtekening te verifiëren en zo Bobs publieke sleutel te vertrouwen [8](#page=8). #### 2.5.3 Commerciële aspecten van certificaten Vanaf begin 2000s geloofden veel organisaties dat certificaten een enorme markt zouden worden, waarbij elke individuele gebruiker minstens één certificaat nodig zou hebben. Dit heeft geleid tot een groot aantal vertrouwde root-certificaten [9](#page=9). ### 2.6 Illustraties * Figuur 14.10 toont ongecontroleerde publieke sleuteldistributie [5](#page=5). * Figuur 14.11 illustreert publieke sleutelpublicatie [5](#page=5). * Figuur 14.12 toont een scenario voor publieke sleuteldistributie met een autoriteit [5](#page=5). * Figuur 14.13 beschrijft de uitwisseling van publieke sleutelcertificaten, zowel het verkrijgen van certificaten van de CA als het uitwisselen van certificaten tussen partijen [5](#page=5). * Figuur 14.14 geeft een visuele weergave van het gebruik van een publieke sleutelcertificaat [8](#page=8). --- # Key Distribution Center (KDC) Een Key Distribution Center (KDC) is een essentieel component in cryptografische systemen die verantwoordelijk is voor het veilig distribueren van encryptiesleutels tussen entiteiten. ### 3.1 Rol en werking van een KDC De primaire rol van een KDC is het faciliteren van veilige communicatie door het beheren en distribueren van cryptografische sleutels. Dit gebeurt door middel van een hiërarchische sleutelstructuur. Elk communicerend paar van gebruikers (zoals hosts, processen of applicaties) verkrijgt van de KDC tijdelijke encryptiesleutels, vaak aangeduid als sessiesleutels. Deze sessiesleutels worden doorgaans gebruikt gedurende de duur van een logische verbinding [3](#page=3). #### 3.1.1 Sleutelhiërarchie De KDC maakt gebruik van minimaal twee niveaus van sleutels: * **Sessiesleutels:** Dit zijn tijdelijke sleutels die worden gebruikt voor de encryptie van communicatie tussen eindsystemen gedurende een specifieke sessie [3](#page=3). * **Master sleutels:** Dit zijn langdurige sleutels die elke eindgebruiker of elk systeem deelt met de KDC. Sessiesleutels worden versleuteld verzonden met behulp van deze master sleutel [3](#page=3). #### 3.1.2 Master sleutel distributie Voor elke eindentiteit (gebruiker of systeem) is er een unieke master sleutel die deze deelt met de KDC. De distributie van deze master sleutels kan op verschillende manieren plaatsvinden, waaronder fysieke levering, aangezien het aantal benodigde master sleutels gelijk is aan het aantal entiteiten (N). Dit reduceert de complexiteit van sleutelbeheer aanzienlijk [3](#page=3). #### 3.1.3 Authenticatie en Tickets (Kerberos) Het Kerberos-systeem is een voorbeeld van een KDC-implementatie die de functies van authenticatie en tickets scheidt. Het proces van sleuteldistributie kan worden weergegeven in een scenario met een initiator A en een responder B [3](#page=3). **Key Distribution Scenario:** * **Stap:** Initiator A stuurt identificatie-informatie en een niet-herhaalbaar getal (nonce) N1 naar de KDC [1](#page=1). ``` IDA || IDB || N1 [1](#page=1). ``` * **Stap:** De KDC genereert een sessiesleutel Ks, versleutelt deze met de master sleutel van A (Ka) en de master sleutel van B (Kb), en stuurt deze terug naar A [2](#page=2) [3](#page=3). ``` E(Ka, [Ks || IDA || IDB || N1])|| E(Kb, [Ks || IDA]) [2](#page=2). ``` * **Stap:** B ontvangt de sessiesleutel via A en bevestigt de ontvangst [3](#page=3). ``` E(Kb, [Ks || IDA]) [3](#page=3). ``` * **Stap &:** Vervolgstappen waarbij de sessiesleutel wordt gebruikt voor verdere communicatie en verificatie [3](#page=3) [4](#page=4) . ``` E(Ks, N2) [4](#page=4). E(Ks, f(N2)) . ``` > **Tip:** Het concept van een KDC vereist dat het centrum te allen tijde betrouwbaar is en beschermd tegen subversie [4](#page=4). ### 3.2 Hiërarchische KDC's Voor grotere netwerken kan het praktisch zijn om de KDC-functie te verdelen over meerdere instanties, wat leidt tot een hiërarchie van KDC's. Lokale KDC's kunnen verantwoordelijk zijn voor specifieke domeinen, zoals een Local Area Network (LAN) of een gebouw. Wanneer entiteiten uit verschillende domeinen willen communiceren, kunnen de respectievelijke lokale KDC's communiceren via een globale KDC. Dit kan de inspanning voor master sleuteldistributie minimaliseren, aangezien de meeste master sleutels die van een lokale KDC met zijn lokale entiteiten zijn. Deze hiërarchische structuur kan worden uitgebreid naar drie of meer lagen, afhankelijk van de netwerkgrootte en geografische reikwijdte [4](#page=4). > **Voorbeeld:** In een groot bedrijf met meerdere vestigingen kan elke vestiging een eigen lokale KDC hebben. Communicatie binnen een vestiging wordt afgehandeld door de lokale KDC. Voor communicatie tussen vestigingen werken de lokale KDC's samen, mogelijk met een centrale KDC voor de toplaag van de hiërarchie. --- # Openbare-sleutelcertificaten en X.509 Openbare-sleutelcertificaten bieden een betrouwbare methode voor sleuteluitwisseling door de rol van X.509 als standaard voor directoryservices en authenticatie te benutten [7](#page=7) [8](#page=8). ### 4.1 Werking van openbare-sleutelcertificaten Een alternatieve benadering voor sleuteluitwisseling omvat het gebruik van certificaten, waarmee deelnemers sleutels kunnen uitwisselen zonder directe communicatie met een publieke-sleutelautoriteit, maar met de betrouwbaarheid van directe verkrijging [7](#page=7). Een certificaat bestaat uit de volgende componenten: * De publieke sleutel van de eigenaar [7](#page=7). * Een identificatie van de eigenaar van de publieke sleutel [7](#page=7). * Een digitale handtekening van een vertrouwde derde partij, doorgaans een certificaatautoriteit (CA) [7](#page=7) [8](#page=8). #### 4.1.1 Verkrijgen en gebruiken van een certificaat Een gebruiker kan zijn of haar publieke sleutel op een veilige manier presenteren aan een certificaatautoriteit en een certificaat verkrijgen. Dit certificaat kan vervolgens door de gebruiker worden gepubliceerd [7](#page=7). Wanneer een andere deelnemer de publieke sleutel van deze gebruiker nodig heeft, kan deze het certificaat verkrijgen en de geldigheid ervan verifiëren aan de hand van de bijgevoegde vertrouwde handtekening. Een deelnemer kan ook sleutelinformatie overdragen aan een ander door diens certificaat te versturen. Andere deelnemers kunnen verifiëren dat het certificaat door de autoriteit is aangemaakt [7](#page=7). #### 4.1.2 Verificatie van een certificaat Elke deelnemer kan een certificaat lezen om de naam en de publieke sleutel van de eigenaar te achterhalen. Bovendien kan elke deelnemer verifiëren dat het certificaat afkomstig is van de certificaatautoriteit en niet nagemaakt is. Alleen de certificaatautoriteit is bevoegd om certificaten te creëren en bij te werken. Iedere deelnemer kan ook de geldigheid van het certificaat controleren [7](#page=7). #### 4.1.3 Aanvraagproces voor certificaten Elke deelnemer dient een aanvraag in bij de certificaatautoriteit, waarbij de publieke sleutel wordt overlegd en een certificaat wordt aangevraagd. Deze aanvraag dient persoonlijk of via een vorm van veilige, geauthenticeerde communicatie te geschieden [7](#page=7). > **Tip:** Het proces omvat het aanleveren van de publieke sleutel en het bewijs van bezit van de bijbehorende privésleutel aan de certificaatautoriteit [8](#page=8). ### 4.2 X.509 standaard X.509 is onderdeel van de X.500-serie aanbevelingen die een directoryservice definiëren. De directory is in feite een server, of een gedistribueerd netwerk van servers, dat een database met gebruikersinformatie beheert. X.509 definieert een raamwerk voor de levering van authenticatiediensten door de X.500-directory aan zijn gebruikers. Het is gebaseerd op het gebruik van publieke-sleutelcryptografie en digitale handtekeningen. De standaard dicteert geen specifiek algoritme voor digitale handtekeningen of een specifieke hash-functie [8](#page=8). #### 4.2.1 Certificaatinhoud en structuur Elk certificaat bevat de publieke sleutel van een gebruiker en is ondertekend met de privésleutel van een vertrouwde certificaatautoriteit. X.509 specificeert alternatieve authenticatieprotocollen die gebaseerd zijn op het gebruik van publieke-sleutelcertificaten [8](#page=8). Een CSR (certificate signing request) bevat de identiteit van de aanvrager, het bewijs van die identiteit, de publieke sleutel, en het bewijs dat de aanvrager de bij de publieke sleutel horende privésleutel bezit [8](#page=8). Een certificaat is een ondertekend document waarin wordt verklaard dat een bepaalde publieke sleutel toebehoort aan een bepaalde organisatie. Dit document is ondertekend door de certificaatautoriteit die de identiteit van de aanvrager heeft geverifieerd [8](#page=8). > **Tip:** Er bestaat een hiërarchie tussen certificaatautoriteiten, die eindigt in zogenaamde rootcertificaten, welke bekend zijn bij alle browsers. Dit is gerelateerd aan het idee uit de vroege jaren 2000 dat certificaten een enorme markt zouden worden, waarbij men geloofde dat elk individu minstens één certificaat nodig zou hebben [8](#page=8) [9](#page=9). #### 4.2.2 Het ondertekeningsproces van een certificaat Het proces van het creëren van een digitaal ondertekend certificaat omvat de volgende stappen [8](#page=8): 1. **Genereren van een hashcode:** Er wordt een hashcode gegenereerd van de onondertekende certificaatdata, die de gebruikers-ID en de publieke sleutel bevat [8](#page=8). 2. **Encryptie van de hashcode:** De gegenereerde hashcode wordt versleuteld met de privésleutel van de certificaatautoriteit (CA) om de digitale handtekening te vormen [8](#page=8). 3. **Creëren van een digitaal ondertekend certificaat:** Het eindresultaat is een digitaal ondertekend certificaat dat de informatie van de CA, de ID van de gebruiker en diens publieke sleutel bevat [8](#page=8). #### 4.2.3 Verificatie door de ontvanger De ontvanger kan de handtekening verifiëren door de volgende stappen uit te voeren [8](#page=8): 1. **Ontsleutelen van de handtekening:** De digitale handtekening wordt ontsleuteld met de publieke sleutel van de CA om de oorspronkelijke hashcode te herstellen [8](#page=8). 2. **Vergelijken van hashcodes:** De ontvanger genereert zelf een hashcode van de ontvangen certificaatdata en vergelijkt deze met de herstelde hashcode. Een overeenkomst bevestigt de authenticiteit en integriteit van het certificaat [8](#page=8). 3. **Verifiëren van de publieke sleutel:** De ontvanger kan het certificaat gebruiken om de publieke sleutel van de eigenaar te verifiëren [8](#page=8). > **Example:** Als Bob zijn publieke sleutel en identiteitsinformatie naar de CA stuurt, genereert de CA een hash van deze gegevens, versleutelt deze met de CA's privésleutel om de handtekening te creëren, en stuurt het ondertekende certificaat terug naar Bob. Iedereen die Bobs publieke sleutel nodig heeft, kan het certificaat verifiëren met de publieke sleutel van de CA [8](#page=8). ### 4.3 Belangrijke aspecten van X.509 certificaten * **Publieke sleutel:** Het certificaat bevat de publieke sleutel van de eigenaar [8](#page=8) [9](#page=9). * **Identificatie:** Er is identificatie-informatie over de eigenaar [9](#page=9). * **Vertrouwde handtekening:** De handtekening van de certificaatautoriteit zorgt voor vertrouwen [7](#page=7) [8](#page=8). * **Rootcertificaten:** De hiërarchie eindigt in rootcertificaten die door alle browsers worden erkend [8](#page=8). * **Ondersteunde algoritmen:** X.509 specificeert niet één enkel digitaal handtekeningalgoritme of hash-functie [8](#page=8). > **Example:** Het aantal vertrouwde rootcertificaten is aanzienlijk, wat historisch gezien voortkomt uit de verwachting dat certificaten een enorme markt zouden worden en individuen ze op grote schaal zouden gebruiken [9](#page=9). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Symmetrische encryptie | Een cryptografisch systeem waarbij dezelfde sleutel wordt gebruikt voor zowel encryptie als decryptie. Beide communicerende partijen moeten deze geheime sleutel delen en deze beschermen tegen onbevoegde toegang. | | Sleutelverdelingstechniek | Het proces en de middelen om een cryptografische sleutel veilig te leveren aan twee partijen die gegevens willen uitwisselen, zonder dat anderen de sleutel kunnen onderscheppen of inzien. | | Key Distribution Center (KDC) | Een centrale server of entiteit die verantwoordelijk is voor het distribueren van cryptografische sleutels aan gebruikers of systemen die veilige communicatie met elkaar wensen. | | Sessiesleutel | Een tijdelijke, unieke sleutel die wordt gebruikt om communicatie tussen twee partijen te versleutelen gedurende de duur van een enkele verbinding of sessie. | | Master key | Een hoofdsleutel die wordt gedeeld tussen een Key Distribution Center en een eindgebruiker of systeem. Deze wordt gebruikt om sessiesleutels veilig te transporteren. | | Hiërarchie van sleutels | Een gelaagde benadering van sleutelbeheer waarbij verschillende niveaus van sleutels worden gebruikt, zoals master keys en sessiesleutels, om de complexiteit van sleuteldistributie te verminderen. | | Kerberos | Een netwerkauthenticatiesysteem dat gebruikmaakt van tickets om veilige communicatie tussen gebruikers en servers te faciliteren, vaak in combinatie met een Key Distribution Center. | | Openbare sleutel | Een deel van een cryptografisch sleutelpaar dat vrij kan worden gedeeld met anderen. Het wordt gebruikt om gegevens te versleutelen die vervolgens alleen kunnen worden ontsleuteld met de bijbehorende privésleutel. | | Publieke aankondiging | Een eenvoudige, maar onveilige methode voor sleutelverdeling waarbij een gebruiker zijn publieke sleutel openbaar maakt aan andere deelnemers of aan de gemeenschap. | | Publiek beschikbare directory | Een gecentraliseerde, openbaar toegankelijke lijst of database waarin de publieke sleutels van deelnemers worden opgeslagen en beheerd door een vertrouwde entiteit. | | Publieke-sleutelautoriteit | Een vertrouwde derde partij die een directory van publieke sleutels onderhoudt en distribueert, waarbij zij een sleutel kunnen uitgeven aan een deelnemer na verificatie van hun identiteit. | | Publieke-sleutelcertificaat | Een digitaal document dat een publieke sleutel koppelt aan een identiteit (bv. een persoon of organisatie), ondertekend door een vertrouwde certificaatautoriteit om de authenticiteit te garanderen. | | Certificaatautoriteit (CA) | Een vertrouwde entiteit die verantwoordelijk is voor het uitgeven, beheren en intrekken van digitale certificaten, waarmee de geldigheid van publieke sleutels wordt bevestigd. | | X.509 | Een internationale standaard die een framework definieert voor de uitwisseling van certificaten, voornamelijk gebruikt in combinatie met X.500 directorydiensten, en gebaseerd op publieke-sleutelcryptografie voor authenticatie. | | CSR (Certificate Signing Request) | Een verzoek dat door een entiteit wordt ingediend bij een certificaatautoriteit om een digitaal certificaat te verkrijgen. Het bevat de identiteit van de aanvrager, de publieke sleutel en bewijs van het bijbehorende privésleutelbezit. | | Digitale handtekening | Een cryptografische techniek die wordt gebruikt om de authenticiteit en integriteit van digitale documenten of berichten te verifiëren. Het wordt gecreëerd met de privésleutel van de afzender en geverifieerd met diens publieke sleutel. | | Hash functie | Een wiskundige functie die een invoer van willekeurige grootte omzet in een uitvoer van vaste grootte (de hashwaarde). Deze functies worden gebruikt om de integriteit van gegevens te controleren en als onderdeel van digitale handtekeningen. |