PKI

Een PKI (Public Key Infrastructure) is een verzameling rollen, beleidsregels, hardware, software en procedures die nodig zijn voor het aanmaken, beheren, distribueren, gebruiken, opslaan en intrekken van digitale certificaten en het beheren van versleuteling met openbare sleutel.

Het doel van een PKI is het vergemakkelijken van de veilige elektronische overdracht van informatie voor een reeks netwerkactiviteiten zoals e-commerce, internetbankieren en vertrouwelijke e-mail. PKI is nodig voor activiteiten waarbij eenvoudige wachtwoorden een ontoereikende authenticatiemethode zijn en er rigoureuzer bewijs nodig is om de identiteit van de betrokken partijen in de communicatie te bevestigen en de overgedragen informatie te valideren.

Afbeelding: “Public-Key-Infrastructure.svg”, gemaakt door Chris (Chrkl), gelicentieerd onder de Creative Commons Naamsvermelding-GelijkDelen 3.0 Unported License (CC BY-SA 3.0). Bron: https://commons.wikimedia.org/wiki/File:Public-Key-Infrastructure.svg(commons.wikimedia.org in Bing)

In cryptografie is een PKI een regeling die publieke sleutels verbindt met de respectievelijke identiteiten van entiteiten (zoals mensen en organisaties). De binding komt tot stand via een proces van registratie en uitgifte van certificaten bij en door een certificaatautoriteit (CA). Afhankelijk van het garantieniveau van de binding, kan dit worden uitgevoerd door een geautomatiseerd proces of onder menselijk toezicht. Als dit via een netwerk gebeurt, moet er een veilig certificaatregistratie- of certificaatbeheerprotocol zoals CMP worden gebruikt.

De PKI-rol die door een CA kan worden gedelegeerd om een geldige en correcte registratie te garanderen, wordt een registratieautoriteit (RA) genoemd. Een RA is verantwoordelijk voor het aanvaarden van aanvragen voor digitale certificaten en het authentiseren van de entiteit die de aanvraag indient. RFC 3647 van de Internet Engineering Task Force definieert een RA als “Een entiteit die verantwoordelijk is voor één of meer van de volgende functies: de identificatie en authenticatie van certificaataanvragers, het goedkeuren of afwijzen van certificaataanvragen, het initiëren van certificaatintrekkingen of schorsingen onder bepaalde omstandigheden, het verwerken van verzoeken van abonnees om hun certificaten in te trekken of te schorsen, en het goedkeuren of afwijzen van verzoeken van abonnees om hun certificaten te vernieuwen of opnieuw te keyen. RA's ondertekenen of geven echter geen certificaten uit (d.w.z., een RA heeft bepaalde taken gedelegeerd in naam van een CA).”Hoewel Microsoft misschien heeft verwezen naar een ondergeschikte CA als een RA, is dit onjuist volgens de X.509 PKI-standaarden. RA's hebben niet de ondertekeningsbevoegdheid van een CA en beheren alleen het doorlichten en verstrekken van certificaten. Dus in het geval van Microsoft PKI wordt de RA-functionaliteit geleverd door de Microsoft Certificate Services website of door Active Directory Certificate Services die Microsoft Enterprise CA en certificaatbeleid afdwingt door middel van certificaatsjablonen en de certificaatinschrijving beheert (handmatig of automatisch). In het geval van Microsoft Standalone CA's bestaat de functie van RA niet aangezien alle procedures die de CA controleren gebaseerd zijn op de administratie- en toegangsprocedure die geassocieerd zijn met het systeem dat de CA host en de CA zelf in plaats van Active Directory. De meeste commerciële PKI-oplossingen die niet van Microsoft zijn, bieden een stand-alone RA-component.

Een entiteit moet uniek identificeerbaar zijn binnen elk CA-domein op basis van informatie over die entiteit. Een derde validatieautoriteit (VA) kan deze entiteitsinformatie verstrekken namens de CA.

De X.509 standaard definieert het meest gebruikte formaat voor publieke sleutel certificaten.

Mogelijkheden

PKI levert “vertrouwensdiensten” - in gewone bewoordingen het vertrouwen in de acties of output van entiteiten, of het nu mensen of computers zijn. Doelstellingen van vertrouwensdiensten respecteren één of meer van de volgende capaciteiten: Vertrouwelijkheid, Integriteit en Authenticiteit (CIA).

