de gestion de clés
Jean-Luc Archimbaud
es infrastructures sont aussi appelées ICP (infrastructures à clés publiques) ou PKI (Public Key Infrastructures). On désigne ainsi l’ensemble des personnes, procédures, matériels, logiciels, pour créer, délivrer, révoquer et publier des certificats électroniques au profit d’une communauté d’utilisateurs.
Il n’y a pas de sécurité dans les services internet de base Ce constat explique en grande partie la genèse de tout ceci.
L’internet, au début de son déploiement mondial, était un réseau académique, réservé à l’enseignement et à la recherche, avec peu d’utilisateurs. En France on dénombrait 3 000 machines connectées en 1990, il y en a plusieurs millions aujourd’hui. Sur ce réseau convivial, la confiance était naturelle. Certains à une époque l’avaient surnommé village global.
Ainsi les protocoles, les applications et les architectures de réseau mis en place au départ, et qui perdurent en grande partie, n’ont pas pris en compte toutes les vulnérabilités évidentes d’un réseau planétaire. Cette simplification a entraîné la prolifération des problèmes de sécurité que l’on connaît maintenant sur ce réseau.
Un des exemples de cette confiance ingénue dans les acteurs du réseau est la messagerie électronique. Basée sur le protocole SMTP (Simple Mail Transfer Protocol), il n’y a aucune garantie sur l’identité de l’expéditeur du
C
message. Il est ainsi trivial d’envoyer un message en usurpant le nom de quelqu’un. Avec un peu de recul, cela paraît une option totalement suicidaire pour un réseau avec des centaines de millions d’utilisateurs. La conséquence se voit chaque jour par le nombre incroyable de « spam » (courriers électroniques non sollicités) et de virus qui arrivent dans les boîtes aux lettres électroniques. S’il était facile de remonter à l’émetteur des messages, cette pollution n’existerait pas ou serait très limitée.
L’identification des machines, elle aussi, est maintenant devenue impossible. Sur ce point, l’opacité a augmenté depuis les débuts de l’internet. Il y a quelques années, le nombre d’adresses IP disponibles était très largement supérieur au peu d’équipements raccordés. Chaque station avait une adresse dédiée et un nom unique. Aujourd’hui, les systèmes de NAT (Network Address Translation) et de PAT (Port Address Translation) qui attribuent quasi aléatoirement des numéros IP rendent difficile, voir impossible, toute identification de machines au comportement dangereux.
Mais il ne faut pas nier le bénéfice de ces choix de l’internet, sans aucune sécurité. Les protocoles et les applications sont beaucoup plus simples que si l’on avait essayé d’y ajouter des fonctions de sécurité. Cette simplicité permet de disposer de matériels et de logiciels à des coûts bas et d’intégrer aisément des équipements hétérogènes. Cela a contribué indéniablement au déploiement exponentiel de ce réseau.
Ainsi, dans les services classiques de l’internet, il n’y a pas d’authentification des utilisateurs et des équipements, pas d’intégrité, ni de confidentialité des informations transportées, les trois fonctions de base de la sécurité. Ceci n’est plus supportable pour les entreprises, les administrations, les particuliers, qui décident de basculer leurs circuits d’information papier, en transferts de documents électroniques via internet.
Il a donc été nécessaire de rajouter à ces services un ensemble de mécanismes pour assurer les trois fonctions de sécurité sur les documents et les nouveaux modes de communication électroniques.
Pour mettre en place ces mécanismes de sécurité, le premier problème est la taille de l’internet. S’il est relativement aisé d’installer ces fonctions entre quelques points d’un réseau, entre un ensemble d’utilisateurs identifiés, ce n’est pas le cas avec des centaines de millions de sites et autant d’utilisateurs anonymes.
Une découverte a permis de résoudre ce problème : la cryptographie asymétrique. Associée à l’utilisation des certificats électroniques, elle permet à travers différents mécanismes d’offrir toutes les fonctions de sécurité. Les lecteurs non familiers de ce sujet pourront lire l’article, de l’auteur dans ce
numéro, « Les principes techniques des certificats électroniques » qui donne les éléments techniques pour comprendre ce qui conduit au besoin de certificats électroniques. Il faut alors créer des certificats électroniques pour tous les utilisateurs et tous les serveurs de l’internet.
Les IGC, infrastructures de gestion de clés
Les certificats électroniques sont des petits fichiers qu’il faut donc créer et gérer. Leur fabrication est simple, un programme de quelques lignes de code suffit. Mais ces éléments doivent être de confiance. Il en découle un certain nombre d’obligations : les informations qu’ils contiennent doivent avoir été vérifiées par des personnes habilitées, ils doivent être infalsifiables, il faut les invalider lorsque les informations qu’ils contiennent ne sont plus exactes...
Il est alors nécessaire de désigner des acteurs, équivalents des agents de mairie, et de définir un circuit de procédures et de vérifications. Il faut ainsi créer une IGC, infrastructure de gestion de clés, terme qui désigne l’ensemble des personnes, procédures, matériels et logiciels, pour créer, délivrer, révoquer et publier des certificats électroniques. Ce sigle rappelle que le certificat électronique permet de gérer des clés, publiques et privées.
Les deux autres sigles, ICP (infrastructure à clés publiques) et PKI (Public Key Infrastructure) sont synonymes d’IGC.
Des normes internationales décrivent les éléments fonctionnels de base d’une IGC : les autorités d’enregistrement, une autorité de certification et un service de publication.
Les autorités d’enregistrement (AE)
Ce sont les mairies ou les préfectures, les guichets auxquels s’adressent les utilisateurs qui désirent obtenir un certificat. L’autorité d’enregistrement (AE) vérifie l’identité du demandeur, s’assure que celui-ci possède bien un couple de clés privée-publique et récupère la clé publique du demandeur.
Elle transmet ensuite ces informations (informations d’identité du demandeur ainsi que sa clé publique) à l’autorité de certification. Une autorité d’enregistrement peut être une personne habilitée, dans un secrétariat.
Une autorité de certification (AC ou CA, Certification Authority)
Celle-ci reçoit les demandes de création de certificats venant des autorités d’enregistrement. Elle crée les certificats, signe ces certificats en utilisant sa clé privée et les transmet aux utilisateurs et au service de publication.
La clé privée d’une autorité de certification est un secret qui nécessite une protection maximale. Un tiers qui prendrait connaissance de cette clé, pourrait générer des faux certificats. Une méthode pour assurer cette protection est de stocker ce secret sur un ordinateur dédié, enfermé dans un coffre, jamais connecté sur un réseau, que l’on utilise uniquement pour créer les certificats.
Un service de publication
Celui-ci rend disponible les certificats émis par l’autorité de certification.
Il publie aussi la liste des certificats valides et des certificats révoqués.
Concrètement ce service peut être rendu par un annuaire électronique LDAP (Lightweight Directory Access Protocol) ou un serveur web accessibles par l’internet.
La liste de révocation (CRL, Certificate Revocation List)
Lorsqu’un certificat est créé, il contient sa date de création et une date de fin de validité. Passée cette date aucune application ne l’acceptera. Mais cette date n’est pas suffisante pour invalider un certificat dans certains cas. En effet, une personne peut quitter une entreprise ou changer de service ou se faire dérober sa clé secrète. Dans ce cas il faut invalider son certificat courant. La méthode est la même que pour les cartes bancaires. Chaque autorité de certification publie régulièrement la liste des certificats révoqués, qui ne sont plus valides. Cette liste est généralement dans un annuaire LDAP, accessible par le web. Pour garantir son origine et son intégrité, elle est signée par l’autorité de certification.
Le choix et la mise au point des procédures pour délivrer les certificats sont fondamentaux pour la fiabilité de l’ensemble. Plus que les faiblesses des algorithmes de chiffrement, ce sont elles qui sont le talon d’Achille des IGC.
La DCSSI (Direction centrale de la sécurité des systèmes d’information) diffuse un document cadre recommandé pour décrire ces procédures : la DPC, description des procédures de certification.
La politique de certification (PC)
Présentée à la fin de cette section, son élaboration est néanmoins la première étape dans la mise en place d’une IGC. La politique de certification constitue l’engagement d’une autorité de certification et de l’IGC associée sur les services rendus. Ce document doit permettre de se rendre compte de la portée de cette autorité et d’en évaluer la solidité. La DCSSI recommande
à chaque autorité de certification de décrire sa politique dans un document dans un format prédéfini, PC2.
La confiance dans les autorités de certification
Concrètement, avec les outils informatiques courants, faire confiance à une autorité de certification consiste à ajouter dans le navigateur l’outil de messagerie ou une application quelconque le certificat de cette autorité de certification. Dans les outils standard, des commandes le permettent. A partir du moment où l’utilisateur décide d’ajouter ce certificat, son application acceptera tous les certificats émis par l’autorité de certification.
On retrouve le même principe dans les applications serveur.
L’administrateur de ces applications ajoute les certificats des autorités de certification dont il acceptera les certificats d’utilisateurs. « Accepter » est à prendre au sens de « faire confiance aux informations contenues dans les certificats ».
Les certificats des autorités de certification ressemblent à des certificats d’utilisateurs. Ils sont signés soit par l’autorité de certification elle-même, soit par une autorité supérieure. Ce dernier cas permet de créer une arborescence d’autorités de certification. Lorsqu’il y a une arborescence, en faisant confiance à la racine on fait confiance à l’ensemble des branches.
Un exemple : l’IGC du CNRS
Il existe une littérature importante sur les IGC, de très bonne qualité mais souvent très théorique et généraliste. Cette section décrit au contraire un cas concret de mise en place d’une telle infrastructure au CNRS, en décrivant l’existant et les objectifs, ce qui explique les choix effectués ainsi que la démarche suivie.
Pas de réseau privé d’entreprise au CNRS
Le CNRS, organisme public de recherche fondamentale, dispose d’un bon réseau de communication. Tous les laboratoires sont connectés à l’internet via Renater (REseau NAtional de la technologie, de l’enseignement et de la recherche) avec des débits souvent bien meilleurs que les entreprises et les autres administrations. Mais on constate que ce réseau et les services associés sont « sous-employés » par manque de sécurité, d’authentification et d’intégrité dans les échanges en particulier. Il y a très peu d’intranets avec les services associés et tous les actes et procédures administratifs officiels utilisent encore le papier et le courrier postal, alors que la messagerie
électronique est utilisée par tout le personnel quotidiennement depuis de nombreuses années.
La principale raison de cette « insécurité » est qu’il n’y a pas un réseau informatique d’entreprise au CNRS, zone que l’on pourrait considérer de confiance. Pour donner quelques explications, il faut savoir que le CNRS est constitué de 1 300 laboratoires et services, la plupart associés (aux universités...), dispersés sur l’ensemble du territoire (et même à l’étranger), souvent dans des campus universitaires ouverts. Dans chaque laboratoire travaillent des agents CNRS gérés par l’organisme, mais aussi d’autres personnels gérés par des universités, d’autres organismes…
L’administration de l’organisme est elle-même éclatée sur 20 délégations régionales. Cet ensemble utilise Renater pour communiquer, réseau sans aucun contrôle d’accès. Cette situation rend impossible la création d’un réseau interne (au sens de la couche 3 du modèle OSI) avec des méthodes classiques de segmentation de réseau. Sans ce réseau d’entreprise, il est impossible de créer des intranets avec des applications réservées à différents groupes de personnels et d’utiliser les services de base de l’internet (messagerie…) pour les actes administratifs sans ajout de fonctionnalités telles que la signature électronique.
Ce sont ces besoins « classiques » associés à cette situation complexe en termes d’architecture de réseau et d’organisation qui ont conduit le CNRS à mettre très tôt en place une IGC.
Les éléments de la politique de certification
Il y a deux ans, le CNRS a finalisé sa politique de certification au format PC2 recommandé par la DCSSI. Bien qu’étant le « document fondateur », il n’a été créé que dans une seconde étape. La première étape a été de réunir un petit groupe formé de spécialistes sécurité, de spécialistes des applications informatiques mais aussi de membres du service juridique et de responsables administratifs connaissant bien le fonctionnement de l’organisme pour définir ce que l’on voulait faire, pouvait faire et comment le faire. En effet, la rédaction d’une politique dans le format PC2 ne peut être lancée que lorsque l’on a répondu à des questions de base : des certificats pour quoi faire ? Pour qui ? De quelle forme ? Avec quels protagonistes ?…
C’est d’abord de la bonne réponse à ces questions, bonne dans le sens bien adaptée à l’organisme, que va dépendre le succès de la mise en place d’une IGC.
Voici en résumé la politique de certification de l’autorité de certification CNRS.
Des certificats pour quels usages ?
Les certificats CNRS sont destinés à un usage professionnel uniquement, lié à l’activité dans ou au nom de l’organisme. Ces certificats CNRS sont créés pour toutes les communications et les applications (scientifiques, administratives...) où ces éléments peuvent être utiles. Ce sont donc des certificats à usages multiples. Au départ intra-organisme, tout est en place (respect des standards...) pour une utilisation future dans les échanges avec les partenaires extérieurs.
Les certificats créés actuellement sont destinés à l’authentification et l’intégrité (donc aussi la signature), dans un second temps des certificats pour le chiffrement (confidentialité) seront créés. L’authentification et l’intégrité sont les besoins prioritaires, loin devant la confidentialité. De plus le service de chiffrement impose un séquestre des clés privées qui doit être assuré avec de nombreuses précautions, à la fois techniques, mais aussi administratives et juridiques, peut-être par un tiers.
Pour les certificats CNRS actuels, l’utilisateur est évidemment le seul à connaître sa clé privée, ce qui est conforme à la législation sur la validité de la signature électronique.
Des certificats avec quels outils utilisateurs ?
De par son organisation et son ouverture, une des contraintes du CNRS est d’utiliser sur le poste utilisateur les produits standard et grand public, de navigation et de messagerie entre autres. Il a donc été choisi, pour utiliser et gérer les certificats, de supporter en priorité les versions récentes de Netscape-Mozilla, Internet Explorer et Outlook.
Des certificats pour qui ?
Il a été décidé de pouvoir délivrer des certificats à toute personne qui travaille dans un laboratoire ou service CNRS, agent CNRS ou non, permanent ou non, et de l’étendre à toute personne qui a besoin d’un certificat dans le cadre de collaborations étroites avec le CNRS. Se restreindre uniquement aux agents fonctionnaires du CNRS ne présentait pas d’intérêt, les applications actuelles ne font pas cette différence. Outre les certificats de personnes, il est délivré aussi des certificats pour des services, serveurs web par exemple, et à l’étude pour la signature de code, applets Java par exemple.
Quels logiciels pour les serveurs de l’IGC ?
Le CNRS a développé son propre logiciel appelé CNRS-IGC, écrit en grande partie en PERL, basé sur OpenSSL, OpenLDAP et Apache. Il permet de gérer plusieurs autorités de certification et des centaines d’autorités d’enregistrement. Les opérateurs, les autorités d’enregistrement et les utilisateurs n’ont besoin que d’un navigateur classique pour toutes les actions liées à la gestion des certificats : demandes, créations, vérifications, validations, révocations...
Le logiciel CNRS-IGC est diffusé de manière contrôlée dans la communauté enseignement-recherche, on envisage la possibilité de le diffuser en licence LGPL.
Quelle architecture d’autorités de certification ?
Actuellement le certificat de l’autorité de certification CNRS est auto- signé. Une étude est en cours pour le faire signer par l’IGC-A de la DCSSI.
Vu la structure de l’organisme et les besoins, une arborescence d’autorités de certification a été créée. L’autorité racine CNRS a trois autorités filles :
– CNRS-Standard qui délivre des certificats pour des utilisations courantes ;
– CNRS-Plus qui délivre des certificats à des personnes ayant une fonction de direction pour les actes importants ;
– CNRS-Projets, dont le but est de pouvoir délivrer des certificats pour des projets de recherche et plus globalement des partenariats nationaux, européens… auxquels participent des entités CNRS mais aussi des organismes non CNRS, des industriels... Sous cette autorité on peut créer autant de sous-autorités que de projets. Cette branche est typiquement un besoin d’organisme de recherche qui a de nombreuses collaborations.
Pour les certificats CNRS-Standard, il y a une autorité d’enregistrement par laboratoire qui est le directeur du laboratoire ou son représentant. Les demandes de certificats CNRS-Standard du personnel du laboratoire sont faites auprès de cette autorité d’enregistrement qui effectue un certain nombre de vérifications puis les accepte ou non. Ces contrôles et cette décision sont donc totalement décentralisés, placés au niveau du directeur du laboratoire, seule personne qui connaît en temps réel l’ensemble de son personnel et donc peut faire les vérifications nécessaires.
Pour les certificats CNRS-Plus, les autorités d’enregistrement sont les personnes avec une haute responsabilité dans le CNRS, actuellement les délégués régionaux, représentants régionaux de la direction du CNRS.
Avec les certificats des sous-autorités dépendantes de CNRS-Projets, l’autorité d’enregistrement de charge sous-autorité est le responsable du projet ou son représentant.
Quel format pour les certificats ?
Les certificats sont au format X509V3, standard actuel utilisé par tous. Les certificats de personnes sont délivrés avec une durée de vie de un an par défaut. La durée peut être inférieure (personnel temporaire par exemple), c’est l’autorité d’enregistrement qui le décide.
Les certificats CNRS contiennent peu d’informations : le prénom, le nom, l’adresse électronique, le code du laboratoire, l’organisme (CNRS) et le pays pour les certificats de personne ; d’une part parce que ce sont des documents publics et d’autre part parce qu’il faut que les informations contenues dans le certificat soient assez stables dans le temps.
Le certificat créé, ainsi que la clé privée associée, sont par défaut dans un fichier sur le poste de l’utilisateur. Celui-ci peut évidemment le transférer dans un jeton USB s’il le désire.
Quelles listes de révocation ?
La liste de révocation de chaque autorité est publiée chaque nuit avec une durée de validité de un mois.
Quelle publication ?
Un annuaire LDAP contient les certificats des personnes et des services.
Actuellement en accès uniquement aux possesseurs de certificats CNRS, il va être prochainement ouvert en accès public avec certaines limitations comme le nombre de réponses.
Une démarche progressive et un déploiement dans un mode « tâche d’huile » Le CNRS n’a pas pris comme décision initiale de créer une IGC et de délivrer un certificat à l’ensemble du personnel des laboratoires. Au contraire, il y a eu plusieurs phases.
Le projet IGC a été conduit par l’UREC, Unité REseaux du CNRS, unité de service du CNRS dont une des missions est de mener des projets technologiques liés aux réseaux ou à la sécurité informatique dans un mode exploratoire similaire à un service de recherche et développement d’une entreprise.
En 1999, l’UREC, percevant les auto-limitations d’utilisation du réseau pour des communications officielles par manque de sécurité, mène une première réflexion sur les certificats électroniques. Face au coût trop élevé des solutions commerciales, une plate-forme de tests d’IGC est montée, avec une autorité de certification CNRS-Test. Un développement logiciel est réalisé à partir de briques du domaine public. Plus d’une centaine de certificats sont délivrés, utilisés dans différentes applications.
Le test s’avérant positif mais demandant d’être prudent, mi-2000, le CNRS confie officiellement à l’UREC la mise en place d’une autorité de certification. Un comité de pilotage est créé avec un groupe technique. La première version de la politique de certification est écrite. En parallèle, l’UREC relance un développement plus solide, mais toujours avec des éléments du domaine public. La première version est mise en exploitation au printemps 2001. L’autorité de certification CNRS est lancée. En juin 2001, plusieurs sites pilotes utilisateurs démarrent dans des environnements variés : laboratoires de recherche, structures administratives nationales et régionales, groupes thématiques de recherche. Le logiciel continue d’être amélioré et la diffusion des certificats s’étend petit à petit en mode tâche d’huile.
Fin 2003, il est décidé de passer en phase de déploiement. Une organisation plus opérationnelle se met de nouveau en place, en définissant plusieurs rôles : comité de pilotage, autorité administrative, administrateur de l’IGC, responsable de l’exploitation de l’IGC, support utilisateur...
Un des choix est de ne délivrer des certificats qu’aux personnes qui en ont besoin. Ainsi quand on parle de déployer les certificats pour l’ensemble du CNRS, ce n’est pas pour donner un certificat (qui serait inutilisé) à l’ensemble du personnel. Cela sous-entend d’être capable de délivrer rapidement un certificat à n’importe quel personnel de n’importe quel laboratoire ou service s’il en a besoin.
Nous n’avons présenté qu’un exemple de mise en place d’IGC, d’autres orientations sont possibles. Les plus courantes sont de faire appel à la sous- traitance pour l’ensemble ou pour des parties, d’utiliser uniquement des supports physiques externes tels que des cartes à puce ou des jetons USB ou encore de créer les certificats depuis l’annuaire de l’entreprise. Sur ce point, pour différentes raisons, il n’existe pas d’annuaire CNRS contenant toutes les personnes qui travaillent dans les laboratoires. C’est un des éléments qui explique les choix faits en termes de diffusion par cet organisme.
Les applications utilisatrices de certificats (au CNRS)
Un projet d’IGC n’est pas destiné à réaliser une belle construction pour créer des certificats. La finalité est que les certificats émis soient utilisés par des applications. Nous allons en lister certaines. Cela peut paraître hors sujet dans une description d’IGC mais il faut comprendre que les utilisations que l’on fait des certificats ont une forte influence sur les principes de l’IGC que l’on met en place, sur les types de certificats créés, sur les procédures... On ne peut donc pas dissocier complètement une IGC des applications utilisatrices des certificats créés par celle-ci.
Plutôt qu’une énumération des utilisations possibles, nous prendrons pour être plus concret un exemple, ce qui se déploie au CNRS.
Utilisations génériques
Dans de très nombreux laboratoires et services du CNRS, les serveurs web et de messagerie (il y en a plusieurs centaines au CNRS) possèdent un certificat (CNRS) de serveur. Il permet de sécuriser les communications entre le serveur et les clients avec les protocoles tel que HTTPS pour le web, IMAPS et POPS pour la messagerie. Ce mode de transport chiffré permet ensuite à l’utilisateur d’entrer son mot de passe sans crainte d’écoute sur le réseau. Ceci ne nécessite aucun développement particulier. Certains sites y ajoutent la possibilité d’authentifier les utilisateurs avec leur certificat (utilisateur), sans qu’ils aient à entrer un mot de passe (pour accéder à leur compte de messagerie par exemple).
Des unités CNRS utilisent le logiciel Sympa pour gérer des listes de diffusion électroniques. Dans ce logiciel, les certificats peuvent être utilisés pour d’un côté authentifier les administrateurs des listes et leur permettre de les administrer à distance (sans mot de passe supplémentaire) et d’un autre côté pour authentifier les émetteurs des messages signés diffusés dans les listes et ne permettre qu’à certains utilisateurs d’émettre des messages, les abonnés de la liste par exemple ou uniquement un modérateur. A l’heure des spam d’envergure, cette fonctionnalité est très utile au CNRS. On peut rappeler que la signature électronique est le seul moyen actuel d’éviter l’usurpation d’adresse.
Utilisations de type gestion
Actuellement, dans six régions, des applications qui permettent d’accéder à des informations de gestion ont été développées et des débuts de
dématérialisation de procédures administratives lancés. On peut citer comme exemples :
– l’accès à des informations financières confidentielles pour chaque gestionnaire de laboratoire : factures en attente d’intégration, commandes non soldées…
– l’accès à des informations utiles aux laboratoires : inventaire des matériels, moteur de recherche des fournisseurs avec marché CNRS et de leur situation administrative…
– l’accès à des bases de données nationales existantes à accès contrôlé par mot de passe. Il s’est agi de développer des interfaces qui d’un côté demandent le certificat au client et de l’autre fournissent un nom-mot de passe aux applications, permettant d’utiliser des certificats sans modification des applications existantes. L’utilisateur n’a ainsi plus besoin de mémoriser ces mots de passe ;
– les demandes de formation permanente et le suivi des dossiers par les différentes personnes concernées : demandeur, directeur, responsable formation permanente…
Ces applications se généralisent dans les autres régions, d’autres sont en cours de développement. Le principe est simple. Les utilisateurs, en priorité les directeurs de laboratoires et les responsables financiers, utilisent leur navigateur habituel pour accéder à ces applications avec leur certificat. Un des gains pour l’utilisateur est qu’il n’a pas besoin de mémoriser les multiples mots de passe, son certificat permet de l’authentifier.
Utilisations dans les laboratoires
Pour donner quelques exemples, les certificats sont utilisés pour :
– la mise à jour de serveurs web dynamiques par plusieurs administrateurs ;
– l’accès à l’intranet du laboratoire. Il s’agit d’intranet de personnes, le contrôle d’accès se faisant sur les certificats de personnes. Ceci est très utile pour les laboratoires éclatés sur plusieurs sites ou pour l’accès à cet intranet depuis un poste nomade ;
– la vie quotidienne du laboratoire en utilisant les messages électroniques signés pour des échanges officiels : dépôt de jours de congés, enquêtes électroniques...
Utilisations dans divers projets de recherche et diverses communautés On les retrouve par exemple dans :
– la création d’intranets de départements scientifiques (STIC, sciences et technologies de l’information et de la communication, 130 directeurs de laboratoires), de communautés (450 correspondants et 55 coordinateurs sécurité informatiques, membres de groupes de travail, de réseaux thématiques…). Avec un contrôle d’accès par certificat, ils permettent un accès restreint à des pages web en lecture et à des zones d’échanges, l’utilisation d’agendas partagés et d’autres outils de travail collaboratif ;
– l’authentification de tous les utilisateurs d’une grille de calcul, utilisateurs du CNRS mais aussi d’autres organismes et sociétés comme le CEA (Commissariat à l’énergie atomique) et l’EDF, ainsi que de tous les serveurs sur cette grille ;
– la signature de notes demandant intégrité et authentification de l’émetteur : les avis de sécurité venant des CERTs (Computer Emergency Response Team) par exemple ;
– la diffusion de logiciels achetés avec une licence d’organisme CNRS à tout possesseur de certificat CNRS.
Ces applications continuent, prennent de l’ampleur avec de nouveaux utilisateurs, et de nouvelles apparaissent. Une demande plus récente, mais qui devient importante, concerne l’obtention d’un certificat pour chaque poste nomade utilisant IPSec ou des méthodes de tunneling sécurisées.
Toutes ces applications ne se sont pas mises en place sans un très important effort d’information, de formation et de support des ingénieurs informatiques, en particulier les administrateurs des systèmes et des réseaux dans les laboratoires, les sites centraux de gestion... Il faut que cette population comprenne les mécanismes, les buts et se forme à la configuration des outils. Le même type d’effort est fait auprès des utilisateurs, en mettant en place un système de support.
Les responsables du projet IGC n’interviennent pas directement dans la mise en place de ces applications, dans leur création et leur déploiement. Par contre, ils prennent en compte les nouveaux besoins, les problèmes rencontrés, pour éventuellement adapter les procédures ou les formats des certificats. Ils veillent aussi de manière à éviter les dérives possibles d’utilisations trop laxistes. Il y a donc une concertation étroite entre le pilotage de l’IGC et les personnes qui mettent en place les applications, sans oublier les utilisateurs.
Si l’on reprend la liste des applications ci-dessus, on pourrait trouver une solution pour chacune sans utiliser les certificats électroniques. Mais les méthodes de sécurisation seraient différentes et chaque application nécessiterait une gestion des utilisateurs avec leurs mots de passe.
L’avantage du certificat est que l’utilisateur possède un seul certificat et un seul mot de passe, celui qui lui permet de débloquer la clé privée sur son poste et qui ne circule pas sur le réseau. Les administrateurs des applications font confiance à ce certificat (et à la clé privée associée) pour authentifier l’utilisateur. Ils n’ont donc pas besoin de gérer des mots de passe. C’est ce gain en temps d’administration, proportionnel au nombre d’applications, qui constitue un des principaux bénéfices de l’utilisation des certificats au CNRS. Ce n’est pas uniquement l’apport en termes de fonctionnalités de sécurité.
La complexité de la mise en place d’une IGC
Les IGC ne sont pas un sujet nouveau. Comme toute nouvelle technique, la première période fut euphorique. La presse spécialisée ne parlait que de PKI comme l’outil qui allait résoudre tous les problèmes de sécurité et d’informatique répartie. Après l’échec de plusieurs tentatives grandioses de mises en place, le balancier est parti dans l’autre sens. Le discours suivant présentait ces infrastructures comme trop complexes à créer, trop lourdes, trop coûteuses, sans vraiment de bénéfices pour les entreprises, des joujoux de responsables de sécurité. On arrive maintenant à une période plus raisonnable où des IGC se déploient avec des objectifs et des moyens moins ambitieux mais réalistes. Le ministère de l’Economie et des finances, par exemple, continue à garder son cap d’utiliser de plus en plus les certificats électroniques avec les entreprises et les particuliers.
Cette section liste les problèmes toujours présents dans ces projets d’infrastructure et plus globalement dans l’utilisation des certificats électroniques, mais essaie d’apporter un éclairage du terrain, de les relativiser, pour les prendre en compte et ainsi éviter certains écueils.
Le projet
La première constatation est que c’est effectivement un projet complexe, car il touche à tous les services d’une entreprise. En phase d’étude, il faut réunir des compétences dans des domaines variés, la sécurité des systèmes d’information évidemment mais aussi les applications informatiques, l’organisation, les procédures administratives, les aspects juridiques, les représentants du personnel…
Le choix du pilotage de ce projet est certainement fondamental. En confier la totale conduite à la direction de la sécurité des systèmes d’information, solution à laquelle on pense de manière naturelle, est certainement une décision à bien peser. En effet, ce service peut avoir tendance à construire un système avec une parfaite fiabilité et une sécurité élevée mais arriver à un ensemble très coûteux avec des procédures tellement draconiennes qu’inacceptables dans l’organisation. Il faut certainement pondérer cette vision sécuritaire, obligatoire il est vrai, par des services plus proches des applications.
Sur la méthode, considérer qu’un projet global pour l’ensemble d’une entreprise est trop ambitieux et décider de procéder par étapes, progressivement, avec des utilisateurs et des applications pilotes, pour valider les options prises et les corriger, est certainement une bonne option.
Une autre recommandation est de choisir les testeurs de manière judicieuse.
Voulant l’adhésion des décideurs d’une organisation, on peut être tenté de les choisir comme population pilote, en déployant une messagerie électronique sécurisée par exemple. Ce n’est certainement pas la meilleure chose à faire. Les directeurs maîtrisent rarement l’outil informatique (toute nouvelle fonctionnalité va être difficile à expliquer), n’ont pas de temps à perdre pour apprendre à manipuler des certificats, et utilisent certainement rarement la messagerie pour les échanges importants (donc quelle est l’utilité de les signer et de les chiffrer ?).
Les objectifs
Une lapalissade est qu’il faut avoir des objectifs qui correspondent à ses besoins et à ses moyens. Si l’on veut quelques certificats de serveurs par exemple on peut les acheter ou les générer avec un simple outil du domaine public comme OpenSSL. Il est inutile de créer une infrastructure de gestion de clés. A noter que lorsqu’une entreprise externalise son IGC, il faut qu’elle en mesure les conséquences. Confier totalement la production des éléments sur lesquels peut reposer à terme l’authentification de son personnel et tous les contrôles d’accès à une société externe doit conduire à s’interroger sur la pérennité du sous-traitant et la dépendance engendrée.
Dans le choix des applications, les certificats n’étant qu’un outil de base utilisé par celles-ci, elles peuvent être très différentes d’une organisation à l’autre. Quand on pense certificats électroniques, on voit immédiatement la signature électronique et la confidentialité des courriers électroniques comme l’application phare. Au CNRS, comme le montre la section précédente, cette utilisation est actuellement marginale, l’authentification
des utilisateurs pour accéder à des applications et des informations de type intranet est le principal service rendu.
D’un point de vue plus général, lors de l’arrivée de nouveaux outils technologiques, on s’est très souvent trompé dans les prévisions d’utilisation. La télévision et l’internet ne sont pas tout à fait des outils annoncés de diffusion de la culture à tous, en France le Minitel a fortement divergé des buts annoncés en devenant rose, le téléphone portable n’a pas uniquement une clientèle professionnelle comme prévu... Il se peut que l’utilisation majeure future des certificats ne soit pas pour signer du courrier électronique. Même si l’on se fixe des objectifs restreints en termes d’applications au départ, une bonne précaution est certainement d’être prêt à faire face à d’autres utilisations non imaginées, et même de laisser faire les concepteurs d’applications qui auront des idées.
Un autre objectif évident, et qu’il faut se fixer, est d’arriver à un niveau de sécurité global des éléments de l’IGC – cela inclut les procédures – acceptable pour les utilisations que l’on veut faire des certificats. Il faut savoir qu’il n’y a pas de contraintes techniques précises imposées. On ne doit pas avoir obligatoirement la clé privée de l’autorité de certification partagée par l’ensemble de l’équipe de direction, les serveurs de l’IGC dans un blockhaus, avoir du personnel assermenté… Si on a peu de moyen, il faut faire au mieux, la recommandation étant plutôt d’avoir un niveau homogène de sécurité dans tous les éléments. Inutile d’avoir un site central très sécurisé pour héberger les serveurs de l’IGC, si on transmet à l’utilisateur son mot de passe pour accéder à sa clé privée par fax.
Par contre, l’obligation est de respecter sa PC, politique de certification, que l’on affiche ainsi que sa DPC, déclaration des procédures de certification, dans les procédures que l’on met en place. Se fixer un niveau de sécurité trop élevé de l’IGC pour l’utilisation qu’on veut faire des certificats conduira à un projet trop coûteux, abandonné avant de commencer.
Le support de stockage des éléments de certification d’un utilisateur
Pour utiliser son certificat, l’utilisateur a besoin de celui-ci, de sa clé privée ainsi que d’autres certificats comme ceux des autorités de certification. Il est nécessaire de décider où vont être stockés ces éléments.
Nous ne comparerons pas techniquement les différents supports mais insisterons sur les conséquences des deux grandes options.
La première, la plus simple, est d’utiliser un simple fichier sur le poste de travail de l’utilisateur, un mot de passe lui permettant de débloquer (accéder à) sa clé privée. Windows gère en standard ces fichiers, donc il n’y a pas
besoin d’installation de pilote. Lorsque l’utilisateur veut utiliser ses éléments de certification sur un autre ordinateur, il exporte ceux-ci dans un fichier protégé par un autre mot de passe, copie ce fichier sur l’autre poste de travail et les installe. La vulnérabilité de ce système est que le secret, la clé privée, est déposé sur le disque du poste de travail et on peut penser que même protégée par un mot de passe elle peut être piratée.
L’autre option est de stocker ces éléments sur un support externe, concrètement un jeton USB, petite clé qui se connecte sur le port USB, ou une carte à puce. Les avantages sont que la clé privée est uniquement stockée sur cet objet, que l’utilisateur doit le posséder pour utiliser celle-ci et qu’il ne le transmettra pas trop inconsidérément à un tiers. La clé privée sera dans ce cas bien mieux protégée. De plus la carte à puce ou le jeton peut aussi servir à d’autres utilisations, comme le contrôle d’accès physique, contenir un porte-monnaie électronique pour le restaurant du personnel…
Si la seconde option est la plus séduisante, choisir dès le départ de stocker les éléments de certification sur un support externe ajoute un surcoût financier important et une complexification au projet de création d’IGC. En effet, il faut évidemment acheter ces supports mais il faut aussi les gérer : les créer, les distribuer aux utilisateurs, les renouveler, les remplacer en cas de perte ou de détérioration (ceci très rapidement lorsqu’ils sont obligatoires pour travailler)... avec toutes les procédures et les contrôles nécessaires. Sur le poste de travail, ils nécessitent l’installation de pilotes particuliers, voir même des périphériques spécifiques, dans le cas des cartes à puce. L’idée répandue que le stockage des éléments de certification sur un support externe permet de les utiliser sur n’importe quel poste est totalement fausse.
C’est l’inverse. Il est préférable de les avoir sous la forme d’un fichier sur une disquette si l’on désire changer de poste de travail.
Si l’entreprise possède déjà une infrastructure pour gérer ces supports physiques avec une population réduite et homogène en termes de parc informatique, ces objets pourront assez facilement servir à stocker les certificats. Dans les autres cas, le surcoût (financier et humain) doit être au préalable évalué. Au CNRS nous avons effectué un test d’utilisation de jetons USB avec plusieurs sites. Devant la difficulté à trouver des pilotes pour tous les systèmes différents dans ces laboratoires, nous en avons conclu que ces supports ne pouvaient pas s’envisager pour l’ensemble du personnel. Par contre, pour des groupes homogènes avec un besoin de niveau de sécurité élevé, cette solution pourrait être mise en place, avec un bon support technique.
A noter que délivrer les éléments de certification aux utilisateurs sous forme de fichier n’interdit pas à ceux-ci de les stocker sur un support externe comme un jeton USB et d’utiliser uniquement ce jeton.
Les CRL
La CRL, Certificate Revocation List, autrement dit la liste de révocation, qui contient la liste des certificats révoqués, est d’un usage très lourd. Elle est souvent mise en exergue comme un dysfonctionnement majeur des IGC. Il est exact que cette liste est stockée sur un serveur et qu’il faut la recharger régulièrement pour avoir la dernière version.
Mais les banques utilisent le même système pour les cartes bancaires. En effet, les équipements des commerçants récupèrent chaque jour la liste des cartes bancaires volées ou interrogent en temps réel un serveur pour les transactions importantes. Pour les cartes d’identité, le système est aussi similaire. Or nous vivons avec ce système.
Il faut aussi préciser que cette liste ne contient que les numéros de série des certificats valides auxquels on ne doit plus faire confiance. Elle ne contient pas les certificats invalides car leur date de validité est dépassée.
Elle reste donc de taille modeste.
Le troisième point à la critique des listes de révocation, le plus fondamental, est que les certificats dont on parle ne sont que des éléments d’identification. Ce ne sont pas des éléments qui décrivent les droits d’accès d’une personne (qui sont dans d’autres éléments, se reporter à la dernière section). Or en cas de problème, l’urgence est de bloquer les accès d’un utilisateur et non d’invalider sa carte d’identité. Il faut donc plutôt concentrer ses efforts sur la mise à jour rapide des droits d’accès plutôt que des révocations de certificats électroniques d’identité.
Un protocole permet d’interroger ces listes en temps réel, OCSP (Online Certificate Status Protocol). Il est déjà standardisé et implémenté dans certains produits. C’est peut-être une solution dans l’avenir.
La politique du CNRS sur ce sujet est de recommander aux administrateurs de serveurs avec des contrôles d’accès par certificat de recharger les CRL chaque nuit, mais aux utilisateurs standard de ne pas tenir compte de ces listes sur leur poste de travail.
Des outils imparfaits pour les utilisateurs et le support nécessaire
Les outils standard de navigation et de messagerie tels que Internet Explorer et Outlook ont de nombreuses lacunes. Ils n’incluent pas certaines fonctionnalités. La double signature, pratique courante avec les documents papier, n’est pas disponible dans ces logiciels. Ils sont aussi complexes à utiliser, souvent mal documentés, avec une logique difficile à comprendre pour un utilisateur non expert. Lors de l’installation de son certificat celui-ci doit ainsi cliquer de très nombreuses fois sur « OK » sans savoir vraiment ce qui se passe. En dernier point, l’architecture et les interfaces logicielles de ces produits sont peu, voire pas du tout, documentées, rendant sceptique, avec raison, sur la confiance que l’on peut avoir dans leurs fonctions de sécurité.
Mais ce manque de confiance peut être général. Est-on sûr que les systèmes tels que Windows ou les programmes comme Word n’ont pas des portes dérobées, qu’ils sont fiables ?
Ces imperfections imposent obligatoirement de mettre en place des formations pour les utilisateurs ainsi qu’un système d’assistance en temps réel performant. C’est impératif et malheureusement très coûteux.
Les certificats électroniques ne sont que des outils limités
Lorsqu’une nouvelle technologie arrive, on pense qu’elle va résoudre tous les problèmes. Les certificats n’ont pas fait exception.
Dans les services de sécurité, ils ne vont pas éliminer les attaques internet par exemple. Ils peuvent seulement permettre de mieux y faire face, en mettant en place des accès mieux contrôlés.
Un autre constat est que ce ne sont que des outils. Ils ne vont pas résoudre, par leur simple utilisation, les incohérences d’une organisation.
Certains voyaient la mise en place d’une IGC comme une manière de tout réorganiser, de tout remettre à plat dans une organisation. C’est certainement le bon moment pour réfléchir à des changements organisationnels mais il ne faut pas que cela devienne l’objectif du projet. Il est préférable d’avoir un autre projet en parallèle, légèrement décalé dans le temps, dont le but est de réfléchir aux évolutions de l’organisation et des procédures de gestion.
Un autre acteur dans le système est l’utilisateur qui reste le même. Il ne faut pas penser qu’un certificat va changer complètement certains utilisateurs avec leur laxisme, voire leur irresponsabilité… tels que les perçoivent les responsables de la sécurité. Il faut évidemment beaucoup sensibiliser les utilisateurs au secret de leur clé privée dans toute mise en
place d’IGC, les former et essayer de leur rendre plus facile la conservation de ce secret. Mais ils restent libres de le faire ou non. Il faut en être conscient et l’accepter. Changer les utilisateurs ne doit pas être l’objectif de l’IGC.
Quelques réflexions
L’œuf et la poule
Actuellement, on se heurte au classique problème de la poule et de l’œuf.
Pour investir dans une IGC, il faut des applications qui utilisent les certificats. Mais pour créer et déployer ces applications, il faut disposer de certificats. C’est une situation que l’on a beaucoup connue au début des réseaux informatiques où on ne voulait pas augmenter la taille des tuyaux car il n’y avait pas d’applications pour les remplir, et il n’y avait pas d’applications consommatrices conçues car les bandes passantes disponibles étaient insuffisantes pour qu’elles puissent être testées et validées. Ce qui a débloqué cette situation est certainement une volonté politique, à tous les niveaux, de financer les réseaux nationaux, régionaux et métropolitains de l’enseignement et de la recherche. Les tuyaux étant là, les applications ont été créées, testées et déployées. Actuellement, pour une entreprise, un organisme ou un ministère, miser sur une IGC c’est parier sur cette technologie, sans un retour sur investissement à court terme. D’où la frilosité de beaucoup, que l’on comprend. On peut néanmoins s’apercevoir qu’en Europe le déploiement des certificats s’accélère dans tous les pays et l’effet boule de neige est peut-être proche. Lorsque ce sera un signe de modernisme d’afficher son certificat, comme d’avoir une adresse électronique à une époque, le pas sera franchi.
La confiance
Ce système, comme tout système de sécurité, repose sur la confiance. A un moment il faut décider de faire confiance à quelque chose, à quelqu’un.
Dans une IGC, on fait confiance ou non, à une autorité de certification. Sur quoi se baser pour prendre cette décision ? Théoriquement sur la politique de certification de l’autorité de certification. Mais chaque utilisateur ne va pas lire cet épais document. Il s’en remettra à ses impressions, à l’idée de sérieux ou non de l’autorité de certification pour décider. Ce n’est pas catastrophique comme approche, c’est ce que chacun fait dans la vie. De plus, la possible arborescence-hiérarchie des autorités de certification permet de limiter ce type de question. En effet, la confiance dans une racine s’étend automatiquement à toutes les branches. La DCSSI a ainsi créé une autorité
de certification IGC-A, A comme Administration, qui peut signer les certificats des autorités de certification des ministères et des organismes publics. Un utilisateur pourra décider de faire confiance à IGC-A, de là il fera confiance à l’ensemble des IGC de l’administration française, si ces IGC sont reconnues par la DCSSI.
Le danger ne vient pas de là. Il est en fait la conséquence cumulée de la complète libéralisation du marché de la certification, c’est un secteur commercial comme un autre, n’importe quelle entreprise peut s’intituler autorité de certification et créer des certificats, et des monopoles en place dans l’informatique. Ainsi lorsque vous utilisez Internet Explorer, cet outil est déjà configuré pour faire confiance à plusieurs dizaines d’autorités de certification. Si vous voulez rester un citoyen libre vous devriez détruire à la main tous ces éléments de confiance, pour ensuite rajouter les autorités auxquelles vous faites confiance, comme IGC-A ou CNRS. Cela demande une bonne connaissance du domaine. Evidemment si le CNRS payait une somme conséquente, Microsoft ajouterait l’autorité de certification CNRS dans Internet Explorer. Ceci est un exemple, ce n’est pas un a priori contre cette société.
Un autre problème délicat provient de l’absence d’une arborescence mondiale des autorités de certification. Il n’y a pas de racine mondiale – c’est peut-être mieux ainsi d’ailleurs. Dans cette situation, comment deux entités qui ont chacune leur autorité de certification, deux sociétés commerciales par exemple, peuvent chacune faire confiance aux certificats émis par l’autre ? C’est la question de l’interopérabilité des IGC. Sans parler du modèle hiérarchique, il y a plusieurs solutions après l’étude comparée des politiques de certification : un accord de reconnaissance mutuelle, la certification croisée (chaque autorité délivre un certificat à l’autre), une autorité de certification pivot (bridge) qui « interconnecte » les autorités de certification. Sans entrer dans les détails, ces différentes techniques sont complexes à mettre en place dans le monde réel. Mais, il n’y a pas encore aujourd’hui de nombreux besoins de ce type. Pour faire un parallèle, l’internet n’a pas commencé par créer des GIX (Global Internet eXchange), lieux d’échanges des opérateurs internet. Il s’est d’abord développé par la connexion des stations sur des réseaux locaux, l’attribution des adresses et des noms... Dans le domaine des IGC, il n’est pas urgent d’essayer de répondre à ces problèmes d’interconnexion avant d’avoir résolu celui de la diffusion et de l’utilisation des certificats à et par une majorité de personnes.
Un certificat unique pour chaque citoyen ?
Ce problème de reconnaissance entre autorités de certification vient de la multiplicité de celles-ci. Une solution proposée par certains, qui réduirait ces problèmes d’interconnexion et aussi les coûts induits par les IGC, est d’avoir un certificat électronique délivré par l’état, unique pour chaque citoyen et qui soit reconnu partout, dans la vie professionnelle aussi bien que privée.
C’est en fait la carte d’identité électronique. Un déploiement est déjà en phase pilote en Belgique pour délivrer des cartes d’identité qui contiennent un certificat électronique. Pour arriver à ce résultat il faut un investissement financier très important au niveau national mais on peut penser que c’est un système techniquement très rentable pour tous à moyen terme. Par contre, la question de la liberté individuelle et les dérives possibles dans le pistage des citoyens dans leur vie se posent. En effet si ce certificat est utilisé partout (travail, banques, hôtels, spectacles...), il sera très simple de suivre toutes les actions des citoyens. Il semble donc déraisonnable d’attendre la carte d’identité électronique française pour bénéficier de certificats électroniques.
Les droits d’accès
Le certificat électronique tel que décrit ici est un certificat d’authentification qui contient uniquement des informations d’identité (prénom, nom, adresse électronique, nom du laboratoire dans le cas du CNRS). Il ne contient pas d’information sur le rôle de la personne (est-elle directeur de laboratoire ?...), sur ses droits (a-t-elle l’autorisation d’effectuer des commandes ?...). C’est le cas dans toutes les IGC. Or, les applications serveurs ont besoin de ces dernières informations pour décider des droits de la personne qui se présente avec son certificat. Il faut donc des mécanismes et un référentiel pour gérer ces autorisations et ces rôles. Ce peut être chaque application qui tient à jour la liste des utilisateurs avec leur fonction. Une autre solution est d’avoir un annuaire central qui regroupe ces informations, annuaire qu’il faut bien sécuriser. La troisième, moins connue et pas répandue, est d’utiliser des certificats de privilèges. Similaires aux certificats décrits dans cet article, ils contiennent le ou les rôles des utilisateurs avec des autorisations ainsi que le condensé de leur certificat d’authentification. Un utilisateur peut avoir autant de certificats de privilèges que d’autorisations ou de rôles. Ces certificats sont présentés par les utilisateurs lorsqu’ils se connectent sur un serveur ou sont stockés dans des annuaires consultés par les serveurs. Ces certificats sont signés par une autorité. Ils peuvent avoir des durées de validité très différentes, quelques heures pour un certificat de visiteur donnant accès au site d’une entreprise, quatre ans pour un certificat de directeur de laboratoire (c’est la durée du mandat) par exemple.
Pourquoi ne pas inclure ces informations dans le certificat d’authentification ? Pour deux raisons principales. La durée de validité, comme dans les exemples précédents, des deux types de certificat est très différente. Cumuler les informations conduirait à avoir des certificat d’identité de durée de vie très courte et à les révoquer très souvent. La seconde raison est que les personnes qui peuvent vérifier les informations (les autorités d’enregistrement) sont différentes. En effet, le CNRS peut déléguer à un directeur de laboratoire (l’autorité d’enregistrement de l’IGC CNRS pour le laboratoire) le pouvoir de valider les certificats d’identité du personnel de son laboratoire, mais il ne peut pas lui donner le pouvoir de se
« désigner » directeur, d’octroyer des délégations de signature pour les commandes... Ce sont d’autres autorités d’enregistrement qui doivent avoir ce pouvoir.
Et ces nouveaux certificats, les certificats de privilèges (aussi nommés certificats d’attributs) nécessitent de déployer... une IGP, infrastructure de gestion des privilèges.
Un système hiérarchique
Le principe arborescent des IGC est conçu pour des systèmes organisés, pyramidaux qui convient bien aux entreprises. Ce n’est pas un système pour des communications informelles, entre groupes d’amis, non structurés. C’est une vision entreprise qui n’est pas forcément la meilleure pour les activités en temps que citoyen dans sa vie sociale.
En guise de conclusion
Y a-t-il une autre solution à court terme ?
Les certificats électroniques et les infrastructures de gestion de clés sont très souvent décriés ; le principal reproche est leur lourdeur. C’est exact.
Mais si on veut amener les fonctions de sécurité de base (authentification, intégrité, confidentialité) à l’ensemble des utilisateurs de l’internet, y a-t-il une autre alternative ? Non, la seule réponse est d’utiliser la cryptographie asymétrique, donc des clés publiques, donc des certificats, donc des IGC.
C’est d’ailleurs une grande chance d’avoir une solution technique à ce besoin de sécurité à si grande échelle. Et lorsque le principe consiste à diffuser une information publique (le certificat) pour avoir des communications confidentielles, on a même de quoi trouver cela magique !
Les services de sécurité sont-ils obligatoires pour tous ?
Par contre, on peut se demander si l’on a effectivement besoin de fonctions de sécurité pour tous les internautes, face au coût à payer. Des solutions alternatives peuvent être de segmenter l’internet à différents niveaux, en groupes d’utilisateurs homogènes, en types d’applications, en sous-réseaux (physiques ou logiques, c’est ce que font les VPN, Virtual Private Networks)... protégés et étanches entre eux, et si besoin d’amener des fonctions de sécurité dans certains sous-ensembles, éventuellement avec des solutions techniques différentes. L’internet dans sa globalité restera alors sans sécurité. C’est une évolution possible.
L’internet, toujours l’internet
Est-ce que les IGC et les certificats vont se généraliser, rester dans quelques niches ou disparaître ? Malgré l’orientation de cet article en faveur des IGC, rien n’est joué. Ce sont des solutions complexes, lourdes et chères.
L’évaluation des points forts et faibles de ces techniques peut permettre d’avancer quelques prévisions, mais il est nécessaire de rester prudent et modeste. D’un côté il peut y avoir des découvertes qui engendrent de nouvelles techniques rendant obsolètes les certificats. Mais la réponse dépend surtout du futur de l’internet, plus globalement des réseaux de communication. Comment vont évoluer ces réseaux en termes de pilotage, d’architecture, d’utilisations, de contrôles... et de malveillances ? Selon ces évolutions, les IGC peuvent devenir incontournables ou inutiles.
