PKI-toepassingen: HTTPS, S/MIME en codeondertekening

Public Key Infrastructure (PKI) vormt de onzichtbare ruggengraat van veilige digitale communicatie. De certificaten en CAs die je hebt bestudeerd, worden dagelijks in tientallen praktijksituaties gebruikt. Het Security+-examen toetst of je gebruiksscenario's voor PKI kunt herkennen, begrijpt welk certificaattype geschikt is voor elk scenario en kunt bepalen welke bescherming PKI in elke context biedt. De drie belangrijkste gebruiksscenario's op het examen zijn HTTPS/TLS (webbeveiliging), S/MIME (e-mailbeveiliging) en codeondertekening (software-integriteit).

HTTPS (HTTP via TLS) is het zichtbaarste gebruiksscenario voor PKI. Wanneer je verbinding maakt met https://bank.com, doet je browser het volgende: (1) het ontvangt het TLS-certificaat van de server, (2) controleert of de certificaatketen leidt naar een vertrouwde root-CA, (3) controleert de hostnaam aan de hand van de SAN-velden, (4) controleert of het certificaat niet is ingetrokken en (5) gebruikt de openbare sleutel voor een Diffie-Hellman-sleuteluitwisseling om een versleutelde sessie tot stand te brengen. Het hangslotpictogram in je browser betekent dat al deze controles zijn geslaagd. Een ontbrekend of ongeldig certificaat leidt tot een browserwaarschuwing die de meeste gebruikers ervan weerhoudt door te gaan.

S/MIME (Secure/Multipurpose Internet Mail Extensions) gebruikt PKI-certificaten om e-mail twee beveiligingsdiensten te bieden. Versleuteling: de afzender versleutelt de inhoud van de e-mail met de openbare sleutel van de ontvanger, zodat alleen de ontvanger deze kan ontsleutelen. Zo blijft de vertrouwelijkheid beschermd, ook als de e-mail tijdens het verzenden wordt onderschept of op een gecompromitteerde server wordt opgeslagen. Digitale handtekeningen: de afzender ondertekent de e-mail met diens privésleutel. Daarmee wordt bewezen dat de e-mail echt van de afzender afkomstig is en niet is gewijzigd. Dit beschermt de integriteit en zorgt voor onweerlegbaarheid. Voor S/MIME moet elke gebruiker een eigen certificaat hebben dat door een CA is uitgegeven.

Codeondertekening gebruikt PKI om software — uitvoerbare bestanden, scripts, stuurprogramma's en installatieprogramma's — digitaal te ondertekenen. Gebruikers kunnen zo controleren of de software afkomstig is van een vertrouwde uitgever en niet is gemanipuleerd. De softwareleverancier ondertekent de code met een privésleutel uit een certificaat voor codeondertekening dat door een vertrouwde CA is uitgegeven. Wanneer een gebruiker de software uitvoert, controleert het besturingssysteem de handtekening met de openbare sleutel van de leverancier uit de certificaatketen. Windows SmartScreen, macOS Gatekeeper en appstores voor iOS en Android vertrouwen allemaal op codeondertekening om de herkomst van software vast te stellen. Niet-ondertekende software kan worden geblokkeerd of beveiligingswaarschuwingen veroorzaken.

Authenticatie met clientcertificaten (ook wel wederzijdse TLS of mTLS genoemd) breidt het standaard-TLS-model uit door te vereisen dat ook de client een certificaat presenteert. Bij standaard-TLS wordt alleen de server met een certificaat geauthenticeerd; bij mTLS authenticeren beide partijen elkaar. Dit wordt gebruikt voor: VPN-authenticatie (smartcards of clientcertificaten in plaats van wachtwoorden), API-authenticatie (machine-tot-machine-authenticatie waarbij de client een dienst en geen persoon is) en bevoorrechte beheerderstoegang (waarbij beheerders hardwaretokens met ingebouwde certificaten moeten gebruiken).

SSH gebruikt cryptografie met openbare sleutels voor twee doelen: serverauthenticatie en clientauthenticatie. Bij serverauthenticatie presenteert een SSH-server bij de eerste verbinding zijn hostsleutel (openbare sleutel). Je SSH-client slaat deze op in ~/.ssh/known_hosts. Bij volgende verbindingen waarschuwt SSH je als de hostsleutel is gewijzigd, wat kan wijzen op een MITM-aanval of een opnieuw opgebouwde server. Bij clientauthenticatie gebruiken beheerders sleutelparen in plaats van wachtwoorden: de openbare sleutel wordt toegevoegd aan authorized_keys op de server en de privésleutel, die nooit wordt verzonden, bewijst de identiteit. SSH-hostsleutels staan los van PKI-certificaten, maar vervullen dezelfde vertrouwensfunctie.