Vertrouwelijkheid: Zekerheid dat geen enkele entiteit kwaadwillig of onbewust een payload in platte tekst kan bekijken. Gegevens worden versleuteld om ze geheim te maken, zodat zelfs als ze zouden worden gelezen, ze als wartaal overkomen. Misschien wel het meest gebruikte gebruik van PKI voor vertrouwelijkheidsdoeleinden is in de context van Transport Layer Security (TLS). TLS is een mogelijkheid die de beveiliging van gegevens tijdens het transport, dus tijdens de overdracht, ondersteunt. Een klassiek voorbeeld van TLS voor vertrouwelijkheid is het gebruik van een webbrowser om in te loggen op een dienst die gehost wordt op een website op het internet door een wachtwoord in te voeren.

Integriteit: De zekerheid dat als een entiteit de verzonden gegevens op de geringste manier zou wijzigen (manipuleren), het duidelijk zou zijn dat dit is gebeurd omdat de integriteit zou zijn aangetast. Vaak is het niet van het grootste belang om te voorkomen dat de integriteit wordt aangetast (tamper proof), maar het is wel van het grootste belang dat als de integriteit wordt aangetast, er duidelijk bewijs is dat dit is gebeurd (tamper evident).

Authenticiteit: Zekerheid dat een entiteit: i) zeker weet waarmee ze verbinding maakt; en/of ii) haar eigen legitimiteit kan bewijzen wanneer ze verbinding maakt met een beschermde dienst. Het eerste wordt aangeduid als servercertificaatauthenticatie, meestal gebruikt bij het inloggen op een webserver. De laatste wordt clientcertificaatauthenticatie genoemd en wordt bijvoorbeeld gebruikt bij het inloggen met een smartcard waarop een digitaal certificaat en een privésleutel staan.

Ontwerp

Public-key cryptografie is een cryptografische techniek waarmee entiteiten veilig kunnen communiceren op een onveilig openbaar netwerk en de identiteit van een entiteit betrouwbaar kunnen verifiëren via digitale handtekeningen.

Een PKI (Public Key Infrastructure) is een systeem voor het aanmaken, opslaan en verspreiden van digitale certificaten, die worden gebruikt om te verifiëren dat een bepaalde publieke sleutel toebehoort aan een bepaalde entiteit. De PKI creëert digitale certificaten die openbare sleutels toewijzen aan entiteiten, slaat deze certificaten veilig op in een centrale opslagplaats en trekt ze indien nodig in.

Een PKI bestaat uit:

• Een certificaatautoriteit (CA), die de digitale certificaten opslaat, uitgeeft en ondertekent;

• Een registratieautoriteit (RA), die de identiteit verifieert van entiteiten die hun digitale certificaten willen opslaan bij de CA;

• Een centrale map, een veilige locatie waar sleutels worden opgeslagen en geïndexeerd;

• Een certificaatbeheersysteem, dat zaken beheert als de toegang tot opgeslagen certificaten of de levering van de uit te geven certificaten;

• Een certificaatbeleid, waarin de eisen van de PKI met betrekking tot de procedures staan. Het doel is om buitenstaanders in staat te stellen de betrouwbaarheid van de PKI te analyseren.

Methoden voor certificering

Certificaatautoriteiten

Hoofdartikel: Certificaatautoriteit

De primaire rol van de CA is het digitaal ondertekenen en publiceren van de openbare sleutel van een bepaalde gebruiker. Dit gebeurt met de privésleutel van de CA, zodat het vertrouwen in de gebruikerssleutel afhangt van het vertrouwen in de geldigheid van de sleutel van de CA. Als de CA een derde partij is die losstaat van de gebruiker en het systeem, dan wordt hij de Registration Authority (RA) genoemd, die al dan niet losstaat van de CA. De binding tussen de sleutel en de gebruiker wordt, afhankelijk van de mate van zekerheid die de binding heeft, tot stand gebracht door software of onder menselijk toezicht.

De term vertrouwde derde partij (TTP) kan ook worden gebruikt voor certificaatautoriteit (CA). Bovendien wordt PKI zelf vaak gebruikt als synoniem voor een CA-implementatie.

Intrekking certificaat

Hoofdartikel: Certificaatintrekking

