FR2815434A1

FR2815434A1 - Procede de verification de coherence de codes destines a un systeme embarque, notamment une carte a puce

Info

Publication number: FR2815434A1
Application number: FR0013266A
Authority: FR
Inventors: Dominique Bolignano; Metayer Daniel Le; Claire Loiseaux; Carolina Lavatelli; Guillaume Phan; Henri Fraisse
Original assignee: Trusted Logic SAS
Current assignee: Trusted Logic SAS
Priority date: 2000-10-17
Filing date: 2000-10-17
Publication date: 2002-04-19
Anticipated expiration: 2020-10-17
Also published as: FR2815434B1

Abstract

L'invention concerne un procédé de vérification de cohérence de codes destinés à un système embarqué (4, 40). Selon l'invention, un jeu d'enregistrements (20) constituant des modèles à format unique est stocké dans la mémoire (2) d'un système informatique (1). Les modèles définissent un espace à deux dimensions hiérarchisé, une première dimension étant constituée par un niveau d'abstraction associé au code et une seconde dimension étant constituée par un degré de formalisation associé à la représentation du modèle. Des enregistrements supplémentaires (21) comprenant des règles de cohérence à observer sont également stockés dans la mémoire (2). Le code est généré et vérifié par référence à ces données enregistrées (20, 21) et des données saisies (11a, 11b). Des documents de certification (130) peuvent être générés automatiquement également par référence à ces données. Le procédé s'applique plus particulièrement aux cartes à puce (4, 40).

Description

L'invention concerne un procédé de vérification de cohérence de codes destinés à un système embarqué.

Elle concerne plus particulièrement, mais non exclusivement, le domaine des applications basées sur une carte à puce.

Dans le cadre de l'invention, le terme"système embarqué"doit être considéré dans son acception la plus générale. Il concerne notamment des systèmes destinés à une carte à puce, ce qui constitue l'application préférée de l'invention, mais également tout système destiné à un dispositif portable ou mobile comportant des moyens propres de traitement de données informatisés et de mémorisation de ces données, de façon très générale à tout terminal que l'on qualifiera de "léger", car muni de ressources informatiques relativement limitées.

Toujours dans le cadre de l'invention, le terme "code" doit également être pris dans un sens générique : codes sources ou objets, programmes, voire des documents électroniques etc. Il couvre notamment des applications logicielles de type appliquettes, ou"applets"selon la terminologie anglosaxonne, écrites en langage"JAVA" (marque déposée), langage très utilisé pour les applications destinées aux cartes à puce ; il couvre également des documents de spécification à différents niveaux d'abstraction.

Pour fixer les idées, on se placera dans ce qui suit dans le cas de l'application préférée de l'invention, à savoir un procédé de vérification de cohérence de codes destinés à une carte à puce.

Les cartes à puce sont utilisées dans divers domaines : applications bancaires, de santé, comme"porte-monnaie"dit électronique, etc. Sur une carte à puce peuvent en outre coexister plusieurs applications (carte à puce dite multi-application).

Pour ces types d'applications, les cartes à puce peuvent se voir dévolues diverses fonctions. En particulier, elles peuvent être utilisées à des fins de sécurité. Le terme "sécurité" doit lui aussi être compris dans un sens général : il recouvre notamment la confidentialité et/ou l'authentification de l'utilisateur du terminal hôte de la carte à puce, de la carte à puce elle-même

et/ou du propriétaire de cette carte à puce, ainsi que la conservation de l'intégrité des données traitées et des applications logicielles mises en oeuvre.

Les garanties exigées en matière de fiabilité et de sécurité sont encore plus importantes lorsqu'on considère des versions de carte à puce de technologie récente sur lesquelles on souhaite installer des applications logicielles multiples. Ces applications logicielles doivent coopérer harmonieusement sans révéler d'informations confidentielles. En effet, ces multiples applications peuvent concerner un seul utilisateur mais aussi, a priori, des utilisateurs distincts. Malgré la coopération précitée, un cloisonnement rigoureux doit être conservé de façon à ce que les informations concernant un utilisateur donné restent confidentielles et ne puissent être communiquées à des utilisateurs non autorisés.

Par ailleurs, il est également capital d'assurer l'intégrité des données manipulées par ces applications : à titre d'exemple, on peut citer les montants des transactions effectuées à l'aide d'une carte bancaire ou le solde d'un portemonnaie électronique.

Pour pouvoir être intégrés dans des systèmes critiques, comme les applications bancaires, les logiciels embarqués doivent donc satisfaire des normes de sécurité très précises, comme celles qui sont regroupées dans ce qu'on appelle les"critères communs pour l'évaluation sécuritaire des technologies de l'information", ci-après appelés sous forme abrégée, les "Critères Communs". Ces critères ou normes conduisent à l'attribution de "certificats"par des centres d'évaluation agréés. Pour obtenir un certificat, il est nécessaire de fournir un ensemble de documents apportant des garanties quant à la cohérence d'une application développée pour les systèmes embarqués. Ces documents sont d'autant plus nombreux et complexes que le niveau de certification est élevé.

A titre d'exemple non limitatif, on peut trouver une description détaillée téléchargeable des"Critères Communs"précités (version 2.1) sur le site WEB du"Service Central de Sécurité des Systèmes d'information" ("SCSSI"), en se connectant à l'adresse suivante : www. scssi. gouv. fr/document/docs/CC/cc21. html.

Les documents font l'objet d'une norme : ISO/IEC 15408.

Les niveaux de certification varient du niveau dit"EAL1" (le plus bas) au niveau dit"EAL7" (le plus haut), pour les "Critères Communs". Les niveaux les plus élevés (à partir de"EAL5") exigent certains documents se présentant sous une forme complètement formalisée, c'est-à-dire dans un langage "mathématique". Les niveaux intermédiaires nécessitent des notations dites semi-formelles (en particulier sous forme graphique), alors que les niveaux les plus bas ne concernent que des descriptions dites"informelles" (c'est-à-dire en langue naturelle). Il faut noter que le niveau de sécurité désormais exigé dans certains pays, notamment en France, pour les applications dans le secteur bancaire et le domaine de la santé ("EAL5"), impose que les logiciels subissent des contrôles de cohérence stricts avant de pouvoir être chargés sur des dispositifs comme des cartes à puce ou des terminaux.

