1 - Titolo del Progetto di Ricerca 2 - Area scientifico

Transcription

UNIONE EUROPEA
REPUBBLICA ITALIANA
REGIONE AUTONOMA DELLA SARDEGNA
ASSESSORATO DELLA PROGRAMMAZIONE, BILANCIO, CREDITO E ASSETTO DEL
TERRITORIO
CENTRO REGIONALE DI PROGRAMMAZIONE
LEGGE REGIONALE 7 AGOSTO 2007, N. 7:
“PROMOZIONE DELLA RICERCA SCIENTIFICA E DELL’INNOVAZIONE TECNOLOGICA IN SARDEGNA”
FORMULARIO PER
PROGETTI DI RICERCA FONDAMENTALE O DI BASE
1 - Titolo del Progetto di Ricerca
TESLA: Tecniche di Enforcement per la Sicurezza dei Linguaggi e delle Applicazioni
2 - Area scientifico-disciplinare
01 - Scienze matematiche e informatiche
3 - Settori scientifico-disciplinari interessati dal Progetto di Ricerca
INF/01 (Informatica)
3a - Parole chiave
Metodi formali per la sicurezza
Sicurezza nei linguaggi di programmazione
Verifica statica e dinamica
4 - Coordinatore Scientifico
Bartoletti
(Cognome)
Massimo
(Nome)
Ricercatore
(Qualifica)
23/11/1974
(Data di nascita)
BRTMSM74S23D612D
(Codice fiscale)
Università degli Studi di Cagliari
(Università, Enti di Ricerca, Aziende Sanitarie e Ospedaliere della Sardegna)
1 di 18
Dipartimento di Matematica e Informatica
(Dipartimento)
070 675 8540
(Prefisso e telefono)
070 675 8504
(Numero fax)
[email protected]
(Indirizzo posta elettronica)
5 - Curriculum scientifico del Coordinatore
Massimo Bartoletti è Ricercatore (SSD INF/01 – Informatica) presso di Dipartimento di Matematica e
Informatica dell’Università degli Studi di Cagliari dal 2008. Ha conseguito il Dottorato di Ricerca in
Informatica all’Università di Pisa nel 2005, con una tesi dal titolo “Language-based security: access
control and static analysis”. I suoi interessi di ricerca riguardano lo studio, la definizione e l’utilizzo di
metodi formali per la sicurezza del software; in particolare, tecniche di analisi statica (analisi del flusso
di controllo, sistemi di tipo ed effetto, model-checking) come supporto per la definizione e
l’ottimizzazione di meccanismi di sicurezza per linguaggi di programmazione orientati agli oggetti, e per
linguaggi funzionali. Un altro campo di ricerca riguarda lo studio di tecniche di analisi statica per
l’orchestrazione di servizi Web in presenza di requisiti di sicurezza, e la definizione di un nuovo
paradigma per l’invocazione di servizi (call-by-contract), che permette al programmatore di specificare le
proprietà semantiche che dovranno essere rispettate dal servizio invocato. Sulla base di tali studi si sono
potuti definire e implementare meccanismi di sicurezza per linguaggi di programmazione commerciali,
in particolare per Java.
Massimo Bartoletti è stato ed è coinvolto in progetti di ricerca nazionali (Progetto PRIN Mefisto
“Metodi Formali per la Sicurezza e il Tempo”, Progetto PRIN Sybilla “Systems Biology: modellazione,
linguaggi e analisi”, Progetto PRIN Soft “Tecniche formali orientate alla sicurezza”) ed internazionali
(EU-FET Global Computing Project IST-2001-32072 Degas “Design Environments for Global
Applications”, EU-FETPI Global Computing Project IST-2005-16004 Sensoria “Software Engineering
for Service-Oriented Overlay Computers”).
Massimo Bartoletti ha pubblicato più di venti tra riviste e atti di congresso internazionali, tutti con
revisione. Inoltre, è stato membro del comitato organizzatore e di programma di vari workshop e
conferenze internazionali (p.e. FCS-ARSPA, ARES, TGC), e revisore per varie riviste e conferenze.
Massimo Bartoletti insegna e ha insegnato corsi, anche di dottorato, in Linguaggi di programmazione,
Architettura degli elaboratori, Modelli e calcoli per la sicurezza. Alcuni suoi lavori sono stati oggetto di
un corso alla scuola internazionale di dottorato Foundations Of Security Analysis and Design, (FOSAD
2006).
6 - Pubblicazioni scientifiche più significative del Coordinatore Scientifico
1. Massimo Bartoletti, Gabriele Costa, Pierpaolo Degano, Fabio Martinelli, Roberto Zunino.
Securing Java with local policies. Journal of Object Technology, 2009 (in corso di pubblicazione).
2. Massimo Bartoletti. Usage automata. ARSPA-WITS, 2009 (in corso di pubblicazione).
3. Massimo Bartoletti, Gabriele Costa, Roberto Zunino. Jalapa: Securing Java with Local Policies.
BYTECODE, 2009 (in corso di pubblicazione).
4. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Planning and Verifying Service
Composition. Journal of Computer Security, 2009 (in corso di pubblicazione).
5. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari, Roberto Zunino. Model checking
usage policies. Trustworthy Global Computing, 2008.
6. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari, Roberto Zunino. Semantics-based
design for Secure Web Services. IEEE Transactions on Software Engineering, Vol. 34, Issue 1, 2008.
7. Massimo Bartoletti, Vincenzo Ciancia, Gian Luigi Ferrari, Roberto Guanciale, Daniele Strollo,
2 di 18
Roberto Zunino. L’orientamento ai servizi. Mondo Digitale, Vol. 25, N. 1, 2008.
8. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari, Roberto Zunino. Type and Effects for
Resource Usage Analysis. FOSSACS, 2007.
9. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari, Roberto Zunino. Secure service
orchestration. FOSAD, 2007.
10. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Security issues in Service
Composition. FMOODS, 2006.
11. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Types and Effects for Secure Service
Orchestration. Computer Security Foundations Workshop (CSFW), 2006.
12. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Plans for service composition.
Workshop on Issues in the Theory of Security (WITS), 2006.
13. Massimo Bartoletti. Language-based security: access control and static analysis. PhD Thesis,
Dipartimento di Informatica, Università di Pisa, 2005.
14. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Enforcing Secure Service
Composition. Computer Security Foundations Workshop (CSFW), 2005.
15. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Checking risky events is enough for
local policies. ICTCS, 2005.
16. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. History-based Access Control with
Local Policies. FOSSACS, 2005.
17. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Method inlining in the presence of
stack inspection. Workshop on Issues in the Theory of Security (WITS), 2004.
18. Massimo Bartoletti, Pierpaolo Degano and Gian Luigi Ferrari. Stack inspection and secure
program transformations. International Journal of Information Security, 2(3-4), 2004.
19. Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari. Static analysis for stack inspection.
Electr. Notes Theor. Comput. Sci. 54, 2001.
7 - Elenco delle Unità operative
I
Cognome
A Bartoletti
B Pinna
C Scateni
II
A
B
C
D
Cognome
Nome
Nome
Pierpaolo
Gian Luigi
Chiara
Emilio
III Cognome
Nome
Cortesi
Focardi
Luccio
Bhattacharya
Carraro
Centenaro
Ferrara
Halder
Zanioli
Università
Massimo Ricercatore non confermato Cagliari
G. Michele Professore Associato
Cagliari
Riccardo
Professore Associato
Cagliari
Degano
Ferrari
Bodei
Tuosto
A
B
C
D
E
F
G
H
I
Qualifica
Agostino
Riccardo
Flaminia
Sukriti
Alberto
Matteo
Pietro
Raju
Matteo
Qualifica
Professore Ordinario
Lecturer
Qualifica
Professore Ordinario
Ricercatore
Dottorando
Dottorando
Dottorando
Dottorando
Dottorando
Dottorando
Università
Pisa
Pisa
Pisa
Leicester (UK)
Università
“Ca’ Foscari”, Venezia
3 di 18
Dipartimento
Matematica e Informatica
Dipartimento
Informatica
Informatica
Informatica
Computer Science
Dipartimento
Informatica
Informatica
Informatica
Informatica
Informatica
Informatica
Informatica
Informatica
Informatica
Disponibilità
temporale
prevista
5
3
1
Disponibilità
temporale
prevista
3
3
3
1
Disponibilità
temporale
prevista
3
1
1
2
1
2
3
2
4
7.a - Unità II e III: Curriculum scientifico dei responsabili delle unità operative
Unità II: Pierpaolo Degano
Pierpaolo Degano è Professore Ordinario di Informatica dal 1990, e dal 1993 afferisce al Dipartimento
di Informatica, Università di Pisa. Dal 1993 al 1996 è stato direttore del Dipartimento di Informatica,
Università di Pisa; dal 2000 al 2003 è stato Presidente del GRIN, Associazione Nazionale dei Professori
di Informatica; dal 2001 ad oggi è Membro del Consiglio Scientifico della Scuola di Dottorato di
Eccellenza “Galileo Galilei”; dal 2006 ad oggi è Presidente del Dottorato in Informatica; dal 2005 ad
oggi è Membro del Consiglio Scientifico del Microsoft Research – University of Trento Centre for
Computational and Systems Biology.
Le principali aree di ricerca di Pierpaolo Degano sono state o sono: Semantica della Concorrenza,
Linguaggi per sistemi distribuiti e mobili, Metodi e stumenti per la verifica di programmi, Sicurezza,
Bio-informatica. Su questi argomenti ha pubblicato piú di 150 articoli su riviste internazionali e atti di
congressi.
Pierpaolo Degano è stato: responsabile scientifico di molte scuole e svariati congressi internazionali
(p.e. ICALP’97, ICTCS’98, WITS’00, ESOP’03, FAST’08, SFM-08-bio e del prossimo CMSB) e
curatore degli atti; curatore di numeri speciali di TCS, ACM Cmpt. Reviews, SCP, Information &
Computation; Direttore dell’Advanced Seminar on Distributed Computing of TAPSOFT’91; membro
del comitato guida di TAPSOFT; ETAPS; EATCS e del suo Italian Chapter; co-fondatore dell’IFIP
TC1 WG 1.7 on Theoretical Foundations of Security Analysis and Design e iniziatore della serie di
W/S WITS.
Pierpaolo Degano ha partecipato, spesso in qualità di responsabile, a progetti nazionali (tra cui cinque
Progetti Cofinanziati, di uno dei quali, BISCA, come responsabile nazionale) e internazionali, tra cui
ESPRIT - Parallel Architectures and Languages; ESPRIT Basic Research Action - Models, Languages
and Logics for Concurrent & Distributed Systems, CEC Working Groups GRA-GRA and MASK;
joint project between Università di Pisa and Hewlett-Packard; ESPRIT Basic Research Action 8130 –
LOMAPS; FET – DEGAS; FET – SENSORIA.
Pierpaolo Degano insegna e ha insegnato corsi, anche di dottorato, in Linguaggi di programmazione,
Compilatori, Semantica, Fondamenti dell’Informatica, Sicurezza, in vari Atenei italiani e stranieri.
Bibliografia
1. H. Gao, C. Bodei, P. Degano. A Formal Analysis of Complex Type Flaw Attacks on Security
Protocols. AMAST, 2008.
2. C. Bodei, P. Degano, H. Gao, L. Brodo. Detecting and Preventing Type flaws: a Control Flow
Analysis with Tags. Electr. Notes Theor. Comput. Sci. 194(1), 2007.
3. R. Zunino, P. Degano. Handling exp, × (and Timestamps) in Protocol Analysis. FoSSaCS,
2006.
4. C. Bodei, M. Buchholtz, M. Curti, P. Degano, F. Nielson, H.R. Nielson, C. Priami. On Evaluating
the Performance of Security Protocols. PaCT, 2005.
5. C. Bodei, P. Degano, R. Focardi, C. Priami. Authentication primitives for secure protocol
specifications. Future Generation Comp. Syst. 21(4), 2005.
6. C. Bodei, P. Degano, C. Priami. Checking security policies through an enhanced Control
Flow Analysis. Journal of Computer Security 13(1), 2005.
7. C. Bodei, M. Buchholtz, P. Degano, F. Nielson, H.R. Nielson. Static validation of security
protocols. Journal of Computer Security 13(3), 2005.
8. R. Zunino, P. Degano. A Note on the Perfect Encryption Assumption in a Process Calculus.
FoSSaCS, 2004.
9. C. Bodei, P. Degano, R. Focardi, C. Priami. Authentication Primitives for Protocol
Specifications. PaCT, 2003.
10. C. Bodei, P. Degano, F. Nielson, H.R. Nielson. Static Analysis for the pi-Calculus with
Applications to Security. Inf. Comput. 168(1), 2001.
4 di 18
Unità III: Agostino Cortesi
Agostino Cortesi è Professore Ordinario di Informatica dal 2002 presso il Dipartimento di Informatica
dell’Università Ca’ Foscari di Venezia, di cui è Direttore dal 2006. Dal 2004 al 2006 presiede il Centro di
Telecomunicazioni di Ateneo; dal 2006 è Pro-Rettore per le Politiche di Valutazione ed Innovazione
dell’Università Ca’ Foscari di Venezia..
Agostino Cortesi è, ed è stato, titolare di vari corsi presso il Corso di Laurea in Informatica, tra i quali
Programmazione, Ingegneria del Software, Analisi e Verifica di Programmi. È coordinatore del modulo
“Sistemi Informatici” del Master in Economia del Turismo dello stesso Ateneo. È inoltre coordinatore
del Master Universitario in Informatica per la Comunicazione.
Agostino Cortesi è autore di più di 60 pubblicazioni su riviste e proceedings di livello internazionale. I
suoi interessi di ricerca riguardano i linguaggi di programmazione e le metodologie di analisi statica di
programmi.
Agostino Cortesi è stato membro dei comitati di programma delle seguenti conferenze: SAS: Static
Analysis Symposium (1997 Paris, 1998 Pisa, 1999 Venice, 2007 Copenhagen), AGP: Declarative
Programming (1997 Grado, 1998 La Coruna, 2003 Rende), VMCAI: Verification, Model Checking, and
Abstract Interpretation (2001 Venice, 2002 New York, 2003 Venice, 2004 Paris), CSFW Computer
Security Foundations (Asilomar 2004). Inoltre è stato Conference Chair del First Int. Workshop on
Concurrent Constraint Programs (Venice 1996) e Local Chair del 31th ACM Symposium on
Programming Languages (Venice 2004). E’ stato guest editor di special issues delle seguenti riviste
internazionali: “Science of Computer Programming”, “Computer Languages”, e “Software Tools for
Technology Transfer”. E’ membro dell’editorial board della rivista internazionale “Computer
Languages, Systems and Structures”, Elsevier ed.
Bibliografia
1. Cortesi, M. Brusò. Non-Repudiation Analysis with LySa. Proc. 24th IFIP International
Information Security Conference (SEC 2009), 2009.
2. Braghin, A. Cortesi, R. Focardi, Information Flow Security in Boundary Ambients. Information
and Computation, Elsevier, Vol. 206(2-4): 460-489, 2008.
3. Cortesi. Widening Operators for Abstract Interpretation. Proc. 6th IEEE Int. Conf. on
Software Engineering and Formal Methods, 2008.
4. Candiello, A. Albarelli and A. Cortesi. An Ontology-based Inquiry Framework. Proc. 5th
Workshop on Semantic Web Applications and Perspectives (SWAP), 2008.
5. M. Backes, A. Cortesi, R. Focardi, M. Maffei. A Calculus for Challenges and Response. Proc.
5th ACM Workshop on Formal Methods in Security Engineering, 2007.
6. M. Backes, A. Cortesi, M. Maffei. Causality-Based Abstraction of Multiplicity in Security
Protocols. Proc. 20th IEEE Computer Security Foundations Symposium, 2007.
7. F. Logozzo, A. Cortesi. Semantic Hierarchy Refactoring by Abstract Interpretation. Proc.
VMCAI, LNCS 3855, 2006.
8. Braghin, A. Cortesi, R. Focardi, F.L. Luccio, C. Piazza. Nesting Analysis of Mobile Ambients.
Computer Languages, Elsevier, 30(3-4):207-230, 2004.
9. Braghin, A. Cortesi, R. Focardi, F.L. Luccio, C. Piazza. Behind BANANA: Design and
Implementation of a Tool for Nesting Analysis of Mobile Ambients. Electronic Notes on
Theoretical Computer Science, Elsevier, 99: 319-337, 2004.
10. L. Zuck, Paul C. Attie, A. Cortesi, (Guest Editors). International Journal on Software Tools for
Technology Transfer, Springer, Special Section on Verification, Model Checking, and Abstract
Interpretation, 2004.
5 di 18
8 - Abstract del Progetto di Ricerca
La sicurezza dei sistemi di elaborazione è un aspetto cruciale della nascente Information Society. Col
crescere del numero di servizi informatici (e-commerce, e-banking, e-governement, ecc.) messi a
disposizione dei cittadini, crescono il numero e la criticità delle problematiche relative all’uso sicuro dei
dati e delle risorse computazionali. Dal punto di vista degli utenti è importante, ad esempio, avere la
certezza che i propri dati personali vengano usati in modo confidenziale, e solo per svolgere il servizio
richiesto. Dal punto di vista dei servizi è importante, ad esempio, avere la certezza che non sarà
possibile, da parte di un utente non autorizzato, portare a compimento un attacco che gli permetta di
usare risorse sensibili, o di negarne l’accesso ad utenti autorizzati. In altre parole, l’interazione tra un
utente e un servizio deve essere regolata da un opportuno contratto, che garantisce ad ambo le parti le
proprietà desiderate. Il problema cruciale da risolvere sta dunque nel come definire il concetto di
“contratto”, e come fare in modo che questo venga effettivamente rispettato, ovvero come garantire la
sua imposizione (enforcement).
Nel processo di sviluppo di software (anche commerciale), tipicamente gran parte dello sforzo
progettuale e implementativo viene riservato agli aspetti funzionali del prodotto, mentre quelli nonfunzionali (come la sicurezza) vengono perlopiù trattati ex-post, rappezzando le falle quando vengono
scoperte, spesso sul prodotto già in uso o in commercio. Nonostante questa prassi sia piuttosto
consolidata, è auspicabile una inversione di tendenza, sia per motivi prettamente economici (rendere
sicuro un software progettato senza alcun security concern può essere molto costoso; un attacco alla
sicurezza andato a buon fine può provocare ingenti danni, sia al gestore del servizio attaccato che ai
suoi utenti), sia per motivi etici e sociali (l’uso non autorizzato di informazioni riservate può limitare i
diritti civili dei cittadini, la concorrenza tra imprese, ecc.).
Per questi motivi, è crescente nella comunità scientifica internazionale l’attenzione verso il problema
della sicurezza nei sistemi informatici. È ormai un fatto ampiamente accettato che la sicurezza debba
essere considerata in tutte le fasi dello sviluppo del software, ovvero sin dall’analisi dei requisiti e della
progettazione. Si sta inoltre consolidando la convinzione che la sicurezza, ancor più degli aspetti
funzionali del software, debba essere trattata con tecniche formali, in modo tale che sia possibile fornire
delle garanzie precise, matematiche, riguardo alle proprietà rispettate o meno da un dato sistema
informatico.
Questo progetto si propone di rafforzare la comprensione e la diffusione di metodi formali per la
sicurezza, proponendo un approccio “verticale”, in cui la sicurezza del software è considerata a diversi
livelli di astrazione. Partiamo da un livello fondazionale, in cui consideriamo modelli idealizzati di
linguaggi di programmazione. A questo livello, introduciamo diverse nozioni di contratto, e studiamo
varie tecniche per la loro analisi ed enforcement. L’obiettivo che ci poniamo è quello di comprendere
come le scelte di linguaggio, contratto, tecnica di analisi, incidono sull’espressività, sulla decidibilità e
sulla complessità dell’enforcement. Passiamo poi a un livello più concreto, dove si considerano
linguaggi di programmazione di uso commerciale. A questo livello, siamo interessati a studiare
raffinamenti dei contratti e delle tecniche di analisi ed enforcement del livello precedente; in particolare,
vogliamo comprendere come la maggiore concretezza del linguaggio incide sui risultati di espressività,
decidibilità e complessità ottenuti al livello precedente. Arriviamo infine al livello delle applicazioni, in
cui sperimentiamo su scenari concreti le tecniche introdotte nei due livelli precedenti. In particolare,
vogliamo stabilire se le nozioni di contratto proposte siano sufficientemente espressive per modellare
proprietà di sicurezza rilevanti in scenari realistici, e quantificare, sia teoricamente che con l’uso di
benchmarks appropriati, la precisione e l’efficienza delle tecniche di analisi e di enforcement. Come
caso di studio principale, considereremo un sistema informatico per la dematerializzazione della
documentazione dei processi amministrativi dell’Università di Cagliari, per il quale svolgeremo
un’analisi dei requisiti di sicurezza, e del quale implementeremo un prototipo, messo in sicurezza
attraverso le tecniche di enforcement definite ai livelli precedenti.
6 di 18
9 - Obiettivi generali, specifici e operativi che il progetto si propone di raggiungere
L’obiettivo principale del progetto è quello di mettere a disposizione metodologie e strumenti di
sviluppo open-source, basati su solidi fondamenti teorici, attraverso i quali realizzare, con minor costo,
software più sicuro. Un ulteriore obiettivo di questo progetto è quello di favorire la cooperazione e lo
scambio di competenze tra i tre atenei italiani coinvolti, di stabilire contatti con l’Università di Leicester
di cui un membro fa parte del progetto, e di consolidare la posizione dell’ateneo cagliaritano nella
comunità internazionale di ricerca che studia la sicurezza dei sistemi informatici. Infine, mediante la
diffusione della metodologia e degli strumenti sviluppati, il progetto si propone di incentivare il
trasferimento di innovazione tecnologica verso le imprese locali e le pubbliche amministrazioni,
stimolando l’attività di verifica e di certificazione di sicurezza dei prodotti software.
Nel seguito descriviamo schematicamente gli obiettivi specifici del progetto, raggruppati secondo le tre
fasi individuate nella Sezione 8.
Fase 1: Fondamenti di specifica, enforcement ed analisi di proprietà di sicurezza

