Toelichting SHA-2 Release Zorg CSP (UZI-register en ZOVAR)

Toelichting SHA-2 Release Zorg CSP (UZI-register en ZOVAR)

Versie 1.0

Datum Status

26 november 2010 definitief

CIBG | Toelichting SHA-2 release Zorg CSP (UZI-register en ZOVAR) | versie 1.0 | 26 november 2010

Inhoud 1 1.1 1.2 1.3 2 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 certificaten 2.2.3 2.2.4 2.2.5

Inleiding—4 Doelstelling—4 Disclaimer—4 Versie historie—4 Inhoudelijke wijzigingen in SHA-2 release—5 Achtergrond en noodzaak voor de release—5 Ondertekening certificaten—5 Risico’s in het gebruikte SHA-1 hashing algoritme—6 Planning en tijdspad—6 Toelichting wijzigingen—6 Nieuwe Staat der Nederlanden Root CA en CA hiërarchie—6 Gebruik van ‘SHA256 with RSA Encryption’ als het signing algorithm voor alle en CRL’s.—7 Aanpassing RSA sleutellengte—8 Geldigheidsduur CA certificaten—8 SHA-256 support bij gebruik van UZI-pas (update SafeSign middleware)—8

3 Impact analyse—9 3.1 Inleiding—9 3.2 Impact voor zorgaanbieders—9 3.3 Impact ketenpartners (LSP, SBV-Z)—10 3.3.1 Pashouders en GBZ-en gaan SHA-2 certificaten gebruiken—10 3.3.2 Introductie SHA-2 certificaten op centrale voorzieningen—10 3.4 Ondersteuning SHA-256 in operating systeem en/of applicatie—10 3.4.1 Toelichting verschillende niveaus SHA-2 support—10 3.4.2 Ondersteuning SHA-256 in Microsoft Windows XP—12 3.4.3 Ondersteuning SHA-256 in Microsoft Windows Vista—12 3.4.4 Ondersteuning SHA-256 in Mac OS X—13 3.4.5 Ondersteuning SHA-256 in Linux—14 3.4.6 Ondersteuning SHA-256 in Windows 2003 server—14 3.4.7 Ondersteuning SHA-256 in Windows 2008—17 3.4.8 Support in standaardapplicaties—17 3.5 Impact voor XIS leveranciers (FAQ)—17 3.5.1 Ondersteunt de nieuwe ‘SHA-2 pas’ nog steeds ‘SHA-1 with RSA’ encryption?—17 3.5.2 Blijven bestaande XIS applicaties dus gewoon werken?—18 3.5.3 Wat is het effect van de langere sleutellengten?—18 3.5.4 Wat moet een software ontwikkelaar doen om de SHA-256 functionaliteit van de middleware te gebruiken?—18 3.5.5 Is SHA-256 ook te gebruiken met Microsoft Crypto API?—20 3.5.6 Is het mogelijk om SHA-256 te gebruiken voor een Elektronische handtekening met een G1 of G2 UZI-pas?—20

Pagina 2 van 20


Lijst met figuren Figuur 1: Huidige ondertekeningsalgoritme in certificaten UZI-register 5 Figuur 2: Illustratie stap 1: berekening hash-waarde 5 Figuur 3: Illustratie stap 2: RSA ‘encryptie’ van de hash-waarde 5 Figuur 4: CA model productieomgeving SHA-2 generatie (G21) 7 Figuur 5: Illustratie keuze hashing algoritme binnen MS-Outlook applicatie 11 Figuur 6: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Windows XP met SP3 12 Figuur 7: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Windows Vista 13 Figuur 8: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Mac OS X sleutelhanger 13 Figuur 9: Correcte weergave SHA-2 algoritme in FireFox op Mac OS X 13 Figuur 10: Foutmelding op Windows 2003 server systeem zonder SHA-256 support 14 Figuur 11: FireFox SHA-256 support op Windows 2003 server systeem 16

Lijst met tabellen Tabel 1: RSA sleutellengte in SHA-2 generatie (G21) 8 Tabel 2: Levensduur certificaten SHA-2 generatie (G21) 8

Copyright CIBG © te Den Haag Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden) door middel van druk, fotokopie, microfilm, geluidsband, elektronisch of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van CIBG.

Pagina 3 van 20


1

Inleiding

1.1

Doelstelling Dit document geeft een inhoudelijke toelichting bij de SHA-2 release van de Zorg CSP1 die gepland is in 2009/2010. Een belangrijk doel is een eerste analyse van de impact voor partijen die certificaten van de Zorg CSP gebruiken of vertrouwen. De doelgroep van dit document zijn ICT projectleiders, specialisten en programmeurs van zowel zorgaanbieders als XIS-leveranciers. Om de invoering van SHA-2 in het zorgveld optimaal te ondersteunen is een aparte ‘landingspagina’ gemaakt op de website met praktische informatie. Zie www.uziregister.nl/sha2

1.2

Disclaimer Bij het opstellen van deze versie was nog geen praktische test mogelijk met SHA-2 UZI-passen of servercertificaten. Wel zijn testen uitgevoerd met het nieuwe Root CA certificaat. Zodra er meer of specifiekere informatie is, zal er een update van dit document komen.

1.3

Versie historie Versie

Datum

Status

0.2

26 sep. 2008

Concept

Toevoegingen en wijzigingen Eerste extern gepubliceerde versie op basis van analyse en beperkte testen met het nieuwe Root CA certificaat.

