5.8.1. Vérification de protocole
Le processus de vérification est fondé sur l'utilisation de méthodes formelles générales et consiste en deux étapes principales : la vérification informelle, qui consiste à identifier les propriétés, effectuer une analyse exhaustive du protocole et décrire le principe des preuves ; et la vérification formelle des preuves, décrites et automatisées en Coq.
Nous exploitons les particularités du domaine : d'une part les acteurs sont répartis en un ensemble d'acteurs de confiance et un unique intrus générique, et d'autre part les propriétés à satisfaire sont des propriétés de sécurité de type authentification, confidentialité, intégrité, etc. L'approche a été étendue aux protocoles de commerce électronique, en particulier aux propriétés de cohérence de transactions, et aux protocoles de téléchargement d'applications Java.
Les réalisations incluent la vérification des protocoles Sésame, une extension de Kerberos, les protocoles de commerce électronique C-SET et SET pour le compte du G.I.E. Cartes Bancaires. L'étude de protocole de téléchargement d'applications Java est en cours.
5.8.2. Java embarqué
Java est en passe de devenir l'un des langages de programmation majeurs, entre autres grâce à sa portabilité, assurée par l'exécution de bytecode Java par une machine virtuelle indépendante du processeur, du système d'exploitation et de la machine hôte.
Désormais les petits systèmes peuvent aussi bénéficier de Java dans le but d'offrir des services multi-applications sûrs. Le plus petit est la carte à puce, et de nombreux systèmes embarqués comme les terminaux de paiement, les GSM, mais aussi les imprimantes, les télécopieurs, les pare-feu, etc., pourront télécharger et exécuter des applications Java.
Alors que la faible consommation de ressources en mémoire et en CPU n'était pas une priorité pour les réalisations de Java classiques, elle en est une cruciale dans les petits systèmes. Par exemple, une carte à puce typique a aujourd'hui environ 8Ko de ROM, 8Kb d'EEPROM, et moins d'1Ko de RAM. Pour cette raison, les techniques d'optimisation fondées sur l'analyse statique, exploitant la structure du typage de Java, et ainsi de suite, peuvent être utilisées avec profit pour réduire la consommation mémoire des machines virtuelles et des applications Java.
Un autre objectif est la sécurité. Les cartes à puce sont des composants permettant d'offrir les garanties les plus fortes de sécurité, mais intégrer Java dans les cartes à puce ne doit pas introduire de faille dans les mécanismes de sécurité de la carte. Des défauts, même mineurs, peuvent en effet avoir des conséquences désastreuses. Pour éviter ceci, nous utilisons les méthodes formelles pour valider les architectures de sécurité et les composants critiques des cartes à puce.
Les activités de l'équipe VIP dans ce domaine comprennent :
la conception de machines virtuelles Java ; l'analyse des mécanismes de sécurité : restrictions d'accès, caractéristiques sécuritaires des machines virtuelles, du téléchargeur d'applications, du gestionnaire de sécurité, du vérificateur de bytecode, etc. ;
la proposition et la justification des optimisations et transformations de machines virtuelles dédiées ;
la conception d'architectures de sécurité ;
l'évaluation d'architectures de sécurité.
Les résultats obtenus cette année sont les suivants. D'abord, les machines virtuelles développées conjointement par VIP et Bull SC&T ont été portées sur les produits industriels de Bull, en particulier la carte à puce Java Odyssey et le terminal de paiement Alto. Ces derniers ont été présentés au salon Cartes'98. Ensuite, VIP participe à l'action incitative JavaCard de l'INRIA, impliquant Dyade, le CERT et les équipes Cristal, Lande, Croap.
5.8.3. Certification
Plusieurs critères d'évaluation de la sécurité des systèmes d'information ont été définis : les ITSEC pour l'Europe, les TCSEC ("Orange Book ') pour les Etats-Unis, et maintenant les CC (critères communs) qui sont une fusion des deux précédents.
Ces critères sont un guide d'évaluation des différents aspects de la sécurité d'un produit, prenant en considération la sécurité de son développement, mais aussi les aspects liés à son cycle de vie et à son environnement. Il y a sept niveaux d'évaluation dans les CC, qui correspondent à la rigueur de la démonstration des propriétés de sécurité décrites dans la cible de sécurité.
Les certificats correspondant aux différents niveaux d'évaluation définis par les CC sont délivrés par des autorités gouvernementales et sont reconnus internationalement. Jusqu'ici utilisés principalement dans le domaine militaire, ils sont aujourd'hui de plus en plus utilisés pour des applications civiles, telles que des bases de données, des pare-feu, des passerelles réseau, des boîtes de chiffrement. Un domaine en pleine explosion de ce point de vue est celui des cartes à puce.
Au niveau le plus bas, seule l'absence de faille évidente est requise. A partir du niveau 5 des CC, ces critères imposent la description et la vérification formelle de la cohérence de la politique de sécurité. Le niveau de formalisation des différents niveaux de spécification et de la correspondance qui existe entre eux augmente jusqu'au niveau 7, où une modélisation et une preuve formelles des propriétés de l'architecture sont demandées.
Dans ce cadre, l'action VIP a participé à plusieurs certifications pour le compte de Bull SC&T, de niveau ITSEC 4 (équivalent CC 5). VIP est d'autre part partenaire dans le projet MASSC (projet MEDEA impliquant ST Thomson, Bull, De La Rue, Oscard et Dyade) et est responsable de la partie méthodes formelles et certification. En particulier, VIP contribue à l'élaboration des profils de protection (OS et applications systèmes) du projet MASSC, et effectue la description formelle et la modélisation des parties critiques de l'OS et des applications systèmes.
5.8.4. Code Mobile sécurisé
Le modèle Web de pages hypertexte multi-média distribuées évolue à l'heure actuelle vers un modèle de calcul distribué, en particulier grâce à l'introduction de code mobile, dont l'exemple le plus connu est Java. Un des thèmes principaux de l'action VIP est de garantir des propriétés de sécurité d'applications téléchargées. Il y a deux façons d'obtenir ces garanties de sécurité : en imposant que le client qui télécharge l'application n'accepte que des applications signées par une autorité de confiance, ou en imposant qu'il n'accepte que des applications accompagnées d'une preuve partielle ou totale des propriétés à vérifier, et dont le client vérifie les preuves.
La première approche, par signatures, est traditionnelle. L'exemple typique est celle des contrôles ActiveX sous Windows. L'application téléchargée contient une signature inviolable de son créateur. La sécurité repose uniquement sur la confiance accordée au créateur ou, plus généralement, à l'autorité certifiante. Dans les contrôles ActiveX, tout repose sur cette confiance. Dans le langage fonctionnel CSL (Caml Special Light), utilisé dans le mécanisme d'applets du browser MMM, les applets signées offrent une autre garantie : que l'applet téléchargée a été compilée avec un compilateur correct, et en particulier qu'aucune erreur de type à l'exécution ne se produira, ni aucune lecture ou écriture en-dehors des zones mémoire valides.
Dans la seconde approche, l'approche par preuves, l'applet est accompagnée d'une preuve formelle de sa sécurité (dans un modèle de sécurité donné). Le client vérifie que la preuve est formellement correcte, et ceci est inviolable. L'inspiration principale de ce type de travail est le principe de code auto-certifié (`` proof-carrying code ') de G. Necula et P. Lee. Il s'agit d'un travail de recherche à long terme, qui complémente l'approche par signatures, notamment pour des propriétés de sécurité plus évoluées que la correction des types et la préservation de l'intégrité de la mémoire, par exemple des propriétés de sûreté cryptographique telles que la confidentialité et l'authentification.
Des expériences sur ces thèmes ont été effectuées ou sont en cours : par extraction de code d'une preuve Coq (G. Huet et Ajay Chander), par des techniques d'analyse de flot de données pour vérifier des droits à la Bell-La Padula dans le modèle de sécurité Java 1.2 (équipe Lande), pour inférer statiquement la quantité de ressources utilisées par des applets Java (Ronan Gaugne), pour vérifier des propriétés de confidentialité et d'authentification d'applets utilisant des primitives cryptographiques (J. Goubault-Larrecq, A. Saïbi, N. El Kadhi).