1 / 36

Mise en sécurité des Logiciels

Mise en sécurité des Logiciels. Boulanger Jean-Louis RATP ESE/ICH/AQL. Le Laboratoire ICH/AQL. Atelier de Qualification des Logiciels, Premier Laboratoire français à être accrédité par le COFRAC dans le cadre du programme 152 pour les essais: SUR1, SUR2, (vérification de spécification)

noam
Download Presentation

Mise en sécurité des Logiciels

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL 18 Janvier 2001

  2. Le Laboratoire ICH/AQL • Atelier de Qualification des Logiciels, • Premier Laboratoire français à être accrédité par le COFRAC dans le cadre du programme 152 pour les essais: • SUR1, SUR2, (vérification de spécification) • SUR 6, (traçabilité) • SUR11, SUR 13 (vérification fonctionnelle) • SUR14 (analyse d’impact) 18 Janvier 2001

  3. Sommaire • Hypothèses • Processeur Sécuritaire Codé • La méthode B • Processus de développement et de validation • Et pour demain ... • Conclusions - Questions 18 Janvier 2001

  4. Hypothèses 18 Janvier 2001

  5. Hypothèses • Pour le métro, il existe un état de sécurité: l’arrêt. • La RATP fixe actuellement deux contraintes pour le développement des logiciels critiques (SSIL>2): • Utiliser la méthode formelle B, • Utiliser le processeur sécuritaire codé (PSC). 18 Janvier 2001

  6. Processeur Sécuritaire Codé 18 Janvier 2001

  7. PSC • Problèmes matériels dûs à l’environnement: • Perturbations électromagnétiques • Vibrations. • Solutions: • Transmissions numériques, • Processeurs codés. 18 Janvier 2001

  8. Principes • La sécurité repose sur le codage des informations et des traitements, • Codage arithmétique séparable, • Contrôle de signatures. 18 Janvier 2001

  9. Matériel • Architecture mono-processeur, • Processeur standard, • Famille des 68000 • Matériel périphérique dédié. 18 Janvier 2001

  10. Codage • Chaque donnée est constituée de deux champs: • Le champ «information», • Le champ «contrôle de longueur fixe» : • Reste de la div entière de l’info par la clé du code, • Signature statique Bx (trace des antécédents) • Signature dynamique D (validité temporelle) (2kx, -rkx +Bx +D) avec 2k>A 18 Janvier 2001

  11. Contrôle des signatures • Vérifier que les signatures statiques sont égales aux valeurs prédéterminées, • Vérifier que la signature dynamique évolue correctement à chaque itération. 18 Janvier 2001

  12. Ce qu’il prend en charge.. • Le PSC peut détecter • les erreurs d’opération, • bonne opérande et bon opérateur mais mauvais calcul • les erreurs d’opérandes ou d’opérateur, • la présence d’une donnée erronnée, • la tentative d’exécution d’une instruction non prévue, • les erreurs de rafraichissement, • les débordements de pile, • les mauvais accès de tableau, • .... 18 Janvier 2001

  13. Ce qu’il provoque ... • En cas de détection d’un problème, le PSC garantit l’arrêt du train. 18 Janvier 2001

  14. Utilisation • SACEM • VAL de Chicago • MAGGALY • ... • METEOR • ASTREE 18 Janvier 2001

  15. La méthode B 18 Janvier 2001

  16. Historique • 1979-1981 • Z est développé lors du séjour de JR Abrial au sein du Programming Research Group • 1985 • C. Morgan introduit le raffinement • 1988-1991 • JR Abrial développe la méthode B pour British Petroleum • 1994-1995 • industrialisation de la méthode B et application METEOR 18 Janvier 2001

  17. Caractéristiques (1) • Orientée Modèle: • comme Z et VDM • Séquentielle et ininterruptible • Orientée Objet: • lien de structuration et module. 18 Janvier 2001

  18. Caractéristiques (2) • La méthode B permet le développement incrémental de spécifications jusqu’à leurs implémentations. • Une seule notation pour les trois niveaux • La méthode est basée sur la PREUVE 18 Janvier 2001

  19. Concept (1) • Les machines abstraites sont composées de trois parties: • la partie déclarative (description de l’état+propriétés): • Théorie des ensembles • Logique du premier ordre • la partie de composition • la partie exécutive (opération faisant évoluer l’état) • Substitution Généralisée 18 Janvier 2001

  20. Exemple: une pile MACHINESTACK ( max) CONSTRAINTS max Î NAT1 SEES OBJECT VARIABLES stack INVARIANT stack Î seq(Object) Ù size(stack) <= max INITIALISATION stack := <> OPERATIONS PUSH (XX) =PRE XX Î Object Ù size(stack) < max THEN stack := stack ¬ XX END; XX ¬ POP = PRE size(stack) > 0 THEN XX,stack := last(stack),front(stack) END END 18 Janvier 2001

  21. De la spécification à l’implantation • 3 niveaux de détail: • la MACHINE • «non séquentielle, non déterministe» • le(s) REFINEMENT • introduit plus de détail mais doit préserver les caractéristiques «non séquentielles, non déterministes» • l’IMPLEMENTATION • séquentielle et déterministe 18 Janvier 2001

  22. Validation du Modèle PO : Le modèle est consistant 1. Modèle non vide 2. Les Opérations préservent l’invariant Machine Raffinement PO : cohérence du raffinement L’initialisation et les opérations préservent la sémantique du niveau supérieur Implementation 18 Janvier 2001

  23. Ce qu’elle prend en compte • Correction statique du typage, au travers des PO. • débordement, • accès hors borne, • mauvaise utilisation (division par 0, ...) • Correction de l’utilisation des opérations au travers de la vérification du respect des pré-conditions. 18 Janvier 2001

  24. Processus de développement 18 Janvier 2001

  25. Séparation code/données 18 Janvier 2001

  26. spécification littérale du logiciel tests fonctionnels preuve ré-expression formelle en B intégration logicielle preuve conception formelle preuve génération de programme (automatique) Cycle de développement 18 Janvier 2001

  27. Procesus de Validation 18 Janvier 2001

  28. Processus RATP • Le processus de validation des logiciels critiques de la RATP s’appuie sur deux activités: • Un contrôle de l’industriel sur l’ensemble du processus. • Une double validation • des logiciels critiques, • des données manipulées par les logiciels critiques. 18 Janvier 2001

  29. Double Validation Cahier des charges Fonctionnel Spécification Fonctionnelle Equipement Tests Fonctionnels Modélisation Spécification Logicielle EXECUTABLE 18 Janvier 2001

  30. Et pour demain ... 18 Janvier 2001

  31. Europe • Suite à l’ouverture des marchés dans le cadre de l’EUROPE, la RATP se doit de respecter la réglementation européenne pour les appels d’offre, la RATP ne peut donc plus avoir les mêmes exigences. 18 Janvier 2001

  32. D’autres architectures .. • Les industriels commencent à proposer l’utilisation d’une architecture matérielle 2 parmi 3 avec voteur logiciel ou matériel. 18 Janvier 2001

  33. D’autres langages ... • Dans le cadre des marchés européens, la RATP peut recommander l’utilisation d’une méthode formelle, mais pas l’exiger. 18 Janvier 2001

  34. D’autres techniques .. • L’outil PolySpace Verifier • Recherche des erreurs d’exécution, • Identification des opérations à risque, • Indépendant de l’architecture. 18 Janvier 2001

  35. PolySpace • La RATP a mené une étude sur un équipement en cours d’utilisation qui a déjà fait l’objet d’une validation. • Bilan: • Non respect de la norme ADA83 (non initialisation de paramètres «in out»), • Une boucle infinie, • Du code mort. 18 Janvier 2001

  36. Conclusions-Questions 18 Janvier 2001

More Related