Montsalvat: Partizionamento delle Applicazioni Java per Minimizzare la TCB in Intel SGX

Informazioni Fondamentali

• ID Articolo: 2305.00766
• Titolo: Montsalvat: Partizionamento delle Applicazioni Java per Minimizzare la TCB in Intel SGX
• Autori: Peterson Yuhala, Jämes Ménétrey, Pascal Felber, Valerio Schiavoni, Alain Tchana, Gaël Thomas, Hugo Guiroux, Jean-Pierre Lozi
• Classificazione: cs.CR (Crittografia e Sicurezza)
• Conferenza di Pubblicazione: 22nd International Middleware Conference (Middleware 2021)
• Link Articolo: https://arxiv.org/abs/2305.00766

Riassunto

La popolarità del linguaggio di programmazione Java ha portato alla sua ampia adozione nelle infrastrutture di cloud computing. Tuttavia, le applicazioni Java eseguite in ambienti cloud non affidabili sono vulnerabili a vari attacchi privilegiati. L'emergere di ambienti di esecuzione affidabili (TEE) come Intel SGX mitiga questo problema. I TEE proteggono il codice e i dati all'interno di enclave sicuri, rendendoli inaccessibili ai software non affidabili, inclusi kernel e hypervisor. Per utilizzare efficacemente i TEE, gli sviluppatori devono partizionare manualmente le applicazioni in componenti affidabili e non affidabili, al fine di ridurre la dimensione della base di calcolo affidabile (TCB) e minimizzare il rischio di vulnerabilità di sicurezza. Questo articolo presenta lo strumento Montsalvat, che fornisce un metodo di partizionamento basato su annotazioni pratico e intuitivo per applicazioni Java orientate agli enclave sicuri. Montsalvat fornisce un meccanismo simile a RMI per garantire la comunicazione tra oggetti e la raccolta coerente della memoria tra componenti partizionati.

Contesto di Ricerca e Motivazione

Definizione del Problema

1. Minacce di Sicurezza: Le applicazioni Java in ambienti cloud non affidabili affrontano minacce di attacchi privilegiati, inclusi attacchi a livello di kernel e hypervisor
2. Requisito di Minimizzazione della TCB: Quando si utilizzano TEE come Intel SGX, è necessario minimizzare la base di calcolo affidabile per ridurre la superficie di attacco
3. Complessità del Partizionamento: Il partizionamento manuale delle applicazioni Java richiede la gestione di problemi complessi come la comunicazione tra oggetti e la coerenza della raccolta della memoria

Limitazioni delle Soluzioni Esistenti

1. Soluzioni di Applicazione Completa: SCONE, Graphene-SGX e altri inseriscono l'intera applicazione (inclusa la JVM) nell'enclave, con una TCB eccessivamente grande (milioni di righe di codice)
2. Soluzioni Specifiche del Framework: VC3, SecureKeeper e altri sono rivolti solo a framework specifici, mancando di generalità
3. Soluzioni Esistenti di Partizionamento Java:
   • Civet richiede un LibOS completo, la TCB rimane comunque grande
   • Uranus richiede strumenti di terze parti per dedurre le partizioni affidabili, con maggiore intervento dello sviluppatore

Motivazione della Ricerca

Sviluppare uno strumento di partizionamento Java generico e automatizzato in grado di:

• Fornire un modo di annotazione intuitivo a livello di classe
• Implementare una comunicazione efficiente tra oggetti attraverso enclave
• Garantire la coerenza della raccolta della memoria distribuita
• Ridurre significativamente la dimensione della TCB

Contributi Fondamentali

1. Metodo di Partizionamento Basato su Annotazioni: Propone un modo di annotazione pratico e intuitivo a livello di classe (@Trusted, @Untrusted, @Neutral) per partizionare le applicazioni Java
2. Meccanismo RMI: Progetta un meccanismo di comunicazione tra oggetti attraverso enclave simile a RMI, implementando invocazioni di metodi remoti trasparenti tramite oggetti proxy
3. Raccolta della Memoria Distribuita: Implementa un'estensione GC basata su riferimenti deboli, garantendo la coerenza della distruzione degli oggetti tra heap affidabili e non affidabili
4. Integrazione GraalVM: Integrazione profonda con GraalVM native-image, sfruttando la compilazione AOT per ottimizzare le prestazioni
5. Miglioramento delle Prestazioni: Realizza miglioramenti significativi delle prestazioni nelle applicazioni reali (PalDB 6.6×, GraphChi 2.2×)