0.3

6 okt. 2008

Concept

1.0

26 nov. 2010

Definitief

1

Inhoudelijke wijzigingen: • Update met hotfix voor Windows 2003; • Opmerking OCSP signer certificaten (par. 2.2.2); Wijzigingen: • Voorblad in rijksbrede overheidshuisstijl; • Par. 1.1 link naar SHA-2 landingspagina;

De ‘Zorg CSP’ omvat zowel het UZI-register (doelgroep zorgverleners) als ZOVAR (doelgroep zorgverzekeraars). In het kader van deze release zijn alle wijzigingen en consequenties voor UZI-register servercertificaten en ZOVAR servercertificaten gelijk tenzij expliciet anders is vermeld. Pagina 4 van 20


2

Inhoudelijke wijzigingen in SHA-2 release

2.1

Achtergrond en noodzaak voor de release

2.1.1

Ondertekening certificaten Het UZI-register ondertekent momenteel de uitgegeven certificaten met een combinatie van het RSA en SHA-1 algoritme: ‘SHA-1 with RSA Encryption’. Figuur 1 laat zien hoe dit in de Microsoft viewer zichtbaar is.

Figuur 1: Huidige ondertekeningsalgoritme in certificaten UZI-register Het proces van ondertekenen vindt plaats in 2 stappen. Allereerst berekent de CA de hash-waarde van de certificaatgegevens. Een hash-functie berekent bij een willekeurig bestand een unieke code -ook wel hash, digest, fingerprint genoemdmet een vaste lengte. Voor SHA-1 is de lengte van de hash-waarde 160 bits. Het doel hiervan is het realiseren van ‘integriteit’, dat wil zeggen dat iedere wijziging in het originele bestand direct leidt tot een compleet verschillende hash-waarde.

Figuur 2: Illustratie stap 1: berekening hash-waarde De tweede stap van de handtekening is het ‘encrypten’ van de hash-waarde met de private RSA key. Bij een certificaat is dat de private key van de CA die het certificaat ondertekent.

Figuur 3: Illustratie stap 2: RSA ‘encryptie’ van de hash-waarde

Pagina 5 van 20


De lengte van de handtekening hangt af van de RSA sleutellengte en heeft dus ook een vaste lengte. 2.1.2

Risico’s in het gebruikte SHA-1 hashing algoritme Het gebruikte hash algoritme SHA-1 is een standaard van het Amerikaanse NIST2. SHA-1 blijkt echter minder veilig dan bij de introductie werd gedacht. Chinese cryptografen hebben aangetoond dat het makkelijker is dan voorheen gedacht om zogenaamde “collisions” te vinden. Een “collision” is een dreiging voor hash algoritmen en houdt in dat twee bestanden kunnen worden gevormd die dezelfde hash-waarde opleveren. Dit houdt in dat (theoretisch) de inhoud van een ondertekend bericht of certificaat gewijzigd zou kunnen worden terwijl de handtekening onder het bericht blijft kloppen. Er zijn nog geen collisions voor SHA-1 gevonden, maar de theoretische sterkte van het algoritme is kleiner dan tot nu toe gedacht. Er moet rekening gehouden worden dat de komende jaren nieuwe doorbraken zullen zijn. Daarom heeft NIST vier nieuwe, sterkere algoritmen tot standaard verheven als opvolger van SHA-1: SHA224, SHA-256, SHA-384 en SHA-512. Deze worden ook wel gevat onder de verzamelnaam SHA-2.

2.1.3

Planning en tijdspad Bovenstaande bedreiging heeft ertoe geleid dat PKI voor de overheid -in navolging van internationale instanties- een overgang naar het SHA-256 algoritme in gang heeft gezet. De huidige planning is dat er na 2010 geen certificaten meer uitgegeven worden waarbij SHA-1 is gebruikt als onderdeel van de ondertekening. De detailplanning van de release zal afzonderlijk gecommuniceerd worden en hangt af van de impactanalyses die de leveranciers van CIBG momenteel uitvoeren.

2.2

Toelichting wijzigingen Deze paragraaf specificeert de wijzigingen die onderdeel zijn van de SHA-2 release.

2.2.1

Nieuwe Staat der Nederlanden Root CA en CA hiërarchie Met de SHA-256 release wordt er een complete nieuwe CA hiërarchie gecreëerd naast de bestaande eerste en tweede generatie CA’s. Figuur 4 geeft het CA model weer voor de productieomgeving van de Zorg CSP die onder de nieuwe Staat der Nederlanden Root CA – G2 valt. Het belangrijkste kenmerk van de nieuwe hiërarchie is het gebruik van het SHA-256 hashing algoritme bij de ondertekening van de certificaten.

2

National Institute of Standards and Technology, FIPS PUB 180-1, Secure Hash Standard. Pagina 6 van 20


Figuur 4: CA model productieomgeving SHA-2 generatie (G21) Toelichting • De naamgeving van de SHA-2 generatie is weergegeven in Figuur 4 die de subject.commonName bevat van de CA certificaten. Voor PKI-overheid is dit de tweede generatie root en domein CA (G2). Om verwarring te voorkomen is besloten de Zorg CSP een versienummer te geven dat zoveel mogelijk gelijk loopt met root en domein CA. Aangezien G2 al gebruikt wordt, is gekozen voor G21. • De G1 en G2 hiërarchie zijn verkleind weergegeven en zullen uitfaseren. De G1 hiërarchie produceert nu alleen nog CRL’s en zal in december 2010 definitief uitfaseren omdat de geldigheidsduur dan verloopt. 2.2.2

