La signature lectronique, contexte, applications et mise en uvre.

Jean-Luc Parouty
INRIA / Direction des Rseaux et des Systmes dInformation (DRSI) 655 Avenue de l'Europe - 38330 Montbonnot France Jean-Luc.Parouty@inria.fr

Roland Dirlewanger
CNRS - Dlgation Aquitaine et Poitou-Charentes (DR15) Esplanade des Arts et Mtiers - 33402 Talence cedex rd@dr15.cnrs.fr

Dominique Vaufreydaz
INRIA Rhne-Alpes / projet PRIMA 655 Avenue de l'Europe - 38330 Montbonnot France Dominique.Vaufreydaz@inrialpes.fr

Rsum
Depuis toujours, le document papier est notre support privilgi ds lors quil nous est ncessaire de conserver le tmoignage dun accord entre plusieurs parties. Traditionnellement, et dfaut de pouvoir en protger lintgrit, lusage de sceaux ou de signatures, permet de garantir lauthenticit de tels documents. Avec lutilisation croissante des outils de communication immatriels , que sont le tlphone, le fax ou encore lInternet, le problme de la protection de nos changes est devenu particulirement critique. Les progrs conjugus des mathmatiques et de linformatique ont permis, depuis les annes 1970, de disposer progressivement dun panel complet de solutions algorithmiques et de standards adapts la certification de nos documents lectroniques. Avec la criticit croissante de nos changes et la disponibilit de solutions techniques avres, la mise en place progressive dun cadre juridique adapt est venu complter lensemble. Aprs un bref rappel des techniques et un tour dhorizon du contexte juridique, nous nous intresserons aux diffrents outils disponibles et leurs limites, puis nous prsenteront brivement les travaux raliss autour dun prototype dapplet signeuse : Sign@tor.

Mots clefs
Signature lectronique, Parapheur lectronique, Certificats, Signature simple, Signature avance, Contractualisation, Niveaux de contractualisation, Signator, Formulaire HTML, XML Signature, XAdES.

1. Rappels / Dfinition
1.1 Principe de la signature lectronique
La signature lectronique repose sur deux familles dalgorithmes, qui seront utiliss de manire complmentaire : - des algorithmes de chiffrement dit asymtriques ou clef publique . - des fonctions de hachages

1.1.1

Algorithmes asymtriques

Le concept dalgorithmes clef asymtrique a t prsent pour la premire fois en 1976 par Whitfield Diffie et Martin Hellman1. Il faudra nanmoins attendre 1978, pour quun tel systme soit prsent, par Ronald Rivest, Adi Samir et Leonard Adelman2. Ainsi naquit lalgorithme RSA3. Le principe dun algorithme asymtrique est relativement simple. Un couple de clefs numriques est construit de manire ce que le cryptogramme gnr partir dun texte clair et lune des clefs ne puisse tre aisment retrouv quavec lautre clef.
1 2

Whitfield Diffie et Martin Hellman, National Computer Conference, 1976. Rivest, R. L., Shamir, A., Adelman, L. A.: A method for obtaining digital signatures and public-key cryptosystems; Communications of the ACM, Vol.21, Nr.2, 1978, S.120-126 3 RSA est constitu des initiales des trois auteurs Rivest, Adelman et Shamir.

En pratique, lune des clefs est conserve secrtement (clef prive), tandis que lautre est diffuse publiquement (clef publique). Seul le propritaire dune clef prive (Alice dans notre exemple) aura pu chiffrer un texte dchiffr avec la clef publique associe (figure 1). Lauthenticit du document peut tre ainsi garantie.

1.1.2

Fonction de hachage

Les fonctions de hachages sont des fonctions sens unique et sans collision , gnrant une sortie de taille fixe (appele condensat ou empreinte), caractristique des donnes fournies en entre. Figure 1 : Algorithmes asymtriques Ces fonctions sont dites sens unique car il est impossible de retrouver les donnes initiales partir de lempreinte. Une fonction est dite sans collision ou injective lorsquil est rput trs difficile de trouver deux sources diffrentes conduisant un mme rsultat. Figure 2 : Fonction de hachage Le calcul du condensat dun document et la comparaison de celui-ci avec sa valeur initiale permet de contrler lintgrit dun document (figure 2).

1.1.3

Construction et vrification d'une signature

La signature lectronique va faire appel ces deux familles dalgorithmes, afin de pouvoir garantir lauthenticit et lintgrit dun document (figure 3). Les algorithmes asymtriques usuellement utiliss sont RSA et DSA4, les fonctions de hachages les plus courantes dont MD55 et SHA6.

1.2

Limite du modle - Problmatique de la confiance dans la clef