Spiegazione Dettagliata del Metodo

Definizione del Compito

Input: Codice sorgente dell'applicazione Java con annotazioni di sicurezza Output: Native image partizionato affidabile e non affidabile, distribuibile nell'ambiente Intel SGX Vincoli: Mantenere la semantica originale dell'applicazione, garantire la comunicazione tra oggetti e la coerenza GC

Architettura del Sistema

Il flusso di lavoro di Montsalvat comprende 4 fasi principali:

1. Fase di Annotazione del Codice

Fornisce tre tipi di annotazioni:

• @Trusted: Le classi e le loro istanze vengono sempre create e operate all'interno dell'enclave
• @Untrusted: Le classi e le loro istanze vengono sempre operate al di fuori dell'enclave
• @Neutral: Classi di utilità, possono esistere indipendentemente su entrambi i lati con più copie

2. Fase di Trasformazione del Bytecode

Utilizza il framework Javassist per la trasformazione del bytecode:

Generazione di Classi Proxy:

• Genera classi proxy per ogni classe affidabile nel runtime non affidabile
• Genera classi proxy per ogni classe non affidabile nel runtime affidabile
• Le classi proxy mantengono le firme dei metodi originali, ma il corpo del metodo viene sostituito con chiamate attraverso enclave

Iniezione di Metodi di Inoltro:

// Il metodo originale viene trasformato in metodo di inoltro
@CEntryPoint
public static void relayAccount(Isolate ctx, int hash, 
                               CCharPointer buf, int b) {
    String s = deserialize(buf);
    Account mirror = new Account(s, b);
    mirrorProxyRegistry.add(hash, mirror);
}

Meccanismo di Mappatura degli Oggetti:

• Ogni oggetto proxy riceve un valore hash univoco
• Mantiene registri di mappatura proxy-mirror
• Implementa riferimenti agli oggetti attraverso enclave tramite valori hash

3. Partizionamento Native Image

Sfrutta l'analisi statica di GraalVM:

• Image affidabile: contiene implementazioni concrete di classi affidabili + proxy di classi non affidabili
• Image non affidabile: contiene implementazioni concrete di classi non affidabili + proxy di classi affidabili
• L'analisi point-to elimina automaticamente il codice non raggiungibile

4. Generazione di Applicazioni SGX

• Libreria Shim: Libreria leggera che intercetta le chiamate libc non supportate e le inoltra al runtime non affidabile
• Generazione EDL: Genera automaticamente file di linguaggio di definizione dell'enclave
• Collegamento Finale: Genera l'applicazione SGX eseguibile

Punti di Innovazione Tecnica

1. Strategia di Partizionamento a Livello di Classe

Rispetto al partizionamento a livello di metodo o dati:

• Più intuitivo per la programmazione orientata agli oggetti
• Evita analisi complesse del flusso di dati
• Confini di incapsulamento naturali

2. Meccanismo di Proxy Trasparente

• Mantiene il modello di programmazione originale
• Gestisce automaticamente la serializzazione/deserializzazione dei parametri
• Supporta il passaggio di grafi di oggetti complessi attraverso enclave

3. Progettazione GC Distribuita

// Sincronizzazione GC basata su riferimenti deboli
WeakReference<ProxyObject> weakRef = new WeakReference<>(proxy);
proxyWeakRefs.add(new ProxyWeakRefEntry(weakRef, proxy.getHash()));

// GC Helper controlla periodicamente
if (weakRef.get() == null) {
    // L'oggetto proxy è stato sottoposto a GC, notifica la distruzione dell'oggetto mirror
    notifyMirrorDestruction(hash);
}

Configurazione Sperimentale

Ambiente Sperimentale

