Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Warning banner met uitleg toegevoegd - links naar terminologie toegevoegd

...

...

...

...

...

...

...

...

Note

Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:

  • Nieuw toegevoegde tekst wordt overal in het rood weergegeven

Bijlage 1: digitale enveloppe  

In de praktijk wordt meestal de combinatie van symmetrische en asymmetrische encryptie gebruikt om informatie te beveiligen. Zo’n veel voorkomende toepassing waarbij de voordelen van beide systemen worden gecombineerd om berichten te vercijferen met behulp van een symmetrisch systeem en een eenmalige sleutel, de sessiesleutel, is de digitale enveloppe. Met deze techniek kan een bericht vercijferd verstuurd worden zonder dat hierbij de verzender en ontvanger van het bericht vooraf over eenzelfde geheime sleutel moeten beschikken. Asymmetrische encryptie wordt toegepast om de sessiesleutel te vercijferen. De techniek wordt geïllustreerd in onderstaande figuur. De verzender van een bericht doet het volgende:

...

De bestemmeling (ontvanger) van het bericht kan de sessiesleutel decrypteren d.m.v. zijn/haar private sleutel om vervolgens het vercijferde bericht opnieuw leesbaar te maken door dit te decrypteren met deze sessiesleutel. 

Bijlage 2: de componenten van een PKI  

...

Een PKI (Public Key Infrastructure) bestaat uit een aantal basiscomponenten:

  • Entiteiten (dit kunnen personen of organisaties zijn ) die onderling veilige transacties willen uitvoeren(dit kunnen personen of organisaties zijn – op de tekening voorgesteld als “Gebruiker” en “Serviceprovider of Relatie”) die onderling veilige transacties willen uitvoeren (op de tekening voorgesteld als “Clientproces”). De relatie tussen entiteiten kan van allerlei typen zijn (leverancier – afnemer, werkgever – werknemer, burger – overheid, enz.). Om dit te kunnen doen moeten de partijen vertrouwen op de registratieautoriteit (Registration Authority of RA) en de certificaatautoriteit (Certificate Authority of CA). Deze twee organisaties horen bij een PKI. De garantie op goed sleutelbeheer, betrouwbare authenticatie en vertrouwelijkheid hangt rechtstreeks af van de kwaliteit van deze componenten;

  • Registration Authority (RA) is de component waar entiteiten aanvragen kunnen indienen voor het verkrijgen van een certificaat (certificate request). Voor een hoog kwaliteitsniveaucertificaat is de kwaliteit van de verificatie van de identiteit van de entiteit belangrijk; 

  • Certificate Authority (CA) geeft certificaten uit op basis van de door de CA zelf goedgekeurde certificaataanvragen (certificate requests). Deze aanvragen worden ontvangen door één of meerdere RA-servers. De CA beheert de uitgegeven certificaten, publiceert ze en bewaart de certificaten in de Certificate repository (op de tekening voorgesteld als “Repository”), een databank van certificaten. Daarnaast publiceert de CA een lijst van ingetrokken certificaten: de Certificate Revocation List (CRL, deze is niet op de tekening te zien maar wordt geraadpleegd via OCSP, zie verder). Via het OCSP-protocol (Online Certificate Status Protocol) kan online worden bevraagd of een certificaat geldig is;

  • Sleutelpaar: een paar asymmetrische sleutels, waartussen een bepaalde relatie bestaat. Een sleutel is de private sleutel van de entiteit. Deze moet geheimgehouden worden. De andere sleutel is de publieke sleutel van de entiteit, deze moet juist openbaar beschikbaar zijn; 

  • Certificaat: een digitaal object, het bevat de identiteit van entiteit, ook de certificaathouder genoemd, de publieke sleutel en een verwijzing naar de verantwoordelijke CA;

  • Certificaat status server: een server van de CA, die via het internet bereikbaar is. Deze stelt informatie beschikbaar over de inhoud van de CRL en over de verstrekte certificaten. Een eindgebruiker kan daarmee bijvoorbeeld via zijn browser op internet controleren of zijn relaties beschikken over geldige certificaten en wat de publieke sleutels daarvan zijn. Een voorbeeld is de OCSP-server. 

Bijlage 3: vier stappen voor het verkrijgen van PKI-certificaten  

Per stap worden steeds twee mogelijkheden uitgelegd: bij variant (A) genereert de aanvrager van het certificaat het sleutelpaar zelf, bij variant (B) doet de certificaatautoriteit (Certificate Authority of CA) dat.
1. Stap 1: het creëren van het sleutelpaar:

...

4. Stap 4: De CA zorgt voor de publicatie van een up-to-date Certificate Revocation List (CRL), waarop alle ingetrokken certificaten staan vermeld. De CRL wordt gepubliceerd op de ‘OCSP-server’ (Online Certificate Status Protocol server), die computers antwoord geeft over de
geldigheidsstatus van een certificaat:

  • (A) de aanvrager heeft zelf het sleutelpaar gegeneerd. De CA stuurt een bevestiging van certificaat naar de aanvrager. De aanvrager is verantwoordelijk voor de beveiligingsmaatregelen rond het gebruik van de private sleutel; of

  • (B) de aanvrager ontvangt van de CA de private sleutel op een beveiligde wijze. De aanvrager is verantwoordelijk voor een beveiligde opslag van deze sleutel en voor de beveiligingsmaatregelen rond het gebruik van de private sleutel