Le processus de vrification de la signature repose totalement sur la confiance qua le vrificateur dans la cl publique de lmetteur. Dans lexemple prcdent, lattaque classique consiste transmettre Bob par un moyen quelconque la cl publique dun tiers et de le convaincre quil sagit de celle dAlice. Tout Figure 3 : Principe message sign avec la cl prive algorithmique de la correspondante sera considr par Bob signature lectronique comme tant sign par Alice. La transmission Bob de la cl publique dAlice doit donc seffectuer par un moyen sr. Pourquoi pas de la main la main ? Cest la technique de lanneau de confiance (public key ring) qui est utilis dans PGP7 : Alice signe un certain nombre de cls publiques dont elle peut certifier le titulaire. Elle transmet Bob sa cl publique, par un moyen sr, et la liste des cls publiques quelle a signes, par un moyen quelconque. Bob peut
4 DIGITAL SIGNATURE STANDARD (DSS), Federal Information Processing Standards, Publication 186, 1994 May 19, http://www.itl.nist.gov/fipspubs/fip186.htm 5 R.L. Rivest, RFC 1321: The MD5 Message-Digest Algorithm, Internet Activities Board, 1992, http://www.ietf.org/rfc/rfc1321.txt?number=1321 6 SECURE HASH STANDARD, Federal Information Processing Standards, Publication 180-1, 1995 April 17, http://www.itl.nist.gov/fipspubs/fip180-1.htm 7 P.R. Zimmermann, The Official PGP Users Guide, Boston, MIT Press, 1995

alors choisir daccorder sa confiance dans toutes ces cls, et, ventuellement, dans toutes les cls publiques signes par les titulaires de celles-ci. Ce processus peut, en quelques changes, certifier un grand nombre de cls. Toutefois, si la population devient trs importante ou si les liens entre les utilisateurs ne permettent pas de faire des changes srs, il parat difficile de garantir qu tout moment un utilisateur dispose dans son anneau de confiance de toutes les cls publiques dont il a besoin. La solution consiste faire signer une information sur lidentit ainsi que la cl publique de chaque utilisateur par une autorit en laquelle tous les partenaires ont confiance. Chaque utilisateur na besoin de rcuprer de faon sre quune seule cl publique, celle de lautorit. Grce cette cl, il peut valider les cls publiques de tous les utilisateurs. Cest cette ide qui est la base des certificats X.509 et des infrastructures de gestions de cls (IGC) : un certificat contient des informations sur son titulaire (nom, prnom, adresse lectronique, organisme, ), des informations sur lautorit qui a sign le certificat, une date de dbut et une date de fin de validit, la cl publique du titulaire, les usages autoriss pour ce certificat, etc. Le tout est sign par la cl prive de lautorit qui a mis le certificat. Cette dernire est appele autorit de certification. Elle dispose elle mme dun certificat, soit autosign, soit sign par une autorit de niveau suprieur. Afin de faciliter la vrification des signatures, les documents ou messages signs contiennent le certificat du signataire. Ainsi, pour vrifier la signature des messages reus dAlice, Bob effectue les oprations suivantes : - il extrait le certificat dAlice du document ou du message - il vrifie la signature du certificat en utilisant la cl publique contenue dans certificat de lautorit de certification qui a mis le certificat dAlice. - il vrifie la validit du certificat (dates de validit, non rvocation, etc...) - il vrifie la signature du message en utilisant la cl publique contenue dans le certificat dAlice. En fin de compte, la confiance dans les cls publiques dune population potentiellement grande dutilisateurs est ramene la confiance dans un petit nombre de cls publiques dautorits de certification.

1.3

Horodatage

Nombreuses sont les procdures administratives qui mettent en jeu la date denvoi des documents : dpt de candidatures, rponses des appels doffres, dclarations diverses, etc. Les mcanismes traditionnels utilisent le cachet de la poste. La dmatrialisation de telles procdures passe par un quivalent lectronique ce cachet de la poste. Le format PKCS#7 qui dcrit les conteneurs de donnes signes dans la messagerie lectronique inclut un champ pour indiquer la date laquelle le message a t sign. Cest toutefois la date et lheure du poste de travail du signataire qui sont utiliss dans ce champ. Lmetteur peut donc tricher en indiquant des dates fausses. De la mme faon, un tiers mal intentionn ayant rcupr une cl prive associe un certificat prim peut ramener artificiellement la date de sa machine dans la priode de validit du certificat et mettre des documents signs. La signature lectronique dun Figure 4 : Principe de l'horodatage document est donc indissociable dun mcanisme qui garantit que le document existait une date et une heure donne et na pas t altr depuis. Cest lhorodatage. Il consiste transmettre une autorit de confiance, appele autorit dhorodatage, une requte comprenant le condensat du document horodater. Lautorit renvoie au demandeur un jeton dhorodatage, le condensat, une date et une heure, le tout sign par lautorit dhorodatage (figure 4).

1.4

Signature ou visa

Le titulaire dun certificat X.509 peut authentifier des documents grce la signature lectronique. Il peut galement sauthentifier auprs de sites WWW qui utilisent le protocole HTTP sur SSL ou TLS. Imaginons une application WWW authentifie qui gre les congs dans un tablissement. Bob remplit un formulaire WWW de demande de congs. Lapplication WWW notifie Alice, son suprieur hirarchique. Elle accde au formulaire WWW qui affiche la demande de Bob ainsi que deux boutons jaccepte cette demande et je refuse cette demande . Si cette application WWW est authentifie par certificats, on peut admettre que seul Bob a pu transmettre la demande et seule Alice a pu laccepter ou la refuser. Pourtant, il ny a pas eu de signature lectronique8. En pratique, ce mcanisme ne peut pas rsister un contentieux. En effet, si lapplication sappuie sur une base de donnes, les administrateurs de cette base ont la possibilit de rajouter ou modifier des enregistrements correspondant la demande de congs de Bob. Dans ce type dapplications, on parlera plutt de visa lectronique. Le visa lectronique ncessite de la part de lutilisateur qui lappose un mcanisme dauthentification quivalent celui de la signature lectronique. Il peut toutefois tre dtourn par des personnes disposant de privilges levs sur lapplication qui utilise ce visa. Dans des organisations o ces personnes sont rputes de bonne foi, on pourra accepter un visa lectronique au mme titre quune signature. Il faudra toutefois bien garder lesprit que le visa ne peut pas avoir la mme valeur probante que la signature lectronique.

