08 Etude PKI CRP-HT PDF

Centre de Recherche Public Henri Tudor
PEKIN PKI e-Luxembourg
Document tude dopportunit dune Infrastructure Cl Publique (PKI Public Key Infrastructure) - Rapport final
Date Version Coordinateur Auteurs 08-04-2002 2.0 Etienne DHoedt Eric Dubois Etienne D'Hoedt Hugues Henriot Gilles Massen (RESTENA) Tom Ries Statut valid MM. Allegrezza, Letsch Diffusion Autorise
Document destin aux membres de la CNSI
La prsente tude a t confie au Centre de Recherche Public Henri Tudor dans le cadre du programme daction eLuxembourg
Introduction
Page 1
L'objectif des travaux qui ont conduit la rdaction de ce rapport, tait d'apporter des lments d'analyse dans le choix pour le gouvernement luxembourgeois d'une solution d'Infrastructure Cls Publiques (ICP) pour ses besoins propres tout d'abord et dans une vision stratgique de synergie avec le secteur priv ensuite. Le prsent rapport s'articule autour de 4 chapitres. Les deux premiers chapitres s'attachent d'une part faire le point sur les initiatives en cours chez nos voisins europens et au GrandDuch, et d'autre part tablir une vue macroscopique des besoins en matire d'applications e-business ncessitant le dploiement d'une Infrastructure Cls Publiques dans les secteurs public et priv. Le troisime chapitre dcrit les diffrents scenarii pour la mise en uvre d'une telle infrastructure. Il analyse galement le modle LuxTrust. Enfin le quatrime chapitre apporte les recommandations pour poursuivre les travaux de slection et de dcision d'un modle luxembourgeois d'Infrastructure Cls Publiques. Le prsent rapport ne se limite pas une analyse de la mise en oeuvre de la signature lectronique, mais il aborde d'autres thmatiques telles l'encryption ou bien encore l'authentification. Le thme central de l'tude est l'Infrastructure Cls Publiques, cl de vote des textes lgaux luxembourgeois et de tout modle d'implmentation.
Introduction
Page 2
Chapitre I Les initiatives existantes
Page 3
Chapitre I.
Les initiatives existantes
1. Les initiatives dans les pays europens

