Laissez-moi entrer dans les détails ici. Voici une image réaliste de ce que je voulais vraiment dire quand j'ai dit que le **fardeau** de la vérification a été déplacé. Contexte : Dans les protocoles TEE modernes SGX/TDX, le PROVER envoie : + des preuves d'attestation (quote/report) + des éléments de vérification nécessaires pour les valider OU Les protocoles s'appuient sur un tiers et NON Intel comme source de vérité pour leurs éléments. Maintenant, le fait que le prouveur lui-même envoie les matériaux nécessaires à la vérification (éléments) au vérificateur OU qu'un tiers fournisse des artefacts critiques pour la prise de décision n'est PAS aussi problématique qu'il n'y paraît à première vue. Mais nous devrons traverser un peu de boue pour bien faire les choses. Laissez-moi vous dire pourquoi. Ce choix de conception est en grande partie un compromis entre praticité et disponibilité. De nombreux vérificateurs NE veulent PAS dépendre des appels réseau Intel en direct à chaque poignée de main. C'est juste. Alors, quels choix de conception les gens privilégient-ils généralement : 1. Le vérificateur récupère directement auprès d'Intel PCS pour obtenir la chaîne de certificats PCK, les CRL PCK, TCBInfo, QEIdentity, etc. Bien : Fraîcheur stonk, le risque de retour en arrière est négligeable Mauvais : Le vérificateur a besoin d'un réseau sortant + problèmes de disponibilité/latence d'Intel 2. Le vérificateur récupère à partir d'un cache de confiance (PCCS) Ici, nous avons un Service de Mise en Cache de Certificats de Provisionnement qui se synchronise avec Intel PCS et est considéré comme la source de vérité pour les vérificateurs (au lieu d'Intel)...