18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL.
-
Upload
deodat-marin -
Category
Documents
-
view
103 -
download
0
Transcript of 18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL.
18 Janvier 2001 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 pileMACHINE 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 consistant1. Modèle non vide2. Les Opérations préservent l’invariant
PO : cohérence du raffinement L’initialisation et les opérations préservent la sémantique du niveau supérieur
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éesSpécification
logicielle
EXECUTABLE
Description de la ligne
Modèle B
Invariant de BesoinCode ADA sécurisé
Caractéristiquedes trains
18 Janvier 2001 26
Cycle de développement
spécification littéraledu logiciel
tests fonctionnels
ré-expressionformelle en B
conceptionformelle
génération deprogramme
(automatique)
intégrationlogicielle
preuve
preuvepreuve
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 FonctionnelleEquipement
Spécification Logicielle
EXECUTABLE
Tests FonctionnelsModélisation
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