Gebruik van ‘SHA256 with RSA Encryption’ als het signing algorithm voor alle certificaten en CRL’s. In alle certificaten die de Zorg CSP uitgeeft en in de CA hiërarchie zal ondertekening van certificaten plaatsvinden op basis van SHA-256 hashing in combinatie met het RSA algoritme. Dit geldt ook voor de ondertekening van CRL’s. Het algoritme is als volgt gespecificeerd (RFC 4055, Additional RSA Algorithms and Identifiers): OBJECT IDENTIFIER '1 2 840 113549 1 1 11' {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) sha256WithRSAEncryption(11)}

In het certificaat staat deze Object Identifier (OID) twee keer: Certificate.signatureAlgorithm tbsCertificate.signature

1.2.840.113549.1.1.11 1.2.840.113549.1.1.11

Opmerkingen • Het SHA-1 algoritme wordt conform de geldende standaarden (RFC 5280) nog wel gebruikt voor berekening van de zogenaamde key-identifiers in de certificaten. Dit zijn hashes van bijvoorbeeld de public key in het certificaat en

Pagina 7 van 20


•

2.2.3

zijn bedoeld als een soort thumbprint die het vergelijken van sleutels vereenvoudigt. Dit levert geen beveiligingsrisico op. Ook OCSP responses zijn ondertekend door de OCSP responder. Momenteel is ‘SHA-1 with RSA Encryption’ het gebruikte algoritme. Dit zal naar verwachting zo blijven omdat het OCSP protocol zelf nog niet is geupdate voor het gebruik van SHA-256. Waarschijnlijk zal ook het OCSP signer certificaat ondertekend zijn op basis van ‘SHA256 with RSA Encryption’.

Aanpassing RSA sleutellengte Naast aanpassing van het hashing algoritme zijn ook de RSA sleutellengtes vergroot om gedurende de geldigheidsduur van de hiërarchie bestand te zijn tegen cryptografische aanvallen. Certificaat Stamcertificaat Domeincertificaat CSP certificaat sub-CA certificaat Eindgebruikercertificaat

RSA sleutellengte (bits) 4096 4096 4096 4096 2048

Tabel 1: RSA sleutellengte in SHA-2 generatie (G21) 2.2.4

Geldigheidsduur CA certificaten De onderstaande tabel geeft een overzicht van de geldigheidsduur van de SHA-2 hiërarchie. Dit is een afweging tussen de verwachtte cryptografische ontwikkelingen en de wens om het aantal vernieuwingen van de hiërarchie te minimaliseren. Certificaat Stamcertificaat Domeincertificaat CSP certificaat sub-CA certificaat Eindgebruikercertificaat

Geldig tot 25-3-2020 24-3-2020 23-3-20203 22-3-20203 Ongewijzigd: 3 jaar

Tabel 2: Levensduur certificaten SHA-2 generatie (G21) 2.2.5

SHA-256 support bij gebruik van UZI-pas (update SafeSign middleware) Minimale vereiste voor gebruik van een SHA-2 UZI-pas is een update van de SafeSign middleware. Los van de handtekeningen onder certificaten wordt het ook mogelijk om SHA-256 te gebruiken bij het gebruik van de UZI-pas voor het plaatsen van handtekeningen. Dit is met name van belang voor XIS-leveranciers en is in meer detail uitgewerkt in paragraaf 3.5.

3

Dit is nagenoeg zeker maar dient formeel nog bevestigd te worden door PKI overheid. Pagina 8 van 20


3

Impact analyse

3.1

Inleiding De impact van de SHA-2 release hangt sterk af van de toepassing en is in dit hoofdstuk nader toegelicht. Hierbij zijn de volgende onderwerpen onderkend: • Impact voor zorgaanbieders. Dit geeft globaal de stappen aan die vereist zijn. • Impact voor ketenpartners (LSP en SBV-Z). Hier gaat het om de impact op de centrale voorzieningen binnen AORTA. • Vereiste ondersteuning van SHA-256 in operating systeem of applicatie. Dit is een algemeen punt: ieder systeem of applicatie die een certificaat of CRL van het UZI-register verifieert, moet het SHA-256 algoritme ondersteunen. • Impact voor XIS-leveranciers. Hierbij is nader ingegaan op het geschikt maken van XIS applicaties.

3.2