Lo studio di formalismi, basati su logiche e su automi, per la specifica e l’enforcement di
proprietà di sicurezza e di contratti.
Lo studio e la sperimentazione di tecniche di enforcement, statiche e dinamiche, di proprietà di
sicurezza su linguaggi, in diversi paradigmi di programmazione. In particolare, studieremo:
o analisi di controllo di flusso ed interpretazione astratta di linguaggi ad oggetti, anche con
multi-threading nativo.
o sistemi di tipo ed effetto e interpretazione astratta per linguaggi funzionali higher-order con
effetti collaterali e creazione di nomi nuovi.
o interpretazione astratta su linguaggi per basi di dati, in particolare per garantire la robustezza
rispetto ad “attacchi di tipo” (p.e. SQL injection).
Lo studio e la sperimentazione di tecniche formali e strumenti di verifica basati su automi
History-Dependent, per l’analisi e la verifica di politiche di sicurezza.
Fase 2: Sicurezza di linguaggi di programmazione commerciali

Studio di formalismi per la specifica di proprietà di sicurezza di programmi Java.
Realizzazione di un meccanismo di run-time enforcement di proprietà di sicurezza su
programmi Java e Java bytecode, la cui correttezza sia sostenuta dall’apparato formale
sviluppato nella fase precedente.
Studio ed ottimizzazione della performance del meccanismo di run-time enforcement.
Realizzazione di un prototipo di analizzatore statico per programmi Java e Java bytecode, in
grado di ottimizzare ulteriormente il meccanismo di run-time enforcement, mantenendo solo i
controlli strettamente indispensabili.
Realizzazione di un ambiente di programmazione open-source, basato su plugin Eclipse, per
facilitare la scrittura e l’analisi di politiche di sicurezza su programmi Java.
Fase 3: Sicurezza delle applicazioni

