21, rue d'artois, F-75008 Paris http://www.cigre.org D2-106 Session 2004 CIGRÉ SECURISATION DES ACCES AU SYSTEME D INFORMATION DE RTE PAR CERTIFICATS NUMERIQUES Vincent GAUGE* Marc BERRIER Colette RODIONOFF (France) RESUME Le Gestionnaire du Réseau de Transport d'electricité français (RTE) expérimente aujourd'hui une solution de sécurisation de son portail d'échange avec ses clients basée sur une technologie de cryptographie à clés asymétriques dite Infrastructure de Gestion de Clés. Ce document décrit les besoins de sécurité qui ont amené à mettre en place cette infrastructure, la conduite du projet de mise en œuvre, et les technologies mises en jeu. Mots clés : IGC, certificats numériques, cryptographie, accès au SI, sécurité, retour d expérience. PRESENTATION DE RTE La mise en place de l'europe de l'électricité a révélé le rôle central que tiennent les réseaux de transport d'électricité dans la réussite d'un véritable marché intérieur. En France, RTE est né le 1 er juillet 2000 de l'exigence de disposer, pour la gestion du réseau de transport de l'électricité, d'une entité responsable identifiée, indépendante, capable de faire fonctionner le système électrique de manière sûre et d'en garantir l'accès pour tous ses clients. Placé sous le contrôle de la Commission de Régulation de l'énergie (CRE), RTE assure une mission de service public, vend ses prestations, équilibre ses comptes et rémunère les capitaux engagés. Son personnel est animé par le souci de l'intérêt général et est conscient de la responsabilité de son entreprise dans l'aménagement et le développement du territoire. Les chiffres suivants permettent de situer RTE : plus de 500 milliards de kwh d'énergie brute transportée par an, 100 000 km de lignes, dont 47% de lignes à très haute tension (225 et 400 kv), 53% de lignes haute tension (63 et 90 kv),
600 postes de transformation, 2 440 postes de livraison, plus de 8 000 personnes. LE PROJET FRONT-OFFICE Les échanges de données relevant du métier, entre RTE et l'externe, sont amenés à s'amplifier, du fait notamment de l'accès d'un nombre croissant de clients au réseau de transport d'électricité et de la mise en œuvre de services nouveaux. Le Système d'information de RTE a pour vocation d'accompagner ces évolutions, sans discrimination vis-à-vis des clients externes, en assurant la confidentialité, la traçabilité, la sécurité et la fiabilité des échanges. Le Front Office est un Système d'information dédié aux services que RTE propose aux acteurs du métier. Par les fonctions mutualisées qu'il offrira aux applications métiers (authentification, chiffrement, horodatage, contrôle d'accès, détection anti-virale, surveillance etc.), il est destiné à devenir le point de contact privilégié de RTE avec les clients de ces applications, pour lesquels il doit faciliter le raccordement informatique, en limitant autant que possible les contraintes particulières. A priori, tous les échanges informatisés de données, contractuels ou protocolaires, avec les acteurs du marché de l'électricité (ou autrement dit, les échanges relevant du métier) devront utiliser le Front Office, comme l'illustre le schéma ci-dessous. Accès nomade Accès t élémaintenace Achat et e-procurement Sociét és tierces, fournisseurs, etc. Back Office HTTP et messagerie à usage général RTE Web instit ut ionnel : rte-france.com Front Office Echanges métier, cont ractuels ou protocolaires Acteurs du marché de l électricité POURQUOI UNE NOUVELLE INFRASTRUCTURE DE SECURITE POUR RTE? Dans le cadre de ses missions de modernisation et de développement du service public de l'électricité, RTE a besoin d'optimiser ses processus d'échanges avec sa clientèle. Cette optimisation passe par la dématérialisation de nombreuses procédures administratives et commerciales. De nouveaux besoins de sécurité apparaissent. Il ne suffit plus de vérifier l'identité d'un individu ou de garantir qu'une information ne peut être accessible qu'aux personnes habilitées. Il convient désormais également de s'assurer que d'une part les données n'ont pas été modifiées par un tiers et d'autre part qu'une organisation ou qu'un individu impliqué dans un échange ne puisse nier son rôle dans l'échange.
La sécurité associée à l ouverture des échanges sur Internet, vient s'ajouter aux besoins plus classiques de sécurisation d'accès au Système d'information de l'entreprise. Limites du système existant Jusqu'à présent, la carte SecurID était utilisée pour permettre aux utilisateurs d'accéder au Système d'information (SI) de RTE. Or, cette carte assure uniquement une authentification forte au réseau d'accès mais ne garantit pas formellement la confidentialité des données au sens de la loi du 10 février 2000 de transposition de la directive européenne relative au marché de l'électricité. Avec la carte SecurID, le client bénéficie d'une bonne protection vis à vis de l'extérieur. Par contre au sein de la communauté des utilisateurs, l'authentification et la confidentialité sont des services vulnérables car il peut y avoir des consultations illicites (usurpation d'identité, altération des données) et, d'une manière générale, l'intégrité des données n'est pas garantie. Une solution adaptée RTE s est engagé envers la CRE à mettre en place un moyen de sécurisation des échanges plus souple et apte à supporter les exigences liées aux évolutions des besoins de confidentialité, et de faire de la mise en place des «certificats PKI» un objectif prioritaire. Une PKI (Public Key Infrastructure), ou Infrastructure de Gestion de Clés (IGC), offre un cadre cohérent et homogène répondant à ces besoins de sécurité : l authentification : identifie les parties de manière sûre et certaine la confidentialité : assure que seul le destinataire peut avoir accès aux données envoyées l intégrité : assure que des données n'ont pas été modifiées la non répudiation : il est impossible pour une partie de réfuter son rôle dans l'échange et/ou dans la teneur de cet échange Les utilisateurs physiques (les personnes) ou logiques (les applications) des services d'une IGC sont identifiés par une pièce d'identité numérique appelée certificat numérique ou, plus simplement, certificat. Dans le cas de RTE, les certificats numériques des personnes sont délivrés sur des cartes à puce. Une IGC est constituée de l'ensemble des composants techniques, ressources, organisation et politiques de sécurité nécessaires à la gestion du cycle de vie et à l'exploitation des certificats. LE PROJET D'IGC DE RTE Phases du projet Le projet d'igc conduit par RTE concerne uniquement la sécurisation des échanges avec les applications du Front Office destinées aux clients de RTE (c est-à-dire les utilisateurs externes à RTE). Ce projet ne prend pas en compte la sécurisation : des autres applications (Back Office, transport, etc.), des applications pour les agents internes de RTE. Le projet se décline en deux phases :
une phase pilote, qui s'est déroulée de février 2002 à décembre 2003, une phase cible, qui se déroule de mars 2003 à mars 2004. La phase pilote a permis : de s'approprier les concepts et de roder tous les rôles et responsabilités afférents à l'igc, de définir les limites des responsabilités de RTE et de ses clients dans le contrôle de la sécurité pour les intégrer au contrat d'accès au SI de RTE, de mener une phase d'expérimentation et d'intégration de cette technologie, de prouver la faisabilité technique de l'igc dans une utilisation réelle, d impliquer et de former les acteurs dans les choix qui seront faits pour l'igc cible, d affiner les besoins pour se rapprocher le plus possible de l'igc cible, de communiquer et de faire adopter ce concept aux différents acteurs du marché, de définir et négocier avec les entités impliquées l'organisation à mettre en place pour la gestion (gestion des clés, des droits, etc.), d intégrer le Retour d'expérience de la phase pilote, et notamment l'igcisation de l'application pilote (service de Publication d informations). Les objectifs de la phase cible sont : ajuster l'infrastructure de délivrance des certificats aux clients, définir et mettre en œuvre l'infrastructure destinée à accueillir les nouvelles applications de RTE IGCisées (dont une passerelle de chiffrement des courriels), fournir des guides (spécifications et cahiers de recette par type de service) aux applications souhaitant être IGCisées afin d'effectuer le développement correspondant. Organisation Les exigences que doit satisfaire l'igc sont formalisées dans une Politique de Certification (ou PC), et les mesures mises en œuvre pour répondre à ces exigences sont définies dans une Déclaration des Pratiques de Certification (ou DPC), conformément à [1]. La DPC décrit notamment les rôles et responsabilités des différentes parties, et les processus organisationnels mis en jeu par les différents composants de l'igc. L'organisme qui signe et délivre les certificats s'appelle une Autorité de Certification (AC). Les démarches pour obtenir la délivrance d'un certificat suivent des procédures d'enregistrement, qui permettent de conserver un niveau de confiance homogène entre tous les certificats délivrés par l'ac. Ces démarches sont menées auprès d'une Autorité d'enregistrement (AE), constituée : d'une Autorité d'enregistrement Locale (AEL) qui, au sein de RTE, constituent l interface entre les clients et l'igc, d'opérateurs, qui assurent la relation entre l'ael et l'ac, en saisissant notamment les demandes de certificats sur le serveur de l'ae.
Les serveurs de l'ae et de l'ac sont hébergés par un Prestataire de Services de Certification (PSC). Le PSC est également en charge de la personnalisation des cartes à puce : insertion des certificats et personnalisation graphique. La mise en œuvre d'une IGC exige de définir des processus organisationnels pour émettre et gérer le cycle de vie des certificats. Dans la phase pilote, le client devait lui même télécharger ses certificats dans sa carte à puce à partir d'un site Internet mis en place par RTE. Or, cette procédure était complexe pour les clients et ne permettait pas à RTE de contrôler le niveau de sécurité des certificats. Les processus de la phase pilote ont donc été revus afin de délivrer une carte à puce prête à l'emploi contenant déjà les certificats du client. La figure suivante illustre les processus organisationnels principaux et les interactions entre les entités concernées par l'igc de RTE. Le cycle de vie des certificats est décrit plus en détail en annexe. Prestataire de Services de Certification Serveurs d AC et d AE Atelier de personnalisation des cartes à puce Enregistrement technique des demandes 3 Envoi des certificat s 2 Front Office Applications 3 Envoi des cartes à puce contenant les certificats RTE Autorité d Enregistrement Autorité de Certification 1 Demandes de certificats Demandes de révocation Demandes d assistance 1 Client de RTE IGCisation des applications et de l'infrastructure Front Office Dans la phase pilote du projet, RTE a décidé de mener une expérimentation sur une seule application pour obtenir un retour d'expérience avant de généraliser cette solution. L'application retenue a développé le code nécessaire à l'utilisation de l'igc pour deux types de canaux : navigation (HTTP), messagerie (SMTP/POP3). L'effort d'igcisation des applications web de RTE s'est révélé raisonnable en terme de coût (deux à trois hommes.mois), mais il ne doit pas être négligé pour autant. Il est nécessaire d'offrir une expertise technique aux équipes de développement de ces applications. En effet, celles-ci ne possèdent généralement pas les compétences spécialisées nécessaires en interne.
Au cours de la phase cible, des services d'infrastructure tels qu'une passerelle de chiffrement ont été mis en place afin de limiter l'impact auprès des applications. Cette passerelle permet de chiffrer et de signer les messages à destination ou en provenance des clients de RTE. Selon les applications, les messages sont envoyés, soit sur des boîtes aux lettres hébergées par RTE, soit directement dans les boîtes aux lettres Internet des clients. Le choix du produit passerelle a répondu aux critères de sélection suivants : aucun impact sur les postes clients, minimisation de l'impact pour les applications, agrément par la DCSSI (conforme à la législation française), être un produit du marché. L objectif final est que les services offerts par la passerelle de chiffrement soient disponibles pour l ensemble des clients soit utilisés par l ensemble des applications de RTE. Migration des applications et des clients Toutes les applications et tous les clients ne peuvent pas être migrés en une seule fois. RTE a donc élaboré des scénarios de migration bâtis sur les principes suivants : IGCisation de toutes les applications de RTE, puis IGCisation des clients un par un. Ce scénario permet en effet d'impacter le moins (souvent) possible les clients de RTE. Il impose en revanche aux applications de gérer la cohabitation entre les clients IGCisés et les clients non IGCisés. Retour d'expérience Les IGC sont des infrastructures techniques simples : une boîte noire de fabrication de certificats et des interfaces d'accès à la boite noire (enregistrement, révocation, etc.). Toutefois, les projets de déploiement d'igc ne sont pas assurés de pérennité et d'efficacité. Certains écueils sont susceptibles de mettre en danger les projets, et les recommandations suivantes sont formulées : Le choix de mettre en place une IGC doit être une décision d'entreprise. Comme tout élément de sécurité, une IGC introduit des impacts pour les applications. Si l'igcisation des applications n'est pas une décision forte de l'entreprise tout entière, peu d'applications intégreront cette technologie (même si l'impact est le plus minime possible). Les pré-requis sur les environnements clients ne doivent pas être sous-estimés. Le projet d IGC de RTE a été complexifié par l hétérogénéité des environnements clients : système d'exploitation, configuration matérielle etc. Il est très difficile et très long d'imposer à une population d'utilisateurs dispersés un logiciel ou un nouveau matériel indispensable à la réalisation de l'authentification ou du chiffrement. Le déploiement implique beaucoup de support technique et l'utilisateur n'est pas forcément prêt à payer le prix de sa sécurité. La mise en place d'une IGC doit s'appuyer sur une société spécialisée dans cette technologie et possédant un réel retour d'expérience. Trop de sociétés affichent aujourd'hui «IGC» sur leur plaquette commerciale alors qu'elles n'ont réalisé que des maquettes.
CONCLUSION Le Front Office est un Système d'information dédié aux services que RTE propose aux tiers. Il est destiné à devenir le point de contact privilégié de RTE avec les clients de ces applications. Au-delà des fonctions de sécurité usuelles telles que la vérification de l'identité d'un individu et la confidentialité des données, les applications du Front Office imposent de nouvelles exigences en termes de sécurité : la garantie que d'une part les données n'ont pas été modifiées par un tiers et, d'autre part, qu'une organisation ou qu'un individu impliqué dans un échange ne puisse nier son rôle dans l'échange. Pour répondre à ces besoins, RTE a mis en place une Infrastructure de Gestion de Clés, qui offre un cadre de sécurité homogène adapté. Cette infrastructure simplifie l'accès du client aux services du Front Office, tout en assurant la sécurité des échanges, qui sont confidentiels du poste client jusqu'à l'application, infalsifiables, et tracés par l'application. De plus, cette infrastructure est adossée à un acteur reconnu dans les services de confiance, le Prestataire de Services de Certification. Cette entité externe garantit l'impartialité de RTE dans les échanges. Ainsi, l'igc de RTE permet d'assurer des services de sécurité adaptés aux besoins des applications du Front Office dans un contexte de marché ouvert remettant en cause la notion de «communauté de confiance». Cette IGC permet en particulier à RTE d'honorer ses obligations contractuelles et légales : RTE doit assurer un service fiable, RTE doit assurer la confidentialité des échanges et des données, RTE doit assurer la non discrimination entre les acteurs. ANNEXE : TECHNOLOGIES MISES EN ŒUVRE PAR LES PKI Cette annexe n'est pas une description exhaustive des technologies mises en œuvre par les IGC ; elle présente simplement quelques notions permettant d'en appréhender les concepts principaux. Cryptographie à clé publique La cryptographie à clé publique, aussi appelée cryptographie asymétrique, repose sur une paire de clés numériques appelée bi-clé : l'une des deux clés est appelée clé privée et constitue une information qui doit rester propre au signataire, l'autre clé est appelée clé publique et constitue une information publique. Les deux clés constituant le bi-clé sont mathématiquement liées, avec les propriétés suivantes : il est impossible de déterminer une clé à partir de l'autre clé, tout ce qui est chiffré avec une clé n'est déchiffrable qu'avec l'autre clé. Abcde fghij klmno pqrst uvwxy Priv #èhé \[@{f F(^fB 1fd~ A -$ù Pub Abcde fghij klmno pqrst uvwxy L'algorithme de chiffrement à clé publique le plus utilisé s'appelle RSA.
Certificats La figure suivante représente la structure d'un certificat minimal, selon le format le plus répandu, X.509v3 de l'itu-t [2]. Numéro de version du format du certificat Numéro de série du certificat Algorithme employé par l AC pour signer le certificat Nom de l AC qui a généré/signé le certificat Période de validité du certificat Nom du porteur du certificat Clé publique du porteur Algorithme à utiliser avec la clé publique Signature de l Autorité de Certification Cycle de vie des certificats L'AC est responsable de la création du certificat. Elle doit également gérer l'ensemble de son cycle de vie, notamment les fonctions de renouvellement et de révocation. La figure suivante détaille le processus de demande et de création des certificats pour un client de RTE. Client de RTE RTE Prestataire de Services de Certification Remplissage du dossier de demande de certificats Transmission de la demande Vérification de la recevabilité de la demande NON : not ificat ion de non-recevabilit é Enregistrement de la demande En voi lecteur de carte à puce Courriel de notification de création de la carte Génération des certificats Packag ing Courriel de notification de création de la carte Envoi carte à puce Envoi code PIN Attente pendant 24h A cceptation de la cart e à puce Notification d accept ation Prise en compte acceptat ion Ouverture de l accès aux applications du Front-Office La durée de vie des certificats émis par RTE est de deux ans, au-delà desquels les certificats sont inutilisables et doivent être renouvelés. Si la demande de renouvellement est effectuée alors que la période de validité du certificat précédent est expirée, le processus de demande est semblable à celui de la création d'un certificat.
Si la période de validité n'est pas encore échue, l'utilisateur peut utiliser son certificat en cours pour effectuer une nouvelle demande de certificat. L'AC établit alors un nouveau certificat avec ou sans période de recouvrement avec l'ancien certificat. Ce processus de renouvellement du certificat peut être soit manuel (demande à renouveler par l'utilisateur avant la fin de validité de son certificat), soit automatique. Pour se protéger contre les évolutions technologiques qui pourraient permettre de trouver la clé secrète, et permettre l'évolution de la solution technique conformément à l'état de l'art de la cryptographie, une durée de vie limitée est accordée aux bi-clés et, de facto, aux certificats associés. Par ailleurs, plusieurs événements peuvent nécessiter la mise en opposition du certificat parce qu'il n'est plus digne de confiance, par exemple : la compromission de la clé privée (elle a été portée à la connaissance d'un tiers), la perte de la clé privée, la nécessité de modifier des informations contenues dans le certificat (par exemple l'adresse de messagerie), Cette mise en opposition est appelée révocation et met un terme à la validité du certificat même si sa date de fin de validité n'est pas encore expirée. Pour tenir informés les utilisateurs d'une telle fin de validité prématurée, divers procédés peuvent être utilisés, et en particulier la publication d'une Liste de Certificats Révoqués (LCR) signée par l'ac. Cette liste noire des certificats est diffusée à intervalles réguliers via un dépôt (par exemple un annuaire LDAP ou un site web). BIBLIOGRAPHIE [1] Chokhani, S. et al., 2003. "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, IETF Network Working Group. [2] ITU-T, 2000. "Information technology Open systems interconnection The Directory: Public-key and attribute certificate frameworks", X.509.