An051_NL - Sociale Zekerheid

BIJLAGE 4
:
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/
15/04/2004
1
Bijlage 4 - DIMONA-aangifte
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 ISABELnetwerk 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 ISABELhandtekening, 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 :
15/04/2004
2
Bijlage 4 - DIMONA-aangifte
 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 ETrust*/ 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.
15/04/2004
3
Bijlage 4 - DIMONA-aangifte
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 DMFAzending.

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)
De toegelaten algoritmen zijn SHA-1, MD2 of MD5.
Moet een data bevatten die verplicht blanco moet zijn
(aanwezig, maar lengte nul).
Verplicht blanco.
Moet (ten minste) een (erkend) certificaat bevatten, uitgereikt
door een erkende certificatieautoriteit.
Niet verplicht.
Minimum één ondertekenaar.
Moet waarde 1 hebben (stemt overeen met versie 1.5 van
PKCS #7)
Identificator van de afzender van het certificaat en
serienummer van dit certificaat
De toegelaten algoritmen zijn SHA-1, MD2 of MD5.
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,
DigestAlgorithms
ContentInfo
ContentInfo.content
Certificates
Crls
SignerInfos
SignerInfo.version
IssuerAndSerialNumber
SignerInfo.digestAlgorithm
SignerInfo.authenticatedAttributes
 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.
Het toegelaten algoritme is rsaEncryption (bepaald in PKCS
#1).
Niet verplicht.
Waarde van de handtekening
SignerInfo.digestEncryptionAlgorithm
SignerInfo.unauthenticatedAttributes
EncryptedDigest
15/04/2004
4
Bijlage 4 - DIMONA-aangifte
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 CAcertificaten 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 :
15/04/2004
5
Bijlage 4 - DIMONA-aangifte
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 digestbewerking, 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.
15/04/2004
6
Bijlage 4 - DIMONA-aangifte