Przechodzimy do Dnia 3 nauki więcej o TEE.

Zdecydowanie powinniśmy ciągle zadawać pytanie, "Czy mój protokół jest bezpieczny?" Ale lepsze pytanie to: "Czy mój protokół jest solidny?"

Pozwól, że wejdę w szczegóły. Oto realistyczny obraz tego, co naprawdę miałem na myśli, gdy powiedziałem, że **ciężar** weryfikacji został przeniesiony. Kontekst: W nowoczesnych protokołach SGX/TDX TEE, PROWER wysyła: + dowody atestacji (cytat/raport) + materiały weryfikacyjne potrzebne do ich walidacji LUB Protokoły polegają na 3. stronie, a NIE na Intel jako źródle prawdy dla swoich materiałów. Teraz, sam prover wysyłający materiały wymagane do weryfikacji (materiały) do weryfikatora LUB jakaś 3. strona dostarczająca krytyczne artefakty decyzyjne NIE jest tak problematyczna, jak się wydaje na pierwszy rzut oka. Ale będziemy musieli przejść przez trochę błota, aby to dobrze zrozumieć. Pozwól, że ci powiem dlaczego. Ten wybór projektowy jest w dużej mierze kompromisem między praktycznością a dostępnością. Wiele weryfikatorów NIE chce polegać na żywych połączeniach sieciowych Intel przy każdym uścisku dłoni. Sprawiedliwe. Jakie wybory projektowe ludzie zazwyczaj koncentrują się na: 1. Weryfikator pobiera bezpośrednio z Intel PCS, aby pobrać łańcuch certyfikatów PCK, CRL PCK, TCBInfo, QEIdentity itp. Dobre: Świeżość, ryzyko wycofania jest znikome Złe: Weryfikator potrzebuje połączenia sieciowego + problemy z dostępnością/latencją Intel 2. Weryfikator pobiera z zaufanej pamięci podręcznej (PCCS) Tutaj mamy Usługę Pamięci Podręcznej Certyfikatów Provisioning, która synchronizuje się z Intel PCS i jest uważana za źródło prawdy dla weryfikatorów (zamiast Intel) Dobre: Pewna świeżość, kontrolowana granica zaufania, niska latencja Złe: Bezpieczeństwo w i wokół PCCS 3. Prover dostarcza materiały (praca offline-ish) Prover łączy materiały z cytatem, a weryfikator waliduje je lokalnie. Dobre: Weryfikator może działać nawet przy ekstremalnych ograniczeniach Złe: Wiele problemów z wycofaniem i przestarzałymi danymi. ------ Jakiego rodzaju architekturę powinien wybrać protokół? Całkowicie zależy od tego, jakie są ich obiecane gwarancje bezpieczeństwa, JAK WAŻNE jest każde poprawne sprawdzenie atestacji dla ich klientów oraz z jakim przepustowością są w porządku. ---- Porozmawiajmy o najczęstszej 2. sytuacji protokołów polegających na PCCS zamiast rozmawiać z Intelem. 1. PCCS jest zazwyczaj uruchamiane przez kogoś, kto obsługuje infrastrukturę po stronie weryfikatora. 2. Tak więc protokoły, które chcą minimalnego zaufania do stron trzecich, uruchamiają własne PCCS. 3. Jednak wiele zespołów polega na punkcie końcowym PCCS dostarczonym przez platformy SGX w chmurze lub zarządzane. Teraz, poleganie na 3. stronie dla krytycznych artefaktów, które decydują o tym, czy atestacja będzie uznana za ważną, brzmi szalenie. Ale są tu pewne gwarancje kryptograficzne. 1. Rozsądny weryfikator powinien zamknąć się na brakujące, źle sformułowane lub w jakikolwiek sposób podejrzane materiały. Jeśli łańcuch podpisów nie może być zbudowany. ODRZUĆ. 2. Wszystkie ważne materiały są (lub powinny być) kryptograficznie uwierzytelnione. 3. W zasadzie, jeśli PCCS "zmienia wpisy", NIE MOŻE fałszować podpisów Intel. 4. Szkody, jakie PCCS (które jest pamięcią podręczną i nie powinno być traktowane jako punkt zaufania dla integralności) może wyrządzić, to: + wstrzymywanie wpisów + serwowanie przestarzałych, ale kiedyś ważnych wpisów + serwowanie śmieci/źle sformułowanych wpisów ---- Ale powiedzmy, że te gwarancje NIE są dla ciebie wystarczające i chcesz dążyć do jak największej bezstronności podczas budowania protokołu TEE w naszej dobrej, starej branży web3. Więc mówisz, że nie będziemy polegać na 3. stronie dla naszego PCCS i zbudujemy własne. Teraz zobaczmy, jak trudne byłoby to, aby "absolutnie dobrze" to zrobić. > Jeśli twój weryfikator ma pobierać materiały z PCCS, to PCCS powinno działać jak brama świeżości, a nie jak głupie lustro. Musisz zapewnić: + PCCS okresowo synchronizuje się z Intel PCS + Odrzuca materiały, które są przestarzałe + Przechowuje tylko najnowszą wersję dla FMSPC/TCBInfo/QEIdentity i nie będzie serwować starszych wersji + Może ustawić minimalną akceptowalną `tcbEvaluationDataNumber` / „datę wydania” dla TCBInfo/QEIdentity. + PCCS rejestruje i alarmuje, gdy nie może odświeżyć na czas. + i inne rzeczy w zależności od specyfiki twojego protokołu A jeśli nie chcesz ich wdrażać w swoim PCCS, musisz wdrożyć te kontrole lokalnie w swoim weryfikatorze. Ale znowu, obrona w głębokości to klucz do sukcesu. --- Najsilniejsze podejście do bezpieczeństwa, jakie mogę ci zostawić w tym temacie, to: > Traktuj materiały dostarczane przez prover jako wskazówkę, a nie prawdę. Zawsze ufaj swojej własnej, dokładnej walidacji ponad jakiekolwiek obietnice przychodzące od kogokolwiek. Twoja lista kontrolna łagodzenia ryzyka dla niepowodzeń dostawcy materiałów powinna obejmować: + Zamknięcie na brakujące/nieprawidłowe materiały + Weryfikacja podpisów/łańcuchów dla wszystkich obiektów zaufania + Egzekwowanie świeżości (czas, wygaśnięcie i monotoniczność) + Pamiętanie o najnowszych widzianych i odrzucanie regresji ------ Z tym wszystkim, dziękuję i życzę powodzenia w twoich przygodach z TEE. A jeśli potrzebujesz pomocy w kwestii punktów zaufania, polityki twojego protokołu i jak radzić sobie z TEE, @bluethroat_labs chętnie ci pomoże.