PKI maakt juridisch bindende digitale documentondertekening in veel rechtsgebieden mogelijk. Handtekeningen in Adobe PDF, DocuSign en elektronische-ondertekeningssystemen van overheden gebruiken allemaal PKI-certificaten om documenten te ondertekenen. Een belangrijke aanvulling op documentondertekening is tijdstempeling: een Trusted Timestamp Authority (TSA) ondertekent de hash van het document opnieuw met een vertrouwd tijdstip. Zo wordt bewezen dat het document op een specifiek moment bestond. Tijdstempeling is ook essentieel voor codeondertekening: zonder tijdstempel worden codehandtekeningen ongeldig wanneer het ondertekeningscertificaat verloopt, zelfs voor software die vóór het verlopen is verspreid.

Nu IoT-apparaten zich snel verspreiden, biedt PKI een manier om apparaten op grote schaal te authenticeren. Elk apparaat krijgt tijdens de productie een uniek certificaat toegewezen, een proces dat provisioning van apparaatidentiteiten wordt genoemd. Servers kunnen zo afzonderlijke apparaten aan de hand van hun certificaten authenticeren. Dit maakt scenario's mogelijk zoals een slimme meter die zijn identiteit aan de server van het nutsbedrijf bewijst, een medisch apparaat dat zich bij een ziekenhuisnetwerk authenticeert of een wagenpark dat zich bij de backend van een fabrikant authenticeert. IoT-PKI moet miljoenen apparaten met beperkte middelen kunnen verwerken. Daarom worden ECC-certificaten steeds vaker gebruikt vanwege hun kleine omvang en snelle verificatie.

VPN-authenticatie op basis van certificaten is aanzienlijk veiliger dan VPN-authenticatie op basis van wachtwoorden. Elke VPN-gebruiker of elk VPN-apparaat krijgt van de interne CA van de organisatie een clientcertificaat. Bij het maken van de verbinding controleert de VPN-gateway het clientcertificaat: de gateway controleert of het is uitgegeven door de vertrouwde interne CA, binnen de geldigheidsperiode valt en niet via CRL/OCSP is ingetrokken. Wanneer een medewerker vertrekt, voorkomt het onmiddellijk intrekken van diens certificaat dat die persoon nog toegang tot de VPN heeft. Dat is betrouwbaarder dan hopen dat de medewerker het wachtwoord niet met anderen heeft gedeeld.

Beveiligingsprofessionals moeten veelvoorkomende certificaatfouten kunnen vaststellen. Certificaat verlopen: de datum notAfter is verstreken — vernieuw het certificaat. Onjuiste hostnaam: de SAN van het certificaat komt niet overeen met de opgevraagde hostnaam — controleer de CN's en SAN's; mogelijk is een wildcard- of multi-SAN-certificaat nodig. Zelfondertekend certificaat: geen CA staat in voor dit certificaat — voeg het toe aan de lokale vertrouwensopslag of vervang het door een door een CA ondertekend certificaat. Onvolledige keten: het intermediaire CA-certificaat wordt niet door de server geleverd — configureer de server om de volledige keten te verzenden. Certificaat ingetrokken: CRL of OCSP toont aan dat het certificaat is ingetrokken — onmiddellijke respons op een mogelijk gecompromitteerde sleutel is vereist.

Twee certificaattypen kunnen meerdere hostnamen afhandelen. Een wildcardcertificaat omvat alle subdomeinen op het eerste niveau van een domein: *.example.com omvat www.example.com, mail.example.com en api.example.com, maar NIET sub.api.example.com (twee niveaus). Eén certificaat en één privésleutel voor alle diensten is handig, maar riskant als de sleutel wordt gecompromitteerd: alle diensten worden dan getroffen. Een multi-SAN-certificaat vermeldt meerdere specifieke domeinen expliciet in de SAN-extensie, bijvoorbeeld example.com, www.example.com en api.example.com. Dit biedt meer granulariteit, maar vereist dat het certificaat wordt bijgewerkt wanneer nieuwe domeinen worden toegevoegd.

In deze les heb je geleerd dat HTTPS/TLS servercertificaten gebruikt om webverkeer te versleutelen en servers te authenticeren; dat S/MIME-certificaten het ondertekenen en versleutelen van e-mail mogelijk maken; dat certificaten voor codeondertekening de integriteit van software en de identiteit van de uitgever aantonen; en dat clientcertificaten wederzijdse authenticatie voor VPN's en API's mogelijk maken. Hierna bekijken we wachtwoordbeleid en meervoudige authenticatie.