Aandachtspunten PKIoverheid Tips en aanbevelingen bij PKIoverheid-certificaten en PKI-enabled applicaties Auteur GBO.overheid / PKIoverheid Versie Versie 1.0 Status Definitief Den Haag, 18 oktober 2007 1/15
Inhoud 1. Inleiding... 3 2. Overzicht van aandachtspunten... 4 2.1 PKI-componenten... 5 2.2 PKI-middleware... 7 2.3 s... 8 2.4 Valideren... 13 2.4 Langdurig bewaren... 15 GBO.Overheid bouwt mee aan de e-overheid Wilhelmina van Pruisenweg 104 2595 AN Den Haag Postbus 84011 2508 AA Den Haag T 070 888 76 66 F 070 888 78 82 www.gbo.overheid.nl
Inleiding Een organisatie die PKIoverheid certificaten wil gaan gebruiken en/of PKI-enabled applicaties wil aanschaffen of (laten) ontwikkelen moet rekening houden met bestaande afspraken en standaarden. Een CSP geeft certificaten uit. De organisatie is vervolgens zelf verantwoordelijk voor het juiste gebruik van certificaten, middelen en PKI-enabled applicaties. De wijze waarop de organisatie hiermee omgaat kan effect hebben op de betrouwbaarheid, de interoperabiliteit en het gebruiksgemak. Hoofdstuk 2 van dit document bevat het overzicht van aandachtspunten voor organisaties en proceseigenaren bij gebruik van PKIoverheid-certificaten. 3/15
Overzicht van aandachtspunten De betrouwbaarheid van PKIoverheid is niet alleen gebaseerd op zorgvuldige uitgifte van certificaten door de CSP s, maar ook op de juiste werking van applicaties en het correct gebruik van certificaten. Aan deze aspecten zijn binnen PKIoverheid geen eisen gesteld. Om het juiste gebruik van certificaten mogelijk te maken zijn diverse aandachtspunten geformuleerd. Deze aandachtspunten zijn bedoeld voor overheidsorganisaties, proceseigenaren die PKIoverheid-certificaten en/ of PKI-enabled applicaties willen (gaan) gebruiken. De aandachtspunten hebben betrekking op enkele specifieke onderdelen, zoals PKI-hardware (smartcard met kaartlezer, het usb-token), de PKImiddleware en de PKI-enabled applicatie. Een bijzondere functie van een PKIapplicatie is de validatie. Het langdurig bewaren (archiveren) is een apart punt van aandacht. De volgende paragrafen bevatten het overzicht van de aandachtspunten. Deze punten zijn ingedeeld in de volgende categorieën: PKI-componenten PKI-middleware Valideren Langdurig bewaren Bij elk aandachtspunt is een korte beschrijving gegeven. Daar waar van toepassing zijn geldende afspraken of standaarden vermeld. Bij een aandachtspunt is tevens aangegeven welk PKI-element een rol speelt. PKI-elementen in dit verband zijn: Smartcard Usb-token PIN-code Kaartlezer PKI-middleware 4/15
2.1 PKI-componenten PKI-element 1 Levensduur PKI-componenten De PKI-componenten smartcard, usb-token en kaartlezer dienen, gezien de levensduur van de certificaten, een technische levensduur van minimaal 5 jaar te hebben. 2 Ondersteuning cryptografische algoritmes De chip (op smartcard, in usb-token) dient tenminste ondersteuning te bieden aan de RSA, SHA-1 en SHA-2 cryptografische algoritmes. Smartcard USB-token Kaartlezer Smartcard USB-token Deel 3 PvE (hoofdstuk 6) ETSI 101 456 ETSI TS 102 176-1 RFC 3647 Deel 3 PvE (hoofdstuk 6) 3 Interface en vorm smartcard is een smartcard voorzien als gebruikerstoken. Dit impliceert een ID-1 vormfactor. De gangbare ISO 7816 standaarden voor plaatsing van de contacten en elektrische interface moeten worden gevolgd en de volledige lay-out (interface en file) van de kaart dient te voldoen aan PKCS#15. 4 Communicatie protocollen De chip op de smartcard of in het usb-token moet de T=0 en T=1 communicatie protocollen ondersteunen. 5 Voedingsspanning De kaartlezer dan wel het usb-token moet kunnen functioneren met een voedingsspanning van 1,8V, 3V en 5V. 6 Geheugenruimte op smartcard De chip (op smartcard, in usb-sleutel) dient tenminste ruimte te bieden aan drie sleutelparen van tenminste 1024 bits met bijbehorende certificaten en drie bovenliggende CA-certificaten uit de hiërarchie van de PKI voor de overheid. (Als de CSP gebruik maakt van meerdere tussenliggende sub-ca s dan moet rekening worden gehouden met een groter benodigd geheugen.) Smartcard ISO 7816 (delen 1 tot en met 8 en deel 15) Kaartlezer Kaartlezer USB-token Smartcard USB-token ISO 10373 ETSI TS 102 176-1 Deel 3 PvE 5/15
PKI-element 7 Interoperabiliteit randapparatuur en smartcard Het is van belang dat een kaartlezer niet gebonden is aan één applicatie of één specifieke smartcard. De randapparatuur dient gebruik te kunnen maken van de functies van de chip. Er dient geen exclusieve binding te zijn aan één leverancier. 8 Veilige PIN-entry Kaartlezers dienen in een onveilig geachte omgeving, zoals in een publiek toegankelijke omgeving, tenminste een veilige user authenticatie (bijvoorbeeld via PIN-entry) en veilige communicatie met de smartcard (trusted path) te bieden. De PINcode mag niet af te leiden zijn aan de hand van de communicatie tussen de lezer en de PC. Tevens dienen replay attacks onmogelijk te zijn. Een mogelijkheid hiertoe is het gebruiken van een kaartlezer met een eigen pin-pad om de PIN-code in te voeren. Smarctard Kaartlezer PIN-code Kaartlezer 6/15
2.2 PKI-middleware PKI-element 9 Ondersteuning certificaten Een dient het juiste certificaat te hanteren voor de elektronische communicatie (vertrouwelijkheid, authenticiteit en elektronische handtekening). De middleware dient ook de 3 persoonsgebonden certificaten (vertrouwelijkheid, authenticiteit en elektronische handtekening) te ondersteunen en mag deze optie voor de applicatie niet blokkeren. 10 Certificaat extensies De client software dient te kunnen werken met certificaat extensies conform X.509 v3. Middleware Middleware Deel 1 & 3 PvE RFC3280 11 Cryptografische bibliotheken De door de PKI-middleware gebruikte drivers en cryptografische bibliotheken dienen in ieder geval de toegestane cryptografische algoritmes uit ETSI TS 102 176 te bieden. 12 Interoperabiliteit middleware De middleware moet de interface bieden tussen de PKI-enabled applicaties, de cryptografische bewerkingen, de gebruikte randapparatuur (drivers) en smartcards of usb-tokens. Om interoperabiliteit te waarborgen dient aan de volgende voorwaarden te worden voldaan: - De middleware dient ten minste een PKCS#11 v2.01 bibliotheek aan te bieden en een CryptoAPI CSP voor MS Windows platforms. - De middleware dient de voor het PC platform gebruikelijke (industrie) cryptografische API's te ondersteunen (zoals bijvoorbeeld gebruikt door de gangbare e-mail pakketten en web-browsers als Microsoft, Netscape en Lotus). Middleware ETSI TS 102 176 Deel 3 PvE (Sectie 6) Middleware Smartcard USB-token 7/15
2.3 s PKI-element 13 Ondersteuning certificaatprofielen De PKI-enabled applicaties moeten ondersteuning bieden aan de verschillende certificaatprofielen die binnen de PKI voor de overheid worden gebruikt. In het bijzonder geldt dat de e-mail client dient om te kunnen gaan met certificaten waarin geen e-mail adres is opgenomen. (Een koppeling aan een e-mail adres is ongewenst aangezien dit leidt tot een certificaat per e-mail adres.) 14 Ondersteuning activeringsgegevens/pin-code De PKI-enabled applicaties moeten ondersteuning bieden aan de optie om per certificaat een andere PIN-code (of andere vormen van activatiegegevens) te gebruiken. PIN-code Deel 3 PvE 15 Onderscheid certificaten De PKI-enabled applicaties, middleware, smartcard en usb-token moeten ondersteuning bieden voor het zogenaamde 3-sleutelpaar principe. Elk sleutelpaar met bijbehorend certificaat heeft zijn functie. Applicaties dienen automatisch de juiste sleutel te selecteren die voor een bepaalde functie geschikt is op grond van het KeyUsage-veld in het certificaat. Gebruikersinterventie of configuratie is alleen nodig als er meer certificaten zijn die dezelfde functie ondersteunen. 16 Ondersteuning Certification Revocation List De PKI-enabled applicaties moeten ondersteuning bieden aan de Certification Revocation List (CRL) op basis van X.509 versie 2. Middleware Smartcard USB-token Deel 1 PvE Deel 3 PvE 8/15
PKI-element 17 Meervoudig ondertekenen / multiple signing Een moet de mogelijkheid bieden een document meer dan één keer te ondertekenen. Meerdere personen kunnen hun elektronische handtekening zetten onder eenzelfde document. De ontvanger van het document moet kunnen zien welke personen het document hebben ondertekend. 18 Clear signing / leesbaarheid na ondertekening Bij het plaatsen van de elektronische handtekening dient (de tekst van) het document in de oorspronkelijke vorm te blijven. De handtekening wordt als bijlage aan het document toegevoegd, zodat de oorspronkelijke gegevens leesbaar zijn voor applicaties die geen PKI ondersteunen. 19 Client/Server authenticatie Een dient op PKI gebaseerde clientauthenticatie en server-authenticatie te ondersteunen (bijvoorbeeld op basis van SSL versie 2.0, TLS, RADIUS, IPSec etc.). Voor online verbindingen is interoperabiliteit met de standaarden SSL versie 2.0 en hoger en TLS nodig. 20 Meesturen vertrouwelijkheidcertificaat Bij het verzenden van een vercijferde gegevens moet het mogelijk zijn om het vertrouwelijkheidcertificaat van de afzender mee te zenden. (De ontvanger kan dan een vercijferd antwoord verzenden.) 21 Meervoudig vercijferen Het moet mogelijk zijn om in één handeling dezelfde data (bijvoorbeeld een emailbericht) voor meerdere personen tegelijk te vercijferen. Als van één of enkele van de geadresseerden geen vertrouwelijkheidcertificaat bekend is, dient hierover een melding te verschijnen. Vervolgens blijft de keuze over om óf alleen vercijferd te verzenden aan de certificaathouders, óf om onvercijferd te verzenden aan alle geadresseerden. 9/15
PKI-element 22 XML-representatie Indien gebruik wordt gemaakt van een op XML gebaseerde representatie van certificaten, is het gebruik van de volgende standaarden verplicht: - XadES voor het handtekeningcertificaat; - XML Sig voor het authenticiteitcertificaat; - XML Encryption voor het vertrouwelijkheidcertificaat. 23 Cryptografische algoritmes De s moeten met gestandaardiseerde cryptografische algoritmes werken. Dit betreft zowel asymmetrische cryptografie (elektronische handtekening, authenticiteit en ondersteunende berekeningen) als symmetrische cryptografie (vercijfering). XadES XML Sig XML Encryption ETSI TS 102 176-1 Deel 3 PvE (hoofdstuk 6) 24 Interoperabiliteit Interoperabiliteit met de volgende standaarden is gewenst: - S/MIME standaarden; RFC 2630, RFC 2632 en RFC 2633 - PKCS#7; - PKCS#11; - PKCS#12 (server certificaten). 25 WYSIWYS Een gebruiker die een handtekening gaat zetten moet er op kunnen vertrouwen dat uitsluitend de zichtbare informatie - en niet meer of minder - wordt ondertekend. De applicatie toont de zichtbare informatie op het beeldscherm. Dit principe staat ook bekend als What-You-See-Is-What-You-Sign (WYSIWYS). PKIapplicatie RFC 1521 (MIME) RFC 2630 (cryptographic message syntax) RFC 2632 (certificate handling) RFC 2633 (message specification). 10/15
PKI-element 26 Meldingen ingeven PIN-code Bij het plaatsen van een elektronische handtekening moet gebruiker de PIN-code invoeren. De PKIapplicatie moet met duidelijke, relevante meldingen in het Nederlands aangeven dat de PIN-code nodig is voor een handtekening of dat de code bedoeld is voor een andere functie, zoals authenticatie. Het weigeren of foutief invoeren van de PIN-code moet uiteraard leiden tot het afbreken van de PKI-functie. 27 Weergave detailinformatie De dient de mogelijkheid te bieden om relevante achtergrondinformatie te raadplegen en de daarin opgenomen verwijzingen te volgen. Met een eenvoudige handeling, bijvoorbeeld het klikken op een indicator, dient detailinformatie over het kenmerk en inhoud van het certificaat beschikbaar te komen. Daarbij dienen minimaal de volgende gegevens te worden weergegeven: naam van de ondertekenaar uit het certificaat; indien aanwezig, de naam van de organisatie van de ondertekenaar uit het certificaat; naam van de uitgever van het certificaat (CSP); certificatenhiërarchie tot aan het stamcertificaat; begin en einde van de geldigheid van het certificaat; resultaat van de validatie van het kenmerk (de hashwaarde); melding in geval van problemen tijdens de validatie. PKIapplicatie PIN-code PKIapplicatie 11/15
PKI-element 28 Off line bewerkingen Applicaties moeten zo veel mogelijk ondersteuning bieden aan off line bewerkingen (bijvoorbeeld e-mail en aanloggen op laptop). Daarvoor dient de applicatie de certificaten en CRL s lokaal op te slaan en een duidelijke melding te geven als een lokaal opgeslagen CRL is verlopen en een nieuwere CRL kan worden opgehaald. PKIapplicaties 12/15
2.4 Valideren PKI-element 29 Controle tijdstempel Indien een tijdstempel (Time Stamping) is gezet over een bericht, moet de bij validatie dit tijdstempel kunnen controleren. Het tijdstip dat in het tijdstempel is opgenomen is het uitgangspunt bij CRL-controle tijdens het valideren van de elektronische handtekening of het authenticiteitskenmerk. ETSI TS 101 861 Timestamping profile Met een tijdstempel kan een betrouwbare tijd worden toegevoegd aan het bericht. Om betrouwbaarheid te garanderen kan het tijdstempel gezet worden door een Trusted Third Party (Time Stamping Authority of TSA). 30 authenticiteitskenmerk en elektronische handtekening Een moet de mogelijkheid bieden om het authenticiteitskenmerk dan wel de elektronische handtekening te controleren. De validatie dient te bestaan uit: - validatie van de certificaten die zijn gebruikt bij het authenticeren dan wel bij het aanmaken van de handtekening; - controle op de juistheid van het kenmerk van authenticatie dan wel handtekening (= controle integriteit en controle relatie met het bijbehorende document dan wel de aangeleverde gegevens). 13/15
PKI-element 31 certificaat De moet het (eindgebruiker-) certificaat valideren. Bij validatie van een certificaat dient de gehele certificatenhiërarchie te worden doorlopen en elk tussenliggend certificaat en stamcertificaat PKIoverheid te worden gevalideerd. De validatie omvat zowel controle op geldigheidstermijn als controle op intrekking van het certificaat via CRL of via het Online Certificate Status Protocol (OCSP). Uitzonderingen: voor het stamcertificaat wordt geen CRL uitgegeven; in het stamcertificaat, de domeincertificaten en de CSP-certificaten is geen OCSP-verwijzing is opgenomen. 32 via CRL Een moet bij controle van een certificaat de CRL s kunnen ophalen met behulp van LDAP of met http. De applicatie dient hiervoor de in het certificaat opgenomen locatie (URL) van de CRL te gebruiken. Na het verstrijken van de vervaldatum van de CRL moet automatisch een nieuwe CRL worden opgehaald. Indien de CRL niet beschikbaar is dient dit aan de gebruiker te worden gemeld. Binnen de PKI voor de Overheid is er geen centrale locatie waar alle CRL s beschikbaar worden gesteld. RFC3280 (hoofdstuk 6) Deel 3 PvE (4.5) Deel 3 PvE (4.5) 14/15
2.4 Langdurig bewaren PKI-element 33 Lokaal opslaan van bericht Een dient de gebruiker de mogelijkheid te bieden om een ondertekende kopie van een bericht lokaal te bewaren. 34 Onvercijferd opslaan Het moet mogelijk zijn om ontvangen vercijferde berichten onvercijferd op te slaan. Hiermee worden eventuele problemen bij het ontcijferen van berichten in het geval van verlies van sleutels voorkomen. 35 Opslag kenmerken (handtekening / authenticatie) en certificaten Om op een later tijdstip nog te kunnen controleren of de elektronische handtekening geldig is moeten de noodzakelijke certificaten worden gearchiveerd. Ontvangers moeten de mogelijkheid hebben om ontvangen certificaten (de hiërarchie) op te slaan en de elektronische handtekening van het document op te slaan samen met het document zelf. Deze elementen kunnen op een later tijdstip worden gebruikt om de integriteit van het document vast te stellen en de gegevens van de ondertekenaar te achterhalen. Omdat validatie van het certificaat in de toekomst niet meer mogelijk is, is het van belang ook de uitslag van validatie van het geldige certificaat vast te leggen. 15/15