Montsalvat : Partitionnement des Applications Java pour Minimiser la TCB dans Intel SGX

Informations Fondamentales

• ID de l'article : 2305.00766
• Titre : Montsalvat: Partitioning Java Applications to Minimize the TCB in Intel SGX
• Auteurs : Peterson Yuhala, Jämes Ménétrey, Pascal Felber, Valerio Schiavoni, Alain Tchana, Gaël Thomas, Hugo Guiroux, Jean-Pierre Lozi
• Classification : cs.CR (Cryptographie et Sécurité)
• Conférence de publication : 22e Conférence Internationale Middleware (Middleware 2021)
• Lien de l'article : https://arxiv.org/abs/2305.00766

Résumé

La popularité du langage de programmation Java a conduit à son adoption généralisée dans les infrastructures informatiques en nuage. Cependant, les applications Java exécutées dans des environnements nuagiques non fiables sont vulnérables à diverses attaques privilégiées. L'émergence d'environnements d'exécution de confiance (TEE) tels qu'Intel SGX atténue ce problème. Les TEE protègent le code et les données dans des enclaves sécurisées, les rendant inaccessibles aux logiciels non fiables, y compris le noyau et l'hyperviseur. Pour utiliser efficacement les TEE, les développeurs doivent partitionner manuellement les applications en parties fiables et non fiables afin de réduire la taille de la base de calcul de confiance (TCB) et de minimiser les risques de vulnérabilité de sécurité. Cet article propose l'outil Montsalvat, qui fournit une méthode de partitionnement pratique et intuitive basée sur les annotations pour les applications Java orientées vers les enclaves sécurisées. Montsalvat fournit un mécanisme similaire à RMI pour assurer la communication entre objets, ainsi qu'une collecte des ordures cohérente entre les composants partitionnés.

Contexte de Recherche et Motivation

Définition du Problème

1. Menaces de sécurité : Les applications Java dans les environnements nuagiques non fiables font face à des menaces d'attaques privilégiées, y compris les attaques au niveau du noyau et de l'hyperviseur
2. Exigence de minimisation de la TCB : Lors de l'utilisation de TEE tels qu'Intel SGX, il est nécessaire de minimiser la base de calcul de confiance pour réduire la surface d'attaque
3. Complexité du partitionnement : Le partitionnement manuel des applications Java nécessite de traiter des problèmes complexes tels que la communication entre objets et la cohérence de la collecte des ordures

Limitations des Solutions Existantes

1. Solutions d'application complète : SCONE, Graphene-SGX, etc. placent l'application entière (y compris la JVM) dans l'enclave, avec une TCB trop importante (millions de lignes de code)
2. Solutions spécifiques aux frameworks : VC3, SecureKeeper, etc. ne ciblent que des frameworks spécifiques, manquant de généralité
3. Solutions de partitionnement Java existantes :
   • Civet nécessite un LibOS complet, la TCB reste importante
   • Uranus nécessite des outils tiers pour déduire les partitions fiables, avec une intervention importante des développeurs

Motivation de la Recherche

Développer un outil de partitionnement Java générique et automatisé capable de :

• Fournir une méthode d'annotation intuitive au niveau des classes
• Implémenter une communication efficace d'objets entre enclaves
• Assurer la cohérence de la collecte des ordures distribuée
• Réduire significativement la taille de la TCB

Contributions Fondamentales

1. Méthode de partitionnement basée sur les annotations : Propose une approche pratique et intuitive d'annotation au niveau des classes (@Trusted, @Untrusted, @Neutral) pour partitionner les applications Java
2. Mécanisme RMI : Conçoit un mécanisme de communication d'objets entre enclaves similaire à RMI, implémentant des appels de méthodes distantes transparents via des objets proxy
3. Collecte des ordures distribuée : Implémente une extension GC basée sur les références faibles, assurant la cohérence de destruction d'objets entre les tas fiables et non fiables
4. Intégration GraalVM : Intégration profonde avec GraalVM native-image, exploitant la compilation AOT pour optimiser les performances
5. Amélioration des performances : Réalise des améliorations significatives des performances dans les applications réelles (PalDB 6.6×, GraphChi 2.2×)

Détails de la Méthode

Définition de la Tâche

Entrée : Code source d'application Java annoté avec des annotations de sécurité Sortie : Native images partitionnées fiables et non fiables, déployables dans l'environnement Intel SGX Contraintes : Préserver la sémantique d'application d'origine, assurer la cohérence de la communication d'objets et de la GC

Architecture du Système

Le flux de travail de Montsalvat comprend 4 phases principales :

1. Phase d'Annotation du Code

Fournit trois types d'annotations :

• @Trusted : Les classes et leurs instances sont toujours créées et manipulées dans l'enclave
• @Untrusted : Les classes et leurs instances sont toujours manipulées en dehors de l'enclave
• @Neutral : Classes utilitaires, peuvent exister indépendamment en plusieurs copies des deux côtés

2. Phase de Transformation du Bytecode

Utilise le framework Javassist pour la transformation du bytecode :

Génération de classes proxy :