Een certificaat kan ingetrokken worden voordat het verloopt, wat aangeeft dat het niet langer geldig is. Zonder intrekking zou een aanvaller zo'n gecompromitteerd of verkeerd uitgegeven certificaat kunnen uitbuiten tot het verloopt. Daarom is intrekking een belangrijk onderdeel van een openbare sleutelinfrastructuur. Intrekking wordt uitgevoerd door de uitgevende certificaatautoriteit, die een cryptografisch geauthenticeerde intrekkingsverklaring produceert.

Voor het distribueren van herroepingsinformatie naar cliënten moet de tijdigheid van de ontdekking van herroeping (en dus het venster voor een aanvaller om een gecompromitteerd certificaat te misbruiken) worden afgewogen tegen het gebruik van middelen voor het opvragen van herroepingsstatussen en privacybelangen. Als informatie over intrekking niet beschikbaar is (per ongeluk of door een aanval), moeten clients beslissen of ze hard falen en een certificaat behandelen alsof het ingetrokken is (en zo de beschikbaarheid verminderen) of zacht falen en het certificaat behandelen alsof het niet ingetrokken is (en aanvallers toestaan om intrekking te omzeilen).

Vanwege de kosten van revocatiecontroles en de beschikbaarheidsimpact van potentieel onbetrouwbare externe services, beperken webbrowsers de revocatiecontroles die ze uitvoeren en zullen ze fail-soft gaan als ze dat doen. Lijsten met certificaten die ingetrokken zijn, kosten te veel bandbreedte voor routinematig gebruik en het Online Certificate Status Protocol levert verbindingslatentie en privacyproblemen op. Er zijn andere schema's voorgesteld, maar deze zijn nog niet succesvol geïmplementeerd om fail-hard controles mogelijk te maken.

Marktaandeel emittent

In dit model van vertrouwensrelaties is een CA een vertrouwde derde partij - vertrouwd door zowel het subject (eigenaar) van het certificaat als door de partij die op het certificaat vertrouwt.

Volgens het NetCraft-rapport uit 2015, de industriestandaard voor het monitoren van actieve Transport Layer Security (TLS)-certificaten, staat er: “Hoewel het wereldwijde [TLS]-ecosysteem competitief is, wordt het gedomineerd door een handvol grote CA's - drie certificaatautoriteiten (Symantec, Sectigo, GoDaddy) zijn goed voor driekwart van alle uitgegeven [TLS]-certificaten op publiek gerichte webservers. De toppositie wordt al sinds het begin van [ons] onderzoek ingenomen door Symantec (of VeriSign voordat het werd overgenomen door Symantec), dat momenteel goed is voor iets minder dan een derde van alle certificaten. Om het effect van verschillende methodologieën te illustreren: onder de miljoen drukste sites heeft Symantec 44% van de geldige, vertrouwde certificaten uitgegeven - aanzienlijk meer dan het totale marktaandeel.”

Na grote problemen in de manier waarop de uitgifte van certificaten werd beheerd, hebben alle grote spelers geleidelijk de door Symantec uitgegeven certificaten gewantrouwd, beginnend in 2017 en voltooid in 2021.

Tijdelijke certificaten en single sign-on

Deze aanpak omvat een server die fungeert als een offline certificaatautoriteit binnen een single sign-on systeem. Een single sign-on server geeft digitale certificaten uit aan het clientsysteem, maar slaat ze nooit op. Gebruikers kunnen programma's etc. uitvoeren met het tijdelijke certificaat. Deze oplossing wordt vaak gebruikt voor X.509-gebaseerde certificaten.

Vanaf sep 2020 is de geldigheid van TLS-certificaten teruggebracht naar 13 maanden.

Web van vertrouwen

Hoofdartikel: Vertrouwensweb

Een alternatieve benadering van het probleem van publieke authenticatie van publieke sleutelinformatie is het vertrouwensweb, dat gebruik maakt van zelfondertekende certificaten en attestaties van die certificaten door derden. De enkelvoudige term “vertrouwensweb” impliceert niet het bestaan van een enkel vertrouwensweb, of gemeenschappelijk vertrouwenspunt, maar eerder een van een willekeurig aantal mogelijk los van elkaar staande “vertrouwenswebben”. Voorbeelden van implementaties van deze benadering zijn PGP (Pretty Good Privacy) en GnuPG (een implementatie van OpenPGP, de gestandaardiseerde specificatie van PGP). Omdat PGP en implementaties het gebruik van digitale e-mailhandtekeningen toestaan voor zelfpublicatie van publieke sleutelinformatie, is het relatief eenvoudig om een eigen vertrouwensweb te implementeren.

