Certification EAL2+ d'une Autorité de

Transcription

1 Innovative Security Technology 96 avenue du Général Leclerc Boulogne Billancourt ST40 Certification EAL2+ d'une Autorité de Vérification des Signatures Electroniques Yann Tourdot GI Semestre d'automne 2004 Période de stage : 15 Juillet Février 2005 Suiveur en entreprise : Tuan N'Guyen Suiveur UTBM : Amir Hajjam

2 Table des matières Avertissements... 3 Remerciements... 4 Glossaire... 5 Chapitre 1 Présentation de Kotio 1. Activités Historique des produits Le personnel Les concurrents Les clients Les actionnaires La sécurité dans l'entreprise Chapitre 2 Certification EAL2+ d'une AVSE 1 Qu'est-ce que la certification? Les enjeux de la certification Niveaux de certification Les différents niveaux de la certification Répartition des produits certifiés Documents à fournir pour le niveau EAL Le composant AVSE Notions générales de PKI Utilité de l'avse Vue fonctionnelle globale de l'avse Le coeur de l'avse Vue statique du coeur de l'application F.VERIFY.CERT F.VERIFY.SIGN F.VERIFY.XMLDSIG Test de l'avse Définition et objectif du test Les différents types de test Etapes du processus de test Méthodes et outils de test

3 6.5 Bilan des tests Conclusion Chapitre 3 Remplacement des composants de RSA-Security 1. Qu'est-ce que RSA-Security? Les enjeux du remplacement Analyse des modules clients existant Analyse des dépendances à RSA-Security Analyse des fonctionnalités de la librairie de sécurité Les critères de choix Les candidats potentiels Réalisation du prototype Test du prototype Caractéristiques finales du prototype Conclusion Chapitre 4 Intégration du chiffrement hybride dans les fichiers de preuves 1. Le chiffrement hybride Utilisation de la ScelloBox dans les Appels d'offre Publique Scénario de chiffrement Conclusion Bilan du stage Bibliographie

4 Remerciements Ce stage a été pour moi une expérience inoubliable, et a conforté mon projet de m'orienter dans le développement de logiciels de sécurité informatique. Je tiens à remercier Isabelle Angelo, PDG de Kotio, ainsi que Philippe million Rousseau, PDG adjoint, pour m'avoir proposé ce stage. Je sais que l'intervention de stagiaires dans les entreprises travaillant dans des milieux sensibles est bien souvent un obstacle. Je tiens à remercier également Tuan N'Guyen, directeur technique, pour m'avoir encadré et conseillé durant mon stage. Un grand merci à mon responsable de stage monsieur Amir Hajjam qui m'a encadré, et qui a fait le déplacement jusqu'à Paris pour suivre l'évolution de mon stage. Enfin, je remercie toute l'équipe de Kotio pour m'avoir accueilli chaleureusement et pour toujours avoir répondu à mes questions. -4-

5 Glossaire AC : Autorité de Certification AES : Advanced Encryption Standard AOP : Appel d'offre Publique AVSE : Autorité de Vérification des Signatures Electroniques CC : Critères Commun (Common Criteria) CESTI : Centre d'evaluation de la Sécurité des Technologies de l'information CRL : Certificate Revocation List DCSSI : Direction Centrale de la Sécurité des Systèmes d'information DLL : Dynamic Link Library EAL : Evaluation Assurance Level IE : Internet Explorer JUnit : Framework de tests unitaires pour Java PKCS : Public Key Cryptography Standard PKI : Public Key Infrastructure RSA : Rivest Shamir Adleman RSA-BSAFE : Gamme de produits cryptographiques commercialisés par la société américaine RSA-Security SHA1 : Secure Hash Algorithme 1 SSL : Secure Socket Layer X509 : Norme concernant les certificats numériques XML : Extensible Markup Language XMLDSIG : XML Digital Signature -5-

6 1.Activités Présentation de KOTIO Le domaine d'activité de KOTIO a toujours été basé sur la signature électronique et le chiffrement de données. KOTIO a commencé en développant des composants logiciels destinés à fournir des services d'authentification forte et de chiffrement au service de courrier électronique. Il s'est avéré que cette activité n'était pas assez rentable. Kotio s'est ensuite réorienté sur une activité de fournisseur de services en mode ASP (Application Service Provider). L'équipe technique s'est mobilisé sur l'écriture d'applications Web mettant destinées à fournir des services en lignes aux entreprises ayant des besoins de chiffrement et de signature électronique. Finalement, la démarche de KOTIO a convergé vers l'activité d'éditeur de composants logiciels destinés à être intégrés dans les dématérialisations de processus métiers ayant des besoins de signature électronique et de chiffrement. On trouvera en annexe 1.1, un article concernant Kotio, paru dans le magazine 01 Informatique 1. 2.Historique des produits La ScelloBox Le produit ScelloBox marque le virage qu'a pris KOTIO en passant de l'activité de fournisseur de service à l'activité d'éditeur de logiciel en mode licence. La ScelloBox est un serveur de gestion de preuves. Plus précisément, c'est un logiciel d'infrastructure permettant la mise en oeuvre et l'intégration de technologies de signature électronique et de chiffrement. Ce logiciel est en particulier pensé pour s'intégrer aux processus de dématérialisation où des besoins de signatures électroniques et de confidentialité se manifestent. Les données que traite la ScelloBox sont appelés des KTO. Ce sont des fichiers de preuves au format XML, plus précisément au format XMLDSIG. CommonBox L'application CommonBox est de moins en moins utilisée. La CommonBox se présentait comme un espace privatif d'échanges sécurisés. Les grandes lignes de ses fonctionnalités étaient : le dépôt signé ou non de documents la signature de documents déposés la gestion de circuits de signatures Chapitre Informatique, Février 2003, n

7 La CommonBox peut-être considérée comme l'ancêtre de la ScelloBox. WebSigning L'application WebSigning n'est plus commercialisée aujourd'hui, elle avait pour objectif de fournir un service de signature en ligne de documents. L'application de WebSigning permettait de présenter des formulaires référençant des fichiers de données. L'utilisateur pouvait consulter ces fichiers, et signer ce formulaire. L'application Web effectuait ensuite toutes les opérations de vérifications cryptographiques liées à la signature électronique du client. KotioMail L'application KotioMail n'est plus commercialisée aujourd'hui, elle était destinée à être intégrée à un serveur Domino/Lotus Notes. Elle permettait : la gestion de mails signés (authentifiés) la gestion d'accusés réception, éventuellement signés 3.Le personnel Kotio est une petite structure de 15 à 20 personnes. Fig 1.1 : Organigramme de la société PDG Isabelle Angelo PDG Adjoint Philippe million Rousseau Commercial Guy Albert Rouf Directeur Technique Tuan N'Guyen Développeur Certification Sécurité des Réseaux Stagiaire Cryptographie Hung Buik Sébastient Vincent Sylvain Meilard Yann Tourdot Développeur Certification Antoine Pineau Medhi Bouallagui Certification Pascal Ballanger Kotio fait appel à des consultants externes pour des tâches très spécifiques, c'est la raison pour laquelle le nombre d'employés de Kotio varie. En général Kotio compte en permanence un à deux consultants. -7-

8 Mon stage a commencé sous la responsabilité de Frédéric Tourand, puis s'est poursuivi sous celle de Tuan N'Guyen à partir du mois de septembre. Kotio a établi une grille des Critères d'attribution des primes. Cette grille établi les différentes modalités d'attribution d'une prime, ainsi que son montant selon le niveau de satisfaction. Cette politique de mérite a pour but de motiver le personnel. Les stagiaires sont également soumis à ce régime de primes. Durant mon stage j'ai pu ainsi obtenir deux primes de 300 bruts chacune. La grille d'attribution des primes est en annexe Les concurrents Bien que le marché de la dématérialisation soit en pleine expansion, Kotio n'a pas vraiment de concurrents. En effet il n'y a pas vraiment d'entreprises qui ont le même positionnement que KOTIO : éditeur de briques de sécurité. En revanche, il en existe plusieurs qui ont des activités s'appuyant sur la signature électronique. Parmi ces concurrents, on peut citer : ADESIUM Utimaco Atos Origin 5.Les clients Kotio dispose de nombreux clients, parmi les plus importants on peut citer : PeopleSoft : intégration aux modules existants Syntégra : portail de réponses aux appels d'offres publiques unilog : PATT effea : portail de réponses aux appels d'offres publiques 6.Les actionnaires L'actionnariat de KOTIO est structuré en quatre groupes : Les fondateurs et dirigeants Les autres actionnaires Les Business angels 2 Les investisseurs KOTIO a reçu un premier apport financier en juin 2000, lors de sa création, puis a fait l'objet de deux apports de fonds en décembre 2003 et en février Particuliers qui investissent leur propre argent dans une société -8-