1.5

Normes et standards

Il existe un nombre considrable de normes et de standards qui rgissent les certificats, la signature lectronique, lidentification des algorithmes cryptographiques, les messages signs, etc. Nous nous focaliserons dans ce paragraphe sur celles qui seront utiles dans la suite. Avant tout, rappelons-nous que les certificats X.509 sont directement drivs des travaux de lISO (International Standardisation Organisation) sur linterconnexion de systmes ouverts (OSI, Open Systems Interconnection). Au centre de ces travaux, il y a la reprsentation pour ltre humain dune part, pour les machines dautre part, de donnes structures manipules par les divers protocoles. Un langage volu (ASN.1, Abstract Syntax Notation One) a t conu pour dcrire ces Certificate: structures. Des mcanismes (BER, Basic Encoding Data: Rules) ont t dfinis pour encoder de faon Version: 3 (0x2) standard ces structures de donnes sur nimporte Serial Number: 807 (0x327) quelle plate-forme afin quelle puisse tre dcodes Signature Algorithm: md5WithRSAEncryption et reconstitues sur nimporte quelle autre. Les mcanismes de codage de BER produisent des Cette section na pas de syntaxe propre. Elle est destine la lecture par des tres humains. donnes binaires. Traditionnellement, les On peut la considrer comme un commentaire technologies de lInternet prfrent manipuler des chanes de caractres ASCII organises en lignes -----BEGIN CERTIFICATE----plus ou moins comprhensibles directement par un MIIEYjCCA0qgAw () humain. Le compromis entre ces deux usages a Codage Base64 du certificat. Seule cette priori orthogonaux a t dutiliser le codage section et les deux balises importent. Base64 qui permet de transformer un document ( )JHGJYUY Figure 5 : Certificat binaire en une suite de caractres ASCII. La partie -----END CERTIFICATE----X509 au format PEM Base64 est entoure dune balise de dbut et dune balise de fin caractristique du contenu. Toute chane de caractres qui se trouve en dehors de ces balises est considre comme du commentaire. Ce format est communment appel le format PEM (Privacy Enhanced Mail), du nom des standards de lInternet relatifs lauthentification et la confidentialit dans la messagerie lectronique. La figure 5 donne une ide de la reprsentation au format PEM dun certificat X.509.
Description en clair du contenu dun certificat.

8 En fait, si. Dans la phase dauthentification du protocole SSL ou TLS, le serveur demande au client de signer une suite doctets dont il a gnr alatoirement une partie. Il sassure ainsi que le client a accs la cl prive du certificat de lutilisateur.

