Montsalvat: Partitionierung von Java-Anwendungen zur Minimierung der TCB in Intel SGX

Grundlegende Informationen

• Paper-ID: 2305.00766
• Titel: Montsalvat: Partitionierung von Java-Anwendungen zur Minimierung der TCB in Intel SGX
• Autoren: Peterson Yuhala, Jämes Ménétrey, Pascal Felber, Valerio Schiavoni, Alain Tchana, Gaël Thomas, Hugo Guiroux, Jean-Pierre Lozi
• Klassifizierung: cs.CR (Kryptographie und Sicherheit)
• Veröffentlichungskonferenz: 22. International Middleware Conference (Middleware 2021)
• Paper-Link: https://arxiv.org/abs/2305.00766

Zusammenfassung

Die Popularität der Java-Programmiersprache führt zu ihrer weit verbreiteten Verwendung in Cloud-Computing-Infrastrukturen. Java-Anwendungen, die in nicht vertrauenswürdigen Cloud-Umgebungen ausgeführt werden, sind jedoch anfällig für verschiedene privilegierte Angriffe. Das Aufkommen von Trusted Execution Environments (TEE) wie Intel SGX mindert dieses Problem. TEE schützt Code und Daten in sicheren Enklaven vor dem Zugriff durch nicht vertrauenswürdige Software, einschließlich des Kernels und des Hypervisors. Um TEE effizient zu nutzen, müssen Entwickler Anwendungen manuell in vertrauenswürdige und nicht vertrauenswürdige Teile aufteilen, um die Größe der Trusted Computing Base (TCB) zu reduzieren und das Sicherheitsrisiko zu minimieren. Dieses Paper stellt das Montsalvat-Tool vor, das eine praktische und intuitive annotationsbasierte Partitionierungsmethode für auf Sicherheitsenklaven ausgerichtete Java-Anwendungen bietet. Montsalvat bietet einen RMI-ähnlichen Mechanismus zur Gewährleistung der Kommunikation zwischen Objekten sowie konsistente Garbage Collection über partitionierte Komponenten hinweg.

Forschungshintergrund und Motivation

Problembeschreibung

1. Sicherheitsbedrohungen: Java-Anwendungen in nicht vertrauenswürdigen Cloud-Umgebungen sind Bedrohungen durch privilegierte Angriffe ausgesetzt, einschließlich Kernel- und Hypervisor-Ebenen-Angriffen
2. TCB-Minimierungsanforderung: Bei der Verwendung von TEE wie Intel SGX muss die Trusted Computing Base minimiert werden, um die Angriffsfläche zu reduzieren
3. Partitionierungskomplexität: Die manuelle Aufteilung von Java-Anwendungen erfordert die Behandlung komplexer Probleme wie Objektkommunikation und Garbage-Collection-Konsistenz

Einschränkungen bestehender Lösungen

1. Vollständige Anwendungslösungen: SCONE, Graphene-SGX und ähnliche Systeme platzieren die gesamte Anwendung (einschließlich JVM) in der Enklave, was zu einer großen TCB führt (Millionen von Codezeilen)
2. Framework-spezifische Lösungen: VC3, SecureKeeper und ähnliche sind nur auf spezifische Frameworks ausgerichtet und mangelt es an Allgemeingültigkeit
3. Bestehende Java-Partitionierungslösungen:
   • Civet erfordert ein vollständiges LibOS, TCB bleibt groß
   • Uranus erfordert Werkzeuge von Drittanbietern zur Inferenz vertrauenswürdiger Partitionen mit erheblicher Entwicklereinmischung

Forschungsmotivation

Entwicklung eines universellen, automatisierten Java-Anwendungspartitionierungswerkzeugs, das:

• Eine intuitive Annotation auf Klassenebene bietet
• Effiziente Objektkommunikation über Enklaven hinweg ermöglicht
• Konsistenz der verteilten Garbage Collection gewährleistet
• Die TCB-Größe erheblich reduziert

Kernbeiträge

1. Annotationsbasierte Partitionierungsmethode: Vorschlag einer praktischen und intuitiven Annotation auf Klassenebene (@Trusted, @Untrusted, @Neutral) zur Partitionierung von Java-Anwendungen
2. RMI-Mechanismus: Entwurf eines RMI-ähnlichen Mechanismus für Objektkommunikation über Enklaven hinweg, der transparente Remote-Methodenaufrufe durch Proxy-Objekte ermöglicht
3. Verteilte Garbage Collection: Implementierung einer auf schwachen Referenzen basierenden GC-Erweiterung, die Objektvernichtungskonsistenz zwischen vertrauenswürdigen und nicht vertrauenswürdigen Heaps gewährleistet
4. GraalVM-Integration: Tiefe Integration mit GraalVM native-image, Nutzung von AOT-Kompilierung zur Leistungsoptimierung
5. Leistungsverbesserung: Erreichung signifikanter Leistungssteigerungen in echten Anwendungen (PalDB 6,6×, GraphChi 2,2×)