9 Fig 1.2 : Evolution de la part des investisseurs dans Kotio 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Juin 2000 Décembre 2003 Février 2005 Légende : Investisseurs Businness Angels Autres Actionnaires Fondateurs et Dirigeants Parmi les investisseurs figurent trois sociétés : CDC-Kineon IRIS SGAM Filiale de la Caisse des dépôts et consignations dont l'objectif est le soutient aux entreprises innovantes. Elle se présente comme un accélérateur de projets en leur apportant des moyens, des financements et son expérience. IRIS est également une émanation de la Caisse de dépôts et consignations. C'est un capital tourné vers les entreprises européennes, mais qui investit également ponctuellement dans des entreprises nord-américaines. Les entreprises ciblées par cet investisseur appartiennent aux secteurs des médias, télécommunications et technologies de l'information. La SGAM (Société Générale Asset Management) est un fond d'investissement géré par la banque Société Générale. Elle a participé aux apports de fond à la création de la société en juin 2000 mais n'a pas pris part aux augmentations de capital

10 7.La sécurité dans l'entreprise La sécurité est au coeur de l'entreprise. Kotio met donc en avant ses infrastructures de sécurité pour convaincre le client. On distingue trois types de sécurité : 1. Sécurité des communications Authentification des correspondants : authentification forte de l'émetteur et des destinataires par signature numérique. Intégrité du message : à la réception, la procédure de vérification de la signature permet de s'assurer que le message transmis n'a pas été modifié pendant le transfert. Confidentialité des communications : les communications entre l'émetteur et Kotio, entre Kotio et les destinataires sont systématiquement cryptées par SSL, procurant le même niveau de confidentialité que les transactions financières. Non répudiation à l'émission : par signature horodatée de l'émetteur, ce dernier ne pourra plus nier ultérieurement avoir envoyé un message à telle heure. Non répudiation à la réception : par signature horodatée du destinataire constituant un accusé de réception. Ce dernier ne pourra plus nier ultérieurement avoir reçu un message ou un document à telle heure. 2. Sécurité physique des données Alimentation électrique sans coupure : il existe deux arrivées de courant distinctes et indépendantes. Les onduleurs sont supervisés 24h/24, 7j/7 et disposent d'une autonomie de 30 minutes. Des groupes électrogènes préchauffés en permanence assurent une autonomie de fonctionnement d'au moins 72 heures. Climatisation : Le centre d'hébergement de Kotio est équipé de systèmes de climatisation et de purification d'air. La régulation thermique et hygrométrique de la salle d'hébergement est assurée par des unités redondantes garantissant une température ambiante constante de 20 C (+/- 2) et une humidité relative de 50% (+/- 10 %) Sécurité incendie : L'extinction du feu se fait par absorption d'oxygène grâce à la diffusion d'un gaz inerte non destructif pour les équipements hébergés. 3. Sécurité réseau des données Protection contre les attaques par l'internet : Kotio dispose d'une équipe technique qualifiée ayant totalement sécurisé les plate-formes serveurs. Protection des clés privées : Les clés privées utilisées par Kotio sont sauvegardées et stockées dans un module hardware résistant aux intrusions, certifiés à la norme FIPS niveau

11 Chapitre 2 Certification EAL2+ d'une AVSE 1.Qu'est- ce que la certification? La certification a pour objectif de permettre à toute entreprise de faire certifier des produits ou des systèmes relatifs aux technologies de l'information, en terme de confidentialité, de sécurité La mise en oeuvre de l'évaluation est confiée à la Direction Centrale de la Sécurité des Systèmes d'information (DCSSI). La DCSSI est une agence dépendant du Ministère de la Défense Nationale. En tant qu'organisme de certification, la DCSSI procède à la délivrance des certificats. Les évaluations sont réalisées par les Centres d'evaluation de la Sécurité des Technologies de l'information (CESTI). Les CESTI sont agréés par la DCSSI. Au terme de l'évaluation, le CESTI rédige un rapport technique d'évaluation remis à l'entreprise évaluée et à la DCSSI. La DCSSI délivre ensuite ou non le certificat attestant que le produit a été certifié. Le processus de certification est un processus qui peut être long (plusieurs années), et dépend du niveau de certification. Fig 3.1 : Les étapes d'une certification DCSSI Suivi des évaluations et certification agrée CESTI Conduite de l'évaluation de la sécurité des produits certifie Référentiel de certification évalue Commanditaire Initialisation et financement de l'évaluation Au 1er Janvier 2005, la DCSSI n'a que 6 CESTI agréés 3, le nôtre étant la société Algoriel. Chaque CESTI

12 dispose de son propre domaine de compétence : cartes à puces, firewall,... La répartition des certificats attribués selon le type de prouits certifiés est disponible en annexe 2.1, intitulée Répartition des produits certifiés. 2. Les enjeux de la certification La certification peut être un processus long et coûteux pour les entreprises d'une part, et d'autre part le résultat n'est pas garanti. Les principales raisons d'une certification sont : 1. Marketing : La certification est avant tout un avantage commercial. Un client préfèrera toujours utilisé une application certifiée, même s'il devra la payer un peu plus cher. 2. L'inversion de la charge de la preuve : Dans le cadre d'un litige opposant l'utilisateur et le créateur de l'application certifiée, c'est désormais à l'utilisateur d'apporter les preuves du litige et de démontrer que l'application n'a pas répondu conformément aux spécifications. 3. L'administration française : Les applications utilisées par l'administration française doivent obligatoirement être certifiées. Le marché de l'administration française est donc ouvert aux sociétés qui certifient leurs applications. 4. Une reconnaissance internationale : La DCSSI a passé des accords avec de nombreux pays pour une reconnaissance mutuelle des produits certifiés (jusqu à un certain niveau de confiance) : Allemagne, Etats-Unis, Japon, Canada,... 3.Niveaux de certification 3.1Les différents niveaux de certification Il existe en tout 7 niveaux de certification, appelés en anglais Evaluation Assurance Levels (EAL), définis dans les Critères Communs. Le niveau de certification le plus bas étant EAL1, le plus haut EAL7. Fig 3.2 : Caractéristiques des Niveaux de Confiance EAL -12-

13 Niveau d'assurance EAL7 : Formellement vérifié, conçu et testé EAL6 : Semi formellement vérifié, conçu et testé EAL5 : Semi formellement conçu et testé EAL4 : Méthodiquement conçu, testé et revu EAL3 : Méthodiquement testé et contrôlé EAL2 : Structurellement testé EAL1 : Fonctionnellement testé Secret Défense Confidentiel Défense Confidentiel Source : L'investissement en temps de recherche, conception, réalisation, et documentation augmente avec le niveau d'assurance désiré. Le volume des documents de certification augmente en général d'au moins 1/3 lors d'un niveau EAL au niveau EAL supérieur. Le niveau EAL7 est réservé au domaine militaire et nucléaire, les niveaux EAL4 à EAL6 sont essentiellement utilisés dans le domaine bancaire. Le niveau EAL4 est très utilisé (voir Fig 3.3), et est considéré comme le plus haut pour du logiciel. Les premiers niveaux sont généralement très marketing : on est certifié mais sans dire le niveau. Il existe des niveaux intermédiaires notés EALX+. Ces niveaux indiquent que certains documents fournis pour l'évaluation ont un niveau de confiance supérieur à celui demandé. Cela permet d'augmenter le niveau de sécurité sur un point particulier. 3.2Répartition des produits certifiés La liste des produits certifiés, ainsi que leur cible de sécurité respective est consultable sur le site de la DCSSI 4. Depuis 2001, date de création de la DCSSI, 90 produits ont été certifiés. Les domaines de certification sont : les micro-circuits, les cartes à puce, les produits réseau, les lecteurs/terminaux, les produits PC et les produits systèmes. Fig 3.3 : Certificats délivrés par la DCSSI au 1er Janvier 2005 Dans le cadre de mon stage, l'application devait être certifiée EAL2+ Source :

