=========================================== Réunion OSSIR groupe sécurité Windows Lundi 2 juin 2003 =========================================== Ordre du jour : 1-Utilisation de l'IGC du CNRS dans le Système d'information régional (Roland DIRLEWANGER / CNRS) 2-Travail collaboratif et signature électronique (Michel MIQUEU / CERT-IST) 3- Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== 1 - Utilisation de l'IGC du CNRS dans le Système d'information régional (Roland DIRLEWANGER / CNRS) ==================================================== Le contexte du CNRS est particulier sur plusieurs points : - Forte déconcentration des laboratoires (plus de 1000 sites) - Nombreuses associations avec des partenaires (le personnel CNRS dans un labo peut représenter moins de 5%) - Informatique des laboratoires non maitrisée par le CNRS et très hétérogène Les principaux besoins identifiés des personnels CNRS sont : - Consulter l'Extranet (procédures administratives en ligne) - Accéder à la messagerie - Echanger du courrier sécurisé ... et ce en toute sécurité, depuis n'importe quel laboratoire, quel que soit le contexte informatique local. Suite aux Journées Réseaux de l'Enseignement Supérieur de 1999, l'idée à germé de lancer un chantier d'étude sur les infrastructures de gestion de clés (IGC), aussi appellées PKI (Public Key Infrastructure) ou ICP (Infrastructure à Clés Publiques). Des solutions "clé en main" existent, à titre d'exemple un grand opérateur de certification propose un tarif de 100 KF (15000 euros) pour 300 à 500 certificats (soit 30 à 50 euros par certificat), puis 80KF (12000 euros) par an (chiffres avril 2001). Toutefois cette solution n'a pas été retenue, pour des raisons économiques (coût), politiques (indépendance nationale) et techniques (maitrise de l'AE). Le CNRS s'est donc orienté vers un développement spécifique basé sur OpenCA représentant un investissement de 1 an-homme. Le produit final est en license OpenSource, disponible auprès du CNRS sur demande. Les choix issus de la préétude sont les suivants : - Génération du biclé par les utilisateurs - IGC de niveau national - AEs régionales et locales "au plus près" des utilisateurs Ce projet a abouti à la distribution de 1 000 à 1 500 certificats, dont certains ont été renouvelés deux ou trois fois. Le nombre d'utilisateurs potentiels dans les labos du CNRS est d'environ 80000, dont 26000 agents CNRS et 54000 d'autres tutelles. En pratique, l'IGC vise à diffuser 4 à 5 certificats par laboratoire, soit moins de 10000 certificats. Quelques enseignements techniques/organisationnels notables issus du projet sont : - Nombreuses implémentations parfois incompatibles dans les produits du marché. Ex. fonction JavaScript crypto.signtext() inexistante sur IE et Netscape 6+. - On constate un taux d'inversion nom/prénom de 30% dans les formulaires saisis par les utilisateurs ... - L'AE doit avoir des notions d'informatique pour offrir du support utilisateur. - La mise en place d'une authentification sur le relai SMTP permet de l'ouvrir à l'extérieur. => la sécurité offre un nouveau service aux utilisateurs ! - La signature électronique est peu utilisée car difficile à mettre en pratique (celui qui prépare n'est pas celui qui signe, signatures multiples non gérée, incompatibilité des mails "forwardés" entre MUA différents, etc.). - Il est nécessaire d'utiliser un gestionnaire de profil, car cette notion n'apparait pas dans le certificat. Le CNRS réalise cette opération avec une appli PHP. Les évolutions probables du projet sont : - Rédaction d'une DPC au format RFC 2527. - Signature de l'autorité racine pour l'IGC-A (en cours de mise en place par la DCSSI, dont le rôle est de signer toutes les autorités racine des organismes publics). Remarque : les boitiers "Confidence" de SAGEM se révèlent poser de nombreux problèmes de compatibilité. Q. Les messageries Lotus sont-elles supportées ? R. Pas de retour d'expérience mais aucun obstacle technique identifié. Q. Coût total de la solution ? R. Difficile car que faut-il faire rentrer dans le coût ? Le coût environné du développement uniquement serait de 100 000 € donc un certificat à 50 € actuellement, ce qui reste compétitif. Q. Des solutions de stockage matériel sont-elles supportées ? R. Le stockage des clés est uniquement logiciel pour le moment. Des tokens USB/cartes pourraient facilement être mis en oeuvre, mais plusieurs problèmes se posent : - Droits nécessaires pour installer les drivers - Incompatibilité avec les versions de Windows pre-Windows 2000 Q. Qui installe le certificat racine sur les postes ? R. En général l'AE (=> compétences informatiques requises). Q. Le certificat de l'IGC-A sera-t-il intégré à IE ? R. Mozilla demande 150 000 $, Microsoft probablement autant. Cette solution ne sera donc probablement pas retenue. Q. Quelle est la durée de validité des certificats ? R. Le changement d'AC est très mal supporté par tous les logiciels, des durées très longues ont donc été choisies. Actuellement : CNRS root -> 20 ans CNRS+, CNRS std -> 10 ans Utilisateurs -> 1 an avec renouvellement quasi transparent Q. Des certiificats avec délégation d'attributs sont-ils mis en oeuvre ? R. Non. Q. Les listes de révocation sont-elles supportées ? R. Oui mais le problème se pose au niveau du client. ==================================================== 2 - Travail collaboratif et signature électronique (Michel MIQUEU / CERT-IST) ==================================================== Dans le cadre du projet EISPP (European Information Security Promotion Program, http://www.eispp.org/), financé par le 5ème PCRD, un consortium regroupant le CERT-IST, le CERT-Siemens, esCERT, le CLUSIT et d'autres partenaires européens s'est monté afin de travailler sur les 2 objectifs suivants : - Etablir une coopération entre les CERTs européens - Proposer des services de sécurité aux PME Ce travail collaboratif a été l'occasion de mettre en place une solution de sécurisation du "workflow". L'outil retenu est PGP/GPG. Un responsable technique est désigné pour chaque lot - son rôle est d'approuver les documents électroniques au format Word. Cette approbation s'effectue par le biais d'une signature détachée, cette dernière est générée par le coordinateur et signée par les autres partenaires. Cette solution simple a néanmoins mis en lumière de nombreux problèmes de mise en oeuvre : - A la fin du processus, le document original qui doit être livré doit refléter que le processus de signature a été accompli, et donc être modifié si le client n’est pas partie prenante du processus de signature. - On ne peut pas réellement considérer PGP comme un standard. - Seul PGP/GPG permet de signer des fichiers tiers. Aucune solution basée sur des certificats X.509 n'a été trouvée. - Il existe dans PGP une notion de clé partagée qui pourrait permettre de s’assurer qu’un document a été signé par tous. Le processus de génération de ce type de clé ne semble pas évident : il faut organiser une "signing party" où tous les intervenants se rencontrent physiquement. A noter que le CERT-IST migre d'une solution PGP vers une solution X.509 afin d’essayer de réutiliser les certificats (tels TéléTVA) déjà utilisés par les PME. Q. Pourquoi avoir choisi de signer du Word, alors que le contenu d'un document peut être sujet à des modifications intempestives (mise à jour de champs, etc.) ? R. On signe un fichier, quel que soit l’outil qui a servi à le générer, et la signature est détachée. Q. Quels ont été les problèmes de compatibilité rencontrés ? R. Le seul problème rencontré a été lié à PGP 8 qui ne permet pas de signer un fichier de signature. A noter que les participants utilisaient, pour la plupart, les versions commerciales de PGP. Q. Quelle est la valeur légale de cette signature ? R. La valeur légale vis-à-vis du client n'était pas un objectif - il s'agissait d'un mécanisme interne au consortium. A priori toutefois cette signature pourrait servir d'élément de preuve. ==================================================== 3 - Revue mensuelle des vulnérabilités Windows (Nicolas RUFF / EdelWeb) ==================================================== Les vulnérabilités les plus récentes des environnements Windows sont passées en revue. La base "OSWIN" (nom provisoire) est également présentée. Cette base de vulnérabilités Windows "donnée" à l'OSSIR et hébergée par EdelWeb suite à un appel d'offres est désormais opérationnelle. Elle est ouverte pour revue aux membres du CA et devrait être ouverte au public le 7 juillet. Son contenu est alimenté par les réunions mensuelles du groupe. La prochaine réunion du groupe est fixée au lundi 7 juillet 2003. Le groupe est ouvert à toute proposition d'intervention et/ou d'hébergement.