ANNEXE 4

21/08/2003 1 Annexe 4 - Déclaration DIMONA
ANNEXE 4 : Signature digitale
Principes de la signature digitale
La signature digitale consiste à transformer, par des manipulations algorithmiques données, un message
original en un nouveau message (le message signé) auxquelles des données d’identification (idéalement,
celles de l’expéditeur) sont intimement liées. De la sorte, le destinataire du message pourra, par des
transformations algorithmiques appropriées appliquées au message d’origine, extraire du message signé
d’une part le message original, d’autre part les données d’identification en question.
NB : · On remarquera que la question de savoir si les données d’identification extraites sont
bien celles de l’expéditeur est une question qui n’est pas résolue ici. Cette question fait
l’objet des certificats, traités par ailleurs dans ce document.
· La problématique du cryptage du message est indépendante de la problématique de la
signature digitale, même si elle est techniquement fort proche (en ce sens que la
signature digitale fait appel à des techniques de cryptographie).
Standards
Afin de permettre une certaine flexibilité des produits de signature digitale, une série de standards sont
publiés sous l’égide de RSA Laboratories, la branche R&D de RSA Digital Security, Inc. Ces standards
sont intitulés PKCS: Public-Key Cryptography Standards. Jusqu’à présent douze d’entre eux, numérotés
de PKCS #1 à PKCS #12, ont été publiés, parmi lesquels les #2 et #4 sont obsolètes. Ces textes font
aussi référence constante aux standards ISO de la série 500 (X.500, X.501 et X.509), relatifs au
Répertoire (Directory), et font usage de la notation définie dans X.208 et X.209 (ASN.1: Abstract Syntax
Notation 1).
L’ensemble de ces textes constitue un standard actuel du marché. Un autre standard est apparu plus
récemment concernant la signature digitale, à savoir la signature XML. Ce standard n'est pas utilisé pour
le moment dans le cadre de DIMONA/DMFA/DRS.
Notons que d’autres ensembles d’algorithmes et de spécifications existent: citons par exemple PGP
(Pretty Good Privacy), dont certains offrent des performances ou des niveaux de sécurité équivalents
sinon meilleurs que ceux de PKCS. Cependant ces spécifications sont en général propriétaires.
Aspects pratiques
Les standards PKCS définissent essentiellement deux aspects de la signature digitale : les algorithmes à
utiliser et la syntaxe du message signé.
Techniques de signature
Le principe est extrêmement simple, et repose sur l’utilisation combinée d’algorithmes de hashing (MD2,
MD5, SHA-1) et d’algorithmes de cryptage asymétrique (RSA). Pour signer un message, l’expéditeur
calcule d’abord le “digest” du message d’origine à l’aide d’un algorithme au choix. Ensuite, il crypte ce
digest en utilisant sa clé privée par cryptage asymétrique. Il associe finalement à ce dernier résultat ses
données d’identification, contenues dans un certificat.
Le destinataire du message peut appliquer la technique inverse afin de vérifier la validité de la signature: il
extrait le certificat afin de déterminer l’identité de l’expéditeur supposé et sa clé publique; il utilise cette clé
publique pour décrypter le digest en utilisant le même algorithme de cryptage asymétrique que
l’expéditeur, et finalement, il calcule lui-même le digest du message reçu et le compare au digest extrait
de la signature: la concordance des valeurs des deux digests garantit l’authenticité du message.

