BIJLAGE 2 : Digitale handtekening
Ten opzichte van de vorige versie van deze bijlage zijn de voornaamste wijzigingen de volgende :
• Wat de handtekening PKCS#7 betreft, aanvaardt de sociale zekerheid twee opties : handtekening met authenticatedAttributes en handtekening zonder authenticatedAttributes.
• Er werd een paragraaf toegevoegd over de verificatie van de handtekening.
1. De digitale handtekening in het algemeen
1. 1 Principes
De digitale handtekening bestaat erin om, via bepaalde algoritmische bewerkingen, een origineel bericht om te zetten in een nieuw bericht (het getekende bericht) waaraan identificatiegegevens (idealiter deze van de verzender) verbonden zijn. Op deze manier kan de bestemmeling van het bericht, via gepaste algoritmische verwerkingen van het bericht dat hij ontvangt, enerzijds het originele bericht en anderzijds de identificatiegegevens terugvinden. Dit mechanisme wordt hieronder meer in detail toegelicht, in de paragraaf "Handtekeningstechnieken". De vraag of de uitgehaalde identificatiegegevens wel degelijk die van de verzender zijn, zal verder in dit document behandeld worden (paragraaf 2.3), wanneer de certificaten ingeleid zullen worden.
Merk op dat de problematiek van het crypteren van het bericht (om de vertrouwelijkheid ervan te verzekeren) onafhankelijk is van de problematiek van de digitale handtekening, zelfs al leunen zij technisch gezien sterk bij elkaar aan (in die zin dat de digitale handtekening een beroep doet op crypteringstechnieken). Het originele bericht wordt immers "ongecodeerd" verstuurd naar de bestemmeling.
1.2 Handtekeningstechnieken
De digitale handtekening steunt op het gebruik van hashing-algoritmen (MD2, MD5, SHA-1) gecombineerd met asymmetrische crypteringsalgoritmen (RSA). Om een bericht te tekenen, berekent de verzender eerst de "digest" van het originele bericht met behulp van een hashing-algoritme. Vervolgens crypteert hij deze digest, via asymmetrische cryptering, door gebruik te maken van zijn persoonlijke sleutel. Ten slotte voegt hij aan dit laatste resultaat zijn identificatiegegevens toe, vervat in een certificaat.
Hij verzendt het geheel (ongecodeerd bericht, gecrypteerde digest en certificaat) naar de bestemmeling.
De bestemmeling van het bericht kan deze techniek omgekeerd toepassen om de geldigheid van de handtekening te controleren : hij haalt het certificaat uit om de identiteit van de veronderstelde verzender en zijn publieke sleutel te bepalen. Om de digest te decrypteren, gebruikt hij deze publieke sleutel met hetzelfde asymmetrische crypteringsalgoritme als de verzender en ten slotte berekent hij zelf de digest van het ontvangen bericht en vergelijkt deze met de digest uit de handtekening : de overeenstemming tussen de waarden van de twee digests garandeert de echtheid van het bericht.
1.3 Standaarden
Om een bepaalde flexibiliteit van de producten van de digitale handtekening toe te laten, zijn een aantal standaarden uitgebracht onder toezicht van de RSA Laboratories, afdeling R&D van RSA Digital Security, Inc. De benaming van deze standaarden is PKCS : Public-Key Cryptography Standards. Deze teksten refereren voortdurend naar de ITU-aanbevelingen (International Telecommunication Union) van de serie 500 (X.500, X.501 en X.509), betreffende de repertoria (Directories), en maken gebruik van de notitie gedefinieerd in X.208 en X.209 (ASN.1 : Abstract Syntax Notation 1). Normen die equivalent zijn aan die van de ITU werden eveneens uitgebracht door de ISO (International Organization for Standardization) of gezamenlijk door de ISO en de IEC (International Electrotechnical Commission) onder de referenties ISO 8824 en ISO 8825 (ASN.1) en ISO/IEC 9594 (serie X.500). Merk op dat vroeger gerefereerd werd naar de aanbevelingen X.200 en X.500 van de ITU als normen van het CCITT (Consultative Committee for International Telegraph and Telephone) waarvan de activiteiten overgenomen werden door de ITU.
De tekst van de PKCS is beschikbaar op de website van RSA Data Security: http://www.rsa.com/
Merk op dat er andere gehelen van algoritmen en specificaties bestaan : we kunnen bijvoorbeeld DSA (acroniem van Digital Signature Standard) en PGP (acroniem van Pretty Good Privacy) citeren.
De PKCS-standaarden bepalen hoofdzakelijk twee aspecten van de digitale handtekening : de te gebruiken algoritmen en de syntaxis van het getekende bericht. Deze laatste maakt het voorwerp uit van de specificatie PKCS #7 (Cryptographic Message Syntax Standard). Recenter is een andere standaard verschenen voor de syntaxis van de digitale handtekening, namelijk de handtekening XML, gedefinieerd door het W3C (http://www.w3c.org). Deze standaard wordt momenteel niet gebruikt in het kader van DIMONA/DMFA/ASR.
1.4 Syntactische aspecten
Een geheel van gegevens moet aan het originele bericht toegevoegd worden om de standaard digitale handtekening te vormen, voornamelijk :
• de gecrypteerde digest;
• de identificator van het gebruikte digest-algoritme;
• het certificaat van de verzender;
• plus een aantal optionele gegevens (lijst van de herroepen certificaten, andere erkende gegevens, etc.).
Noteer dat eenzelfde bericht door verschillende ondertekenaars mag getekend worden. De bovenvermelde gegevens zullen dan herhaald worden voor elk van de ondertekenaars.
Om deze gegevens op ondubbelzinnige wijze te kunnen doorsturen, definieert de specificatie PKCS#7 versie 1.5 een uiterst nauwkeurige syntaxis, gebaseerd op de gestandaardiseerde syntaxis ASN.1.
2. De digitale handtekening van de sociale aangiften (DIMONA, DMFA, ASR)
2.1 Basisvragen
Als het gaat over de transfer van getekende bestanden, dan stellen er zich drie soorten vragen : 1. welk type digitale handtekening mag men gebruiken ?
2. hoe wordt de identiteit van de ondertekenaar van een bericht gegarandeerd ? 3. hoe moeten de bestanden (bericht en handtekening) georganiseerd worden ?
2.2 Types van handtekening
Twee types van digitale handtekening worden erkend :
1. de zogenaamde "ISABEL-handtekening", die gebruikt moet worden wanneer via het ISABEL- netwerk gewerkt wordt; niet alleen de verzender moet zijn digitale ISABEL-handtekening gebruiken, ook de berichten verstuurd door de sociale zekerheid naar de verzender zullen een ISABEL-handtekening bevatten.
2. de zogenaamde "standaardhandtekening", gebruikt in de andere gevallen.
2.3 Certificaten
In alle gevallen doen de handtekeningen een beroep op een certificaat, dat de identiteit van de
berichttekenaar garandeert; deze certificaten kunnen verkregen worden bij een certificatiedienstverlener (ook "Certification Authority" genoemd, of "CA" in het kort). Als men gebruik maakt van de ISABEL- handtekening, moet de CA noodzakelijkerwijs ISABEL zijn. Noteer dat ISABEL ook certificaten levert voor de zogenaamde "standaardhandtekening". Er bestaan trouwens talrijke leveranciers van certificaten voor de standaardhandtekening. Om aanvaard te worden door de sociale zekerheid, moet een certificaat in feite aan twee randvoorwaarden beantwoorden :
• de oorsprong van het certificaat : het Informatiesysteem van de sociale zekerheid is in staat om de certificaten te valideren die geleverd worden door de certificatieautoriteiten vermeld in de op het portaal van de sociale zekerheid gepubliceerde lijst (zie hieronder). De certificaten die door andere certificatieautoriteiten geleverd worden kunnen, op verzoek van een gebruiker, alleen aanvaard worden voorzover de nodige aanpassingen voor de validatie van deze certificaten aangebracht werden aan het Informatiesysteem.
• het type van certificaat : alleen de certificaten uitgereikt aan natuurlijke personen, die zich tijdens het certificatieproces fysisch hebben aangeboden, kunnen aanvaard worden.
De certificatiedienstverleners vermeld in de lijst hieronder werden gekozen omdat zij een bepaald kwaliteitsniveau van de geleverde certificaten garanderen in termen van betrouwbaarheid van de gebruikte infrastructuur om de certificaten te beheren, van controle van de identiteit van de houder van een certificaat, of van beveiliging van de gebruikte crypteringssleutels.
De lijst van de aanvaarde certificaten ziet er op 15 maart 2004 als volgt uit:
CA TYPES CERTIFICATEN
Belgacom E- Trust*/ Certipost
Qualified Certificate
GlobalSign PersonalSign Class 3 Pro**en PersonalSign Qualified
Isabel Classe 3
*De activiteiten van Belgacom SA als certificatiedienstverlener werden overgenomen door Certipost SA sinds 19 december 2003.
**De certificaten PersonalSign Class 3 Pro uitgebracht vooraleer de certificaten PersonalSign Qualified beschikbaar zijn, worden aanvaard tot aan hun vervaldag.
2.4 Bestanden en organisatieschema
Deze paragraaf preciseert welke specificaties men moet naleven als de standaardhandtekening gebruikt wordt.
2.4.1 Algemeen schema
In dit geval wordt door de sociale zekerheid slechts één organisatieschema van de bestanden aanvaard voor de aangiften DIMONA, DMFA of ASR.
Het betreft een schema van twee bestanden, één met het gestructureerde bericht (DIMONA, DMFA of ASR) zonder encryptie of versleuteling, en één met de digitale handtekening. Wat de handtekening betreft, is de gebruikte versie van de standaard PKCS#7 de versie 1.5 die dateert van 1 november 1993.
Het gestructureerd bericht is geëncodeerd ASCII en wordt als zodanig doorgestuurd in een bestand waarvan de naam beantwoordt aan de specificaties beschreven in de documentatie die beschikbaar is op het portaal van de sociale zekerheid.
In het geval van DIMONA zal de bestandsnaam bijvoorbeeld zijn : DIMD.123456.20030801.00001.021.N.R Voor een ongecodeerd DMFA-bestand zal de bestandsnaam de volgende structuur hebben :
FI.DMFA.123456.20030801.00001.R.1.1
en voor de ASR-berichten zullen de bestandsnamen de volgende structuur hebben : FI.XXXX.123456.20030801.00001.R
waarbij XXXX de volgende waarden aanneemt :
WECH wanneer het gaat over een ASR werkloosheid;
AOAT wanneer het gaat over een ASR arbeidsongeval;
BZMP wanneer het gaat over een ASR beroepsziekten;
ZIMA wanneer het gaat over een ASR ZIV.
Voor details kunt u terecht in de documentatie die beschikbaar is op het portaal van de sociale zekerheid.
Wat de digitale handtekening van het bericht betreft, wordt de procedure voor de berekening van de handtekening later gedetailleerd, in de paragraaf 2.4.3. Het belangrijkste is dat de elementen waaruit de handtekening bestaat, opgenomen zijn in een structuur PKCS #7 ContentInfo, die moet behoren tot het type SignedData. Het veld SignedData wordt verderop beschreven, in de paragraaf 2.4.2.
Dit ContentInfo is geëncodeerd base-64 en wordt doorgestuurd naar de sociale zekerheid in een bestand waarvan de naam dezelfde structuur heeft als het bijbehorende gegevensbestand, behalve dat het laatste karakter van het prefix een S moet zijn.
• Voor een DIMONA-aangifte heeft het bestand met de handtekening bijvoorbeeld de volgende naam : DIMS.123456.20030801.00001.021.N.R;
Het geheel van de twee bestanden DIMD en DIMS, samen met een GODIMD.*-bestand, vormt een DIMONA-zending.
• Voor een DMFA-aangifte heeft het bestand met de handtekening de volgende naam : FS.DMFA.123456.20030801.00001.R.1.1
Het geheel van de twee bestanden FI en FS, samen met een GO.*-bestand, vormt een DMFA- zending.
• Gelijkaardige regels worden toegepast voor de ASR-aangiften. Voor details kunt u terecht in de documentatie die beschikbaar is op het portaal van de sociale zekerheid.
2.4.2 Structuur van de handtekening
De structuur van het veld SignedData wordt hieronder beschreven.
Version Moet waarde 1 hebben (stemt overeen met versie 1.5 van
PKCS #7)
DigestAlgorithms De toegelaten algoritmen zijn SHA-1, MD2 of MD5.
ContentInfo Moet een data bevatten die verplicht blanco moet zijn (aanwezig, maar lengte nul).
ContentInfo.content Verplicht blanco.
Certificates Moet (ten minste) een (erkend) certificaat bevatten, uitgereikt door een erkende certificatieautoriteit.
Crls Niet verplicht.
SignerInfos Minimum één ondertekenaar.
SignerInfo.version Moet waarde 1 hebben (stemt overeen met versie 1.5 van PKCS #7)
IssuerAndSerialNumber Identificator van de afzender van het certificaat en serienummer van dit certificaat
SignerInfo.digestAlgorithm De toegelaten algoritmen zijn SHA-1, MD2 of MD5.
SignerInfo.authenticatedAttributes Niet verplicht. Als dit veld aanwezig is, moet het ten minste bevatten
• een toevoegsel (PKCS #9) van het type contentType, dat noodzakelijk het type data bevat,
• een toevoegsel (PKCS #9) van het type
messageDigest, dat de digest van het gestructureerde bericht bevat. Zie "Berekening van de waarde van de handtekening".
Het kan ook bevatten
• een toevoegsel (PKCS #9) van het type emailAddress met het elektronisch adres van de verzender,
• een toevoegsel (PKCS #9) van het type signingTime, met vermelding van de datum en het uur waarop de handtekening geplaatst werd.
SignerInfo.digestEncryptionAlgorithm Het toegelaten algoritme is rsaEncryption (bepaald in PKCS
#1).
SignerInfo.unauthenticatedAttributes Niet verplicht.
EncryptedDigest Waarde van de handtekening
Merk op dat de sociale zekerheid niet meer eist dat het veld authenticatedAttributes aanwezig is. De twee opties worden aanvaard voor de handtekening van de sociale aangiften : met of zonder authenticated Attributes. Als dit veld aanwezig is, moet de inhoud ervan uiteraard conform zijn aan de hierboven beschreven specificaties.
We onderstrepen dat de handtekening van de berichten verstuurd door de sociale zekerheid naar een aangever geen authenticatedAttributes bevat (zie paragraaf 3 : verificatie van de handtekening).
Verder aanvaardt de sociale zekerheid dat het veld Certificates niet alleen het certificaat van de ondertekenaar bevat maar de hele reeks van certificaten tot aan het root-certificaat van de CA die het certificaat van de ondertekenaar heeft afgeleverd, maar dit is niet verplicht.
2.4.3 Berekening van de waarde van de handtekening
De specificatie PKCS#7 preciseert dat de berekening van de waarde van de handtekening verschillend is naargelang het veld authenticatedAttributes aanwezig is of niet.
Als het veld authenticatedAttributes niet aanwezig is, dan wordt de waarde van de handtekening als volgt bekomen. Het ongecodeerde bericht (gecodeerd in ASCII) wordt onderworpen aan één van de toegelaten hashing-algoritmen en er wordt een "digest-bericht" aangemaakt. Daarna stelt men een DigestInfo samen, die een sequentie is samengesteld uit de identificator van het algoritme dat gebruikt werd voor deze hashing en uit deze 'message digest'. Ten slotte wordt de BER-codering van deze DigestInfo onderworpen aan het RSA-coderingsalgoritme.
Als het veld authenticatedAttributes aanwezig is, dan bevat dit noodzakelijkerwijs de digest (bekomen door middel van één van de toegelaten hashing-algoritmen) van het ongecodeerde bericht (bericht gecodeerd in ASCII). Daarna wordt de DER-codering van het veld authenticatedAttributes onderworpen aan hetzelfde hashing-algoritme om een 'message digest' aan te maken. De berekening van de waarde van de handtekening gaat dan voort zoals in het geval waarbij het veld authenticatedAttributes niet aanwezig is (samenstelling van een DigestInfo en onderwerping van de BER-codering van deze DigestInfo aan het RSA-coderingsalgoritme).
In beide gevallen is het belangrijk dat het ongecodeerde bericht onderworpen aan de hashing gecodeerd is in ASCII (en bijvoorbeeld niet in UNICODE).
3. De verificatie van de digitale handtekening van een bericht verstuurd door de sociale zekerheid De grote lijnen van een procedure om een digitale handtekening te verifiëren, werden reeds geschetst in paragraaf 1.2.
Hieronder wordt dieper ingegaan op de procedure voor de verificatie van de digitale handtekening van een bericht verstuurd door de sociale zekerheid (schema met twee bestanden), in het geval van een
"standaardhandtekening" (er wordt hier niet ingegaan op een "ISABEL-handtekening").
Aangezien de Contentinfo verstuurd in het bestand met de handtekening base-64 gecodeerd is, moet eerst een decodering uitgevoerd worden. Vervolgens moet uit de SignedData-structuur het certificaat van de ondertekenaar gehaald worden. Het wordt aanbevolen de geldigheid van dit certificaat te controleren, voornamelijk :
A1 : verificatie van de vervaldatum van het certificaat;
A2 : verificatie van de integriteit van het certificaat, d.w.z. verificatie van de handtekening van het certificaat gebruikt door de ondertekenaar (wat impliceert dat men moet beschikken over de CA- certificaten van de certificatieautoriteit die het certificaat van de ondertekenaar heeft afgeleverd);
A3 : verificatie van de niet-herroeping van het certificaat;
Als elk van deze stappen een positief resultaat oplevert, kan overgegaan worden naar de volgende stappen. Anders wordt de handtekening geweigerd.
Vervolgens wordt overgegaan tot de verificatie van de handtekening zelf. Noteer eerst dat in verband met de SignedData-structuur beschreven in 2.4.2 twee punten gepreciseerd kunnen worden in het geval van een door de sociale zekerheid getekend bericht : het algoritme gebruikt voor de hashing van het ongecodeerde bericht is MD5, en het veld authenticatedAttributes is niet aanwezig. De stappen van de verificatie zijn de volgende :
B1: RSA-decodering van het veld "waarde van de handtekening", aan de hand van de publieke sleutel vervat in het certificaat van de ondertekenaar;
B2: hashing MD5 van het ongecodeerde bericht, samenstelling van een sequentie ASN.1 bestaande uit de identificator van het gebruikte hashing-algoritme (MD5) en het resultaat van de digest- bewerking, en BER-codering van deze sequentie;
B3: vergelijking van de resultaten bekomen in B1 en B2; als deze resultaten identiek zijn, wordt de handtekening aanvaard; anders wordt zij geweigerd.