Methodische Details

Aufgabendefinition

Eingabe: Java-Anwendungsquellcode mit Sicherheitsannotationen Ausgabe: Partitionierte vertrauenswürdige und nicht vertrauenswürdige native Images, die in Intel SGX-Umgebungen bereitgestellt werden können Einschränkungen: Beibehaltung der ursprünglichen Anwendungssemantik, Gewährleistung von Objektkommunikation und GC-Konsistenz

Systemarchitektur

Der Workflow von Montsalvat umfasst 4 Hauptphasen:

1. Code-Annotationsphase

Bereitstellung von drei Annotationstypen:

• @Trusted: Klassen und ihre Instanzen werden immer innerhalb der Enklave erstellt und manipuliert
• @Untrusted: Klassen und ihre Instanzen werden immer außerhalb der Enklave manipuliert
• @Neutral: Utility-Klassen, die auf beiden Seiten unabhängig mehrere Kopien haben können

2. Bytecode-Transformationsphase

Verwendung des Javassist-Frameworks für Bytecode-Transformation:

Proxy-Klassengenerierung:

• Generierung von Proxy-Klassen für jede vertrauenswürdige Klasse in der nicht vertrauenswürdigen Laufzeit
• Generierung von Proxy-Klassen für jede nicht vertrauenswürdige Klasse in der vertrauenswürdigen Laufzeit
• Proxy-Klassen behalten ursprüngliche Methodensignaturen bei, aber Methodenkörper werden durch Aufrufe über Enklaven hinweg ersetzt

Relay-Methodeninjizierung:

// Ursprüngliche Methode in Relay-Methode umgewandelt
@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);
}

Objektmappingmechanismus:

• Zuweisung eines eindeutigen Hash-Werts für jedes Proxy-Objekt
• Verwaltung von Proxy-Mirror-Objektregistern
• Realisierung von Objektreferenzen über Enklaven hinweg durch Hash-Werte

3. Native Image-Partitionierung

Nutzung der statischen Analyse von GraalVM:

• Vertrauenswürdiges Image: Enthält konkrete Implementierungen vertrauenswürdiger Klassen + Proxys nicht vertrauenswürdiger Klassen
• Nicht vertrauenswürdiges Image: Enthält konkrete Implementierungen nicht vertrauenswürdiger Klassen + Proxys vertrauenswürdiger Klassen
• Points-to-Analyse beschneidet automatisch unerreichbaren Code

4. SGX-Anwendungsgenerierung

• Shim-Bibliothek: Leichte Bibliothek, die nicht unterstützte libc-Aufrufe abfängt und an die nicht vertrauenswürdige Laufzeit weiterleitet
• EDL-Generierung: Automatische Generierung von Enclave Definition Language-Dateien
• Endgültige Verknüpfung: Generierung der ausführbaren SGX-Anwendung

Technische Innovationspunkte

1. Partitionierungsstrategie auf Klassenebene

Im Vergleich zu Partitionierung auf Methoden- oder Datenebene:

• Besser geeignet für objektorientierte Programmierlogik
• Vermeidung komplexer Datenflussanalyse
• Natürliche Kapselungsgrenzen

2. Transparenter Proxy-Mechanismus

• Beibehaltung des ursprünglichen Programmiermodells
• Automatische Behandlung der Parameterserialisierung/-deserialisierung
• Unterstützung für komplexe Objektgraphen über Enklaven hinweg

3. Verteiltes GC-Design

// GC-Synchronisierung basierend auf schwachen Referenzen
WeakReference<ProxyObject> weakRef = new WeakReference<>(proxy);
proxyWeakRefs.add(new ProxyWeakRefEntry(weakRef, proxy.getHash()));

// GC Helper überprüft regelmäßig
if (weakRef.get() == null) {
    // Proxy-Objekt wurde GC, benachrichtige die andere Seite
    // über die Zerstörung des Mirror-Objekts
    notifyMirrorDestruction(hash);
}

Experimentelle Einrichtung

Experimentelle Umgebung

