Mise en sécurité des Logiciels

Slides:



Advertisements
Présentations similaires
Yassine Lakhnech Prof. UJF Verimag
Advertisements

EPITECH 2009 UML EPITECH 2009
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Analyse et Programmation Orientées Objets
Tests et Validation du logiciel
Eléments de Génie Logiciel
Processus d'expression du besoin
La Recette La recette.
La Gestion de la Configuration
La sécurité informatique
QSL,27 Novembre Vérification probabiliste Université Paris II Michel de Rougemont 1.Algorithmes probabilistes qui.
2002 Exploratoire ASTRÉE : Analyse Statique de logiciels Temps-RÉel Embarqués 1)Le problème considéré est de démontrer statiquement (à la compilation)
Structures de données et complexité
Spécification et qualité du logiciel
Validation des Systèmes Informatisés Industriels
Cours n° 8 Conception et Programmation à Objets
M.E.D.A.L. Module dEnseignement à Distance pour lArchitecture Logicielle Alain VAILLY Diapositive n° 1 IUP MIAGE - Université de NANTES IUP-MIAGE 3ème.
Régine Laleau Centre d'Étude et de Recherche en Informatique du CNAM
UML - Présentation.
Les démarches de développement
Les démarches de développement
TP 3-4 BD21.
Processus de validation basée sur la notion de propriété
Cours DESS Nantes 04 Décembre 2002
Quoi ? Un tampon.
INTRODUCTION.
L ’étude de coûts du secteur privé (données 1998)
Processus de validation basée sur la notion de propriété
1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.
Le Marketing Une revue ….. Come 2001 Come 2001.
RESUMES Module II1 SOMMAIRE CYCLE 1 : Saisir – Afficher – Données
Introduction à la conception de Bases de Données Relationnelles
DeltaPROD Suivi des interventions Gestion de configuration
Mai 2001FRANCOROIII - Challenge Recherche Locale Guidée Par Le Coût Des Contraintes Gavranovic Haris Univerzitet U Sarajevu IMAG, Grenoble.
Techniques de test Boulanger Jean-Louis.
Structures de données IFT-2000 Abder Alikacem Standard Template library Édition Septembre 2009 Département dinformatique et de génie logiciel.
MOT Éditeur de modèles de connaissances par objets typés
Thème 8 : l'observation et l'expérimentation
Présentation du mémoire
CSI3525: Concepts des Languages de Programmation
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
Partie II Sémantique.
Programmation non procédurale Le projet ECOLE 2000
NORMALISATION DES LANGAGES DE PROGRAMMATION des Automates Programmables Industriels CEI Jean-Jacques DUMÉRY -1-
Sensibilisation a la modelisation
Modélisation des opérations Spécifier les transformations détat que lon attend des services de la machine Létat dune machine entièrement déterminée par.
Achat en ligne Université de Montréal Présentation par Renée Pelletier, Directrice Division approvisionnements, Direction des finances.
NORMALISATION DES LANGAGES DE PROGRAMMATION des Automates Programmables Industriels CEI
ANALYSE METHODE & OUTILS
Spécification de Demoney en JML par raffinement Pierre-Alain Masson, Julien Groslambert LIFC Besançon Réunion GECCOO - 10 mars 2006 FRE 2661.
Cours Architecture des Systèmes Informatiques
30 Janvier 2002 Club SEE 63 "Systèmes Informatiques de Confiance" 1 Vérification de spécification de logiciel critique Jean-Louis Boulanger RATPEST/ITF/AQL.
Supports de formation au SQ Unifié
Algorithmique et programmation (1)‏
13/12/2006Journée IGCS Bourgogne - d'après Bruno CHEVALIER, 2001 Relations entre la Sensibilité des Sols et le Couvert Forestier Réalisation d’une typologie.
Un survol du language C.
Un outil d’estimation du temps d’exécution au pire-cas par analyse statique de programmes IRISA - Projet Solidor Antoine COLIN.
Introduction au Génie Logiciel
1 École des Mines de Saint-Etienne. 158, cours Fauriel Saint-Etienne Cedex 2. Tél Fax Jean-Jacques Girardot
François CARCENAC,Frédéric BONIOL ONERA-DTIM Zoubir MAMMERI IRIT
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Conception Formelle en PVS Master 2 ISC Chef de Projet: M. Pierre Castéran Présenté par: Roland Atoui Xavier Dumas Sébastien Jardel Laurent Vendredi.
INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Flot de conception de.
L’enseignement de spécialité SLAM
Les démarches de développement
2 Tracks Unified Process
Application ferroviaire et COTS
Introduction Module 1.
19 avril Spécification d’un cadre d’ingénierie pour les réseaux d’organisations Laboratoire de recherche : OMSI à l’EMSE.
Transcription de la présentation:

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

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

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

Hypothèses 18 Janvier 2001

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

Processeur Sécuritaire Codé 18 Janvier 2001

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

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

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

(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

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

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

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

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

La méthode B 18 Janvier 2001

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

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

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

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

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

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

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

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

Processus de développement 18 Janvier 2001

Séparation code/données 18 Janvier 2001

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

Procesus de Validation 18 Janvier 2001

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

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

Et pour demain ... 18 Janvier 2001

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

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

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

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

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

Conclusions - Questions 18 Janvier 2001