Analisi dei requisiti funzionali e progettazione, mediante specifica dei workflow, di un sistema
informatico per la dematerializzazione della documentazione amministrativa dell’Università di
Cagliari.
Analisi dei requisiti di sicurezza del sistema informatico al punto precedente.
Modellazione dei requisiti di sicurezza identificati al punto precedente attraverso uno dei
formalismi individuati nelle fasi 1 e 2.
Analisi dei possibili attacchi di sicurezza sull’interfaccia e sul protocollo dei workflow
individuati al primo punto.
Realizzazione in Java di un prototipo del sistema informatico di dematerializzazione, e sua
7 di 18

messa in sicurezza attraverso i meccanismi di enforcement individuati nelle fasi 1 e 2.
Verifica formale del prototipo realizzato al punto precedente, attraverso le tecniche di analisi
individuate nelle fasi 1 e 2.
10 - Coerenza con gli obiettivi strategici della pianificazione regionale per lo sviluppo e
l’occupazione nel quadro delle raccomandazioni europee
Gli obiettivi generali e specifici del progetto sono coerenti con gli obiettivi strategici della pianificazione
regionale per lo sviluppo e l’occupazione nel quadro delle raccomandazioni europee. Infatti, accanto a
uno sviluppo dei fondamenti teorici, il progetto affronta anche tematiche prettamente applicative.
Questi obiettivi sono coerenti con quelli individuati dal Documento annuale di programmazione
economica finanziaria (Dapef 2008, p. 41), che inquadra tra gli obiettivi in materia di ricerca e
innovazione lo “sviluppare una stretta integrazione tra la ricerca fondamentale, o di base, e quella
applicata e tra il sistema della ricerca e quello dell’impresa”. Le tecniche di specifica, enforcement ed
analisi di proprietà di sicurezza che ci si propone di studiare e sviluppare, sono volte a realizzare
strumenti e metodi che contribuiscono allo sviluppo della società dell’informazione. Le tematiche
riguardanti lo studio di tali tecniche su linguaggi commerciali, e la realizzazione di strumenti open-source
per la specifica e l’enforcement di proprietà di sicurezza, promuovono lo sviluppo economicamente
sostenibile di software efficiente e sicuro per sistemi complessi, quali le pubbliche amministrazioni.
Con l’analisi dei requisiti, la progettazione, l’implementazione di una sistema informatico per la
dematerializzazione della documentazione amministrativa dell’Università di Cagliari, e la messa in
sicurezza di questo attraverso i metodi formali sviluppati all’interno del progetto, ci si propone di
compiere un ulteriore passo in avanti verso la completa e sicura informatizzazione dei procedimenti,
anche amministrativi. Si noti che la Sardegna è la prima Regione Italiana a rendere obbligatorio l’utilizzo
di documenti elettronici e la firma digitale. Dando seguito a una delibera della Giunta Regionale del
dicembre 2008, dal 15 gennaio 2009 tutti gli atti della Regione Autonoma Sardegna dovranno essere
predisposti in formato elettronico e firmati digitalmente. Tutti i dirigenti e i funzionari regionali saranno
dotati di un dispositivo di firma digitale, ovvero di una smartcard che consente sia la sottoscrizione dei
documenti elettronici, che l’autenticazione attraverso l’accesso telematico ai servizi pubblici on-line. In
questo progetto non ci focalizzeremo soltanto su problematiche di autenticazione, ma anche sul fatto
che i documenti vengano acceduti e utilizzati solo dai soggetti autorizzati, secondo protocolli prestabiliti
e le cui proprietà di sicurezza siano formalmente verificate e certificate. Il caso di studio considerato,
facilmente esportabile anche alla dematerializzazione documentale di altre PA, è coerente con gli
obiettivi strategici della pianificazione regionale per lo sviluppo e l’occupazione, vedi ad es. il Quadro
strategico nazionale (Qsn 2007-2013, p. 101), che pone come obiettivo: “lo sviluppo […] di modelli
organizzativi e gestionali innovativi e sostenibili dei servizi della Pubblica Amministrazione locale,
procedendo oltre alla pur necessaria innovazione delle procedure amministrative (da non limitare ai
supporti tecnologici) per puntare sulla trasformazione dei processi organizzativi delle PA e sulla
maggiore accountability dei processi decisionali […] In quest’ambito si fa particolare riferimento alla
gestione dell’identità digitale e della sicurezza in rete [...]”.
11 - Stato dell’arte
Le tematiche affrontate dal progetto intersecano vari filoni di ricerca legati alla sicurezza informatica.
Descriviamo in seguito alcuni tra i principali e recenti risultati apparsi in letteratura, sia sugli aspetti
fondazionali che su quelli più applicativi.
Una moltitudine di tecniche formali sono state studiate per specificare e imporre politiche di sicurezza.
Un modello astratto di politiche è stato definito in [Sch00], dove viene caratterizzata la classe di
politiche che possono essere imposte attraverso monitoring a tempo di esecuzione. In [HM+06]
vengono caratterizzate le politiche imponibili attraverso la riscrittura di programmi. In [LB+05] viene
studiata una classe di automi che possono sopprimere e inserire eventi nella traccia dell’esecuzione. In
[Bart09] viene studiata l’espressività e l’enforcement di automi i cui archi possono contenere variabili e
guardie booleane, mentre in [BD+08] viene proposta una tecnica corretta e completa di model checking
8 di 18
(di complessità polinomiale) per questi automi. Tra gli approcci logici, in [GA08] si considera una logica
modale in cui un principale può, attraverso una modalità chiamata say, affermare proprietà su un certo
oggetto; in [LG+03] si propone una logica per la delega che consente di dedurre i permessi di un
soggetto attraverso le deleghe che gli sono concesse da altri soggetti; in [KN+08] si propone una logica
per ragionare sul comportamento passato degli attori coinvolti, in modo da costringere gli attori ad un
comportamento corretto nel futuro; [FP+08] propone una logica fuzzy, capace quindi di dedurre anche
in caso di informazione vaga o incompleta, in cui viene introdotta una modalità analoga al say di
[GA08]. La sicurezza di linguaggi ed applicazioni ha relazioni con simili approcci, e chiarire
ulteriormente tali relazioni può portare a meglio definire quale sia la logica più adatta ad esprimere le
politiche e le tecniche di enforcement che il progetto si propone di sviluppare.
Complementari alle tecniche di specifica delle politiche di sicurezza, sono le tecniche di enforcement,
che fanno in modo che le politiche siano rispettate dai programmi. Tradizionalmente, queste tecniche
sono basate sul controllo dinamico dello stato dell’esecuzione (execution monitoring), anche se negli ultimi
anni sono stati proposti diversi approcci che sfruttano tecniche di analisi statica e di verifica per
ottimizzare il meccanismo di enforcement dinamico. Sistemi di tipo [IK05] e di tipo ed effetto
[SS04,BD+07], in abbinamento con tecniche di model-checking, vengono usati per garantire a tempo
statico l’uso sicuro di risorse, su linguaggi funzionali con effetti collaterali. In [CF00, MS+03] si
combinano tecniche statiche e dinamiche per trasformare i programmi in modo da renderli conformi a
politiche di safety, minimizzando al contempo l’onere del controllo a tempo di esecuzione. In [BG+05]
viene usata un’analisi di controllo di flusso per decidere staticamente se i controlli locali di sicurezza
implicano una data politica globale. Sono state proposte tecniche di enforcement basate su sistemi di
tipo anche per modelli di programmazione concorrente e distribuita, p.e. [BC+04, BG+06].
Tra i linguaggi di programmazione commerciali, uno tra i più rilevanti dal punto di vista della sicurezza
è il linguaggio Java. Difatti, vari aspetti della sicurezza di Java sono stati negli anni oggetto di studio da
parte della comunità scientifica, il che ha permesso di migliorarne l’efficacia. Sulla base della type safety,
garantita dalla verifica statica del bytecode, sono stati recentemente proposti e introdotti nel linguaggio
nuovi meccanismi di sicurezza, in particolare quello noto come stack inspection [Gong99]. Potendo solo
controllare la pila delle chiamate, questo meccanismo soffre di alcune importanti limitazioni. Ad
esempio, poiché un metodo rimosso dallo stack delle chiamate non ha più alcun influsso sui controlli di
sicurezza, la stack inspection non offre alcuna protezione nel caso in cui del codice trusted usi risultati
forniti da codice untrusted [FG02]. In assenza di altri meccanismi generali per l’enforcement di politiche,
è prassi comune rinunciare alla separazione tra aspetti funzionali e sicurezza, e lasciare al
programmatore l’onere di implementare i meccanismi necessari, di solito attraverso controlli inseriti
esplicitamente nel codice. Poiché dimenticare anche un singolo controllo può compromettere la
sicurezza dell’intera applicazione, questa consuetudine è alquanto rischiosa. Per ovviare a queste
limitazioni, sono stati recentemente proposti modelli di sicurezza alternativi, basati sul controllo della
storia dell’esecuzione [EA+AF03, Skalka05, BC+09]. Questi meccanismi sono chiaramente più
espressivi rispetto alla stack inspection, ma poiché esistono in letteratura molti modelli basati sulla storia,
diventa cruciale sceglierne uno che concili adeguatamente il potere espressivo con le proprietà teoriche
di cui gode. È inoltre importante che i meccanismi di sicurezza siano implementati in modo tale da
essere trasparenti ai programmatori, e con un overhead computazionale tollerabile.
Bibliografia
[AF03] M. Abadi and C. Fournet. Access control based on execution history. 10th Annual Network and
Distributed System Security Symposium, 2003.
[Bart09] M. Bartoletti. Usage automata. To appear in ARSPA-WITS, 2009.
[BC+09] M. Bartoletti, Gabriele Costa, P. Degano, F. Martinelli, R. Zunino. Securing Java with local
policies. To appear in Journal of Object Technology, 2009.
[BC+04] M. Bugliesi, G. Castagna, S. Crafa. Access control for mobile agents: The calculus of boxed
ambients. ACM Trans. Program. Lang. Syst. 26(1), 2004.
[BG+06] C. Braghin, D. Gorla, V. Sassone. Role-based access control for a distributed calculus. Journal
9 di 18
of Computer Security 14(2), 2006.
[BD+07] M. Bartoletti, P. Degano, G.L. Ferrari, R. Zunino. Types and effects for resource usage
analysis. FOSSACS, 2007:
[BD+08] M. Bartoletti, P. Degano, G.L. Ferrari, R. Zunino. Model checking usage policies. Trustworthy
Global Computing, 2008
[BG+05] F. Besson, Th. de Grenier de Latour, T.P. Jensen. Interfaces for stack inspection. J. Funct.
Program. 15(2), 2005.
[CF00] T. Colcombet, P. Fradet. Enforcing Trace Properties by Program Transformation. POPL, 2000
[EA+99] G. Edjlali, A. Acharya, V. Chaudhary. History-based access control for mobile code. Secure
Internet Programming, 1999.
[FG02] C. Fournet, A.D. Gordon. Stack inspection: theory and variants. ACM Trans. on Prog. Lang. and
Sys. 25(3), 2003.
[FP+08] T. Flaminio, G.M. Pinna and E. Tiezzi. A complete fuzzy logical system to deal with trust
management systems. Fuzzy Sets and Systems 159(10), 2008.
[GA08] D. Garg, M. Abadi: A Modal Deconstruction of Access Control Logics. FoSSaCS, 2008.
[Gong99] L. Gong. Inside Java 2 platform security: architecture, API design, and implementation.
Addison-Wesley, 1999.
[HM+06] K.W. Hamlen, G. Morrisett, F.B. Schneider. Computability classes for enforcement
mechanisms. ACM Trans. on Prog. Lang. and Sys. 28(1), 2006.
[IK05] A. Igarashi, N. Kobayashi. Resource usage analysis. ACM Trans. Prog. Lang. Syst., 2005.
[KM+08] K. Krukow, M. Nielsen, V. Sassone. A logical framework for history-based access control
and reputation systems. Journal of Computer Security 16(1), 2008.
[LG+03] N. Li, B.N. Grosof, J. Feigenbaum. Delegation logic: A logic-based approach to distributed
authorization. ACM Trans. on Inf. and Sys. Security 6(1), 2003.
[LB+05] Jay Ligatti, Lujo Bauer, David Walker. Edit automata: enforcement mechanisms for run-time
security policies. Int. J. Inf. Sec. 4 (1-2), 2005.
[MS+03] K. Marriott, P.J. Stuckey, M. Sulzmann. Resource Usage Verification. APLAS 2003.
[Sch00] F.B. Schneider. Enforceable security policies. ACM Trans. Inf. and Sys. Sec. 3(1), 2000.
[Skalka05] C. Skalka. Trace effects and object orientation. PPDP, 2005.
12 - Articolazione del progetto e tempi di realizzazione
Suddividiamo il programma di ricerca in tre fasi, che scandiscono il flusso logico delle attività. Il
diagramma sottostante rappresenta schematicamente le tre fasi, dove una maggiore area indica un
maggiore impegno di risorse necessarie per il raggiungimento dei vari obiettivi proposti. È da notare
che i risultati ottenuti nell’ultima fase potranno essere usati come input per la prima fase, ottenendo
così un processo di retroazione virtuosa, in cui la ricerca fondazionale e quella applicativa vengono
vicendevolmente raffinate.
Fase 1: Fondamenti di specifica, enforcement
e analisi di proprietà di sicurezza
Fase 2: Sicurezza dei linguaggi di
programmazione commerciali
Fase 3:
Sicurezza delle applicazioni
Nel seguito descriviamo più in dettaglio le linee di ricerca delle tre fasi del progetto, e i tempi di
realizzazione previsti, indicati come intervallo di mesi all’interno della durata del progetto.
10 di 18
1-A. Logiche ed automi per la sicurezza (mesi 1-12).
Studieremo formalismi, basati su automi e su logiche, per la specifica di proprietà di sicurezza sulla
storia dell’esecuzione. Per quanto riguarda gli automi, approfondiremo lo studio degli usage automata,
caratterizzandone l’espressività e la complessità computazionale dell’enforcement. Per quanto riguarda
l’approccio logico, svilupperemo una logica modale con quantificatori universali ed esistenziali (questi
ultimi non esprimibili con usage automata, ma necessari per esprimere politiche di delega). La possibilità
di avere un linguaggio logico consentirà di poter specificare le politiche come formule della logica, e
quindi in modo composizionale. Inoltre, se la logica è corretta e completa, le formule sono anche
dimostrabili. Confronteremo l’espressività del linguaggio logico con quella degli usage automata,
individuando in quali scenari sia preferibile usare un formalismo piuttosto che l’altro. Passeremo
dunque allo studio di logiche fuzzy (in grado cioè di esprimere un grado di “incertezza”). In questo
modo riusciremo a modellare scenari in cui occorre quantificare la bontà di un matching semantico, p.e.
al fine di intraprendere una negoziazione per il service-level agreement tra servizi.
1-B. Analisi comportamentale di programmi (mesi 1-12).
Studieremo tecniche di analisi statica di programmi, per costruire a tempo di compilazione
approssimazioni corrette (e sufficientemente precise) del comportamento dei programmi a tempo di
esecuzione. In particolare, siamo interessati ad approssimare tutti i possibili pattern di creazione ed uso
di risorse. Questo ci permetterà di usare tecniche automatiche di verifica, p.e. model checking su usage
automata, per garantire che tutte le possibili esecuzioni del programma rispettano le politiche di
sicurezza richieste. Intendiamo sperimentare e confrontare l’uso di due diverse tecniche di analisi
statica: sistemi di tipo ed effetto, e interpretazione astratta. I sistemi di tipo ed effetto permettono di
costruire, in modo composizionale sui costrutti di un programma, un’approssimazione del suo tipo e
dei suoi effetti collaterali (nel nostro caso, le possibili sequenze di creazione/uso di risorse). Il problema
cruciale da risolvere è quello di legare correttamente, mantenendo un livello di precisione adeguato, gli
usi di risorse con la loro creazione; questo sembra richiedere l’introduzione di una nuova classe di tipi
ed effetti, con un binder per legare i nomi di risorse, sia nel tipo che nell’effetto. L’interpretazione
astratta è una tecnica di analisi statica, largamente applicata sia in ambito teorico che industriale, che
permette la definizione e l’approssimazione di semantiche di linguaggi di programmazione. L’uso di
questa tecnica, grazie alla sua genericità e flessibilità, sembra particolarmente promettente in questo
contesto, soprattutto per quanto riguarda la precisione dell’approssimazione costruita. L’applicazione di
questa tecnica richiederà lo studio di domini astratti e di corrispondenti operatori appropriati per
l’analisi delle proprietà di sicurezza considerate.
Svilupperemo le analisi comportamentali sovramenzionate per linguaggi appartenenti a tre paradigmi di
programmazione: linguaggi funzionali con effetti collaterali, linguaggi orientati agli oggetti con
multithreading, e linguaggi di interrogazione per basi di dati. Tutti e tre i paradigmi sono di estremo
interesse nel campo della sicurezza. Il paradigma funzionale, mediante le funzioni di ordine superiore,
fornisce un buon modello per la mobilità del codice. Il paradigma orientato agli oggetti è la base di
linguaggi, p.e. Java, di largo uso nello sviluppo di applicazioni, anche distribuite. I linguaggi per
l’interrogazione delle basi di dati costituiscono l’interfaccia verso il lato server delle applicazioni, e la loro
sicurezza è dunque un aspetto cruciale per la sicurezza dell’intero sistema. Attraverso l’uso di analisi
generiche come l’interpretazione astratta, ci aspettiamo di poter usare tecniche comuni ai vari
paradigmi. Ad esempio, il problema di approssimare le risorse create dinamicamente nel paradigma
funzionale sembra essere analogo a quello di approssimare i riferimenti creati dinamicamente nel
paradigma ad oggetti. Riguardo ai linguaggi di interrogazione per basi di dati, studieremo tecniche di
interpretazione astratta per garantire la robustezza rispetto ad attacchi (p.e. gli injection attacks) basati
sulle caratteristiche dei linguaggi.
11 di 18
1-C. Verifica statica di proprietà di sicurezza (mesi 7-12).
Recentemente, molti ricercatori hanno evidenziato come gli aspetti di sicurezza debbano essere
considerati a vari livelli di astrazione. L’ampio spettro di tali livelli di astrazione rende necessario l’uso di
approcci e tecniche diverse. Tipicamente le tecniche di analisi sono dipendenti da aspetti sintattici,
mentre le tecniche basate su model checking, che operano su una rappresentazione del comportamento di
un sistema, sono indipendenti dalla sintassi. Proporremo un approccio per integrare armoniosamente
tecniche complementari per l’analisi e la verifica di proprietà di sicurezza a diversi livelli di astrazione. Il
nostro approccio sarà basato sull’uso di History Dependent Automata (HDA, in breve) come
linguaggio intermedio per la rappresentazione dei costrutti studiati all’interno del progetto. Gli HDA
estendono automi classici con meccanismi espliciti per il trattamento dei “nomi”. Il loro scopo è quello
di fornire una rappresentazione basata su automi per una classe di formalismi detti “calcoli nominali”.
Questi sono calcoli di processi che introducono la nozione di “nome”, in modo di rappresentare
fenomeni computazionali quali p.e. la mobilità e la creazione dinamica di risorse. Il principale beneficio
apportato dagli HDA sarà la possibilità di trattare in maniera uniforme gli aspetti di sicurezza di
interesse, rendendo così possibile confrontare le varie tecniche proposte. È stato infatti dimostrato che
diverse classi di calcoli nominali (p.e. quelli della famiglia del pi-calcolo) possono essere rappresentate
con HDA, il che sembra promettere un grado di generalità sufficiente per usare gli HDA come
linguaggio intermedio comune per i vari approcci considerati nel progetto. Gli HDA definiscono un
utile strumento per la verifica a stati finiti, in quanto molti processi, grazie ad una implicita azione di
garbage collection, hanno un insieme di stati finito, laddove negli approcci tradizionali anche agenti molto
semplici sarebbero rappresentati da una struttura infinita. L’algoritmo di minimizzazione di HDA
fornirà un metodo generale per verificare proprietà di sicurezza sui calcoli nominali considerati. Infatti,
nonostante la formalizzazione di queste proprietà possa variare significativamente al variare del calcolo
considerato, l’algoritmo di minimizzazione di HDA potrà essere facilmente adattato, attraverso
l’opportuna regolazione di alcuni parametri.
Fase 2: Sicurezza dei linguaggi di programmazione commerciali
2-A. Specifica e run-time enforcement di politiche di sicurezza su programmi Java (mesi 7-12).
Estenderemo le tecniche di specifica studiate nella Fase 1A, per trattare politiche di sicurezza e di uso di
risorse su programmi Java. Questo richiederà di risolvere diversi problemi, che derivano sia dalla natura
più concreta del linguaggio trattato, sia dall’elevato grado di generalità che prevediamo di dare al nostro
approccio. Per gestire il più ampio insieme di situazioni che si potranno presentare in scenari reali,
rilasceremo alcune delle ipotesi fatte nella Fase 1. Coerentemente con la metodologia di aspect-oriented
programming, per ottenere un buon livello di separation of concerns tra programmazione di aspetti funzionali
e sicurezza, assumeremo che la figura deputata a scrivere le politiche di sicurezza non possa intervenire
sul codice sorgente dei programmi Java. Questo richiederà lo studio di metodi di specifica più fini
rispetto a quelli adottati nella Fase 1A, ad esempio prevedendo tecniche dipendenti dal contesto.
Inoltre, considereremo anche il caso in cui il programma sorgente Java non è disponibile, ma lo è solo il
bytecode risultante dalla compilazione. In questo modo sarà possibile gestire anche la messa in
sicurezza di codice mobile o fornito da terze parti untrusted. Per realizzare l’enforcement di politiche sul
bytecode Java, prenderemo come punto di partenza un prototipo per la riscrittura di bytecode
(chiamato “Jalapa”) attualmente in fase di sviluppo presso le unità di Cagliari e Pisa. La trasformazione
di tale prototipo in un tool efficacemente applicabile a situazioni reali richiederà un notevole sforzo
implementativo, sia per individuare ed eliminare tutte le possibili backdoors attraverso le quali potrebbero
essere tentati degli attacchi, sia per minimizzare l’impatto dell’enforcement delle politiche sulla
performance dei programmi. Realizzeremo inoltre un ambiente di programmazione, nella forma di un
plugin Eclipse, grazie al quale facilitare lo sviluppo e la messa in sicurezza di programmi Java. Compito
di questo plugin sarà anche quello di integrare i tool per la specifica e l’enforcement delle politiche con i
tool per l’analisi e la verifica di politiche di sicurezza descritti al punto seguente.
12 di 18
2-B. Analisi e verifica statica di politiche di sicurezza su programmi Java (mesi 7-18).
Studieremo analisi statiche su programmi Java e Java bytecode, sia allo scopo di ottimizzare il
meccanismo di enforcement descritto al punto precedente, sia per trattare alcune politiche non
imponibili da meccanismi di enforcement a tempo di esecuzione. Tra le varie tecniche di analisi,
particolarmente promettente sembra quella implementata da un analizzatore statico generico per
programmi Java multithread (chiamato “Checkmate”) sviluppato dall’unità di Venezia. L’intuizione di
un analizzatore generico è quella di specificare, al livello del bytecode, tutte le componenti necessarie
per l’analisi di un linguaggio di programmazione (ad esempio la semantica dei singoli costrutti e
l’approssimazione degli indirizzi creati a tempo di esecuzione), e definire solo l’interfaccia (ovvero quali
operazioni devono essere specificate) per altre componenti, p.e. il dominio numerico e la proprietà da
analizzare). L’analizzatore può quindi essere istanziato, ad esempio con diversi domini numerici e per
controllare diverse proprietà. In questo modo si può concentrare il lavoro solo sulle componenti
essenziali per l’analisi, dando per assodate tutte le problematiche specifiche del linguaggio analizzato.
Utilizzare un tale strumento per applicare metodi formali per la sicurezza a linguaggi di
programmazione commerciali appare particolarmente promettente, poiché permette di astrarre da tutte
le problematiche specifiche di un linguaggio di programmazione, per concentrarsi sugli aspetti
fondamentali a livello di sicurezza. La soluzione ideale per l’applicazione e l’implementazione di tali
tecniche su linguaggi commerciali è quindi proprio quella proposta dagli analizzatori generici, che
permettono di dedicarsi solo agli aspetti cruciali del modello formale, in quanto forniscono già una
soluzione per tutte le problematiche relative alla specificità del linguaggio di programmazione
analizzato.
3-A. Realizzazione di un prototipo di un sistema informatico per la dematerializzazione
documentale dell’Università di Cagliari (mesi 1-9).
Considereremo, come caso di studio principale, un sistema informatico per la dematerializzazione della
documentazione amministrativa dell’Università di Cagliari, con particolare riguardo ai processi di
gestione della carriera universitaria degli studenti. Con il termine “dematerializzazione” si intende la
ridefinizione dei processi amministrativi, allo scopo di eliminare la documentazione cartacea in favore
di documenti informatici. Oltre a ridurre i volumi di carta prodotti, la dematerializzazione favorisce lo
scambio dei documenti tra le amministrazioni per via telematica, diminuendo così i tempi necessari per
completare i vari processi amministrativi. Il nostro programma di ricerca per questa fase consiste
nell’analisi dei requisiti funzionali, nel progetto, e nella realizzazione di un prototipo di workflow
documentale che definisce le procedure di dematerializzazione amministrativa dello scenario
considerato, usando un motore per workflow open source e conforme agli standard WfMC-XPDL
(www.wfmc.org).
3-B. Analisi dei requisiti di sicurezza e studio dei possibili attacchi sull’interfaccia e sul
protocollo (mesi 10-15).
Poiché l’informatizzazione dei processi amministrativi descritti al punto precedente prevede il passaggio
da un sistema dove la sicurezza è garantita da meccanismi “fisici” (p.e. gli archivi cartacei che
contengono la documentazione), ad un sistema aperto e interoperabile, dove i vari utenti dell’Università
(docenti, studenti, personale amministrativo) fruiscono di servizi on-line attraverso una rete pubblica
(Internet), il problema della sicurezza è, in questo contesto, altamente critico. Anche ipotizzando
meccanismi di autenticazione perfetti, rimane aperta la possibilità che un errore presente
nell’implementazione di un servizio abbia conseguenze nefaste sulla sicurezza dell’intera applicazione.
Ricordiamo ancora che, solitamente, il processo di implementazione è focalizzato sugli aspetti
funzionali, e spesso i programmatori hanno solo una visione parziale dell’applicazione e delle
problematiche di sicurezza in gioco. Inoltre, l’uso improprio delle funzionalità implementate potrebbe
essere sfruttato per portare a compimento degli attacchi sulla logica dell’applicazione e sul protocollo di
13 di 18
comunicazione tra le varie componenti dell’applicazione. Studieremo l’esistenza di possibili attacchi di
questo tipo attraverso metodi formali.
3-C. Specifica delle proprietà di sicurezza e loro enforcement per il sistema informatico di
dematerializzazione documentale (mesi 10-18).
Usando il nostro approccio di separation of concerns tra funzionalità e sicurezza, lavoreremo nell’ipotesi
che l’implementazione del sistema informatico della fase 3A sia inaffidabile, e ipotizzeremo che una
terza parte, esperta di sicurezza, fornisca l’insieme delle politiche rilevanti per lo scenario in questione.
Potremo dunque rendere sicura l’implementazione, anche se fallata, applicando il meccanismo di
enforcement sviluppato nella fase 2A. Più in dettaglio, considereremo il prototipo di workflow
documentale implementato nella fase 3A, e specificheremo le politiche di sicurezza in gioco utilizzando
i formalismi introdotti nella fase 1A, e raffinati nella fase 2A. Sarà interessante capire se tali formalismi
sono sufficientemente espressivi per definire tutte le politiche rilevanti al nostro caso di studio, oppure
se ci sono delle politiche che richiedono tecniche ad-hoc. Dopodiché, sperimenteremo le tecniche di
analisi statica introdotte nelle fasi 1B-1C, e raffinate nella fase 2B, sia allo scopo di comprenderne la
reale efficacia, sia a quello di ottenere indizi sui punti nel codice dell’applicazione che potrebbero dar
luogo a delle vulnerabilità di sicurezza.
Diagramma di GANTT
Mesi
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1-A. Logiche ed automi per la sicurezza
W f

