Diapositiva 1

1
Prof. S.Bistarelli
Seminario di Sicurezza
Tecniche di controllo formale
Martino Angela
a.a. 2007-2008
2
Cosa sono

• Sono dei linguaggi che vengono usati per la
  rappresentazione del comportamento e la
  descrizione di sistemi informatici.

Venire incontro alle esigenze.
- Sintassi ben definita. - Semantica di
base. - Sistema logico-matematico come
struttura sottostante.
Approccio induttivo vs Model
checking technique
Premesse ? Proprietà
Logica temporale tabella di verità
Utilizzo, grado di automazione, completezza,
dominio, pre/post sviluppo
3
Inductive verification tecnique

• Usate per problematiche poco complesse.
• Forniscono tecniche per provare teoremi.
• Mostrano come una specifica di sistema incontra
  un insieme di proprietà.
• Più step.
• Theorem prover (trova prove intermedie).
• Interazione con lutilizzatore (lemmi).
• Fase di progettazione del prodotto.

Model checking technique
Ammette stati transitori - Fatto su misura per
lo strumento che lo utilizza - Poche interazioni
- Equivalenza modello e proprietà desiderata
- Test sui prodotti -
4
Specifiche formali
E la descrizione dettagliata delle
caratteristiche di un sistema o di un programma.
E una specifica scritta in un linguaggio formale
con una sintassi ristretta e ben definita basata
su concetti matematici fondamentali.
Special

• E un linguaggio di primo livello basato sulla
  logica e sviluppato da SRI international.
• Linguaggio non procedurale.
• Ricchezza espressiva (Union, Diff, End, Or,
  forAll, ?, If-Then-Else)

- Moduli (Predefiniti, funzioni, parametri,
asserzioni, tipi di dato)
gt manipolazione
Designator, Boolean..
Costruiti intorno al modulo, usati per la
dimostrazione di teoremi.
Globali o interne, informazioni sullo stato del
sistema.
5
Le prime tecniche di verifica formale
I primi metodi cercavano di meccanizzare e
formalizzare le fasi di sviluppo di alcuni
processi, portando ai moderni modelli di
controllo e allanalisi di protocolli di
comunicazione.
Tra i primi
The Enhanced Hierarchical Development Methodology
(EHDM)
Forniva modelli di progettazione per
limplementazione di specifiche e verifiche
usando il concetto di successivi miglioramenti
delle stesse. Si creava una gerarchia di macchine
astratte ed il passaggio delle informazioni in
essa accresceva il livello di dettaglio.
La macchina astratta(AM) era dotata di un insieme
di moduli di specifiche scritte in Special,
strumenti di supporto, controlli sintattici,
mappe tra coppie di macchine
6
The Hierarchical Development Methodology (EHDM) Hd
m of sri international
E una metodologia pensata come una Struttura
gerarchica di base che doveva essere di supporto
alle fasi di progettazione e implementazione di
programmi generici
Supporta la descrizione di un sistema a vari
livelli di astrazione usando uno specifico
linguaggio,tecniche di verifica per dimostrare
che i successivi livelli di astrazione fossero
consistenti
Multilevel Security Tool MLS tool il primo model
checking
MLS generator per generare formule per raffinare
le specifiche (Vc)
Linput fornito era una specifica formale in
SPECIAL
Strumento completamente automatico per verificare
le proprietà del sistema,le violazioni delle
specifiche descrittive
Theorem prover processava le formule del
programma e forniva una lista di quelle che
fallivano/superavano il test
7
I livelli di astrazione di HDM
Requirements
La gerarchia inizia con lanalisi e
laccettazione di alcuni requisiti
Model
che venivano estesi in un modello coerente che
veniva testato e rappresentava la base delle
verifiche degli altri livelli
External interfaces AM1
La prima A.M. era generalmente uninterfaccia per
specifiche fornite dallesterno. Attraverso le
funzioni implementate in termini di chiamate al
livello più basso, i programmi venivano scritti
in un linguaggio comprensibile al livello
successivo (linguaggio intermedio).
Abstract machine AM2
Il più basso livello è rappresentato dalla
macchina primitiva, vista come una combinazione
di hw e sw, che verificava il processo in
esecuzione.
Primitive machine AMn
8
Il funzionamento
In ogni macchina astratta venivano implementate
delle funzioni in termini di chiamate al livello
più basso che erano riunite in un programma.. Il
programma risultante veniva mandato ad un
traduttore che lo indirizzava nel Common Internal
Form (CIF), che lo rendeva comprensibile agli
strumenti del sistema il quale usando la traccia
i due livelli di specifiche erano tradotte in un
linguaggio intermedio. Questo linguaggio insieme
al CIF generava condizioni di verifica al
dispositivo Boyer-Moore theorem prover.
Lesattezza del CIF (corrispondenza con il
programma) implicava la correttezza della reale
implementazione
verifica
AMk
Translator
Linguaggio intermedio
CIF
Mapping specification
Verification condition generator
AMk1
Specifica del modello
Theorem prover
Proof results
9
.
The Boyer-Moore Theorem Prover
Lutente deve fornire assiomi,teoremi,lemmata,
necessari durante il processo dimostrativo
(rispetto di proprietà transitiva/riflessiva/simme
tria).
Conoscenze dellutente
VCs Verification Condition, condizioni che
dovevano essere verificate provenienti dal
Generator.
Traccia delle vecchie dimostrazioni
Eseguiva la formula in una serie di passi
- Semplificare la formula (uso costrutti
logici,lemmi). - Riformulare la dichiarazione
scambiando termini con altri più facili. -
Eguaglianze sostitutive sostituire i vincoli con
altri equivalenti. - Generalizzare la formula
variabili al posto delle regole già dimostrate. -
Eliminazione dei termini irrilevanti. -
Induzione per provare teoremi quando necessario
Usciva appena ritornava una soluzione altrimenti
andava al passo successivo.
10
Prototipe Verification System
Fu costruito come un prototipo da utilizzare per
la verifica di modelli quali EHDM e HDM Mette a
disposizione specifiche di controllo,
dimostrazioni in un linguaggio leggibile ma non
forniva una dettagliata metodologia di sviluppo ?
serve per spiegare dimostrazioni e teoremi in
passi successivi
Strumenti
Si serve di un dispositivo di dimostrazione di
teoremi molto interattivo Theorem prover.
Proof checker Strumento di controllo
(grammaticale e sintattico).
Declaration Dichiarazioni per la teoria.
Libreria interna Preludes.
Costrutti Sottotipi, record, tipi di dato.
11
Il processo dimostrativo si divide in 4 fasi