14 On constate que la DCSSI n'a jamais délivré de certificat EAL6 ou EAL7, les spécifications d'une telle application demanderaient énormément de temps (plusieurs années), de rigueur et de compétences très spécifiques. Les niveaux les plus prisés sont EAL3 et EAL4. 3.3Documents à fournir pour le niveau EAL2+ Pour chaque Niveau d'assurance, il existe un ensemble de documents à fournir. Le nom de ces documents, leur contenu et leur nombre sont définis selon une grille très stricte définie dans un ensemble de documents nommés Critères Communs 5 (CC). Ces documents sont volumineux et décrivent la méthodologie de rédaction d'un projet de certification.en France seul une dizaine de personnes maîtrisent parfaitement les CC. Dans le cadre de mon stage et de la certification EAL2+, voici la grille des documents nécessaires : Fig 3.4 : Liste des documents à fournir pour une certification EAL2+ Nom de la classe Classe ACM : Configuration management Classe ADO : Delivery and operation Class ADV: Development Class AGD: Guidance documents Class ATE: Tests Class AVA: Vulnerability assessment Nom du document ACM_CAP.2 Configuration items ADO_DEL.1 ADO_IGS.1 ADV_FSP.1 ADV_HLD.1 ADV_RCR.1 Intitulé du document Description Pages Delivery procedures Installation, generation, and startup procedures Informal functional specification Descriptive high-level design Informal correspondence demonstration AGD_ADM.1 Administrator guidance AGD_USR.1 ATE_COV.1 ATE_FUN.1 ATE_IND.2 AVA_SOF.1 AVA_VLA.2 User guidance Evidence of coverage Functional testing Independent testing - sample Strength of TOE security function Developer vulnerability analysis Détaille le processus de configuration pour le développement et la maintenance de l'application. Procédures de livraison et de packaging de l'application. Preuve de l'installation et de l'initialisation correcte des fonctions de sécurité. Liste des fonctions de sécurité, de leur APIs. Décomposition de l'application en soussystèmes. Modélisation UML. Fait la correspondance entre les différents documents de spécifications. Guide d'administration de l'application : lancement, maintenance, dépannage. Guide d'utilisation de l'application : Comment utiliser l'application. Preuve que les tests envisagés couvrent les fonctionnalités du périmètre de l'évaluation. Description de la totalité des cas de tests envisagés Doit prouver que les fonctions de sécurité répondent correctement.. Description extrêmement formalisée du périmètre de l'évaluation. Document en anglais. Analyse des vulnérabilités de l'application

15 Documents sous ma responsabilité 300 Document permettant de passer de EAL2 à EAL2+ Quel que soit le Niveau de Confiance, un dossier de certification comporte toujours 13 documents. La différence entre un dossier de niveau EALX et un dossier de niveau EALX+1 réside dans le contenu de ces documents. Pour chacun des 13 documents il existe plusieurs versions : par exemple il existe quatre versions du document Developer vulnerability analysis : AVA_VLA.1, AVA_VLA.2, AVA_VLA.3 et AVA_VLA.4. La version 1 est demandée jusqu'à EAL3, la version 2 est demandée pour EAL4, la version 3 est demandée pour EAL5 el la version 4 est demandée pour EAL6 et EAL7. La seule inclusion d'un document de Niveau de Confiance supérieur à celui demandé entraîne le niveau EAL+. Pour l'avse, le document Developer vulnerability analysis (AVA_VLA.1) était demandé pour une certification EAL2. Cependant nous avons décidé de fourni le document AVA_VLA.2 ce qui nous permet de prétendre au niveau de certification EAL2+. Le passage de EAL2 à EAL2+ représente avant tout un argument marketing. 4.Le composant AVSE 4.1Notions générales de PKI L'objectif de cette partie est de donner au lecteur les termes clés utilisés dans les PKI. Cette partie n'a pas pour but d'expliquer le fonctionnement d'une PKI, pour cela veuillez vous référer à l'annexe 2.2 intitulée Notions fondamentales d'une PKI ou au très bon livre Sécuriser ses échanges électroniques avec une PKI, Eyrolles, Thierry Autret, Laurent Bellefin, Marie-Laure Oble-Laffaire. Intégrité L'intégrité concerne la protection contre l'altération accidentelle ou volontaire d'un message émis. En réalité, il n'est pas possible d'empêcher la modification d'un message contre un acteur malveillant, en revanche on peut vérifier à tout moment s'il a été modifié ou non. Pour cela, l'émetteur réalise une empreinte numérique du message qu'il joint au message : le récepteur fait de même sur le message reçu et compare son résultat à l'empreinte de référence. L'opération cryptographique associé est le hash. Confidentialité La confidentialité a trait à la protection contre la consultation non autorisée des données stockées ou échangées. Dans le cadre des données échangées, seul le chiffrement est possible pour garantir la confidentialité. Pour cela, l'émetteur et le récepteur utilisent des algorithmes cryptographiques basés sur des techniques de mathématiques. L'opération cryptographique associée est le chiffrement. Non Répudiation L'explication simple de la notion de non répudiation consiste à apporter la preuve à l'un des participants d'un échange d'informations de son identité. Par exemple prouver à un interlocuteur qu'on est bien la personne que l'on prétend être. En réalité le terme de non répudiation n'est pas vraiment approprié car tout acte est contestable devant un juge. Une des opérations cryptographiques associée est la signature électronique. On parle également de -15-

16 signature numérique. Dans ce rapport j'utiliserai indifféremment ces deux termes. Signature numérique La signature numérique est un mécanisme qui contribue aux services d'authentification, d'intégrité et de non répudiation. La signature est réalisée en utilisant la clé privée du signataire, tous ses partenaires pouvant ainsi vérifier sa signature en utilisant sa clé publique. Certificat numérique Pour pouvoir utiliser une clé publique avec sécurité, il faut que le récepteur puisse répondre au moins à la question : A qui appartient cette clé publique? Pour cela, il faut que la clé publique soit accompagnée de d'informations descriptives de son propriétaire et que ces informations ne soient pas falsifiables. On peut donc considérer qu'un certificat numérique est une carte d'identité numérique du propriétaire de la clé. Pour visualiser les informations contenues dans un certificat numérique, veuillez vous reporter à l'annexe 2.3 intitulée Visualisation d'un certificat numérique. Horodateur L'horodateur est un composant de la PKI qui délivre des marques de temps sécurisés (protégées contre l'altération) sur des données qui lui sont présentées. L'horodateur a un rôle très important, car il permet de situer les évènements dans le temps. 4.2Utilité de l'av SE Le fonctionnement des PKI est complexe, cependant il existe des besoins communs à toutes les PKI. Ces besoins sont notamment : la connaissance de l'état d'un certificat numérique à une date donnée, et la vérification juridique et technique d'une signature électronique. La différence entre vérification juridique et vérification technique sera abordée dans la partie 5.3 intitulée F.VERIFY.SIGN. Partant de ce besoin, l'autorité de Vérification des Signatures Electronique (AVSE) doit donc rendre les services de : 1. Vérification de certificats numériques 2. Vérification de signatures électroniques 3. Vérification de fichiers de signatures XMLDSIG A chaque service correspond une et une seule fonction. Ainsi seules trois fonctions sont accessibles sont accessibles pour un utilisateur lambda : une fonction pour vérifier les certificats numériques notée F.VERIFY.CERT, une fonction pour vérifier les signatures électroniques notée F.VERIFY.SIGN et une fonction pour vérifier les fichiers de signatures XMLDSIG notée F.VERIFY.XMLDSIG. L'AVSE est un module serveur 100% Java. L'AVSE doit retourner à l'utilisateur des réponses juridiquement valables. Le schéma, extrêmement simplifié, ci-dessous montre les entrées / sorties de l'avse : Fig 3.5 : Principe de fonctionnement général de l'avse Oui + Preuves le certificat numérique la signature numérique le fichier de signatures XMLDSIG juridiquement valable? AVSE Non + Preuves Impossible de répondre Remarques : Dans ce schéma, l'avse est considérée comme une boîte noire. Son fonctionnement interne sera décrit dans la partie 4.3 intitulée Vue fonctionnelle globale de l'avse. En réalité l'avse ne se contente pas simplement de répondre Oui ou Non, mais elle détaille son -16-