La faiblesse des outils actuellement utilisés pour ce faire rend ces contrôles particulièrement laborieux et augmente le coût de développement des applications sécuritaires. Par ailleurs cet état de fait rend impossible toute forme d'incrémentalité dans la production des documents de certification. Par exemple, les documents requis aux niveaux élevés ne peuvent s'appuyer sur ceux qui ont été fournis dans des formats très différents à des niveaux inférieurs.

L'invention vise à répondre à ces besoins, sans nécessiter des procédures extrêmement longues et coûteuses, tout en palliant les inconvénients des dispositifs de l'art connu, et dont certains viennent d'être rappelés.

Le procédé selon l'invention permet de construire des logiciels pour systèmes embarqués et surtout de vérifier qu'ils satisfont des contraintes de cohérence prédéterminées bien précises. Il permet en particulier de générer automatiquement des documents de certification qui sont définis dans le standard des"Critères Communs".

Il permet aussi de générer des documents de certification à un niveau déterminé à partir de documents de certification précédemment générés à un niveau de certification inférieur. En d'autres termes, le procédé autorise un mode de fonctionnement de type incremental.

Pour ce faire, selon une caractéristique Importante du procédé selon l'invention, un format unique est utilisé, suffisamment général pour décrire des systèmes selon les différents modes rappelés ci-dessus, ou degrés de formalisation :"informel","semi-formel"ou"formel"et selon différents niveaux dits"d'abstraction", encore appelés de raffinement , allant de la spécification fonctionnelle (niveau le plus abstrait) à la mise en oeuvre en mémoire de la carte à puce ("implémentation"), de façon générale du système embarqué, en passant par des niveaux intermédiaires (communément appelés par l'Homme de Métier, "conception de haut niveau"ou générafe et"concept) on de bas niveau"ou détaillée ). L'ensemble définit un espace à deux dimensions dont les éléments sont stockés dans des moyens de mémoire d'un système informatique de mise en oeuvre du procédé de l'invention, ces éléments étant reliés par des liens représentant des contraintes de cohérence à respecter, conformément à une autre caractéristique du procédé de l'invention.

De façon pratique, chaque document est représenté par un enregistrement de mémoire de structure unique qui sera décrite ci-après de façon plus détaillée.

L'invention a donc pour objet principal un procédé de vérification de cohérence de codes destinés à un système embarqué, notamment une carte à puce, à l'aide d'un système informatique comprenant au moins un processeur de traitement de données numériques, des moyens de mémoire et des moyens d'entrée/sortie de données, caractérisé en ce qu'il comprend au moins : une phase préliminaire comprenant au moins une étape de stockage dans lesdits moyens de mémoire d'au moins un premier jeu d'enregistrements, chacun constituant un modèle comportant un nombre déterminé de champs configurés suivant une structure de format unique, lesdits modèles définissant un espace à deux dimensions hiérarchisé, une première dimension étant constituée par un premier paramètre définissant un niveau d'abstraction associé au dit code et une seconde dimension étant constituée par un second paramètre définissant un degré de formalisation associé à la représentation dudit modèle, et une deuxième étape de stockage dans lesdits moyens de mémoire d'au moins un

deuxième jeu d'enregistrements comprenant des règles de cohérence à observer ; et - une phase ultérieure comprenant au moins les étapes suivantes : a/au moins l'entrée dans ledit système de données numériques définissant un desdits niveaux d'abstraction et un desdits degrés de formalisation à associer au dit code de manière à adresser un desdits modèles stockés en mémoire et un jeu de règles de cohérence à observer stockées en mémoire ; et bl la vérification dudit code sous la commande dudit processeur de traitement de données par utilisation dudit modèle adressé et dudit jeu de règles de cohérence à observer
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : - la figure 1 illustre schématiquement un exemple de réalisation de système informatique permettant la mise en oeuvre du procédé selon l'invention pour la vérification de la cohérence de codes destinés à un système embarqué, ainsi que la production de documents de certification de ces codes ; et - la figure 2 illustre schématiquement des modèles à format unique, utilisés par le procédé selon l'invention, enregistrés dans la mémoire du système de la figure 1, et définissant un espace à deux dimensions.

Dans ce qui suit, sans en limiter en quoi que ce soit sa portée, on se placera dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas de la construction et de la vérification de cohérence de codes destinés à des cartes à puce, ainsi que la production de documents de certification pour ces cartes à puce.

De même, pour fixer les idées et pour mieux illustrer le procédé selon invention, on considérera plus particulièrement une application de type dit "porte-monnaie électronique" résidant sur une carte à puce.

La figure 1 illustre schématiquement un exemple de réalisation de système informatique 1 permettant la mise en oeuvre du procédé selon

l'invention pour la vérification de la cohérence de codes destinés à un système embarqué, ainsi que la production de documents de certification de ces codes.

Le coeur 14 du système informatique proprement dit comprend notamment un dispositif de traitement de données numériques à programme enregistré 140, par exemple un microprocesseur, ou plus généralement un processeur de données, fonctionnant sous la commande d'un système d'exploitation déterminé, ou"OS"selon la terminologie anglo-saxonne, par exemple sous un environnement"UNIX","WINDOWS" (tous marques déposées) ou tout autre environnement approprié. Le système 14 comprend également une mémoire centrale 2, pouvant elle-même être divisée en mémoire vive (ou"RAM") et fixe et/ou semi-fixe ("ROM","EPROM", etc.). I! est également prévu une mémoire de masse, par exemple une mémoire à disque dur 142 et des dispositifs d'entrée-sortie, représentés sous la référence unique 141, permettant des communications et des interfaces appropriées avec le monde extérieur. Un ou plusieurs bus de communication interne, sous la référence unique 144, réuni (ssen) t ces différents organes.