• Hardware: Intel Xeon E3-1270 CPU (3,80 GHz), 64 GB RAM
• SGX-Konfiguration: 128 MB EPC (93,5 MB verfügbar), maximale Heap 4 GB, Stack 8 MB
• Software: Ubuntu 18.04, SGX SDK v2.11, GraalVM CE v21.0.0
• Vergleichsbaseline: SCONE (JVM läuft in der Enklave)

Bewertungsmetriken

• Leistungsmetriken: Anwendungsausführungszeit, Operationsverzögerung
• Overhead-Analyse: Overhead bei der Erstellung von Proxy-Objekten, RMI-Aufruf-Overhead, GC-Leistung
• Beschleunigungsverhältnis: Leistungsverbesserung relativ zu nicht partitionierten und SCONE-Lösungen

Testanwendungen

1. Synthetische Benchmarks: CPU-intensive und I/O-intensive Operationen
2. PalDB: LinkedIns eingebetteter Schlüssel-Wert-Speicher
3. GraphChi: Framework zur Verarbeitung großer Graphen (PageRank-Algorithmus)
4. SPECjvm2008: Standard-Java-Mikro-Benchmark-Tests

Experimentelle Ergebnisse

Hauptleistungsergebnisse

1. Leistungsverbesserung echter Anwendungen

• PalDB: 6,6× Verbesserung gegenüber SCONE (RTWU-Schema), 2,8× (RUTW-Schema)
• GraphChi: 2,2× Verbesserung gegenüber SCONE
• SPECjvm2008: 5 von 6 Benchmark-Tests zeigen signifikante Verbesserungen (1,38×–2,66×)

2. Overhead-Analyse von Proxy-Objekten

• Erstellung von Proxy-Objekten ist 3–4 Größenordnungen langsamer als konkrete Objekte
• RMI-Aufrufe sind 3–4 Größenordnungen langsamer als lokale Aufrufe
• Serialisierung von Parametern erhöht den Overhead um das 10-fache (innerhalb der Enklave) bis zum 3-fachen (außerhalb der Enklave)

3. GC-Leistungsauswirkung

• GC innerhalb der Enklave ist eine Größenordnung langsamer als außerhalb der Enklave
• GC-Konsistenzvalidierung: Mirror-Objekte werden korrekt bereinigt, wenn Proxy-Objekte zerstört werden

Ablationsexperimente

Vergleich von Partitionierungsstrategien

Durch synthetische Benchmark-Tests mit unterschiedlichen Anteilen vertrauenswürdiger Klassen:

• CPU-intensive Operationen: Signifikante Leistungsverbesserung durch Verschiebung weiterer Klassen aus der Enklave
• I/O-intensive Operationen: Noch deutlichere Leistungsverbesserung durch Verschiebung von I/O-Operationen aus der Enklave

Nicht partitioniert vs. partitioniert vs. SCONE

In allen Tests ist die Leistungsreihenfolge:

1. Native Ausführung (ohne SGX) – am schnellsten, aber unsicher
2. Partitioniertes native Image – ausgewogene Leistung und Sicherheit
3. Nicht partitioniertes native Image – mittlere Leistung
4. SCONE+JVM – am langsamsten, aber beste Kompatibilität

Fallstudien

PalDB-Partitionierungsstrategie

@Trusted class DBReader   // Schutz sensibler Lesevorgänge
@Untrusted class DBWriter // Verschiebung von I/O-Schreibvorgängen aus der Enklave

Das RTWU-Schema bietet bessere Leistung, da teure Schreibvorgänge über Enklaven hinweg vermieden werden.

GraphChi-Partitionierungsstrategie

@Trusted class GraphChiEngine    // Schutz der Kernberechnungslogik
@Untrusted class FastSharder     // Verschiebung von Graph-Sharding-I/O-Operationen

Nach der Verschiebung von Sharding-Operationen aus der Enklave ist die Leistung nahe an der nativen Leistung.

Verwandte Arbeiten

Vollständige Enklave-Anwendungslösungen

• SCONE, Graphene-SGX, SGX-LKL: Bieten gute Kompatibilität, aber TCB ist zu groß
• Haven: Frühe Lösung für vollständige Anwendungen

Framework-spezifische Partitionierung

• VC3: Hadoop-Datenanalyse
• SecureKeeper: ZooKeeper-Erweiterung
• Opaque: Spark SQL-Plattform
• Einschränkung: Nur auf spezifische Frameworks anwendbar

Universelle Partitionierungslösungen

• Glamdring: Automatische Partitionierung für C/C++, nicht auf Java anwendbar
• Panoply: Mikro-Container-Lösung
• Civet: Java-Partitionierung, aber mit vollständigem LibOS
• Uranus: Annotation auf Methodenebene, erfordert Werkzeuge von Drittanbietern