17 analyse dans un format XML. Voir parties 5.2, 5.3 et 5.4. Il y a deux types de raisons pour que l'avse ne soit pas en mesure de répondre : raisons applicatives : L'AVSE ne dispose pas des données nécessaires pour répondre. raisons fonctionnelles : Dans la partie 4.3 intitulée Vue fonctionnelle globale de l'avse, on verra que l'avse s'appuie sur un système d'horodatage et un système d'audit pour fonctionner. Si l'un de ces services n'est pas disponible, l'avse ne répondra pas. 4.3Vue fonctionnelle globale de l'av SE Dans la partie 4.2 intitulée Utilité de l'avse, je décris le fonctionnement de l'avse en la considérant comme une boîte noire. Désormais je vais décrire son fonctionnement en la considérant comme une boîte blanche, c'est-à-dire que je vais décrire le fonctionnement interne de l'application. Fig 3.6 : Flot d'informations dans l'avse AVSE E0 Données sans attributs de sécurité Référentiel 3 fonctions de sécurité externes : F.VERIFY_XMLDSIG F.VERIFY_SIGN Fabrication du message de réponse R0 F.VERIFY_CERT E0 R1 R1 Données avec attributs de sécurité R2 Audit R2 R1' Horodateur Légende : Concaténation Périmètre de l'application AVSE Données sans attributs de sécurité Coeur de l'application AVSE de l'information Données avec attributs de sécurité Communication avec le référentiel R i : Réponse de l'avse E i : Paramètre en Entrée Etape 1 : L'application cliente envoie une requête (avec des paramètres d'entrée E0) à l'avse en appelant l'une des 3 fonctions externes. Etape 2 : L'AVSE traite la requête et construit une première réponse interne R

18 Etape 3 : L'AVSE concatène la réponse R0 avec les paramètres d'entrée de la requête E0. La réponse est notée R1. Etape 4 : La réponse R1 est envoyée à l'horodateur pour être signée et horodatée. L'horodateur renvoie à l'avse la signature horodatée R1' à l'avse. Etape 5 : L'AVSE concatène la réponse R1 et la signature horodatée R1' pour obtenir une nouvelle réponse notée R2 qui est la réponse finale de l'avse. C'est cette réponse qui sera renvoyée vers l'application cliente. Etape 6 : L'AVSE enregistre dans ses pistes d'audit la réponse R2 qu'elle s'apprête à renvoyer. Etape 7 : L'AVSE renvoie la réponse R2 à l'application cliente. Par attributs de sécurité, il faut associer les notions de : Intégrité : Si la réponse de l'avse est modifiée par un attaquant, la modification sera automatiquement détectée. Non répudiation : En signant ses réponses, l'avse s'identifie et ne pourra contester une réponse qu'elle aura émise. Anti-rejeu : En horodatant ses réponses l'avse prévient toutes les techniques de rejeu qu'un attaquant pourrait utiliser. Le référentiel : Il doit être vu dans ce schéma comme une base de données au sens générique du terme. Il contient les certificats des AC (tous les certificats de la chaîne de confiance) ainsi que leur CRL respective. En pratique il s'agit de la combinaison d'une base de données et d'un KeyStore (Fichier de Clés). L'audit : C'est un service permettant d'enregistrer toutes les actions de l'avse dans des fichiers nommés pistes d'audit. Les pistes d'audit sont séparées en deux catégories : les pistes d'audit administratives qui enregistrent toutes les actions de l'administrateur, et les pistes d'audit clientes qui enregistrent toutes les réponses de type R2. L'horodateur : L'horodateur a la même utilité que dans une PKI classique. Il permet d'associer de manière unique la signature et la date à laquelle elle a été créée. La source de temps de l'horodateur est une source de temps sûre. Concrètement pour l'avse il s'agit d'un boîtier physique (valeur ) fabriqué par la société DATUM 6 qui est une société américaine spécialisée dans les horodateurs. 5.Le coeur de l'avse Durant mon stage, mon objectif était de développer le coeur de l'avse, c'est-à-dire la partie de l'application qui va donner la réponse. Concrètement sur le schéma [Fig 3.6] de la page précédente, cela consiste à créer R0 connaissant E0 et le référentiel. L'écriture de l'avse demande des notions très pointues concernant la gestion des PKI, et les opérations cryptographiques asymétriques d'autre part. 5.1Vue statique du coeur de l'avse L'objectif de cette partie est de donner une vue statique du coeur de l'avse, c'est-à-dire de décrire simplement les liens entre les différents modules du coeur de l'avse. Je n'explique pas la raison de ces liens dans cette partie mais dans les parties 5.2, 5.3 et 5.4. Le schéma de l'annexe 2.4 intitulée Vue statique du coeur de l'avse montre les liens entre les différents modules du coeur de l'avse. Les 3 fonctions du coeur de l'avse sont les 3 fonctions accessibles depuis l'extérieur de l'application soit : 1. F.VERIFY.CERT ( 5.2) 2. F.VERIFY.SIGN ( 5.3) 3. F.VERIFY.XMLDSIG ( 5.4) L'intérêt et le fonctionnement de ces trois fonctions sera expliqué dans les parties 5.2, 5.3 et

19 5.2F.VERIFY.CERT L'objectif de la fonction : vérifier l'état d'un certificat pour une date donnée. Cette fonction est la plus importante des trois fonctions externes, car elle est à la base des deux autres. Les paramètres d'entrée de la fonction sont : 1. Le certificat utilisateur à vérifier. 2. La date GMT pour laquelle on veut vérifier l'état du certificat. Résumé : Dans les PKI, il est très important de connaître l'état d'un certificat pour une date donnée. Un certificat peut être valide ou invalide. Il y a plusieurs raison d'invalider un certificat, en voici quelques unes : Mauvais format : le certificat donné en paramètre de la fonction doit être un conforme à la norme X509 7, sinon il est déclaré invalide. Certificat corrompu : si le certificat a été corrompu, c'est-à-dire qu'un attaquant a modifié son contenu, la fonction détecte cette modification (si infime soit-elle) et déclare le certificat invalide. Certificat périmé : si la date donnée en paramètre d'entrée de la fonction n'est pas comprise entre la date de début de validité et la date de fin de validité, alors le certificat est périmé à la date donnée. La fonction déclare alors le certificat invalide. Certificat révoqué : si le certificat a été révoqué avant la date pour laquelle on vérifie sa validité, alors il est déclaré invalide. L'AC inconnue du référentiel : pour valider un certificat, il faut que l'ac ayant délivré le certificat soit connu de l'avse. Concrètement cela implique que tous les certificats de la chaîne de confiance sont contenus dans le référentiel de l'avse. Si l'ac est inconnue, l'avse ne déclarera pas le certificat invalide, mais avertira qu'elle n'a pas les informations nécessaires pour valider le certificat. Un certificat de la chaîne de confiance est corrompu : si un des certificats de la chaîne de confiance contenue dans le référentiel de l'avse est corrompue, l'avse ne reconnaîtra pas l'ac, et donc ne sera pas en mesure de valider le certificat. La CRL de l'ac est indisponible ou corrompue : Si l'avse ne dispose pas de CRL pour l'ac qui a émis le certificat à vérifier ou si la CRL est corrompue, alors l'avse ne pourra pas tester la révocation du certificat contre cette CRL, et invalidera donc le certificat. Ordre des opérations : Toutes ces vérifications sont effectuées dans un ordre logique de priorité afin d'optimiser le temps de réponse. En effet les cas les vérifications les plus discriminantes sont effectuées au début, les vérifications demandant plus de temps (révocation) sont traitées en dernier. On pourra retrouver l'enchaînement des vérifications sur le certificat en annexe 2.5 intitulée Enchaînement des vérifications dans F.VERIFY.CERT. Gestion des erreurs : A chaque anomalie correspond un code particulier. De plus il y a une hiérarchie des anomalies (erreurs, alertes,...). Les vérifications stoppent dès la première erreur rencontrée. Fig 3.7 : Hiérarchie des anomalies Type d'anomalie Valeur du code Commentaire Erreur < 0 Alerte > 0 Anomalie bloquante entraînant l'arrêt des vérifications. Anomalie non bloquante. Le but de l'alerte est d'attirer l'attention sur un point précis. Ok 0 La vérification s'est correctement déroulée

