İçeriğe geç
Bağımsız Doğrulama

Bu neden özel?

0G, Private Compute istemlerinizi neden okuyamaz ve siz bunu kendiniz nasıl doğrulayabilirsiniz?

Bu, kısa versiyon. Prosedür: verifying-the-gateway.md; tasarım ise şurada: design/.

Kısa cevap

Düz metin TEE belleğinde kalır

TLS, ağ geçidi TEE'si içinde sonlanır. Her istek, sağlayıcı güvenli bölgesinin anahtarına mühürlenir; bu nedenle Yönlendirme yalnızca şifreli metni taşır ve anahtarı asla elinde bulundurmaz.

Operatör, güvenli bölge belleğini okuyamaz

Anahtarlar güvenli bölge belleğinde oluşturulur ve saklanır. Ne bulut sunucusu ne de 0G operatörleri anahtarları, istemleri veya şifresi çözülmüş yanıtları inceleyebilir.

Her iki TEE de doğrulanabilir

Ağ geçidi ve sağlayıcı TEE'leri, donanım imzalı ölçümler ve sürüm derlemeleri yayımlar; böylece herkes tam olarak hangi kodun çalıştığını doğrulayabilir.

İsteminiz nereye gider?

Yönlendirme her isteği iletir ve faturalandırır, ancak mühürlü gövdeyi açmak için gereken anahtarı asla almaz.

Şifreli metin · TLS

Tarayıcınız

Ağ geçidi TEE'si içinde sonlanan standart bir HTTPS oturumu.

Düz metin · bellek

Ağ Geçidi TEE'si

İstek, doğrulanmış sağlayıcı güvenli bölgesinin anahtarına mühürlenir.

Şifreli metin · HPKE

0G Yönlendirme

Mühürlü gövdeyi içeriğini görmeden iletir ve şifre çözme anahtarını asla elinde bulundurmaz.

Düz metin · bellek

Sağlayıcı TEE'si

Model, isteğin şifresini çözen aynı doğrulanmış güvenli bölge içinde çalışır.

Şifreli metin · imzalı

Yanıt

Yönlendirmenin taklit edemeyeceği bir güvenli bölge imzasıyla mühürlü olarak geri döner.

Yanıttan sonra ağ geçidi, sağlayıcının imzasını istem içeriği olmaksızın getirir. İstemler asla günlüklerde, yedeklerde veya diskte saklanmaz.

“TEE içinde” ifadesi neden doğrulanabilir?

TLS anahtarı içeride üretilir

Giriş bileşeni, özel anahtarını gizli VM'in içinde üretir ve sunulan sertifikayı bir Intel TDX kanıtlama özetine bağlar. Bunların eşleşmesi, TLS'in enklav içinde sonlandığını kanıtlar.

Intel, çalışan derlemenin özetini imzalar

Kanıtlama özeti, her konteyneri özetine göre sabitleyen dağıtım bildirimine bağlanır. Herhangi bir kod değişikliği, herkesin yayınlanmış bir sürümle karşılaştırabileceği farklı, donanım imzalı bir ölçüm üretir.

Önce sağlayıcı doğrulanır

Ağ geçidi, sağlayıcı kanıtlama özetini DCAP ile doğrular ve şifreleme anahtarını bu doğrulanmış kanıttan okur; asla yönlendirme katmanından okumaz. Doğrulanmamış sağlayıcılar ve imzasız yanıtlar reddedilir.

Kendiniz doğrulayın

Doğrulayıcıyı derleyin ve bir ağ geçidi alan adına karşı tek bir komut çalıştırın. Bu komut; Intel'in kanıtlama özetini, bağlantınıza sunulan sertifikayı, kod özetini ve kodun yayınlanmış sürümünü doğrular.

$cd 0g-pc-e2ee/client && go build -o pcverify ./cmd/pcverify
$./pcverify -gateway <gateway-domain>

Hâlâ görebildiklerimiz

Mesaj gövdesini şifrelemek, çevresindeki tüm meta verileri gizlemez. Yönlendirme katmanı bu alanları okuyabilir ve ücretlendirebilir; ancak enklav imzası, yönlendirme katmanının bunları değiştirmesini engeller.

  • İstediğiniz model, çünkü yönlendirme katmanının onu yönlendirmesi gerekir.
  • Tam token kullanımınız, çünkü yönlendirme katmanı buna göre ücretlendirir.
  • Mesaj boyutları; şifreli metnin uzunluğu, düz metin uzunluğu artı bir sabittir.
  • İstek ve yanıt zamanlaması; akışla gelen parçaların zamanlaması dahil.

Bunun kanıtlamadığı şeyler

  • Tespit, önleme değil. Dürüst olmayan bir dağıtım, ancak biri doğrulamayı çalıştırdığında herkesçe tespit edilebilir hâle gelir.
  • Başarılı bir doğrulama, yalnızca kontrol edilen bağlantıyı kapsar; aynı alan adı altındaki her enklavı otomatik olarak kapsamaz.
  • Bu, doğrulanabilir bir aktarım; doğrulanabilir hesaplama değil. Hangi enklavın bir yanıt ürettiğini kanıtlar; modelin kalitesini veya davranışını değil.
  • Kullanılabilirlik kanıtlanmaz; bir dağıtım yine de çevrimdışına alınabilir.
  • Barındırılan ağ geçidi, düz metni gören ikinci bir enklav ekler. İstemci tarafı mühürleme, henüz desteklenen bir giriş noktası değildir.

Daha derinlemesine