Lasciami entrare nei dettagli qui. Ecco un quadro realistico di ciò che intendevo davvero quando ho detto che il **carico** della verifica è stato spostato. Contesto: Nei moderni protocolli TEE SGX/TDX, il PROVER invia: + prove di attestazione (quote/report) + garanzie di verifica necessarie per convalidarla OPPURE I protocolli si basano su una terza parte e NON su Intel come fonte di verità per le loro garanzie. Ora, il fatto che il provatore stesso invii i materiali richiesti per la verifica (garanzie) al verificatore O che qualche terza parte fornisca artefatti critici per il processo decisionale NON è così problematico come sembra in superficie. Ma dovremo attraversare un po' di fango per farlo bene. Lasciami spiegarti perché. Questa scelta di design è in gran parte un compromesso tra praticità e disponibilità. Molti verificatori NON vogliono dipendere da chiamate di rete Intel in tempo reale ad ogni handshake. Giusto. Quindi, quali scelte di design le persone tendono a considerare: 1. Il verificatore recupera direttamente da Intel PCS per estrarre la catena di certificati PCK, le CRL PCK, TCBInfo, QEIdentity, ecc. Buono: Freschezza stonk, il rischio di rollback è trascurabile Cattivo: Il verificatore ha bisogno di una rete in uscita + problemi di disponibilità/latenza di Intel 2. Il verificatore recupera da una cache fidata (PCCS) Qui abbiamo un Servizio di Cache di Certificati di Provisioning che si sincronizza con Intel PCS ed è considerato la fonte di verità per i verificatori (anziché Intel)...