Een van de voordelen van het vertrouwensweb, zoals in PGP, is dat het kan samenwerken met een PKI CA die volledig vertrouwd wordt door alle partijen in een domein (zoals een interne CA in een bedrijf) die bereid is om certificaten te garanderen, als een vertrouwde introducer. Als het “web van vertrouwen” volledig vertrouwd is, dan is, door de aard van een web van vertrouwen, het vertrouwen schenken aan één certificaat het vertrouwen schenken aan alle certificaten in dat web. Een PKI is slechts zo waardevol als de standaarden en praktijken die de uitgifte van certificaten controleren en het opnemen van PGP of een persoonlijk ingesteld vertrouwensweb zou de betrouwbaarheid van de implementatie van PKI door die onderneming of dat domein aanzienlijk kunnen aantasten.

Het web van vertrouwen concept werd voor het eerst naar voren gebracht door PGP bedenker Phil Zimmermann in 1992 in de handleiding voor PGP versie 2.0:

Na verloop van tijd zul je sleutels verzamelen van andere mensen die je misschien wilt aanwijzen als vertrouwde introducé. Alle anderen zullen hun eigen vertrouwde introducers kiezen. En iedereen zal geleidelijk aan een verzameling certificerende handtekeningen van andere mensen verzamelen en samen met hun sleutel verspreiden, met de verwachting dat iedereen die het ontvangt ten minste één of twee van de handtekeningen zal vertrouwen. Dit zal leiden tot het ontstaan van een gedecentraliseerd fouttolerant web van vertrouwen voor alle publieke sleutels.

Eenvoudige openbare sleutelinfrastructuur

Hoofdartikel: Eenvoudige openbare sleutelinfrastructuur

Een ander alternatief, dat zich niet bezighoudt met publieke authenticatie van publieke sleutelinformatie, is de eenvoudige publieke sleutelinfrastructuur (SPKI), die voortkwam uit drie onafhankelijke pogingen om de complexiteit van X.509 en PGP's vertrouwensweb te overwinnen. SPKI associeert gebruikers niet met personen, omdat de sleutel wordt vertrouwd en niet de persoon. SPKI gebruikt geen notie van vertrouwen, omdat de verificateur ook de uitgever is. Dit wordt een “autorisatielus” genoemd in SPKI-terminologie, waarbij autorisatie een integraal onderdeel is van het ontwerp. Dit type PKI is vooral nuttig voor het maken van integraties van PKI die niet afhankelijk zijn van derde partijen voor certificaatautorisatie, certificaatinformatie, etc.; een goed voorbeeld hiervan is een air-gapped netwerk in een kantoor.

Gedecentraliseerde PKI