Impact voor zorgaanbieders Voor een zorgaanbieder gelden de volgende aandachtspunten bij het geschikt maken van de ICT omgeving voor de SHA-2 release: • Randvoorwaarde voor gebruik van de SHA-2 UZI-passen/servercertificaten binnen AORTA is uiteraard dat de centrale voorzieningen al aangepast zijn. • Er dient SHA-256 support te zijn in de operating systemen en/of applicaties voor het valideren van certificaten en CRL’s. Dit is inhoudelijk verder toegelicht in paragraaf 3.4. • De XIS applicatie dient geschikt te zijn. Dit is inhoudelijk verder toegelicht in paragraaf 3.5. Uitvoering hiervan ligt bij de leverancier van de XIS applicatie. • Distributie van nieuwe root CA certificaat. PKI overheid is een traject gestart om het nieuwe Root CA certificaat te distribueren via dezelfde kanalen als het huidige Root CA certificaat. Dit betekent dat het nieuwe root CA certificaat minimaal beschikbaar komt via: 1 Het Microsoft trusted root CA program. In dat geval wordt het nieuwe root CA certificaat verspreid via Windows update. Mocht een gebruiker bijvoorbeeld op een website komen die beveiligd is met een ‘SHA-2’ servercertificaat dan wordt het nieuwe root CA certificaat automatisch opgehaald. 2 Mozilla. Bij installatie van bijvoorbeeld FireFox zal automatisch het nieuwe Root CA certificaat meegenomen worden. 3 MacOS X. 4 Opera browser. • Distributie van de nieuwe CA hiërarchie voor de diverse pastypen. Dit betreft een vergelijkbare actie als bij de vernieuwing van het CSP CA certificaat. • Samen met de SHA-2 release zal er een nieuwe SafeSign versie komen. Deze zal op alle werkplekken geïnstalleerd moeten worden waar men de nieuwe passen gaat gebruiken. LET OP! Ook buiten uw organisatie kan de introductie van de SHA-2 release impact hebben. Hieronder zijn twee voorbeelden uitgewerkt. Servercertificaten. Indien u een servercertificaat uit de SHA-2 generatie installeert op uw portal/website met de bijbehorende hiërarchie zal iedereen die uw site bezoekt in staat moeten zijn om de handtekeningen onder de certificaten te controleren.

Pagina 9 van 20


Secure email. Als u een e-mail ondertekent met een UZI-pas uit de SHA-2 generatie zal de ontvangende partij een systeem en/of email pakket moeten hebben dat in staat is om de handtekeningen onder de certificaten te controleren. 3.3

Impact ketenpartners (LSP, SBV-Z)

3.3.1

Pashouders en GBZ-en gaan SHA-2 certificaten gebruiken Vanaf het moment dat er UZI-passen gebruikt worden door zorgverleners of dat GBZ-en een servercertificaat kunnen hebben uit de SHA-2 hiërarchie moeten de centrale LSP en SBV-Z systemen in staat zijn om deze certificaten te controleren. Dit betekent concreet dat op de centrale systemen het volgende uitgevoerd moet zijn: • Realiseren van SHA-2 support in applicatie en/of operating systeem. • Installatie van het nieuwe root CA certificaat. • Installatie van CA hiërarchie van de pastypen die men wil vertrouwen. Dit betreft een vergelijkbare actie als bij de vernieuwing van het CSP CA certificaat. Vergelijkbaar met de eerste en tweede generatie is het de verwachting dat de SHA2 hiërarchie niet conflicteert met reeds aanwezige CA certificaten in de ‘certificate store’. G1 en G2 UZI-passen en servercertificaten kunnen nog gewoon gebruikt worden en zullen vanzelf uitfaseren.

3.3.2

Introductie SHA-2 certificaten op centrale voorzieningen Het volgende punt is formeel geen onderdeel van de SHA-2 release van de Zorg CSP maar is hier voor de volledigheid opgenomen. De servercertificaten van LSP en SBVZ zijn niet uitgegeven door de Zorg CSP maar vallen wel onder de PKI voor de overheid. Dat betekent dat op de centrale systemen op enig moment de servercertificaten onder de nieuwe Root CA van PKI voor de overheid uitgegeven zullen zijn. Alle partijen die vanaf dat moment met LSP of SBV-Z willen communiceren zullen in staat moeten zijn om deze nieuwe certificaten te controleren. Dit betekent concreet dat alle aangesloten systemen het volgende uitgevoerd moeten hebben: • Realiseren van SHA-2 support in applicatie en/of operating systeem; • Installatie van het nieuwe root CA certificaat; • Mogelijk ook installatie van CA hiërarchie. Dit is dus een belangrijk moment: vanaf dat moment zijn alle systemen die nog geen SHA-2 ondersteunen niet meer in staat om een verbinding op te zetten met LSP of SBV-Z. Het advies is om hierbij de globaal de planning aan te houden van PKI voor de overheid om na 2010 geen SHA-1 meer toe te passen4.

3.4

Ondersteuning SHA-256 in operating systeem en/of applicatie Onafhankelijk van de toepassing dient ieder systeem en/of applicatie dat een certificaat of CRL van het UZI-register verifieert het SHA-256 algoritme ondersteunen. Zo niet, dan kan het systeem de handtekening die de CA onder het certificaat of CRL heeft gezet niet controleren. Deze paragraaf geeft toelichting bij een aantal operating systemen en geeft eerst een toelichting bij verschillende niveaus van SHA-2 support.

3.4.1

Toelichting verschillende niveaus SHA-2 support Om spraakverwarring te voorkomen is het goed om onderscheid te maken tussen twee niveaus in SHA-2 support: 1 alleen SHA-2 in de certificaten; 2 SHA-2 zowel in de certificaten als in het applicatie protocol. 4

Deze is overgenomen van NIST: http://csrc.nist.gov/groups/ST/hash/policy.html Pagina 10 van 20


