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