Cryptografische standaarden hebben twee belangrijke doelen: het interoperabel maken van verschillende implementaties en het voorkomen van diverse bekende fouten in gangbare schema's. In deze blog bespraken we de Public Key Cryptography Standard (PKCS), die een aanzienlijke impact heeft gehad op het gebruik van publieke-sleutelversleuteling in de praktijk. De PKCS-standaard is een reeks standaarden, genaamd PKCS 1 tot en met 15.

Deze standaarden hebben betrekking op RSA -encryptie, RSA-handtekening, wachtwoordgebaseerde encryptie, syntaxis voor versleutelde berichten, syntaxis voor informatie over privésleutels, geselecteerde objectcategorie en attribuuttype, syntaxis voor authenticatieverzoeken, interface voor encryptietokens, syntaxis voor uitwisseling van persoonlijke informatie en grammatica voor informatie over versleutelde tokens. RSA Laboratories publiceert de PKCS-standaard.

Hoewel RSA Laboratories het publiek om commentaar en suggesties over de PKCS-standaard vraagt, behoudt RSA Laboratories zich de exclusieve bevoegdheid voor om alle aspecten van de PKCS-standaard te bepalen. PKCS is de basis geworden voor veel andere standaarden, zoals S/MIME.

Cryptografie met publieke sleutels is gebaseerd op een asymmetrisch cryptografisch algoritme dat gebruikmaakt van twee gerelateerde sleutels: een publieke sleutel en een privésleutel. Het bijzondere aan deze twee sleutels is dat de privésleutel wordt afgeleid uit de publieke sleutel. Dit is computationeel onhaalbaar. Gebruikers publiceren hun publieke sleutels in openbare registers, zoals LDAP-directory's, en houden hun privésleutels voor zichzelf.

Afhankelijk van het doel van het algoritme zijn er algoritmen voor encryptie en decryptie met publieke sleutels en algoritmen voor digitale handtekeningen. Encryptiealgoritmen kunnen worden gebruikt om gegevens te versleutelen met een publieke sleutel (bijvoorbeeld een symmetrische sleutel), zodat alleen de ontvanger met de bijbehorende privésleutel de gegevens kan decoderen.

Typische algoritmen voor encryptie met openbare sleutels zijn RSA en ECIES (Elliptic Curve Integrated Encryption Scheme, zie SECG 2000). Het handtekeningalgoritme wordt gecombineerd met het berichtendigestalgoritme, dat berichten van elke lengte met behulp van de privésleutel kan omzetten in een handtekening. Op deze manier kan dezelfde handtekening niet computationeel worden gevonden zonder de privésleutel te kennen.

Het bericht met de standaardhandtekening kan worden gevonden of de handtekening van een specifiek bericht worden bekeken. Iedereen met de bijbehorende openbare sleutel kan de geldigheid van de handtekening verifiëren. Typische algoritmen voor digitale handtekeningen met openbare sleutels zijn RSA, DSA en ECDSA.

PKCS-specificaties

Nee.	PKCS-titel	Heb je vragen? Stel ze hier.
1	RSA Cryptografie Standaard
2		opgenomen in PKCS #1
3	Diffie-Hellman-sleutelovereenkomststandaard	vervangen door IEEE 1363a etc.
4	Wachtwoordgebaseerde cryptografiestandaard
5	Uitgebreide certificaatsyntaxisstandaard	nooit aangenomen
6	Cryptografische berichtensyntaxisstandaard	vervangen door RFC 3369 (CMS)
7	Standaard voor syntaxis van privésleutelinformatie
8	Geselecteerde objectklassen en attribuuttypen
9	Standaard voor certificeringsaanvraagsyntaxis
10	Cryptografische tokeninterfacestandaard	aangeduid als CRYPTOKI
11	Standaard voor de uitwisseling van persoonlijke informatiesyntaxis
12	(gereserveerd voor ECC)	nooit gepubliceerd
13	(gereserveerd voor pseudo-willekeurige getallengeneratie)	nooit gepubliceerd
14	Cryptografische tokeninformatie syntaxisstandaard

PKCS-normen

PKCS #1: RSA-cryptografiestandaard

PKCS #1 v2.1 biedt standaarden voor de implementatie van op RSA-algoritmen gebaseerde cryptografische encryptieschema's met openbare sleutels en digitale handtekeningschema's met bijlage. Het definieert ook de bijbehorende ASN.1-syntaxis voor het weergeven van sleutels en het identificeren van de technieken.

De veiligheid van het RSA-algoritme is gebaseerd op de moeilijkheidsgraad van het ontbinden van het product van grote priemgetallen. In PKCS #1 v2.1 wordt een multi-prime RSA-schema geïntroduceerd. Multiprime RSA betekent dat de modulus niet het product is van twee priemgetallen, maar van meer dan twee priemgetallen. Dit wordt gebruikt om de prestaties van cryptografische RSA-primitieven te verbeteren.