Le format DER (Distinguished Encoding Rules) correspond aux donnes binaires contenues dans un fichier PEM. Cest donc le rsultat du dcodage Base64 des donnes contenues entre la balise de dbut et la balise de fin. Il faut un interprte ASN1 pour les afficher ou les manipuler, comme par exemple, openssl9 ou pp10 . Les PKCS (Public-Key Cryptography Standards) dfinissent douze standards (de PKCS#1 PKCS#12) pour spcifier lutilisation dalgorithmes de chiffrement ou dchanges de cls, les interfaces avec des modules cryptographiques, les certificats, les requtes de certificats, les conteneurs de diverses natures. Par exemple, PKCS#6 dcrit les certificats. Cest un sur-ensemble des certificats X.509. Arrtons-nous sur les deux PKCS les plus courants : le 7 et le 12. Le PKCS#7 dcrit les conteneurs de donnes. Il peut sagir de donnes signes, chiffres, signes et chiffres ou bien dune liste de certificats dautorits de certification, etc. Le PKCS#12, galement connu sous le nom de PFX, dcrit les mcanismes qui permettent de garantir lintgrit et la confidentialit de donnes comme des cls prives, des certificats dutilisateurs ou dautorits de certification. Cest le format utilis pour sauvegarder ou pour transporter des certificats dutilisateurs et les cls prives correspondantes. Les donnes contenues dans un fichier au format PKCS#12 sont protges par un certain nombre de cls. Lune sert au contrle dintgrit des donnes, les autres servent chiffrer/dchiffrer des donnes confidentielles comme les cls prives. En pratique, les outils usuels comme les navigateurs nutilisent quune seule cl pour toutes ces oprations. Cette cl est dfinie par lutilisateur au moment o il exporte son certificat et sa cl prive. Elle est demande au moment o il importe son certificat. Le format S/MIME11 dfinit une collection de types MIME permettant denvoyer et de recevoir des donnes signes, chiffres ou les deux la fois via la messagerie lectronique. Les donnes en question peuvent tre elles mmes des parties MIME, comme dans le cas o on signe un message lectronique contenant un document attach. S/MIME dcrit notamment les types multipart/signed , application/pkcs7-signature et application/pkcs7-mime . A ces standards historiques peuvent tre ajout plusieurs nouveaux standards mieux adapts nos besoins fonctionnels, en provenance notamment du monde XML. XML Signature Ce premier standard est le rsultat du groupe de travail XML Signature WG qui est un groupe conjoint du W3C et de lIETF. De ces travaux sont issus une Recommandation du W3C et une Standard track de lIETF, XML-Signature Syntax and <?xml version="1.0" encoding="UTF-8" ?> Processing12 / RFC327513.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod () /> <SignatureMethod Algorithm=() />

<Reference URI="#object"> <DigestMethod Algorithm=() /> <DigestValue>7/XT()Ysk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>ov3HOo()3L4=</SignatureValue> <KeyInfo> <KeyValue> <RSAKeyValue> <Modulus>q07()WkArc=</Modulus> <Exponent>A()AB</Exponent> </RSAKeyValue> </KeyValue> </KeyInfo> Figure 6 : <Object Id="object">some text</Object> Signature XML </Signature>

XML Signature a t conu pour permettre la signature des changes XML. Pour cela, lessentiel des fonctionnalits offertes par les signatures de type PKCS ont t reprises, avec un certain nombre dapports propres XML, dont le principal est sans doute la possibilit offerte de pouvoir ne signer quune partie de larbre XML, autrement dit dun document. La signature dun document va consister construire une liste de rfrences (URI), puis de calculer pour chacune dentres elles un condensat. Cette liste de condensat fera son tour lobjet dun hachage, qui sera sign. On pourra alors ajouter divers lments, tels que le certificat du signataire. Les rfrences tant des URI, ces dernires

http://www.openssl.org http://www.mozilla.org RFC 2311 12 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 13 http://www.ietf.org/rfc/rfc3275.txt

10 11

peuvent tre internes ou externe au document, concerner tout ou partie de celui-ci, etc. La figure 6 offre un exemple de signature XML. A noter, que la matrise dASN1 est ici facultative :-) Plusieurs implmentations de XML Signature sont actuellement disponibles14, on peut citer : - XMLsec15, diffus sous licence MIT et qui peut appuyer sur les couches cryptographiques dOpenSSL, Mozilla (NSS), GnuTLS ou Microsoft MSCryptoAPI. XMLsec propose une API C++. - Apache XML Security16, du groupe Apache, diffus sous licence Apache Software Licence, qui propose une double API, Java et C++. XML Advanced Electronic Signatures (XAdES) XAdES est une extension de XML Signature. Les extensions concernent notamment le domaine de la nonrpudiation, en dfinissant des formats XML pour les Signatures lectroniques avances susceptibles de rester valides pendant de grandes priodes, conformment la Directive Europenne 1999/93/EC . XAdES17 est le rsultat des travaux de la section STF 178 de lETSI18. Une note W3C reprend ces spcifications, en vue dune recommandation W3C19. Concernant la mise en uvre de XAdES, si les implmentations ne sont pas extrmement nombreuses, il est nanmoins incontournable de citer linitiative OpenXAdES, qui, comme le nom lindique, est une initiative ouverte autour de XAdES. Dans le but de favoriser leurs changes, la Finlande et lEstonie ont dploys une carte didentit lectronique commune20, permettant lauthentification forte et la signature lectrique. Accessoirement, cest galement une carte dindent reconnue dans 19 pays europens ;-) 30 environ, valable 3 ans. Afin dtre en conformit avec la Directive europenne 1999/93/CE , un important travail t entrepris au sein dun projet darchitecture de signature lectronique appel DigiDoc , qui sest appuy sur les spcifications de XAdES. A ce jour, le projet DigiDoc offre (ct Estonie21) : - Un client, permettant de vrifier une signature lectronique et de signer un document avec sa carte didentit lectronique - Un portail DigiDoc, offrant, outre les fonctions du client tlchargeable, la possibilit de signature multiple et collaborative (dpt pour signature 1 ou n signataires) - Un format de signature [bas sur XAdES] - Un ensemble de librairies, permettant limplmentation de clients. La Smart Card (traduction Finlando-anglaise ;-) est actuellement en production aussi bien ct Finlande que ct Estonie22

2. Aspects juridiques
2.1 Contexte juridique
Le cadre juridique dfinissant le statut de la signature lectronique en France, et plus gnralement en Europe, est le rsultat de la transposition de la directive europenne 1999/93/CE. Les diffrents textes sont : - 1999 : Directive Europenne 1999/93/CE - 2000 : Loi n2000-230 du 13 mars 2000 : Prise en compte de la signature lectronique au sein du code civil.

14 15

http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html http://www.aleksey.com/xmlsec 16 http://xml.apache.org/security/index.html 17 Rfrence ETSI : ETSI TS 101 903 V1.1.1 (2002-02) 18 European Telecommunications Standards Institute (ETSI), http://www.etsi.org, Portail technique : http://portal.etsi.org 19 Rfrence W3C : http://www.w3.org/TR/2003/NOTE-XAdES-20030220/ 20 Les organismes Finlandais et Estoniens du projets sont : le AS Sertifitseerimiskeskus et le Finnish Vestrekisterikeskus accessibles aux URLs suivantes : http://www.sk.ee et http://www.fineid.fi Pour en savoir plus, voir The Estonian ID Card and Digital Signature, Concept Principles and Solutions, Whitepaper Version: June 5, 2003 : http://www.id.ee/file.php?id=122 21 Pour en savoir plus : http://www.id.ee 22 Les statistiques Estoniennes, indiquent que plus de 300.000 id-kaart sont actuellement en circulation, dont 10% pour des non estoniens.