Schlussfolgerung und Diskussion

Hauptschlussfolgerungen

1. Machbarkeitsprüfung: Annotationsbasierte Partitionierungslösung auf Klassenebene ist praktikabel und intuitiv
2. Leistungsvorteil: Partitionierte Anwendungen zeigen signifikante Leistungsverbesserungen gegenüber vollständigen Enklave-Lösungen
3. TCB-Reduktion: Durch Shim-Bibliothek statt LibOS wird die vertrauenswürdige Codebasis erheblich reduziert
4. Entwicklerfreundlichkeit: Annotationsmethode ist für Entwickler intuitiver

Einschränkungen

1. Kapselungsanforderung: Annahme, dass alle annotierten Klassen korrekt gekapselt sind (private Felder)
2. RMI-Overhead: Aufrufe über Enklaven hinweg haben immer noch erheblichen Overhead und sind nicht für häufige Interaktionen geeignet
3. GraalVM-Abhängigkeit: Beschränkung auf das GraalVM-Ökosystem
4. Einschränkungen der statischen Analyse: Begrenzte Unterstützung für bestimmte dynamische Funktionen

Zukünftige Richtungen

1. Aufrufe ohne Transformation: Untersuchung von Techniken zur Reduzierung teurer RMI-Aufrufe
2. Unterstützung mehrerer Isolates: Erweiterung auf Umgebungen mit mehreren Isolates
3. Automatische Partitionierung: Automatische Partitionierungsempfehlungen basierend auf statischer Analyse
4. Unterstützung anderer TEE: Erweiterung auf AMD SME, ARM TrustZone

Tiefgreifende Bewertung

Stärken

1. Starke Innovativität: Erste Lösung für Java-Anwendungspartitionierung auf Klassenebene mit intuitivem und vernünftigem Design
2. Technische Vollständigkeit: Vollständige Toolchain von Annotation bis zur endgültigen SGX-Anwendung
3. Ausgezeichnete Leistung: Zeigt signifikante Leistungsverbesserungen in echten Anwendungen
4. Hoher praktischer Wert: Löst praktische Probleme bei der sicheren Cloud-Bereitstellung von Java-Anwendungen

Schwächen

1. Immer noch erheblicher Overhead: RMI-Aufruf-Overhead von 3–4 Größenordnungen begrenzt anwendbare Szenarien
2. Strenge Annahmebedingungen: Anforderungen an Klassenkapselung können die Anwendbarkeit auf bestehenden Code einschränken
3. Unvollständige Bewertung: Mangel an Bewertung großer, langfristig laufender Anwendungen
4. Unzureichende Sicherheitsanalyse: Begrenzte Analyse des Schutzes vor fortgeschrittenen Bedrohungen wie Seitenkanalangriffen

Einflussfaktor

1. Akademischer Beitrag: Bietet neue Perspektiven für die Partitionierung verwalteter Sprachanwendungen in TEE-Umgebungen
2. Praktischer Wert: Kann direkt auf die Sicherheitsverstärkung von Java-Cloud-Anwendungen angewendet werden
3. Reproduzierbarkeit: Autoren versprechen Open-Source-Veröffentlichung, was Forschungsreproduzierung und Erweiterung erleichtert

Anwendungsszenarien

1. Cloud-Java-Dienste: Cloud-Anwendungen, die Geschäftslogik schützen müssen
2. Datenanalyseplattformen: Analysefameworks, die sensible Daten verarbeiten
3. Fintech-Anwendungen: Finanzdienste, die hohe Sicherheitsgarantien benötigen
4. IoT-Edge-Computing: Sichere Berechnung in ressourcenbeschränkten Umgebungen

Literaturverzeichnis

Das Paper zitiert 60 verwandte Arbeiten, die SGX-Technologie, TEE-Anwendungen, Java-Sicherheit, Kompilierungsoptimierung und andere wichtige Arbeiten in mehreren Bereichen abdecken und eine solide theoretische Grundlage für diese Forschung bieten.

Gesamtbewertung: Dies ist ein hochqualitatives Systemforschungspapier, das praktische Bereitstellungsprobleme von Java-Anwendungen in TEE-Umgebungen löst. Die Methodologie ist vernünftig gestaltet, die Implementierung ist vollständig, die Experimente sind umfassend und es hat großen akademischen Wert und praktische Bedeutung. Obwohl es noch Verbesserungspotenzial bei RMI-Overhead und Anwendbarkeit gibt, bietet es wichtige Referenzen für verwandte Forschung.