Gedecentraliseerde identifiers (DID's) elimineren de afhankelijkheid van gecentraliseerde registers voor identifiers evenals gecentraliseerde certificaatautoriteiten voor sleutelbeheer, wat de standaard is in hiërarchische PKI. In gevallen waar het DID-register een gedistribueerd grootboek is, kan elke entiteit dienen als zijn eigen root-autoriteit. Deze architectuur wordt gedecentraliseerde PKI (DPKI) genoemd.

Geschiedenis

Ontwikkelingen in PKI vonden begin jaren 1970 plaats bij de Britse inlichtingendienst GCHQ, waar James Ellis, Clifford Cocks en anderen belangrijke ontdekkingen deden met betrekking tot versleutelingsalgoritmen en sleuteldistributie. Omdat de ontwikkelingen bij GCHQ zeer geheim zijn, werden de resultaten van dit werk geheim gehouden en pas halverwege de jaren 90 openbaar gemaakt.

De openbaarmaking van zowel veilige sleuteluitwisseling als asymmetrische sleutelalgoritmen in 1976 door Diffie, Hellman, Rivest, Shamir en Adleman veranderde de veilige communicatie volledig. Met de verdere ontwikkeling van snelle digitale elektronische communicatie (het Internet en zijn voorgangers) werd de behoefte duidelijk aan manieren waarop gebruikers veilig met elkaar konden communiceren en, als een verder gevolg daarvan, aan manieren waarop gebruikers er zeker van konden zijn met wie ze eigenlijk communiceerden.

Er werden verschillende cryptografische protocollen uitgevonden en geanalyseerd waarbinnen de nieuwe cryptografische primitieven effectief gebruikt konden worden. Met de uitvinding van het World Wide Web en de snelle verspreiding ervan werd de nood aan authenticatie en veilige communicatie nog dringender. Commerciële redenen alleen (bv. e-commerce, online toegang tot eigen databases via webbrowsers) waren voldoende. Taher Elgamal en anderen bij Netscape ontwikkelden het SSL-protocol (‘https’ in Web URL's); dit omvatte het vastleggen van sleutels, serverauthenticatie (vóór v3 alleen eenrichtingsverkeer), enzovoort. Zo ontstond een PKI-structuur voor webgebruikers/sites die beveiligde communicatie wensen.

Verkopers en ondernemers zagen de mogelijkheid van een grote markt, begonnen bedrijven (of nieuwe projecten bij bestaande bedrijven) en begonnen te ijveren voor wettelijke erkenning en bescherming tegen aansprakelijkheid. Een technologieproject van de American Bar Association publiceerde een uitgebreide analyse van enkele van de te verwachten juridische aspecten van PKI-activiteiten (zie de ABA richtlijnen voor digitale handtekeningen) en kort daarna begonnen verschillende Amerikaanse staten (Utah was de eerste in 1995) en andere rechtsgebieden over de hele wereld wetten aan te nemen en voorschriften in te voeren. Consumentengroepen stelden vragen over privacy, toegang en aansprakelijkheidsoverwegingen, waarmee in sommige rechtsgebieden meer rekening werd gehouden dan in andere.

De wet- en regelgeving verschilde, er waren technische en operationele problemen bij het omzetten van PKI-schema's in succesvolle commerciële exploitatie en de vooruitgang verliep veel trager dan de pioniers zich hadden voorgesteld.

In de eerste jaren van de 21ste eeuw was de onderliggende cryptografische techniek duidelijk niet eenvoudig om correct in te zetten. Bedieningsprocedures (manueel of automatisch) waren niet gemakkelijk correct te ontwerpen (en zelfs als ze zo ontworpen waren, niet perfect uit te voeren, wat de techniek vereiste). De bestaande standaarden waren ontoereikend.

PKI-verkopers hebben een markt gevonden, maar het is niet helemaal de markt die in het midden van de jaren 90 werd voorzien en het is langzamer gegroeid en op enigszins andere manieren dan werd verwacht. PKI's hebben sommige van de verwachte problemen niet opgelost en verschillende grote leveranciers zijn failliet gegaan of overgenomen door anderen. PKI heeft het meeste succes gehad in overheidsimplementaties; de grootste PKI-implementatie tot nu toe is de PKI-infrastructuur van het Defense Information Systems Agency (DISA) voor het Common Access Cards-programma.

Gebruikt

PKI's van het ene of het andere type en van verschillende leveranciers hebben vele toepassingen, waaronder het leveren van openbare sleutels en bindingen aan gebruikersidentiteiten, die worden gebruikt voor:

Encryptie en/of verificatie van afzenders van e-mailberichten (bijvoorbeeld met OpenPGP of S/MIME);

Encryptie en/of authenticatie van documenten (bijvoorbeeld de standaarden XML-handtekening of XML-codering als documenten als XML zijn gecodeerd);

Authenticatie van gebruikers voor applicaties (bijvoorbeeld smartcard logon, client authenticatie met SSL/TLS). Er is experimenteel gebruik voor digitaal ondertekende HTTP authenticatie in de Enigform en mod_openpgp projecten;

Het opstarten van veilige communicatieprotocollen, zoals Internet sleuteluitwisseling (IKE) en SSL/TLS. In beide protocollen wordt bij het opzetten van een veilig kanaal (een “beveiligingsassociatie”) gebruik gemaakt van asymmetrische sleutel- d.w.z. openbare sleutelmethoden, terwijl bij de daadwerkelijke communicatie sneller gebruik wordt gemaakt van symmetrische sleutel- d.w.z. geheime sleutelmethoden;

Mobiele handtekeningen zijn elektronische handtekeningen die aangemaakt worden met een mobiel toestel en die steunen op handtekening- of certificatiediensten in een locatieonafhankelijke telecommunicatieomgeving;

Het internet der dingen vereist veilige communicatie tussen wederzijds vertrouwde apparaten. Een publieke sleutelinfrastructuur stelt apparaten in staat om X.509-certificaten te verkrijgen en te vernieuwen, die worden gebruikt om vertrouwen tussen apparaten tot stand te brengen en communicatie te versleutelen met TLS.

Open source implementaties

OpenSSL is de eenvoudigste vorm van CA en gereedschap voor PKI. Het is een toolkit, ontwikkeld in C, die in alle grote Linux-distributies zit en zowel gebruikt kan worden om je eigen (eenvoudige) CA te bouwen als om toepassingen PKI-enabled te maken. (Apache gelicentieerd)

EJBCA is een volledige CA-implementatie voor bedrijven, ontwikkeld in Java. Het kan gebruikt worden om een CA op te zetten, zowel voor intern gebruik als voor een dienst. (LGPL gelicentieerd)

XiPKI, CA en OCSP responder. Met ondersteuning voor SHA-3, geïmplementeerd in Java. (Apache gelicentieerd)

XCA is een grafische interface en een database. XCA gebruikt OpenSSL voor de onderliggende PKI-bewerkingen.

DogTag is een volledig uitgeruste CA ontwikkeld en onderhouden als onderdeel van het Fedora Project.

CFSSL open source toolkit ontwikkeld door CloudFlare voor het ondertekenen, verifiëren en bundelen van TLS-certificaten. (BSD 2-clausule gelicentieerd)

Kluisprogramma voor het veilig beheren van geheimen (inclusief TLS-certificaten) ontwikkeld door HashiCorp (Mozilla Public License 2.0 gelicentieerd)

Boulder, een op ACME gebaseerde CA geschreven in Go. Boulder is de software waarop Let's Encrypt draait.

Kritiek

Zie ook: X.509 § Beveiliging, Comodo Group § Inbreukincident 2011, en Diginotar § Uitgifte van frauduleuze certificaten

Sommigen beweren dat het aanschaffen van certificaten voor het beveiligen van websites door SSL/TLS en het beveiligen van software door code signing een dure onderneming is voor kleine bedrijven. De opkomst van gratis alternatieven, zoals Let's Encrypt, heeft hier echter verandering in gebracht. HTTP/2, de nieuwste versie van het HTTP-protocol, staat in theorie onbeveiligde verbindingen toe; in de praktijk hebben grote browserbedrijven duidelijk gemaakt dat ze dit protocol alleen ondersteunen via een PKI-beveiligde TLS-verbinding. Webbrowsers die HTTP/2 implementeren, waaronder Chrome, Firefox, Opera en Edge, ondersteunen HTTP/2 alleen via TLS door gebruik te maken van de ALPN-extensie van het TLS-protocol. Dit zou betekenen dat website-eigenaren, om de snelheidsvoordelen van HTTP/2 te krijgen, gedwongen zouden worden om SSL/TLS-certificaten te kopen die door bedrijven worden beheerd.

Momenteel worden de meeste webbrowsers geleverd met voorgeïnstalleerde tussenliggende certificaten die zijn uitgegeven en ondertekend door een certificaatautoriteit, met publieke sleutels die zijn gecertificeerd door zogenaamde rootcertificaten. Dit betekent dat browsers een groot aantal verschillende certificaatleveranciers bij zich moeten hebben, waardoor het risico op een sleutelcompromittering toeneemt.

Als bekend is dat een sleutel gecompromitteerd is, kan dit worden opgelost door het certificaat in te trekken, maar zo'n compromittering is niet eenvoudig te detecteren en kan een enorme inbreuk op de beveiliging zijn. Browsers moeten een beveiligingspatch uitbrengen om tussenliggende certificaten die zijn uitgegeven door een gecompromitteerde root-certificaatautoriteit in te trekken.

Gebaseerd op het Wikipedia-artikel “Public Key Infrastructure”, beschikbaar onder de Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationale Licentie (CC BY-SA 4.0). Bron: https://en.wikipedia.org/wiki/Public_key_infrastructure