20 La liste complète des codes d'erreur de l'avse est disponible dans l'annexe 2.6 intitulée Codes d'erreur de l'avse. Le format de la réponse : La réponse retournée est au format XML. Ci dessous le format exact de la réponse. Fig 3.8 : Format de la réponse de la fonction F.VERIFY.CERT <CERT DN=xxx>ERR_CERT</CERT> <CRL>ERR_CRL</CRL> Légende : ERR_CERT : Code d'erreur concernant le certificat ERR_CRL : Code d'erreur concernant la CRL La balise CERT contient le code d'erreur concernant la vérification du certificat. La balise CRL contient le code d'erreur concernant la vérification de la CRL. La valeur du DN (Distinguished Name) du certificat est ici remplacée par XXX correspond à un certain champ du certificat. Analyse d'une réponse : Voici une réponse réelle retournée par l'avse : Fig 3.9 : Exemple de réponse retournée par F.VERIFY.CERT <CERT DN="tourdot">-1100</CERT> <CRL>0</CRL> La vérification de la CRL s'est correctement déroulée. Le certificat est corrompu. 5.3F.VERIFY.S I G N L'objectif de la fonction : vérifier une signature électronique et vérifier l'état du certificat. Les paramètres d'entrée de la fonction sont : 1. Le certificat utilisateur associé à la signature. 2. La date GMT pour laquelle on veut vérifier la signature. 3. La signature à vérifier. 4. Les données qui ont été signées. 5. L'empreinte des données qui ont été signées. 6. L'algorithme de la signature. Dépendance : Cette fonction s'appuie sur F.VERIFY.CERT. Résumé : Dans les PKI il est très important de vérifier une signature et vérifier l'état du certificat associé à la signature à une date donnée. Il y a plusieurs raisons d'invalider une signature d'une part, et d'autre part, il y a deux niveaux d'invalidation : 1. Invalidation technique de la signature : L'invalidation technique de la signature est déclarée à la suite d'opérations purement mathématiques. Il s'agit de la vérification standard d'une signature électronique qui se fait à partir des 3 éléments suivant : les données signées, la signature, la clé publique du certificat associé. -20-

21 Il n'y a que trois raisons d'invalider la vérification purement technique d'une signature : Données signées corrompues : si les données ont été corrompues par un attaquant, la vérification de la signature échoue et la signature est déclarée invalide. Signature corrompue : si la signature a été corrompue par un attaquant, la vérification de la signature échoue et la signature est déclarée invalide. Clé publique corrompue : si la clé publique a été corrompue par un attaquant, la vérification de la signature échoue et la signature est déclarée invalide. 2. Invalidation juridique de la signature : L'invalidation juridique de la signature est déclarée à la suite Il y a plusieurs raisons d'invalider la vérification juridique d'une signature : La vérification technique de la signature a échoué : si la vérification technique de la signature échoue, alors la signature est déclarée juridiquement non valable. Certificat révoqué : si le certificat est révoqué avant la signature, alors la signature est déclarée juridiquement non valable. Droit du certificat : un certificat dispose d'un certain nombre de droit. S'il n'a pas le droit de Signature Digitale alors la signature est déclarée juridiquement non valable. De manière générale, si la vérification effectuée par F.VERIFY.CERT échoue, alors la signature est déclarée juridiquement non valable. Ordre des opérations : Dans un premier lieu la fonction F.VERIFY.SIGN délègue la vérification du certificat à F.VERIFY.CERT. Ensuite elle vérifie techniquement la signature. On pourra retrouver l'enchaînement des vérifications de la fonction F.VERIFY.SIGN en annexe 2.7 intitulée Enchaînement des vérifications dans F.VERIFY.SIGN. Gestion des erreurs : La gestion des erreurs est identique à F.VERIFY.CERT. Voir Fig 3.7. Le format de la réponse : La réponse retournée est au format XML. Ci dessous le format exact de la réponse. Fig 3.10 : Format de la réponse de la fonction F.VERIFY.SIGN <SIGN>ERR_SIGN</SIGN> <CERT DN=xxx>ERR_CERT</CERT> <CRL>ERR_CRL</CRL> Légende : ERR_SIGN : Code d'erreur de la vérification technique de la signature ERR_CERT : Code d'erreur concernant le certificat ERR_CRL : Code d'erreur concernant la CRL Analyse d'une réponse : Voici une réponse réelle retournée par l'avse : Fig 3.11 : Exemple de réponse retournée par F.VERIFY.SIGN -21-

22 La signature est techniquement validée. <SIGN>0<SIGN> <CERT DN="tourdot">-1160</CERT> <CRL>0</CRL> La vérification de la CRL s'est correctement déroulée. Le certificat est révoqué à la date donnée. Remarque : l'analyse de la réponse ci-dessus montre qu'il s'agit d'une signature techniquement valable (code d'erreur 0 dans la balise <SIGN>) mais cette même signature est juridiquement non valable car le certificat était révoqué lors de la création de la signature. 5.4F.VERIFY.XMLD S I G Avant tout, il est important de comprendre la notion de fichier de signatures. On emploie également le terme de fichier de preuves ou de fichiers KTO. Dans ce rapport j'utilise indifféremment l'un ou l'autre de ces termes. L'annexe 2.8 intitulée Les fichiers de preuves explique la notion de fichier de preuves. L'objectif de la fonction : vérifier un fichier de signatures. Les paramètres de la fonction sont : 1. Le chemin d'accès au fichier de signatures 2. Le nom du fichier de signatures Dépendance : Cette fonction s'appuie sur F.VERIFY.SIGN. Résumé : Dans les PKI, il existe des fichiers de signatures. Ces fichiers sont au format XML, et contiennent une ou plusieurs balises signatures au format XMLDSIG 8 (XML DIGITAL SIGNATURE). La norme XMLDSIG instaure un standard concernant l'utilisation de la signature dans les fichiers XML, la nomenclature des balises, leur contenu... La norme XMLDSIG est une norme complexe, il n'est pas l'objectif de ce rapport d'expliquer cette norme. Le but de cette fonction est très simple : vérifier chacune des balises signatures. Pour chaque balise signature, la fonction extrait les 6 paramètres nécessaires à la vérification d'une signature via la fonction F.VERIFY.SIGN puis les lui transmet. Ordre des opérations : La fonction vérifie les balises signatures les unes après les autres. Aucune balise signature n'est prioritaire sur l'autre, et l'invalidation d'une signature n'impacte pas la validation des signatures. On pourra retrouver l'enchaînement des vérifications sur un fichier de signature dans l'annexe 2.9 intitulée Enchaînement des vérifications dans F.VERIFY.XMLDSIG. Gestion des erreurs : La gestion des erreurs est identique à F.VERIFY.CERT et F.VERIFY.SIGN. Le format de la réponse : La réponse retournée est au format XML. Ci dessous le format exact de la réponse. Fig 3.12 : Format de la réponse de la fonction F.VERIFY.XMLDSIG