- 2001 : Dcret n 2001-272 du 30 mars 2001 Transposition de la Directive Europenne 1999/93/CE - 2002 : Dcret n 2002-535 du 18 avril 2002 Attribution du rle de certificateur la DCSSI - 2002 : Arrt du 31 mai 2002 Attribution du rle daccrditeur au COFRAC, pour lvaluation des prestataires de certification lectronique.

2.2

Synthse

Les textes dfinissent deux types de signatures ; La signature lectronique simple, qui nest pas prsume fiable jusqu preuve du contraire. En cas de contestation, cest donc celui qui veut se prvaloir des effets juridiques de cette signature d'apporter la preuve de la fiabilit du systme mis en uvre. La signature lectronique prsume fiable, qui ne peut tre conteste quen apportant la preuve de sa non fiabilit. Pour tre prsume fiable , un procd de signature lectronique doit remplir trois conditions : - La signature lectronique est scurise - La signature lectronique est tablie grce un dispositif scuris de cration de signature - La vrification de la signature lectronique repose sur lutilisation dun certificat lectronique qualifi, mis par un prestataire de service de certification lectronique. Les diffrentes exigences sont rsumes dans la figure 7.

Figure 7 : Cadre juridique de la signature lectronique en France

3. Contractualisation des actes lectroniques

3.1 Niveau de contractualisation
Par contractualisation dune procdure lectronique , nous entendons le fait de confrer une procdure lectronique une valeur contractuelle. Cela passe gnralement par lacceptation des diffrentes parties des mmes termes dun contrat, avec une preuve de cette acceptation rciproque. Dans ce contexte, la disponibilit dune signature lectronique prsume fiable au sein dun document lectronique devrait offrir une solution parfaitement adapte Mais les choses ne sont pas aussi simple ;-) Comme nous lavons vu, il nest pas facile de pouvoir rpondre lensemble des exigences indispensables la mise en uvre dune telle signature. Aussi dans la pratique, plusieurs niveaux de contractualisation peuvent tre identifis23 : - Un premier niveau, bas sur la simple dissuasion, repose sur une authentification dclarative sans vritable contrle. On peut citer les demande d'extrait de casier judiciaire (bulletin n3). o le formulaire lectronique de demande, se contente de prciser : L'extrait de casier judiciaire ne peut tre demand que par la personne qu'il concerne ou son reprsentant lgal s'il s'agit d'un mineur ou d'un majeur sous tutelle. Et de prciser : Se faire dlivrer l'extrait de casier judiciaire d'un tiers est sanctionn par la loi (article 781 du Code de procdure pnale). - Un deuxime niveau de contractualisation peut tre dfinit lorsque des moyens organisationnels et techniques sont mis en uvre afin de garantir au mieux lidentit des diffrents acteurs, sans pour autant que lon puisse parler de preuve au sens juridique du terme. On peut citer en exemple les achats en lignes o le vendeur se contente didentifier une carte bleue (et peut-tre son propritaire ;-) Plus sr en terme de scurit, mais tout aussi dpourvu de valeur de preuve , lusage dun accs restreint par login/mot de passe sur un systme dinformation nest gure plus satisfaisant dun point de vue contractualisation. - Un troisime niveau peut tre dfini, lorsque lon rentre dans le primtre de la signature lectronique simple . Un document lectronique sign est recevable dun point de vue juridique, mme si en cas de contestation la preuve de sa fiabilit reste apporter. A noter que beaucoup de procdures lectroniques faisant intervenir une authentification forte , par certificats, sont ralises au travers de formulaires Web et donc ne conduisent pas la fourniture dun document sign en tant que tel. Un document sign avec un certificat du trsor public peut avoir, en revanche, valeur de preuve. - Dernier niveau, celui de la signature lectronique prsume fiable . Les conditions devant tre remplies sont nombreuses et difficiles runir, mais la valeur juridique dun document sign avec une signature de ce type est quivalente un document papier. Il existe peu dexemples de contractualisation de ce niveau. Ladministration lectronique est classiquement dcoupe en 4 niveaux dinteractivit ou de services24, seul le dernier niveau est vritablement concern. Les moyens mettre en oeuvre sont rapidement trs importants vis--vis des bnfices et/ou des risques.

3.2

Choix dun niveau de contractualisation

Le choix dun niveau de contractualisation sera le rsultat dune dichotomie entre : - Le cot des moyens mettre en uvre - Le cot li aux diffrents risques - Les bnfices attendus

Les niveaux prsents concernent la valeur juridique des procdures, non leur niveau de scurit au sens informatique du terme. Niveau 1 : information, Niveau 2 : possibilit de rcuprer les formulaires, Niveau 3 : aide lectronique comme le calcul des impts, Niveau 4 : Dlivrance directe dun service ou dun produit en ligne, exemple : tl dclaration, demande de passeport, etc.
24

23

Ainsi, les achats par carte bleue, que ce soit via Internet ou par tlphone, sont exposs la contestation de lacheteur. Le vendeur ne pouvant garantir lidentit du porteur de la carte bleue, lacheteur (suppos) aura donc a priori gain de cause. Nanmoins, le bnfice induit par la souplesse de ce mode de vente, reste (manifestement) trs suprieur au cot des transactions contestes. Dans le cas du trsor public et de la tl dclaration, lutilisation dune technologie de signature simple est galement une forme de compromis. - Le processus est protg par une authentification forte, offrant une bonne confiance sur le plan technique. - Il ny a pas dacte sign prsum fiable, mais la dclaration est juridiquement recevable (mme si le systme reste sans doute en de de la procdure papier) - La procdure lectronique permet de grosses conomies dans le traitement des dossiers par rapport au papier25 - Un meilleur service est offert, etc.