• Génère des classes proxy pour chaque classe fiable dans l'exécution non fiable
• Génère des classes proxy pour chaque classe non fiable dans l'exécution fiable
• Les classes proxy conservent les signatures de méthode d'origine, mais les corps de méthode sont remplacés par des appels entre enclaves

Injection de méthodes relais :

// Transformation de la méthode d'origine en méthode relais
@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);
}

Mécanisme de mappage d'objets :

• Chaque objet proxy se voit attribuer une valeur de hachage unique
• Maintient des registres de paires proxy-miroir
• Implémente les références d'objets entre enclaves via les valeurs de hachage

3. Partitionnement de Native Image

Exploite l'analyse statique de GraalVM :

• Image fiable : contient les implémentations concrètes des classes fiables + proxies des classes non fiables
• Image non fiable : contient les implémentations concrètes des classes non fiables + proxies des classes fiables
• L'analyse de points élaguer automatiquement le code inaccessible

4. Génération d'Application SGX

• Bibliothèque Shim : Bibliothèque légère qui intercepte les appels libc non supportés et les relaye à l'exécution non fiable
• Génération EDL : Génère automatiquement les fichiers de langage de définition d'enclave
• Liaison finale : Génère l'application SGX exécutable

Points d'Innovation Technique

1. Stratégie de Partitionnement au Niveau des Classes

Par rapport au partitionnement au niveau des méthodes ou des données :

• Plus conforme à l'intuition de la programmation orientée objet
• Évite l'analyse complexe du flux de données
• Frontières d'encapsulation naturelles

2. Mécanisme de Proxy Transparent

• Préserve le modèle de programmation d'origine
• Gère automatiquement la sérialisation/désérialisation des paramètres
• Supporte le passage de graphes d'objets complexes entre enclaves

3. Conception de la GC Distribuée

// Synchronisation GC basée sur les références faibles
WeakReference<ProxyObject> weakRef = new WeakReference<>(proxy);
proxyWeakRefs.add(new ProxyWeakRefEntry(weakRef, proxy.getHash()));

// Helper GC vérifie périodiquement
if (weakRef.get() == null) {
    // L'objet proxy a été collecté, notifie l'autre côté
    // de détruire l'objet miroir
    notifyMirrorDestruction(hash);
}

Configuration Expérimentale

Environnement Expérimental