Alleen in certificaten In deze situatie worden er alleen certificaten gebruikt uit de SHA-2 generatie. Vertrouwende partijen moeten dus in staat zijn om het gebruikte ‘Signature Algorithm’ in de certificaten te interpreteren: SHA256 with RSA Encryption. Hiervoor zijn er globaal 2 mogelijkheden: 1 Binnen het operating systeem. Dit is vooral van toepassing voor Microsoft omgevingen. Hier wordt de cryptografische functionaliteit gerealiseerd in de Microsoft Cryptographic Module/Cryptographic Service Provider. Op het moment dat deze Module/CSP is aangepast (zie paragraaf 3.4.2) zouden alle applicaties die hier gebruik van maken in staat moeten zijn om met de SHA-2 certificaten overweg te kunnen. Voorbeelden van dergelijke applicaties zijn Internet Explorer, Outlook, Internet Information Server. 2 Binnen de applicatie. Dit is bijvoorbeeld het geval bij Mozilla applicaties zoals FireFox. Deze zijn niet afhankelijk van cryptografische functies in het operating systeem. Dit is een begrijpelijke keuze omdat FireFox beschikbaar is op Windows, MacOS en Linux. Ook als het operating systeem geen SHA-2 support heeft, kan FireFox wel overweg met certificaten die ondertekend zijn met ‘SHA256 with RSA Encryption’. Dit is geïllustreerd in paragraaf 3.4.6. SHA-2 toepassen in de applicatie Het feit dat certificaten ondertekend zijn met ‘SHA256 with RSA Encryption’, zegt nog niets over het cryptografische (hashing) algoritme dat binnen een applicatie in gebruik is. Ter illustratie geeft Figuur 5 weer hoe (via Opties -> Security Settings -> Change Settings) het hashing algoritme geselecteerd kan worden dat Outlook gebruikt om de hashwaarde over het te ondertekenen e-mailbericht te berekenen. Hier is nu nog de keuze MD5 en SHA-1. Dit houdt in dat in de certificaten ‘SHA256 with RSA Encryption’ gebruikt kan zijn, terwijl het bericht is ondertekend op basis van ‘MD5 with RSA encryption’. Toepassing van SHA-256 voor berichtondertekening vereist dus een applicatie update van Outlook los van SHA-256 support in Windows XP of Vista. Dit is niet waarschijnlijk op korte termijn. Ook hier geldt dat de ontvanger de handtekening alleen kan controleren als deze eveneens SHA-256 ondersteunt in de email client.

Figuur 5: Illustratie keuze hashing algoritme binnen MS-Outlook applicatie Bij SSL/TLS speelt een vergelijkbare situatie: het gebruik van ‘SHA-2 certificaten’ zegt niets over het hashing algoritme binnen het SSL/TLS protocol. Zie ook de Pagina 11 van 20


opmerking over OCSP in par. 2.2.2. Randvoorwaarde is in alle gevallen dat de RFC’s waarin deze applicatie protocollen zijn beschreven het gebruik van SHA-256 specificeren. Binnen AORTA is dit relevant bij Token Authenticatie en Elektronische Handtekeningen onder medicatievoorschriften. Voor Token Authenticatie wordt een SHA-1 hash berekend over het token. De Elektronische Handtekening is momenteel nog in de ontwerpfase, maar zal vermoedelijk een SHA-2 hash toepassen om te kunnen voldoen aan het normenkader van de elektronische handtekening. Dit valt verder buiten de scope van dit document. 3.4.2

Ondersteuning SHA-256 in Microsoft Windows XP Figuur 6 toont het nieuwe root CA certificaat op een XP systeem met Service Pack 3 geïnstalleerd5. Het ‘Signature algorithm’ is binnen het operating systeem bekend en is correct weergegeven. Dit betekent dat applicaties die de Microsoft Cryptographic Module overweg kunnen met certificaten uit de SHA-2 generatie.

Figuur 6: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Windows XP met SP3 3.4.3

Ondersteuning SHA-256 in Microsoft Windows Vista Onder Windows Vista kan het nieuwe root CA certificaat worden vertrouwd. Ook hier is het Signature algorithm binnen het operating systeem bekend. Dit is zowel met als zonder SP1 het geval.

5

Zoals aangegeven in http://support.microsoft.com/kb/936929 is dit Service Pack beschikbaar voor Microsoft Windows XP Home Edition; Microsoft Windows XP Media Center Edition; Microsoft Windows XP Professional en Microsoft Windows XP Tablet PC Edition. De functionaliteit binnen SP3 die SHA-256 ondersteunt is de Microsoft Cryptographic Module die als volgt is omschreven: Implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in X.509 certificate validation. This has been added to the crypto module rsaenh.dll. XP SP2 crypto modules Rsaenh.dll/Dssenh.dll/Fips.sys had been certified according to FIPS 140-1 specifications. The Federal Information Processing Standard (FIPS) 140-1 standard has been replaced by FIPS 140-2, and these modules have been validated and certified according to this standard. For more information, see the Microsoft Kernel Mode Cryptographic Module. Pagina 12 van 20


Figuur 7: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Windows Vista 3.4.4

Ondersteuning SHA-256 in Mac OS X Op Mac OS X 10.5.3, PowerPC is met succes het nieuwe stamcertificaat en het onderliggende domein CA certificaat toegevoegd aan de sleutelhanger. In de sleutelhanger kan men persoonlijke wachtwoorden opslaan, maar ook certificaten: dus een soort personal certificate store.

Figuur 8: Correcte weergave ‘SHA256 with RSA encryption’ algoritme in Mac OS X sleutelhanger Verder is FireFox op de Mac OS X meestal in gebruik voor web toepassingen die authenticatie met de UZI-pas gebruiken. Ook binnen FireFox is het nieuwe stamcertificaat met succes toe te voegen.

Figuur 9: Correcte weergave SHA-2 algoritme in FireFox op Mac OS X

Pagina 13 van 20