• Hardware: CPU Intel Xeon E3-1270 (3.80 GHz), 64GB RAM
• Configurazione SGX: 128MB EPC (93.5MB disponibili), heap massimo 4GB, stack 8MB
• Software: Ubuntu 18.04, SGX SDK v2.11, GraalVM CE v21.0.0
• Baseline di Confronto: SCONE (JVM in esecuzione all'interno dell'enclave)

Metriche di Valutazione

• Metriche di Prestazione: Tempo di esecuzione dell'applicazione, latenza operativa
• Analisi dei Costi: Costi di creazione degli oggetti proxy, costi delle chiamate RMI, prestazioni GC
• Rapporto di Accelerazione: Miglioramento delle prestazioni rispetto ai metodi non partizionati e SCONE

Applicazioni di Test

1. Benchmark Sintetici: Operazioni CPU-intensive e I/O-intensive
2. PalDB: Archivio chiave-valore incorporato di LinkedIn
3. GraphChi: Framework di elaborazione di grafi su larga scala (algoritmo PageRank)
4. SPECjvm2008: Test di microbeneficio Java standard

Risultati Sperimentali

Risultati Principali delle Prestazioni

1. Miglioramento delle Prestazioni delle Applicazioni Reali

• PalDB: Miglioramento di 6.6× rispetto a SCONE (schema RTWU), 2.8× (schema RUTW)
• GraphChi: Miglioramento di 2.2× rispetto a SCONE
• SPECjvm2008: Miglioramento significativo in 5/6 benchmark (1.38×-2.66×)

2. Analisi dei Costi degli Oggetti Proxy