21/08/2003 2 Annexe 4 - Déclaration DIMONA
Aspects syntaxiques
Un ensemble de données doivent être jointes au message d’origine pour constituer la signature digitale
standard :
· le digest crypté ;
· l’identifiant de l’algorithme de digestion utilisé ;
· le certificat de l’expéditeur ;
· plus une série de données optionnelles (liste de certificats
révoqués, autres données authentifiées, etc).
De plus, un même message peut être signé par plusieurs signataires différents.
Afin de permettre la transmission de ces données et du message d’origine de manière non-ambiguë, une
syntaxe extrêmement précise est détaillée dans les standards, basée sur la syntaxe standardisée ASN.1.
Références
Nous disposons comme documentation des textes des PKCS pertinents et d’autres standards.
En particulier, un usage (certainement intensif) sera fait de :
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.
Le texte des PKCS est disponible sur le site Web de RSA Data Security : http://www.rsa.com/
En pratique
Lorsqu'il s'agit de transmettre des fichiers signés, les questions qui se posent sont de trois ordres:
1. quel type de signature digitale peut-on utiliser ?
2. qui est autorisé à signer un message ?
3. comment les fichiers (message structuré et signature) doivent-ils être organisés ?
Types de signature
L’ONSS reconnaît deux types de signatures digitales :
1. la signature ISABEL, qui doit être utilisée lorsque le réseau mis en œuvre est le réseau ISABEL ;
2. la signature standard, utilisée dans les autres cas et basée sur les standards PKCS.
Lorsque le réseau utilisé est le réseau ISABEL, l’expéditeur doit utiliser sa signature digitale ISABEL.
Les messages émis par la Sécurité Sociale vers l'expéditeur porteront également une signature ISABEL.
Dans les deux cas, les signatures font appel à un certificat, qui garantit l’identité du signataire du
message; ces certificats peuvent être obtenus auprès d'un Prestataire de Service de Certification
(également appelé 'Certification Authority', ou, en abrégé, CA). Si l'on utilise la signature ISABEL, le CA
doit nécessairement être ISABEL. Notons que ISABEL fournit également des certificats pour la signature
standard. Il existe d'ailleurs de nombreux fournisseurs de certificats pour la signature standard. En fait,
pour être accepté par la Sécurité Sociale, un certificat doit répondre à deux contraintes :
· l’origine du certificat : le Système d’Information de la Sécurité Sociale est en mesure de valider les
certificats délivrés par les autorités de certification qui figurent dans la liste publiée sur le site-portail
de la sécurité sociale (voir ci-dessous). Les certificats délivrés par d’autres autorités de certification

21/08/2003 3 Annexe 4 - Déclaration DIMONA
ne peuvent être acceptés, à la demande d'un utilisateur, que dans la mesure où les adaptations
nécessaires à la validation de ces certificats auront été apportées au Système d’Information.
· le type de certificat : seuls les certificats attribués aux personnes physiques, qui se sont présentées
physiquement lors de la procédure de certification pourront être acceptés.
Les Prestataires de Service de Certification mentionnés dans la liste ci-dessous ont été retenus parce
qu'ils garantissent un certain niveau de qualité des certificats délivrés en terme de fiabilité de
l’infrastructure utilisée pour gérer les certificats, de vérification de l’identité du détenteur d’un certificat ou
de sécurité des clés de cryptage utilisées.
Liste des certificats acceptés :
CA TYPES de CERTIFICATS
Belgacom E-Trust High Grade Professional*
Belgacom E-
Trust**/ Certipost
Qualified Certificate
GlobalSign Personal Class 3 Pro
Isabel Classe 3
* Les certificats High Grade Professional ne sont plus délivrés par Belgacom E-Trust depuis le 11/9/2002.
La date ultime d'acceptation de tels certificats est donc le 11/9/2003.
** Les activités de certification de Belgacom ont été reprises par l'entité Certipost dans le courant de 2003.
Si la signature standard est utilisée, les messages doivent répondre aux spécifications définies dans les
sections ci-après.
Fichiers et schéma d'organisation
Un seul schéma d’organisation des fichiers est accepté.
Il s'agit d'un schéma à deux fichiers, l’un contenant le message structuré (DIMONA, DMFA ou DRS) en
clair, non encrypté et l’autre la signature digitale .
La signature répond aux normes contenues dans les standards PKCS, et en particulier PKCS #7:
Cryptographic Message Syntax Standard. La version du standard utilisée est la version 1.5 datée du 1er
novembre 1993.
Le message structuré est encodé ASCII et transmis tel quel dans un fichier dont le nom répond aux
normes édictées dans la section “Méthode pour envoyer des déclarations" dans les glossaire :
Par exemple, dans le cas de DIMONA le nom du fichier sera: DIMD.123456.20030801.00001.021.N.R
Pour un message en clair DMFA, le nom de fichier aura la structure:
FI.DMFA.123456.20030801.00001.R.1.1
et pour les messages DRS, les noms de fichier auront les structures
FI.XXXX.123456.20030801.00001.R
où XXXX peut par exemple prendre les valeurs suivantes :
WECH lorsqu'il s'agit de DRS chômage;
AOAT lorsqu'il s'agit de DRS accident du travail;
BZMP lorsqu'il s'agit de DRS maladies professionnelles;
ZIMA lorsqu'il s'agit de DRS A.M.I
Pour des détails, on se reportera à la documentation disponible sur le Portail de la Sécurité Sociale.
Pour la signature digitale, ce message est transformé en un OCTET STRING encodé DER, et soumis à
l’algorithme de hashing. Le résultat du hashing est inclus dans un type AuthenticatedAttributes, et cet
AuthenticatedAttributes est lui-même soumis à l’algorithme de “digestion-encryption”. Les détails pour le
calcul de la valeur de la signature sont fournis dans le paragraphe 'calcul de la valeur de la signature', ci-
dessous. L'essentiel est que les éléments constitutant la signature soient contenus dans une structure de
type PKCS #7 ContentInfo, qui doit être de type signedData. Le champ SignedData est décrit ci-dessous.