Le système 1 comprend naturellement d'autres organes nécessaires à son bon fonctionnement : alimentation en énergie, etc., habituels aux systèmes informatiques et qu'il n'y a pas lieu de décrire plus avant.

Selon une première caractéristique de l'invention, la mémoire 2 comprend une zone 20 permettant le stockage d'une suite d'enregistrements particuliers, que l'on appellera modèles ci-après, selon une configuration à deux dimensions. Cette configuration résulte d'un arrangement physique (mémoire dédiée) ou logique (carte d'adressage sous la commande du processeur 140) de la mémoire 2. Il peut s'agir en outre de zones de mémoire fixe ou semi-fixe (enregistrements"permanents"ou"semi-permanents"), ou encore de zones de mémoire vive (enregistrements chargés ou téléchargés au démarrage du système 1 par exemple). Tout ou partie de ces enregistrements peut être associé à des enregistrements complémentaires dans d'autres zones de la mémoire 2, référencées arbitrairement 21.

Pour mener à bien les opérations propres au procédé selon l'invention, on prévoit un certain nombre de dispositifs d'entrée et/ou sortie, notamment un

organe de visualisation 10 (écran cathodique, etc.), des organes de saisie de données, clavier 11 a et pointeur 11b (souris), par exemple, des lecteurs de supports de données, par exemple un lecteur de CédéROM ou de disquette, représentés sous la référence unique 12 et des moyens d'impression 13, notamment pour la production de documents"papiers"de certification 130.