PKCS #3 (verouderd): Diffie-Hellman-sleutelovereenkomststandaard

PKCS #3 v1.4 beschrijft een methode voor het implementeren van de Diffie-Hellman-sleutelovereenkomst, waarbij twee partijen een geheime sleutel kunnen afspreken die alleen zij kennen. PKCS #3 is vervangen door de moderne behandeling van sleutelvaststellingsschema's zoals gespecificeerd in IEEE 1363a (2003), ANSI 9.42, ANSI X9.44, ANSI X9.63, enz.

PKCS #5: Wachtwoordgebaseerde cryptografiestandaard

In veel toepassingen van openbare-sleutelcryptografie is de gebruikersveiligheid uiteindelijk afhankelijk van een of meer geheime tekstwaarden of wachtwoorden. Zo wordt de privésleutel van een gebruiker meestal versleuteld met een wachtwoord, en wordt de versleutelde privésleutel bewaard op opslagapparaten. Er zijn echter twee fundamentele problemen met betrekking tot het gebruik van wachtwoorden:

Een wachtwoord is niet direct toepasbaar als sleutel voor een conventioneel cryptosysteem
Wachtwoorden worden vaak gekozen uit een relatief kleine ruimte.

Speciale aandacht is daarom vereist om zich te verdedigen tegen zoekaanvallen. PKCS #5 biedt een algemeen mechanisme om de beveiliging van wachtwoordgebaseerde cryptografische primitieven te verbeteren, inclusief sleutelafleidingsfuncties, encryptieschema's, berichtauthenticatieschema's en ASN.1-syntaxis die de technieken identificeert.

PKCS #6 (Historisch): Uitgebreide certificaatsyntaxisstandaard

Toen PKCS #6 werd opgesteld, bevond X.509 zich in versie 1.0 en was er geen extensiecomponent gedefinieerd in het certificaat. Een X.509 v3-certificaat kan informatie over een bepaalde entiteit bevatten in de extensiecomponent. Sinds de introductie van X.509 v3 is de status van PKCS #6 historisch.

PKCS #7 en RFC 3369: CMS of cryptografische berichtensyntaxis

PKCS #7 is vervangen door IETF RFC 3369 (Housley 2002): cryptografische berichtensyntaxis (CMS), de basis voor de S/MIME-specificatie. CMS definieert de syntaxis die wordt gebruikt om willekeurige berichtinhoud digitaal te ondertekenen, te verwerken, te authenticeren of te versleutelen. CMS beschrijft met name een encapsulatiesyntaxis voor gegevensbescherming. De syntaxis staat meerdere encapsulaties toe; één encapsulatie-envelop kan in een andere worden genest.

Op dezelfde manier kan één partij eerder ingekapselde gegevens digitaal ondertekenen. In de CMS-syntaxis kunnen willekeurige kenmerken, zoals de ondertekeningstijd, samen met de berichtinhoud worden ondertekend, en kunnen andere details, zoals tegenhandtekeningen, aan een handtekening worden gekoppeld. Een verscheidenheid aan architecturen voor certificaatgebaseerd sleutelbeheer (bijvoorbeeld die gedefinieerd door de IETF PKIX-werkgroep) wordt ondersteund in CMS.

PKCS #8: Standaard voor syntaxis van privésleutelinformatie

De veiligheid van het publieke-sleutelcryptosysteem is volledig afhankelijk van de bescherming van de privésleutels. Over het algemeen worden de privésleutels gecodeerd met een wachtwoord en opgeslagen op een opslagmedium. Het is essentieel om een standaard te hebben voor het opslaan van privésleutels, zodat deze probleemloos van het ene systeem naar het andere kunnen worden verplaatst.

PKCS #8 v1.2 beschrijft een syntaxis voor informatie over de privésleutel, inclusief een privésleutel voor sommige algoritmen voor openbare sleutels, een set kenmerken en een syntaxis voor gecodeerde informatie over de privésleutel. Een wachtwoordgebaseerd encryptiealgoritme (bijvoorbeeld een van de algoritmen beschreven in PKCS #5) kan worden gebruikt om de informatie over de privésleutel te versleutelen.

PKCS #9: Geselecteerde objectklassen en attribuuttypen

Ter ondersteuning van PKCS-gedefinieerde kenmerken (bijvoorbeeld voor het opslaan van PKCS-kenmerken in een directoryservice) in directorysystemen gebaseerd op LDAP en de X.500-protocollen, definieert PKCS #9 v2.0 twee hulpobjectklassen: pkcsEntity en naturalPerson. PKCS-kenmerken kunnen in deze twee objectklassen worden verpakt en geëxporteerd naar andere omgevingen, zoals LDAP-directorysystemen.