1-B. Analisi comportamentale di programmi
1-C. Verifica statica di proprietà di sicurezza
W f
Fase 2: Sicurezza dei linguaggi di programmazione commerciali
2-A. Specifica e run-time enforcement di politiche di sicurezza su programmi Java

2-B. Analisi e verifica statica di politiche di sicurezza su programmi Java
W f
3-A. Realizzazione di un prototipo di un sistema informatico per la dematerializzazione

documentale dell’Università di Cagliari
3-B. Analisi dei requisiti di sicurezza e studio dei possibili attacchi sull’interfaccia e sul
protocollo
3-C. Specifica delle proprietà di sicurezza e loro enforcement per il sistema informatico di
dematerializzazione documentale

13 - Ruolo di ciascuna unità operativa in funzione degli obiettivi previsti e relative modalità di
integrazione e collaborazione
Tutte le sedi coinvolte in questo progetto hanno un background consolidato nella ricerca di metodi
formali per la sicurezza del software, sia riguardo agli aspetti prettamente fondazionali, sia riguardo a
quelli sperimentali ed applicativi. I risultati delle ricerche delle tre unità coinvolte sono riconosciuti dalla
comunità scientifica internazionale, e hanno portato a collaborazioni rilevanti con atenei ed istituti di
ricerca italiani ed esteri.
14 di 18
Data la presenza di molti interessi comuni tra le tre unità, questo progetto fornirà un incentivo per
avviare nuove collaborazioni. Nel seguito, discutiamo nel dettaglio il ruolo di ciascuna unità
relativamente alle varie fasi del progetto individuate nella Sezione 12.
1A. Logiche ed automi per la sicurezza
Porteremo avanti la collaborazione tra le unità di Cagliari e Pisa riguardo allo studio di automi per la
specifica e l’enforcement di politiche di uso di risorse e di sicurezza. Cagliari approfondirà gli studi
fondazionali iniziati sugli usage automata, ed insieme a Pisa svilupperà le tecniche di verifica basate su
model-checking. L’unità di Cagliari studierà logiche, modali e fuzzy, per la specifica di politiche e di
contratti.
1B. Analisi comportamentale di programmi
C’è un forte interesse comune tra tutte le unità sugli aspetti di analisi comportamentale di programmi,
sia nel paradigma funzionale che ad oggetti. Le unità di Cagliari e quella di Pisa studieranno analisi
basate su sistemi di tipo ed effetto, mentre quella di Venezia studierà tecniche basate su interpretazione
astratta. Le tre unità collaboreranno alla comparazione dei risultati ottenuti attraverso i diversi tipi di
analisi, in particolare relativamente alla precisione delle approssimazioni ottenute.
1C. Verifica di proprietà di scurezza
Questo punto prevede l’interazione tra tutte le unità. In particolare, l’unità di Pisa approfondirà gli
aspetti fondazionali legati agli automi History-Depenent, e collaborerà con Cagliari e con Venezia per
mappare su di essi le astrazioni (calcoli nominali) costruite nella fase 1B, e per effettuare la verifica delle
proprietà di sicurezza.
2A. Specifica e run-time enforcement di politiche di sicurezza su programmi Java
L’implementazione del meccanismo di enforcement di politiche su programmi Java sarà portata avanti
dall’unità di Cagliari, anche grazie a personale specificamente attivato per questo progetto; in
collaborazione con l’unità di Pisa, svilupperà l’ambiente di programmazione basato su plugin Eclipse.
2B. Analisi e verifica di politiche di sicurezza su programmi Java
C’è un forte interesse comune tra tutte le unità sugli aspetti di analisi considerati in questa fase, in
particolare riguardo alla sperimentazione di varie analisi di proprietà di sicurezza attraverso
l’analizzatore statico generico per programmi Java (Checkmate) sviluppato dall’unità di Venezia. Tutte
le unità collaboreranno allo studio e all’implementazione di analisi statiche per inferire aspetti
comportamentali di programmi Java bytecode, e per verificarne proprietà di sicurezza.
3A. Realizzazione di un prototipo di un sistema informatico per la dematerializzazione
documentale dell’Università di Cagliari
Questa fase sarà sviluppata dall’unità di Cagliari, anche grazie a personale specificamente attivato per
questo progetto.
3B. Analisi dei requisiti di sicurezza e studio dei possibili attacchi sull’interfaccia e sul
protocollo
A questa fase parteciperanno tutte le unità coinvolte nel progetto. In particolare le varie sedi
beneficieranno dell’esperienza dell’unità di Venezia riguardo allo studio di attacchi basati sulla logica
dell’applicazione, e delle unità di Pisa e di Venezia riguardo all’analisi formale di protocolli per la
sicurezza.
3C. Specifica delle proprietà di sicurezza e loro enforcement per il sistema informatico di
dematerializzazione documentale
Questa fase sarà sviluppata principalmente dall’unità di Cagliari, anche grazie a personale
specificamente attivato per questo progetto. Non escludiamo comunque una collaborazione con l’unità
di Venezia, che ha una esperienza consolidata nello studio delle vulnerabilità di sistemi di
15 di 18
autenticazione, crypto-USB e smartcard, per sperimentare tecniche analoghe sui dispositivi integrati nel
sistema informatico in esame.
14 - Risultati attesi dalla ricerca, il loro interesse per l’avanzamento della conoscenza e le
eventuali potenzialità applicative
Indichiamo, nel seguito, i principali risultati attesi per ogni fase. Tali risultati sono volutamente molto
specifici in modo da poter essere verificati, e costituiranno, quindi, lo strumento primario per la
valutazione dell’avvenuto raggiungimento degli obiettivi del progetto. L’interesse per l’avanzamento
della conoscenza è stato illustrato in modo esauriente nelle sezioni 9, 10 e e 12.
Risultati attesi Fase 1

