3.1.4. Bijlagen

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:

1. Opstellen van een bericht;
2. Genereren van een symmetrische sessiesleutel. Deze wordt éénmalig gebruikt;
3. Encrypteren van het bericht d.m.v. de sessiesleutel;
4. Encrypteren van de sessiesleutel (one-time key) met de publieke sleutel van de bestemmeling; en
5. Toevoegen van de geëncrypteerde sleutel aan het geëncrypteerd bericht, en verzenden van het geheel naar de bestemmeling.

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. 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, een databank van certificaten. Daarnaast publiceert de CA een lijst van ingetrokken certificaten: de Certificate Revocation List (CRL). 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:

• (A) de aanvrager genereert zelf het sleutelpaar. Daarna vraagt hij een certificaat aan bij de registratieautoriteit (Registration Authority of RA). De aanvrager geeft daarbij de publieke sleutel van zijn sleutelpaar mee; of
• (B) de aanvrager vraagt een certificaat aan bij de RA zonder zelf de sleutel gegenereerd te hebben.

2. Stap 2: de RA doet de verificatie van de aanvrager van het certificaat. De nauwkeurigheid van de verificatie is een belangrijk kwaliteitsaspect van het certificaat. Dit kan variëren van geen verificatie tot een grondige controle van de gegevens. Daarna bestelt de RA het certificaat bij de CA. Als de RA-functie geautomatiseerd verloopt, dan worden correct ingevulde aanvragen automatisch doorgestuurd naar de CA.

3. Stap 3: de CA beoordeelt de authenticiteit van aanvragen en maakt na goedkeuring nieuwe certificaten aan en zet deze in een (lokale) bewaarplaats (repository):

• (A) indien de aanvrager zelf een sleutelpaar heeft gegenereerd en de publieke sleutel heeft meegeleverd met de aanvraag, maakt de CA na goedkeuring het certificaat aan en zet deze in een lokale repository;
• (B) zoniet, genereert de CA een sleutelpaar en gebruikt de nieuwe publieke sleutel om een certificaat aan te maken. Deze wordt in een lokale repository gezet. De private sleutel wordt op een zodanige wijze bewaard, dat ook niemand bij de CA kennis kan nemen van de waarde van de sleutel.

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 (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.

Symmetrische encryptie met de KEK als sleutel zorgt hier voor de beveiliging van de periodieke sleutel, zodat deze via een niet vertrouwd pad verzonden kan worden of veilig op een systeem kan worden opgeslagen. De periodieke sleutel kan weer verkregen worden met de omgekeerde bewerking (Key Unwrap) en dezelfde KEK. Een bekende toepassing is Over-The-Air-Keying (OTAK) voor encryptie van draadloze systemen voor spraak;

• 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

De berichtuitwisseling verloopt als volgt:

1. Vanuit de client (webbrowser) wordt een serviceverzoek gedaan naar een webserver;
2. De server stuurt een willekeurige code samen met de publieke KEK van de server. De webbrowser checkt de geldigheid van het certificaat van de server aan de hand van een tabel in de browser;
3. De client genereert een willekeurige (random) sessiesleutel, versleutelt deze met de publieke KEK van de server en stuurt die terug naar de server;
4. De server decrypteert de sessiesleutel met behulp van de geheime private KEK van de server en stuurt de met de nieuwe sessiesleutel versleutelde code opnieuw naar de client, zodat die kan verifiëren of er nog steeds met dezelfde server gecommuniceerd wordt;
5. De sessiesleutel is nu bij beide partijen bekend en wordt vervolgens voor de symmetrische encryptie van het webverkeer gebruikt. Veilige interactie is nu gegarandeerd voor de duur van de sessie.

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 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:

• De inhoud van het bericht niet is gewijzigd
• Het bericht afkomstig is van de zender van de overeenkomende publieke sleutel, gekoppeld aan het certificaat van de zender en daarmee heeft de zender zich bij de ontvanger geauthentiseerd.