Vervolgacties • Testen op andere releases van MacOS X dan 10.5.3 • Nader onderzoek naar de volgende bevinding: http://discussions.apple.com/thread.jspa?messageID=3548575 There is a bug in Apple's sha256.c and hmac-sha256.c source code files. If you're running the code on a PPC Mac, you will not encounter the bug, but if you're running Apple's code on an Intel machine (or you compile it using something other than GCC), you may encounter the problem. 3.4.5

Ondersteuning SHA-256 in Linux Hier zijn nog geen testen op uitgevoerd. Gangbare applicaties en libraries van Mozilla en OpenSSL hebben SHA-256 support op applicatieniveau zodat SHA-256 naar verwachting op Linux werkend is te krijgen. Vervolgacties • Testen op de ondersteunde Linux distributies (RHEL 4 en SuSe 10).

3.4.6

Ondersteuning SHA-256 in Windows 2003 server CIBG heeft een test uitgevoerd met een Windows 2003 server: Standard Release, met Service Pack 2 en volledig bijgewerkt met alle windows updates tot en met september 2008. Issue Hhet openen van het SHA-2 Root certificaat levert op een Windows 2003 server een foutmelding op in de certificate viewer (zie Figuur 10). Omdat er geen support is voor SHA-256 kan Windows 2003 niet vaststellen of het certificaat is gewijzigd. Het detail scherm geeft weer dat het operating systeem het ‘Signature algorithm’ niet kent en toont daarom de Object Identifier van het algoritme die in het certificaat staat.

Figuur 10: Foutmelding op Windows 2003 server systeem zonder SHA-256 support De consequentie hiervan is dat een Windows 2003 server niet in staat is om een certificaat of CRL te controleren die gebruikt maakt van het ‘SHA-256 with RSA encryption’ algoritme. Pagina 14 van 20


Microsoft heeft een Hotfix beschikbaar die dit probleem verhelpt: http://support.microsoft.com/kb/938397. CIBG heeft vastgesteld dat na installatie van deze hotfix op Windows 2003 server R2 SP1 en SP2 (Intel 32 bits) de nieuwe certificaten wel herkend worden en te installeren zijn in de certificate store. Microsoft heeft wel een disclaimer: “WAARSCHUWING: Deze hotfix is niet uitgebreid getest. Daarom is deze uitsluitend bedoeld voor systemen of computers waarop het exacte probleem wordt ondervonden dat in een of meer van de Microsoft Knowledge Base-artikelen in het "KB-artikelnummers"-veld van de tabel onder aan dit emailbericht wordt beschreven. Als u niet zeker weet of specifieke compatibiliteitsproblemen of installatieproblemen aan deze hotfix zijn gekoppeld, raden we u aan te wachten op de volgende versie van het servicepack. Dat servicepack bevat een volledig geteste versie van deze hotfix.“ De werking van deze hotfix zal dus nog getest moeten worden met o.a. de volgende toepassingen: • Internet Information Server; • Smartcard logon met de UZI-pas in een Windows 2003 domain; • Windows Terminal Services. De remote desktop draait op de Windows 2003 server en heeft dus dezelfde cryptografische functionaliteit als de Windows 2003 server; • XIS server applicaties die Crypto Service Provider van het Windows 2003 gebruiken. Ook zonder de hotfix is het mogelijk dat er applicaties draaien op de Windows 2003 server die zelf SHA-2 functionaliteit hebben. Ter illustratie is dat met FireFox getest. Hiervoor in FireFox 3.0.1 geïnstalleerd op een Windows 2003 server zonder hotfix kb938397. Hierin kan men CA certificaten importeren die de browser vervolgens vertrouwt voor bijvoorbeeld het ondertekenen van servercertificaten. Dit kan via: Tools -> Options -> Tab Encryption -> View Certificates -> Import. Importeer het nieuwe root CA certificaat Klik op Tabblad Authorities

Pagina 15 van 20


Figuur 11: FireFox SHA-256 support op Windows 2003 server systeem Toelichting • De certificate manager laat zien dat het huidige Staat der Nederlanden Root CA certificaat is ‘ingebouwd’ in Mozilla FireFox als ‘Builtin Object Token’. Installatie van de browser is voldoende om dit certificaat te vertrouwen. • Het G2 certificaat is geïmporteerd (Software Security Device). • Met View / details is zichtbaar dat het SHA-256 with RSA Encryption bekend is en dat het domeincertificaat gekoppeld is aan het root CA certificaat (certificate hierarchy). Vervolgacties 1 Het is niet duidelijk of Microsoft SHA-2 support in de toekomst in Windows 2003 server officieel gaat toevoegen. Er is geen Servicepack meer gepland maar er zijn nog wel security updates mogelijk voor Windows 20036. PKI overheid zal deze vraag uitzetten bij Microsoft. 2 Testen met IIS en Apache. 3 Het is onduidelijk wat de consequenties zijn als op een Windows 2003 server het .NET framework 3.5 SP1 wordt geïnstalleerd7. Hierin is wel SHA-256 support opgenomen8 dus .NET applicaties (XIS-en) zouden deze functionaliteit kunnen gebruiken voor signatures binnen de applicatie. Of hierdoor ook certificaat validatie mogelijk wordt, is niet duidelijk. 4 Testen smartcard logon.

6 7 8