1. Fase esplorativa La specifica viene ripulita.
2. Fase di sviluppo Si lavora sullefficienza della
   dimostrazione.
3. Fase di presentazione La prova viene
   ulteriormente raffinata e controllata.
4. Generalizzazione Si analizza la dimostrazione
   per apprendere.

Il proof checker analizza la conclusione,
progressivamente ricava deduzioni, scopre dei
sottobiettivi e le fasi vengono ripetute fino al
raggiungimento del sottobiettivo più banale,
controllando che i vincoli vengano rispettati.
Deduzioni primitive - Regole proposizionali
Tagliare il problema in parti più piccole. -
Regole per quantificare Variabili di tipo non
numerico. - Regole di eguaglianza Come il
rimpiazzo di una parte di eguaglianza premessa da
unaltra. - Lemmi, assiomi, procedure
decisionali
12
Symbolic Model Verifier (SMV)
E basato sulla logica degli alberi logici (CTL)
alle connessioni è attribuito un peso temporale.
La connessione è rappresentata da 2 lettere
A inevitabile?per tutti i percorsi,
E
possibilita ?per almeno un percorso x prox
stato
fqualche stato
futuro
g tutti gli
stati
u finchè


1)
2)
AXin tutto il prossimo cammino
EX cè almeno
un prossimo cammino

• Questi programmi usano la logica CTL per
  esprimere le loro proprietà.
• Le loro capacità sono
• Verità della specifica in tutti gli stati
• Traccia delle operazioni svolte in esecuzione
• Sono formati da diversi moduli (Main identifica
  la radice)
• Può avere diversi tipi di espressioni VAR,
  ASSIGN,INVAR, DEFINE,SPEC..

13
stato iniziale
p1, p3 s0
Modello rappresentativo del sistema
Sistema M con 3 stati possibili s0 s1 s2
p1 s1
p2, p3 s2
Passaggio da uno stato allaltro
Atomo del sistema che si trova in quello stato
p
Stati di transizione possibili s0?s1 s0?s2
s1?s0 s1?s2 s2?s2
s0
s1
s2
p1 è vero in s1 (p1 e p2) veri in s0 (p2 p3) in
s2
s2
s0
s2
s2
s2
Grafico districato percorsi computazionali
iniziando da uno stato
s2
14
Un altro esempio
Stato iniziale del sistema
(n1,n2)
Il programma deve tradurre le proprietà di un
sistema in elementi grafici
s0
(t1,n2)
(n1,t2)
s5
s1
Si dota un sistema di proprietà che ne
anticipino la conclusione
(c1,n2)
(t1,t2)
(t1,t2)
(n1,c2)
s2
s6
s8
s3
2 sistemi concorrenti che dividono una risorsa e
non hanno accesso ad essa insieme
(c1,t2)
(t1,c2)
s4
s7
- Quale processo (p1 / p2) può entrare nella zona
critica a quel tempo?
3 stati possibili Ni il processo i non
tenta di entrare Ti il processo i tenta
di entrare Ci il pocesso i si trova nella
zona critica
N T C
Stati possibili del sistema (n1,n2), (n1,t2),
(n1,c2), (t1,n2), (t1,t2), (t1,c2), (c1,n2),
(c1,t2) (c1,c2).
15
Stato iniziale del sistema
(n1,n2)
s0
(t1,n2)
(n1,t2)
s5
s1
(c1,n2)
(t1,t2)
(t1,t2)
(n1,c2)
s2
s6
s8
s3
Il grafico rappresenta le seguenti proprietà
(c1,t2)
(t1,c2)
s4
s7
Safety Solo un processo può accedere alla
risorsa ad un determinato tempo ? In tutti i
cammini c1 e c2 non possono apparire
simultaneamente. ? AG (c1 ? c2)
Nonblocking Un processo può sempre chiedere di
entrare ? Per ogni cammino ha un
successore ti. ? AG (ni ? EXti)
Liveness Un processo tenta di entrare ed
eventualmente ce la fa ? Per tutti i
cammini se ti è vero nei passi futuri ci sarà
ci. ? AG (ti ? AFci)
16
Analizzatore di protocolli per i laboratori di
ricerca navale
Serve per crittografare protocolli, la loro
autenticazione e i protocolli di distribuzione di
chiavi.
Usa il Prolog
Presupposto Intrusi alla scoperta di
informazioni per accedere ai messaggi scambiati
Lutente specifica gli stati nonsicuro e ne
prova la raggiungibilità
NPA Temporal Requirements LanguageEsprime
generici requisiti di distribuzione delle chiavi
in base alle esigenze
Contribuisce allo sviluppo di CAPSL (Common
Autentication Protocol Specification
Language) Specifiche sul protocollo dorigine
? Traduttore ? Linguaggio supportato dal
sistema
Protocol specification types spec.
environment