PKCS #9 v2.0 definieert ook enkele nieuwe attribuuttypen en matchingregels die in verschillende PKCS-standaarden kunnen worden gebruikt. Zo definieert het de attribuuttypen challengePassword en extensionRequest die gebruikt moeten worden in het attribuutveld PKCS #10, en beschrijft het enkele attribuuttypen die gebruikt moeten worden in de velden signedAttrs, unsignedAttrs, unprotectedAttrs, authAttrs en unauthAttrs van PKCS #7 (CMS).

PKCS #10: Standaard voor certificeringsaanvraagsyntaxis

PKCS #10 v1.7 specificeert de syntaxis voor certificaatverzoeken. Wanneer een entiteit een certificaat met een openbare sleutel wil verkrijgen, stelt deze een certificaatverzoek op. Dit verzoek wordt naar een certificeringsinstantie gestuurd , die het verzoek omzet in een X.509-certificaat met een openbare sleutel.

Een certificeringsinstantie voldoet aan het verzoek door de verzoekende entiteit te authenticeren en de handtekening van de entiteit te verifiëren. Als het verzoek geldig is, wordt er een X.509-certificaat samengesteld op basis van de onderscheidende naam en openbare sleutel, de naam van de uitgever en het door de certificeringsinstantie gekozen serienummer, de geldigheidsperiode en het handtekeningalgoritme.

Stel dat de certificeringsaanvraag PKCS #9-kenmerken bevat. In dat geval kan de certificeringsinstantie ook de waarden in deze kenmerken en andere bij de certificeringsinstantie bekende informatie gebruiken om X.509-certificaatuitbreidingen te construeren. PKCS #10 specificeert niet in welke vorm de certificeringsinstantie het nieuwe certificaat retourneert.

PKCS #11: Cryptografische Token Interface Standaard

PKCS #11 v2.20 specificeert een application programming interface (API), genaamd "Cryptoki", voor apparaten die cryptografische informatie bevatten en cryptografische functies uitvoeren. Cryptoki, uitgesproken als "crypto-key" en een afkorting voor "cryptographic token interface", volgt een eenvoudige objectgebaseerde aanpak die technologieonafhankelijkheid (elk apparaat) en resource sharing (meerdere applicaties die toegang hebben tot meerdere apparaten) nastreeft, door applicaties een standaard, logische weergave van het apparaat te bieden, een zogenaamde "cryptographic token".

Cryptoki was vanaf het begin bedoeld als een interface tussen applicaties en allerlei draagbare cryptografische apparaten, zoals die gebaseerd op smartcards, PCMCIA-kaarten en intelligente diskettes. Het primaire doel van Cryptoki was een programmeerinterface op een lager niveau die de details van de apparaten abstraheert en de applicatie een standaardmodel van het cryptografische apparaat presenteert, een zogenaamde "cryptografisch token".

PKCS #12: Standaard voor de uitwisseling van persoonlijke informatiesyntaxis

PKCS #12 v1.0 beschrijft een overdrachtssyntaxis voor persoonlijke identiteitsgegevens, inclusief privésleutels, certificaten, diverse geheimen en extensies. Machines, applicaties, browsers, internetkiosken, enzovoort, die deze standaard ondersteunen, stellen gebruikers in staat om één set persoonlijke identiteitsgegevens te importeren, exporteren en gebruiken. PKCS #12 kan worden gezien als een voortzetting op PKCS #8 door essentiële maar aanvullende identiteitsgegevens en privésleutels op te nemen en een hogere beveiliging in te stellen via privacy- en integriteitsmodi voor openbare sleutels.

PKCS #15: Cryptografische tokeninformatie-syntaxisstandaard

Cryptografische tokens, zoals geïntegreerde schakelingen (of IC-kaarten), zijn van nature veilige computerplatformen die bij uitstek geschikt zijn om applicaties te voorzien van verbeterde beveiligings- en privacyfunctionaliteit. Ze kunnen authenticatiegegevens verwerken, zoals digitale certificaten en mogelijkheden, autorisaties en cryptografische sleutels.

Bovendien kunnen ze veilige opslag- en rekenfaciliteiten bieden voor gevoelige informatie, zoals privésleutels en sleutelfragmenten. Tegelijkertijd bieden veel van deze tokens een geïsoleerde verwerkingsfaciliteit die deze informatie kan gebruiken zonder deze bloot te stellen aan de hostomgeving, waar deze mogelijk kwetsbaar is voor schadelijke code (virussen, Trojaanse paarden, enzovoort). Helaas wordt het gebruik van deze tokens voor authenticatie- en autorisatiedoeleinden belemmerd door het gebrek aan interoperabiliteit.

Ten eerste ontbreken er in de sector standaarden voor het opslaan van een gemeenschappelijk formaat van digitale gegevensdragers (sleutels, certificaten, enz.). Dit maakt het moeilijk om applicaties te ontwikkelen die met gegevensdragers van verschillende technologieleveranciers kunnen werken. Ten tweede zijn de mechanismen om meerdere applicaties in staat te stellen digitale gegevensdragers effectief te delen, nog niet volwassen.