Zie http://www.microsoft.com/windows/lifecycle/servicepacks.mspx en http://www.microsoft.com/windowsserver2003/default.mspx Download: http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-831981DA479AB0D7&displaylang=en Zie: http://blogs.msdn.com/shawnfa/archive/2008/08/25/using-rsacryptoserviceprovider-for-rsa-sha256signatures.aspx Pagina 16 van 20


3.4.7

Ondersteuning SHA-256 in Windows 2008 Hoewel dit nog niet getest is, zal dit naar verwachting gelijk zijn aan de situatie bij Vista. Vervolgacties 1 Test uitvoeren met Windows 2008 server inclusief smartcard logon.

3.4.8

Support in standaardapplicaties Hieronder is een aantal standaardapplicaties genoemd waar deze release ook invloed op heeft. Hier zijn ze alleen genoemd. Zodra er testpassen zijn zullen zoveel mogelijk standaardtoepassingen getest worden. Adobe Adobe maakt gebruik van een eigen root CA certificaat en “certificate store”. Door Adobe-USA wordt onderzocht hoe het stamcertificaat van PKI overheid in de “certificate store” kan worden opgenomen. PKI overheid bereidt een pilot voor met Adobe en heeft daarbij ook SHA-256 op de agenda staan. Citrix Dit is naar verwachting vergelijkbaar met Window 2003 Terminal Server. Als de 2003 server support heeft voor SHA-256 zal dit voor de citrix client ook beschikbaar zijn. Mozilla Thinderbird email client Dit zal naar verwachting gewoon werken omdat hier hetzelfde mechanisme in gebruik is als bij FireFox: SHA-256 support is ingebouwd in de applicatie. Smartcard logon (Windows 2003 en Windows 2008) Dit zal naar verwachting alleen werken bij volledige support binnen Windows 2003 server. Windows 2008 server zal naar verwachting werken.

3.5

Impact voor XIS leveranciers (FAQ) Wat de impact op applicatieniveau is, hangt sterk af van implementatiekeuzes van de leverancier. Dit verklaart het ruime tijdspad dat gekozen is om alle partijen gelegenheid te geven om applicaties aan te passen indien noodzakelijk. Zoals aangegeven in paragraaf 3.4.1 is er een minimale variant (alleen certificaten met ‘SHA-256 with RSA encryption’ als signature algorithm zijn bruikbaar) tot een maximale variant waarbij men SHA-256 ook in de applicatie gebruikt voor het berekenen van hash-waarden. Dit laatste is waarschijnlijk van toepassing in het kader van EMD+ wat onder andere elektronische handtekeningen onder medicatievoorschriften introduceert. Deze paragraaf probeert in de vorm van FAQ’s de impact zo volledig mogelijk toe te lichten.

3.5.1

Ondersteunt de nieuwe ‘SHA-2 pas’ nog steeds ‘SHA-1 with RSA’ encryption? Ja, er komt alleen 'security mechanisme9 ' bij voor het gebruik van SHA-256 naast de huidige security mechanismen. Er verdwijnen geen security mechanismen. Voor applicatieontwikkelaars houdt de SHA-2 support in dat het PKCS#11 security mechanisme CKM_SHA256_RSA_PKCS ook gebruikt kan worden via de middleware.

9

Hier is een security mechanisme bedoeld conform Hoofdstuk 12 van de PKCS#11 standaard. Zie http://www.rsa.com/rsalabs/node.asp?id=2133 Pagina 17 van 20


3.5.2

Blijven bestaande XIS applicaties dus gewoon werken? Nee, dat hangt af van de specifieke configuratie. Het antwoord in paragraaf 3.5.1 houdt in dat maatwerk applicatie code die nu SHA-1 hashes berekent via de middleware naar verwachting niet gewijzigd hoeft te worden. Zoals toegelicht in paragraaf 3.4.1 dienen minimaal alle systemen die certificaten uit de SHA-2 generatie moeten vertrouwen het SHA-256 algoritme te ondersteunen. Verder moet de applicatie overweg kunnen met grotere RSA sleutels (zie paragraaf 3.5.3).

3.5.3

Wat is het effect van de langere sleutellengten? Het effect is dat zowel de certificaten als handtekeningen groter zullen zijn. Vanwege de variabele gegevens van pashouders wisselt de omvang van certificaten en is het niet exact voorspelbaar. Wel is een indicatie te geven. Ter illustratie: het huidige root CA certificaat is 958 bytes en het nieuwe root CA certificaat is 1.486 bytes. Een belangrijke reden van de toegenomen omvang van certificaten is de omvang van de handtekeningen onder de certificaten. Bij het RSA algoritme geldt de volgende regel: het aantal bytes van de signature is gelijk aan de RSA sleutellengte in bits gedeeld door 8. Bij een 1024-bits RSA key is de signature dus 128 bytes. Handtekeningen onder authenticatie tokens of mediciatievoorschriften worden dus 256 bytes onafhankelijk van het gebruikte hashing algoritme10 .

3.5.4