Caratterizzazione dell’espressività degli usage automata e studio della complessità computazionale
dell’enforcement basato su usage automata.
Una nuova logica modale per politiche di uso di risorse e di delega.
Una nuova logica fuzzy per esprimere politiche di service-level agreement.
Sistemi di tipo ed effetto per l’analisi comportamentale di linguaggi con creazione ed uso di risorse.
Interpretazione astratta per l’analisi comportamentale di linguaggi con creazione ed uso di risorse, e
confronto con i sistemi di tipo ed effetto al punto precedente.
Uso di automi History-Dependent come linguaggio intermedio per la verifica delle proprietà di
sicurezza definite nel progetto.

Specifica di politiche di sicurezza basate sulla storia, adatte a controllare il corretto uso di risorse in
programmi Java.
Implementazione di un meccanismo di enforcement delle suddette politiche, mediante riscrittura di
bytecode Java.
Analisi statica su programmi Java per costruire approssimazioni dei pattern di uso di risorse per
programmi Java bytecode.
Verifica statica delle approssimazioni ottenute al punto precedente, e suo uso per l’ottimizzazione
del meccanismo di enforcement a tempo di esecuzione.

Analisi dei requisiti, progetto ed implementazione di un prototipo di un sistema informatico per la
dematerializzazione della documentazione amministrativa dell’Università di Cagliari.
Analisi dei requisiti di sicurezza del sistema informatico al punto precedente.
Analisi degli attacchi sull’interfaccia e sul protocollo dei processi amministrativi individuati al primo
punto.
Specifica dei requisiti di sicurezza mediante i formalismi sviluppati all’interno del progetto.
Enforcement delle politiche di sicurezza specificate al punto precedente sul prototipo del sistema
informatico, mediante le tecniche sviluppate all’interno del progetto.
Analisi e verifica delle politiche di sicurezza sul prototipo del sistema informatico, mediante le
tecniche sviluppate all’interno del progetto.
15 - Elementi e criteri proposti per la verifica dei risultati raggiunti
Il successo del progetto potrà essere misurato in termini del raggiungimento dei risultati attesi elencati
in sezione 14. Tali risultati produrranno principalmente pubblicazioni su riviste o in atti di conferenze
del settore, e rapporti tecnici di ricerca. Stimando una pubblicazione per ogni risultato atteso nelle fasi 1
e 2, e due pubblicazioni riguardo alla fase 3, possiamo quindi prevedere circa 12 pubblicazioni totali
sulle tematiche specifiche di questo progetto. Un ulteriore parametro di valutazione sarà dato dal
rilascio di strumenti di enforcement e di analisi per la sicurezza, e di ambienti di programmazione
sicura, e dalla loro divulgazione attraverso seminari e siti Web dedicati.
16 di 18
Riteniamo inoltre fondamentale l’interazione tra le unità, e l’apertura verso la comunità nazionale ed
internazionale di ricerca nel settore. Per questo scopo, oltre che per divulgare i risultati e per ottenere
riscontri da parte di altri esperti nell’area della sicurezza, abbiamo previsto l’organizzazione di un
workshop sulle tematiche del progetto, nella sede di Cagliari. Il successo di tale workshop potrà
costituire un altro elemento di valutazione della riuscita del progetto.
16 - Mesi persona complessivi indicativi previsti per il Progetto di Ricerca e Imputazione dei costi
del personale a carico del progetto
Personale
attivato per
questo
progetto
Costi imputabili
nella misura del
20% del costo
totale del Progetto
Unità Operativa I
(Cagliari)
Componenti della sede dell’Unità Operativa
Presenza di partner di altri Dipartimenti o Enti di Ricerca
Dottorato
Titolari di borse
Post-dottorato
Scuola di Specializzazione
Personale di ricerca attivato Assegnisti
per questo specifico
Borsisti
progetto
Altre tipologie
Altro Personale esterno attivato per questo specifico progetto di ricerca
Totale
Personale
attivato per
questo
progetto
Costi imputabili
nella misura del
20% del costo
totale del Progetto
Unità Operativa I
(Pisa)
Dottorato
Titolari di borse
Post-dottorato
Borsisti
progetto
Altre tipologie
Totale
Personale
attivato per
questo
progetto
Costi imputabili
nella misura del
20% del costo
totale del Progetto
Unità Operativa I
(Venezia)
Dottorato
Titolari di borse
Post-dottorato
Borsisti
progetto
Altre tipologie
Totale
17 di 18
Numero
Disponibilità
temporale
Indicativa prevista
Costi a carico del
progetto:
Mesi persona
3
9
2
1
2
18
36
18
36
6
63
56
Numero
Disponibilità
temporale
Indicativa prevista
Costi a carico del
progetto:
Mesi persona
3
1
9
1
1
4
10
1
Numero
Disponibilità
temporale
Indicativa prevista
Costi a carico del
progetto:
Mesi persona
3
5
1
6
14
9
19
1
17 - Costo complessivo del progetto articolato per voci
Voce di spesa
Materiale inventariabile
Grandi Attrezzature
Materiale di consumo
Spese per calcolo ed elaborazione dati
Spese di personale (max.20% del costo totale del progetto)
Personale attivato per questo progetto
Servizi esterni
Missioni
Pubblicazioni
Partecipazione / Organizzazione convegni
Altro (voce da utilizzare solo in caso di spese non riconducibili alle voci sopraindicate)
Spese Generali (60% delle spese di personale, ad esclusione del personale attivato per il progetto)*
Totale
Unità I
Unità II
Unità III
(Cagliari)
(Pisa)
(Venezia)
8.000
0
3.000
0
(a)
8.000
68.500
0
8.000
0
20.000
5.000
4.800
125.300
4.000
0
500
0
(b)
7.000
0
0
7.000
0
2.000
0
4.200
24.700
4.000
0
500
0
(c)
7.000
0
0
8.000
0
2.500
0
4.200
26.200
* L’importo della voce sarà calcolato forfettariamente nella misura del 60% (sessanta per cento) dell’ammontare dei costi per il personale, costo che in ogni caso non
deve eccedere il 20% (venti per cento) del costo totale ammissibile del progetto.
N.B.: per il calcolo delle spese di personale (max. 20% del costo totale del progetto) utilizziamo la
quota forfettaria PRIN 2008. In particolare:
(a) 2 mesi-persona per 1 ricercatore = 2 × 4000 € = 8000 €
(b) 1 mese-persona per 1 professore ordinario = 7000 €
(c) 1 mese-persona per 1 professore ordinario = 7000 €
18 - Prospetto finanziario suddiviso per Unità Operative
Voce di spesa
Costo complessivo
Firma .........................................................
Unità I
Unità II
Unità III
(Cagliari)
(Pisa)
(Venezia)
125.300
24.700
26.200
Data............................................
18 di 18