Trecem la Ziua 3 în care am învățat mai multe despre TEE-uri

Cu siguranță ar trebui să ne întrebăm constant, "Protocolul meu este sigur?" Dar, o întrebare mai bună este: "Protocolul meu este robust?"

Permiteți-mi să intru în detalii. Iată o imagine realistă a ceea ce am vrut cu adevărat să spun când am spus că povara verificării a fost mutată. Context: În protocoalele moderne SGX/TDX TEE, PROVER-UL trimite: + dovezi de atestare (citat/raport) + garanții de verificare necesare pentru validare SAU Protocoalele se bazează pe o terță parte și NU pe informații ca sursă de adevăr pentru garanțiile lor colaterale. Acum, faptul că provatorul însuși trimite materialele necesare pentru verificare (garanții) către verificator SAU o terță parte care furnizează artefacte critice pentru luarea deciziilor NU este atât de problematic pe cât pare la prima vedere. Dar va trebui să trecem prin noroi ca să facem bine. Lasă-mă să-ți spun de ce. Această alegere de design este, în mare parte, un compromis între practicitate și disponibilitate. Mulți verificatori NU vor să depindă de apeluri live de rețea Intel pentru fiecare strângere de mână. Corect. Deci, ce alegeri de design aleg de obicei oamenii: 1. Verificatorul preia direct de la Intel PCS pentru a extrage lanțul de certificare PCK, CRL-urile PCK, TCBInfo, QEIdentity etc. Bine: Prospețimea este proaspătă, riscul de rollback este neglijabil Rău: Verificatorul are nevoie de rețeaua de ieșire + probleme de disponibilitate/latență Intel 2. Preluarea verificatorului dintr-un cache de încredere (PCCS) Aici avem un serviciu de cache pentru certificate de aprovizionare care se sincronizează cu PCS Intel și este considerat sursa de adevăr pentru verificatori (în loc de Intel) Bine: Ceva prospețime, limită de încredere controlată, latență scăzută Rău: Securitatea în și în jurul PCCS 3. Prover furnizează materiale colaterale (flux de lucru destul de offline) Prover include garanții împreună cu oferta, iar verificatorul îl validează local. Bine: Verificatorul poate funcționa chiar și cu restricții extreme Rău: Rollback și stagnare din belșug. ------ Acum, ce tip de arhitectură ar trebui să aleagă un protocol? Depinde complet de garanțiile de securitate promise, de CÂT de IMPORTANTĂ este fiecare verificare corectă de atestare pentru clienții lor și de ce debit sunt de acord. ---- Să vorbim despre cel mai comun al doilea caz în care protocoalele se bazează pe PCCS în loc să vorbească cu Intel. 1. PCCS este de obicei administrat de cel care operează infrastructura pe partea de verificare. 2. Astfel, protocoalele care cer încredere minimă în terți își administrează propriile PCCS. 3. Totuși, un număr mare de echipe se bazează pe un endpoint PCCS oferit de platformele Cloud sau SGX gestionate. Acum, să depinzi de o terță parte pentru artefacte critice care determină dacă o atestare ar fi considerată validă sau nu, sună nebunesc. Dar există unele garanții criptografice în joc aici. 1. Un verificator rațional ar trebui să se închidă în caz de garanție lipsă, malformă sau oricum suspectă. Dacă lanțul de semnături nu poate fi construit. RESPINS. 2. Toate garanțiile importante sunt (sau ar trebui ideal să fie) autentificate criptografic. 3. Practic, dacă PCCS "schimbă intrările", NU POT falsifica semnături Intel. 4. Daunele pe care PCCS (care este un cache și nu ar trebui tratat ca o ancoră de încredere pentru integritate) este: + reține intrările + slujește intrări învechite, dar odată valide + intrări de tip garbake/malformat pentru servire ---- Dar să presupunem că aceste garanții NU sunt suficiente pentru tine și vrei să împingi spre cât mai multă lipsă de încredere în timp ce construiești un protocol TEE în industria noastră web3. Așadar, spui că nu ne vom baza pe o terță parte pentru PCCS-ul nostru și ne vom construi unul propriu. Acum să vedem cât de greu ar fi să faci asta "absolut corect". > Dacă verificatorul tău va obține materiale colaterale de la PCCS, atunci PCCS ar trebui să se comporte ca o poartă de prospețime și nu ca o oglindă proastă. Trebuie neapărat să te asiguri: + PCCS se sincronizează periodic de la Intel PCS + Refuză să ofere garanții expirate + Păstrează doar cea mai recentă versiune pentru FMSPC/TCBInfo/QEIdentity și nu va deservi versiunile mai vechi + Poate fixa un minim acceptabil "tcbEvaluationDataNumber" / "dată de emitere" pentru TCBInfo/QEIdentity. + Jurnale PCCS + alarme când nu se poate reîmprospăta la timp. + și alte lucruri bazate pe specificul protocolului tău Și dacă nu vrei să le implementezi în PCCS-ul tău, va trebui să implementezi aceste verificări în verificatorul local. Dar, din nou, apărarea în profunzime este regula jocului. --- Cea mai puternică mentalitate de securitate pe care ți-o pot lăsa în acest subiect este: > Tratează garanții furnizate de furnizor ca pe un indiciu, nu ca pe un adevăr. Ai încredere întotdeauna în validarea ta temeinică, mai mult decât în promisiunile care vin de la oricine. Lista ta de verificare pentru atenuarea aventurilor furnizorului tău de garanții ar trebui să includă: + Eșecul a fost închis pentru garanții lipsă/invalide + Verificarea semnăturilor/lanțurilor pentru toate obiectele de încredere + Impunerea prospețimii (timp, expirare și monotonicitate) + Stocarea în cache a celor mai noi regresii și respingerea regresiilor ------ Cu asta, vă mulțumesc și vă doresc tot ce e mai bun pentru aventurile voastre TEE. Și, dacă ai nevoie de ajutor legat de ancorele de încredere, politicile tale de protocol și cum să gestionezi TEE-urile pentru a construi un protocol robust, @bluethroat_labs fi bucuros să te ajut.