Wat moet een software ontwikkelaar doen om de SHA-256 functionaliteit van de middleware te gebruiken? Dit betreft dus de situatie waarbij men binnen de XIS applicatie een SHA-256 hashwaarde wil gebruiken als onderdeel van handtekening (SHA-256 with RSA encryption). Voor het berekenen van een RSA signature kan men de volgende PKCS#11 functies gebruiken: • C_SignInit • C_Sign Onderdeel van deze functies is een security mechanisme9 dat men moet meegeven. Hierbij zijn er twee varianten waarbij hashing wel of geen onderdeel is van het mechanisme. Men kan dus kiezen om de hash-waarde in de applicatie te berekenen en die berekende hash via de middleware aan te bieden aan de UZI-pas voor uitsluitend een RSA bewerking. In de andere variant biedt men de data aan de middleware aan en geeft men een security mechanisme mee dat zowel een hashing algoritme als het RSA algoritme specificeert. De middleware berekent de hash-waarde en de UZI-pas voert de RSA bewerking uit. Hieronder zijn twee stukjes C++ voorbeeld code opgenomen die het verschil illustreren. Hashing in applicatie en alleen RSA bewerking via middleware (UZI-pas) *********************************************************************** void SignVerify(CK_SESSION_HANDLE hSession) { CK_MECHANISM mechanism = {CKM_RSA_PKCS,0,0}; CK_BYTE data[] = "KJLKJLKJASFLKJASFJL AFASghrttyuihjw"; // We use 36 bytes for testing this reflects normal use because // length(MD5_HASH) + length(SHA1_HASH) => 36 10 De toegenomen omvang van het Root CA certificaat is daarmee als volgt te verklaren. De toename is 1.486 - 958 bytes = 528 bytes. De (self-signed) handtekening met een 4096 bits sleutel is 4096 / 8 = 512 bytes. Dit is een toename van 256 bytes t.o.v. de oude situatie met 2048 bits sleutels. De sleutel zelf is 2048 bits groter wat betekent: 2048 / 8 = 256 bytes. De resterende toename van 16 bytes komt voort uit een langere naamgeving. Pagina 18 van 20


CK_ULONG dataLen = 36; // The result of the signing/encryption/decryption // operation will be 128 byes long because we are using // a 1024 bits key. CK_BYTE signature[128]; CK_ULONG signatureLen = 128; CK_BYTE encryptedData[128]; CK_ULONG encryptedLen; CK_BYTE decryptedData[128]; CK_ULONG decryptedLen; FL_CALL(C_SignInit,(hSession,&mechanism,prk)); FL_CALL(C_Sign,(hSession,data,dataLen,signature,&signatureLen)); // if Verify goes wrong cryptoki returns // CKR_SIGNATURE_INVALID (0x000000C0) FL_CALL(C_VerifyInit,(hSession,&mechanism,puk)); FL_CALL(C_Verify,(hSession,data,dataLen,signature,signatureLen)); } } *********************************************************************** Zowel hashing als RSA bewerking via middleware (UZI-pas) Men kan ook een security mechanisme gebruiken waarin de hashfunctie zit. Het onderstaande voorbeeld komt uit de SDK (AuthenticationSample) die voor SafeSign beschikbaar is en op de UZI-site staat. Hier wordt de data gesigned met een combinatie van SHA-1 (eerste hash berekenen in middleware) en vervolgens RSA signing (met private key op de UZI-pas). *********************************************************************** //////////////////////////////////////////////////////////////////// // // SLIDE 8 // Sign the challenge //////////////////////////////////////////////////////////////////// // // Signing can be done as a one-part or multi-part operation, and can // // // //

be done using various hash algorithms. Please refer to the PKCS #11 specification for details. In this example, we use a single part operation and we use SHA-1 hashing with PKCS #1 padding. This is a very common combination.

CK_MECHANISM sha1PKCS1 = { CKM_SHA1_RSA_PKCS, NULL, 0 }; rv = pP11->C_SignInit(hSession, &sha1PKCS1, hPrivateKey); CheckRV(rv); // // // // //

If you use a hash, you can sign an unlimited amount of data, but for this example, we only use 10 bytes... You can use repeated calls to C_Sign to determine the size of the signature, as done below. The sample data represents the challenge that we would typically Pagina 19 van 20


// get from the server when going through an authentication sequence. // Of course, this value would be random and different every time // in a real world scenario. unsigned char ucData[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; CK_ULONG ulSigSize = 0; // Determine the size of the signature rv = pP11->C_Sign(hSession, ucData, 10, NULL, &ulSigSize); CheckRV(rv); // Allocate space for the signature unsigned char* pSignature = new unsigned char[ulSigSize]; // Retrieve the signature rv = pP11->C_Sign(hSession, ucData, 10, pSignature, &ulSigSize); CheckRV(rv); printf("Signature: \n\n

");

for (int i = 0; i < ulSigSize; i++) { if ((i > 0) && ((i % 16) == 0)) { printf("\n "); } printf("%02X ", pSignature[i]); } delete[] pSignature; printf("\n\n"); *********************************************************************** 3.5.5

Is SHA-256 ook te gebruiken met Microsoft Crypto API? Ja, ook bij applicaties die gebruik maken van de Microsoft interface komt er een nieuw security mechanisme via de SafeSign Cryptographic Service Provider. De functie CryptCreateHash zal ook SHA-256 als algoritme ondersteunen. Zie http://msdn.microsoft.com/en-us/library/ms867086.aspx

3.5.6

Is het mogelijk om SHA-256 te gebruiken voor een Elektronische handtekening met een G1 of G2 UZI-pas? Ja, de hashwaarde over het te ondertekenen bericht wordt dan in de applicatie berekend en vervolgens wordt met de UZI-pas alleen een RSA signature gezet over deze hash-waarde. Hierbij moet men dus de eerste variant toepassen die is beschreven in paragraaf 3.5.4.

Pagina 20 van 20

Toelichting SHA-2 Release Zorg CSP (UZI-register en ZOVAR)

Recommend Documents