• Matériel : Processeur Intel Xeon E3-1270 (3,80 GHz), RAM 64 Go
• Configuration SGX : EPC 128 Mo (93,5 Mo disponibles), tas maximum 4 Go, pile 8 Mo
• Logiciel : Ubuntu 18.04, SGX SDK v2.11, GraalVM CE v21.0.0
• Lignes de base de comparaison : SCONE (JVM dans l'enclave)

Indicateurs d'Évaluation

• Indicateurs de performance : Temps d'exécution de l'application, latence des opérations
• Analyse des frais généraux : Frais généraux de création d'objets proxy, frais généraux d'appels RMI, performances de la GC
• Ratio d'accélération : Amélioration des performances par rapport aux schémas non partitionnés et SCONE

Applications de Test

1. Benchmarks synthétiques : Opérations intensives en CPU et en I/O
2. PalDB : Magasin clé-valeur embarqué de LinkedIn
3. GraphChi : Framework de traitement de graphes à grande échelle (algorithme PageRank)
4. SPECjvm2008 : Tests de microbenchmark Java standard

Résultats Expérimentaux

Résultats Principaux de Performance

1. Amélioration des Performances des Applications Réelles

• PalDB : Amélioration de 6,6× par rapport à SCONE (schéma RTWU), 2,8× (schéma RUTW)
• GraphChi : Amélioration de 2,2× par rapport à SCONE
• SPECjvm2008 : Amélioration significative dans 5/6 benchmarks (1,38×-2,66×)

2. Analyse des Frais Généraux des Objets Proxy

• La création d'objets proxy est 3-4 ordres de grandeur plus lente que les objets concrets
• Les appels RMI sont 3-4 ordres de grandeur plus lents que les appels locaux
• La sérialisation des paramètres augmente les frais généraux de 10× (dans l'enclave) à 3× (en dehors de l'enclave)

3. Impact de la Performance de la GC

• La GC dans l'enclave est 1 ordre de grandeur plus lente qu'en dehors de l'enclave
• Vérification de la cohérence GC : les objets miroir sont correctement nettoyés lors de la destruction des objets proxy

Expériences d'Ablation

Comparaison des Stratégies de Partitionnement

Via des benchmarks synthétiques testant différents pourcentages de classes fiables :

• Intensif en CPU : Déplacer plus de classes en dehors de l'enclave améliore significativement les performances
• Intensif en I/O : Déplacer les opérations I/O en dehors de l'enclave améliore davantage les performances

Non partitionné vs Partitionné vs SCONE

Dans tous les tests, le classement des performances est :

1. Exécution native (sans SGX) - Plus rapide mais non sécurisé
2. Native image partitionné - Équilibre performance et sécurité
3. Native image non partitionné - Performance moyenne
4. SCONE+JVM - Plus lent mais meilleure compatibilité

Études de Cas

Stratégie de Partitionnement de PalDB

@Trusted class DBReader   // Protège les opérations de lecture sensibles
@Untrusted class DBWriter // Déplace les opérations d'écriture I/O en dehors de l'enclave

Le schéma RTWU offre de meilleures performances car il évite les conversions d'enclave coûteuses pour les écritures.

Stratégie de Partitionnement de GraphChi

@Trusted class GraphChiEngine    // Protège la logique de calcul principal
@Untrusted class FastSharder     // Déplace les opérations I/O de partitionnement de graphe

Après le déplacement des opérations de partitionnement en dehors de l'enclave, les performances se rapprochent de celles natives.

Travaux Connexes

Solutions d'Enclave d'Application Complète

• SCONE, Graphene-SGX, SGX-LKL : Offrent une bonne compatibilité mais TCB trop importante
• Haven : Solution d'application complète précoce

Partitionnement Spécifique aux Frameworks

• VC3 : Analyse de données Hadoop
• SecureKeeper : Extension ZooKeeper
• Opaque : Plateforme Spark SQL
• Limitations : Applicables uniquement à des frameworks spécifiques

Solutions de Partitionnement Générique

• Glamdring : Partitionnement automatique C/C++, non applicable à Java
• Panoply : Approche de micro-conteneurs
• Civet : Partitionnement Java mais utilise un LibOS complet
• Uranus : Annotations au niveau des méthodes, nécessite des outils tiers

Conclusion et Discussion

Conclusions Principales

1. Vérification de la faisabilité : L'approche de partitionnement au niveau des classes basée sur les annotations est faisable et intuitive
2. Avantages de performance : Les applications partitionnées offrent des améliorations significatives de performance par rapport aux solutions d'enclave complète
3. Réduction de la TCB : Réduit considérablement la base de code fiable via une bibliothèque shim plutôt qu'un LibOS
4. Convivialité pour les développeurs : L'approche par annotations est plus intuitive pour les développeurs

Limitations

1. Exigences d'encapsulation : Suppose que toutes les classes annotées sont correctement encapsulées (champs privés)
2. Frais généraux RMI : Les appels entre enclaves ont toujours des frais généraux significatifs, inadaptés aux scénarios d'interaction fréquente
3. Dépendance GraalVM : Limité à l'écosystème GraalVM
4. Limitations de l'analyse statique : Support limité pour certaines caractéristiques dynamiques

Directions Futures

1. Appels sans conversion : Rechercher des techniques pour réduire les coûteux appels RMI
2. Support multi-isolate : Étendre à des environnements multi-isolate
3. Partitionnement automatique : Recommandations de partitionnement automatique basées sur l'analyse statique
4. Support d'autres TEE : Étendre à AMD SME, ARM TrustZone

Évaluation Approfondie

Avantages

1. Innovation forte : Première approche de partitionnement d'applications Java au niveau des classes, conception intuitive et raisonnable
2. Complétude de l'ingénierie : Chaîne d'outils complète des annotations à l'application SGX finale
3. Performance excellente : Démontre des améliorations significatives de performance dans les applications réelles
4. Valeur pratique élevée : Résout les problèmes pratiques du déploiement sécurisé d'applications Java en nuage

Insuffisances

1. Frais généraux toujours importants : Les frais généraux d'appels RMI restent de 3-4 ordres de grandeur, limitant les scénarios d'application
2. Conditions d'hypothèse strictes : Les exigences d'encapsulation des classes peuvent limiter l'applicabilité du code existant
3. Évaluation incomplète : Manque d'évaluation d'applications à grande échelle et d'exécution à long terme
4. Analyse de sécurité insuffisante : Analyse limitée de la protection contre les attaques par canaux auxiliaires et autres menaces avancées

Impact

1. Contribution académique : Fournit une nouvelle perspective pour le partitionnement d'applications de langages gérés dans les environnements TEE
2. Valeur pratique : Peut être directement appliqué au renforcement de la sécurité des applications Java en nuage
3. Reproductibilité : Les auteurs s'engagent à l'open-source, facilitant la reproduction et l'extension de la recherche

Scénarios d'Application

1. Services Java en nuage : Applications en nuage nécessitant la protection de la logique métier sensible
2. Plateformes d'analyse de données : Frameworks d'analyse traitant des données sensibles
3. Applications de technologie financière : Services financiers nécessitant des garanties de sécurité élevées
4. Informatique en périphérie IoT : Calcul sécurisé dans les environnements aux ressources limitées

Références

L'article cite 60 articles connexes, couvrant plusieurs domaines tels que la technologie SGX, les applications TEE, la sécurité Java et l'optimisation de compilation, fournissant une base théorique solide pour cette recherche.

Évaluation globale : Cet article est une recherche système de haute qualité qui résout les problèmes pratiques du déploiement d'applications Java dans les environnements TEE. La conception de la méthode est raisonnable, l'implémentation est complète, les expériences sont suffisantes, et elle possède une excellente valeur académique et pratique. Bien qu'il y ait encore de la place pour l'amélioration en termes de frais généraux RMI et d'applicabilité, elle fournit une référence importante pour la recherche connexe.