De nombreux pays europens se sont lancs dans des projets e-government afin dexploiter au mieux les possibilits des NTIC1 et de ce fait, amliorer lefficience de leurs services administratifs. Quelque soit le niveau de service que ces pays dsirent offrir leurs concitoyens, les problmes de protection des donnes et dauthentification des acteurs sont rcurrents ds lors que lon aborde lchange de donnes administratives sur un rseau ouvert, comme lInternet, ou ferm, via un Intranet. Les solutions techniques, parfaitement matrises ce jour, ncessitent cependant une organisation relativement lourde si lon dsire doter les citoyens, les entreprises et les administrations des outils ncessaires lchange scuris dinformations. Une utilisation gnrale de la signature lectronique suppose la cration dun nombre consquent de services afin de grer les demandes de certificats, leurs ralisations, leurs rvocations ainsi que toutes les structures ncessaires au contrle de ces services. Les choix organisationnels pris par un pays ont une influence directe sur lvolution des services qui auront exploiter la signature lectronique, de mme que sur linteroprabilit avec le secteur priv. De ce fait, il convient de prendre connaissance des diverses pratiques en matire de dploiement de la signature lectronique. Cest ce que propose le reste de ce chapitre o sont prsents brivement les projets en cours chez nos voisins europens.
NTIC : Nouvelles Technologies de lInformation et de la Communication
Page 4
1.1
Allemagne Des projets nationaux et des projets locaux
De nombreux projets sont en cours actuellement en Allemagne et ont t initis dans leur grande majorit par le gouvernement fdral. Pour les besoins de son administration, le gouvernement a cre le BSI2 afin de coordonner les projets de dveloppement d'ICP et den assurer leur interoprabilit. Au niveau rgional, les villes et Lnders allemands sont incits dvelopper des services en ligne pour les besoins du citoyen. Ces projets sont partiellement financs par le gouvernement ou, pour certains dentre eux, rcompenss dans le cadre de la comptition mdia@komm, qui vise promouvoir le-service en gnral, au niveau rgional. 1.1.1 Dploiement des infrastructures cls publiques au sein des administrations.
Le rle du BSI est dassurer un niveau de scurit minimum ainsi que linteroprabilit de toutes les ICP utiliss par les administrations qui exploitent le rseau Intranet mis leur disposition, lIVBB3. Depuis maintenant une anne, le BSI assure un service de Root PSC via l'ICP-1 Verwaltung afin de certifier, et donc dassurer une reconnaissance mutuelle, de toutes les autorits de certification mises en uvre par les diverses administrations. Les informations techniques et organisationnelles requises par le BSI sont disponibles via la documentation E-governement Handbook . Les administrations des Lnders, des villes ou bien les institutions publiques sont libres de dployer leurs propres solutions dinfrastructure cls publiques afin de rpondre leurs besoins. Ces solutions peuvent tre gres aussi bien en interne que sous-traites des entreprises spcialises. Quelques soient les choix retenus, ces autorits de certification doivent tre certifies par l'ICP-1 Verwaltung afin de pouvoir exploiter le rseau Intranet. L'ICP-1 Verwaltung est une autorit de certification auto-certifie et les Security Policies publies par le BSI autorisent jusqu 5 niveaux hirarchiques dans la chane des autorits de certification. Les tapes suivre par une autorit qui dsire tre accrdite par les services du BSI sont pour le moins peu contraignantes. Il est simplement exig de ladministration qui demande laccrditation : De prendre connaissance des documents techniques, security policies et contrats du BSI De sengager respecter les exigences du BSI en retournant un document sign (self obligation assertion) via lequel ladministration dclare avoir mis en uvre linfrastructure ncessaire au respect des rgles dictes par le BSI. De dfinir prcisment lorganisation qui sera mise en uvre dans le cadre du dploiement de lautorit de certification (Dfinition prcise des responsabilits, publication de Security Policies, ) Une fois la demande accepte, le BSI devra certifier la paire de cls de lautorit de certification qui demande laccrditation. Aucun audit spcifique nest prvu afin de dlivrer laccrditation. Le BSI se rserve simplement le droit, en cas de suspicions, de rvoquer une autorit de certification. Cette rvocation nimplique nullement lusage des certificats pour les besoins internes ladministration rvoque, mais elle ne pourra plus en avoir lusage dans le cadre de lIVBB, lIntranet administratif. A ce jour, seul le-mail inter-administration exploite rellement les possibilits offertes par cette infrastructure. Les outils utiliss doivent tre dfaut dtre standards les plus communs possible. Netscape ou Outlook sont les outils les plus rpandus et permettent lauthentification de lexpditeur, lencryption des donnes et de vrifier lintgrit des donnes.
2 3
Bundesamt fr Sicherheit in der Informationstechnik InformationsVerbund Berlin-Bonn
Page 5
Self certified Root Certificate
Root CA
Root CA certifies CAs with a CA Certiificate
CA A
CA B
CA C
CA certifies Sub CA with CA Certificate
CA certifies Users with User Certificate
User
Sub CA
User
Figure 1 : Hirarchisation des autorits de certification dans les administrations allemandes. 1.1.2 Du gouvernement aux citoyens
Dans le cadre du projet BundOnline 2005, tous les services administratifs pouvant tre mis la disposition des citoyens via lInternet doivent tre dvelopps avant 2005. Cette initiative, lance par Gerhard Schrder le 18 Septembre 2000 lors de son intervention sur legovernment, vise la cration dun portail administratif rassemblant lensemble des services en ligne des administrations publiques. Plusieurs projets sont dores et dj oprationnels, mais le niveau de scurit exig dans le cadre de ces services est toujours trs faible voir inexistant. Lorsque les utilisateurs sont amens sauthentifier, les mthodes utilises reposent sur lemploi dun password gr par ladministration qui met disposition le service. Par contre, SSL est couramment utilis pour lencryption ainsi que pour lauthentification du serveur distant. Le projet BAfG4
Gestion des dossiers tudiants. Via ce service, les tudiants peuvent accder en ligne leurs dossiers de demande ou dobtention de prts dtudes. Ils ont en outre la possibilit daccder aux informations leurs permettant de grer le remboursement de ces emprunts, contracts auprs de ladministration. 500 000 emprunts sont grs via cette plate-forme ce jour. Les informations sensibles sont encryptes via SSL et le serveur dispose dun certificat dauthentification. Le projet ELSTER.
Ce projet est linitiative du Bundesfinanzamt et vise promouvoir lusage des outils caractre financier utiliss par les citoyens, les entreprises ou cabinets dexperts comptables afin deffectuer des dclarations en ligne. Les informations publies dans le cadre de ce projet sadressent aux diteurs de logiciels comptables et financiers afin quils puissent quiper leurs produits de fonctionnalits autorisant les dclarations en ligne avec les services du ministre des finances. Le site www.elster.de publie des informations relatives au format des donnes transmettre ainsi quau niveau de protection exig lors du transfert de ces donnes. Les modalits dauthentification sont galement explicites, mais elles ne requirent jamais de certificats de la part de lutilisateur final.
4
Bundesausbildungsfrderungsgesetz
Page 6
Le projet PROFI
Ce service permet de simplifier les modalits de gestion des projets dinnovation, de recherche ou dducation financs conjointement par les ministres de lducation et de la recherche, ainsi que par le ministre de lconomie et des technologies du gouvernement fdral. Lobjectif est principalement de rduire les pertes de temps ainsi que les cots dus cette gestion conjointe qui se concrtise en fait par une double gestion. Les informations pouvant tre dsormais partages par les deux administrations, lefficacit globale du processus a t nettement amliore. 1.1.3 Les citoyens et leurs administrations locales.
En 1998, le gouvernement lana le projet media@komm afin de favoriser le dveloppement des rseaux locaux citoyens appels pour la circonstance the digital office for Citizens . 136 villes dAllemagne prirent part ce projet dot dun prix de 50.000.000 DM pour la meilleure des solutions. 70.000.000 DM furent galement investis par les villes ou des socits prives partenaires de lopration. Les solutions dployes vont des plus simples aux concepts les plus complexes dans lesquels tous les acteurs de la ville ont t pris en compte le citoyen, les administrations locales, les socits locales, les services bancaires, etc Aucun contrle, aucune gestion globale de ces projets ne ft souhait si bien que chaque ville tait libre de ses choix et a pu se lancer dans les projets les plus ambitieux. Par exemple, de nombreuses villes ont souhait fournir leurs administrs une carte citoyen afin de leur fournir une authentification lectronique utiliser dans le cadre des services lectroniques mis leur disposition ou encore, dans le cadre de leurs interactions avec les services bancaires locaux ou de leurs achats sur Internet. Cest le cas de la ville de Bremen, qui a men une tude approfondie concernant les diffrentes interactions que peuvent avoir ses administrs avec les services administratifs de la ville. Certaines de ces oprations administratives ncessitent limplication de plusieurs services et de plusieurs socits prives. Cest le cas du changement dadresse. Le service qui a t dvelopp permet dsormais au citoyen, en une seule opration, deffectuer un changement dadresse. Tous les services administratifs concerns seront informs, de mme que la poste et certaines socits prives avec lesquelles ladministr a des contacts rguliers. Lintgration dune puce lectronique sur les cartes de payement est en cours et permet lutilisateur dtre authentifi. Les rglements en ligne sont dsormais possibles, aussi bien pour des services administratifs que dans le cadre du commerce lectronique local.
Page 7
1.2
Belgique - cration dune ICP fdrale et dune carte didentit lectronique
Dans le cadre des actions e-gouvernment, gres par le Fedict5, deux tudes sont en cours concernant le dploiement dune ICP fdrale (projet FedPKI) ainsi que celui dune carte didentit lectronique (projet BelPIC). Ces deux projets sont troitement lis dans la mesure ou lensemble des certificats ncessaires lutilisation de la carte didentit lectronique devra tre gr par l'ICP fdrale. Bien que ces projets ne soient encore que dans une phase dtude, certains choix conceptuels et fonctionnels ont fait lobjet de publications disponibles sur le site du Fedict. 1.2.1 FedPKI
Lensemble des aspects didentification, dencryption et de scurit en gnral des projets egovernment du Fedict reposent sur ce projet. Cest pourquoi la priorit lui a t donne afin de permettre ladministration fdrale de dployer des outils de communication scuriss (portails lectroniques, authentification, signature lectronique, messagerie lectronique, ) bass sur lusage des certificats. De plus, ce projet doit pouvoir rpondre lensemble des besoins de ladministration Belge en matire de certificat, que ce soit pour son usage interne ou externe. Enfin, il se veut volontairement ouvert, intgralement bas sur des standards ouverts afin de faciliter au maximum les interactions entre le systme ICP et les choix technologiques qui restent la discrtion de chaque administration. Les fonctionnalits de la premire gnration FedPKI : Compatibilit totale avec le projet BelPIC et gestion des certificats ncessaires lusage de la carte didentit lectronique, Gestion des certificats dapplications utiliss au sein de ladministration (application interne, portail lectronique scuris, authentification client serveur, ) Dploiement dune messagerie lectronique scurise interne et externe Structuration de linfrastructure cl publique Lautorit de certification (FedCA) est appele CA membrane. Une unique interface est visible de ses utilisateurs (essentiellement les autorits denregistrements) mais elle est compose de plusieurs Autorits de Certifications. Cette sparation des rles permet de grer des niveaux de scurit diffrents, des fonctions diffrentes comme le montre le schma ci-dessous : FedCA Security Officers FedCA FedPKI operators FedCA BelPIC operators
FedCA BelPIC entities
FedCA High
FedCA Medium
FedCA Normal
Figure 2 : Organisation dune CA membrane compos de plusieurs CA spcialiss.
Fedict : Service public fdral Technologie de lInformation et de la Communication (http://www.fedict.be)
Page 8
Cette organisation met en uvre plusieurs autorits de certification afin dobtenir des niveaux de scurit diffrents, ainsi que des autorits spcialises dans la gestion des certificats de la carte didentit lectronique. Les FedRA : Chaque service, administration fdrale ou communale doit avoir la possibilit de prendre sa charge les demandes des certificats. Cette dcision sappuie sur le fait que ces administrations sont les mieux places pour effectuer lidentification de base des demandeurs, pralable la dlivrance du ou des certificats. De ce fait, les administrations communales seront autorit denregistrement pour les citoyens qui dsirent obtenir une carte didentit lectronique. Dans le cadre du projet FedPKI, il a donc t dcid de faire un FedRA, compos doutils et de spcifications, suffisamment ouverts afin que chacune de ces administrations puisse ladapter ses besoins ainsi qu ses propres choix technologiques. Le rle du FedDirectory, ou rpertoire centralis, est de publier les certificats ainsi que les listes de certificats rvoqus. Pour des raisons de scurit, il sera lui-mme redondant afin dviter toute interruption de service. Ce rpertoire sera principalement aliment par les informations reues des autorit denregistrement. Linteroprabilit de cette architecture sera assure par les choix technologiques qui seront dtermins puisquil est souhait que ce rpertoire ait plusieurs formats de stockage de linformation (LDAP, LDAPS, Active Directory, Novell Directory Services, X500, XML) ainsi que plusieurs protocoles de communications (OCSP, SQL, ) 1.2.2 BelPIC ou Belgium Personal Identity Card
Agenda Juin 2001 Remise au gouvernement dune tude conceptuelle relative lintroduction de la carte didentit lectronique ralise par la Banque Carrefour de la Scurit Social et le Ministre de lIntrieur Si le document de travail est accept par le gouvernement, un cahier des charges pour la production de la carte didentit lectronique sera mis ainsi que les spcifications techniques des appareils de lecture des cartes Test grandeur nature de la carte dans un nombre limit de communes Dploiement systmatique sur tout le territoire
Automne 2001
Juin-juillet 2002 Dbut 2003
La carte didentit lectronique, telle quelle est dfinie par ltude en cours, devra offrir les fonctionnalits suivantes : identification du titulaire; authentification (cest--dire la preuve que le titulaire de la carte est bien la personne identifie par la carte); moyen dapposer une signature lectronique avec valeur probante; preuve lectronique dune qualit, dun mandat ou dune comptence du titulaire; support de programmes qui peuvent tre excuts dans le microcircuit de la carte; support de donnes lectroniques.
Une distinction est faite concernant lauthentification de lutilisateur et lusage de sa signature. En effet, il est prvu que lutilisateur puisse apposer une signature lectronique avec valeur probante en utilisant une paire de cls distincte de celle qui lui servira lors de ses diverses authentifications. Cette distinction permet davoir des niveaux de scurit diffrents entre les authentifications et les signatures et vite les signatures par erreur puisque chaque paire est protge par un code PIN unique. Notons galement que cette carte devra pouvoir mmoriser dautres certificats afin, notamment, de pouvoir utiliser des certificats de qualit. Il est galement prvu de mmoriser sur cette carte les informations mdicales actuellement
Page 9
distribues aux citoyens via la carte SIS tout en assurant la compatibilit des lecteurs de cartes SIS avec ceux de la carte BelPIC. Les communes auront le rle dautorit denregistrement et les demandeurs devront choisir leur autorit de certification parmi celles qui auront pass un contrat avec les pouvoirs publics. Ce qui implique quelles acceptent le modle propos (CF FedPKI) ainsi que certaines conditions en matire de qualit, dinteroprabilit et de scurit. Processus dacquisition dune carte didentit lectronique : 1. Tout habitant convoqu se rend avec le formulaire adquat et les documents utiles (carte didentit actuelle, photo didentit) la commune o il est inscrit dans le registre de la population. Il y fait la demande dune carte didentit lectronique et indique le cas chant sur le formulaire lautorit de certification (AC) de son choix. 2. Le fonctionnaire comptent du service de population contrle lidentit du demandeur selon la procdure dcrite. 3. Les donnes du demandeur sont transmises la Centrale denregistrement auprs du Registre national. 4. La Centrale denregistrement enregistre les donnes de la demande dans le Registre des cartes didentit et les transmet ensuite au producteur de cartes. 5. Le producteur des cartes ralise les contrles utiles et personnalise la carte microcircuit, autrement dit, il imprime sur la carte les donnes didentit de son titulaire ainsi quun numro de carte didentit unique. Ensuite, la carte est cde linitialisateur des cartes. 6. a. Linitialisateur des cartes fait gnrer sur la carte une paire de cls de base et enregistre dfinitivement dans le microcircuit de la carte le numro de carte unique ainsi que les donnes didentit du demandeur. 6. b. Linitialisateur des cartes demande au Registre national de signer de manire digitale les donnes fixes de la carte. Cette signature digitale est galement enregistre dans la carte. Le Registre national gnre cette signature lorsque la demande est correctement formate, sans en vrifier explicitement le contenu. Seules les instances comptentes disposant du certificat de serveur professionnel affrent la cl prive utilise sont en mesure de vrifier la validit de cette signature digitale. Note : Si le demandeur opte pour une demande diffre de certificat, les tapes 7 9 ne doivent pas tre ralises. 7. Si le demandeur a demand des certificats didentit, linitialisateur des cartes fait gnrer deux paires de cl et envoie les demandes de certificat utiles lAC souhait lintervention du Registre national. Ces demandes de certificat sont protges laide dune cl de base prive enregistre dans la carte microprocesseur. Le Registre national contrle les incompatibilits de cls ventuelles et transmet une demande de certificat signe lAC souhait. Cette demande contient, outre la cl publique, un numro de srie de certificat. Ce numro est dduit de nombreux paramtres, notamment du numro de personne du titulaire, de la cl de base publique de la carte, du numro de carte et dinformations confidentielles qui sont uniquement connues par le Registre national. 8. Lautorit de certification gnre ensuite, aprs approbation de la demande, les certificats demands. 9. Lautorit de certification envoie ensuite les certificats au Registre national. Le Registre national vrifie les informations et la signature figurant sur le certificat. Si ces informations savrent correctes, le Registre national transmet les certificats linitialisateur de la carte.
Page 10
Figure 3: Processus d'acquisition d'une carte d'identit 10. a. Linitialisateur des cartes enregistre sur la carte le code PIN initial et le code dactivation pour le titulaire (PUK1) ainsi que le code dactivation pour le fonctionnaire comptent (PUK2). 10. b. La carte didentit lectronique finie est envoye la commune du demandeur dans un coffre scuris. 10. c. Linitialisateur des cartes envoie directement au demandeur, sous pli ferm, le code PIN et un code PUK1 ainsi que la convocation pour retirer sa carte didentit lectronique auprs du service de la population communal. 11. Le demandeur se rend avec son code PIN, son code PUK1 et sa convocation la commune pour y retirer sa carte didentit lectronique. 12. a. Sur place, la carte est simultanment active par le fonctionnaire communal comptent et lutilisateur laide du PUK1 et PUK2. Note : Si le demandeur opte pour une demande diffre de certificats didentification et de signature, ltape 12b ne doit pas tre ralise. 12. b. Le demandeur de la carte produit ensuite une signature de test pour chacun des certificats demands pour laquelle il doit chaque fois introduire son code PIN. Le demandeur de la carte ralise aussi une identification de test sur un site web des pouvoirs publics spcialement configur cet effet. A cet effet, il doit galement introduire son code PIN. 12. c. Ce nest quaprs le dblocage correct de la carte et la validation ventuelle des signatures de test que le fonctionnaire communal peut remettre la nouvelle carte didentit lectronique au demandeur. 13. Fin de lenregistrement / du processus dactivation.
Page 11
1.3
Finlande Utilisation de la carte didentit lectronique depuis janvier 2001
La Finlande est lorigine des premires initiatives concernant le dploiement systmatique dune solution ICP. En effet, entre 1995 et 1997, les premires tudes de faisabilit taient ralises et le premier projet pilote a dbut ds 1998. Dcision ft prise en 1999 de mettre en place une Infrastructure Cl Publique gre par les administrations publiques et de fournir aux citoyens une carte didentit lectronique ; la carte Fineid6 vit le jour.
Figure 4 : Une carte didentit lectronique FINEID Les premires applications sont la dmatrialisation des relations entre ladministration et les citoyens. Les cartes seront acceptes par les services municipaux (bibliothques, crches, etc ) comme lment didentification. Tout un panel dinterfaces avec la carte est en cours de dveloppement sur les tlphones mobiles, les dcodeurs de tlvision numrique, des terminaux spcifiques. Les interfaces et les lecteurs de cartes avec les ordinateurs personnels sont dvelopps. Les services en cours de dfinition par le gouvernement finlandais concernent lamlioration de laccessibilit aux : Changement dadresse personnel, Accs aux archives personnelles, Accs aux services du logement social, Courrier lectronique scuris.
La position du gouvernement finlandais a t de faire raliser une carte puce et des terminaux hautement scuriss permettant dobtenir une signature digitale forte. Cette fonction gnrique peut tre exploite par le secteur priv pour monter des services comme le paiement en ligne, la banque domicile, le commerce lectronique, sachant que la transaction est faite sur la signature ralise laide de la carte didentit. Lmetteur de certificats est le centre denregistrement de la population finnoise, qui a aussi pour responsabilit de sassurer du bon fonctionnement global de linfrastructure. Les cartes didentit sont distribues aux citoyens par les services de la police locale qui a galement le rle dautorit denregistrement. Une carte didentit cote FIM 160 soit environ EUR 26,8. 1.3.1 La carte FinEID en dtail
La carte Fineid a plusieurs rles. Cest tout dabord une carte didentit au sens classique du terme puisque les informations concernant le porteur identit, photographie, adresse - sont inscrites sur la carte. Elle est reconnue ce titre par les 15 pays de la communaut europenne, signataires des accords de Schengen. De plus, cette carte est munie dune puce lectronique dont laccs est protg par un code PIN, connu uniquement par le porteur. Toutes utilisations des informations contenues par la puce ncessitent lentre de ce code et
6
FINland Electronic IDentification card
Page 12
en cas de mauvaise saisie par le porteur, la carte est bloque au-del du troisime essai. Les services de police locaux sont habilits dbloquer les cartes en la prsence des porteurs. La dure de vie de la carte a t fixe trois ans pour des raisons de scurit et pass de ce dlai, elle nest plus oprationnelle. 1.3.2 Les informations mmorises sur la carte didentit
Trois certificats sont mmoriss sur la carte du porteur ; le premier tant son certificat didentification et dencryption, le second, le certificat de signature et de non-rpudiation et le troisime tant le certificat de lautorit de certification. Aucune information caractre personnel, autre que le nom et le prnom du porteur, nest mmorise sur la carte. Les autres informations sont techniques et concernent : Le nom de lautorit certifiante La priode de validit du certificat Le user ID du porteur Le numro de srie du certificat Le mode de calcul de la paire de cls publique / prive La technique utilise par lautorit de certification pour la signature du certificat
Outre ces informations accessibles, dautres ne le sont pas comme les cls prives de chaque paire. Pour assurer une compatibilit maximale de cette carte avec les quipements informatiques utiliss ce jour, toutes les technologies ncessaires la ralisation et lutilisation de la carte FINEID sont standards. X509 V3 pour le format des certificats, ISO 7816 pour les puces et les lecteurs, X500 et LDAP pour les rpertoires de listes de rvocation. 1.3.3
7
Une organisation centralise et des partenaires associs
Le FPRC , centre denregistrement de la population et service public, est lautorit de certification pour lidentit lectronique. Ce service est responsable de la cration et de la maintenance de linfrastructure ncessaire la gestion de la carte FINEID. Il est notamment le garant, vis--vis de ladministration Finlandaise, du bon fonctionnement de linfrastructure cl publique ainsi que des services annexes. Ce service dlgue des partenaires privs certaines de ces activits : La socit ICL Invia est lintgrateur de technologie, ID2 Technologie, socit sudoise, fournit la solution ICP, La socit Sonera, oprateur en tlcommunication, gre les listes de rvocation de certificats ainsi que le help desk associ, La socit Novacall, spcialise dans le call center, est responsable du help desk utilisateur, Les databases de cls publiques et de certificats sont gres par Elisa communication, intgrateur de solution Internet, Les cartes sont fabriques par Setec. Lapproche Finlandaise se distingue par le fait que les premires initiatives, en matire de scurisation des changes sur lInternet, furent prises et gres par le gouvernement et ses administrations. Aprs les premires annes dtudes, entre 1995 et 1998, le gouvernement opta pour une solution qui offre un service didentification classique et un service didentification lectronique. En ce qui concerne les services qui sont en cours de dveloppement et qui pourront exploiter la carte FINEID, plus rien ne soppose leur essor. Linfrastructure cl publique est disponible, elle est unique et gre par les services de ltat. Le secteur public, comme le secteur priv, ont leur disposition les fondations ncessaires au dveloppement de leurs eservices scuriss.
Finnish Population Register Center
Page 13
1.4
France Les travaux du Ministre des Finances
La premire initiative, concernant la mise en place de services en ligne scuriss en France, a t prise par le Ministre de lconomie, des finances et de lindustrie. Ces services sont runis sous le terme gnrique de tlprocdures et sadressent plus particulirement aux grosses entreprises, cabinets dexperts comptables ainsi qu tous les services financiers disposant dune connexion lInternet. Ces tlprocdures permettent aux contribuables de tldclarer ainsi que de tlpayer la TVA via un service EDI8 ou un service EFI9. Ces diffrents services ont t mis en uvre depuis le 23 avril 2001 et font suite la loi du 13 mars 2000 qui confre un cadre juridique la signature lectronique. 1.4.1 TlTVA via EFI :
Lchange de formulaires informatiss exploite les outils et concepts de lInternet et permet au Ministre doffrir ses services un plus grand nombre de contribuables. En effet, les techniques EDI ncessitent des infrastructures matrielles et logicielles lourdes et coteuses, elles sont donc rserves aux professionnels tels que les cabinets comptables ou les organismes agrs. Elles ncessitent lintermdiation technique dun partenaire EDI agr par la DGI10, lentreprise pouvant elle-mme demander la DGI son agrment en tant que partenaire EDI. Par contre, lEFI est accessible toute entreprise disposant dune connexion lInternet ainsi que dun certificat numrique reconnu par les services du Ministre. De ce fait, elle peut utiliser les applications requises par la messagerie scurise S/MIME ou les transactions Web scurises via le protocole SSL. Politique de rfrencement des certificats par le Ministre Souhaitant sappuyer sur le march des services de certification , le Ministre sest engag dans un processus de rfrencement de certificats numriques. Le document du Ministre Politique de Certification Type permet dtablir les critres de rfrencement de certificats utilisables pour des changes dmatrialiss des tlprocdures, entre dune part, les clients des Infrastructures Cls Publiques commerciales ou corporatives et, dautre part, les services oprationnels du Ministre. La publication, la mise jour de la PC-Type ainsi que lhomologation des classes de certificats des autorits de certification sont des tches intgralement gres par les services du Ministre. La conduite des audits auprs des autorits de certification est quant elle dlgue une EAR11, organisme qui, sous la responsabilit du Ministre, est charg du rfrencement des certificats recevables. Le document Politique de Certification-Type Les grands principes de la politique de certification type se dclinent comme suit. Les certificats dfinis par la PC-Type sont conformes aux standards et ne contiennent pas dinformations spcifiques aux applications du Ministre. La PC-Type permet dhomologuer des catgories de certificats offertes par des autorits de certification et non pas daccrditer ces autorits de certification dans leur ensemble. Les contrles de conformits tablis par la PC-Type portent sur les points suivants : 1 Spcifications techniques minimales requises Dtails des champs dauthentification des certificats Rgle de gnration et de re-gnration de bi-cls Tailles des cls et algorithmes dencryption utiliser 2 Rgles de fonctionnement de lautorit de certification Chaque demande de certificat doit faire lobjet dun dossier de demande qui devra tre archiv
8 9
Echange de Donnes Informatis Echange de Formulaires Informatis Direction gnrale des Impts 11 Entit dAudit et de Rfrencement
10
Page 14
Description des rgles de suspension et de rvocation des certificats Obligation de logger certains vnement techniques comme larrt des serveurs informatiques en production, tous les problmes relatifs la scurit de linfrastructure informatique ou la manipulation des certificats. 3 Processus internes lentreprise Dune manire gnrale, toutes les rgles de fonctionnement de lautorit de certification doivent tre crites et disponibles tout moment. Ces rgles concernent aussi bien la politique de gestion du personnel que les modalits techniques de gestion des certificats (cration, rvocation, suspension, etc ) Circuit dhomologation dune classe de certificats par les services du Ministre 1. 2. 3. 4. 5. Demande dhomologation dune classe de certificats par une Autorit de Certification auprs des services du Ministre Dsignation dune Entit dAudit et de Rfrencement par le Ministre pour la conduite de lAudit Ralisation de laudit par lEAR sur base de la PC-Type publie par le Ministre Transmission du rapport daudit et dun avis au Ministre qui peut tre : Russite , Echec , A confirmer Transmission de lavis du Ministre lAutorit de Certification candidate lhomologation : o En cas de succs, transmission dun avis de rfrencement. o En cas dchec, transmission dun avis de non rfrencement ou de drfrencement dune ou de plusieurs autres classes de certificats de cette mme autorit, homologues prcdemment. o En cas de rsultats confirmer, transmission dun avis dchance au terme duquel les points dfaillants devront tre rsolus. Un contrle de confirmation permettra de vrifier que les points critiques ont bien t rsolus.
2 4
Ministre de lEconomie, des Finances et de lIndustrie
1 5
3
Entit dAudit et de Rfrencement Autorit de Certification
Figure 5 :Modalits dobtention dune homologation par une Autorit de Certification 1.4.2 Exploitations des tlprocdures par le contribuable
Lutilisation de ces services prsuppose lacquisition dun certificat numrique par lusager quil pourra se procurer auprs dun fournisseur de certificats parmi ceux qui ont demand et obtenu leur rfrencement. La liste exhaustive des classes de certificats homologues ou en cours dhomologation est accessible publiquement sur le site du Ministre. Un unique certificat permet daccder lensemble des services du Ministre actuels ou futurs -, mme si les modes opratoires diffrent, de mme quil est possible lusager dutiliser ce certificat dans dautres contextes que les tlprocdures. Il est noter que les tlprocdures
Page 15
du Ministre exploitent certaines extensions de certificat. Si, dans le cadre dune utilisation de ce certificat dans un autre contexte, ces attributs sont modifis, lusager peut se voir refuser laccs certains tlservices qui utilisent ces mmes extensions. Dautres services seront proposs dans le cadre des tlprocdures : une publication gnrale sur la TVA (modifications lgislatives, dispositions fiscales nouvelles) une publication spcifique aux tlprocdures et plus particulirement sur TlTVA (modalits dadhsion, tlchargement du contrat) une possibilit de consultation des tldclarations EFI prcdemment transmises au serveur une possibilit de consulter les avis de rception des dpts des tldclarations et des tlrglements correspondants qui sont par ailleurs transmis ladresse lectronique des redevables une fonction de gestion des certificats numriques permettant notamment de dlguer le pouvoir de tldclarer et de tlrgler un tiers une bote aux lettres de correspondance gnrale sur la procdure, laquelle le redevable pourra adresser des observations ou poser des questions.
Page 16
1.5
Italie - Une carte didentit lectronique en phase de test
Suite au dploiement du rseau informatique RUPA12 sur le territoire italien entre 1997 et 1999, ladministration italienne, linitiative du Ministre de lintrieur, est dans une phase exprimentale de dploiement de la carte didentit lectronique depuis le second semestre de lanne 2000. Cette exprience vise mettre en circulation 100000 cartes didentit lectroniques via la collaboration des communes qui se portent volontaires afin de valider les choix techniques ainsi que les processus de fabrication, de diffusion ou de contrle de cette carte. Quant ses fonctionnalits, en dehors des aspects didentification du porteur, la puce embarque doit permettre de contrler les accs aux futurs services en ligne des administrations et den scuriser la communication. 1.5.1 Composition de la carte
Cette carte devant servir de carte didentit classique, les informations ci-dessous apparaissent clairement sur le support en poly-carbonate : Informations relatives au porteur (identit complte et photographie) Informations relatives la commune qui est lorigine du document Identifiant unique de la carte Date dmission et de fin de validit de la carte.
La carte est galement munie dune bande optique afin de mmoriser trois catgories dinformations : 1 - Des donnes : Les informations relatives au porteur au format numrique, photographie et empreinte comprises Un hologramme afin de limiter les possibilits de fraude Des donnes didentification unique de la bande optique (Numro de srie, fabricant, date de fabrication, ) 2 - Des informations de contrle de ces donnes : Un champ de contrle est associ chacune des donnes ci-dessus. Ce champ mmorise des informations relatives au service, la personne qui est lorigine de la mmorisation de la donne ainsi que de celle qui a autoris cette mise jour : Numro de donne et type de donne Date et heure de cration de la donne Certificat de lentit qui est lorigine de la mise jour de cette donne Identit de loprateur qui est lorigine de la mise jour de cette donne Numro dautorisation du Ministre de lintrieur concernant la mise jour de la donne Date et heure de cette autorisation Certificat du Ministre de lintrieur Numro didentification de la carte 3 Des informations relatives aux services en ligne et accessibles par lutilisateur Ces services peuvent ncessiter la prsence dinformations au moment de lutilisation de la carte. Une zone appele Directory Service permettra ce type dusage. Rles de la puce lectronique La puce lectronique sert de cryptosystem initial afin de gnrer une paire de cls publiques et prives. Elle mmorise et protge laccs ces informations. Notons que la cl publique est mmorise sous la forme dun certificat dlivr par le Ministre de lintrieur et que ce certificat lie la cl publique au numro de srie de la carte. Ce certificat utilise une extension compose du hash-codage des informations personnelles du porteur. Toutes les informations relatives au porteur sont galement mmorises.
12
Rseau Unitaire pour lAdministration Publique
Chapitre I Les initiatives existantes 1.5.2
Page 17
Circuit de fabrication, dinitialisation et dmission de la carte
Les diffrents acteurs Les cartes didentit vierges sont fabriques par un institut public, lIPZS13, qui est charg notamment dassembler le support plastique, le microchip et la bande optique. Chaque cration de carte fait lobjet dune autorisation qui mane directement du Ministre de lintrieur qui fournit le numro unique de cette carte. Lors de cet assemblage, sont mmorises sur la carte toutes les informations relatives sa fabrication, et ce, sur les trois supports (plastique, bande optique et microchip). Ces cartes didentit vierges sont ensuite achemines vers les communes qui participent lexprimentation et seront dlivres tous les citoyens qui en font la demande. La commune qui souhaite dlivrer ces cartes doit non seulement collecter les informations ncessaires leurs ralisations mais elle doit galement possder lensemble du matriel ncessaire linitialisation. Ce matriel, appel poste dmission, coordonne le processus dmission de la carte en fournissant : Une connexion rseau scurise vers le Ministre de lintrieur : Rseau RUPA, Internet ou autre Un processus dacquisition des donnes du citoyen : Videocamra ou WebCam pour la photo du demandeur, Une tablette graphique pour la signature, Eventuellement un scanner si les deux priphriques ci-dessus ne sont pas disponibles, Un lecteur dempreintes pour lempreinte digitale du demandeur. Un processus de ralisation de la carte : Un lecteur / graveur de chip, Un lecteur / graveur de bande optique, Une imprimante thermographique, Une imprimante impact. Loprateur communal, aprs avoir acquis les informations ncessaires lmission de la carte didentit (donnes individuelles, photo, empreintes digitales, ) met en route le processus de demande dautorisation auprs du Ministre de lintrieur et effectue les oprations de personnalisation des divers supports constituant la carte (criture sur le chip, sur la bande optique, impression des donnes sur le support plastique). Cette opration ncessite un environnement logiciel spcifique et scuris afin dobtenir du Ministre toutes les autorisations et informations adquates pour piloter les diffrentes tapes qui constituent la ralisation finale de la carte. Dernier acteur, le Ministre de lintrieur. Ce dernier orchestre le bon fonctionnement de lensemble de ce processus et se porte garant de sa fiabilit. Il est galement Autorit de Certification lorsquil fournit le certificat qui sera mmoris sur le microchip au moment de la ralisation dune carte. Notons cependant que ce certificat nest pas li au porteur de la carte, mais uniquement au numro de srie de cette carte. Ladministration Italienne, de ce fait, recre, au format lectronique, la notion didentit individuelle telle que nous la connaissons aujourdhui afin de faciliter lusage des services gouvernementaux mais aucune porte nest prvue vers le commerce lectronique ou tout autre usage priv de cette carte didentit.
13
IPZS : Istituto Poligrafico e Zecca dello Stato
Page 18
1.6
Royaume-Uni complte ?
Une
organisation
complexe
mais
En 1999, un service spcial, ddi au commerce lectronique et son dveloppement ft cr et rattach au cabinet du premier Ministre. Il sagit du E-Envoy dont les objectifs annoncs sont : Faire du Royaume-Uni une place incontournable pour le commerce lectronique dici fin 2002 Offrir tous ceux qui le souhaitent, une connexion lInternet dici fin 2005 Mettre disposition tous les services administratifs sur lInternet dici fin 2005
Pour ce faire, un e-Minister a t dsign afin de coordonner toutes les actions du gouvernement dans ce domaine. Ce e-Minister , en collaboration avec les services du EEnvoy, est galement charg de transmettre mensuellement au premier Ministre un rapport davancement concernant la mise en oeuvre de la stratgie gouvernementale en matire de commerce lectronique. Ces rapports sont disponibles sur le site de E-Envoy, de mme que le plan daction du gouvernement. Parmi ces initiatives, un effort consquent est consacr la mise sur Internet de services gouvernementaux et certains dentre eux sont actuellement disponibles : Les dclarations annuelles relatives aux impts retenus la source peuvent tre faites via le site de la Direction Gnral des Impts. Certaines demandes daide rgionale peuvent tre adresses auprs du Ministre de lAgriculture, de la Pche et de lAlimentation. La dclaration de TVA on-line est en service auprs de ladministration des Douanes et des Contributions Indirectes.
A loccasion de la mise en ligne de ces services, plusieurs sites ont t crs afin de guider les utilisateurs dans leurs e-demarches ; le site du gouvernement gateway centralise toutes les demandes daccs aux services. Pour chaque demande denregistrement auprs dun service, lutilisateur se verra attribu un Activation Pin quil devra utiliser lors de sa premire connexion. Concernant son identification, certains services exigent la possession dun certificat numrique, alors que dautres se contentent dun classique UserID/Password. Tout dpend du niveau de confidentialit des informations changes. Le site Ukonline.gov.uk est le portail de ladministration Anglaise vers tous ces services en ligne. 1.6.1 Gestion des certificats numriques qualifis
En 1999, suite un lobbying intensif auprs du gouvernement de la part du secteur priv, ft cr un organisme indpendant tScheme charg de laccrditation des autorits de certification. Lindpendance de cet organisme est assure par la constitution de son bureau puisque tous les acteurs du march y sont reprsents (Secteur priv, public, associations de consommateurs, cabinet du premier Ministre, etc ) La mission principale de cet organisme est la publication de critres daccrditation Approval Profiles via ses groupes de travail composs dexperts ainsi que la gestion des modalits dobtention de laccrditation tScheme. Suite une demande daccrditation de la part dun organisme de certification auprs de tScheme, un audit sera men dans les locaux de cet organisme par un auditeur indpendant et dsign par le UKAS14. Le UKAS, suivant le mme principe que tScheme , est un organisme indpendant charg de laccrditation des auditeurs.
14
United Kingdom Accreditation Service
Page 19
Un organisme de certification qui souhaite obtenir laccrditation tScheme doit subir un audit sur la base des Approval Profiles de tScheme. Cet audit pourra tre men par un auditeur accrdit par le UKAS, seul organisme reconnu par ltat pour laccrditation des auditeurs. On a, de ce fait, une sparation trs distincte des responsabilits : A tScheme : Publication des Approval Profile B UKAS : Accrditation des auditeurs sur la base des Approval Profile en cours de validit C Lautorit de certification candidate effectue une demande daccrditation auprs de tScheme et prend connaissance des modalits de ralisation de laudit. Elle devra choisir le cabinet daudit qui ralisera laudit dans ses locaux, parmi ceux accrdits par le UKAS D Cabinet dAudit : Ralisation sur le terrain des audits et publication dun rapport daudit E tScheme : Transmission lautorit de certification de la dcision finale de Tscheme, sur la base du rapport daudit effectu par le cabinet daudit
D : Ralisation de lAudit Autorit de certification C : Demande daccrditation E: Accrditation tScheme Approval Profiles A : Publication B: Accrditation UKAS Cabinet dAudit
tScheme
UKAS
Figure 6 : Modalits daccrditation dune autorit de certification Pour utiliser les services administratifs qui ncessitent un certificat, lutilisateur devra sadresser une autorit de certification accrdite par tScheme suivant le principe cidessus. Aujourdhui, seules deux socits ont reu laccrditation tScheme ncessaire la distribution de certificats compatibles avec les services en ligne de ladministration anglaise.
Page 20
1.7
1.7.1
Suisse Lchec dune initiative prive

La socit SWISSKEY S.A.
Dans le souci dapporter aux transactions lectroniques la familiarit et la confidentialit semblables lunivers du papier, un partenariat entre Swisscom, Telekurs Holding S.A. et une association des chambres de commerce et dindustrie Suisse et de la principaut du Liechtenstein (DigiSigna) a donn naissance SWISSKEY S.A. au printemps 1998. Par aprs, SWISSCOM sest retir et a vendu ses parts Telekurs (en 2000). Ainsi, lactionnariat se prsentait de la faon suivante : Telekurs (95 %) et Digisigna (5%). SWISSKEY tait fournisseur sur le plan fdral et international de certificats numriques didentit pouvant garantir le respect de la confidentialit et de la sphre prive sur Internet. Lentreprise dlivrait des certificats numriques qui permettent de garantir lauthentification et la scurit des changes et du transfert des donnes sur Internet, tout en grant ceux-ci avec une infrastructure adquate. Cooprant troitement avec banques, offices postaux, chambres de commerce et dindustrie, SWISSKEY veillait ce que chaque certificat soit tabli sur la base dune vrification scrupuleuse de lidentit de lindividu ou de lentreprise titulaire. SWISSKEY assurait en outre une coordination internationale et garantissait la certification transversale avec dautres organismes de certification internationaux afin que les certificats mis en Suisse reoivent un bon accueil dans le monde entier. Parmi ces missions et prestations, nous retenons les suivantes : Etablissement et renouvellement des certificats numriques Rvocation de certificats expirs ou invalids Gestion et publication de la liste des certificats et de leurs titulaires Archivage et publication des listes de rvocation de certificats
SWISSKEY proposait deux catgories de solutions : A - un service de certification public destin aux particuliers et aux entreprises : SWISSKEY Personal ID : le certificat numrique didentit pour un usage priv SWISSKEY Corporate ID : la solution extensible de certification lusage dentreprises SWISSKEY Server ID : le certificat serveur pour crer des sites web scuriss. B - des Customer branded CA Services: Services de certification personnaliss pour entreprises et institutions dans le but de scuriser les communications internes dune entreprise tout en profitant de linfrastructure existante de SWISSKEY (sous-traitance chez SWISSKEY de lmission et de la gestion de certificats internes). Grce au SWISSKEY Certificate Management System (SCMS), lentreprise peut demander et administrer efficacement un grand nombre de certificats SWISSKEY Corporate ID. Il offre ainsi tous les avantages dune ICP locale. Le SCMS sadresse avant tout aux entreprises et aux organisations qui vont utiliser un grand nombre de certificats SWISSKEY et qui veulent en conserver une vue densemble. Ainsi, le gestionnaire peut donner des certificats prts lemploi, que ce soit sur une SWISSKEY SafeCard, sur une disquette ou sur tout autre moyen adquat. Les certificats universels de SWISSKEY reposaient sur des normes internationales (X.509 v.3, RSA, MD5) et taient compatibles avec toutes les versions rcentes de browsers WEB, applications de courriers, etc. 1.7.2 Un certificat de SWISSKEY en 6 tapes :
Afin dobtenir un certificat SWISSKEY, tout utilisateur doit passer par 6 tapes : Demande. A ladresse de www.swisskey.ch, on trouve un formulaire de demande de certificat remplir et imprimer.
Page 21
Enregistrement. Ensuite, muni dune copie de sa demande, le candidat se prsente en personne auprs dun service denregistrement agr par SWISSKEY dans sa localit en prsentant les papiers didentit afin de confirmer les donnes figurant sur la demande. A trs peu dexceptions, les chambres de commerce de Suisse et du Liechtenstein ainsi que toutes les succursales du Crdit Suisse et de lUBS en Suisse faisaient office de service denregistrement SWISSKEY et couvraient ainsi toute la Suisse. La liste complte tait disponible sur le site de SWISSKEY. Les personnes non-domicilies en Suisse devaient se faire confirmer leur identit par un notaire. Certification. Aprs rception et revrification de sa demande, un certificat est dlivr par le systme de gnration de cls de SWISSKEY. Confirmation. Par courrier, le candidat reoit une confirmation de SWISSKEY lui indiquant la procdure suivre pour retirer son certificat. Installation. Le candidat installe son certificat sur son ordinateur et auprs des applications pertinentes. Un certificat est valable deux ans. Il doit ensuite tre renouvel (en ligne) aussi longtemps quil est actif. Les informations concernant lidentification sont reprises de lancien certificat. Publication. SWISSKEY veille ce que la cl publique du certificat du candidat soit rpertorie et accessible toute personne voulant entrer en communication crypte avec lui. Linscription dans le rpertoire est facultative. SWISSKEY publie galement dans son rpertoire une CRL qui contient tous les certificats bloqus temporairement ou dfinitivement, peu importe laccord pralable de la personne concerne. 1.7.3 Linfrastructure
Linfrastructure de SWISSKEY tait construite de manire hirarchique, partant dune Root CA, qui a comme seul rle de certifier les metteurs et soi-mme. SWISSKEY a une hirarchie de CA 3 niveaux.
SWISSKEY Root CA
SWISSKEY Personal ID CA 512
SWISSKEY Personal ID CA 1024
SWISSKEY Corporate ID CA 512
SWISSKEY Corporate ID CA 1024
Figure 7 : Modalits daccrditation dune autorit de certification 1. Au sommet, il y a exactement un certificat Root CA (selfsigned) 2. Au niveau suivant, il y a les CA individuelles pour les diffrents groupes-cibles, qui sont toutes certifies par la SWISSKEY Root CA 3. Les certificats-utilisateurs se trouvent au niveau 3, cest--dire quils sont tous mis par une CA, mais pas par la SWISSKEY Root CA elle-mme. SWISSKEY supportait la certification des cls 512 bit et de 1024 bit. Le certificat SWISSKEY Root et les certificats SWISSKEY CA ont une cl de 2048 bit. En ce qui concerne les classes de certificats, SWISSKEY se concentrait tout dabord sur la fourniture de certificats cl avec vrification rigoureuse de lidentit du requrant, impliquant un contact personnel et visuel.
Page 22
Ceci correspond peu prs un certificat de classe 3 pour Verisign. Dans un premier temps, SWISSKEY nenvisageait pas de dlivrer de certificats sur la base dun contrle didentit effectu par une adresse de E-Mail. En ce qui concerne la cible vise, SWISSKEY tait un prestataire neutre et prt collaborer avec tous les cercles intresss, et non rserv des applications dun type spcifique. 1.7.4 Fin de SWISSKEY S.A.
Aprs trois ans, plus de 6000 particuliers se servaient dun SWISSKEY Personal ID et environ 500 organisations de toutes tailles utilisaient les produits SWISSKEY. Nanmoins, le 7 mai 2001, lmission de SWISSKEY ID et de SafeCard a t stoppe. SWISSKEY rvoquera les certificats existants la fin dcembre 2001. La demande de certificats numriques navait pas atteint le niveau attendu en Suisse et ds lors la rentabilit de la firme ntait pas assure. De mme, des prvisions ne laissaient pas croire que le seuil serait atteint dans un avenir proche. Sur le plan international, il savre galement que la demande de certificats universels natteignait pas suffisamment rapidement un volume permettant de couvrir les frais dmission et de gestion des passeports pour le monde numrique. Selon SWISSKEY, ce manque de demande proviendrait essentiellement du fait que, actuellement, sur Internet trop peu doffres et de solutions se basent sur des certificats numriques. Ce manque sexpliquerait par le degr lev de complexit que de tels projets prsentent. Malgr le fait quil nexistait aucune alternative la technologie ICP, elle serait beaucoup plus lente que prvue se rpandre. Le blocage dfinitif des certificats a t fix au 31 dcembre 2001, ceci afin de donner tous les clients SWISSKEY le temps ncessaire pour trouver des alternatives adquates. Une partie des activits ont t reprise par Payserv, une filiale de Telekurs. Il est envisageable que Payserv continue offrir des services spcifiques de certification pour des clients dune certaine taille (par exemple des banques). Aprs la disparition de SWISSKEY, dautres groupes ont montr leur intrt pour le service de certification, dont IG TOP (www.imsec.ch), SwissSign (www.swisssign.com, un joint venture entre think digital, S.W.I.S. Group et Swiss Secure) et SwissCert (www.swisscert.com, derrire lequel est la firme IT-Secure.com). Ce dernier est annonc dans plusieurs articles de presse comme celui qui sera le plus probable de prendre la relve de SWISSKEY. 1.7.5 Signature digitale
Dans sa stratgie pour une socit de linformation en Suisse, le Conseil dEtat avait dj adopt en avril 2000 lordonnance sur les services de certification lectronique (OSCert, http://www.admin.ch/ch/f/rs/7/784.103.fr.pdf ). Ceci a marqu un premier pas en direction de la reconnaissance de la signature lectronique en Suisse. Lordonnance fixe les exigences essentielles dans le domaine des services lis la signature numrique et permet aux fournisseurs de tels services de se faire reconnatre sils remplissent ces exigences. La reconnaissance est dlivre par des organismes de certification accrdits auprs du Service daccrditation suisse (SAS) de lOffice fdral de mtrologie. Les fournisseurs de services de certification pourront sen prvaloir comme un label de qualit. Ils resteront toutefois libres de fournir des services de certification en dehors du systme prvu. Dans une deuxime tape, le conseil dEtat a approuv le 9 juillet 2001 la loi sur les services de certification dans le domaine de la signature digitale (ZertES) (http://www.ejpd.admin.ch/Doks/PM/2001/bg-zertes-d.pdf )15. Elle traite de la reconnaissance lgale de la signature lectronique et la met au pied dgalit avec la signature manuscrite si elle repose sur un certificat dune instance de certification accrdite. Cette mme loi fixe aussi les rgles concernant laccrditation des prestataires de services de certification ainsi Message relatif la loi fdrale sur les services de certification dans le domaine de la signature digitale : http://www.ejpd.admin.ch/Doks/PM/2001/bot-zertes-f.pdf
15
Page 23
que les responsabilits qui leur incombent. Aprs la mauvaise exprience de SWISSKEY, la loi admet que lEtat peut mettre lui-mme des certificats. Elle prvoit que lEtat peut charger une administration dmettre des certificats digitaux qualifis qui peuvent aussi tre utiliss dans la sphre prive. Daprs le journal Der Bund du 11 juillet 2001, le Dpartement Fdral de Justice et Police (EJPD) a t charg de mener une tude sur la mise disposition tous les citoyens suisses dune identit digitale. De plus, il semble quils tudient si ce concept de lidentit digitale pourrait tre tendu la Smartcard. Lobjectif de la cration de la signature digitale est surtout de faciliter les transactions avec les administrations. Selon lEJPD, il faut viter que chaque administration organise un systme isol. Apparemment, il est envisag dquiper la carte didentit avec un chip qui contiendrait les informations ncessaires pour toutes les offres dans le cadre du e-gouvernement. Le citoyen serait nanmoins libre dopter pour cette nouvelle carte didentit. Le concept de la SmartCard aurait, toujours selon le EJPD, lavantage de permettre facilement des extensions vers les utilisations dans le secteur priv. LEJPD est convaincu que cette solution va trs vite se propager et cela malgr les rsultats mitigs qua connu ce concept en Finlande (6000 personnes disposent dune SmartCard aprs deux ans). Les premiers rsultats de cette tude de faisabilit seront attendus pour automne 2001.
Page 24
1.8
Synthse et Conclusions
Les diffrents projets prsents dans ce rapport ont ceci de commun quils ont tous t, leur origine, initis par ladministration publique, en gnral un Ministre. Avec le dveloppement fulgurant quont connu les moyens de communication rseaux, et lInternet en particulier la fin des annes 90, est apparu la mme poque la problmatique de lidentification fiable de ses usagers. Plusieurs secteurs sont concerns par ce besoin. Ils ncessitent des niveaux de scurisations distincts et de ce fait, une approche organisationnelle distincte : Les besoins inter-administration Certains pays comme lAllemagne ou lItalie ont su mettre rapidement des moyens de communication inter-administration scuriss afin dassurer la confidentialit et lintgrit des informations changes tout en offrant la possibilit dauthentifier les fonctionnaires via des technologies plus ou moins complexes. LAllemagne a rglement, via le BSI, lusage des certificats au sein du rseau intranet des administrations (IVBB) et une autorit de certification suprieure a t cre pour assurer la reconnaissance mutuelle des solutions ICP dployes par les administrations. Le rseau RUPA, lintranet Italien des administrations, offre aujourdhui les mmes fonctionnalits ses fonctionnaires la diffrence prs quun unique certificateur, le centre technique RUPA, joue le rle de certificateur pour lensemble des besoins des administrations. Ces projets nont jamais abord la problmatique de lauthentification lectronique dans son ensemble, ni les aspects dinteroprabilit avec dautres secteurs qui ncessitent galement lusage des certificats (communication administration-citoyens, commerce lectronique, ). Leurs objectifs taient principalement doutiller correctement et rapidement les administrations qui, au fil du temps, ressentaient un rel besoin en terme de scurisation des changes de donnes via rseaux informatiques. Les besoins citoyens-administrations ou entreprises-administrations Pour lensemble des pays tudis, les projets de grande envergure ont t justifis pour rpondre ces besoins afin de pouvoir proposer des services en ligne scuriss. Cela se fait gnralement par tapes successives : 1. Mise disposition, via des technologies web, des formulaires administratifs Aucune scurit nest exige puisque le transport des donnes ventuellement confidentielles se fait par voie postale. 2. Mise disposition, via des technologies web encryptes, des formulaires administratifs Cela permet de remettre ladministration des informations confidentielles via web, mais cette dernire naura aucune certitude concernant lauthentification de celle ou celui qui est lorigine de la communication. A quelques exceptions prs, ces deux premires tapes sont dployes dans les pays tudis dans la mesure o elles sont simples mettre en uvre, tant sur un plan technique quorganisationnel. La dernire tape consiste authentifier tous les acteurs via un change de certificats entre les deux parties. Lintrt est vident et bien compris de toutes les administrations puisque cela ouvre la porte ladministration virtuelle, scurise, et plus efficace. Pour atteindre ce but, on distingue deux grandes approches. La premire consiste dployer une carte didentit lectronique, la seconde, rglementer le march du certificat lectronique qui est prsent dans tous ces pays. Le commerce lectronique et les besoins externes aux administrations Cest un tat de fait, le commerce lectronique a dbut bien avant le dploiement des services administratifs en ligne. Ce march ncessite galement lusage de moyens de communication scuriss ainsi que celui de techniques dauthentifications. Force est de constater quaujourdhui, le particulier nest pas porteur de certificat essentiellement pour des raisons de complexits techniques. Il nest donc pas encore dusage, dans le cadre du
Page 25
commerce lectronique, dexiger du client une identification fiable alors que les outils et les standards pour ce faire, existent. Le secteur bancaire est un cas particulier dans la mesure ou chaque banque ou presque a les moyens de fournir sa clientle une solution e-banking maison. Suite ce constat, on pourrait sattendre ce que les administrations publiques aient un rle de facilitateur ou dinitiateur puisquelles dveloppent elles-mmes des solutions de communication avec ses citoyens. On pourrait sattendre ce que les aspects dinteroprabilit soient pris en compte afin que les utilisateurs naient pas porter une multitude de certificats ou utiliser plusieurs techniques dauthentification. Les solutions tudies prcdemment ne vont pas dans ce sens puisque, une fois de plus, la priorit a t mise sur les besoins propres aux administrations. Que ce soit via la carte didentit lectronique ou via la rglementation du march des certificateurs, les pays tudis ne sont facilitateurs que dans la mesure o ils gnralisent petit petit lusage dune authentification fiable sur lInternet. Mais leurs actions ne visent pas directement rpondre lensemble des besoins, tous secteurs confondus. Les diffrentes approches. Sur les six pays tudis, lItalie, la Finlande et la Belgique ont opt pour le dploiement dune carte didentit lectronique. La Belgique nen est quau dbut du projet, mais lItalie et la Finlande ont dj men des tests grandeur nature. Pour ces trois projets, lide principale consiste remplacer la carte didentit actuelle, au format papier ou plastique, par une carte au format carte de crdit. Des informations lisibles et relatives lidentit du porteur sont inscrites sur la carte et un microchip est implant pour lidentification lectronique, la signature lectronique ainsi que pour lencryption des donnes. Le circuit de distribution de ces cartes, la gestion des certificats implants dans ces cartes sont systmatiquement la charge de ladministration, qui se porte garante de la fiabilit de cette nouvelle identit. Il existe cependant des diffrences notables entre ces cartes, diffrences qui influeront directement sur leurs usages : La carte italienne contient un certificat anonyme. Ce nest pas le porteur qui est authentifi mais son numro de carte didentit. En supposant que cette carte puisse tre utilise dans un cadre externe aux administrations, il ny aura pas la possibilit dauthentifier directement le porteur si lon nutilise que son certificat. La carte finlandaise propose deux certificats, le premier pour lauthentification et le second pour la signature lectronique. Enfin, la carte belge se veut plus ouverte. Elle peut mmoriser un certificat dauthentification, un certificat de signature ainsi que plusieurs autres certificats de qualit. Imposer lusage dun certificat didentit, dlivr par ladministration, peut convenir une majorit de secteurs privs dsirant authentifier ses clients. A lexception peut-tre du secteur bancaire qui souhaitera ventuellement imposer ses certificats afin davoir une matrise complte du niveau de scurit ou des aspects de confidentialit. Une carte didentit qui permettrait de mmoriser des certificats personnels, autres que ceux dlivrs initialement par ladministration, est peut-tre une voie explorer si lon souhaite dmocratiser lusage dune unique carte didentification lectronique. La France et le Royaume-Uni ont prfr rglementer lexistant, savoir, les autorits de certification, afin de spcifier le niveau de scurit minimum requis dans le cadre de lusage des services en ligne mis la disposition des citoyens. Si lapproche est la mme, lenvergure des moyens dploys ne lest pas. En France, seul le Ministre des Finances a pris les devants afin de rpondre ses propres besoins. Le Royaume-Uni, quant lui, a une approche beaucoup plus globale puisquun certificat en provenance dune autorit de certification accrdite permet daccder lensemble des services administratifs en ligne. La Suisse a ragit trs rcemment en dbutant une tude de faisabilit concernant la carte didentit lectronique. Mais elle dispose dores et dj, depuis avril 2000, de larsenal juridique, ainsi que de linfrastructure adquate, ncessaire laccrditation des autorits de certification. Cette accrditation tait initialement un label de qualit dlivr par ladministration. Cest aujourdhui le label de qualit minimum requis en Suisse pour pouvoir dlivrer des certificats utiliss comme signature lectronique.
Page 26
Si cette approche permet de rpondre aux besoins immdiats des administrations, ces tats ninterviennent pas en tant que facilitateurs et laissent le secteur priv se dvelopper indpendamment du secteur public. Au travers des sept pays qui sont tudis dans ce rapport, on distingue nettement trois approches distinctes. Les deux premires concernent les initiatives prises par les tats (ou une administration) qui souhaitent rpondre leurs besoins immdiats dauthentification du citoyen, soit en dployant une carte didentit lectronique, soit en cherchant rglementer le march priv du certificat. La troisime approche est celle de la Suisse qui, dans un premier temps, na pas souhait intervenir et a laiss le secteur priv sorganiser. Si ces approches rpondent des besoins bien prcis, tel que la scurisation des changes entre les citoyens et leurs administrations, elles sont nettement moins convaincantes ds lors quil sagit daborder le problme dans son ensemble. Les aspects dinteroprabilits entre les secteurs concerns (privs, publics), de reconnaissance de la solution ICP vis--vis du monde extrieur, ou de contrle de la multiplication des certificats sont rarement pris en considration. Des initiatives uniquement prives, comme SWISSKEY, ont disparu pour cause de faillite financire alors que les besoins, en terme de scurisation des changes de donnes, existent bien en Suisse comme ailleurs. Vendre du certificat est beaucoup trop technique et mercantile pour pouvoir remporter un succs auprs du public. Seuls quelques initis et les entreprises y voient un rel intrt. Lextrme inverse, adopt par lItalie et la Finlande, consiste dployer une solution publique via une carte didentit. Ce choix est certainement prenne puisque officiel, mais bien que nous nayons que trs peu de recul pour porter un jugement objectif, rien ne dit quil remportera un consensus de la part de tous les secteurs. LItalie a fait le choix dun certificat anonyme dlivr par le Ministre de lIntrieur et donc non reconnu par les Root CA classiques. En Finlande, force est de constater quil y a un certain attentisme de la part du secteur priv alors quil pourrait pleinement exploiter une solution existante. Ces choix, certainement adapts aux besoins des administrations, sont beaucoup trop rigides pour convenir toutes les situations. Enfin, la spcificit du Luxembourg implique la prise en compte des travailleurs frontaliers. Ces derniers reprsentent 35 % des emplois sur le territoire et sont, au mme titre que les Luxembourgeois, utilisateurs des services administratifs. Les choix qui seront retenus par le Luxembourg devraient, idalement, tenir compte de lexistant dans les pays limitrophes mais les solutions de ces pays, ne sont ce jour, pas suffisamment mres pour tre srieusement prises en considration. En supposant que le Luxembourg opte pour une solution didentit lectronique, lusage de certificats de qualits permet de prendre en compte les personnes qui ne peuvent avoir une identit lectronique luxembourgeoise (les travailleurs frontaliers ou les trangers qui rsident sur le territoire Luxembourgeois) mais qui lon souhaite donner un accs aux services administratifs luxembourgeois en ligne.
Page 27
2. Les initiatives au Grand Duch de Luxembourg

2.1 Linitiative de la Chambre de Commerce
La Chambre opre actuellement une solution en matire d'ICP. Dans cette solution, elle joue le rle de RA et aussi partiellement (pour la partie non technique) celle de CA (PSC). Pour la partie purement technique, la solution de GlobalSign (ex BelSign) a t retenue. GlobalSign gre la partie technique lie la construction du certificat, la partie publique relative la mise disposition des cls publiques ainsi que la publication du LDAP. La Chambre prend en charge toutes les activits en relation avec la gestion des certificats : vrification des donnes relatives ltablissement dun certificat numrique, dcision d'mission et de rvocation des certificats. 4 types de certificats sont actuellement mis pour un total denviron 200 certificats distribus : 1. Certificat de classe 3 (de lordre de 40 certificats mis) Lmission de ces certificats repose sur une identification physique dune personne et de lassurance de sa reprsentation dune socit. Le format des certificats respecte les normes les plus rcentes (X509, V3). Outre les informations habituelles, ce certificat comprend lidentit de la personne ainsi que de la socit quil reprsente. Ces certificats sont essentiellement utiliss par les socits dans le cadre de leurs exportations et relations commerciales. 2. Certificat de classe 2 (de lordre de 60 certificats mis) Lmission de ces certificats repose sur une identification de la personne (photocopie dun passeport, etc.) Une utilisation de ces certificats est par exemple celle que fait une socit qui met des bases de donnes interrogeables en ligne via le Web et qui veut restreindre les accs ces bases. Plutt quune solution base sur un login, elle distribue un certificat tout ses clients et ceux-ci lutilisent lors de leur connexion via Internet. 3. Certificats de serveur (de lordre de 100 certificats mis) Ils assurent lidentification des serveurs. Leur utilisation est rendue obligatoire par Cetrel pour tous les sites e-business avec lesquels il y a une connexion avec Cetrel. 4. ObjectSign. Il sagit dun nouveau produit qui permet dassocier un certificat tout fichier informatique transfr. Ils permettent aux vendeurs de logiciels de sidentifier auprs de leurs destinataires. A ce stade, force est de constater que lutilisation massive de certificats (ne serait ce que dans les changes de courrier) nexiste pas aujourdhui et quil est important didentifier les bons business case en la matire. Un exemple concerne bien entendu les relations entre les entreprises et les administrations. Il est signaler que la socit GlobalSign grant la partie technique relative la gestion des certificats ne se trouve pas sur le sol luxembourgeois. Cette socit jouit cependant dune reconnaissance certaine, le fait tant que les certificats mis par cette socit sont considrs comme certificats root par les browsers et les systme de messagerie les plus connus (Outlook, Netscape). Enfin, signalons quune initiative globale est actuellement en cours dlaboration au niveau europen pour lintgration (c--d linteroprabilit) des certificats mis par les diffrentes chambres de commerce (initiative ChamberSign).
Page 28
2.2
Linitiative LuxTrust
Nous faisons le point dans ce chapitre sur linitiative prise par lABBL au niveau de ltablissement dune ICP dans le secteur financier. Fin 2000, sur base dun business case dfini par PWC, lABBL a dcid dun projet permettant lvaluation de la mise en place dun Trust Center (LuxTrust) au niveau des banques. Ce projet est pilot par un steering committee compos de reprsentants de 12 banques de la place; rcemment la Poste a rejoint linitiative. Dautres banques dont le sige principal est situ hors Luxembourg ne participent actuellement pas au projet en raison du cot pressenti. Dans un premier temps, un projet pilote doit tre mis en place afin dvaluer la faisabilit technique dun systme ICP dans un environnement reprsentatif (gestion de lordre de 4000 certificats et 14 RA). A cette occasion, un certain nombre dlments seront valus tels que : lutilisation dune smart card avec deux certificats (signature et encryption) base sur lutilisation de pseudonymes dans le cadre dun mail scuris (S/MIME) et pour des communications scurises sur le Net (SSL), la conformit aux standards internationaux, lvaluation des technologies OCSP et LDAP, etc. . A ce stade, lvaluation des attribute certficate na pas t considre. Outre ces considrations techniques, le pilote doit tre galement suffisamment stable que pour pouvoir tre ensuite tendu au systme live. La procdure suivie a commenc avec un appel doffre qui a rsult en une trentaine de rponses. Avec laide dexperts trangers, des slections ont rduit successivement 19, puis 6 et enfin 3 le nombre doffres, deux des dernires offres tant bases sur la technologie Baltimore. Afin de limiter le cot de cette phase dvaluation, il semble envisag de ne tester que deux propositions. Pour cette valuation, il est ncessaire de dgager une enveloppe de 488.000 EUR. Celle-ci couvre le la gestion des certificats (AC et AE) ainsi que l'tude Cetrel, une tude juridique, les environnements de Production, de Backup et de Test. Aprs cette phase de test, la mise en uvre de la solution proprement dite est estime 1.600.000 EUR. Depuis quelques mois, des rflexions ont conduit tendre le concept initial un concept plus global incluant une autorit de certification au niveau du domaine public (GovTrust). Le modle propos est dcrit dans le document suivant : LuxTrust, rapport managrial, Cetrel, 31 juillet 20001 . La discussion initialise dans ce document servira de base aux propositions que nous discuterons dans la suite du document au chapitre 3.3.
2.3
Autres initiatives
Plusieurs socits prives ont rcemment propos leurs services au Gouvernement luxembourgeois pour la mise en place de PKI pour les besoins du Gouvernement, pour les besoins de tous les acteurs concerns de secteurs public et priv du Grand-Duch de Luxembourg, pour linteroprabilit de PKIs au niveau communautaire, europen voire mondial.
Page 29
3. Les aspects Luxembourg
lgaux
au
Grand
Duch
de
Le dploiement du commerce lectronique induit une adaptation de la lgislation afin de permettre la reconnaissance de la signature lectronique dans l'ensemble des transactions qu'elle affecte. Le Luxembourg, comme la plupart des pays europens, a traduit la directive europenne dans sa lgislation nationale. Deux textes constituent aujourd'hui la lgislation luxembourgeoise: - la loi du 14 aot 2000 relative au commerce lectronique (http://www.etat.lu/memorial/T00_a/tablealp.html /Economie /Commerce). - le rglement grand-ducal du 1er juin 2001 (http://www.etat.lu/memorial/T01_a/tablealp.html /Economie /Commerce). La prsente tude ne s'attache pas rendre un avis sur ces textes ou sur leur mise en application. Plusieurs ressources peuvent nanmoins tre cites dans ce domaine: - Les services du Ministre de l'Economie qui ont particip l'laboration des textes. - Le Professeur A. Prm du CRP Gabriel Lippmann. - Me Stephan Legoueff, auteur d'un rapport intitul "Le commerce lectronique et le droit luxembourgeois" downloadable sur: http://www.vocats.com/vocats/LeGoueff.nsf/ArticleEng/DBF7DF77113F40C1C1256A DC0051C4B0?OpenDocument Il est important de noter que la lgislation en vigueur donne la mme valeur la signature lectronique qu' une signature conventionnelle dans la mesure o l'on respecte le principe des certificats mis dans une ICP. Ainsi, la loi ne bouleverse pas les principes habituels mais les tend aux nouvelles technologies.
Chapitre II Les besoins
Page 30
Chapitre II.
Les besoins
1. Les besoins du Secteur Public

Notice : Pour des raisons videntes de confidentialit, certaines donnes internes cette section ont t volontairement masques.
Pour mener bien cette tude, il convenait d'identifier les besoins des Ministres, Administrations et Services Publics en matire de signature lectronique. Pour ce faire, le projet a consult plusieurs organismes publics dans un double objectif. Tout dabord, il s'agissait d'identifier les projets en cours ou les ides de projets qui auraient ncessit une ICP. Ensuite, il sagissait de recueillir diffrentes ides ou recommandations concernant la mise en place de cette infrastructure. Les besoins repris ci-dessous sont ceux qui nous semblent impacter de manire directe le choix d'une ICP. D'autres projets intressants, trs proches des technologies de la Socit de l'Information ne sont pas repris ici car ils ne ncessitent pas l'utilisation d'une ICP. La liste des Administrations consultes est donne ci-dessous : Administration du Cadastre et de la Topographie Administration des Contributions Directes Administration des Douanes et Accises Administration de l'Enregistrement et des Domaines Centre Commun de la Scurit Sociale Centre de Communication du Gouvernement Centre Informatique de l'Etat Chambre des Dputs Ministre des Affaires Etrangres Ministre de lAgriculture Ministre des Classes Moyennes, du Tourisme et du Logement Ministre des Finances Ministre de la Fonction Publique et de la Rforme Administrative Ministre de la Justice et l'Administration Judiciaire Ministre de la Sant Ministre des Transports Ministre du Travail et de lEmploi Ministre des Travaux Publics Police Grand-Ducale Service Information et Presse Service des Mdias et des Communications Restena
Page 31
1.1
Des besoins identiques
Lors de nos entrevues nous avons identifi des projets ou besoins identiques d'une administration l'autre. 1.1.1 Communication lectronique externe
Lors d'une demande de renseignements manant d'un citoyen ou d'une entreprise, l'administration doit souvent rpondre de manire officielle. Dans l'tat actuel des choses, si la demande est faite par e-mail, l'administration rpondra par courrier postal pour apporter un caractre officiel la rponse, garantir le respect des procdures en matire de signature et garder une copie du courrier sortant. Le fait d'utiliser la signature lectronique dans la communication lectronique externe apporterait le caractre officiel un mail de rponse une premire sollicitation lectronique. Il reste cependant identifier l'outil capable de supporter la signature lectronique et d'organiser l'utilisation de ce nouvel outil pour garantir le respect des procdures en matire de signature. Le retour sur investissement pourrait tre important car la plupart des administrations sont confrontes la question. 1.1.2 Procdures internes
L'ensemble des agents de l'Etat sont amens quotidiennement changer des documents dans le cadre de procdures bien tablies. Ces changes s'oprent au sein de l'administration ou entre des administrations concernes par une mme procdure. Habituellement, la faon de faire est d'utiliser le courrier physique. En effet, pour des raisons de scurit et parce quactuellement le document lectronique n'a pas la valeur d'un document physique, le courrier lectronique est plus rarement utilis dans ce contexte. Plusieurs administrations ont mis en vidence les avantages de numriser certaines procdures dans deux buts principaux: - acclration des changes, - prennit des changes. La signature lectronique permettrait d'une part de donner au document lectronique la mme valeur que le document papier et d'autre part de garantir l'identit des diffrents acteurs. En outre, cette problmatique est commune l'ensemble des administrations, ce qui devrait garantir un retour sur investissement intressant. Encore faut-il que le systme mis en place puisse s'intgrer aux diffrentes applications mtiers des administrations. Les rsultats d'un tel projet restent internes aux administrations et les retombes directes pour le citoyen sont apparemment faibles. Notons cependant que la mise en place d'un systme de workflow associ la signature lectronique constitue un systme "back office" de toute premire utilit pour connatre par exemple l'tat d'avancement d'un dossier. Nous pensons donc que la mise en place d'un workflow constitue une tape indispensable dans la mise en uvre d'applications en ligne pour le citoyen et les entreprises.
Page 32
1.2
Des besoins de mme type
Nous avons repris ici les projets ou applications ncessitant une potentielle utilisation d'une ICP et pertinentes dans le cadre de e-Luxembourg. Elles sont regroupes en diffrentes catgories d'application. Les dclarations fiscales Les dclarations de POLICE Les demandes de documents officiels Les constitutions de dossiers Les transactions en ligne
Page 33
2. Les besoins du Secteur Priv

Des rencontres ont eu lieu avec la Chambre du Travail, la Chambre des Mtiers et de la Chambre des Employs Privs. Elles ont permis de mettre en lumire les besoins en matire d'ICP. De tels besoins doivent encore tre exprims par la Fedil, celle-ci ayant initialis une enqute concernant ceux-ci. Tant la Chambre du Travail que la Chambre des Employs Privs se positionnent en termes de consommateurs de signature lectronique destination des relations avec le secteur public. Elles ne prvoient pas actuellement de produire et grer des signatures destination de leurs membres. Le besoin essentiel concerne la possibilit dun email scuris permettant dencrypter les informations et/ou dauthentifier le correspondant ainsi que parfois de vrifier lintgrit des documents changs. Parmi les organismes cibls, on peut citer : le Ministre de lEducation Nationale, de la Formation Professionnelle et des Sports, le Ministre de la Famille, le Ministre du Travail, le Ministre des Finances, lADEM, le Statec, la Chambre des Dputs, le Conseil Economique et Social. Au niveau dun applicatif scuris, il a t identifi la ncessit de pouvoir introduire en ligne les feuilles de relevs mensuels destination de lIGSS. Un tel formulaire doit tre remis mensuellement par toutes les entreprises et est actuellement sur support papier. Dans le futur, en tant qumetteur de cls, la Chambre des Employs Privs pourrait imaginer une gestion scurise lectronique de ces changes avec ses membres mais dans ce cas une simple identification au niveau du certificat serait suffisante. Sil ny a pas de projet ICP en cours la Chambre des Mtiers, des besoins ont t identifis tant au niveau des relations de la Chambre avec ses membres quau niveau des membres/Chambre avec le secteur public. Un rle important de la Chambre consiste dans lassistance la cration dentreprises et dans la gestion de leur immatriculation. Il serait important de pouvoir automatiser cette procdure impliquant la socit, le secteur artisanal concern, la Chambre des Mtiers et le Ministre des Classes Moyennes. A noter que la carte dartisan nest jamais attribue la socit elle-mme mais bien au niveau du patron (personne physique) ou de son grant technique ayant la qualification ncessaire. Le principe didentification est donc galement valable ce niveau. Au niveau des diffrentes chambres ou organes reprsentatifs (comme le CRTIB), il y a un besoin important de scurisation dans lchange des documents entre les professionnels du secteur. Des besoins spcifiques sont galement relatifs aux appels doffre pour les chantiers publics. En outre, des besoins identifis concernent les applicatifs suivants: les relations avec la TVA, avec le Centre Commun , le paiement des cotisations, les contributions, les relations avec la centrale des bilans ainsi quau niveau du registre de commerce. Dans son rle, la Chambre des Mtiers serait intresse de pouvoir offrir une infrastructure ICP commune ses membres ainsi que de dfinir et dassurer des rles de AC/AE. NB : La Chambre des Mtiers ne couvre pas les professions librales (OAI) pour lesquelles des besoins doivent galement tre identifis. Linteroprabilit entre les diffrents secteurs est bien entendue importante. Les entrevues conduites dans le cadre des prsents travaux sont: Chambre de Commerce: P. Emering, S. Breier, J-C. Wirth CETREL: M. Hemmerling, C. Harpes, J. Plumer, Y. Nullens ABBL:L. Thiel Chambre du Travail: M. Wagner, M. Detaille Chambre des Employs Privs: T. Wiltgen, C. Frising Chambre des Mtiers: M. Gross, C. Bram
Page 34
3.
Typologie des besoins
L'ensemble des besoins prsents dans les 2 premires parties de ce chapitre correspondent des besoins types tels le mail scuris, le transfert de documents intgres, l'envoi de documents signs et horodats, Nous avons repris ici des besoins types des applications en ligne et expliqu l'impact de leur mise en uvre.
3.1
L'authentification
Actuellement, la plupart des applications en ligne qui veulent identifier un utilisateur, proposent une interface dans laquelle le systme demande une identification de l'utilisateur (UserId) et un mot de passe confidentiel. Cette faon de faire entrane une multiplication d'UserId et de mots de passe qui dans certains cas seront grs par l'utilisateur sur un support physique. Les fournisseurs d'applications sont de plus en plus nombreux, aussi bien au niveau de l'Etat que du secteur priv. Si l'on veut pouvoir dvelopper plus d'applications en ligne et offrir des conditions d'utilisation favorisant l'mergence de tlservices, il pourra tre intressant de diminuer la gestion des accs ces diffrents services en vitant de multiplier les donnes d'accs aux applications. L'utilisation de certificats et donc d'une infrastructure cl publique permet de rpondre cette problmatique. En effet, un mme certificat dlivr pour une personne, pourra tre utilis pour son identification auprs de plusieurs applications. Dans ce contexte, l'utilisation d'un certificat d'identit unique permettrait chaque citoyen et aux entreprises de disposer d'un moyen souple d'accs aux tlservices. Il convient cependant de distinguer dans l'authentification le fait de dcliner son identit relle ou d'utiliser un alias. Cette seconde faon de faire peut se rvler utile lors de transactions ne ncessitant pas la connaissance de l'identit du tiers. En cas de problme il sera toujours possible de retrouver l'identit de la personne sur base de son alias. Dans une utilisation courante, le commerant ne connat pas l'identit de l'acheteur, ce qui est souvent le cas dans des transactions commerciales traditionnelles.
3.2
L'autorisation
Lorsque qu'une personne veut aujourd'hui acheter un bien dans un commerce, elle ne dcline en gnral pas son identit. Le commerant doit cependant tre capable de formaliser l'acte conomique correspondant la vente du bien. Actuellement cela se concrtise naturellement par la rencontre physique des deux parties. Sur Internet, cette rencontre n'existe pas. Il conviendrait donc que l'acheteur soit capable de poser un acte sans ncessairement s'authentifier.
3.3
Le cryptage
Le cryptage est une technique qui permet de cacher le contenu d'un document lectronique et de la rendre lisible uniquement pour certaines personnes connues au moment de l'encryptage. Cette technique est une des solutions pour rpondre aux besoins de confidentialit. Il est important de noter que l'utilisation des techniques de cryptographie dans une entreprise n'est pas sans poser des problmes organisationnels. Le premier est que le cryptage est une technique assez contraignante dans la mesure o les acteurs concerns, l'auteur et les destinataires, doivent tre connus lors du cryptage du document. Donc si une personne est remplace par une autre au sein de l'entreprise (dans la
Page 35
mme fonction), cette nouvelle personne sera incapable de lire les messages crypts de son prdcesseur. Ce cas de figure revient quitter sa fonction avec tout ses dossiers. Il en va de mme pour une absence inopine de longue dure, personne dans l'entreprise n'a accs l'information. Le problme est li au fait que le certificat n'est pas associ un rle, mais bien une personne. Une des pratiques permettant de remdier ce problme est la cration d'un Key Escrow pour l'entreprise. Le Key Escrow ou "notaire des cls prives" garde une copie de toutes les cls prives utilises dans l'entreprise des fins d'encryption. De cette manire, en cas de besoin, l'on peut utiliser le double d'un cl. Les rgles qui permettent d'utiliser les cls stockes par le Key Escrow sont dfinir et leur application est primordiale pour la russite d'une telle organisation. On le comprend trs rapidement, ce type d'organisation impose que chaque employ possde, outre une ventuelle cl prive personnelle, une cl prive professionnelle. Le second problme est la maintenance qu'il faut oprer rgulirement sur les fichiers pour qu'ils restent compatibles avec les standards du moment. Ce travail permanent est indispensable, si l'on veut tre capable de lire des messages crypts encods il y a 5 ou 10 ans.
3.4
La fonction ou les qualits
L'utilisation de la signature lectronique dans le cadre d'une fonction au sein d'une entreprise ncessite la mise en place d'une organisation adapte. Le fait qu'un employ ou agent de l'Etat volue au sein de l'organisation, l'amne occuper des postes diffrents. On peut comprendre aisment que l'aptitude signer tel ou tel type de document peut voluer avec ces postes. Ainsi un certificat utilis dans une fonction A ne pourrait tre valable dans la fonction B. Si c'tait le cas, le dtenteur du certificat disposerait d'un accs trs large l'information. On peut assimiler ce cas la personne qui change de bureau, mais qui garde les cls de son ancien bureau. Dans le mme ordre d'ide, il faudra dfinir l'utilisation des cls dans les entreprises qui accderont aux applications des diffrentes administrations. Sur ce point on peut en effet avoir plusieurs cas de figures. La premire solution serait de crer une cl qui permet d'authentifier la socit et que celle-ci puisse poser des actes. Cette solution prsente le dsavantage de ne pas pouvoir identifier la personne physique qui pose un acte au nom de la socit. La seconde solution est de travailler avec des certificats authentifiant la personne physique qui pose des actes au nom de la socit. Cette question des fonctions ou des qualits qu'une personne physique possde est assez complexe et peut tre rgle par l'utilisation des certificats d'attribut (techniquement peu rpandu) ou des Privilege Management Infrastructure et par la mise en place d'une organisation adapte.
3.5
L'intgrit des donnes
L'intgrit des donnes est la garantie que les donnes n'ont pas t altres accidentellement ou de manire volontaire. Actuellement, ce sont les systmes d'information eux mmes qui garantissent l'intgrit des donnes. En effet si vous tes connect un systme dans lequel vous posez des actes, c'est le systme informatique qui sera le seul pouvoir garantir que vous avez bien pos cette acte. Les technologies de base de donnes actuelles permettent un administrateur de modifier les donnes contenues dans ces bases. La garantie d'intgrit dans les applications actuellement repose donc partiellement sur la confiance faite aux administrateurs de ces systmes.
Page 36
L'utilisation de la signature lectronique permettrait de remdier cette faille de scurit. Le fait de signer un document peut garantir galement l'intgrit des donnes qu'il contient. Dans cette configuration, les administrateurs de systmes informatiques ne peuvent plus modifier les donnes de faon indtectable. Il est clair que l'utilisation d'une infrastructure cls publiques pour garantir l'intgrit des donnes est la solution la plus adapte, mais il faut tre conscient du travail accomplir sur l'ensemble des applications existantes. Le systme actuel bas partiellement sur la confiance faite aux administrateurs restera encore une solution rpandue dans les annes venir.
3.6
L'utilisation de canaux scuriss vs. La signature de document
Lors de nos entretiens et dans les travaux qui s'en sont suivis, la discussion de l'utilisation d'une transmission signe ou de la signature du document transmis est souvent apparue. Il est clair que cette discussion est trs lie au contexte de l'implmentation physique du transfert. Dans le premier cas, une fois que le document est transmis, il n'y a rien qui peut indiquer une ventuelle certification. Seule l'application qui garde ce document pourrait garantir le document. Dans le second cas, le document une vie propre puisqu'il est lui mme certifi. Qu'il soit utilis dans un envoi ou bien consult dans une application, il garde toutes ses qualits intrinsques. Ce second cas est bien entendu plus intressant que le premier, mais sa mise en uvre est actuellement plus dlicate. La problmatique prsente ici est fort semblable au point prcdent.
3.7
Le time stamping
Cette technique est utilise pour garantir la date d'envoi d'un document lectronique. Elle sera indispensable lors de l'envoi de documents l'administration avec date limite ou pour la longvit de validit de donnes signes avec une cl arrive expiration. Le time stamping se base galement sur une infrastructure cls publiques et fait intervenir des tiers de confiance (TTPs, Trusted Third Parties).
3.8
De l'exploitation des donnes existantes au sein de l'Etat
La mise en uvre de guichets virtuels pour le citoyen et l'entreprise couple la signature lectronique apporterait une valeur ajoute dans les changes avec l'Etat. Un des avantages serait pour le citoyen et l'entreprise de ne plus devoir passer par plusieurs administrations dans le cadre d'une mme procdure. Les guichets virtuels permettraient une recherche automatique d'information dj prsente dans les systmes d'information de l'Etat. Ainsi, le requrant, en une seule opration, pourrait disposer de l'ensemble de l'information requise. Prcdemment, il collectait cette information auprs de plusieurs administrations. Cette collecte automatique d'information au sein de l'Etat pose deux problmes. Tout d'abord le respect de la directive sur la protection des donnes c'est--dire que des donnes transmises ne peuvent tre utilises par l'administration qu'aux fins pour lesquelles elles ont t transmises. Il faudrait donc avoir l'autorisation d'aller collecter de l'information pour un requrant donn. Cette autorisation pourrait tre donne au travers du guichet virtuel. Le second problme est li la disponibilit et la qualit de cette information. Il conviendrait sur ce point de pouvoir revoir certains fichiers cls de l'administration afin qu'ils constituent de vritables rfrences pouvant tre utilises par l'ensemble des applications de l'Etat.
Page 37
4. Conclusions
Au terme de ces consultations, plusieurs lments sont intressants noter. En termes de besoin en administrations, il est trs difficile d'apporter une conclusion une diversit de besoins si importante. Nous tenons cependant attirer l'attention du lecteur sur deux besoins aux antipodes l'un de l'autre. Le premier, sans doute le plus rpandu dans les entrevues que nous avons conduites, est l'introduction de la signature lectronique dans les changes de mail lectronique. Le nombre de personnes concernes est important, et l'application est assez simple car les outils du march pourraient rapidement supporter la signature lectronique. Le second besoin est beaucoup moins visible mais fondamental dans le dploiement d'applications pour le citoyen. Il s'agit de la mise en uvre de systme de gestion de flux de documents, les workflows. Ces systmes de back-office sont ncessaires dans toutes les applications traitant du suivi de dossiers. Un autre lment sous estim ce jour est l'impact organisationnel li la mise en uvre de la signature lectronique. En effet mme si la signature lectronique aura, grce la mise en uvre d'une ICP, la mme valeur qu'une signature papier, les procdures administratives devront tre adaptes aux spcificits d'une ICP. Ce volet organisationnel est selon nous important et devra tre trait avant tout dploiement d'applications utilisant les certificats. L'Etat joue un rle moteur dans le dploiement de telles infrastructures. Outre son rle de facilitateur conomique en soutenant des initiatives favorisant le dploiement d'applications en ligne ou tlservices, le gouvernement peut lui-mme tre moteur en dployant des applications pour les entreprises et les citoyens. Aux vues des diffrents besoins d'application dans les administrations, il conviendra de choisir quelques applications pilotes qui feront l'objet d'une attention particulire dans la conduite du projet de mise en uvre. Le choix de ces applications est primordial, il peut se baser sur des critres tels le nombre d'utilisateurs concerns, la capacit de ceux-ci assimiler les NTIC et plus particulirement la signature lectronique, le nombre de transactions annuelles, le retour sur investissement pour l'administration, la visibilit pour le grand public, Outre le choix et le suivi de la mise en uvre d'applications pilote, il conviendra de toujours observer l'volution des diffrentes composantes de la signature lectronique, en cela les aspects technologiques et les aspects juridiques.
Chapitre III Les scenarii de mise en oeuvre
Page 38
Chapitre III. Les scenarii de mise en oeuvre

1. Etude des diffrents scenarii
Dans ce qui suit, nous allons analyser diffrents scenarii dune infrastructure cl publique. Diffrentes architectures organisationnelles sont possibles en termes du positionnement des prestataires de services de certification (PSC) et des autorits denregistrement (AE). Pour chaque scnario, nous allons dresser un cadre descriptif et procder une analyse thorique. Dans cette analyse, nous nous focaliserons essentiellement sur les questions dorganisation dune telle hirarchie, ainsi que sur les liens entre les diffrents organes composants. Notons simplement que chaque modle connat ses forces et faiblesses. Il est donc absolument ncessaire de prendre en compte le contexte dans lequel on veut implanter une telle architecture avant de la choisir. Pour chaque scnario, nous allons adopter une grille danalyse identique. Dans un premier temps, nous allons brivement dcrire, dune manire gnrale, lorganisation du modle prsent ainsi que son implmentation sur le march luxembourgeois. Ensuite, nous allons rflchir sur des problmes plus concrets lis au modle, savoir larrive dun nouveau PSC sur le territoire luxembourgeois et les liens dinteroprabilit avec les applications et certificats trangers. Puis, nous nous pencherons sur les consquences du modle pour lEtat, et cela la fois en tant quutilisateur de cl publique et en tant que fournisseur dapplications. Enfin, nous nous intresserons aux consquences pour le citoyen sur le sol luxembourgeois. Le volet technique n'est que trs peu abord dans cette partie. La section suivante dans ce chapitre traitera de la problmatique lie linteroprabilit dun point de vue technique.
1.1
Scnario 1 : Aucune initiative coordonne
Cadre gnral
Ce scnario vise dmontrer les consquences pour le Luxembourg d'un modle o aucune initiative coordonne ne se met en place. En quelque sorte, cest le scnario dans lequel lEtat assume dans une moindre mesure son rle de facilitateur conomique. Description du cadre luxembourgeois
Dans le cas o aucune initiative coordonne ne serait envisage, deux risques majeurs peuvent se prsenter. Soit, vu les investissements entreprendre pour tablir une telle infrastructure, les secteurs renoncent un systme d'ICP propre et achtent des solutions lextrieur. Dans ce cas, le Luxembourg risque un retard dans un domaine aussi sensible que la scurit des transactions et lidentification des divers intervenants lors dun change lectronique. Soit, des initiatives indpendantes vont voir le jour conduisant plusieurs ICP indpendantes et non interoprables (souvent non-rentables aussi, vu la taille du Luxembourg). On arriverait donc une situation o il existerait une multiplicit de certificats (un pour chaque domaine dapplication, voire pour chaque application), ce qui risque de crer une confusion et une lassitude des utilisateurs. Ceci ne favoriserait pas lutilisation grande chelle des certificats, ce qui a de nouveau un impact ngatif sur la rentabilit des diverses initiatives (qui dpend en large partie du nombre de certificats mis).
Page 39
Lexemple des Etats-Unis devrait constituer un avertissement cet gard. En effet, des initiatives indpendantes se sont cres un peu partout (DOD PKI, NASA PKI, NFC PKI, University PKI, Illinois PKI,). Suite cela, afin de remdier au caractre non-interoprable de ces diffrentes architectures, le gouvernement amricain a lanc linitiative dtablir une ICP cross-gouvernementale, omniprsente et interoprable. Le Luxembourg a la chance de ne pas disposer ce moment dune vritable ICP rpandue. Il faudrait donc profiter de cette situation pour implmenter directement une ICP interoprable et accessible tous. Par rapport une ICP, lEtat joue plusieurs rles. Il est tout d'abord lgislateur. Ensuite il est lui-mme utilisateur, car ses agents doivent bnficier de certificats pour interagir avec les citoyens. Il est galement fournisseur d'applications en ligne pour le citoyen. Outre ces rles principaux, il est, selon notre avis, facilitateur conomique. Ainsi, le gouvernement pourrait intervenir lors de llaboration dune stratgie commune en matire d'ICP et participer mettre en place un systme d'ICP performant au Luxembourg afin de favoriser le dveloppement du commerce lectronique. Reste dfinir un partenariat pour cette ICP luxembourgeoise, qui rpondra aux besoins de tous les acteurs impliqus. Larrive dun autre PSC sur le march luxembourgeois
Comme aucune initiative coordonne nexiste sur le march luxembourgeois, il ny a, premire vue, pas dentrave particulire quant son dveloppement. Dautre part, labsence de toute initiative coordonne fait quil nexiste pas de systme auquel il pourrait greffer son infrastructure pour rendre ses certificats interoprables avec toute une srie dapplications. Liens et interoprabilit
Lorsque chaque organisation met en place sa propre ICP, il faut alors que chaque organisation se crosscertifie avec les autres PSC ou se greffe sur un arbre de confiance hirarchique existant. Ceci engendre des ngociations difficiles entre les diffrents prestataires. Une autre option serait que les organisations dcident dutiliser, ct de leur ICP interne, des certificats tablis et reconnus de par le monde (type Verisign) pour leurs communications externes. Consquences pour lEtat
LEtat en tant quutilisateur de cls a ainsi deux options pour scuriser ses changes internes et externes. Ou bien il achte des certificats chez un prestataire externe, ou bien il met en uvre sa propre ICP. Lors dun achat lextrieur, il na aucun contrle sur linfrastructure et ds lors, il y a un certain risque. De plus, il est dpendant dune socit externe. Lorsquil opte pour la mise en oeuvre dune ICP indpendante, cela engendre ncessairement des cots dinvestissements lourds en termes techniques et humains. En tant que fournisseur dapplications, lEtat peut avoir une approche ouverte, cest--dire reconnatre tous les providers sur le march. Le citoyen est donc libre de choisir le prestataire qui lui convient le mieux. Une consquence pour lEtat est quil doit implmenter dans son systme autant dAPI16 quil y a de providers sur le march. Une alternative serait de limiter le nombre dAPI dployer pour accder aux applications des diverses administrations. Pour ce faire, il peut dcider de fournir lui-mme les certificats utilisables ou de faire appel une socit externe. Ici, on est donc de nouveau devant le mme problme que pour son rle dutilisateur.
API (Application Program Interface) : interfaces entre les applications et les composants PKI
16
Page 40
Consquences pour le citoyen
La consquence de cette non organisation pour le citoyen est quil devra disposer dune carte pour chacune des applications utilises. Dautre part, la multitude des prestataires de services de certification accepts devrait orienter les prix des certificats vers un niveau concurrentiel.
Page 41
1.2
Scnario 2 : Un prestataire de services de certification unique
Cadre gnral
Partons du plus basique des modles reposant sur un et un seul Prestataire de Service de Certification, PSC (CA), qui est responsable pour la prestation des services de certification pour tous les utilisateurs de la mme ICP. Un tel modle est certainement le plus facile tablir, cependant il montre ses limites lorsque la communaut des utilisateurs devient plus grande et surtout plus diversifie.
PSC
Alice
Bob
Figure 8 : Le modle de base Description du cadre luxembourgeois
Appliqu au Luxembourg, cela revient envisager un prestataire de services de certification unique, en charge de lmission de certificats utilisables dans toutes les applications des diffrents acteurs conomiques. Dans ce qui suit, nous allons utiliser le nom LUXEMBURGISH TRUST ORGANISATION (LTO) pour dsigner cet organe.
Luxemburgish Trust Organisation (PSC)
AE 1
AE 2
AE 3
Figure 9 : Schma conceptuel du modle de base Dans ce scnario, il y a un PSC LUXEMBURGISH TRUST ORGANISATION qui met des certificats de classes et de niveaux de scurit diffrents. La LUXEMBURGISH TRUST ORGANISATION, en tant que PSC, agit comme ROOT PSC et sauto-certifie. Cet organisme serait supervis par un comit compos des reprsentants des diffrents secteurs fondateurs. Nanmoins, il pourrait rester ouvert aux autres secteurs intresss par la suite. Cet organe dfinit une policy et une CPS ( Certificate Practice Statement ) pour les
Page 42
certificats quelle met. Les membres de la LUXEMBURGISH TRUST ORGANISATION agissent ensuite en tant qu'autorit d'enregistrement (AE). Cette initiative a le mrite quelle propose un niveau de scurit trs lev. Tout le monde utilise le mme type de certificat qualifi, donc il doit rpondre aux ncessits de lacteur le plus demandeur en termes de qualit et de scurit, en loccurrence lEtat. Ce niveau de scurit lev saccompagne dun niveau de cot lev en termes humain et technique (longueur de cl par exemple), cot qui sera certainement rpercut aux utilisateurs. On peut d'ailleurs s'interroger sur lutilit dun tel niveau de scurit maximale pour les diffrents secteurs en jeu. En outre, comme relev plus haut, dans une structure hirarchique, il faut que les diffrents acteurs se mettent daccord sur le contenu du certificat qualifi et sur un processus dmission et denregistrement unique. Vu les diffrents besoins des acteurs, cela risque de devenir lourd raliser. Ce modle impliquerait aussi que chaque AE, peu importe le secteur auquel elle appartient, soit qualifie pour enregistrer les donnes dune personne pour lmission dun certificat qualifi utilisable dans tous les domaines. Concrtement, une AE quelconque peut tre amene enregistrer une personne et lui fournir un certificat qualifi quelle va utiliser lors de sa dclaration fiscale par exemple. Arrive dun autre PSC sur le march luxembourgeois
Une fois l'ICP LUXEMBURGISH TRUST ORGANISATION tabli, un nouveau PSC dsireux de s'installer sur le march luxembourgeois, rencontrerait de rels problmes se dvelopper. Dune part, tous les citoyens qui souhaitent communiquer avec les administrations publiques disposent dj dun certificat, et dautre part, celui-ci est aussi utilisable pour des applications dans dautres domaines. Il devrait donc tre extrmement difficile pour un autre PSC de fournir des certificats au grand public. Ceci est vrai moins que les certificats LUXEMBURGISH TRUST ORGANISATION ne disposent pas dune grande reconnaissance lextrieur des frontires du Grand-Duch. Dans ce cas, un prestataire de services de certification de renomme internationale pourrait occuper la part de la certification des transactions transfrontalires. Liens et interoprabilit
Afin dassurer linteroprabilit avec les certificats manant dautres pays, il faut que le ROOT PSC LUXEMBURGISH TRUST ORGANISATION se fasse reconnatre par ses paires en Europe et dans le monde entier. Pour ce faire, elle peut se crosscertifier avec les autres ROOT PSC ou se rattacher un arbre de confiance existant. Nous reviendrons sur ce dernier point la section suivante. Une autre possibilit envisager est de crer, un niveau europen une sorte de PSC qui se charge de linteroprabilit des diffrentes infrastructures au niveau europen (du moins en ce qui concerne les applications administratives). Consquences pour lEtat
LEtat en tant quutilisateur de cl va recourir linfrastructure LUXEMBURGISH TRUST ORGANISATION pour ses besoins internes et externes. Il dispose de certificats dun niveau de scurit lev, qui de plus sont accepts dans toutes les applications des partenaires associs la LUXEMBURGISH TRUST ORGANISATION. En tant que fournisseur dapplications, il tirera ncessairement un bnfice de lunicit du certificat existant. La facilit y rsultante devrait favoriser la propagation du certificat et par l son utilisation lors des changes lectroniques avec les administrations.
Page 43
Cependant, il reste le problme que nimporte quelle AE du systme peut rcolter les informations sur un individu et lui dlivrer un certificat qualifi. Cela ncessiterait des procdures lourdes de contrle pour sassurer du srieux du travail des AE. Consquences pour le citoyen
Lunicit du certificat qualifi pour toutes les applications (administrations, bancaires,..) reprsente certes un avantage pratique pour lutilisateur. Il a donc une seule carte manipuler. Au niveau financier, lachat dun seul certificat devrait savrer moins onreux que la configuration o l'on doit se procurer un certificat pour chaque domaine dapplications. Certes, lorganisation est en position de quasi monopole pour lmission de certificats utilisables au Luxembourg, ce qui priori ne devrait pas favoriser un prix comptitif et attractif. Plusieurs arguments plaident cependant en faveur de cette proposition. Ce genre de business prsente une structure de cot atypique, savoir des cots fixes initiaux importants et des cots marginaux faibles. Le fait dmettre un certificat supplmentaire ne fait pas augmenter les cots dune manire significative. Ds lors, la rentabilit est essentiellement lie au nombre de certificats mis. On pourrait argumenter que la concurrence orienterait les prix la baisse et les ramnerait un prix proche du cot marginal. Cependant pour avoir une telle concurrence, on devrait sassurer que tous les certificats soient parfaitement interoprables et accepts dans tous les domaines. Si une telle interoprabilit nest pas garantie, on se retrouverait dans une situation, o chaque prestataire de services de certification est en position de monopole dans son domaine respectif. Dautre part, lEtat, en tant que facilitateur conomique et membre de la LTO a tout intrt favoriser la propagation du certificat et imposer un prix attractif. Comme le certificat est en principe utilisable pour toutes les applications, il se peut que le certificat contienne des informations (attributs/qualits de lutilisateur) qui ne sont destines qu une seule application. Par exemple, le certificat pourrait contenir des informations sur la solvabilit de lutilisateur. Cette information pourrait tre ncessaire pour des applications bancaires. Or, comme le certificat est identique pour toutes les applications, tous les fournisseurs dapplications auraient accs cette information. Un problme de violation de la vie prive pourrait alors se poser. Dun point de vue psychologique, cela ne contribue certainement pas mettre lutilisateur en confiance et par l, la promotion de lutilisation des certificats numriques. Un certificat contenant plusieurs attributs d'un mme utilisateur poserait galement des problmes en terme de rvocation. En effet, les cycles de rvocation des divers attributs ne sont pas les mmes.
Page 44
1.3
Scnario 3 : Un prestataire de services de certification unique
Cadre gnral
Le scnario ne diffre du prcdent quen un seul point, savoir le lien quil entretient avec un ROOT PSC au niveau international. Ici, il ne sautocertife pas, mais ses certificats reposent sur des certificats mis par un ROOT PSC connu et tabli. Description du cadre luxembourgeois
Cette hirarchie est similaire celle dcrite avant, sauf quici, la LTO a un lien hirarchique avec un organisme de certification (un Root PSC) connu au niveau international. Pour mettre des certificats, la LTO ne sautocertifie plus, mais base ses certificats sur les certificats dun PSC tabli. Lobjectif de cela est de faciliter la reconnaissance du certificat audel des frontires luxembourgeoises, et par l, daccrotre le spectre d'utilisation de son certificat. Ds lors, en grande partie, les mmes commentaires simposent que pour le scnario prcdent.
ROOT PSC
(au niveau international)
AE 1
AE 2
AE 3
Figure 10 :Schma conceptuel du modle de base avec lien vers linternational Arrive dun autre PSC sur le march luxembourgeois
Nous avions identifi prcdemment comme niche de march la certification des transactions transfrontalires. Avec ce lien hirarchique tabli avec un prestataire de services de certification connu, il ny a plus dentrave la reconnaissance du certificat LUXEMBURGISH TRUST ORGANISATION lextrieur des frontires luxembourgeoises. Ds lors, il va savrer encore plus difficile pour un nouveau PSC de sinstaller sur le march luxembourgeois. Afin de concurrencer la LTO, il lui reste donc deux paramtres. Le niveau de scurit et le prix du certificat. Le nouveau PSC pourrait galement se positionner en tant que fournisseur de certificats anonymes, au cas o cette option ne serait pas envisageable pour les certificats qualifis LTO.
Page 45
Liens et interoprabilit
Cest ici que rside le grand avantage dune telle approche. Le fait de se lier un ROOT PSC connu donne une valeur ajoute au certificat LTO. Les utilisateurs sont de cette manire assurs quils peuvent utiliser leur certificat dlivr par la LUXEMBURGISH TRUST ORGANISATION dans dautres applications. Une autre approche serait de se crosscertifier avec des paires dans dautres pays. Nous reviendrons sur les dangers et opportunits dune telle approche dans le scnario suivant. Le revers dune telle approche est que le certificat national LTO se trouve ainsi sous tutelle dune instance internationale et doit sadapter aux critres techniques et scuritaires de cet organisme. Consquences pour lEtat
LEtat, comme tout autre utilisateur, pourrait profiter de cette reconnaissance accrue du certificat au-del des frontires. Un problme peut se poser en tant que fournisseur dapplications. Comme le certificat LUXEMBURGISH TRUST ORGANISATION fait partie dun arbre de confiance sous tutelle dune instance trangre, la LTO doit se conformer aux exigences manant de ce ROOT PSC. Donc il se pourrait que le certificat rponde encore moins aux besoins de lEtat. De plus, il pourrait savrer dangereux que toute la communication avec les administrations luxembourgeoises reposent sur un prestataire de services de certification tranger et sur lequel lEtat na aucune mainmise. Nous pouvons imaginer les consquences nfastes dune faillite subite de ce ROOT PSC. Consquences pour le citoyen
Une meilleure reconnaissance du certificat facilite lutilisation du certificat et permet au citoyen de recourir ce mme certificat lors des changes internationaux.
Page 46
1.4
Scnario 4 : La structure hirarchique
Cadre gnral
Afin de mieux rencontrer les besoins spcifiques, il est souhaitable de dvelopper des ICP diffrentes pour chaque type de communaut quon fdrera ensuite. Pour cela, il y a essentiellement deux faons de procder : une relation hirarchique ou une relation peerto-peer . Dans une relation hirarchique, tous les utilisateurs font confiance au mme Root PSC. Celuici nmet en gnral pas de certificats aux utilisateurs, mais se concentre sur lmission de certificats aux PSC subordonns. Chaque PSC a tout au plus un seul lien suprieur. Chaque PSC peut mettre des certificats aux utilisateurs ou dautres PSC subordonns, pour crer ainsi un arbre de confiance. Le PSC suprieur impose des conditions lmission dun type de certificat au PSC subordonn. Ces conditions sont connues et ds lors ne doivent pas faire lobjet dune spcification dans le contenu du certificat. Le grand avantage de ce modle par rapport aux prcdents, cest que chaque PSC subordonn peut mettre ses propres certificats, en adaptant les caractristiques aux besoins du secteur en question.
PSC PSC PSC PSC
Figure 11 : Le modle hirarchique Un tel modle prsente certainement des avantages de reprsentation des relations entre les diffrentes composantes du modle. La structure hirarchique permet ainsi aux utilisateurs de bien comprendre et connatre les domaines dapplication des diffrents PSC (CA). Ce modle permet aussi une standardisation des policies (rgles) travers linfrastructure crant ainsi une assurance de scurit globale plus accrue que tous les autres modles PSC multiples. De mme, lintgration dune nouvelle ICP se fait de manire assez facile (tout est relatif, en ralit cest bel et bien plus compliqu que cela parat), vu quil suffit de relier le ROOT PSC de cette ICP avec un des PSC de la hirarchie existante. Cette structure de larbre de confiance et le caractre unidirectionnel des relations permettent aussi de retrouver assez rapidement le chemin de certification. Ces chemins de certification sont en rgle gnrale assez courts. Nanmoins, la structure de larbre connat aussi des points faibles, notamment le fait que toute la structure repose sur une seule entit, savoir le Root PSC de la hirarchie. En effet, la disparition de cette entit pourrait savrer catastrophique pour toute la structure. Dautre part, il est probable quil est politiquement impossible de se mettre daccord sur un seul Root PSC. Des conflits dintrts entre les diverses entreprises et administrations participantes peuvent entraver un tel accord. Lorsquon est dans le cas o les communauts d'utilisateurs sont constitues de diffrentes entits lintrieur dune mme entreprise, le modle hirarchique peut trs bien fonctionner. Un problme surgit probablement lorsque les communauts reprsentent des socits
Page 47
diffrentes et indpendantes. Dans ce cas, leur relation nest pas base sur un tel lien suprieur subordonn. Description du cadre luxembourgeois
Dans ce scnario, la LUXEMBURGISH TRUST ORGANISATION joue le rle de pur PSC. Il nmet pas directement aux utilisateurs, mais sert comme ROOT PSC pour les PSC sectoriels et certifie les certificats mis par les PSC sectoriels. Cest elle qui gre linfrastructure technique commune, et tablit une Certificate Policy pour les certificats LTO. Ainsi, les certificats mis par les PSC sectoriels sont dpendants dun point de vue technique et dun point de vue politique de la LUXEMBURGISH TRUST ORGANISATION. Nanmoins, ceux-ci dfinissent eux-mmes en fonction des besoins des applications du secteur le contenu et le niveau de scurit de leurs certificats. Ce lien hirarchique permet de sassurer quil existe une certaine homognit des certificats portant le nom LUXEMBURGISH TRUST ORGANISATION. Ceci parat essentiel pour la construction dune corporate image des certificats LTO et dun espace de confiance transparent.
LTO PSC Secteur 1
LTO PSC Secteur 2
AE
AE
AE
AE
AE
AE
Figure 12 : Schma conceptuel du modle hirarchique
Cet arbre de confiance dans lespace de confiance LUXEMBURGISH TRUST ORGANISATION amne aussi une interoprabilit entre les diffrents secteurs. Comme tous les utilisateurs ont comme seul point unique de confiance le ROOT PSC, cela leur permet de vrifier assez rapidement la crdibilit du certificat prsent. Cependant, cela ne veut pas dire que nimporte quel certificat mis par un PSC quelconque de linfrastructure sera accept dans toutes les applications des diffrents secteurs. Une relation dacceptation pourrait tre unilatrale. Concrtement, on pourrait simaginer que les banques acceptent les certificats mis par lEtat, mais pas inversement.
Larrive dun autre PSC sur le march luxembourgeois
On retrouve essentiellement les mmes problmes que cits plus haut pour les autres scenarii. Afin de rendre ses certificats interoprables avec les certificats LTO, le PSC arrivant sur le march luxembourgeois pourrait ainsi ngocier de pouvoir se greffer sur larbre de confiance LTO et accepter comme autorit suprieure le ROOT PSC LUXEMBURGISH TRUST
Page 48
ORGANISATION. Ceci signifierait nanmoins une perte dautonomie norme, vu quil devrait se conformer linfrastructure existante dun point de vue technique et politique. Liens et interoprabilit
Pour analyser le cas, prenons lexemple de deux ICP indpendantes et structures de manire hirarchique, en loccurrence une ICP luxembourgeoise et belge. Le cas deux infrastructures facilitera la comprhension du problme. Nanmoins, la constellation n ICP ne diffre pas fondamentalement du cas simple.
PSC PSC PSC PSC PSC
PSC PSC PSC
ICP luxembourgeoise
ICP belge
Figure 13 : Deux ICP hirarchiques indpendantes Afin de rendre ces deux domaines interoprables, un lien doit tre tabli entre les deux. Concrtement, le problme est le suivant. Est-ce quun citoyen belge peut utiliser son certificat belge auprs dune application dune administration au Luxembourg ? Si oui, il doit tre possible pour ladministration luxembourgeoise de vrifier la crdibilit de son certificat belge. Vu quil ny a aucune liaison de confiance entre les deux infrastructures, cela pose problme. A dfaut dun tel lien, il faudrait donc que les administrations luxembourgeoises acceptent comme point de confiance le ROOT PSC belge ou bien que le citoyen belge se procure un certificat luxembourgeois afin de communiquer avec ladministration au Luxembourg. Pour crer un tel lien, il existe thoriquement deux possibilits, savoir un lien hirarchique ou une relation peer-to-peer. Supposons aussi quaucun ROOT PSC naccepte de devenir subordonn de lautre. Linitiative doit donc venir dune instance suprieure reconnue par les deux, en loccurrence europenne, pour crer une sorte de ROOT PSC europen qui certifie les diffrents ROOT PSC au niveau national. Lalternative consisterait inciter les prestataires nationaux la cross certification. De cette manire, aucune instance suprieure ne doit tre mise en uvre. Nanmoins, un nombre non ngligeable daccords bilatraux devraient tre signs. Ce nombre daccords bilatraux pourrait tre diminu en instaurant au niveau europen un Bridge Authority , conformment ce qui sest pass aux Etats-Unis. Cela permet dautant plus dintgrer et de relier des ICP de structures diffrentes. Cette dernire solution parat presque invitable, vu quau niveau europen les diverses initiatives en cours pour le moment ne se font pas de manire concerte ou dune faon top down . De plus, chaque pays adapte son modle aux caractristiques propres de son conomie. La cration dun Bridge Authority au niveau europen nous parat la seule manire de relier des ICP de structures diffrentes, tout en vitant de passer un nombre innombrable daccords bilatraux et en permettant aux prestataires nationaux de garder une certaine autonomie.
Page 49
Consquences pour lEtat
A lintrieur des frontires luxembourgeoises, lEtat, en tant quutilisateur, pourrait se voir confronter au problme que les autres secteurs PSC nacceptent pas son certificat pour leurs applications. En effet, le lien avec le ROOT PSC LUXEMBURGISH TRUST ORGANISATION garantit une reconnaissance, mais cela ne veut pas dire que les PSC sont automatiquement obligs daccepter les certificats des paires. Si tel tait le cas, lEtat devrait se procurer et grer plusieurs certificats sil dsire communiquer avec les autres communauts. Si en plus de la reconnaissance, les fournisseurs d'applications acceptaient les certificats mis pour le compte de l'Etat , alors lEtat dtiendrait un certificat unique, sous son contrle, et qui serait utilisable dans les autres domaines. Cette structure narrange cependant rien dun point de vue reconnaissance en dehors des frontires luxembourgeoises. Le problme reste le mme quavant. Ds lors si le certificat LTO manque de reconnaissance lors des transactions internationales, lEtat se voit contraint de disposer dun deuxime certificat reconnu pour tout ce qui concerne le volet international. En tant que fournisseur dapplications, ce modle permet lEtat (et aux autres secteurs) de concevoir leur certificat de manire rencontrer leurs besoins au mieux et de ladapter aux fonctionnalits requises pour les applications des administrations. Nanmoins, il doit tenir compte des rgles techniques et politiques imposes par le ROOT PSC. Ces rgles sont en gnralement fixes en consensus avec les autres secteurs reprsents. Consquences pour le citoyen
Lutilisateur na connatre quun seul point de confiance, savoir le ROOT PSC. Tout le systme est chapeaut par cet organe. Cela vitera au citoyen de connatre toute la structure de l'ICP. Quant linteroprabilit entre les diffrents domaines de la LUXEMBURGISH TRUST ORGANISATION, tout dpend des accords entre les secteurs. De mme, le citoyen espre utiliser son certificat LTO pour des applications internationales. Cela dpendra de la notorit et de la reconnaissance du certificat LTO au-del des frontires luxembourgeoises.
Page 50
1.5
Scnario 5 : Mesh hirarchie
Cadre gnral
Une alternative cette structure hirarchique est de relier les PSC par une relation peer-topeer 17. Il existe diffrentes formes dune telle relation entre paires . Cependant, elles sont toutes bases sur le principe de la cross certification, qui est en quelque sorte un accord de confiance bilatral entre deux entits dune ICP. Deux PSC par exemple smettent mutuellement des certificats et reconnaissent par l lquivalence entre leurs deux certificats. Cette reconnaissance est prcde par une analyse des Certificate Policies et par la comparaison des aspects de scurit des deux types de certificat sous analyse. Une cross certification peut tre mutuelle ou unilatrale. Une forme de cette cross certification est connue sous le nom Mesh PKI architecture ou Web of trust architecture
PSC 1
PSC 3
PSC 2
Figure 14 : La mesh architecture Dans ce cas de figure, tous les PSC sont des points de confiance. Par lmission de certificats entre les PSC (dune manire bilatrale), les deux PSC en question reconnaissent leur relation de confiance mutuelle. Comme il sagit dune relation entre paires, il nest pas question quun PSC impose des conditions lautre PSC quant aux certificats que celui-ci peut mettre et la faon dy procder. Cependant, il se peut que la relation soit accompagne de certaines conditions, par exemple, une restriction du domaine dapplication. Dans ce cas, il faut que ces limitations de confiance soient spcifies dans le certificat mis au paire. Cette structure prsente lavantage par rapport au modle hirarchique que les diffrents PSC sont organisationnellement indpendants et peuvent avoir des policies diffrentes. Elle permet aussi dintgrer aisment une nouvelle communaut dutilisateurs par le simple fait dtablir une relation de confiance avec un autre PSC du systme existant. Dautre part, la disparition dun PSC ne met pas en cause la survie de la totalit de larchitecture. Cependant, cette structure dispose aussi de quelques points ngatifs, d en large partie au caractre bidirectionnel des relations de confiance. Premirement, le dveloppement du chemin de certification est plus complexe. En effet, un chemin dun utilisateur vers un point de confiance est non dtermin. Lexistence de plusieurs possibilits rend la tche de vrification plus ardue et moins structure. Au pire, la vrification pourrait mme rsulter en un dead end . Lorganisation dune structure mesh ne permet pas lutilisateur (ni aux processus de peer: A person who has equal standing with another or others, as in rank, class, or age. ( The American Heritage Dictionary of the English Language, Fourth Edition, 2000 by Houghton Mifflin Company.)
17
Page 51
vrification des certificats) de connatre le domaine dapplication du certificat. Pour connatre celui-ci, il doit se baser sur le contenu du certificat, ce qui complique videmment les choses. De plus, la cross certification peut introduire une cascade de confiance non-dsire de par le principe de transitivit. Pour y remdier diverses possibilits existent ( name constraints , policy constraints , path length constraints , ). Elles ont toutes comme objectif de se protger contre les effets pervers de la transitivit des relations de confiance. Description du cadre luxembourgeois
Cette hirarchie se caractrise par un organe suprieur aux diffrents PSC, qui a en quelque sorte un rle fdrateur. Cest cet organe qui va rdiger une Certificate Policy (CP), qui servira par la suite comme rgle que les diffrents PSC utilisant lappellation LUXEMBURGISH TRUST ORGANISATION devront respecter. Ainsi la LTO devient le garant de la cohrence des diffrents policies au niveau des PSC pour crer ainsi une corporate image homogne. La LTO soccuperait donc de tout ce qui joint la promotion des certificats et de la marque LUXEMBURGISH TRUST ORGANISATION ainsi que de la surveillance du respect des normes LTO dites. Le lien entre LUXEMBURGISH TRUST ORGANISATION et les diffrents PSC est donc plutt un lien formel que technique. Chaque secteur dispose dun PSC, qui dfinit lui-mme par rapport la Certificate Policy du groupe sa propre Certificate Policy et sa Certificate Practice Statement et dtermine le certificat quil veut mettre en tenant compte de la spcificit du secteur. Les secteurs pourraient donc, dans le cadre prdfini par lorgane fdrateur, adapter leur certificat qualifi aux besoins de leur march. Ce modle leur fournit donc la flexibilit tout en bnficiant de limage de marque de la LUXEMBURGISH TRUST ORGANISATION.
Luxemburgish Trust Organisation (rle fdrateur)
LTO PSC Secteur 1
Cross certification
LTO PSC
Secteur 2
AE
AE
AE
AE
AE
AE
Figure 15 : Schma conceptuel dune structure mesh Larrive dun autre PSC sur le march luxembourgeois
Les mmes remarques que prcdemment simposent ici. Cependant, pour rendre ses certificats interoprables avec ceux de la LUXEMBURGISH TRUST ORGANISATION, il suffirait au nouveau PSC de se crosscertifier avec les secteurs PSC. Liens et interoprabilit
Cette fois-ci, les dcisions dinteroprabilit se prennent au niveau sectoriel, vu que la LUXEMBURGISH TRUST ORGANISATION na quun rle fdrateur et nagit pas en tant que PSC. Les PSC secteurs sont libres de choisir la faon de rendre leurs certificats interoprables.
Page 52
Ainsi on pourrait simaginer quau niveau europen, tous les PSC administrations se crosscertifient mutuellement et acceptent les certificats mis par les autorits nationales. Remarquons quici aussi la tche pourrait tre allge en instaurant une Bridge Authority au niveau europen. De cette manire, chaque autorit nationale naurait passer quun seul accord avec cette Bridge europenne pour assurer linteroprabilit des certificats europens. Consquences pour lEtat
LEtat dispose de son propre certificat quil est mme dadapter ses propres besoins. De mme que lors du scnario prcdent, il contrle ses AE et dtermine les procdures denregistrement pour son certificat. En ce qui concerne linteroprabilit avec les PSC des autres secteurs, cest lui qui va mener les ngociations et le cas chant dlimite le champ dapplications des autres certificats. Ainsi, on pourrait trs bien imaginer quil existerait une relation unidirectionnelle de confiance, cest--dire que les certificats mis par le gouvernement seraient accepts dans les autres domaines mais que lEtat prserverait le monopole pour ses propres applications. Ainsi tous les citoyens luxembourgeois disposant du certificat mis par lEtat pourraient utiliser le mme certificat pour toutes les applications, et les autres secteurs soccuperaient davantage de leur clientle non couverte. Un PSC qui vise un public ncessitant une reconnaissance internationale importante de ses certificats pourrait ds lors recourir dautres types de lien. Ainsi, un PSC secteur pourrait dcider de se lier une ROOT PSC international pour garantir sa reconnaissance au niveau international. Cela viterait aussi que toute linfrastructure LTO soit sous tutelle dune organisation trangre. Ainsi lEtat en tant quutilisateur de cl publique dispose dun certificat (presque) entirement sous son contrle et, en tenant compte de ses propres besoins, il peut tablir une liaison de confiance avec les prestataires lis. En tant que fournisseur dapplications, il peut dterminer quels certificats seront accepts pour ses applications. Ainsi, il peut dcider de restreindre son choix ses propres certificats. Ainsi, tout personne qui dsire communiquer avec lEtat devrait se procurer un certificat de lEtat et se prsenter auprs dune autorit denregistrement autorise. Consquences pour le citoyen
Si aucune cross certification ne se fait entre les diffrents PSC sectoriels, le citoyen est oblig de se procurer plusieurs certificats. Ceci a le dsavantage de grer et dacheter un certificat pour chaque domaine dans lequel il veut lutiliser. Dun autre ct, la multiplicit des certificats pourrait tre un garant de la confidentialit des informations spcifiques contenues dans chaque certificat. Si les diffrents secteurs imposent leur certificat propre pour accder leurs applications, le client sera oblig de payer le prix fix par les PSC en question.
Page 53
1.6
Scnario 6 : Bridge Certification Authority
Cadre gnral
Afin de combler les dfauts des deux modles prcdents, un nouveau modle pour lier les diffrents PSC a t pens. Ce modle a t implment aux Etats-Unis afin de coordonner les initiatives indpendantes qui se sont dj dveloppes prcdemment. Il sagissait donc l dune approche bottomup . Le modle de la Bridge Certification Authority (BCA) (ou Bridge PSC) peut aussi tre vu de manire inverse, cest--dire baser le modle ds le dpart sur cet organe afin de garantir linteroprabilit.
PSC 1 Bridge PSC
PSC 2
PSC 3
PSC 4
Figure 16 : Une architecture avec un Bridge PSC Le modle BCA est construit selon une structure distribue et non hirarchique. Ainsi, il ne figure pas en tant que Trust point pour les utilisateurs comme dans le modle hirarchique. Cela permet aux utilisateurs de garder leur point de confiance initial. Son objectif est de raliser des relations peer-to-peer entre les diffrentes communauts dutilisateurs. Mais contrairement la mesh PKI PSC, la Bridge PSC nmet pas de certificats directement aux utilisateurs. Elle ne crosscertifie quavec des PSC. La BCA tablit un bridge de confiance entre les diffrentes communauts afin de leur permettre dinteragir travers la BCA avec un niveau de scurit donn. Comme les diffrents certificats qui sont incorpors dans cette membrane de confiance doivent faire preuve de leur capacit de cross certifier et dinteroprer avec les autres PSC, la BCA promeut en mme temps ladoption de standards travers la membrane. La BCA devient ainsi un garant de la cohrence des policies lintrieur de cet espace de scurit, un arbitre de confiance et un facilitateur conomique, sans pourtant tre une ROOT PSC. Cest elle qui ngocie avec les PSC et qui soccupe de tout le policy management et du mapping des certificats. Ainsi, il nest plus ncessaire pour les diffrentes communauts dentrer en arrangement bilatral de cross certification. Il suffit de faire un arrangement avec la BCA pour un ou plusieurs certificats. L o les certificate policies se recoupent, la BCA tablit un lien de confiance entre les diffrentes communauts. Elle permet aussi de relier deux ICP existantes de structures divergentes. Pour cela, il suffit de crer un lien entre le ROOT PSC du modle hirarchique avec la BCA et dautre part entre un PSC du systme mesh et la BCA. La BCA peut relier beaucoup d'ICP diffrentes en un
Page 54
seul point. De plus, sa structure dcentralise reprsente pour le moment au mieux le monde rel des relations organisationnelles. .
Bridge PSC
PSC
PSC
PSC
PSC
PSC
PSC
PSC
Figure 17 : Liaison de deux architectures diffrentes par un Bridge PSC Description du cadre luxembourgeois
Au sein de ce modle nous distinguons une entiti LUXEMBURGISH TRUST ORGANISATION Bridge Authority (LTOBA) qui est responsable de linteroprabilit des PSC secteurs. Au sein de la LTOBA on retrouve une Policy Authority, qui est compose de reprsentants des PSC faisant partie de la membrane. Cest elle, qui dtermine quels PSC peuvent participer la membrane et dcide des niveaux de cross certification. Ce dernier est tabli en valuant les Certificate Policies et les Certificate Practice Statement avec la CP et CPS de la LTOBA. Lobjectif de ce policy mapping est de sassurer de la scurit relative des certificats des divers PSC par rapport aux autres de faon ce quils puissent interoprer des niveaux de scurit pralablement tablis et mutuellement compris. Cest ce comit qui est en charge en quelque sorte de la gestion de la LTOBA.
Luxemburgish Trust Organisation Bridge Authority

Technical Agent
LTO PSC
Secteur 1
LTO PSC
Secteur 2
AE
AE
AE
AE
AE
AE
Figure 18 : Schma conceptuel du modle Bridge PSC Linfrastructure est base sur une infrastructure technique partage qui est gre par un partenaire externe et qui est audit rgulirement par la LTOBA. Ensuite, chaque secteur PSC peut tablir ses propres certificats bass sur linfrastructure partage et adapte aux caractristiques du march.
Page 55
Arrive dun autre PSC sur le march luxembourgeois
A part les mmes difficults que cites prcdemment, remarquons ici que si le nouveau PSC souhaite interoprer avec les PSC sur place, il lui suffit dentrer en ngociation avec la LTOBA pour se relier au systme existant. Cest alors la LTOBA qui soccupe du mapping de ses certificats par rapport aux PSC de la membrane de confiance. Liens et interoprabilit
Toute la tche est centralise au sein de lorgane suprieur, savoir la LTOBA. Cest elle qui soccupe de tout. Notons que les secteurs ne perdent pas tout le contrle, vu que leurs reprsentants sigent au conseil dadministration de la Bridge et participent la prise de dcision. Cette solution permet des extensions de confiance dune manire flexible tout en gardant le contrle en un point de confiance central. Il reprsente aussi un systme ouvert, caractristique qui a t cite comme essentielle pour le succs du modle luxembourgeois (cfr. Chapitre 1). Comme tous les prestataires de services de certification extrieurs ont un seul point de contact pour rgler les problmes dinteroprabilit, cela devrait bnficier linteroprabilit de tous les certificats faisant partie de la membrane avec les certificats extrieurs la membrane. Notons aussi que cette solution permet plus aisment dassocier au systme un PSC repris dans les browsers habituels et de relier les divers certificats au certificat de ce PSC. Ceci donnerait une plus value non ngligeable des certificats reconnus par la LTOBA et favoriserait leur utilisation grande chelle. Consquences pour lEtat
En tant quutilisateur, ce modle lui permet dutiliser son certificat selon les liens de confiance tablis lors du mapping dans dautres domaines. En tant que fournisseur dapplications, lEtat peut modliser son certificat selon ses propres besoins. Comme il sige au sein de la LTOBA, il intervient lors de la dcision de quels certificats sont accepts pour des applications auprs des administrations. De plus, cette fonction au sein de la LTOBA lui permet de garder une vue densemble de tout ce qui se passe en matire de certification et pourrait, en cas de dysfonctionnement, intervenir. Cest ce modle qui permet lEtat dassumer le plus efficacement le rle du facilitateur conomique. Consquences pour le citoyen
Le mapping permet au citoyen de connatre au pralable les relations de confiance entre les entits composant la membrane de confiance. Ainsi, en fonction de ses besoins, il peut opter pour les certificats les plus adapts. Cest aussi par le biais de ce modle quon favorise le plus une certaine concurrence entre les PSC, comme la LTOBA assure une certaine interoprabilit des certificats mis par les PSC du systme. Ainsi, la LTOBA procure au citoyen un double bnfice, savoir, dune part une certaine interoprabilit des certificats, ce qui devrait rduire le nombre de certificats ncessaires, et dautre part, une certaine concurrence entre les certificats et par-l contribuer un prix comptitif des certificats. Si, en plus, on russit associer un ROOT PSC reconnu par les browsers rpandus sur le march, le citoyen pourrait utiliser son certificat national dans des transactions internationales.
Page 56
1.7
Conclusions
Aprs avoir passer en revue les diffrents scenarii, quelques grandes tendances nous semblent se dgager pour un modle ICP au Luxembourg. Il parat invitable dopter pour un modle flexible, qui permet aux diffrents secteurs de modliser leur certificat en fonction de leurs besoins. Parmi les trois derniers modles prsents, il nous parat que cest celui tablissant une Bridge Authority qui est priori un modle adapt au contexte luxembourgeois. Ce modle vite les cross certifications multiples en centralisant la gestion des liens de confiance en point unique de confiance. Cet organe laisse cependant aux secteurs une certaine autonomie dans la dtermination de leurs policies et du contenu de leurs certificats. La LTOBA assure un niveau dhomognit des certificats portant le label LTO en ditant des normes et standards respecter. Ces rgles sont fixes en concertation avec les diffrents secteurs associs et non imposes par une instance suprieure. Cette manire dagir facilitera certainement lacceptation des normes dites et par l leur mise en uvre. La LTOBA devient aussi le garant dune certaine interoprabilit au sein du systme, ce qui nous parat essentiel pour le succs et lutilisation grande chelle de la certification. Ce modle reste cependant ouvert et permet des extensions des liens de confiance vers dautres PSC europens et internationaux.
Page 57
2. Considrations techniques lies l'interoprabilit

Les scenarii tels que prsents sont tous techniquement ralisables l'heure actuelle. Ils ont par contre des implications techniques assez diffrentes en ce qui concerne le chanage, la cross certification ou encore l'interoprabilit internationale. Il faut savoir qu'un utilisateur ou service peut seulement valider un certificat qui lui est prsent que s'il fait confiance l'metteur du certificat, c'est--dire le PSC ayant tabli le certificat. Cette relation de confiance peut comprendre plusieurs tapes intermdiaires. Il s'agit alors de relations de chanage hirarchique ou de cross certification. Dans ces cas on ne fait pas confiance l'metteur direct du certificat, mais plutt au PSC qui avait certifi le premier PSC. Pour plus de dtails sur le chanage, le lecteur pourra se rfrer l'annexe rappelant les aspects techniques des ICP. Les scenarii prsents impliquent presque tous des relations de confiance plusieurs niveaux. Techniquement il est tout fait possible de valider une telle chane, sous condition de connatre toutes les tapes entre le certificat et le PSC de confiance. Ces tapes ou chanes peuvent se retrouver deux endroits: au niveau des serveurs applicatifs authentifiant ses utilisateurs, ou au niveau des certificats dtenus par les citoyens. Dans tous les cas, cette configuration est assez statique. La consquence de la situation actuelle est que les scenarii sont effectivement ralisables, mais il est trs difficile de modifier les relations entre PSC de faon transparente pour les utilisateurs aprs leur dploiement. De plus, comme les dveloppements inter-europens futurs sont imprvisibles, il est assez improbable que la solution telle qu'elle sera choisie puisse tre raccorde sans le moindre problme une ventuelle structure europenne. Il faut cependant noter que les interoprabilits plus grande chelle se raliseront vraisemblablement travers de rpertoires et mta-rpertoires. Les avances dans ces domaines sont considrables et promettent de rsoudre la plupart des problmes d'interoprabilit. En rsumant, il faut souligner l'importance des choix relatifs l'infrastructure ds le dbut du projet, en particulier en ce qui concerne les relations entre PSC et entre PSC et RootPSC.
Page 58
3. Rflexions sur le rle de LuxTrust

3.1 Introduction
Dans cette partie, nous tudions le modle LuxTrust tel que propos dans le document du Cetrel intitul LuxTrust, Rapport managrial publi en juillet dernier et dont certains passages repris en italique sont cits dans les paragraphes qui suivent. Comme nous lavons indiqu dans la premire partie, ce modle constitue une alternative intressante pour le dploiement d'une ICP au Luxembourg. Il est cependant important de noter que les principes que nous dgageons ici ne sappliquent pas spcifiquement la relation entre le Gouvernement et le secteur financier mais sappliquent toute situation o lon dsire fixer des conditions de coopration au niveau dune structure ICP entre plusieurs secteurs ou, au niveau dun secteur, entre plusieurs sous-secteurs. Dans ce rapport sont identifis 4 acteurs : 1. LuxTrust : un trust center dfinissant et rendant disponible un certain nombre de services dvelopps autour dune infrastructure de certification confie au TTA. 2. TTA : le TrustCenter Technical Agent oprant lexploitation de linfrastructure de certification. 3. LuxTrustFS et LuxTustGov : les deux PSC associs aux domaines financiers et publics, dautres PSC pouvant tre imagins. 4. Les diffrents AE oprant dans les diffrents domaines. Les 2 avantages que lon peut immdiatement noter dans cette proposition sont : 1. lutilisation dune infrastructure commune permettant un partage des cots entre les diffrents domaines dsireux de mettre en place une ICP. Il faut tre conscient que la mise en place d'une ICP pour un grand nombre de certificats cote trs cher. Certaines tudes citent un ordre de grandeur de 200 mio Luf auxquels sajoutent des frais rcurrents de maintenance de lordre de 50 mio. Outre des cots purement lis linfrastructure matrielle et logicielle, il ne faut pas sous-estimer les cots de dveloppement et de maintenance des applications logicielles, les cots lis la scurisation particulire des installations et enfin les cots de formation des utilisateurs ncessaires pour vraiment apprhender les enjeux de la scurit en matire d'ICP. 2. la recherche dune solution commune plusieurs secteurs permettant dviter la prolifration de diffrentes infrastructures non ncessairement intgrables par manque dinteroprabilit. Ainsi, dans beaucoup de pays (comme par exemple aux USA), plusieurs ICP sont dj oprationnelles ou en cours doprationalisation au niveau de diffrents secteurs privs ainsi quau niveau de diffrentes administrations. Des tudes telles que celles du FPKISC aux USA indiquent clairement quil est trs difficile de rendre interoprables diffrentes infrastructures dj en place. Dans le modle propos, LuxTrust est propritaire de la solution technologique opre par le TTA. Son ambition est de permettre au secteur priv comme lEtat et au secteur public de disposer rapidement dune infrastructure de certification de signatures lectroniques, conforme aux exigences propres des futures autorits de certification prive(s) et publique(s), compatible avec les standards internationaux et assurant aux acteurs luxembourgeois la ncessaire indpendance vis--vis des fournisseurs trangers. Lobjet de cette partie est dapprofondir cette dfinition initiale de manire mettre en vidence certains lments cls devant tre considrs comme des pr requis sa ralisation. Ces diffrents lments seront dtaills dans les sections qui suivent. Ils concernent : les difficults techniques inhrentes au dploiement de composants ICP. limportance pour les administrations tant en interne quau niveau des relations avec lextrieur (citoyens et entreprises) de disposer dune infrastructure ICP unique permettant de couvrir les diffrents besoins identifis. En particulier, nous verrons en
Page 59
quoi un concept unique de carte didentit lectronique peut satisfaire lensemble des exigences tout en respectant galement le rglement Grand-Ducal en matire dutilisation de CQ (Certificat Qualifi). la ncessaire interoprabilit demande entre les diffrents domaines (actuellement LuxTrustFS et LuxTrustGov) o la signature lectronique est utilise. A ce niveau, il faut viter au maximum des procdures redondantes (plusieurs identifications) conduisant les citoyens et les entreprises devoir grer plusieurs certificats pour diffrents usages. Un certificat a un cot (couvrant les frais du AE et du PSC mission, gestion, rvocation, renouvellement -). Plus un citoyen/entreprise possde de types de certificats diffrents, plus le cot est lev sil ny a pas de masse critique atteinte au niveau de chacun des types. la problmatique du label LuxTrust. Mme si lensemble du Luxembourg (et/ou de la Grande Rgion) peut avoir confiance dans le label LuxTust, il faut encore convaincre le reste du monde de cette qualit. le rle devant tre jou par LuxTrust. LuxTrust repose sur un partenariat pouvant avoir des objectifs diffrents. Il convient ds lors que les partenaires autour de la table se mettent daccord au pralable sur les missions assumer en matire de scurit et de services offerts.
Au travers de ltude des diffrents lments, nous dgagerons un certain nombre dexigences qui pourraient tre prises en considration dans un futur appel propositions visant identifier un consortium susceptible de raliser le TTA avec succs. Pour rappel, dans son tude pralable, le CETREL a identifi 3 de ces consortiums afin de mener une exprimentation pilote en matire de-mail scuris dans le secteur financier. Notre rapport ne vise pas remettre en cause cette tude initiale. Cependant, pour la slection dune solution finale, nous pensons que des exigences supplmentaires devront tre prises en compte. Celles-ci sont dtailles dans les sections qui suivent.
Page 60
3.2
Le niveau technique : les composants ICP
Bien que l'ICP ait t invente il y a plus de vingt ans et sa commercialisation importante commence depuis plus de 10 ans, il est important de remarquer que ce march manque encore de maturit et que la plupart des produits dvelopps se placent plutt sur des marchs de niches. Beaucoup de ces produits ne rpondent ds lors pas des standards bien dfinis ou des exigences gnralisables. Beaucoup (trop ?) dorganismes de standardisation existent pour dfinir les services devant tre offerts par les composants dune ICP (services cryptographiques, smart card, gestion des cls et certificats, etc.). Quelques exemples dorganismes de standardisation sont : IETF PKIX, RSA PKCS, W3C, PKI Forum, OASIS, EESSI). Cependant, deux constatations sont importantes : 1. Les standards sont complexes et ne sont pas stables (nouvelles volutions pour XML, pour le mobile , etc.). En particulier, cest le cas, au niveau des signatures et des certificats qualifis. LEESSI actuellement publie les premiers standards techniques compatibles avec linterprtation de la directive europenne sur la signature lectronique. 2. La complexit des standards conduit des interprtations diffrentes et donc des implmentations diffrentes (par exemple au niveau des champs dun certificat). Il est noter quun des standards posant le moins de problme dincompatibilit est celui relatif au LDAP (annuaire), encore que le langage permettant dexprimer des query sur ces directory ne soit pas lui standardis. Mme si les standards taient stables et bien interprts, les API daccs (interfaces entre les applications et les composants matriels ICP) resteraient propritaires. L aussi, des efforts de standardisation sont en cours comme par exemple ceux autour de larchitecture CDSA et du groupe NIST PKI. Mais actuellement, cette date, ils nont pas dbouch sur des rsultats tangibles. 1. Si lon opte pour plusieurs vendeurs de composants ICP (Baltimore, Entrust, IBM, RSA, etc.), il faudra dvelopper systmatiquement plusieurs API dans un mme programme permettant daccder aux composants API (cfr les SDK : software development kits propritaires) 2. Il est noter aussi que la multiplicit des vendeurs entrane aussi une plus grande htrognit au niveau des services offerts par les diffrents composants ICP. Ainsi, lalgorithme de cryptographie utilis peut tre diffrent chez deux vendeurs. Eu gard cette situation, nous formulons deux recommandations importantes : Au niveau du TTA, il convient de reposer sur un seul dveloppement (fournisseur) technologique de composants ICP afin de pas tre confront des problmes dinteroprabilits techniques. Ce dveloppeur technologique devra faire preuve de ses efforts en matire de respect des standards et de son influence au niveau des organismes de standardisation. En particulier, il faudra veiller ce que les solutions proposes soient en conformit avec les standards de lEESSI au niveau europen ainsi qu'avec ceux de l'IETF au niveau international. Les diffrents composants ICP sont utiliss : 1. dans les applications clientes en vue daccder aux services centraux offerts par les AE et PSC 2. dans les applications utilises par les AE lorsquils communiquent avec le PSC. Les services offerts par les composants ICP tant encore dun niveau assez lmentaire, il reste donc encore beaucoup de travail pour le dveloppement des applications, en particulier au niveau des applications clients. Le travail serait facilit par lutilisation dun middleware packageant les diffrents services de base afin doffrir des interfaces de plus haut niveau et moins complexes permettant de dvelopper plus rapidement de nouvelles applications.
Page 61
Afin dacclrer le dveloppement dapplications clients existantes ou nouvelles nous recommandons Au niveau du TTA, il convient dassocier aux composants ICP, un fournisseur de middleware offrant des services de plus haut niveau permettant une intgration plus facile au niveau des applications, tout en respectant les standards en vigeur. Lutilisation dun middleware, s'il est suffisamment ouvert, permet aussi dassurer une plus grande indpendance des applications lors de changements techniques au niveau ICP (tokens, cryptography, directories, etc.).
Page 62
3.3
LuxTrustGov : lutilisation gnralise dune signature qualifie
La confiance dans un systme de cl lectronique est lie essentiellement au certificat mis par le PSC qui accompagne cette cl. Le certificat contient diffrentes informations (validit du certificat, identit du PSC qui la mis, etc.). En outre le certificat a trois grandes fonctions : 1. lidentification (mme si cest au moyen dun pseudonyme) de celui qui le dtient 2. la demande dautorisation accder diffrentes ressources (et cela indpendamment dune identification) 3. lindication dattributs/qualits (informations) spcifiques de son porteur. A lintrieur dun domaine comme celui de lEtat (entre administrations ou dune administration vers lextrieur) , on peut tre amen interagir dans le cadre de diffrents contextes et de diffrentes applications. Diffrentes solutions sont ds lors possibles : 1. un seul certificat avec tous les attributs. Cela pose les problmes suivants : privacit des attributs : toutes les applications ont potentiellement accs toutes les informations contenues sur le certificat alors que certaines exigent un accs plus restreint (accs des infos sur la sant par exemple). les cycles de rvocation des attributs ne sont pas lis. Ds lors quun attribut doit tre rvoqu, on doit alors rvoquer lentiret du certificat et en r-mettre un nouveau avec les attributs encore valides. 2. un certificat par type dapplication avec uniquement les attributs spcifiques ncessaires chaque application. Problmes poss : plusieurs certificats grer par lutilisateur. Suivant le contexte, il doit choisir la bonne cl et le bon certificat do une plus grande complexit dutilisation. redondance (et donc discordances possibles) de plusieurs informations (par exemple au niveau de lidentification). processus de rvocations multiples (par exemple, si lutilisateur a perdu toutes ses cartes). 3. utilisation des certificats de qualification (attribute certificate) en complment du certificat court didentification. Par analogie, dans cette approche, le certificat didentification est considr comme un passeport et le certificat de qualit comme un visa permettant daccder une ressource/application particulire. Problmes poss : Le travail de standardisation est en cours. Les certificats de qualit ne sont pas encore utilisables dans tous les systmes de-mails et de Web browsers. Lutilisateur doit toujours utiliser deux certificats : le certificat didentit et un certificat de qualit. 4. utilisation dune PMI (Privilge Management Infrastructure) en complment dun certification didentification. Il sagit dune directory de certificats enrichie dinformations relatives aux attributs/qualits spcifiques. Lutilisation dune PMI permet : de donner un utilisateur sur base de son certificat des autorisations daccs diffrentes applications/ressources. Ces autorisations peuvent tre accordes spcifiquement la personne, son rle au sein dun groupe ou du fait de son appartenance au sein dun groupe. La PMI permet galement de grer les dlgations. de faire des queries sur la directory afin de retrouver des qualits spcifiques de lutilisateur (par exemple, la solvabilit) ou des valeurs de ces qualits. Lensemble de ces recherches tant nouveau scuris (accs restreints via ICP) et les rponses signes. La PMI peut galement tre dcentralise en terme dorganisation (management) et aussi au niveau physique (dcentralisation des bases de donnes) de manire assurer la confidentialit de certaines informations dans les sous-domaines corrects (sgrgation des diffrents sous-domaines).
Page 63
Notre conclusion est donc dutiliser un certificat restreint lidentification de son porteur associ un systme de PMI au niveau de LuxTrustGov Au niveau du TTA, on veillera sassocier un partenaire possdant une exprience dans la mise en place de solutions de type Privilge Management Infrastructure et s'engageant respecter les standards mergeants. Au niveau de cette identification, pour le citoyen, nous proposons que ce certificat qualifi se trouve associ la carte didentit afin de crer une carte didentit lectronique. Plusieurs tudes indiquent en effet quune smart card seule est plus souvent perdue par son utilisateur que lorsquelle nest pas associe un autre document jug important. Au niveau du TTA, on veillera sassocier un partenaire possdant une exprience lie aux technologies en matire de smart card, en particulier dans celles utilises en conformit avec les recommandations de lEESSI. Une question restera tre tranche, savoir lutilisation ou pas dun pseudonyme pour lidentification. Quelques rflexions : Le pseudonyme figure au dos dune carte didentit qui elle nest pas anonyme. Doit-on systmatiquement sidentifier dans toutes les situations ou bien parfois ne cherche-t-on pas juste avoir une autorisation? Plus lidentit de quelquun circule sur Internet, plus des problmes de confidentialit et de privacit peuvent se poser. Lors de la signature d'e-mails ou lors de transactions de e-commerce, il peut tre souhaitable de pouvoir certifier son identit. Une dernire considration est plus pragmatique mais est nanmoins fondamentale pour faciliter la vie du grand public. Pour le citoyen, il est important que le certificat dlivr par son administration soit reconnu par son browser et e-mail. Reconnu signifie que le PSC ayant dlivr le certificat figure dans la liste des PSC reconnus par ces logiciels. Si cela nest pas le cas, le citoyen devra dabord installer le certificat de base de son PSC dans la liste des PSC reconnus, ce qui complique encore la vie de lutilisateur et donc risque de freiner la pntration de la signature lectronique ! Afin dviter ce problme, il convient donc que le certificat dlivr par GovTrust soit chan un des certificats root identifis par ces logiciels. Au niveau du TTA, on sassurera de la participation dune socit ayant une exprience de PSC et dlivrant ces certificats root au niveau des browsers/email. Celle-ci devra accepter ainsi de produire des certificats GovTrust chans vers son certificat root. En plus lexprience de PSC devra tre utilise pour mettre en place et assurer lintgration de la solution.
Page 64
3.4
Linteroprabilit entre des diffrents domaines et PSC
Pour des raisons dindpendance et de stratgies spcifiques, il parat appropri que diffrents PSC existent dans LuxTrust. Ainsi, actuellement, on prvoit un PSC au niveau LuxTrustFS et un au niveau de LuxTrustGov. Cependant, la question dinteroprabilit se pose nouveau, savoir dans quelle mesure les certificats mis par un des PSC sont reconnus par lautre. Un des rles de LuxTrust est ds lors nouveau dassurer cette introprabilit. Les modles connus sont les modles hirarchiques, de cross-certification et de Bridge CA. Le modle hirarchique a priori nest pas intressant. Dune part, on ne voit pas la plus value associe au chanage systmatique une certificat root LuxTrust. Dautre part, il ny a pas de ncessit dune reconnaissance systmatique de tous les certificats par tous les PSC. Par exemple, sil est envisageable que les certificats mis par LuxTrustGov soient reconnus par LuxTrustFS, linverse nest pas ncessairement dsir Le modle Bridge PSC est utilis principalement dans une approche de fdration bottom-up (fdration de systmes legacy existants voir lexemple du FBCA aux USA). Or, dans notre cas, nous sommes dans une construction top-down (sans legacy). Cependant, les rgles visant pouvoir uniformiser et comparer les policies sont applicables dans notre situation. Le modle cross-certification est le plus facile mettre en uvre, surtout parce quon utilise une technologie unique garantissant des certificats interoprables. Il implique que LuxTrust sinvestisse dans la mise en uvre de cette forme dinteroprabilit, le plus simple tant encore dutiliser le mcanisme de Certificate Trust Lists (liste de PSC identifis par leurs certificats et signs par le PSC en qui on a confiance). Dans ce modle envisag, chaque PSC a ses propres CP (Certificate Policy) et CPS (Certification Practices Statement). Avant de permettre, une cross-certification, LuxTrust devra bien sr comparer ces policies afin de vrifier quelles sont bien de qualits gales. En termes pragmatiques, les diffrents PSC peuvent tre localiss dans la mme installation (btiment scuris). Ces PSC apparaissent comme des subordonns accrdits du root PSC. Ces PSC peuvent nanmoins exister dans diffrentes hirarchies en dehors de LuxTrust (ils ont leur indpendance ce niveau), mais au moins au niveau informatique, les IT managers peuvent facilement vrifier les certificats cross-certifis. Le root PSC est trs scuris et reste gnralement off-line. Il est uniquement utilis afin de crer les certificats de base des subordonns et les certificats de cross-certification. Le Root PSC doit oprer un haut niveau dassurance et de qualit. Pour assurer techniquement cette interoprabilit, LuxTrust pourra tre amen dfinir des services appropris fournir par le TTA. Au niveau du TTA, linfrastructure devra offrir des services garantissant linteroprabilit entre diffrents PSC de LuxTrust. Des exemples de ces services sont la gestion dcentralise des Certificates lists et des CRL Distribution points et la gestion de meta-directory, permettant la propagation entre diffrentes directory. Comme on le voit, le rle de LuxTrust est ici assez similaire celui de lABA au niveau des banques amricaines sauf quil garantit en plus lintroprabilit entre plusieurs PSC.
Page 65
3.5
LuxTrust et le reste du monde
En matire d'ICP, au niveau mondial, la situation est parfois rsume par certains auteurs comme celle de fragmented islands of trusts , c--d de certificats nayant quune reconnaissance dans un monde relativement ferm (pays ou communaut dintrt). Bien sr les modles voqus ci-dessus (modles hirarchiques, bridge PSC et crosscertification) permettent de construire des ponts entre ces communauts (PSC). Mais cependant, mme si cela est techniquement faisable (ce qui est loin dtre toujours le cas !), la ralit est plus complexe ds lors quil faut aussi juger de la qualit dun PSC, cest--dire pouvoir juger du srieux de ses procdures, non seulement au niveau de leurs dfinitions (CP et CPS) mais aussi de leffectivit de leur suivi (au moyen daudit). Aussi, le srieux dun PSC se juge au niveau des assurances quil peut offrir en termes de la disponibilit des services (24h, 7 jours), leurs performances ainsi que la scurit (physique, matriel et logiciel) de son infrastructure. Cette liability dun PSC peut ainsi se trouver matrialise au niveau dune forte assurance contracte afin de ddommager ses clients en cas de dfaillances. Il y a ici une question importante se poser par LuxTrust concernant ces aspects. Dsire-t-il ds le dbut associer un label de haute qualit ses certificats mis ? Si la rponse est oui, il conviendra : 1. soit au niveau de chaque PSC, dengager des initiatives permettant la reconnaissance des certificats mis. Ainsi au niveau bancaire, il faudra tudier les conditions permettant le certificat LuxTrustFS dtre reconnu au niveau dinitiatives telles que Identrust, ABA (initiatives amricaines) et GTA (initiative europenne). Au niveau du domaine public, ce stade, il ny a pas encore de relle initiative en matire de reconnaissance europenne croise des cartes didentit lectroniques (le rle de laccrditation tant trs important ce niveau). Il est noter quau niveau des socits, une initiative au niveau des Chambres de Commerce est en cours. 2. soit globalement au niveau LuxTrust, dassurer un branding. Celui-ci peut soit se dfinir progressivement ou soit tre import par linclusion dun PSC reconnu au sein du consortium. Au niveau du TTA, si LuxTrust dsire avoir une reconnaissance rapide dun branding pour ses certificats, il est important dinclure un partenariat stratgique avec un PSC offrant des garanties fortes au niveau de ses CP et CPS.
Page 66
3.6
Les finalits de LuxTrust
En bref, on peut rsumer les missions de LuxTrust comme tant les suivantes : Dfinir et garantir le fonctionnement dune infrastructure ICP partage offrant des services utiliss dune part au niveau des applicatifs et dautre part au niveau des PSC et AE. Dvelopper une solution introprable base sur lmission de certificats qualifis servant essentiellement assurer lidentification de leur porteur. Linteroprabilit est la fois interne (entre PSC de LuxTrust) et externe (autres CA) en assurant un branding Luxtrust associ la qualit des services associs. Comme nous lavons indiqu, le branding repose largement sur la fiabilit et la scurit des services offerts, cette fiabilit sera couverte par une assurance adquate mais rsultera aussi de la mise en place et de laudit des best practices recommandes par des organismes tels que : BS7799 (ou ISO 17799), application particulire au niveau ICP and Policy Framework (X9.79) RFC 2527 (plus spcifique aux CPS) Common Criteria (NIST) - (Evaluation Assurance Levels) PD 5000 COBIT A ce stade, le niveau de confiance pourrait encore tre renforc par le rglement daccrditation Grand-Ducal qui donnerait encore davantage de poids aux mesures de qualit mises en place par LuxTrust. (voir lexemple du tScheme UK). Une autre partie du branding provient galement de la richesse des services proposs. A ct de services relativement standards mais non toujours effectivement implments tels que : La consultation en ligne de ltat des certificats (OCSP) Le time-stamping Dtection automatique de cls venant chance, gnration des nouveaux certificats Key backup and services de recovery. Archivage permettant de garder lhistoire des cls dencryption et des certificats aprs leur expiration. Attention, ce dernier service ne sapplique quaux cls dencryption (les cls servant la signature ne pouvant tre par dfinition archives) Dans sa stratgie, LuxTrust pourrait aussi prfrer dvelopper des services plus hautes valeurs ajoutes comme par exemple : services de transaction e-business ( linstar de ceux spcifis au niveau ebXML), le service de recommand lectronique ntant quun service lmentaire ce niveau. services de roaming pour les mobile users. etc. Afin de pouvoir passer rapidement ltude et au dploiement de ces services, notre recommandation serait dintroduire au niveau du TTA un partenaire offrant dj lensemble de ces services lmentaires ou prt les rpliquer sur le territoire luxembourgeois. LuxTrust pourrait ainsi plus utilement se pencher sur les services valeur ajoute.
Chapitre IV Recommandations
Page 67
Chapitre IV. Recommandations

1. Une approche globale pour les besoins de l'Etat
Pour rpondre ses besoins propres l'Etat doit maintenant dcider de la dmarche de mise en uvre d'une ICP. Nous avons expliqu les avantages d'une dmarche concerte avec le secteur priv. Il faut nanmoins rester raliste sur le temps ncessaire tablir un partenariat concret entre les diffrentes parties. Ce temps pourrait tre considr par certains comme un frein au dploiement de la signature lectronique voire inutile. Nous pensons que c'est aujourd'hui qu'il faut tudier et dcider des cooprations possibles. Agir dans la prcipitation hypothquerait selon nous le succs des applications e-government. Le travail de ngociations ne doit cependant pas bloquer le dveloppement de la signature lectronique au sein de l'Etat. Nous recommandons donc sur ce point de constituer rapidement une quipe oprationnelle capable de concrtement discuter les modles de partenariat possibles. Ds lors que le choix de l'ICP et de l'organisation associe seront raliss, l'Etat devra dfinir la dmarche des projets mettant en uvre des applications utilisatrices d'ICP. Nous recommandons que cette dmarche s'articule autour de deux objectifs principaux. Il s'agit tout d'abord de grer le risque des projets concerns pour garantir l'atteinte des rsultats et ensuite de dmontrer, de valider et de diffuser l'intrt de la signature lectronique dans les relations du citoyen et des entreprises avec l'Etat et d'une manire plus large dans la vie de tous les jours. Pour atteindre ces rsultats, il faudra choisir quelques projets parmi l'ensemble des applications susceptibles d'utiliser la signature lectronique. Ce choix devra se faire en fonction de critres objectifs et pertinents tels le nombre d'utilisateurs concerns, la maturit du secteur concern, le nombre de transactions annuelles, le retour sur investissement pour l'administration, la visibilit pour le grand public, la motivation des acteurs concerns, limpact organisationnel, Ensuite, nous recommandons d'assurer la gestion de ces projets de manire unifie afin d'anticiper les problmes propres que chacun rencontrera dans la mise en uvre des applications ICP. Dans le mme ordre d'ides, il est primordial d'assurer une communication globale de qualit avec le niveau d'information adapt aux diffrents publics. Enfin, nous pensons qu'il est indispensable de disposer d'un observatoire juridique, technique et organisationnel sur l'volution de la signature lectronique afin d'informer et de conseiller les dcideurs et les projets de choix stratgiques en la matire.
Page 68
2. Partenariats Publics-Privs dans la mise en uvre d'une ICP

Dans le chapitre 3.3 de ce rapport, nous avons identifi un certain nombre dlments devant tre pris en considration pour pouvoir mettre en place au Luxembourg une solution PKI unique pouvant tre partage tant par le secteur public que par diffrents autres acteurs du secteur priv. Ces lments sont relatifs : une utilisation facilite de la signature et du certificat associ. A cet effet, nous proposons lintroduction dun seul certificat unique inscrit sur une carte didentit lectronique. Ce certificat devrait tre limit un nombre dinformations minimum (contenant en particulier lidentification de son porteur au moyen dun nom ou dun pseudonyme). Cette signature pourrait tre utilise diffrentes fins dans le secteur public mais dans un certain nombre de relations au niveau du secteur priv. une implmentation efficace tant au niveau des applications logicielles quau niveau des services devant tre offerts au niveau de linfrastructure technique.
au degr de reconnaissance de la solution ICP dsire hors Luxembourg. A ce niveau, les lments essentiels sont associs au respect des standards mais aussi au niveau de branding que lon veut associer.
La dcision de la mise en place dune ICP inter-sectorielle est bien entendu lie un partage des cots. Dans ce qui suit, nous allons dabord prsenter les cots lis lintroduction dune carte didentit lectronique gnralise. Ensuite, nous discuterons de linfluence dun partenariat au niveau de ces cots. Elments de cots et options possibles pour le secteur public Ces lments sont tablis sur base dune solution adapte aux besoins du gouvernement mettant une carte didentit lectronique pour tous les luxembourgeois (calcul sur une base de 300.000 cartes). Ces donnes ne sont quindicatives et sont bases sur diffrentes informations reues de diffrents vendeurs ainsi que certaines sources (projet TIE, document Service Costs and Applicability ). Poste 1 : Infrastructure de base Cette infrastructure de base inclut un bunker scuris ainsi que le hardware ncessaire (serveurs, rseau, etc.) ainsi que les logiciels de base. o Option 1 : lensemble est dveloppe sur le sol luxembourgeois. Cot du bunker : entre 500.000 et 1.000.000 EUR Infrastructure IT : entre 250.000 et 750.000 EUR Les diffrences de cot dpendent du niveau de scurit dsir. Il faut bien entendu prvoir un cot de maintenance pour ces diffrents lments. o Option 2 : Hbergement auprs dun Data Center Cot initial : de lordre de 140.000 EUR Cot rcurrent annuel de lordre de 70.000 EUR Poste 2 : Infrastructure de PSC et de AE. Lhypothse que nous avons suivie est quil y a de nombreuses autorits denregistrement (niveau commune). o Option 1 : Lensemble est opr par un oprateur propre mettre en place Cot de linfrastructure ICP : de 450.000 1.000.000 EUR Cot opratoire : entre 400.000 et 1.000.000 EUR Le cot opratoire reste fixe dans le temps, une maintenance est prvoir au niveau du cot de linfrastructure. o Option 2 : Lensemble est sous-trait un fournisseur de service extrieur Cot annuel : entre 450.000 et 1.500.000 EUR (cela dpend du degr de reconnaissance du fournisseur ainsi que de la qualit des assurances associes aux services fournis)
Page 69
Poste 3 : Mise en place et intgration Ce poste reprend les frais lis ltablissement des procdures (CP,CPS) et leur mise en place. Le cot dpend du fait que les procdures sont vraiment nouvelles ou se rapprochent de solutions existantes. Cot : entre 200.000 et 1.000.000 EUR Poste 4 : Mise en place dune carte didentit lectronique o Cot de la smart card : entre 3.300.000 et 6.600.000 EUR o Cot des certificats : entre 500.000 et 1.200.000 EUR La dure de vie dun certificat peut tre estime trois ans maximum. On peut ajouter un cot supplmentaire si il y une association un certificat root reconnu o Cot du root certificate : partir de 110.000 EUR Ce cot peut naturellement tre beaucoup plus lev en fonction de la reconnaissance de ce certificat root. Poste 5 : Assurance (liability) o Cot : de 110.000 EUR 8.000.000 EUR ( !) Ce cot est tout fait dpendant du niveau de liability et de branding que lon veut associer au certificat LuxTrust. Poste 6 : Logiciels applicatifs. Ce poste couvre deux aspects : o Les toolkit et middleware permettant une implmentation plus rapide au niveau des applicatifs. Le cot dpend du niveau de services offerts. Cot : de 100.000 500.000 EUR o Une infrastructure de type PMI (Privilge Management Infrastructure) permettant lutilisation dun certificat unique dans diffrentes circonstances Cot : 1.000.000 EUR
A cela, il faut encore ajouter le cot difficilement chiffrable li au dveloppement/maintenance des logiciels applicatifs, des audits, de la formation du personnel et de linformation gnrale. De manire globale, on peut donc estimer : 1. une solution complte se trouvant dans un bunker scuris sous la responsabilit dun oprateur luxembourgeois un cot moyen de 9.500.000 1.100.000 EUR. 2. une solution complte outsource ltranger un oprateur utilisant son propre hosting un cot moyen de 8.000.000 9.500.000 EUR Une solution intermdiaire peut galement tre doutsourcer dabord la solution puis de la rapatrier ensuite lorsquune certaine masse critique de certificats est atteinte. Il y a alors bien sr dans ce cas un cot de migration quil faudra prvoir. Il est galement possible de mettre en place ce type dinfrastructure sur plusieurs annes. Les conomies ne sont pas cependant linaires car certains des lments de la solution sont relativement indpendant du nombre de certificats effectivement dlivrs. Il faut savoir quun cot de lordre de 6.000.000 EUR est directement proportionnel au nombre de smart card et certificats dlivrs (entre 0 et 300.000). Le niveau du cot est toujours proportionnel au niveau de branding que lon veut associer aux certificats distribus. Ce niveau de branding est toujours directement dpendant du niveau de scurit (physique, matriel, logiciel) associ la solution ainsi quau niveau de la liability garantissant la qualit et la correction des services offerts. Cet aspect de branding est particulirement important si lon dsire vendre des certificats ltranger, comme cela peut tre lobjectif de certains partenaires du secteur priv associ.
Intrt conomique dune solution commune plusieurs secteurs Les postes de cots suivants relatifs linfrastructure de base (Poste 1) peuvent tre supports conjointement. Le montant total sera cependant lgrement plus lev en fonction du nombre de certificats supplmentaires que les autres secteurs associs se proposent
Page 70
dmettre. A ce niveau, il conviendra que ces secteurs tablissent des business plans prcis permettant dtablir un tel chiffrage. Pour les postes 2 (infrastructures de PSC et dAE), 5 (assurances) et logiciels applicatifs (6), certaines conomies dchelles pourront tre ralises du fait dune infrastructure et de logiciels fournis par un fournisseur commun. Comme nous lavons indiqu ci-dessus, laspect branding pouvant avoir un cot important, il faudra que le Gouvernement et les secteurs associs dfinissent le niveau de branding souhait. Pour le poste 4 (Certificats et carte didentit), du fait du principe dinteroprabilit recommand dans cette solution, les certificats mis par le Gouvernement seront exploitables par dautres secteurs. A nouveau des conomies dchelle seront galement applicables aux certificats mis par le Gouvernement du fait de lutilisation de technologies communes.
3. Quelques suivantes
considrations
quant
aux
tapes
Au-del des considrations quant une coopration entre le gouvernement et dautres secteurs, un certain nombre dtapes doivent tre maintenant ralises quant la mise en place dune ICP. Pour la ralisation de certaines de ces tapes, il pourrait tre utile dobtenir une assistance extrieure dune socit ayant une forte exprience dans les aspects organisationnels et juridiques lis au dploiement dune ICP. 1. Dfinition du scope de la solution ICP et collecte des exigences dtailles en matire dapplications faisant appel aux services dune signature lectronique. 2. Analyse des exigences et conception du Trust Center devant oprer l'ICP ainsi que conception du cadre juridique. Cette analyse doit permettre didentifier : a. Les services devant tre fournis par linfrastructure ICP ainsi que son architecture et son niveau de support souhait. Ces lments seront la base de llaboration dun cahier des charges permettant lvaluation technologique des solutions proposes. b. La spcification des conditions de dploiement dune solution ICP au sein dune organisation. Ces spcifications incluront les lments relatifs la scurit du rseau et des applications ainsi que les descriptions relatives aux policies (CP, CPS) mettre en place dans lorganisation.
Annexes
Page 71
ANNEXES Annexe I : Rappels techniques Annexe II : Rfrences Annexe III: Glossaire
Annexes
Page 72
Annexes
Page 73
1. Rappels techniques
Cette partie du rapport rappelle les concepts techniques la base de toute ICP. Le lecteur retrouvera les services offerts par la cryptographie dans le contexte ICP, les techniques cryptographiques de base ainsi que les lments indispensables la mise en place de toute ICP.
1.1
Besoins de scurit de la communication lectronique
Afin de rendre les communications lectroniques fiables et dignes de confiance, la cryptographie peut offrir quatre services: L'authentification des acteurs permet aux personnes voulant communiquer d'tre sres de l'identit des parties participant la communication. L'intgrit des donnes est assure de sorte que toute manipulation ou erreur lors de la transmission puisse tre dtect de manire fiable. La confidentialit des messages fait en sorte qu'un message puisse seulement tre lu par son destinataire, mais pas par d'ventuels messagers. La non-rpudiation empche l'metteur de nier l'envoi d'un message et de rcuser son contenu.
Tous ces services sont fournis par l'utilisation conjointe de diffrentes techniques cryptographiques. Afin d'expliquer les oprations ncessaires nous prsenterons rapidement les techniques cryptographiques lmentaires.
1.2
Algorithmes cryptographiques
Depuis l'antiquit, le but de la cryptographie tait avant tout de transmettre des messages confidentiels alors que l'metteur ne pouvait faire confiance aux voies de transmissions. Le message tait donc transform de sorte ce que le messager ne puisse comprendre le message. A l'arrive, le destinataire appliquait la transformation inverse et rcuprait l'information transmise. Ces transformations sont les oprations de base de la cryptographie et s'appellent le chiffrement (angl.: encryption) et le dchiffrement (ou encore: codage/dcodage, cryptage/dcryptage). Les oprations ncessaires aux transformations sont dcrites par l'algorithme de cryptage. Initialement l'algorithme tait le secret qui servait chiffrer et dchiffrer les messages. Ainsi par exemple parmi les premiers chiffrages connus nous comptons celui de Csar qui consistait dcaler les lettres de l'alphabet par un nombre de positions fixes (A->D, B->E, etc.). De nos jours les algorithmes couramment utiliss et reconnus comme fiables ne sont pas secrets dans leur fonctionnement mais plutt bien documents et analyss. Le secret qui garantit alors la confidentialit d'un message chiffr est une chane de caractres nondivulgue appele la cl. Les algorithmes ne sont plus bass sur une substitution ou une transposition des caractres mais sur une suite plus ou moins complexe d'oprations logiques et/ou mathmatiques. Ces algorithmes appartiennent deux grandes familles d'algorithmes, les algorithmes cl secrte et les algorithmes cl publique.
Annexes
Page 74
1.2.1
Algorithmes cl secrte
Les algorithmes cl secrte ou encore cl partage sont des algorithmes dits symtriques. En fait les oprations de chiffrement et de dchiffrement se servent de la mme cl. Cette cl est aussi le seul lment protgeant la confidentialit d'un message chiffr, elle doit donc rester rigoureusement secrte et doit seulement tre connue aux deux parties qui communiquent. Lors d'une communication via un chemin non-scuris (p.ex. Internet) la cl secrte doit donc tre transmise pralablement par une voie scurise digne de confiance. Le service que les algorithmes symtriques peuvent offrir est la confidentialit des communications. L'authentification est possible entre les deux parties. La non-rpudiation est cependant impossible parce que les deux parties peuvent indpendamment crer le mme message. Ainsi l'metteur pourrait nier avoir envoy un message aprs envoi, et le rcepteur ne dispose d'aucun moyen pour prouver le mensonge.
1.2.2
Algorithmes cl publique
Les algorithmes cl publique sont des algorithmes dits asymtriques. Les oprations de chiffrement et de dchiffrement n'utilisent pas la mme cl, mais seulement un lment d'une paire de cl. Lors de la cration de la cl servant de base un algorithme de cl publique, une paire de deux cls usages complmentaires est gnre: une premire cl dite prive et une seconde dite publique. L'ide inhrente ce procd est que la cl prive reste sous le contrle exclusif de son titulaire et reste strictement confidentielle. La cl publique par contre sera librement diffuse et ne constitue nullement un secret. Par ailleurs, mme si les cls prive et publique sont mathmatiquement lies, il est impossible de dduire la partie prive de la partie publique dans un laps de temps raisonnable. La complmentarit des cls s'exprime lors des oprations de chiffrement et dchiffrement. Ainsi un message chiffr avec une cl publique sera dchiffr par la cl prive correspondante et vis versa. Afin de communiquer, deux parties ont chacune besoin d'une paire de cls. Le chiffrement d'un message se fait alors avec la cl publique du destinataire. Le destinataire dchiffrera le message avec sa cl prive. Avant de pouvoir chiffrer la communication il faut videmment avoir transmis la cl publique. Comme celle-ci peut tre divulgue sans mettre en cause la confidentialit des donnes chiffres avec elle, la transmission peut se faire par un chemin non-scuris. Les algorithmes cl publique offrent donc la confidentialit mais aussi la non-rpuditation et par la mme l'authentification. Ainsi l'metteur peut galement chiffrer son message avec sa cl prive. Le rsultat en est un message que toutes les personnes possdant la cl publique correspondante peuvent dchiffrer. Ainsi ils vrifient que l'metteur est la personne dtenant la cl prive et comme celle-ci est uniquement connue par son propritaire l'authenticit du message est garantie. Pour la mme raison l'metteur ne peut nier tre l'origine du message. 1.2.3 Quel type d'algorithme est choisi?
Le choix du type d'algorithme, symtrique ou asymtrique, dpend essentiellement du contexte. Ainsi parmi les avantages des algorithmes cl secrte on compte leur rapidit (jusqu' un facteur 1000 plus rapide qu'un algorithme cl publique de fiabilit comparable). L'inconvnient principal est la gestion des cls: il faut une cl secrte par paire de personnes voulant communiquer entre elles, et les cls doivent tre changes par voie scurise. Mais malgr son handicap au niveau des performances, les algorithmes cl publiques prsentent un avantage incontestable parce qu'il suffit d'avoir une paire de cls par personne voulant communiquer, et de plus il ne faut pas disposer de voie scurise avant la communication.
Annexes
Page 75
Ainsi, en pratique, on essaie de combiner le meilleur des deux mondes. La plupart du temps les algorithmes cl publique sont utiliss pour l'authentification et la transmission d'une cl secrte gnre alatoirement pour les besoins de la communication. Il suffit ainsi d'encrypter qu'un petit message contenant une cl secrte avec l'algorithme peu performant. Ensuite cette cl secrte servira pour la suite de la communication et permettra ainsi de fonctionner avec un algorithme symtrique plus performant.
1.2.4
Les fonctions de hachage scuris
Un type particulier d'algorithme utilis intensment dans les communications scurises sont les fonctions de hachage scurises (angl.: secure hash functions). Ces fonctions prennent en entre un message quelconque et en calculent un digest, c'est--dire une suite de caractres (couramment de 128 160 caractres). Les fonctions sont construites de sorte que pour un digest donn il est trs difficile de construire un autre message qui lui correspondrait. Ainsi un digest sert en tout premier lieu vrifier l'intgrit d'un message. Un message modifi lors de sa transmission, et ne serait-ce que d'un caractre, produira un digest entirement diffrent. De mme, si une personne malintentionne voudrait changer le contenu d'un message, elle sera incapable de le modifier de sorte ce que le digest reste le mme. En pratique, le digest est galement la base des signatures lectroniques. Ainsi l'metteur d'un message ne chiffre pas l'intgralit du message avec sa cl prive (cf. ci-dessus) mais calcule plutt un digest et chiffre ce dernier (toujours avec sa cl prive). Cryptographiquement cette opration est suffisante pour garantir l'authenticit du message, son intgralit et la non-rpuditation, et satisfait ainsi aux besoins d'une signature lectronique.
1.3
Infrastructure Cls Publiques
Si les techniques et algorithmes cits ci-dessus permettent de rpondre techniquement aux besoins d'une communication fiable, une utilisation grande chelle de manire transparente et facile ncessite des lments d'infrastructure supplmentaires. Ces lments sont regroups sous le terme d'infrastructure cls publiques.
1.3.1
Les certificats
Nous avons vu que techniquement les algorithmes cl publique peuvent rpondre aux besoins d'une communication scurise. Par contre ce qui manque toujours est un moyen d'authentifier et d'identifier une cl publique, c'est--dire pouvoir la mettre en relation avec une personne ou un service sans ambigut et avec certitude. Les certificats rsoudent ce problme. Un certificat est en fait une cl publique jointe une identit et authentifie par une autorit de certification. Afin d'exprimer cette authentification, l'autorit de certification (CA, certification authority, ou encore PSC) signe les donnes cl publique et identit lectroniquement. Evidemment se pose maintenant la question de comment faire confiance cette signature qui n'est encore et toujours qu'une longue suite de caractres. La validit de la signature peut tre contrle avec la cl publique du PSC, mais qui garantit l'authenticit de cette cl ? Afin de remdier partiellement ce dilemme, les PSC s'auto-authentifient en signant eux-mmes leur propre cl publique. Maintenant, la confiance se base sur un certificat du PSC autosign. Comme on ne peut plus se rfrer une autre autorit pour valider l'exactitude de ce certificat, ce dernier est inclus par les PSC importants directement dans les applications (p.ex. browsers et clients mail) les plus courantes. En rsum la confiance accorde un certificat
Annexes
Page 76
donne est galement celle accorde un constructeur de browser et aux chemins de distribution de ce dernier.
1.3.2
La chane de certification
Le paragraphe prcdent introduit la notion de certificat ainsi que la vrification de ce dernier. Le point important est qu'il faut toujours faire confiance d'une manire ou une autre une autorit de certification qui prsente un certificat auto-sign. Souvent nous appelons un tel PSC aussi Root-PSC (ou encore Root-CA), parce qu'il est la racine de toute relation de confiance. A partir de ce certificat, il existe plusieurs faons d'arriver un certificat utilisateur. Dans l'approche la plus simple, telle que dcrite ci-dessus, le PSC signe simplement la cl publique de l'utilisateur et lui tablit ainsi son certificat. Afin de structurer l'tablissement de certificats, de le rendre matrisable et nuanc, les relations hirarchiques furent introduites. En pratique l'approche est donc lgrement diffrente du cas prcdent: ainsi pouvons-nous trouver plusieurs relations de confiance entre un Root-PSC et un certificat utilisateur. Ainsi il est courant qu'un Root-PSC tablisse un certificat pour un deuxime PSC qui lui tablirait des certificats pour les utilisateurs finaux. Dans le mme ordre d'ides il peut y avoir un nombre important d'tapes intermdiaires entre un Root-PSC et un utilisateur final. L'ensemble des tapes entre un Root-PSC avec lequel il existe une relation de confiance et un certificat utilisateur est appel une chane de certification ou encore une chane de confiance. Les chanes de certification permettent donc de valider un certificat dont l'metteur (PSC) direct n'est pas (encore) connu. La validation se fait en validant les tapes successives entre les certificats jusqu'au Root-PSC. Ici se situe une des faiblesses des standards actuels: la validation peut seulement se faire si le titulaire prsente toute la chane de validation (donc tous les certificats intermdiaires) ensemble avec son certificat. Il ne faut pas s'y mprendre: la validation est toujours faites suivant les techniques cryptographiques et est donc digne de confiance, il faut cependant lui prsenter tous les lments ncessaires la vrification. Techniquement cela implique que les certificats utilisateurs devraient donc galement contenir "en annexe" les chanes de certification, c'est--dire les certifcats des PSC intermdiaires jusqu'au Root-PSC. Ce n'est pas un problme technique, mais cela implique qu'il devient difficile de modifierou adapter cette chane aprs distribution des certificats utilisateurs. La solution ces problmes se trouvera vraisemblablement dans de nouveaux protocoles ou encore dans le mrissement et l'tablissement plus grande chelle des annuaires (angl: directories) qui devraient permettre de retrouver dynamiquement toute chane de certification.
1.3.3
Les certifications hirarchiques et croises
Les chanes de certification dcrites ci-dessus se basent sur une certification hirarchique, c'est--dire un PSC plus "haut" dans la chane (donc plus prs du Root-PSC) tablit un certificat pour le PSC "en dessous". Un autre moyen pour tablir une chane de certification est la certification croise (angl.: cross-certification). Ici deux PSC (souvent des Root-PSC) s'tablissent mutuellement un certificat et indiquent ainsi leur confiance mutuelle. La diffrence entre une certification croise et une certification hirarchique est plus conceptuelle que technique: la premire exprime une relation entre gaux tandis que la seconde est plus perue comme relation envers un subordonn. La vrification technique de ces relations reste la mme.
1.3.4
Le concept de confiance
Le mot "confiance" revient rgulirement dans cette discussion d'ICP et il convient de l'claircir brivement. Techniquement, nous parlons de "faire confiance un certificat" si
Annexes
Page 77
nous pouvons valider le certificat, donc si une chane de certification peut tre suivie jusqu' un Root-PSC connu par le logiciel qui effectue la validation. La "confiance" est donc accorde si un ensemble de rgles techniques sont respectes. D'un autre ct, quand nous faisons confiance un certificat, nous nous fions au contenu d'un certificat, et la validation technique de ce dernier n'est qu'un lment contribuant la confiance. En fait, la plus grande partie de la confiance provient du fait que nous estimons que l'autorit de certification ayant tabli un certificat ait correctement fait son travail. La perception de ce travail peut cependant tre diffrente de PSC en PSC, et ici le cadre lgal prend le relais des dfinitions techniques et garantit ainsi dans une certaine mesure le respect de rgles prdfinies. Etant donn que ces rgles sont essentiellement des lois nationales ou directives europennes, la confiance accordable un certificat n'est donc pas ncessairement la mme suivant le PSC en question. Le danger de confusion apparat donc ce niveau: un certificat peut tre techniquement digne de confiance mais ne pas avoir de valeur lgale parce que le PSC metteur ne se soumet aucune rglementation digne de ce nom. En fin de compte il revient donc chaque personne ou service qui est prsent un certificat de prendre une dcision consciente de la confiance accorder au certificat. Dans cette dcision la validit technique est une condition ncessaire, mais pas suffisante.
1.4
Applications
Aujourd'hui deux types de protocoles pouvant se servir de certificats sont largement disponibles. D'un ct il y a S/MIME (Secure Multipurpose Internet Mail Extensions) qui permet d'changer des e-mails encrypts et signs, et d'un autre ct il y a les protocoles de transport SSL et TLS (Secure Socket Layer et Transport Layer Security). Le fonctionnement de S/MIME et son utilisation sont assez faciles. En pratique il suffit de choisir le mode de fonctionnement voulu et le logiciel s'occupe en rgle gnrale du reste. Le rsultat en est un document sign et/ou encrypt destin tre envoy par courrier lectronique. Comme S/MIME se base sur la cryptographie cl publique, l'metteur peut seulement encrypter un message s'il a connaissance au pralable de la cl publique du destinataire du message. Il peut cependant toujours signer son message. TLS respectivement SSL servent scuriser une connexion en authentifiant une ou les deux parties communicantes et en encryptant le trafic gnr. Ces protocoles sont aujourd'hui frquemment rencontrs sur des sites web afin de protger la transmission de donnes sensibles. Le client et le serveur peuvent prsenter un certificat pour authentification. Le serveur peut galement offrir des services diffrents suivant le contenu du certificat (identit du porteur, nationalit, mais aussi PSC ayant tabli le certificat). La diffrence fondamentale entre les deux type de protocoles prsents est que S/MIME permet de signer et encrypter des messages alors que TLS/SSL scurisent uniquement un canal de transmission, sans se prononcer pour autant sur son contenu. Les donnes scurises seulement par TLS/SSL ne bnficient donc pas de la non-rpudiation.
Annexes
Page 78
Annexes
Page 79
2. Rfrences
2.1
Allemagne www.bsi.de www.elster.de Belgique www.fedict.be Finlande www.fineid.fi France : www.minefi.gouv.fr www.internet.gouv.fr www.service-public.fr Italie www.ct.rupa.it www.aipa.it Royaume-Uni www.ukonline.gov.uk www.gateway.gov.uk www.e-envoy.gov.uk www.tScheme.org Suisse www.swisskey.ch www.admin.ch Etudes comparatives www.e-envoy.gov.uk/publications/int_comparisons.htm europennes) (comparaison des initiatives
Les initiatives des pays europens
2.2
Les initiatives de standardisation
Centre for European Normalisation/ISSS, http://www.cenorm.be/isss EEMA , http://www.eema.org/ The European Electronic Signature Standardization Initiative (EESSI) , http://www.ict.etsi.fr/eessi/EESSI-homepage.htm The Internet Engineering Task Force (IETF) , http://www.ietf.org/ International Telecommunication Union (ITU) , http://www.itu.org/ ISO Standards and World Trade: http://www.iso.ch/wtotbt/wtotbt.htm OASIS , http://www.oasis-open.org/ The Open Group , http://www.opengroup.org/ PKI Forum , http://www.pkiforum.org/ Smart Card Industry Association (SCIA) , http://www.scia.org/
Annexes
Page 80
TIE: Trust Infrastructure for Europe, EU IST Project Number 26763, www.tie-project.org World Wide Web Consortium (W3C) , http://www.w3.org/ Information Security Committee, PKI Assessment Guidelines, American Bar Association, June 18, 2001 United States General Accounting Services, Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology, February 2001
Annexes
Page 81
3. Glossaire
AC : Autorit de certification (voir PSC) AE: Autorit d'Enregistrement: service servant d'interface avec le demandeur de certificat en recueillant et vrifiant les informations relatives au demandeur. (angl.: RA, Registration Authority) Algorithme symtrique: algorithme utilisant une mme cl pour les oprations de chiffrage et de dchiffrage. Exemples: DES, IDEA, Rijndael, Blowfish, ... Algorithme asymtrique: algorithme deux cls complmentaires dont une est utilise pour le chiffrage et l'autre pour le dchiffrage. Exemples: RSA, ElGamal, Elliptic Curve Cryptography Annuaire: (angl.: directory): base de donnes structure hirarchique dont une application courante est le stockage d'identits (de personnes, serveurs, PSCs, etc.) ainsi que de certains attributs les concernant, dont p.ex. leurs certificats. Authentification: action de vrification des donnes prsentes (p.ex. l'identit d'une personne). Autorisation: action de permettre une personne (normalement pralablement authentifie) l'accs des services. CA: Certification Authority (voir PSC). Certificat: un certificat consiste en la cl publique laquelle on associe un certain nombre d'attributs (p.ex.: nom, adresse e-mail, ...) et qui sont signs par une autorit de certification. Chiffrage: (angl.: encryption) transformation d'un message en clair en un texte illisible pour toute personne ne connaissant pas les secrets de la transformation. L'opration inverse est appele dchiffrage. On utilise aussi les termes codage et dcodage. Cl prive: partie de la paire de cls utilise par un algorithme asymtrique devant rester sous le contrle exclusif de son (unique) propritaire. Cl publique: partie de la paire de cls utilise par un algorithme asymtrique pouvant tre publique et devant tre communique toutes les parties voulant communiquer. Cl secrte: cl utilise par un algorithme symtrique devant tre connue pas les parties communiquantes. CPS: voir DPC. CRL: les Certificate Revocation Lists sont des listes publies priodiquement par les PSC reprenant les certificats rvoqus. CRS: un Certificate Signing Request est la requte prsente par une entit un PSC afin qu'un certificat lui soit mis. DES: Data Encryption Standard: algorithme symtrique tabli dans les annes 70 toujours trs rpandu (entre autre dans sa version renforce 3DES) DPC: Dclaration des Pratiques de Certification: nonc des pratiques procdurales, techniques et lgales appliques par un PSC. Ce document sert gnralement de base pour valuer le niveau de confiance envers un PSC ou les certificats que ce dernier dlivre. (angl.: CPS, Certificate Practice Statement)
Annexes
Page 82
DSA: Digital Signature Algorithm: algorithme voisin de RSA permettant uniquement la signature de messages mais pas leur chiffrage. ICP: Infrastructure Cls Publiques (angl.: PKI, Public Key Infrastructure) LDAP: Lightweight Directory Access Protocol. Protocole d'accs aux donnes contenues dans un rpertoire. OCSP: l'Online Certification Status Protocol permet de vrifier la validit d'un certificat (p.ex. s'il a t rvoqu ou non) en temps rel. PKI: voir ICP. PSC: Prestataire de Services de Certification: organisme dlivrant des certificats. Aussi utilis pour dcrire une autorit de certification (angl.: CA, Certification authority). Attention: l'organisme PSC peut baser son fonctionnement sur plusieurs PSC "techniques". RA: voir AE. ROOT PSC: PSC qui se trouve en bout de chane de certification et en qui il faut faire explicitement confiance afin d'accepter la chane en question. RSA: algorithme asymtrique de Rivest, Shamir et Adleman S/MIME: les Secure Multipurpose Internet Message Extensions sont un standard permettant l'change scuris d'e-mails. Secure Hash: ce sont des fonctions de hachage scurises, c'est--dire construites sur base de techniques cryptographiques de sorte qu'elles ne soient par rversibles. Signature Digitale: message cryptographique ajout un message garantissant l'authenticit de ce dernier. Time Stamping: Service d'un tiers de confiance crant un message cryptographique garantissant qu'un document ait exist un moment donn. Ce service est important pour des documents ayant une longvit suprieure la cl les ayant signs, ainsi que des documents devant tre lis un moment prcis dans le temps. TLS/SSL: Transport Layer Security et Secure Socket Layer sont deux protocoles trs proches servant tablir des connexions scurises, c'est--dire authentifies et encryptes. X.500: normes de l'ITU dcrivant une structure d'annuaire. X.509: la norme X.509 est une recommandation de l'ITU galement reprise par l'IETF rgissant le contenu et le format des certificats.
Table des Matires
Page 83
Tables des matires
Chapitre I.
1. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2. 2.1 2.2 2.3 3.
Les initiatives existantes _________________________________________ 3
Les initiatives dans les pays europens _____________________________________________ 3 Allemagne Des projets nationaux et des projets locaux _________________________ 4 Belgique - cration dune ICP fdrale et dune carte didentit lectronique ________ 7 Finlande Utilisation de la carte didentit lectronique depuis janvier 2001 _______ 11 France Les travaux du Ministre des Finances _______________________________ 13 Italie - Une carte didentit lectronique en phase de test ________________________ 16 Royaume-Uni Une organisation complexe mais complte ? _____________________ 18 Suisse Lchec dune initiative prive _______________________________________ 20 Synthse et Conclusions ___________________________________________________ 24 Linitiative de la Chambre de Commerce _____________________________________ 27 Linitiative LuxTrust______________________________________________________ 28 Autres initiatives _________________________________________________________ 28
Les initiatives au Grand Duch de Luxembourg_____________________________________ 27
Les aspects lgaux au Grand Duch de Luxembourg _________________________________ 29 Les besoins _________________________________________________ 30
Chapitre II.
1. 1.1 1.2 2. 3.
Les besoins du Secteur Public ___________________________________________________ 30 Des besoins identiques _____________________________________________________ 31 Des besoins de mme type __________________________________________________ 32
Les besoins du Secteur Priv ____________________________________________________ 33 Typologie des besoins __________________________________________________________ 34 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 L'authentification ________________________________________________________ 34 L'autorisation____________________________________________________________ 34 Le cryptage______________________________________________________________ 34 La fonction ou les qualits__________________________________________________ 35 L'intgrit des donnes ____________________________________________________ 35 L'utilisation de canaux scuriss vs. La signature de document ___________________ 36 Le time stamping _________________________________________________________ 36 De l'exploitation des donnes existantes au sein de l'Etat ________________________ 36
4.
Conclusions__________________________________________________________________ 37 Les scenarii de mise en oeuvre _________________________________ 38
Chapitre III.
1. 1.1 1.2 1.3 1.4 1.5
Etude des diffrents scenarii ____________________________________________________ 38 Scnario 1 : Aucune initiative coordonne ____________________________________ 38 Scnario 2 : Un prestataire de services de certification unique ____________________ 41 Scnario 3 : Un prestataire de services de certification unique ____________________ 44 Scnario 4 : La structure hirarchique _______________________________________ 46 Scnario 5 : Mesh hirarchie ____________________________________________ 50
Table des Matires 1.6 1.7 2. 3.
Page 84
Scnario 6 : Bridge Certification Authority ___________________________________ 53 Conclusions _____________________________________________________________ 56
Considrations techniques lies l'interoprabilit __________________________________ 57 Rflexions sur le rle de LuxTrust________________________________________________ 58 3.1 3.2 3.3 3.4 3.5 3.6 Introduction _____________________________________________________________ 58 Le niveau technique : les composants ICP ____________________________________ 60 LuxTrustGov : lutilisation gnralise dune signature qualifie _________________ 62 Linteroprabilit entre des diffrents domaines et PSC _________________________ 64 LuxTrust et le reste du monde ______________________________________________ 65 Les finalits de LuxTrust __________________________________________________ 66 Recommandations __________________________________________ 67
Chapitre IV.
1. 2. 3. 1.
Une approche globale pour les besoins de l'Etat _____________________________________ 67 Partenariats Publics-Privs dans la mise en uvre d'une ICP__________________________ 68 Quelques considrations quant aux tapes suivantes _________________________________ 70 Rappels techniques ____________________________________________________________ 73 1.1 1.2 1.3 1.4 Besoins de scurit de la communication lectronique___________________________ 73 Algorithmes cryptographiques ______________________________________________ 73 Infrastructure Cls Publiques _____________________________________________ 75 Applications _____________________________________________________________ 77 Les initiatives des pays europens ___________________________________________ 79 Les initiatives de standardisation ____________________________________________ 79
ANNEXES ______________________________________________________________________ 71
2.
Rfrences___________________________________________________________________ 79 2.1 2.2
3.
Glossaire ____________________________________________________________________ 81

08 Etude PKI CRP-HT PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

08 Etude PKI CRP-HT PDF

Uploaded by

Copyright:

Available Formats

Centre de Recherche Public Henri Tudor

PEKIN PKI e-Luxembourg

Document destin aux membres de la CNSI

Chapitre I Les initiatives existantes

Les initiatives existantes

1. Les initiatives dans les pays europens

NTIC : Nouvelles Technologies de lInformation et de la Communication

Chapitre I Les initiatives existantes

Allemagne Des projets nationaux et des projets locaux

Bundesamt fr Sicherheit in der Informationstechnik InformationsVerbund Berlin-Bonn

Chapitre I Les initiatives existantes

Self certified Root Certificate

CA certifies Users with User Certificate

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Belgique - cration dune ICP fdrale et dune carte didentit lectronique

FedCA BelPIC entities

Figure 2 : Organisation dune CA membrane compos de plusieurs CA spcialiss.

Fedict : Service public fdral Technologie de lInformation et de la Communication (http://www.fedict.be)

Chapitre I Les initiatives existantes

Juin-juillet 2002 Dbut 2003

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Finlande Utilisation de la carte didentit lectronique depuis janvier 2001

FINland Electronic IDentification card

Chapitre I Les initiatives existantes

Une organisation centralise et des partenaires associs

Finnish Population Register Center

Chapitre I Les initiatives existantes

France Les travaux du Ministre des Finances

Chapitre I Les initiatives existantes

Ministre de lEconomie, des Finances et de lIndustrie

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Italie - Une carte didentit lectronique en phase de test

Rseau Unitaire pour lAdministration Publique

Chapitre I Les initiatives existantes 1.5.2

Circuit de fabrication, dinitialisation et dmission de la carte

IPZS : Istituto Poligrafico e Zecca dello Stato

Chapitre I Les initiatives existantes

United Kingdom Accreditation Service

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Suisse Lchec dune initiative prive

Chapitre I Les initiatives existantes

SWISSKEY Personal ID CA 512

SWISSKEY Personal ID CA 1024

SWISSKEY Corporate ID CA 512

SWISSKEY Corporate ID CA 1024

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

2. Les initiatives au Grand Duch de Luxembourg

Chapitre I Les initiatives existantes

Chapitre I Les initiatives existantes

3. Les aspects Luxembourg

Chapitre II Les besoins

1. Les besoins du Secteur Public

Chapitre II Les besoins