Mise en sécurité des Logiciels

Présentation au sujet: "Mise en sécurité des Logiciels"— Transcription de la présentation:

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 Processus de développement et de validation
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: Solutions:
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 (2kx, -rkx +Bx +D) avec 2k>A
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 Z est développé lors du séjour de JR Abrial au sein du Programming Research Group 1985 C. Morgan introduit le raffinement JR Abrial développe la méthode B pour British Petroleum industrialisation de la méthode B et application METEOR 18 Janvier 2001

17 Caractéristiques (1) Orientée Modèle: Séquentielle et ininterruptible
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 MACHINE STACK ( 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 Machine Raffinement Implementation
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 Cycle de développement
spécification littérale du logiciel tests fonctionnels ré-expression formelle en B conception formelle génération de programme (automatique) intégration logicielle preuve 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 Modélisation Tests Fonctionnels 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