• La creazione di oggetti proxy è 3-4 ordini di grandezza più lenta degli oggetti concreti
• Le chiamate RMI sono 3-4 ordini di grandezza più lente delle chiamate locali
• La serializzazione dei parametri aggiunge 10× (all'interno dell'enclave) a 3× (al di fuori dell'enclave) di overhead

3. Impatto sulle Prestazioni GC

• GC all'interno dell'enclave è 1 ordine di grandezza più lento di GC al di fuori dell'enclave
• Verifica della coerenza GC: gli oggetti mirror vengono correttamente puliti quando gli oggetti proxy vengono distrutti

Esperimenti di Ablazione

Confronto delle Strategie di Partizionamento

Attraverso test di benchmark sintetici con diverse proporzioni di classi affidabili:

• CPU-intensive: Spostare più classi al di fuori dell'enclave produce miglioramenti significativi delle prestazioni
• I/O-intensive: Spostare le operazioni I/O al di fuori dell'enclave produce miglioramenti più evidenti

Non Partizionato vs Partizionato vs SCONE

In tutti i test, l'ordine delle prestazioni è:

1. Esecuzione nativa (senza SGX) - Più veloce ma non sicuro
2. Native image partizionato - Bilancia prestazioni e sicurezza
3. Native image non partizionato - Prestazioni medie
4. SCONE+JVM - Più lento ma migliore compatibilità

Analisi dei Casi

Strategia di Partizionamento di PalDB

@Trusted class DBReader   // Protezione delle operazioni di lettura sensibili
@Untrusted class DBWriter // Spostamento delle operazioni di scrittura I/O al di fuori dell'enclave

Lo schema RTWU ha prestazioni migliori perché evita costose conversioni di scrittura dell'enclave.

Strategia di Partizionamento di GraphChi

@Trusted class GraphChiEngine    // Protezione della logica di calcolo principale
@Untrusted class FastSharder     // Operazioni I/O di partizionamento del grafo

Dopo aver spostato le operazioni di partizionamento al di fuori dell'enclave, le prestazioni si avvicinano a quelle native.

Lavori Correlati

Soluzioni di Enclave per Applicazioni Complete

• SCONE, Graphene-SGX, SGX-LKL: Forniscono buona compatibilità ma TCB eccessiva
• Haven: Soluzione iniziale per applicazioni complete

Partizionamento Specifico del Framework

• VC3: Analisi dati Hadoop
• SecureKeeper: Estensione ZooKeeper
• Opaque: Piattaforma Spark SQL
• Limitazioni: Applicabili solo a framework specifici

Soluzioni di Partizionamento Generico

• Glamdring: Partizionamento automatico C/C++, non applicabile a Java
• Panoply: Soluzione di microcontenitori
• Civet: Partizionamento Java ma utilizza LibOS completo
• Uranus: Annotazione a livello di metodo, richiede strumenti di terze parti

Conclusioni e Discussione

Conclusioni Principali

1. Verifica della Fattibilità: Lo schema di partizionamento a livello di classe basato su annotazioni è fattibile e intuitivo
2. Vantaggi di Prestazione: Le applicazioni partizionate mostrano miglioramenti significativi delle prestazioni rispetto ai metodi di enclave completo
3. Riduzione della TCB: La riduzione significativa del codice affidabile attraverso la libreria shim piuttosto che LibOS
4. Facilità di Sviluppo: Il metodo di annotazione è più intuitivo per gli sviluppatori

Limitazioni

1. Requisiti di Incapsulamento: Presuppone che tutte le classi annotate siano correttamente incapsulate (campi privati)
2. Overhead RMI: Le chiamate attraverso enclave hanno ancora un overhead significativo, non adatte a scenari di interazione frequente
3. Dipendenza da GraalVM: Limitato all'ecosistema GraalVM
4. Limitazioni dell'Analisi Statica: Il supporto per alcune caratteristiche dinamiche è limitato

Direzioni Future

1. Chiamate Senza Conversione: Ricerca di tecniche per ridurre le costose chiamate RMI
2. Supporto Multi-Isolate: Estensione a ambienti con più isolate
3. Partizionamento Automatico: Raccomandazioni di partizionamento automatico basate su analisi statica
4. Supporto per Altri TEE: Estensione ad AMD SME, ARM TrustZone

Valutazione Approfondita

Punti di Forza

1. Forte Innovazione: Primo schema di partizionamento Java a livello di classe, con design intuitivo e ragionevole
2. Completezza Ingegneristica: Catena di strumenti completa dalle annotazioni all'applicazione SGX finale
3. Prestazioni Eccellenti: Dimostra miglioramenti significativi delle prestazioni nelle applicazioni reali
4. Alto Valore Pratico: Risolve il problema pratico della distribuzione sicura in cloud delle applicazioni Java

Insufficienze

1. Overhead Ancora Significativo: L'overhead delle chiamate RMI rimane di 3-4 ordini di grandezza, limitando gli scenari di applicazione
2. Condizioni di Presupposto Rigorose: I requisiti di incapsulamento delle classi potrebbero limitare l'applicabilità del codice esistente
3. Valutazione Incompleta: Mancanza di valutazione di applicazioni su larga scala e a lungo termine
4. Analisi di Sicurezza Insufficiente: L'analisi della protezione contro attacchi avanzati come gli attacchi ai canali laterali è limitata

Impatto

1. Contributo Accademico: Fornisce nuove prospettive per il partizionamento delle applicazioni di linguaggi gestiti in ambienti TEE
2. Valore Pratico: Può essere direttamente applicato al rafforzamento della sicurezza delle applicazioni Java in cloud
3. Riproducibilità: Gli autori si impegnano a rilasciare il codice open source, facilitando la riproduzione della ricerca e l'estensione

Scenari di Applicazione

1. Servizi Java in Cloud: Applicazioni cloud che necessitano di protezione della logica di business sensibile
2. Piattaforme di Analisi Dati: Framework di analisi che elaborano dati sensibili
3. Applicazioni Fintech: Servizi finanziari che richiedono garanzie di sicurezza elevate
4. Elaborazione Edge IoT: Elaborazione sicura in ambienti con risorse limitate

Bibliografia

L'articolo cita 60 lavori correlati, coprendo tecnologie SGX, applicazioni TEE, sicurezza Java, ottimizzazione della compilazione e altri campi importanti, fornendo una base teorica solida per questa ricerca.

Valutazione Complessiva: Questo è un articolo di ricerca di alta qualità che affronta il problema pratico della distribuzione delle applicazioni Java in ambienti TEE. Il design del metodo è ragionevole, l'implementazione è completa, gli esperimenti sono sufficienti e ha buon valore accademico e pratico. Sebbene ci sia ancora spazio per miglioramenti nell'overhead RMI e nell'applicabilità, fornisce importanti riferimenti per la ricerca in campi correlati.