Proyek mengklaim modelnya berjalan di dalam TEE: sampai mana attestation bisa diperiksa

Apa yang sebenarnya ikut ditandatangani

Di halaman penjelasan layanan attestation SGX miliknya, Intel memisahkan dua hal. Yang pertama, bagian yang membuat pihak pengandal lebih yakin: programnya memang berjalan di dalam enclave SGX, dan mesin itu sudah diperbarui ke tingkat keamanan terbaru — yakni versi trusted computing base, TCB, lapisan kepercayaan yang berada di chip dan microcode. Yang kedua, tiga hal yang disediakan hasil attestation itu sendiri: identitas software yang diattestasi, detail status yang tidak ikut diukur seperti mode eksekusinya, dan penilaian apakah software-nya sempat diutak-atik. Dua daftar tadi sama-sama berhenti di lapisan lingkungan.

Artinya pertanyaan yang dijawab dokumen tersebut adalah “versi mana yang dimuat di mesin ini”, bukan “apakah yang dimuat itu mengerjakan hal yang benar”. Sebuah shell tipis yang kerjanya cuma meneruskan prompt pengguna apa adanya ke API pihak ketiga tetap bisa memegang attestation yang lolos, asalkan shell itu sendiri dimuat utuh.

Ada satu detail yang pantas dibuka sendiri: dokumennya sekalian memperlihatkan mesin itu berhenti di tingkat keamanan yang mana. Kalau yang diserahkan proyek menunjukkan TCB-nya sudah kedaluwarsa, dokumen itu tetap asli — hanya saja tingkat yang dijamin di dalamnya lebih rendah daripada yang terdengar waktu dipromosikan.

Membuat, memverifikasi, dan mempercayai: tiga peran berbeda

RFC 9334 dari IETF, arsitektur prosedur remote attestation, menulis pembagian perannya terpisah: Attester menghasilkan Evidence, Verifier menilai Evidence itu lalu mengeluarkan Attestation Results, dan baru Relying Party yang memakai hasil tersebut untuk memutuskan percaya atau tidak. Standarnya memisahkan ketiganya karena hasil penilaian hanya punya bobot ketika yang menilai bukan orang yang sama dengan yang dinilai.

Kembali ke sisi proyek, yang akan Anda temui kira-kira ada tiga bentuk, dan kedalaman yang bisa diperiksa dari masing-masingnya berbeda jauh:

• Tertulis di dokumentasi atau utas media sosial bahwa “kami berjalan di dalam TEE”, tanpa dokumen apa pun yang dilampirkan — ini keterangan sendiri, cukup masuk ke kolom “klaim tim” di tabel bukti.
• Diberi tangkapan layar sebuah laporan attestation — isinya milik satu titik waktu, Anda tidak bisa memverifikasinya ulang, dan tidak terlihat apakah deployment-nya sudah berganti sesudah itu.
• Diberi jalur verifikasi yang terbuka: dokumennya diambil di mana, dijalankan dengan verifier yang mana, bahkan setiap keluaran disertai tanda tangan — bentuk inilah yang mendekati arti harfiah kalimat promosinya.

Bentuk kedua dan ketiga sering memakai kata yang sama persis di naskah pemasaran. Ketika mengubah klaim promosi menjadi pengujian yang bisa diamati, meminta jalur verifikasi itu adalah langkah yang paling murah; kalau tidak diberikan, baris ini berhenti di situ.

Dokumen sisi CPU tidak menutupi GPU

Inferensi model besar umumnya berjalan di GPU, sementara attestation sebuah enclave CPU hanya mencakup sisi CPU. GPU berjalan di jalur lain: NVIDIA mengemas attestation untuk komputasi konfidensialnya sebagai rangkaian layanan tersendiri, dan dokumentasi resminya menyebut layanan remote attestation (NRAS), layanan reference integrity manifest (RIM), serta layanan OCSP, yang dipakai untuk memeriksa keaslian dan integritas perangkat keras maupun perangkat lunak NVIDIA secara kriptografis.

Jadi yang benar-benar perlu ditanyakan adalah cakupannya: komponen mana yang berada di dalam lingkungan terlindungi, bobot modelnya dimuat di mana, kunci privat untuk menandatangani ikut berada di lingkungan yang sama atau tidak, dan GPU-nya diattestasi sekalian atau tidak. Tanpa potongan GPU, kalimat “modelnya berjalan di lingkungan terlindungi” bisa jadi hanya mencakup penjadwalan dan pra-pemrosesan.

Satu mata rantai lagi yang kerap dilewati: nilai pengukuran itu sendiri cuma sebaris hash. Ia baru berubah menjadi bukti kalau bisa dicocokkan kembali ke image atau instruksi build yang publik dan dapat dibangun ulang. Ketika pencocokan itu gagal, yang Anda pegang hanya sebaris angka — persoalan yang sebetulnya satu urusan dengan rantai bukti kode dan versi deployment.

Tiga hal yang bisa diminta ke proyeknya

Berdebat soal aman atau tidaknya perangkat keras tidak perlu. Minta tiga hal ini saja; kalau tidak bisa diberikan, itu sudah menjadi kesimpulan tersendiri.

1. Jalur attestation yang bisa diverifikasi ulang secara terbuka: dokumennya berbentuk apa, diambil di mana, dijalankan dengan verifier yang mana.
2. Build yang bersesuaian dengan nilai pengukurannya: image yang mana, versi berapa, dan bagaimana hash yang sama dibangun ulang.
3. Satu pernyataan cakupan: komponen apa saja yang berada di dalam lingkungan terlindungi, GPU masuk hitungan atau tidak, dan kunci privat wallet-nya disimpan di mana.

Kurang satu dari tiga, klaim ini turun satu tingkat di tabel bukti. Tidak satu pun bisa didapat, catatan yang lebih jujur adalah memasukkannya ke materi pemasaran, bukan ke sifat keamanan. Pemeriksa bukti dan klaim AI bisa dipakai untuk menderetkan baris ini bersama klaim-klaim lainnya.

Satu hal lagi yang perlu ditegaskan: sekalipun ketiganya lengkap, dokumen attestation tetap tidak menjawab siapa yang bisa mengubah atau menghentikan Agent itu. Wewenang upgrade, penyimpanan kunci, dan daftar penanda tangan multisig berjalan di garis yang sama sekali lain.

Buku kerja verifikasi

Dua kartu di bawah menyasar dua titik yang paling mudah dikaburkan di berkas ini: apakah dokumennya bisa diverifikasi ulang dari sisi Anda, dan apakah cakupannya sudah dituliskan. Simpan hasil putusannya bersama materinya.