Bijlage 4: distributie mechanismen voor crypto-sleutels  

Afhankelijk van de toepassing zijn er verschillende methoden om sleutels veilig te distribueren:

  • Distributie van de Key Encryption Keys Key (KEK): de KEK moet voorafgaand aan de ingebruikname van de encryptie over een vertrouwd pad gedistribueerd worden. De KEK wordt meestal op een fysiek medium opgeslagen, zoals een smartcard, dat bijvoorbeeld met een speciale koerier verstuurd kan worden of bij een loket afgehaald moet worden op basis van een bewijsstuk en legitimatie. Bij specifieke apparatuur wordt de asymmetrische sleutel al bij de fabriek geïnstalleerd;

  • Distributie van periodieke sleutels: voor beveiliging van de distributie van periodieke sleutels kan men zowel kiezen voor asymmetrische encryptie (de KEK is een publieke sleutel afkomstig van een PKI) als voor symmetrische encryptie (de KEK is geheim). Een voorbeeld van een systeem met een geheime KEK is de (Advanced Encryption Standard) AES Key Wrap-methode, zie onderstaand figuur.

...

  • Distributie van periodieke sleutels met een publieke KEK verloopt bijvoorbeeld op een vergelijkbare manier als hierna beschreven wordt voor distributie van een sessiesleutel; of

  • Distributie van een sessiesleutel: onderstaande figuur laat zien hoe een publieke KEK (afkomstig van een PKI) wordt gebruikt bij het uitwisselen van een sessiesleutel voor het beveiligen van webverkeer (https) tussen client en server op het internet

Image RemovedImage Added

De berichtuitwisseling verloopt als volgt:

...

Omdat de KEK van alle sleutels de langste levensduur heeft, is dat ook de meest gevoelige sleutel. De KEK zelf wordt niet versleuteld en dient dus op een andere wijze fysiek en/of logisch te worden afgeschermd. Toegang tot de KEK is alleen toe te staan na identificatie en authenticatie van de beheerder dan wel de gebruiker van de KEK. Er bestaan ook oplossingen waarbij een KEK ontbreekt. Een bekend voorbeeld is wifi-encryptie in de pre-shared key (PSK) modus. Daarbij worden de (periodieke) wifisleutels ter plaatse door een beheerder ingevoerd. De beheerder moet ervoor zorgen dat de sleutels niet bekend worden.

Bijlage 5: MAC  

De volgende figuur illustreert het gebruik van een MAC (Message Authentication Code of) om berichtauthenticatie te realiseren bij het verzenden van berichten: 

...

Message Authentication Codes worden in diverse protocollen toegepast. Bijvoorbeeld in (Secure Sockets Layer/ Transport Layer Security) SSL/ TLS om het kanaal tussen twee communicerende partijen (server/server of client/server) te beveiligen: bericht-integriteit (werd de informatie niet gewijzigd in transit?) en authenticatie (is de informatie wel afkomstig van de juiste server?). Dit toon het belang aan om websites niet louter omwille van vertrouwelijkheidsdoeleinden via (HyperText Transfer Protocol Secure) HTTPS (dus SSL/ TLS over http) te ontsluiten. 

Bijlage 6: integriteit, authenticatie en onweerlegbaarheid  

Integriteit, authenticatie en onweerlegbaarheid worden aan een bericht toegevoegd in volgende stappen:

...

  1. De zender stelt een bericht op;

  2. Over de inhoud van het bericht wordt een controlegetal berekend, de hash. Voor de berekeningsmethode van de hash wordt een standaard algoritme gebruikt, dat door elke infrastructuur die deze standaard ondersteunt, is toe te passen;

  3. Het controlegetal wordt versleuteld met de private sleutel van de zender en bij de al dan niet versleutelde berichtinhoud gevoegd als een digitale handtekening. Versleutelen van de inhoud van het bericht voor vertrouwelijkheid is mogelijk;

  4. Het bericht wordt samen met de digitale handtekening verstuurd;

  5. Van het bericht wordt de handtekening ontcijferd met de publieke sleutel van de zender, waarna het controlegetal (Z) voor de zender ontvanger leesbaar wordt;

  6. De publieke sleutel van de zender is gekoppeld aan een geldig certificaat, uitgegeven door een betrouwbare certificaatautoriteit (CA). Dit garandeert de identiteit van de zender;

  7. Van de inhoud van het bericht wordt aan de ontvangkant opnieuw een controlegetal (O) berekend; en

  8. Tenslotte wordt het meegestuurde controlegetal (Z) vergeleken met controlegetal (O). Wanneer deze getallen precies gelijk zijn, dan is daarmee bewezen dat:

...