4. tat de lart
4.1 4.1.1 Signature numrique dans Microsoft Office XP Service de certificats de Windows

La certification et les fonctionnalits de signature numrique sont des services offerts par les systmes dexploitation de Microsoft. Ce service repose sur lutilisation dun fournisseur de services cryptographiques (le CSP26 pour Cryptographic Service Provider) dont linstance par dfaut est le Microsoft CSP v1.0. Il est cependant possible dinstaller dautres modules de certification. Le CSP Microsoft supporte un certain nombre de normes et de standards (X509v3, PKIX, CRL v2, S/MIME, SSLv3, TLSv1, PKCS #7, #10, #12, etc.) et permet lutilisation de signatures numriques pour la messagerie lectronique, la navigation sur le Web, la mise en place de systmes de fichiers chiffrs (EFS27) et les documents bureautiques depuis la version XP de la suite bureautique Office. Laccs au service de cryptographie est ralise au moyen dune interface de programmation standardise pour tous les CSP : la CryptoAPI, actuellement en version 2.0. Elle permet une gestion du stockage des certificats en magasins , en fonction de leur niveau de confiance ou de leur niveau hirarchique, de leur importation ou de leur exportation. Elle est de plus compltement intgre au framework .NET de Microsoft. La vrification de la rvocation des certificats est fate auprs de lautorit de certification au moyen des CRL (Certificate Revocation Lists). Au sein dun rseau de type Active Directory, il est possible de diffuser ces CRL au moyen de diffrents protocoles comme HTTP, LDAP et SMB. Le protocole OCSP nest pas support.

4.1.2

Signature numrique de documents bureautiques

Comme nous lavons prcdemment dit, depuis sa version dite XP ou 2002, lutilisateur de la suite bureautique de Microsoft dispose de fonctionnalits de signature numrique des documents. Celles-ci sappliquent pour 3 types de documents : les prsentations, les documents mis en page et les tableaux. Cette signature numrique de documents est ralise diffrents niveaux comme le montre la figure 8. Dans un premier temps, au sein de chaque document, les macros peuvent tre signes. Le document entier peut ensuite tre sign son tour en utilisant le mme certificat numrique ou un autre. La signature multiple de document est aussi supporte. Il est donc possible une ou plusieurs Figure 8 personnes de contresigner un mme document. Cependant, dans tous les cas, la signature dun document nentrane pas la signature des macros quil contient et rciproquement.
25 Le nombre de tl dclaration aura t de 600.000 durant les mois de mars-avril 2003 (dclaration des revenus 2002), avec 12 millions de connexion sur le portail fiscal. 26 Microsoft a fait le choix de dfinir sa propre interface de service cryptographique avec le CSP. Netscape a dfinit, pour sa part le PKCS#11, IBM le CDSA (Common Data Security Architecture), etc. 27 EFS (Encrypting File System). Pour en savoir plus : http://www.microsoft.com/windows2000/techinfo/howitworks/security/encrypt.asp

4.1.3

Limites

Dun point de vue fonctionnel, si la signature multiple dun document est possible, la traabilit nest que partielle car les signatures sont juxtaposes et non englobantes . Il est donc impossible de reconstituer lhistorique dun document sign par plusieurs signataires. Plus grave, la non disponibilit des spcifications des formats de documents (Word, Excel, PowerPoint, etc.) est rdhibitoire quant la confiance quil est possible daccorder ces documents : - On ne sait pas ce que lon signe - La vrification par une tierce application nest pas possible Si la signature lectronique rsume fiable nest donc pas envisageable, lutilisation dans un cadre de signature simple nest pas non plus vidente : comment apporter la preuve quune solution inconnue puisse tre de confiance ? Figure 9 : Avertissement Windows Pour finir, Microsoft lui-mme, bien conscient des limitations du systme en affiche clairement les limites juridiques au moment de signer (figure 9);

4.2

Adobe Acrobat 6

Adobe concentre une part extrmement importante de ses activits dans ldition lectronique, dont le fer de lance est la suite Acrobat, avec le format de document pdf et dont la version 6 intgre dsormais la possibilit de signer des documents. A linverse de Microsoft, qui conserve jalousement les spcifications de ses formats de documents, Adobe a fait le choix de diffuser ouvertement les spcifications du format pdf28. Dans une logique dinteroprabilit29, il est clairement spcifi que les formats de signatures doivent tre compatibles avec les standards mis par le groupe PKIX de lIETF. En pratique, les signatures mises en uvre dans un document pdf sont des PKCS#7. A noter que dans larchitecture mise en uvre par Adobe, les mcanismes de signature doivent pouvoir sappuyer sur des dispositifs dauthentifications divers, tels des lecteurs dempreintes digitales ou rtiniennes, etc. Autre caractristique intressante dans la signature de documents pdf, une identit visuelle peut tre associe la signature lectronique. Il est ainsi possible de personnaliser au sens humain du terme une signature lectronique. La vrification de la signature se faisant, par exemple, en cliquant sur le symbole visuel. Ce dernier pouvant tre une signature manuscrite scanne, un tampon, une photo, etc. (figure 10). Enfin, ct cadre juridique, un avis de non responsabilit balise ici encore prcisment le chemin (figure 11). Nanmoins, le fait de pouvoir disposer des Figure 11 spcifications du format de document, dutiliser des standards reconnus dans une optique dinteroprabilit affiche et de pouvoir disposer de plusieurs implmentations concurrentes fait que cette solution est pour le moins intressante. Figure 10 : Signature dun document pdf

28

Les spcifications du format pdf, dans sa version 1.5 [Correspondant la version 6 dAcrobat] sont disponibles lURL : http://partners.adobe.com/asn/tech/pdf/specifications.jsp (1172 pages) 29 PDF Reference, fourth edition, Adobe Portable Document Format Version 1.5, Signature Interoperability (8.7.1), page 661

5. Problmes lis la signature lectronique

La signature lectronique est un moyen beaucoup plus fiable de vrifier lauthenticit dun document. La vrification dune signature lectronique ne ncessite aucune expertise particulire. Ce qui nest pas le cas pour la signature manuelle. En effet, comme on la vu lors de lvasion de trois dtenus de la prison de Borgo en mai 2001, il est assez facile de crer des faux documents papier qui peuvent induire gravement en erreur les personnes qui ils sont destins. Malgr tout, la gnralisation de la signature lectronique nest pas encore pour demain. Elle souffre dun certain nombre de handicaps. - lattachement lindividu : la signature manuelle est difficile imiter. Avec un niveau dexpertise suffisant, il est possible de prouver si une telle signature est authentique ou non. Dans le cas de la signature lectronique, il est ais de dupliquer sa cl prive et son certificat et de les transmettre un collaborateur. Lutilisation de jetons cryptographiques externes ne rsout que partiellement cet inconvnient : on peut prter son jeton. Certes, lacte de dupliquer son certificat ou de prter son jeton est en contradiction avec les chartes de bon usage. Malheureusement, face des prtextes durgence ou de soi-disant efficacit, est-il possible de faire respecter les chartes ? - la prennit : pour vrifier une signature lectronique, il faut disposer du document original sous une forme lectronique ainsi que des outils implmentant les divers algorithmes. Si des documents ont t transmis par courriers lectroniques signs, il faudra tre en mesure de les collecter dans les boites lettres des utilisateurs afin de les archiver sur des supports de longue dure. Est-ce que les contrleurs de la Cours des comptes auront des outils pour vrifier la rgularit des pices signs lectroniquement ? Aurons-nous encore dans 10, 20 ou 50 ans les outils qui permettent de lire ces supports ? de vrifier les signatures ? - un dplacement de la charge de travail : la signature lectronique est bien implante dans la plupart des outils de messagerie. On peut donc imaginer transposer toutes les procdures papier vers des procdures utilisant des documents lectroniques signs. Le gain serait vident : en dlais de transmission des documents originaux, en cots daffranchissement, en saisies des donnes du papier vers les systmes dinformation. Si on focalise sur lacte de signature lui-mme, on constate quactuellement, les responsables de nos structures, signent un nombre important dactes, classs dans des parapheurs. Les dossiers ayant t instruits par des collaborateurs, le signataire na besoin que de quelques secondes par acte. Il retransmet ensuite le parapheur ses collaborateurs qui font suivre chaque dossier vers son destinataire final. Dans le cas de la signature par messagerie lectronique, ce processus est difficile mimer. En tout tat de cause, il risque de demander au signataire davantage de rflexion pour chaque acte. Ce dernier nest pas prt assumer cette charge, mme si elle se traduit par un gain pour dautres. La solution passe vraisemblablement par un mcanisme de workflow, pilot par une application WWW et qui joue le rle de parapheur lectronique. - habilitations : la signature lectronique dun document peut tre aisment vrifie par le destinataire. Toutefois, rien nindique que le signataire est autoris signer un tel acte. Ce problme dhabilitation nest pas spcifique la signature lectronique mais cette dernire ne la pas rsolu. Les certificats dattributs permettront certainement daccompagner la signature dun document des habilitations du signataire. Il y a toutefois peu de chances que les outils de messagerie standards puissent interprter correctement ces attributs. L aussi, la mise en place de mcanismes de workflow pourrait pallier ce problme. - Fracture technologique : comme beaucoup dvolutions, lutilisation croissante de ces technologies risque de conduire un schma dexclusion. Si au sein dune organisation structure, comme une entreprise ou une administration, des mcanismes daccompagnement sont disponibles (formation, support, etc.), leur mise en uvre dans un contexte plus large est souvent plus difficile, plus coteuse. Tout le monde sera-t-il capable deffectuer une tldclaration ? La mise en place de tels outils ne risque t-elle pas de se faire au dtriment des procdures traditionnelles ? Quel sera le poids des usagers historiques terme ?

6. Sign@tor
6.1 Objectifs et contexte
Le projet Sign@tor est le rsultat dune multiple constatation : - La plupart de nos systmes dinformation sont accessibles via des interfaces HTML. - Aucune solution satisfaisante ne permet la signature de formulaires HTML30 - Il existe plusieurs architectures cryptographiques et il est difficile de nen considrer quune seule. Si au sein dune organisation homogne, le contrle et la matrise des postes de travail permet de disposer dun parc relativement cohrent, ds lors que lon va vouloir atteindre un public plus large, lhtrognit des systmes et des outils devient un facteur essentiel intgrer. Lobjectif de Sign@tor est de proposer une solution la signature de formulaire HTTP dans un environnement ouvert, multi-plateforme, en sappuyant sur lune ou lautre des diffrentes couches cryptographiques disponibles et avec la possibilit den intgrer aisment de nouvelles. Les diffrentes couches cryptographiques, implmentant les principaux standards31 et dont le support est souhait, sont : - Windows, qui propose deux interfaces : CryptoAPI et .NET32 - Netscape, qui propose une solution open source, NSS33 - Java, qui ne propose quune implmentation partielle. Outre la fonction de signature simple , Sign@tor doit pouvoir offrir un certain nombre de services tels que larchivage des textes signs, la journalisation des actes, larchivage parallle distant, la possibilit dhorodater, etc. De la mme faon que pour la gestion des diffrentes couches cryptographiques, ladjonction de nouveaux services doit pouvoir tre simple et modulaire.

Fig. 12

Enfin, et cest encore l un lment essentiel, linterface et la robustesse du code sont des lments primordiaux tant donn la criticit de lapplication. Un soin tout particulier concernant ces aspects a donc t pris tout au long des phases dtude et de dveloppement. Sign@tor est le fruit dune coopration entre lINRIA et le CNRS.

6.2

Architecture logicielle

La technologie retenue est Java, avec un conditionnement en applet signe, afin de pouvoir accder aux ressources systmes34. Les raisons de ce choix sont celles nonces prcdemment ; portabilit de la solution, robustesse de la technologie, possibilit de disposer dune interface graphique de qualit, etc.

Une session HTTPS permet de garantir authentification, intgrit et confidentialit, mais sans pour autant que les informations changes ne soient signes. Parmi les standards incontournables : x509, pkcs7, pkcs12, SMIME 32 Larchitecture.Net offre un support pour les algorithmes symtriques, asymtriques et de hachages usuels. Une gestion minimale des certificats X509 est galement pourvue. A noter que .NET intgre une implmentation complte de XML Signature [W3C]. Pour en savoir plus : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcryptographyoverview.asp 33 Overview of NSS, Open Source Crypto Libraries : http://www.mozilla.org/projects/security/pki/nss/overview.html 34 Une applet signe peut se voir attribuer des privilges, lui permettant de sexcuter en dehors de la sand box .
31

30

Afin de permettre une bonne adaptabilit aux besoins et un dveloppement conjoint, indispensable tant donn le spectre des technologies utilises, une architecture logicielle totalement modulaire a t retenue (figure 12). Les diffrents composants intervenants dans le fonctionnement de Sign@tor sont: - Les gestionnaires dAPI qui font linterface entre lapplication et les couches cryptographiques. - Les Agents, qui prennent en charge les services darchivage, de journalisation, etc. - Les fonctions, offrant les grandes fonctions, comme la signature.

6.3

Mise en oeuvre

LApplet est insre dans le document HTML, et apparat sous la forme dune petite icne. Linterface entre le document HTML et Sign@tor se fait par des appels Javascripts, permettant deffectuer les diffrentes tapes du processus de signature. Le dclenchement proprement dit de celle-ci intervenant, par exemple, lorsque lon cliquera sur le bouton Envois du formulaire. La signature dun formulaire comprendra les tapes suivantes (figure 13) : - Les paramtres du formulaire sont soumis lApplet, sous la forme de couples (nom-de-paramtre, valeur) - Un format de structuration des donnes est prcis (concatnation simple, tableau html, xml, etc.) - Un format de sortie est prcis (S/MIME ou PKCS #7) - La demande de signature est dclenche. - Le rsultat est rcupr et rang dans un champ hidden (par exemple) - Le formulaire est envoy Lorsque Sign@tor va tre sollicit pour la premire fois, un processus dacceptation de licence, dinstallation et de configuration va devoir tre effectu. Lobjectif de la licence est de clairement prsenter au signataire le fait quil engage sa signature en tant que tel, Figure 13 linstallation va consister installer dans le homedir du signataire un espace pour les journaux et les archives. Ltape de configuration va lui permettre de slectionner ses prfrences. Une fois ces tapes effectues, le panneau de signature lui sera directement propos. La plupart des lments, tel que le libell de la licence, les textes davertissement, les options accessibles lutilisateur, etc. sont entirement paramtrables. Lensemble des prfrences de lutilisateur sont galement sauvegardes, dans lespace Sign@tor de son homedir.

6.4

Bilan & perspectives

Le prototype actuel fonctionne et est capable de signer en sappuyant sur lAPI Mozilla. Limplmentation actuelle intgre lensemble des contraintes de modularit et des fonctionnalits de contrle. La faisabilit du concept est ainsi dmontre. Reste maintenant en faire un produit utilisable en exploitation ;-) En plus de la signature, dautres fonctions doivent pouvoir tre intgres, comme la demande de certificat ou la gestion de CA, permettant ainsi de couvrir dautres segments de nos besoins. Sign@tor peut ainsi tre vue comme une sorte de plateforme cryptographique, polyvalente et ouverte, ct client. Il ne semble pas exister beaucoup de solutions comparables, notamment dans le monde open source :-( Une rflexion est en cours concernant lvolution fonctionnelle et la dfinition dun cadre appropri au projet Sign@tor.