RISULTATI ATTESI
Nel corso dei 2 anni del progetto si vuole sviluppare un prototipo per la
trasformazione automatica di programmi che sia basato su un modello formale del
problema (sviluppato dall'Università degli Studi di Verona). Questo prototipo,
rispetto a quelli esistenti, avrebbe la caratteristica di poter dare
certificazione formale del livello di protezione raggiunto dal codice
trasformato. In particolare, assumendo di poter conoscere la potenza dell'utente
maleintenzionatodato, si potrà individuare il tipo di trasformazione necessaria
per difendere un programma da tale tipo di attacco. L'idea è quella di poter
“regolare” il grado di protezione del codice in base alle necessità.
Il prototipo scritto in Java sarà sviluppato nelle sue 4 parti principali:
1. Interfaccia per la definizione del livello di sicurezza
2. Modulo di trasformazione software
3. Interfaccia grafica sulla struttura dei programmi
4. Pacchetto di valutazione delle prestazioni
Nel seguito elenchiamo gli indicatori di prestazione del prototipo:
– Numero di trasformazioni fornite: numero dei differenti offuscatori e
watermarker di codice implementati
dal prototipo (offuscamento di controllo, offuscamento dei dati, offuscamento di
layout, watermarking
statico, watermarking dinamico, watermarking astratto)
– Degradazione ammissibile: massimo 10%. Viene fissata una soglia massima di
degradazione delle
prestazioni del programma accettata dall'offuscamento e dal watermarking di
programmi. Ovvero il
programma offuscato (o con il watermark) dovrà avere una perdita di prestazioni
rispetto al programma
originale inferiore al 10%.
– Complessità del tipo di attacco ammissibile. Un attacco è detto ammissibile
quando è in grado di violare
la proprietà intellettuale del software anche quando questo è stato protetto
attraverso tecniche di
offuscamento o di watermarking del codice. Questo significa che l'utente
maleintenzionato riesce a
invertire l'offuscamento (deoffuscare) del codice o ad eliminare la firma
inserita dal software watermarking
riottenendo cosiì il programma originale. Le tecniche proposte dal prototipo
sono tanto più efficienti
quanto più è complesso il tipo di attacco ammissibile.
– Gestione della combinazione delle diverse tecniche. È auspicabile che il
prototipo sia in grado si
comporre le diverse tecniche di offuscamento del codice e di software
watermarking tra loro.
Per quanto riguarda la qualità del prototipo si intende fornire:
1. Prototipo documentato. Il prototipo sarà fornito di adeguata documentazione
nella quale vengono
descritte le specifiche e le caratteristiche del prodotto. Questo verrà
sviluppato seguendo un processo di
sviluppo a spirale mostrato nell'immagine seguente. Partendo dal centro della
spirale il progetto segue le
fasi di: analisi dei rischi e pianificazione, analisi dei requisiti,
progettazione (disegno del progetto,
implementazione e test), e valutazione. Il numero di iterazioni della sequenza
di queste fasi è arbitrario e
dipende dal grado di robustezza che si vuole ottenere per quanto riguarda
l’immissione di watermarks ed
offuscamento.
2. Valutazione su banchmarks noti in
letteratura, in larga parte programmi C e C++. Il prototipo verrà testato e
valutato su banchmarks standard (es: gcc, gzip, gap...).
3. Pubblicazione dei risultati sperimentali
ottenuti in atti di congressi e journals scientifici di rilevanza
internazionale.
4. Possibilità di integrazione di tecnologie
differenti (control-flow obfuscation, data-obfuscation, layout obfuscation) per
la trasformazione di programmi.
5. Possibilita' di trasformare codice
scritto in diversi linguaggi di programmazione, con particolare riferimento ai
linguaggi ad oggetti C++ e Java. In questo ambito le operazioni di
trasformazione si concentreranno sia sul codice sorgente che su codice
intermedio, generato da compilatori;
6. Definizione di uno standard per la
definizione e l’implementazione di strumenti di modulazione del grado di
sicurezza e robustezza di watermarks ed offuscamento.
7. Gestione di programmi di grandi
dimensioni (nell’ordine di 1500 user-functions), in tempi di trasformazione
ragionevoli.
8. Possibilità di controllare la fase di
progettazione dei watermarks e delle tecniche di offuscamento in termini della
loro robustezza e dei costi di trasformazione (tempo, degradazione performances
e spazio per applicazioni embedded tipo java-card) attesi.
9. Migliori risultati in termini di
robustezza del watermark e dell’offuscamento rispetto ad altri prototipi noti:
DIABLO e SANDMARK.