23 <VERIFICATION ID=refXmldsig> Résultat de la vérification de la 1 balise signature { <SIGNATURE ID=sigID> <SIGN>ERR_SIGN</SIGN> <CERT DN=xxx>ERR_CERT</CERT> <CRL>ERR_CRL</CRL> </SIGNATURE> Résultat de la vérification de la dernière balise signature {... <SIGNATURE ID=sigID> <SIGN>ERR_SIGN</SIGN> <CERT DN=xxx>ERR_CERT</CERT> <CRL>ERR_CRL</CRL> </SIGNATURE> </VERIFICATION> 6.Test de l'avse Légende : ERR_SIGN : Code d'erreur de la vérification technique de la signature ERR_CERT : Code d'erreur concernant le certificat ERR_CRL : Code d'erreur concernant la CRL refxmldsig : Identifiant unique du fichier de signatures sigid : Identifiant unique de la balise signature 6.1Définition et objectifs des tests Selon la norme IEEE : le test est un processus manuel ou automatique, qui vise à établir qu un système vérifie les propriétés exigées par les spécifications, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification. Dans le processus de certification, les tests doivent se soumettre à cette norme. Une étude démontre qu'en moyenne, une nouvelle erreur est introduite dans un logiciel après avoir corrigé six erreurs. Les tests sont une façon d'améliorer la qualité des logiciels et ils permettent aussi d'en évaluer la qualité. Il est préférable de connaître l'état de la qualité du logiciel avant la livraison au client et y réagir, au lieu que ce soit le client qui rende compte des problèmes trouvés une fois le logiciel déployé (les conséquences pouvant être : coût de maintenance et de re-déploiement élevés, insatisfaction du client, pertes de données, risques de poursuite ou de non-paiement, etc...) L'efficacité du test (son aptitude à détecter les erreurs) dépend du contexte de l'utilisation : plus le contexte est critique, plus l'effort des tests est important. Dans le cadre de la certification d'une application de sécurité, l'efficacité des tests doit être maximale. Les tests doivent : Mettre en évidence les erreurs d'un logiciel Permettre d'obtenir la confiance avant l'utilisation opérationnelle. Les tests n'on pas pour objectif de :

24 Diagnostiquer la cause des erreurs Corriger les erreurs Prouver la correction d'un programme 6.2Les différents types de test Il existe différents type de test, chacun ayant un but très précis : 1. Les tests unitaires : procédure visant à tester le bon fonctionnement d'un module très précis et uniquement ce module. 2. Les tests d'intégration : procédure visant à tester des unités fonctionnelles constituées d'un assemblage de modules. 3. Les tests de non régression : ils ont pour but, suite à la modification d'un des constituants du logiciel, de montrer que les autres parties du logiciel n'ont pas été affectées par cette modification. 4. Les tests de performance : ils ont pour but de vérifier que le temps de réponse d'un composant est conforme aux spécifications. Pour la certification EAL2+ de l'avse, nous avons utilisé 3 types de tests : les tests unitaires, les tests de non régression, et les tests de performance. Les tests unitaires ont été utilisés pour tester les 3 fonctions principales : F.VERIFY.CERT, F.VERIFY.SIGN et F.VERIFY.XMLDSIG. Les tests de performances ont été utilisés pour vérifier que le temps moyen de l'avse ne dépassait pas un certain temps fixé dans les spécifications. En effet le cahier des charges de l'avse imposait qu'elle puisse supporter le rythme de Les tests de non régression ont été utilisés à chaque modification du code de l'avse, pour vérifier que cette modification n'avait aucun impact sur le comportement attendu de l'application. 6.3Etapes du processus de test Il y a 5 étapes fondamentales pour effectuer les tests. 1. Planification. Cette étape doit répondre à la question «Comment s'y prendre?». C'est durant cette étape que l'on définit les objectifs du test, la couverture 10 des tests, les outils à utiliser. Cette étape conduit à la rédaction d'un document intitulé Plan de test synthétisant l'ensemble des choix effectués durant la phase de planification. 2. Conception des cas de test. Cette étape décrit tous les cas de test envisagés. On décrit le scénario de test, les paramètres en entrée, et les résultats attendus. Pour chaque scénario, on doit expliciter ce qu'on veut prouver par ce test. 3. Exécution. Cette phase consiste à exécuter la totalité des scénarii de test. 4. Observation des résultats. Cette étape conduit à la rédaction d'un Rapport de Test dans lequel on analyse les résultats du test, on identifie les tests en échec Correction. Les tests en échec sont-il dus au produit testé ou au programme de test? Ajout de nouveaux cas de test. Fig 3.13 : Enchaînement des étapes d'une procédure de test 10 Fonctionnalités à tester et importance des tests. -24-

25 Planification Conception Exécution Observation Réussi? Livraison Correction Source : Norme IEEE Méthodes et outils de test Pour développer, et exécuter les tests, j'ai utilisé l'outil JUNIT qui est l'outil de test unitaire intégré avec l'ide Eclipse 11. La totalité du programme de test a été écrit en Java. Junit est un outil puissant qui permet en quelques secondes de lancer les tests et d'obtenir un compte-rendu détaillé de ce qui marche et de ce qui ne marche pas. Pour écrire et concevoir les tests, il a fallu appliquer les règles suivantes : Règles : Une classe : un test Une classe devant être testée, autant qu'elle dispose de son propre module de tests. Comme la notion de module la plus fine en Java est la classe, on écrit une classe de test pour chaque classe à tester. Règle de nommage Chaque classe de l'application ayant sa classe de test, cela permet de retrouver facilement le test attaché à une classe : pour ce faire, il suffit de prendre la convention de nommage : TestMaClass. Ainsi le nom de la classe de test de F.VERIFY.CERT et TestF.VERIFY.TEST. Ecrire les scénarii courants On écrit les scénarii d'utilisation courante de l'application, même si on sait que l'application répond correctement en utilisation normale. Les scénarii de la fonction F.VERIFY.SIGN sont disponibles en annexe 2.10 intitulée Scénarii de test de la fonction F.VERIFY.SIGN. Mettre l'application en difficulté C'est l'étape la plus importante, il faut soumettre à l'application pour vérifier que l'application résiste bien, et que dans tous les cas l'utilisateur reçoive un message clair. Réinitialiser l'environnement A la fin du programme de test, tous les fichiers créés, les certificats, les CRL... doivent être supprimés des répertoires disque, des bases de données... pour ne pas influer sur le résultat d'un autre lancement de test. Génération automatique des données de test Ce n'est pas une règle facile à respecter, mais il est tout de même préférable de la suivre. Ainsi dans mon programme de test, toutes les signatures, les certificats, les CRL, les fichiers de preuves sont générés automatiquement à chaque lancement du programme de test. Couverture des tests Il existe des programmes permettant d'évaluer le pourcentage du code parcouru durant le test. Ces programmes donnent une estimation de la couverture des tests. Pour l'avse, 95% du code était parcouru durant l'exécution de mon programme de test. (Cela signifie que sur 1000 lignes de codes, 950 étaient parcourues.) Fig 3.14 : Illustration du programme de test

26 Indice du test en cours Nombre d'erreurs détectées Nombre de tests en échec durant l'éxécution Test en échec Test OK Erreur Barre de progression des tests Barre de progression des tests Comme on peut le constater, il y a trois types de réponse à un test : 1. Test OK : le test a été passé avec succès, les résultats renvoyés par l'application sont conformes à ce que le programme de test attendait. 2. Test en échec : le test a échoué, les résultats renvoyés par l'application ne sont pas conformes à ce que le programme de test attendait. 3. Erreur : l'erreur est fatale. Elle signifie un plantage qui peut provenir de l'application testée ou du programme de test lui-même. 6.5Bilan des tests Plus de 130 cas tests ont été soumis pour vérifier la conformité du coeur de l'avse par rapport aux spécifications. Lors de mon départ, seuls 3 tests étaient encore en échec, et les raisons de ces échecs étaient connues. L'écriture de test est une étape bien souvent négligée, car longue et fastidieuse. Dans le cadre de la certification EAL, le programme de test est un programme à part entière. Le programme de test que j'ai écrit balayait 95% du code source de l'avse. Les 5% restants étant des cas triviaux de tests. D'autre part un balayage de 100% n'aurait pas prouvé que le coeur de l'avse répondait correctement, car encore une fois il est bon de rappeler que les tests servent à montrer et non à prouver. A la fin de mon stage, j'ai réalisé ces diagrammes pour estimer la charge de travail accomplie concernant le programme de test par rapport à celle de l'avse : Fig 3.15 : Comparaison de l'avse et de son programme de test -26-

27 Lignes de code Temps de développement Documentation 45 % 55 % 40 % 60 % 75 % 25 % AVSE : 2700 lignes test : 3200 lignes AVSE : 1000 heures test : 650 heures AVSE : 300 pages test : 100 pages Légende : Programme de test de l'avse AVSE Lignes de code L'AVSE et son programme de test ont sensiblement le même nombre de lignes de code. Cependant le code du programme de test est très factorisable, car pour le test d'une fonction le modèle de test est le même, il n'y a que les données qui diffèrent. Temps de développement Le temps de développement de l'avse est supérieur au temps de développement du programme de test. Documentation Le volume de documentation de l'avse est beaucoup plus important que celui du programme de test. Ceci s'explique par l'abondance des documents de spécifications exigés pour une certification EAL. 7.Conclusion Ce sujet était le plus intéressant de tous, car il consiste en la réalisation d'une application entière à partir de spécifications. Cela m'a donc permis d'intégrer et d'appliquer les méthodes rigoureuses de l'ingénierie logicielle. (définition du besoin, cahier des charges, tests...). D'autre part ce sujet m'a permis de me familiariser avec la procédure de certification EAL, qui est stricte et extrêmement normalisée (Crières Communs). Je pense que c'est l'un des atouts majeurs de ce sujet, voire du stage, car les personnes compétentes, ou ayant au moins abordé le sujet, sont très prisées par les sociétés éditrices de logiciels de sécurité informatique. Ce sujet m'a permis d'aborder le sujet connus, mais néanmoins trop peu appliqué de l'importance des tests dans le processus d'ingénierie logicielle. Ce sujet intégrait également des notions juridiques telle que la légalité de la preuve apportée par l'avse. -27-

28 Chapitre 3 Remplacement des composants de RSA- Security Descriptif : Parmi les briques de sécurité que KOTIO propose à ses clients, on trouvera entre autres un outil de signature électronique et d'opérations cryptographiques déployé sur le poste client. Ce module cryptographique utilise des composants cryptographiques de base RSA-Security. Kotio souhaite prendre un peu de distance vis-à-vis de cette dépendance tant sur le plan technique que financier. Le but de ce sujet est de réaliser le prototype d'une libraire de sécurité totalement indépendante des produits de RSA- Security. Il a fallu adopter une méthodologie très rigoureuse pour ce sujet. En effet toutes les étapes de la réalisation du prototype étaient clairement définies par le responsable technique, et s'enchaînaient logiquement : Les enjeux du remplacement : cerner tous les impacts (business, métier...) de ce sujet Connaître les points forts et les points faibles des produits à remplacer Analyse de l'architecture cliente pour déterminer la ou les couches impactée par le remplacement Estimation de la charge de travail : quantité de fonctions à remplacer... (haut niveau) Analyse des fonctions à remplacer : APIs, rôle, fonctionnement (bas niveau) Déterminer tous les critères de choix de la librairie de remplacement Rechercher les librairies candidates au remplacement Concevoir un ou plusieurs prototypes de la librairie de sécurité Tester le prototype Comparer les performances de l'actuelle librairie de sécurité et du prototype Valider / Invalider le prototype 1.Qu'est- ce que RSA- Security? RSA-Security est une société 12 internationale dont la société mère se trouve aux USA. Les trois inventeurs de l'algorithme cryptographique RSA en 1979 : Rivest, Shamir et Adlemann ont fondé cette société. RSA- Security a déposé un brevet sur l'algorithme RSA qui n'est tombé dans le domaine public qu'en Jusqu'ici seul la société RSA-Security avait le monopole de l'algorithme RSA. Il fût un temps où la société RSA-Security demandait un dollar pour chaque clé RSA générée. Aujourd'hui la société est l'une des leaders dans le domaine de la sécurité informatique plus particulièrement de la cryptographie. Elle a diversifié ses offres : transactions bancaires, sécurité des accès... RSA-Security est également très présente dans le domaine de la Recherche et possède de nombreux laboratoires. Elle organise également des conférences dans le monde entier, et organise de nombreux concours de cryptanalyse

29 2.Les enjeux du remplacement Les applications RSA-Security utilisé par Kotio sont : RSA-CryptoC et RSA-CertC. La première gère toutes les fonctionnalités de cryptographie, la seconde est dédiée à la gestion des certificats. Ces deux librairies sont des librairies C. Fig 3.1 : Les produits Crypto-C et Cert-C de la société RSA-Security Les librairies Crypto-C et Cert-C font partie de la gamme de produits RSA-BSAFE, acquise par Kotio en 2001 pour la somme de Avant de remplacer les produits de RSA-Security, il m'a fallu étudier quels était les points forts et les points faibles de leurs produits : Inconvénients : Librairie propriétaire : Les codes sources des implémentations ne sont pas publiés par la société RSA-Security. Pour les clients de Kotio cela pose un problème de transparence. Société américaine : C'est un problème marketing : les clients français sont rétissent quant à l'utilisation de produits américains (dont le code n'est pas publié) pour gérer leurs données sensibles. Coût de la librairie : l'achat des licences des produits RSA-CryptoC et RSA-CertC a coûté Il s'agit d'une licence à vie. Ces produits ont été acquis en Maintenance : Le coût de la maintenance est de par an pour chacune des applications. Portabilité OS : RSA-CryptoC et RSA-CertC ont principalement été écrit pour Windows, bien qu'il existe des solutions portables sous Linux. Avantages : Packaging : Les produits de RSA-Security sont extrêmement bien packagés. Chaque produit dispose d'une documentation importante : un manuel nommé User's Manual décrivant les concepts fondamentaux et un autre manuel Library Manuel destiné au développeur où chaque fonctionnalité est parfaitement décrite, et illustrée à l'aide d'exemples. Marketing : Certains clients considèrent la société RSA-Security comme la société référence en matière de cryptographie. Remarque : Kotio utilise également un autre produit de RSA-Security nommé RSA-Keon, dont le prix de licence est de RSA-Keon offre toutes les fonctionnalités pour la gestion d'une AC : création de certificats, création de CRL

30 3.Analyse des modules clients existants Avant même d'étudier les solutions de remplacement possibles, il a fallu réaliser une étude complète de l'existant. A l'aide de la documentation Kotio et de recherches personnelles, j'ai donc analysé structurellement et fonctionnellement les différentes couches présentes sur la partie cliente. Fig 3.2 : Architecture des librairies installées sur le poste client Internet Explorer KotioCertif.ocx KotioMail KotioCertif KotioMail.ocx Librairie impactée par le remplacement Librairie cryptographique à remplacer Librairie de sécuriré RSA-BSAFE Libraire Horodateur Crypto API Windows KotioSecureLib.dll tti.dll crypt32.dll Légende : Librairies développées par Kotio Librairies propriétaires Description fonctionnelle des modules : KotioMail : KotioCertif : Nom exact de l'élément : kotiomail.ocx Rôle : gère la signature sur le poste Client, construit le fichier de signatures (qui encapsule le fichier initial/source, les différents tampons d horodatage, la ou les signatures de/des l utilisateur/s). Mode de fonctionnement : Est une librairie appelée par les fonctions Java script insérées dans les pages Web de l application KOTIO. Il y a trois étapes fondamentales au moment du dépôt du document sur le serveur KOTIO : 1. construction du fichier de signatures (.KTO) au format XML avec insertion du document source. 2. insertion et vérification du tampon d horodatage, et signature de l ensemble par l utilisateur. Fait abondamment appel à la librairie KotioSecureLib.dll. 3. gère l interaction avec la page Web (IE) afin de réaliser l upload du fichier de preuve sur le serveur (n interagit pas directement avec le serveur). Réalise le découpage du fichier en paquets pour le transfert. Nom exact de l élément : kotiocertif.ocx Rôle : choix du certificat à utiliser dans le cadre des services de signature électronique KOTIO. Mode de fonctionnement : à la première connexion de l utilisateur sur le serveur KOTIO (après inscription) le poste client (via la page Web) appelle une fonction de KotioCertif qui affiche la liste des certificats compatibles avec le l AC (le CN du certificat) choisie pour l utilisateur lors de l inscription. L utilisateur choisi son certificat parmi la liste disponible reconnue. Le certificat est récupéré depuis IE au format X509 (encodé base 64) y compris la clé publique. Ces informations sont -30-

31 uploadées sur le serveur KOTIO par la page Web (formulaire caché dans une commande http POST). Ce composant a donc un rôle extrêmement réduit (affichage et choix du certificat), et se comporte de manière passive (comme une librairie). KotioSecureLib (Couche impactée par le remplacement!) Nom exact de l élément : KotioSecureLib.dll Intègre (par compilation statique) la fourniture RSA-Security : BSAFE-Cert C et BSAFE-Crypto C Rôle : effectue la signature électronique du document, le chiffrement du document, calcule des hash des documents. Mode de fonctionnement : réalise la signature électronique sur le poste client en faisant appel aux librairies RSA- BSAFE. réalise le chiffrement AES et RSA en faisant appel aux librairies RSA-BSAFE. fait appel à la librairie d horodatage afin de vérifier les tampons. Librairie d horodatage Nom exact de l élément : tti.dll Fourniture de la société DATUM. Cette librairie est propriétaire et les sources ne sont pas publiées. Rôle : vérification des tampons d horodatage. Extraction de l heure contenue dans le tampon. Crypto API Windows Nom exact de l élément : crypt32.dll (également connu sous le nom de MSCAPI : Microsoft Crypto APIs) Librairie fournie par Microsoft sur toutes ses versions de Windows. Cette librairie implémente notamment l'accès au KeyStore d'internet Explorer. Cette librairie est propriétaire et les sources ne sont pas publiées. Conclusion : Cette étape m'a permis d'avoir une vue d'ensemble de l'architecture des composants clients, de leurs rôles et de leurs interactions. Elle m'a également permis d'identifier concrètement le composant à remplacer (RSA-BSAFE), ainsi que l'a couche impactée par le remplacement (KotioSecureLib.dll) 4.Analyse des dépendances à RSA- Security Le but de cette étape est d'étudier les dépendances de la librairie de sécurité aux produits de RSA- Security afin d'identifier les fonctions à remplacer et d'estimer le volume des fonctionnalités à remplacer. Dans cette étape on considère la librairie de sécurité comme une boîte noire, c'est-à-dire que l'on ne s'intéresse pas encore aux fonctions. -31-

32 Fig 3.3 : Répartition des fonctions de la librairie de sécurité Fonctions totalement indépendantes de RSA-BSAFE % 8 fonctions Fonctions dépendant indirectement de RSA-BSAFE 8 % 3 fonctions 71 % 27 fonctions Fonctions dépendant directement de RSA- BSAFE Les fonctions dépendant directement de RSA-BSAFE devront donc être intégralement réécrites. Les autres (fonctions neutres et dépendant indirectement de RSA-BSAFE) n'ont pas besoin d'être réécrites. Conclusion : la librairie de sécurité représente une quarantaine de fonctions dont plus de 70% est à réécrire. 5.Analyse des fonctionnalités de la librairie de sécurité Le but de cette étape est d'étudier la totalité des fonctions de la libraire de sécurité. Dans cette étape, le composant est considéré comme une boîte blanche. Chaque fonction est étudiée selon : Structure des paramètres Type de paramètres (In / Out) Type de la sortie Dépendances entre les fonctions Description de la fonction Les principales fonctions de la librairie de sécurité sont donc : Générer une signature électronique à partir d'un support logiciel (KeyStore d'internet Explorer) Générer une signature électronique à partir d'un module physique (Carte à Puce, Clé USB...) Calcul de l'empreinte d'une donnée Calcul de l'empreinte d'un fichier Extraction d'information à partir d'un certificat codé en base 64 (clé publique, CN...) Vérification d'une signature électronique -32-

33 6.Les critères de choix Le but de cette étape est de lister tous les critères de choix d'un remplaçant aux produits de RSA- Security. Les deux principaux critères qui m'étaient imposés étaient que la solution devait être OpenSource et devait pouvoir fonctionner sous Windows/Linux pour pouvoir s'interfacer avec Internet Explorer ou Mozilla. J'ai ensuite listé tous les critères de choix d'une librairie cryptographie. Voici les principaux critères : Critères techniques : 1. Empreinte de la librairie : la taille de la librairie est un critère important car la solution développée devra être déployée sur le poste client, il faudra donc veiller à ce que la taille soit minimale. 2. Fonctionnalités : la nouvelle librairie devra posséder toutes les fonctionnalités cryptographiques des librairies de RSA-Security, notamment la prise en charge des algorithmes SHA1, RSA, et AES, et la gestion des standards PKCS 1.5, PKCS7, PKCS 11 et PKCS Compatibilité OS : la solution adoptée devra être compatible Linux et Windows. 4. Browser : la solution adoptée devra être capable de s'interfacer aussi bien avec Internet Explorer de Microsoft qu'avec Mozilla. 5. Langage : la librairie existante est écrite en C. Critères commerciaux : 1. Licence : la licence de la nouvelle solution devra être libre et non contaminante, c'est-à-dire un droit total d'utilisation, de modification et de commercialisation. 2. Prix : le rapport qualité / prix de la nouvelle solution devra être le plus optimal. 3. Support / Packaging : la librairie est-elle bien packagée? Quels sont les types de support de la documentation? Assistance technique? 4. Maintenance / Mises à jour : gratuit? Payant? Régulières? Référencement des bugs? 5. Pérennité : la solution adoptée devra être pérenne. Pour la pérennité d'une librairie on peut se fier à sa date de création, la situation financière de l'entreprise qui propose la solution, l'activité des mailings liste Prestige : la librairie adoptée doit être connue. 7. Concurrence : Kotio dispose d'une liste détaillée de ses concurrents. Quelles solutions nos concurrents ont-ils adoptés, pourquoi? Certains critères sont très précis et peuvent paraître en contradiction : par exemple la librairie devra être compatible à la fois avec Internet Explorer et Mozilla. Or ces deux Explorer sont réputés pour être totalement incompatibles. La direction technique est consciente qu'il sera peut-être impossible de trouver une librairie rassemblant tous ces critères, le but sera alors de trouver celle le dénominateur commun et de compléter au cas par cas les fonctionnalités manquantes. 7.Les candidats potentiels Le but de cette étape est de trouver tous les candidats potentiels au remplacement de RSA-BSAFE. Une fois les critères de sélection déterminés et validés par la direction techniques, il a fallu trouver tous les candidats potentiels, et les lister selon ses critères, définis dans la partie 6, pour déterminer lequel était le meilleur remplaçant possible. L'étude comparative de tous les remplaçants potentiels est en annexe 3.1 intitulée Etude des candidats de remplacement. -33-

34 Fig 3.4 : Libraires étudiées pour le remplacement Librairie Organisation Type Langage Java C++ C OpenSSL OpenSSL.org Librairie Bouncy Castle BouncyCastle.org Librairie / Provider OpenOCES Danish National IT and Telecom Agency Application XML Security Library Communauté OpenSource Librairie Apache XML Security Apache Librairie IAIK Network Security Services NSS Microsoft Crypto APIs MSCAPI Technical University Graz (Autriche) Librairie / Provider Mozilla.org Librairie Microsoft Librairie Légende : Avis favorable Avis défavorable L'avis a été pris à partir du tableau en annexe 3.1. A ce stade de l'étude un avis favorable n'indique pas que la libraire a été choisie pour le remplacement, mais seulement qu'elle correspond à un maximum de critères définis dans la partie 6 intitulée Les critères de choix. 8.Réalisation du prototype Le but de cette étape est de choisir la ou les librairies adéquates et de réaliser le prototype correspondant. Seuls trois librairies sont candidates au remplacement des produits de RSA-Security : OpenSSL Network Security Services (NSS) Microsoft Crypto API (MSCAPI) Cependant aucune de ces librairies ne répond à la totalité de nos critères. Par exemple MSCAPI peut accéder au KeyStore d'internet Explorer, mais pas à celui de Mozilla. NSS peut accéder au KeyStore de Mozilla, mais pas à celui d'internet Explorer... Le prototype devra donc combiner ces librairies afin d'obtenir une nouvelle librairie de sécurité. J'ai proposé le prototype suivant : MSCAPI : accès au KeyStore d'internet Explorer NSS : tout le reste (hash, opération sur les certificats, KeyStore Mozilla...) La nouvelle architecture fournit donc une nouvelle libraire de sécurité ne reposant plus sur RSA-BSAFE, mais sur NSS et MSCAPI. Ci dessous l'architecture du prototype proposé : -34-

35 Fig 3.5 : Architecture du prototype Internet Explorer KotioCertif.ocx KotioMail KotioCertif KotioMail.ocx Librairie de sécuriré KotioSecureLib.dll NSS MSCAPI Libraire Horodateur tti.dll NSS et MSCAPI remplacent RSA-BSAFE crypt32.dll Légende : Librairies développées par Kotio Librairies propriétaires ou OpenSource La réécriture de la libraire de sécurité, qui rappelons le est une DLL (Dynamic Link Library) a été totalement réalisé avec l'ide Microsoft Visual Studio 6.0. L'utilisation de cet environnement de développement m'était imposée du fait que l'ancienne libraire de sécurité avait été développé avec ce dernier. Microsoft Visual Studio est un IDE complet offrant via le même logiciel la possibilité de programmer en Visual Basic, C, C++. Il offre également un puissant programme de déboguage, et une multitude de programmes très utiles pour la gestion des DLL, des ActiveX... Fig 3.6 : Environnement de développement de la librairie de sécurité { Gestion des sources, librairies... Fenêtre de développement Fenêtre de construction : Erreurs, alertes détectées