Un programme généré par le système 1, et dont la cohérence a été vérifiée, peut être stocké sur le disque dur 142 ou sur un support externe (par exemple sur une disquette ou sur un disque optique gravé, si le système 1 dispose d'un graveur) et/ou être chargé directement dans la puce 40 d'une carte à puce 4, ou plus généralement d'un système embarqué ou d'un terminal léger, via des organes d'entrée-sortie appropriés 142. Ce programme peut aussi être transmis à un système éloigné par voie télématique.

Selon une caractéristique essentielle de l'invention, le procédé repose sur une entité que l'on appellera"document", concrétisé par un enregistrement en mémoire que l'on appellera "modèle", de format unique et comportant une pluralité de champs, dont certains peuvent être considérés comme facultatifs selon le niveau d'abstraction et le degré de formalisation.

La figure 2 illustre schématiquement une configuration d'une zone de mémoire 20, à deux dimensions, de la mémoire 2, destinée au stockage permanent ou temporaire de modèles. Ces modèles, symbolisés par des blocs, sont au nombre de douze dans l'exemple décrit (matrice 3x4), et portent les références 200a à 203c, respectivement.

De façon arbitraire, on a représenté, en niveaux verticaux (quatre lignes de la matrice 20), quatre niveaux d'abstraction (arbitrairement dénommés niveaux 0 à 3), représentés par les symboles"FSP","HLD","LLD"et"IMP", pour "Functional SPecification" (spécification fonctionnelle, le plus haut niveau), "High Level Design" (conception de haut niveau, niveau intermédiaire haut), "Low Level Design" (conception de bas niveau, niveau intermédiaire bas) et "IMPlementation" (implémentation, le plus bas niveau), respectivement, et repérés par les références numériques 200 à 203. Les trois colonnes de la matrice d'enregistrements 20 sont associées aux degrés de formalisation :

11 t 1 "informel","semi-formel"et"formel", et associés aux indices"a"à"c", respectivement.

Il existe également des liens entre les différents modèles (symbolisés par des traits fléchés sur la figure 2), liens de même niveau (appelés liens de formalisation), référencés lu et l'o, pour le niveau d'abstraction"FSP", à 13 et 1'3, pour le niveau d'abstraction"IMP", et liens inter-niveaux (appelés liens de raffinement), toi, t'oi et 1"or, entre les niveaux 0 ("FSP") et 1 ("HLD"), à 123, l'23 et 1"23, entre les niveaux 2 ("LLD") et 3 ("IMP"). Selon une autre caractéristique du procédé de l'invention, ces liens représentent des contraintes de cohérence que doivent respecter le code généré par le système 1. Ces contraintes dépendent de la position des "documents" dans l'espace à deux dimensions de la matrice 20. Les fonctions représentant un jeu de contraintes C peuvent donc être symbolisées de façon générale par une relation du type : C = f (NA, DF), dans laquelle NA est le niveau d'abstraction et OF le degré de formalisation.

On va maintenant décrire de façon plus détaillée les différents enregistrements stockés en mémoire, selon un exemple de réalisation pratique du procédé de l'invention.

Pour fixer les idées, sans que cela soit limitatif en quoi que ce soit de la portée de l'invention, un document, concrétisé en mémoire 2 (zone 20) par un "modèle", est constitué typiquement des champs suivants le caractérisant :

- un champ nom (constitué d'une chaîne de caractères) ; - un niveau d'abstraction (constitué par un code représentant"FSP","HLD", "LLD"ou"IMP"dans l'exemple décrit, ou simplement par ces caractères) ; - un ensemble d'attributs dénommés classes ; - une interface ; - des liens ; - un invariant ; - un graphe d'appel ; et - un protocole.

Les termes utilisés ci-dessus vont être précisés.

L'ensemble des "classes" est représenté par une adresse en mémoire d'une représentation de liste de noms, chaque nom désignant une classe.

L'interface est représentée par une adresse en mémoire d'une représentation de liste de noms, chaque nom désignant une opération. Les opérations listées sont celles qui sont accessibles de l'extérieur de l'application.

Pour l'application "porte-monnaie électronique" précitée, il s'agit par exemple d'une opération de"débit"et de"recharge".

Les liens sont représentés par une adresse en mémoire d'une représentation de liste de paires ; chaque paire étant constituée d'un nom de modèle et d'un type de lien (par exemple "raffinement" ou "formalisation").

L'invariant est représenté par une adresse en mémoire d'une représentation de propriété, qui peut être une chaîne de caractères quelconque dans le cas d'une représentation informelle, une chaîne de caractères conformément à une grammaire restreinte dans le cas d'une représentation semi-formelle, ou une chaîne de caractères conformément à une grammaire restreinte et possédant une sémantique précise dans le cas d'une représentation formelle. L'invariant est une propriété de l'état du modèle (ensemble des variables de ses classes) qui doit être maintenue en permanence par le code lors de son exécution sur la carte à puce, ou de façon plus générale sur le système embarqué. A titre d'exemple, toujours dans l'application précitée "porte-monnaie électronique", le montant du solde associé à ce porte-monnaie électronique doit rester supérieur à un seuil fixé.

Le graphe d'appel est représenté par une adresse en mémoire d'une représentation de graphe dont les noeuds sont des noms d'opérations. Le graphe d'appel représente les appels effectifs entre opérations du modèle.

Le protocole est représenté par une adresse en mémoire d'une représentation de graphe dont les noeuds sont des noms d'opérations. Le protocole représente les enchaînements possibles d'opérations de l'interface du modèle. A titre d'exemple, une application chargée sur une carte à puce doit être personnalisée avant de pouvoir être exécutée.

La configuration à format unique d'un modèle stocké en mémoire 2 est illustré par la TABLE 1 placée en fin de la présente description.

Certains champs peuvent être considérés comme facultatifs selon le niveau d'abstraction et le degré de formalisation associés au modèle. Pour indiquer cet état de fait, ils peuvent prendre une valeur prédéterminée, par exemple, la valeur numérique"-1", quand ils ne sont pas définis.

A titre d'illustration, la TABLE 1 présente le cas où l'invariant n'est pas requis pour une description informelle. Dans cet exemple le graphe d'appel et le protocole sont requis seulement pour les niveaux d'abstraction"HLD"et"LLD" des descriptions semi-formelles et formelles.

Lorsqu'on utilise une représentation semi-formelle, on peut faire appel à la notation dite"UML" ( Unified Modeling Language ), à l'aide de diagrammes de classes, d'états ou"states charts", selon l'appellation anglo-saxonne, ou de diagrammes d'activités.

Les différents champs rappelés ci-dessus sont, pour certains, constitués eux-mêmes d'enregistrements comprenant des champs. A leur tour, ces champs peuvent être constitués d'enregistrements comprenant des champs, comme il le sera précisé ci-après. Les données correspondantes sont enregistrées dans un ensemble de positions de mémoire qui ont été référencées de façon unique 21 sur la figure 1. Il existe donc une cascade d'enregistrements liés entre eux de façon hiérarchique. Ces différents champs vont maintenant être décrits de façon détaillée, dans un exemple de réalisation pratique.

La configuration du champ "classes" des "modèles" (TABLE 1) est détaillé dans la TABLE Il placée en fin de la présente description. Les classes regroupent des informations (c'est-à-dire des variables) et des opérations traitant d'un"type"de données particulier (par exemple "tableau d'enregistrements", "clef', "numéro d'identification", etc. ). Les classes comportent typiquement les champs suivants : - un nom (constitué d'une chaîne de caractères) ; - un modèle auquel la classe appartient (constitué d'une chaîne de caractères) ; - une qualité : statique ou dynamique - une visibilité, dite "publique" ou "privée" ; - un ensemble de variables ;

- un ensemble d'opérations ; - des liens ; et - un invariant.

Les termes utilisés ci-dessus vont être précisés.

Une classe statique représente un module alors qu'une classe dynamique correspond à un type. Elle peut être"instanciée"au sens des langages à objets.

Une classe dite"privée"n'est accessible que dans son modèle alors que l'accès à une classe dite"publique"n'est pas restreint.

L'ensemble de variables est représenté par une adresse en mémoire d'une représentation de liste de noms, chaque nom désignant une variable.

L'ensemble d'opérations est représenté par une adresse en mémoire d'une représentation de liste de noms, chaque nom désignant une opération.

Les liens sont représentés par une adresse en mémoire d'une représentation de liste de paires ; chaque paire étant constituée d'un nom de classe et d'un type de lien, par exemple "raffinement" ou "utilisation".

L'invariant est représenté par une adresse en mémoire d'une représentation de propriété qui peut être une chaîne de caractères quelconque dans le cas d'une représentation informelle, une chaîne de caractères conformément à une grammaire restreinte dans le cas d'une représentation semi-formelle, ou une chaîne de caractères conformément à une grammaire restreinte et possédant une sémantique précise dans le cas d'une représentation formelle. L'invariant est une propriété de l'état de la classe (ensemble de ses variables) qui doit être maintenue en permanence par la mise en oeuvre.

A titre d'illustration, la TABLE Il présente le cas où l'invariant n'est pas requis pour une description informelle.

La configuration du champ "variables" des "classes" (TABLE Il) est détaillée dans la TABLE III placée en fin de la présente description. Les variables comprennent les champs suivants : - un nom (constitué d'une chaîne de caractères) ; - une classe d'appartenance (constituée d'une chaîne de caractères) ;

- un type (constitué d'une chaîne de caractères) ; - une valeur initiale (constituée d'une chaîne de caractères) ; - une qualité dite"statique","dynamique"ou"constante" ; et - une visibilité dite"protégée""ou"privée".

Une variable dite"statique"représente une variable de classe (au sens des langages dits à objets, c'est à dire qu'elle est associée à la classe ellemême). Une variable dite"dynamique"représente une variable d'instance : elle est associée aux objets de la classe. Une variable de qualité dite"constante"ne peut être modifiée par une opération. Une variable dite "privée" n'est accessible que dans sa classe, alors qu'une variable dite"protégée"n'est accessible que de son modèle.

La configuration du champ "opérations" des "classes" (TABLE Il) est détaillée dans la TABLE IV placée en fin de la présente description. Les opérations comportent typiquement les champs suivants : - un nom (constitué d'une chaîne de caractères).

- une classe à laquelle elle appartient (constituée d'une chaîne de caractères).

- une visibilité dite"publique","protégée"ou"privée ; - une qualité dite "statique" ou "dynamique" ; - un prototype ; - une pré-condition ; - une post-condition ; - un ensemble de variables lues ; - un ensemble de variables modifiées ; et - un graphe de contrôle.

Les termes utilisés ci-dessus vont être précisés.

Une opération dite"privée"n'est accessible que dans sa classe, une opération dite"protégée"n'est accessible que de son modèle et l'accès à une opération dite"publique"n'est pas restreint.

Une opération dite"statique"représente une opération de classe (au sens des langages à objets, c'est à dire qu'elle est associée à la classe elle-

même) et une opération dite"dynamique"représente une opération d'instance.

Cette dernière est associée aux objets de la classe.

Un prototype est représenté par une adresse en mémoire d'une représentation de liste de triplets, chaque triplet étant constitué d'un nom de variable, d'un type et d'un genre (entrée ou sortie). Un prototype représente des paramètres (d'entrée et de sortie) d'une opération avec leurs types.

Une pré-condition est représentée par une adresse en mémoire d'une représentation de propriété qui peut être une chaîne de caractères quelconque dans le cas d'une représentation informelle, une chaîne de caractères conforme à une grammaire restreinte dans le cas d'une représentation semi-formelle, ou une chaîne de caractères conforme une grammaire restreinte et possédant une sémantique précise dans le cas d'une représentation formelle. Une précondition est une propriété de l'état du modèle (ensemble de ses variables) et des paramètres d'entrée qui doit être satisfaite au moment de l'appel de l'opération.

A titre d'exemple, si on considère de nouveau l'application"porte- monnaie électronique", le montant du solde doit excéder la valeur à débiter avant toute application de l'opération de débit.

Une post-condition est représentée par une adresse en mémoire sur une représentation de propriété qui peut être une chaîne de caractères quelconque dans le cas d'une représentation informelle, une chaîne de caractères conforme à une grammaire restreinte dans le cas d'une représentation semni-formelle, ou une chaîne de caractères conforme à une grammaire restreinte et possédant une sémantique précise dans le cas d'une représentation formelle. Une post-condition est une propriété de l'état du modèle (ensemble de ses variables) et des paramètres d'entrée et de sortie qui doit être satisfaite après l'exécution d'un appel à l'opération.

A titre d'exemple, toujours dans le cas de l'application"porte-monnaie électronique", pour l'opération débit, on doit produire un état tel que le montant du solde est décrémenté de la valeur du paramètre d'entrée de l'opération.

L'ensemble de variables lues, ainsi que l'ensemble de variables modifiées sont représentés par des adresses en mémoire d'une représentation de liste de noms, chaque nom désignant une variable.

Un graphe de contrôle est représenté par une adresse en mémoire d'une représentation de graphe dont les noeuds sont des noms d'opérations ou des structures de contrôle (branchements par exemple). Les arcs peuvent être étiquetés par des événements (résultat d'un test par exemple). Un graphe de contrôle représente la succession des opérations effectuées et les conditions qui président à leurs appels.

A titre d'illustration, la TABLE IV présente le cas pour lequel les champs "pré-condition","variables lues","variables modifiées"et"graphe de contrôle" ne sont pas requis pour une description informelle.

Selon une des caractéristiques essentielles du procédé de l'invention, le format unique décrivant la configuration des modèles permet de vérifier de façon automatique les règles de cohérence du code à générer par le système 1 (figure 1).

Ces règles peuvent être classées en deux catégories principales : des règles de cohérence dite"interne"et des règles de cohérence dite"de raffinement".

Les règles de cohérence dite"interne"assurent la bonne formation des modèles pris individuellement. A titre d'illustration, les règles suivantes peuvent être imposées à tout modèle : - Une interface doit regrouper toutes les opérations dites"publiques"du modèle (et aucune autre). Cette règle est vérifiée en parcourant simultanément la liste définissant l'interface et la succession des listes définissant les opérations des classes (en ne retenant de ces dernières que celles qui sont associées à la visibilité dite"publique").

- Un graphe d'appel du modèle ne doit pas inclure de liens qui n'apparaîtraient pas dans les graphes de contrôle des opérations concernées. Cette règle est vérifiée en deux étapes : la première étape consiste à construire, pour chaque opération, que l'on peut référencer 01, la liste des opérations 0, telles qu'il existe un arc reliant 01 à 0, dans le graphe

d'appel du modèle, et la seconde étape consiste à parcourir le graphe de contrôle de 01 pour s'assurer que toutes les opérations de la liste construite précédemment apparaissent dans ce graphe de contrôle.

- Un invariant d'un modèle ne doit pas impliquer de variables qui n'appartiennent pas à une classe du modèle. Cette règle est vérifiée en parcourant simultanément la liste définissant l'invariant et la succession des listes définissant les variables des classes.

- Un invariant d'un modèle ne doit pas être invalidé par une opération du modèle. Cette règle, qui est de nature sémantique, n'est pas vérifiable en toute généralité, ce conformément aux résultats d'indécidabilité des théories mathématiques. Le format unique préconisé par l'invention sert dans ce cas à engendrer la propriété à démontrer ("obligation de preuve") et la transmettre à un"démonstrateur"qui sera utilisé pour la vérifier (par exemple avec l'aide d'un utilisateur).

Les règles de cohérence dite"de raffinement"permettent de s'assurer de l'absence de contradiction entre deux niveaux d'abstraction adjacents, par exemple les niveaux"FSP"et"HLD" (figure 2).

A titre d'illustration, les règles suivantes peuvent être imposées à toute paire de modèles adjacents. Ces modèles sont appelés ci-après"modèle source"et"modèle raffiné", respectivement.

- les deux modèles possèdent la même interface ; - le graphe d'appel du modèle source est inclus dans le graphe d'appel du modèle raffiné ; - l'invariant du modèle raffiné implique l'invariant du modèle source ; - la pré-condition d'une opération du modèle source implique la pré-condition de l'opération correspondante dans le modèle raffiné ; et - la post-condition d'une opération du modèle raffiné implique la post- condition de l'opération correspondante dans le modèle source.

Le raffinement doit permettre d'atteindre (éventuellement en plusieurs étapes) la mise en oeuvre sans remettre en cause une spécification du système ou cahier des charges. Cette contrainte justifie la première règle (préservation de l'interface) et les trois dernières (préservation de l'invariant et des conditions

d'application et effets des opérations). Les opérations du modèle raffiné en particulier doivent pouvoir être utilisées à la place de leurs correspondantes dans le modèle source, qui constituent ce que l'on peut appeler un"contrat" qu'elles doivent respecter. La deuxième règle prend en compte le fait qu'un raffinement introduit des détails de mise en oeuvre, ce qui justifie l'ajout de nouvelles opérations.

Les trois dernières règles ci-dessus sont de nature sémantique et conduisent à des propriétés qui peuvent être vérifiées à l'aide d'un assistant de preuve (comme la préservation de l'invariant dans le cas des règles de cohérence interne). Les deux premières sont vérifiées par des parcours des structures définissant, respectivement, les interfaces des modèles, et leurs graphes d'appel.

Les règles de cohérence rappelées ci-dessus reposent sur les redondances qui existent entre diverses informations présentes dans un modèle. Ces redondances peuvent être exploitées d'une autre manière, en permettant de compléter automatiquement certains champs quand leur valeur peut se déduire des informations présentes par ailleurs dans le modèle. Par exemple, le champ "graphe d'appel" d'un modèle peut se déduire de l'ensemble des champs"graphe de contrôle"de ses opérations quand ils ont tous été complétés. Il suffit pour cela de parcourir le graphe de contrôle de chaque opération 0 en comptabilisant dans une liste les opérations 0, qui y apparaissent. Le graphe d'appel est alors constitué de l'ensemble des arcs (0, 0,). Cette technique permet d'offrir à un utilisateur un environnement de développement offrant une souplesse d'utilisation sans sacrifier pour autant sur la qualité du résultat.

Pour résumer ce qui vient d'être décrit de façon détaillée, le procédé de vérification de cohérence de codes destiné à un système embarqué selon l'invention comprend deux phases principales, chacune de ces phases étant elles-mêmes subdivisées en étapes.

Pendant la première phase, ou phase préliminaire, les différents enregistrements constituant les champs des modèles, présentant une configuration à format unique, sont stockés dans une ou plusieurs zones de la

mémoire 2 du système 1, que l'on a représenté arbitrairement sous la forme d'une zone unique 20, et définit un espace à deux dimensions ("degrés de formalisation"et"niveaux d'abstraction", respectivement). De même, certains des champs étant aussi divisés en champs et ses derniers champs divisés à leur tour en champs, les enregistrements correspondants sont stockés dans des zones déterminées 21 de la mémoire 2. Les différents modèles (200a à 203c) de l'espace à deux dimensions précité sont associés à des liens qui constituent des règles de cohérence à respecter. Ces règles sont également enregistrées dans la mémoire 2 ainsi que des règles dites internes régissant tout ou partie des champs.

Il est à noter que la phase appelée "préliminaire" peut elle-même se subdiviser avantageusement en des"sous-phases"ou étapes distinctes. Lors d'une première étape, les modèles sont enregistrés en mémoire, a priori une fois pour toutes. Lors d'une seconde étape, les règles de cohérence, notamment, peuvent être personnalisées en fonction d'applications et/ou d'utilisateurs spécifiques. Il s'agit donc d'une personnalisation .

Les modèles et les règles de cohérence dépendent naturellement des normes particulières de sécurité à respecter, par exemple les normes dites "Critères Communs" précitées. Il doit être cependant clair que le procédé de l'invention n'est pas limité à une norme particulière. S'il n'est pas possible de trouver un format unique générique à plusieurs normes, plusieurs jeux de modèles à format unique peuvent être stockés en mémoire, ce sans remettre en question le procédé de l'invention. Un choix préalable devra alors être effectué entre les différentes normes. Ensuite, quelle que soit la nature du code à générer et à vérifier, celui-ci pourra l'être en faisant appel au jeu de modèles à format unique sélectionné. La cohérence du code généré sera vérifiée dans ce cadre de modèles, ce quels que soient le "degré de formalisation"et/ou le "niveau d'abstraction"considéré (s).

On doit bien comprendre aussi que, bien que le format des modèles et de la cascade hiérarchique de champs successifs décrivant ces modèles soit unique, certains champs sont obligatoires alors que d'autres peuvent être optionnels, ce en fonction du"degré de formalisation"et/ou du"niveau

d'abstraction"considéré (s). Dans le cas où un champ optionnel ne serait pas effectivement présent, on peut lui affecter une valeur numérique prédéterminée, par exemple "-1" comme il a été décrit, représentatif de cet état de fait.

Du fait de la cascade hiérarchique de champs précitée, il est possible, de façon avantageuse, de remplir automatiquement certains champs à partir de données existantes par ailleurs dans d'autres champs.

Ces différents enregistrements, selon le type de mémoire considéré et/ou le système utilisé, les données correspondantes peuvent être résidentes dans la mémoire de façon permanente (mémoire fixe de type"ROM"par exemple) ou semi-permanente (mémoire re-programmable de type"EEPROM"), ou encore peuvent être chargées (à partir d'un disque dur) ou téléchargées (via un dispositif d'entré/sortie) dans une mémoire vive ("RAM"), par exemple lors d'une phase initiale de démarrage du système.

Lors d'une phase ultérieure du procédé, que l'on peut qualifier de phase opérationnelle, un opérateur charge des données, via des organes de saisie et/ou de pointage (figure 1 : clavier 11 a et souris 11b) et des moyens d'entrées de données (par exemple un lecteur de CédéROM ou de disquette 12), en vue de la construction d'un code particulier destiné à un système embarqué (par exemple une application de type "porte-monnaie électronique").

Ces données comprennent notamment le code proprement dit, dans un langage informatique déterminé, ou des spécifications. Ces données comprennent en outre des spécifications plus spécifiques à l'invention relatives au"degré de formalisation"et/ou au"niveau d'abstraction"à respecter.

L'élaboration du code et, selon un aspect important du procédé selon l'invention, la vérification de sa cohérence en tenant compte des données préalablement stockées pendant la phase préliminaire (modèles à format unique, règles, etc. ) s'effectuent sous le contrôle et la commande du processeur 140 (figure 1) et, de façon classique en soi, de programmes supplémentaires enregistrés (non représentés) dans une mémoire fixe et/ou chargés et/ou téléchargés dans une mémoire vive (par exemple des zones prédéterminées de la mémoire 2).

Un opérateur humain (non représenté) peut surveiller le processus et intervenir le cas échéant grâce aux moyens de visualisation 10 eVou de saisie de données (par exemple 10a et 10b). Des itérations peuvent être nécessaires pour obtenir un résultat correct, par exemple si incohérences sont détectées par le système.

Une fois le code élaboré conformément aux modèles stockés et sa cohérence vérifiée par rapport aux règles précitées, le code peut être stocké sur le disque dur 142 eVou téléchargé directement dans le système embarqué, notamment dans la mémoire (non représentée) de la puce électronique 40 de la carte à puce 4, via des organes d'entrée/sortie 141 appropriés. Il peut également être sauvegardé, de façon connue en soi, sur tout support de données externe : disquette, CédéROM, bande magnétique (par exemple du type dit"DAT"), etc., ou encore transmis à une station éloignée par voie télématique, ce pour un usage ultérieur.

Selon un mode de réalisation préféré, le procédé selon l'invention permet la production, de façon automatique, à partir du code construit et vérifié, de documents de certification, quel que soit le niveau d'abstraction atteint, conforme à un standard ou une norme particulière, par exemple les "Critères Communs de sécurité"précités. La structure de ces documents s'appuie sur le format unique de modèle, et plus précisément est fonction de la"position"du modèle dans l'espace à deux dimensions précité.

De même que pour le code, il est possible de produire des documents pour une certification à un niveau donné en s'appuyant sur des modèles antérieurement produits pour une certification antérieure à un niveau inférieur. Naturellement, il est nécessaire que les données antérieurement générées aient été sauvegardées, sous une forme ou une autre.

De façon pratique, un exemplaire papier 130 peut être obtenu à l'aide d'une imprimante 13 ou d'un organe similaire. Le document en question peut également être généré sous forme de document électronique, fichier accompagnant le code généré (sous un format de fichier standard, par exemple de type texte), enregistré sur un support de donné, ou transmis par voie

télématique à une autorité de certification, en adoptant toutes mesures de sécurisation nécessaires (chiffrage, signature électronique, etc.).

A la lecture de ce qui précède, on constate aisément que le procédé de l'invention atteint bien les buts qu'il s'est fixés.

Il permet notamment, en s'appuyant sur des modèles à format unique, définissant un espace à deux dimensions, de construire des codes destinés à des systèmes embarqués ; notamment des cartes à puce, et surtout de vérifier qu'ils satisfont des contraintes de cohérences prédéterminées, ce sans nécessiter d'avoir recours à des procédures extrêmement longues et coûteuses.

Il permet également de produire automatiquement des documents de certification à un niveau préétabli.

Il permet enfin de produire des documents de certification d'un niveau élevé en s'appuyant sur des documents de certification d'un niveau moins élevé antérieurement produits.

Il doit être clair cependant que le procédé selon l'invention n'est pas limité aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1 et 2.

Comme il a été également indiqué, le procédé selon l'invention n'est pas limité à la vérification de cohérence de codes destinés aux seules applications à base de cartes à puce, mais permet la vérification de cohérence de codes destinés à toutes sortes de systèmes embarqués, et de façon plus générale de terminaux qui ont été appelés "légers".

TABLE 1 : Modèles

<tb>
<tb> CHAMPS <SEP> Obligatoire
<tb> Nom <SEP> Obligatoire
<tb> Niveau <SEP> d'abstraction <SEP> Obligatoire
<tb> Classes <SEP> Obligatoire
<tb> Interface <SEP> Obligatoire
<tb> Liens <SEP> Obligatoire
<tb> Informel <SEP> Semi-formel <SEP> formel
<tb> Invariant <SEP> Optionnel <SEP> Obligatoire <SEP> Obligatoire
<tb> Graphe <SEP> d'appel <SEP> Optionnel <SEP> Obligatoire <SEP> Obligatoire
<tb> (à <SEP> partir <SEP> de"HLD")
<tb> Protocole <SEP> Optionnel <SEP> Obligatoire <SEP> Obligatoire
<tb> (à <SEP> partir <SEP> de"HLD")
<tb>
TABLE Il : Classes

<tb>
<tb> CHAMPS <SEP> Obligatoire
<tb> Nom <SEP> Obligatoire
<tb> Modèle <SEP> Obligatoire
<tb> Visibilité <SEP> Obligatoire
<tb> Variables <SEP> Obligatoire
<tb> Opérations <SEP> Obligatoire
<tb> Liens <SEP> Obligatoire
<tb> Informel <SEP> Semi-formel <SEP> formel
<tb> Invariant <SEP> Optionnel <SEP> Obligatoire <SEP> Obligatoire
<tb>

TABLE III : Variables

CHAMPS Obligatoire Nom Obligatoire Classe Obligatoire 1 Type Obligatoire Valeur initiale Obligatoire Qualité Obligatoire Liens Obligatoire

TABLE IV : Opérations

CHAMPS Obligatoire Nom Obligatoire Classe Obligatoire Visibilité Obligatoire Qualité Obligatoire Prototype Obligatoire Informel Semi-formel formel Pré-candi tion Optionnel Obligatoire Obligatoire Post-condition Obligatoire Obligatoire Obligatoire Variables lues Optionnel Obligatoire Obligatoire Variables modifiées Optionnel Obligatoire Obligatoire Graphe de contrôle Optionnel Obligatoire Obligatoire (à partir de"LLD")

Claims

REVENDICATIONS 1. Procédé de vérification de cohérence de codes destinés à un système embarqué, notamment une carte à puce, à l'aide d'un système informatique comprenant au moins un processeur de traitement de données numériques, des moyens de mémoire et des moyens d'entrée/sortie de données, caractérisé en ce qu'il comprend au moins : une phase préliminaire comprenant au moins une étape de stockage dans lesdits moyens de mémoire (2) d'au moins un premier jeu d'enregistrements (20), chacun constituant un modèle (200a-203c) comportant un nombre déterminé de champs configurés suivant une structure de format unique, lesdits modèles définissant un espace à deux dimensions hiérarchisé, une première dimension étant constituée par un premier paramètre définissant un niveau d'abstraction associé au dit code et une seconde dimension étant constituée par un second paramètre définissant un degré de formalisation associé à la représentation dudit modèle, et une deuxième étape de stockage dans lesdits moyens de mémoire (2) d'au moins un deuxième jeu d'enregistrements (21) comprenant des règles de cohérence à observer ; et - une phase ultérieure comprenant au moins les étapes suivantes : a/au moins l'entrée dans ledit système (1) de données numériques définissant un desdits niveaux d'abstraction et un desdits degrés de formalisation à associer au dit code de manière à adresser un desdits modèles stockés en mémoire et un jeu de règles de cohérence à observer stockées en mémoire (2) ; et b/la vérification dudit code sous la commande dudit processeur de traitement de données (140) par utilisation dudit modèle adressé et dudit jeu de règles de cohérence à observer.
2. Procédé selon la revendication 1, caractérisé en ce que ledit deuxième jeu d'enregistrements (21) comprenant des règles de cohérence à observer est

<Desc/Clms Page number 24>

personnalisé en fonction d'une utilisation prédéterminée, avant stockage en mémoire (2).
3. Procédé selon la revendication 1, caractérisé en ce que lesdites règles de cohérence à observer comprennent un premier jeu constitué de règles de cohérence internes aux dits modèles et un deuxième jeu de règles de cohérence dites de raffinement constituant des liens entre modèles (200a- 203c) dudit espace à deux dimensions.
4. Procédé selon la revendication 1, caractérisé en ce que lesdits niveaux d'abstraction sont au nombre de quatre et comprennent, en allant du niveau hiérarchique le plus haut au plus bas, un niveau dit de spécification

fonctionnelle (200a-200c), un niveau dit de conception de haut niveau (201a- 201c), un niveau dit de conception de bas niveau (202a-202c) et un niveau dit d'implémentation (203a-203c).
5. Procédé selon la revendication 1, caractérisé en ce que lesdits degrés de formalisation sont au nombre de trois et comprennent, en allant du niveau hiérarchique le plus haut au plus bas, des niveaux pour lesquels la description desdits champs est effectuée de manière formelle, semi-formelle et informelle, respectivement.
6. Procédé selon la revendication 1, caractérisé en ce que ladite phase préliminaire comprend des étapes de stockage en mémoire (2) de plusieurs jeux supplémentaires d'enregistrements sur plusieurs niveaux en cascade, chaque jeu d'enregistrements étant associé à au moins un champ du jeu de niveau immédiatement supérieur.
7. Procédé selon la revendication 6, caractérisé en ce que lesdits modèles comprennent les champs suivants : - un champ représentant le nom dudit modèle ; - un champ représentant ledit niveau d'abstraction ;

<Desc/Clms Page number 25>

- un champ associé à un ensemble d'attributs dits de classes, représenté par une adresse dans ladite mémoire d'un enregistrement d'une représentation d'une liste de noms, chacun desdits noms désignant une classe déterminée ; - un champ dit d'interface, représenté par une adresse dans ladite mémoire d'un enregistrement d'une représentation d'une liste de noms, chacun desdits noms désignant une opération déterminée ; - un champ définissant des liens, représenté par une adresse dans ladite mémoire d'un enregistrement d'une représentation d'une liste de paires, chacune desdites paires étant constituée d'un nom d'un desdits modèles et d'un type de lien déterminé représentant une desdites deux dimensions ; - un champ dit d'invariant, représenté par une adresse dans ladite mémoire d'un enregistrement de propriété, la structure de ladite propriété étant dépendante dudit degré de formalisation, ledit invariant étant constituant une propriété de l'état dudit modèle devant être maintenu en permanence lors d'une exécution dudit code dans ledit système embarqué (4) ; - un champ définissant un graphe d'appel, représenté par une adresse dans ladite mémoire d'un enregistrement d'une représentation de graphe possédant des noeuds représentant des noms d'opération, ledit graphe d'appel représentant des appels effectifs entre des opérations dudit modèle ; et - un champ définissant un protocole, représenté par une adresse dans ladite mémoire d'un enregistrement d'une représentation de graphe possédant des noeuds représentant des noms d'opération, ledit protocole représentant des enchaînements possibles d'opérations de ladite interface dudit modèle.
8. Procédé selon la revendication 6, caractérisé en ce qu'il comprend une étape consistant à compléter automatiquement au moins une partie desdits champs à partir de données présentes dans d'autres champs.
9. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, lors de ladite phase ultérieure, une étape supplémentaire de production de documents de certification d'un niveau déterminé (130), associés audit code,

<Desc/Clms Page number 26>

par utilisation dudit modèle adressé et dudit jeu de règles de cohérence utilisé pour la vérification de cohérence dudit code.
10. Procédé selon la revendication 9, caractérisé en ce que lesdits documents de certification sont conformes aux normes dites"Critères Communs" (norme ISO/IEC 15408).
11. Procédé selon la revendication 1, caractérisé en ce qu'il permet, lors de ladite phase ultérieure, de s'appuyer sur un niveau de formalisation pour construire les données correspondant à un niveau de formalisation supérieur.