21/08/2003 4 Annexe 4 - Déclaration DIMONA
Ce ContentInfo est encodé base-64 et transmis dans un fichier dont le nom a la même structure que le
fichier de données correspondant, mais le dernier caractère du préfixe n'est plus un D mais un S. Par
exemple, pour une déclaration DIMONA, le fichier contenant la signature aura pour nom :
DIMS.123456.20030801.00001.021.N.R ;
L'ensemble des deux fichiers DIMD et DIMS, accompagné par un fichier GODIMD.* constitue un envoi
DIMONA.
Pour une déclaration DMFA, le fichier contenant la signature aura pour nom
FS.DMFA.123456.20030801.00001.R.1.1
L'ensemble des deux fichiers FI et FS, accompagné par un fichier GO.* constitue un envoi DMFA. Des
règles équivalentes s'appliquent aux déclarations DRS. Pour des détails on se reportera à la
documentation disponible sur le Portail de la Sécurité Sociale.
Structure de la signature
Le champ SignedData mentionné ci-dessus doit contenir les informations suivantes :
Version Doit valoir 1 (correspond à la version 1.5 de PKCS #7).
DigestAlgorithms Les algorithmes admis sont SHA-1, MD2 ou MD5.
ContentInfo Doit contenir un data qui doit obligatoirement être vide
(présent, mais de longueur nulle).
ContentInfo.content Obligatoirement vide.
Certificates Doit contenir (au moins) un certificat (de classe agréée)
délivré par une autorité de certification reconnue. Voir note.
Crls Pas obligatoire
SignerInfos Minimum un.
SignerInfo.version Doit valoir 1 (correspond à la version 1.5 de PKCS #7).
IssuerAndSerialNumber Identifiant de l'émetteur du certificat et numéro de série de ce
certificat
SignerInfo.digestAlgorithm Les algorithmes admis sont SHA-1, MD2 ou MD5.
SignerInfo.authenticatedAttributes Obligatoire. Il doit contenir au minimum
· un attribut (PKCS #9) de type contentType, contenant
nécessairement le type data,
· un attribut (PKCS #9) de type messageDigest,
contenant le digest du message structuré. Voir 'calcul
de la valeur de la signature'.
Il peut contenir aussi
· un attribut (PKCS #9) de type emailAddress contenant
l’adresse électronique de l’émetteur,
· un attribut (PKCS #9) de type signingTime, portant la
date et l’heure où la signature a été apposée.
SignerInfo.digestEncryptionAlgorithm L’algorithme admis est rsaEncryption (défini dans PKCS #1).
SignerInfo.unauthenticatedAttributes Pas obligatoire.
EncryptedDigest Valeur de la signature
Calcul de la valeur de la signature
Le messageDigest inclus dans les Authenticated.Attributes contient le digest du message structuré
(ASCII, dans un OCTET STRING encodé DER; seul le contenu de l’OCTET STRING est digéré, pas les
octets d’identification ni les octets de longueur). Le champ authenticatedAttributes lui-même est ensuite
soumis au mécanisme de “digestion-encryption”. Plus précisément: on commence par effectuer un
hashing du champ 'attributs authentifiés'; ensuite, on constitue un DigestInfo, qui est séquence composée
de l'identifiant de l'algorithme utilisé pour ce hashing et du résultat de ce hashing; enfin, le codage BER de
ce DigestInfo est soumis à l'algorithme RSA de chiffrement.