La version du standard retenue est PKCS #7

BIJLAGE 4
:
Digitale handtekening
Principes van de digitale handtekening
De digitale handtekening bestaat erin om, via algoritmische bewerkingen, een origineel bericht om te
zetten in een nieuw bericht (het getekende bericht) waaraan identificatiegegevens (idealiter deze van de
verzender) nauw verbonden zijn. Op deze manier kan de bestemmeling van het bericht, via algoritmische
bewerkingen van het originele bericht, enerzijds het originele bericht en anderzijds de desbetreffende
identificatiegegevens uit het getekende bericht halen.
NB : . Wij merken op dat de vraag of de uitgehaalde identificatiegegevens wel degelijk deze
van de verzender zijn, hierbij niet wordt opgelost. Deze vraag komt aan bod bij de
'certificaten', die elders in dit document behandeld worden.
· De problematiek van het crypteren van het bericht is onafhankelijk van de problematiek
van de digitale handtekening, zelfs indien deze technisch gezien heel sterk bij elkaar
aanleunen (in die zin dat de digitale handtekening een beroep doet op
crypteringstechnieken).
Standaarden
Teneinde 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. Tot op
heden zijn er twaalf, genummerd van PKCS #1 tot PKCS #12, verschenen, waaronder de #2 en #4
verouderd zijn. Deze teksten refereren ook voortdurend naar de ISO-standaarden van de serie 500 (X.500,
X.501 en X.509), betreffende het repertorium (Directory), en maken gebruik van de notitie gedefinieerd in
X.208 en X.209 (ASN.1: Abstract Syntax Notation 1).
Het geheel van deze teksten vormt een actuele marktstandaard. Recentelijk is een andere standaard
verschenen voor de digitale handtekening, namelijk de XML-handtekening. Deze standaard wordt
momenteel niet gebruikt in het kader van Dimona, DMFA of ASR.
We merken op dat er andere verzamelingen van algoritmen en specificaties bestaan: bv. PGP (Pretty
Good Privacy), waarvan sommige gelijkwaardige of zelfs betere performanties of veiligheidsniveaus
aanbieden dan deze van de PKCS. In het algemeen zijn deze specificaties echter niet-standaard.
Praktische aspecten
De PKCS-standaarden bepalen hoofdzakelijk twee aspecten van de digitale handtekening: de te gebruiken
algoritmen en de syntaxis van het getekende bericht.
Handtekeningstechnieken
Het principe is uitermate eenvoudig en 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 algoritme naar keuze. Vervolgens
crypteert hij deze digest door gebruik te maken van zijn persoonlijke sleutel via asymmetrische cryptering.
Tenslotte voegt hij aan dit laatste resultaat zijn identificatiegegevens toe, vervat in een certificaat.
De bestemmeling van het bericht kan deze techniek omgekeerd toepassen, teneinde de geldigheid van de
handtekening te controleren. Hij haalt het certificaat uit teneinde 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 tenslotte 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.
21/08/2003
1
Bijlage 4 - DIMONA-aangifte
Syntactische aspecten
Een geheel van gegevens moet aan het originele bericht toegevoegd worden om de standaard digitale
handtekening te vormen:
 de gecrypteerde digest;
 de identificator van het gebruikte digestion-algoritme;
 het certificaat van de verzender;
 plus een aantal optionele gegevens (lijst van de herroepen
certificaten, andere erkende gegevens, etc.).
Bovendien mag eenzelfde bericht door verschillende ondertekenaars getekend worden.
Teneinde deze gegevens en het originele bericht op een ondubbelzinnige manier over te maken, is er een
uiterst nauwkeurige syntaxis gedetailleerd in de standaarden, gebaseerd op de gestandaardiseerde
syntaxis ASN.1.
Referenties
Wij beschikken over de teksten van de relevante PKCS en andere standaarden ter documentatie. In het
bijzonder zal er (zeker intensief) gebruik worden gemaakt van:
PKCS #1 :
RSA Encryption Standard;
PKCS #5 :
Password-Based Encryption Standard;
PKCS #7 :
Cryptographic Message Syntax Standard;
RFC 1422 :
Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based
Key Management.
De tekst van de PKCS is beschikbaar op de Website van RSA Data Security: http://www.rsa.com/
In de praktijk
Als het gaat over de transfer van ondertekende bestanden, rijzen er drie vragen:
1. welk type van digitale handtekening mag men gebruiken ?
2. wie is gemachtigd om een bericht te tekenen ?
3. hoe moeten de bestanden (DIMONA-bericht en handtekening) georganiseerd zijn ?
Types van handtekening
De RSZ erkent twee types van digitale handtekening:
1. De ISABEL-handtekening, die gebruikt moet worden indien via het ISABEL-netwerk gewerkt wordt;
2. De standaardhandtekening, die gebruikt wordt in alle andere gevallen en die gebaseerd is op de
PKCS-standaarden.
Wanneer het netwerk van ISABEL gebruikt wordt, moet de verzender zijn digitale ISABEL-handtekening
gebruiken. De berichten die door de Sociale Zekerheid naar de verzender worden verstuurd, zullen ook
een ISABEL- handtekening dragen.
In beide gevallen doen de handtekeningen een beroep op een certificaat, dat de identiteit van de
berichthandtekenaar 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 standaardhandtekening. Er bestaan trouwens talrijke leveranciers voor de standaardhandtekening. Om door de Sociale Zekerheid aanvaard te worden, moet een certificaat eigenlijk 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
21/08/2003
2
Bijlage 4 - DIMONA-aangifte
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.
Lijst van de aanvaarde certificaten :
CA
TYPES CERTIFICATEN
Belgacom E-Trust
High Grade Professional*
Belgacom ETrust**/Certipost
Qualified Certificate
GlobalSign
Personal Class 3 Pro
Isabel
Classe 3
* De certificaten High Grade Professional worden niet meer afgeleverd door Belgacom E-Trust sinds
11/9/2002. De laatste datum voor de aanvaarding van zulke certificaten is dus 11/9/2003.
** De certificatieactiviteiten van Belgacom werden overgenomen door Certipost in de loop van 2003.
Indien de standaardhandtekening gebruikt wordt, moeten de berichten beantwoorden aan de in de secties
hierna bepaalde specificaties.
Bestanden en organisatieschema
Slechts één organisatieschema voor de bestanden wordt aanvaard.
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.
De handtekening voldoet aan de normen opgenomen in de PKCS-standaarden, en in het bijzonder aan de
standaard PKCS #7: Cryptographic Message Syntax Standard. De gebruikte standaardversie is 1.5 van 1
november 1993.
Het gestructureerde bericht is geëncodeerd ASCII en als zodanig doorgestuurd in een bestand waarvan de
naam beantwoordt aan de normen bepaald in 'Methode om aangiftes door te sturen' in de glossaria.
Bijvoorbeeld, in het kader van Dimona is de bestandsnaam: DIMD.123456.20030801.00001.021.N.R
Voor een DMFA-bericht zonder versleuteling heeft de bestandsnaam de volgende structuur:
FI.DMFA.123456.20030801.00001.R.1.1
en voor de ASR-berichten hebben de bestandsnamen de volgende structuur:
FI.XXXX.123456.20030801.00001.R
waarbij XXXX bijvoorbeeld de volgende waarden kan aannemen:
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 meer details, zie de documentatie op het Portaal van de Sociale Zekerheid.
Voor de digitale handtekening is dit bericht omgevormd tot een OCTET STRING geëncodeerd DER, en
onderworpen aan de hashing-algoritme. Het resultaat van de hashing is inbegrepen in een type
AuthenticatedAttributes, en dit AuthenticatedAttributes wordt zelf onderworpen aan de algoritme voor
'digestion-encryption'. De details voor de berekening van de waarde van de handtekening worden gegeven
in de paragraaf 'berekening van de waarde van de handtekening' hieronder. Het voornaamste is dat de
elementen waaruit de handtekening bestaat, bevat zijn in een structuur van het type PKCS #7 ContentInfo,
die moet behoren tot het type signedData. Het veld SignedData wordt verderop beschreven.
21/08/2003
3
Bijlage 4 - DIMONA-aangifte
Dit ContentInfo is geëncodeerd base-64 en overgemaakt in een bestand waarvan de naam dezelfde
structuur heeft als het bijbehorende gegevensbestand, behalve dat het laatste karakter van het prefix niet
langer een D is maar wel een S. Voor een DIMONA-aangifte bijvoorbeeld zal het bestand dat de
handtekening bevat de volgende naam hebben:
DIMS.123456.20030801.00001.021.N.R
De twee bestanden DIMD en DIMS vormen, samen met een bestand van het type GODIMD.*, een
DIMONA-zending.
Voor een DMFA-aangifte heeft het bestand dat de handtekening bevat de volgende naam:
FS.DMFA.123456.20030801.00001.R.1.1
De twee bestanden FI en FS vormen, samen met een bestand GO.*, een DMFA-zending. Gelijkaardige
regels worden toegepast voor de ASR-aangiften. Voor details kan u terecht bij de documentatie
beschikbaar op het Portaal van de Sociale Zekerheid.
Structuur van de handtekening
Het veld SignedData, dat hierboven wordt beschreven, moet de volgende informatie bevatten:
Version
DigestAlgorithms
ContentInfo
ContentInfo.content
Certificates
Crls
SignerInfos
SignerInfo.version
IssuerAndSerialNumber
SignerInfo.digestAlgorithm
SignerInfo.authenticatedAttributes
SignerInfo.digestEncryptionAlgorithm
SignerInfo.unauthenticatedAttributes
EncryptedDigest
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 certification authority. Zie nota.
Niet verplicht
Minimum één.
Moet waarde 1 hebben (stemt overeen met versie 1.5 van PKCS
#7).
Identificator van de verzender van het certificaat en serienummer
van dit certificaat.
De toegelaten algoritmen zijn SHA-1, MD2 of MD5.
Verplicht. Het moet minimum bevatten:
 een attribuut (PKCS #9) van het type contentType, dat
noodzakelijk het type data bevat;
 een attribuut (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 attribuut (PKCS #9) van het type emailAddress met het
elektronisch adres van de verzender;
 attribuut (PKCS #9) van het type signingTime, met vermelding
van de datum en het uur wanneer de handtekening geplaatst
werd.
De toegelaten algoritme is rsaEncryption (bepaald in PKCS #1).
Niet verplicht.
Waarde van de handtekening.
Berekening van de waarde van de handtekening
Het messageDigest begrepen in de Authenticated.Attributes bevat de digest van het gestructureerde
bericht (ASCII, in een OCTET STRING geëncodeerd DER; enkel de inhoud van de OCTET STRING wordt
verwerkt, niet de identificatie-bytes, noch de lengte-bytes). Het veld authenticatedAttributes zelf wordt
vervolgens onderworpen aan het 'digestion-encryption'-mechanisme. Meer bepaald: men begint met het
uitvoeren van een hashing van het veld 'geauthentificeerde attributen'; vervolgens stelt men een DigestInfo
samen, die een sequentie is samengesteld uit de identificator van de algoritme gebruikt voor deze hashing
en uit het resultaat van deze hashing: tenslotte wordt de BER-codering van deze DigestInfo onderworpen
aan de algoritme RSA voor codering.
21/08/2003
4
Bijlage 4 - DIMONA-aangifte