Sejak Apple mengumumkan peluncuran awan pribadi dan NVIDIA menyediakan komputasi rahasia dalam GPU, lingkungan eksekusi tepercaya (TEE) telah menjadi semakin populer. Jaminan kerahasiaan mereka membantu melindungi data pengguna (termasuk kunci pribadi), sementara isolasi memastikan bahwa eksekusi program yang ditempatkan di atasnya tidak dapat dimanipulasi - baik oleh manusia, program lain, atau sistem operasi. Oleh karena itu, tidak mengherankan bahwa banyak produk di bidang Crypto x AI menggunakan TEE untuk membangun produk.
Seperti halnya dengan setiap teknologi baru, TEE sedang mengalami periode eksperimen yang optimis. Artikel ini bertujuan untuk menyediakan panduan konsep dasar bagi pengembang dan pembaca umum, sehingga mereka dapat memahami apa itu TEE, model keamanan TEE, kerentanan umum, dan praktik terbaik penggunaan TEE dengan aman. (Catatan: Untuk memudahkan pemahaman teks, kami dengan sengaja menggunakan istilah yang lebih sederhana untuk menggantikan istilah TEE).
Apa itu TEE
TEE adalah lingkungan isolasi di prosesor atau pusat data di mana program dapat berjalan tanpa intervensi dari bagian lain dari sistem. Untuk mencegah intervensi dari bagian lain terhadap TEE, kita memerlukan serangkaian desain, terutama termasuk kontrol akses yang ketat, yaitu mengontrol akses bagian lain dari sistem terhadap program dan data dalam TEE. Saat ini, TEE hadir di mana-mana, mulai dari ponsel, server, PC, hingga lingkungan cloud, sehingga sangat mudah diakses dan terjangkau.
Konten di atas mungkin terdengar kabur dan abstrak, sebenarnya cara TEE diimplementasikan oleh server dan penyedia cloud yang berbeda berbeda, tetapi tujuan pokoknya adalah untuk mencegah TEE diinterferensi oleh program lain.
Sebagian besar pembaca mungkin akan menggunakan informasi biometrik untuk masuk ke perangkat, misalnya membuka kunci ponsel dengan sidik jari. Tetapi bagaimana kita memastikan aplikasi jahat, situs web, atau sistem operasi jailbreak tidak dapat mengakses dan mencuri informasi biometrik ini? Faktanya, selain mengenkripsi data, sirkuit dalam perangkat TEE sama sekali tidak mengizinkan program apa pun mengakses area memori dan pemrosesan yang digunakan oleh data sensitif.
Dompet keras adalah contoh lain dari skenario aplikasi TEE. Dompet keras terhubung ke komputer dan berkomunikasi dengan sandbox-nya, tetapi komputer tidak dapat mengakses frase kunci yang disimpan di dalam dompet keras secara langsung. Dalam kedua kasus di atas, pengguna percaya bahwa produsen perangkat dapat merancang chip dengan benar dan memberikan pembaruan firmware yang sesuai untuk mencegah data rahasia di dalam TEE diekspor atau dilihat.
Model Keamanan
Sayangnya, ada begitu banyak jenis implementasi TEE, dan setiap implementasi yang berbeda (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) memerlukan pemodelan analisis keamanan yang independen. Di bagian sisa dari artikel ini, kita akan membahas terutama IntelSGX, TDX, dan AWSNitro, karena sistem TEE ini memiliki lebih banyak pengguna dan juga memiliki alat pengembangan yang lengkap. Sistem-sistem di atas juga merupakan sistem TEE yang paling umum digunakan di dalam Web3.
Secara umum, alur kerja aplikasi yang diterapkan di TEE adalah sebagai berikut:
"Pengembang" menulis beberapa kode yang mungkin atau mungkin tidak bersumber terbuka
Kemudian, pengembang akan mempackage kode ke dalam file gambar Enclave (EIF), yang dapat dijalankan di TEE
EIF ditempatkan di server yang dilengkapi dengan sistem TEE. Dalam beberapa kasus, pengembang dapat langsung menggunakan komputer pribadi yang dilengkapi dengan TEE untuk menempatkan EIF dan menyediakan layanan kepada publik.
Pengguna dapat berinteraksi dengan aplikasi melalui antarmuka yang telah ditentukan sebelumnya.
Jelas, ada tiga risiko potensial di dalamnya:
Pengembang: Apa tujuan dari menyiapkan kode EIF? Kode EIF mungkin tidak sesuai dengan logika bisnis yang dipromosikan oleh pihak proyek, dan mungkin mencuri data privasi pengguna.
Server: Apakah file EIF TEE berjalan sesuai dengan yang diharapkan? Atau apakah EIF benar-benar dieksekusi di dalam TEE? Server juga dapat menjalankan program lain di dalam TEE.
Pemasok: Apakah desain TEE aman? Apakah ada pintu belakang yang akan mengungkapkan semua data dalam TEE kepada pemasok?
Beruntungnya, TEE sekarang memiliki solusi untuk menghilangkan risiko di atas, yaitu Reproducible Builds( dan Remote Atteststations) yang dapat dibangun ulang(.
Jadi apa yang dimaksud dengan konstruksi yang dapat diulang? Pengembangan perangkat lunak modern seringkali memerlukan impor dependensi yang besar, seperti alat, pustaka, atau kerangka eksternal, dan file dependensi ini juga mungkin memiliki masalah tersembunyi. Sekarang solusi seperti npm menggunakan hash kode yang sesuai dengan file dependensi sebagai identifier unik. Ketika npm menemukan bahwa file dependensi tidak sesuai dengan nilai hash yang tercatat, itu bisa menganggap bahwa file dependensi telah dimodifikasi.
Dapat dibangun ulang yang dapat dianggap sebagai seperangkat standar, yang bertujuan agar ketika kode apa pun berjalan di perangkat apa pun, asalkan dibangun sesuai prosedur yang telah ditentukan sebelumnya, maka akhirnya akan menghasilkan nilai hash yang konsisten. Tentu saja, di dalam praktek kita juga dapat menggunakan produk lain selain hash sebagai identifier, di sini kita sebut sebagai pengukuran kode)code measurement(.
Nix adalah alat umum untuk build berulang. Ketika kode sumber program terbuka, siapa pun dapat memeriksa kode untuk memastikan bahwa pengembang tidak memasukkan sesuatu yang tidak biasa, dan siapa pun dapat membangun kode menggunakan Nix untuk memeriksa apakah produk yang dibangun memiliki metrik / hash kode yang sama dengan produk yang digunakan oleh tim proyek dalam produksi. Tetapi bagaimana kita mengetahui metrik kode untuk suatu program di TEE? Ini membawa kita ke konsep yang disebut "bukti jarak jauh". **
Bukti Jarak Jauh adalah pesan tanda tangan yang berasal dari platform TEE (Pihak Terpercaya), yang mencakup nilai pengukuran kode program, versi platform TEE, dll. Bukti jarak jauh memungkinkan pengamat eksternal mengetahui bahwa suatu program sedang dijalankan di lokasi aman yang tidak dapat diakses oleh siapa pun (TEE asli versi xx).
Dapat dibangun ulang dan bukti jarak jauh memungkinkan pengguna mana pun untuk mengetahui kode aktual yang berjalan di dalam TEE dan informasi versi platform TEE, sehingga mencegah pengembang atau server melakukan hal yang jahat.
Namun, dalam kasus TEE, selalu perlu mempercayai pemasoknya. Jika pemasok TEE berbuat jahat, mereka dapat dengan langsung memalsukan bukti jarak jauh. Oleh karena itu, jika memandang pemasok sebagai media serangan yang mungkin, sebaiknya menghindari ketergantungan hanya pada TEE, lebih baik menggabungkannya dengan ZK atau protokol konsensus.
Keindahan TEE
Menurut pandangan kami, fitur-fitur yang sangat populer di TEE, terutama dalam hal kemudahan implementasi untuk AI Agent, terutama terdiri dari beberapa poin berikut:
Kinerja: TEE dapat menjalankan model LLM, kinerjanya dan biayanya mirip dengan server konvensional. Sementara zkML memerlukan daya komputasi yang besar untuk menghasilkan bukti zk LLM.
Dukungan GPU: NVIDIA menyediakan dukungan komputasi TEE pada seri GPU terbarunya (Hopper, Blackwell, dll.)
Keakuratan: LLMs adalah non-deterministik; masukan yang sama dari kata kunci yang sama akan menghasilkan hasil yang berbeda. Oleh karena itu, beberapa node (termasuk pengamat yang mencoba membuat bukti penipuan) mungkin tidak pernah mencapai konsensus tentang hasil operasi LLM. Dalam skenario ini, kita dapat mempercayai bahwa LLM yang berjalan di dalam TEE tidak dapat dimanipulasi oleh penjahat, program di dalam TEE selalu berjalan sesuai dengan yang ditulis, ini membuat TEE lebih cocok untuk menjamin keandalan hasil penalaran LLM daripada opML atau konsensus.
Kerahasiaan: Data di dalam TEE tidak terlihat oleh program eksternal. Oleh karena itu, kunci privat yang dihasilkan atau diterima di dalam TEE selalu aman. Fitur ini dapat digunakan untuk menjamin kepada pengguna bahwa pesan yang ditandatangani oleh kunci tersebut berasal dari program internal TEE. Pengguna dapat dengan aman menitipkan kunci privat kepada TEE dan mengatur beberapa kondisi tandatangan, dan dapat mengonfirmasi bahwa tandatangan dari TEE sesuai dengan kondisi tandatangan yang sudah ditetapkan sebelumnya
Koneksi Internet: Melalui beberapa alat, program yang dijalankan di TEE dapat mengakses internet dengan aman (tanpa perlu mengungkapkan permintaan atau respons ke server yang menjalankan TEE, namun masih dapat memberikan jaminan pengambilan data yang benar kepada pihak ketiga). Ini sangat berguna untuk mengambil informasi dari API pihak ketiga, dan dapat digunakan untuk mengoutsourcing komputasi ke penyedia model yang tepercaya namun propietary.
Hak Tulis: Berbeda dengan skema zk, kode yang berjalan di TEE dapat membangun pesan (baik itu tweet atau transaksi) dan mengirimkannya melalui jaringan API dan RPC
**Pengembang Ramah: Kerangka dan SDK terkait TEE memungkinkan orang menulis kode dalam bahasa apa pun dan dengan mudah mendeploy program ke TEE seperti yang dilakukan di server cloud
Baik atau buruk, pada saat ini sulit menemukan alternatif untuk banyak kasus penggunaan TEE. Kami percaya bahwa pengenalan TEE akan memperluas ruang pengembangan aplikasi di atas rantai, yang mungkin mendorong terciptanya skenario aplikasi baru.
TEE bukan peluru perak
Program yang berjalan di TEE masih rentan terhadap serangkaian serangan dan kesalahan. Seperti kontrak pintar, mereka rentan terhadap sejumlah masalah. Untuk kemudahan, kami akan mengklasifikasikan kerentanan yang mungkin seperti berikut:
Pengembang lalai
Kerentanan waktu proses
Kekurangan Desain Arsitektur
Masalah operasional
pengembang ceroboh
Baik disengaja maupun tidak, pengembang dapat melemahkan jaminan keamanan program dalam TEE melalui kode yang disengaja atau tidak disengaja. Ini termasuk:
Kode Tidak Transparan: Model keamanan TEE bergantung pada verifikasi eksternal. Transparansi kode sangat penting untuk verifikasi oleh pihak ketiga eksternal.
Masalah Pengukuran Kode: Bahkan jika kode tersebut terbuka, jika tidak ada pihak ketiga yang membangun ulang kode dan memeriksa nilai pengukuran kode dalam bukti jarak jauh, lalu memeriksa pengukuran kode yang disediakan dalam bukti jarak jauh, itu mirip dengan menerima bukti zk tetapi tidak memverifikasinya.
Kode Tidak Aman: Meskipun Anda hati-hati menghasilkan dan mengelola kunci dengan benar di TEE, logika yang terkandung dalam kode juga dapat mengungkapkan kunci dalam TEE selama proses panggilan eksternal. Selain itu, kode dapat berisi pintu belakang atau kerentanan. Dibandingkan dengan pengembangan backend tradisional, ini membutuhkan proses pengembangan dan audit perangkat lunak yang memiliki standar tinggi, mirip dengan pengembangan kontrak pintar.
Serangan Rantai Pasokan: Pengembangan perangkat lunak modern menggunakan banyak kode pihak ketiga. Serangan Rantai Pasokan merupakan ancaman serius terhadap integritas TEE.
Kerentanan Waktu Eksekusi
Pengembang bahkan yang paling berhati-hati pun bisa menjadi korban kerentanan saat runtime. Pengembang harus mempertimbangkan dengan hati-hati apakah salah satu dari berikut ini akan mempengaruhi jaminan keamanan proyek mereka:
Kode Dinamis: Tidak selalu mungkin untuk menjaga semua kode tetap transparan. Terkadang, kasus penggunaan itu sendiri memerlukan eksekusi dinamis dari kode yang tidak transparan yang dimuat ke dalam TEE pada waktu runtime. Jenis kode seperti ini rentan terhadap kebocoran informasi rahasia atau pelanggaran invarian, sehingga perlu dijaga dengan sangat hati-hati untuk mencegah hal ini.
Data Dinamis: Sebagian besar aplikasi menggunakan API eksternal dan sumber data lainnya selama proses eksekusi. Model keamanan diperluas untuk mencakup sumber data ini, yang berada pada posisi yang sama dengan orakel dalam DeFi. Data yang tidak benar atau usang dapat menyebabkan bencana. Misalnya, dalam kasus penggunaan Agensi AI, terlalu bergantung pada layanan LLM seperti Claude.
Komunikasi yang Tidak Aman dan Tidak Stabil: TEE perlu berjalan di dalam server yang mengandung komponen TEE. Dari segi keamanan, server yang menjalankan TEE sebenarnya berperan sebagai perantara sempurna antara TEE dan interaksi eksternal (MitM). Server tidak hanya dapat mengintip koneksi eksternal TEE dan melihat konten yang sedang dikirim, tetapi juga dapat memeriksa IP tertentu, membatasi koneksi, dan menyisipkan paket data dalam koneksi dengan tujuan menipu salah satu pihak agar percaya bahwa itu berasal dari xx.
Misalnya, dalam TEE, mesin pencocokan yang dapat memproses transaksi enkripsi tidak dapat memberikan jaminan urutan yang adil (anti-MEV), karena router/gateway/host masih dapat menjatuhkan, menunda, atau memprioritaskan berdasarkan alamat IP sumber paket data.
Kekurangan Arsitektur
Teknologi yang digunakan dalam aplikasi TEE harus diperlakukan dengan hati-hati. Beberapa masalah yang mungkin muncul saat membangun aplikasi TEE adalah:
**Aplikasi dengan Luas Serangan yang Lebih Besar: *** Serangan aplikasi mengacu pada jumlah modul kode yang perlu diamankan sepenuhnya. Kode dengan serangan yang lebih besar sangat sulit diaudit dan mungkin menyembunyikan bug atau kerentanan yang dapat dieksploitasi. ** Ini juga sering bertentangan dengan pengalaman pengembang. Misalnya, dibandingkan dengan program TEE yang tidak bergantung pada Docker, program TEE yang bergantung pada Docker memiliki serangan yang lebih besar. Enclave yang bergantung pada sistem operasi yang matang memiliki serangan yang lebih besar dibandingkan dengan program TEE yang menggunakan sistem operasi yang paling ringan.
Portabilitas dan Aktivitas: Dalam Web3, aplikasi harus tahan terhadap sensor. Siapa pun dapat memulai TEE dan mengambil alih peserta sistem yang tidak aktif, serta membuat aplikasi di dalam TEE dapat dipindahkan. Tantangan terbesar di sini adalah portabilitas kunci. Beberapa sistem TEE memiliki mekanisme derivasi kunci, tetapi begitu menggunakan mekanisme derivasi kunci di dalam TEE, server lain tidak dapat menghasilkan kunci di dalam program TEE secara lokal, ini membuat program TEE biasanya terbatas pada mesin yang sama, yang tidak cukup untuk menjaga portabilitas
Akar Kepercayaan yang Tidak Aman: Misalnya, ketika menjalankan AI Agent di dalam TEE, bagaimana cara memverifikasi apakah alamat yang diberikan termasuk dalam Agent tersebut? Jika desainnya tidak dipikirkan dengan baik, dapat menyebabkan akar kepercayaan sebenarnya menjadi pihak ketiga eksternal atau platform pengelolaan kunci, bukan TEE itu sendiri.
Masalah Operasional
Titik terakhir namun tidak paling tidak penting adalah, ada beberapa hal praktis tentang bagaimana menjalankan server yang menjalankan program TEE secara nyata:
Versi Platform yang Tidak Aman: Platform TEE kadang-kadang menerima pembaruan keamanan, pembaruan tersebut akan tercermin sebagai versi platform dalam bukti jarak jauh. Jika TEE Anda tidak berjalan pada versi platform yang aman, hacker dapat menggunakan media serangan yang diketahui untuk mencuri kunci dari TEE. Yang lebih buruk, TEE Anda mungkin berjalan pada versi platform yang aman hari ini, tetapi besok bisa menjadi tidak aman.
Tidak ada keamanan fisik: Meskipun Anda telah melakukan upaya maksimal, TEE dapat rentan terhadap serangan saluran samping, yang umumnya membutuhkan akses fisik dan kontrol ke server yang meng-host TEE. Oleh karena itu, keamanan fisik merupakan lapisan pertahanan yang penting. Konsep terkait adalah bukti awan, di mana Anda dapat membuktikan bahwa TEE berjalan di pusat data awan dan platform awan tersebut memiliki jaminan keamanan fisik.
Membangun Program TEE yang Aman
Kami membagi saran kami menjadi beberapa poin berikut:
Solusi yang paling aman
Langkah pencegahan yang diperlukan
Saran tergantung pada kasus penggunaan
Solusi paling aman: tanpa dependensi eksternal
Membuat aplikasi yang sangat aman mungkin melibatkan penghapusan dependensi eksternal seperti input eksternal, API, atau layanan, untuk mengurangi serangan yang mungkin terjadi. Pendekatan ini dapat memastikan bahwa aplikasi berjalan secara independen tanpa interaksi eksternal yang dapat mengancam integritas atau keamanannya. Meskipun strategi ini dapat membatasi keanekaragaman fitur aplikasi, namun dapat memberikan tingkat keamanan yang sangat tinggi.
Jika model berjalan secara lokal, tingkat keamanan ini dapat dicapai untuk sebagian besar kasus penggunaan CryptoxAI.
2. Tindakan Pencegahan yang Diperlukan
Tidak peduli apakah aplikasi memiliki dependensi eksternal atau tidak, konten berikut diperlukan!
Menganggap aplikasi TEE sebagai kontrak pintar, bukan aplikasi backend; tetapkan frekuensi pembaruan yang rendah, dan lakukan pengujian secara ketat.
Pembangunan program TEE harus sama ketatnya dengan menulis, menguji, dan memperbarui kontrak pintar. Seperti kontrak pintar, TEE beroperasi di lingkungan yang sangat sensitif dan tidak dapat diubah, di mana kesalahan atau perilaku yang tidak terduga dapat memiliki konsekuensi serius, termasuk kehilangan dana sepenuhnya. Audit menyeluruh, pengujian yang luas, dan pembaruan minimal yang telah diaudit dengan cermat sangat penting untuk memastikan integritas dan keandalan aplikasi berbasis TEE.
Memeriksa kode audit dan memeriksa pipa bangunan
Keamanan aplikasi tidak hanya bergantung pada kode itu sendiri, tetapi juga bergantung pada alat-alat yang digunakan dalam proses pembangunan. Pipa pembangunan yang aman sangat penting untuk mencegah kerentanan. TEE hanya menjamin bahwa kode yang disediakan akan berjalan sesuai dengan proses yang diharapkan, tetapi tidak dapat memperbaiki cacat yang diperkenalkan dalam proses pembangunan.
Untuk mengurangi risiko, kode harus diuji dan diaudit dengan ketat untuk menghilangkan kesalahan dan mencegah kebocoran informasi yang tidak perlu. Selain itu, pembangunan yang dapat diulang berperan sangat penting, terutama ketika kode dikembangkan oleh satu pihak dan digunakan oleh pihak lain. Pembangunan yang dapat diulang memungkinkan siapa pun memverifikasi apakah program yang dieksekusi di dalam TEE sesuai dengan kode sumber asli, untuk memastikan transparansi dan kepercayaan. Tanpa pembangunan yang dapat diulang, sangat sulit untuk menentukan konten yang tepat dari program yang dieksekusi di dalam TEE, yang dapat mengancam keamanan aplikasi.
Misalnya, kode sumber DeepWorm (proyek pemodelan otak cacing yang dijalankan di TEE) sepenuhnya terbuka. Program yang dieksekusi di dalam TEE dibangun secara dapat direproduksi menggunakan saluran Nix.
Menggunakan perpustakaan yang telah diaudit atau diverifikasi
Ketika memproses data sensitif dalam program TEE, hanya gunakan perpustakaan yang telah diaudit untuk manajemen kunci dan pemrosesan data pribadi. Perpustakaan yang belum diaudit dapat mengungkapkan kunci dan mengancam keamanan aplikasi. Utamakan dependensi yang telah diperiksa secara menyeluruh dan berfokus pada keamanan untuk menjaga kerahasiaan dan integritas data.
Selalu verifikasi bukti dari TEE
Pengguna yang berinteraksi dengan TEE harus memverifikasi bukti jarak jauh atau mekanisme verifikasi yang dihasilkan oleh TEE untuk memastikan interaksi yang aman dan dapat dipercaya. Tanpa pemeriksaan ini, server dapat memanipulasi respons, sehingga sulit untuk membedakan antara output TEE yang sebenarnya dan data yang telah dimanipulasi. Bukti jarak jauh menyediakan bukti kunci untuk kode dan konfigurasi yang berjalan di dalam TEE, dan kita dapat menggunakan bukti jarak jauh ini untuk menentukan apakah program yang dieksekusi di dalam TEE sesuai dengan yang diharapkan.
Bukti konkret dapat diverifikasi di rantai (IntelSGX, AWSNitro), menggunakan bukti ZK (IntelSGX, AWSNitro) untuk verifikasi di luar rantai, atau dapat diverifikasi oleh pengguna sendiri atau layanan host (seperti t16z atau MarlinHub).
3. Saran Berdasarkan Kasus Penggunaan
Berdasarkan kasus penggunaan dan struktur aplikasi, petunjuk berikut mungkin membantu membuat aplikasi Anda lebih aman.
Pastikan selalu melakukan interaksi pengguna dengan TEE melalui saluran yang aman
Server yang di dalam TEE pada dasarnya tidak dapat dipercaya. Server dapat mengintersep dan mengubah komunikasi. Dalam beberapa kasus, membaca data tanpa mengubahnya mungkin dapat diterima, tetapi dalam kasus lain, bahkan membaca data saja mungkin tidak diinginkan. Untuk mengurangi risiko ini, sangat penting untuk membangun saluran enkripsi end-to-end yang aman antara pengguna dan TEE. Setidaknya, pastikan pesan mencakup tanda tangan untuk memverifikasi keasliannya dan sumbernya. Selain itu, pengguna perlu selalu memeriksa bukti jarak jauh yang diberikan oleh TEE untuk memastikan bahwa mereka berkomunikasi dengan TEE yang benar. Ini memastikan integritas dan kerahasiaan komunikasi.
Misalnya, Oyster dapat mendukung penerbitan TLS yang aman dengan menggunakan catatan CAA dan RFC8657. Selain itu, itu juga menyediakan protokol TLS asli bernama Scallop, yang tidak bergantung pada WebPKI.
Mengetahui bahwa TEE memori adalah transient
Memori TEE adalah transient, yang berarti saat TEE dimatikan, isinya (termasuk kunci enkripsi) akan hilang. Jika tidak ada mekanisme keamanan yang dapat menyimpan informasi ini, data penting mungkin tidak dapat diakses secara permanen, yang dapat mengakibatkan kesulitan dalam akses keuangan atau operasional.
Jaringan Komputasi Multipihak (MPC) dengan sistem penyimpanan terdesentralisasi seperti IPFS dapat digunakan sebagai solusi untuk masalah ini. Jaringan MPC membagi kunci ke beberapa node untuk memastikan tidak ada satu pun node yang memiliki kunci lengkap, sambil memungkinkan jaringan untuk membangun kembali kunci saat diperlukan. Data yang dienkripsi dengan kunci ini dapat disimpan dengan aman di IPFS.
Jika diperlukan, jaringan MPC dapat memberikan kunci ke server TEE baru yang menjalankan gambar yang sama, dengan syarat-syarat tertentu dipenuhi. Metode ini dapat memastikan elastisitas dan keamanan yang kuat, sehingga data tetap dapat diakses dan dirahasiakan bahkan di lingkungan yang tidak terpercaya.
Ada solusi lain, yaitu TEE membagi transaksi terkait ke server MPC yang berbeda, setelah itu server MPC menandatangani dan menggabungkan transaksi tersebut sebelum akhirnya ditambahkan ke blockchain. Metode ini jauh kurang fleksibel, tidak dapat digunakan untuk menyimpan kunci API, password, atau data apa pun (tanpa layanan penyimpanan pihak ketiga yang terpercaya).
Untuk kasus penggunaan yang sangat aman, layak untuk mencoba mengurangi ketergantungan periferal sebanyak mungkin dengan mengorbankan pengalaman pengembang. Misalnya, Dstack dilengkapi dengan kernel minimal berbasis Yocto yang hanya berisi modul yang diperlukan untuk fungsi Dstack. Bahkan layak untuk menggunakan teknologi lama seperti SGX (lebih dari TDX) karena teknologi tersebut tidak memerlukan bootloader atau sistem operasi menjadi bagian dari TEE.
Isolasi Fisik
Dengan mengisolasi fisik TEE dari intervensi manusia yang mungkin, keamanan TEE dapat ditingkatkan lebih lanjut. Meskipun kita dapat mempercayai pusat data untuk menyediakan keamanan fisik dengan mendukung server TEE di pusat data dan penyedia cloud, proyek seperti Spacecoin sedang mengeksplorasi alternatif yang cukup menarik - luar angkasa. Makalah SpaceTEE bergantung pada langkah-langkah keamanan seperti pengukuran momen inersia setelah peluncuran untuk memverifikasi apakah satelit mengalami deviasi yang diharapkan saat memasuki orbit.
Multiple Verifiers
Sama seperti Ethereum mengandalkan implementasi klien ganda untuk mengurangi risiko bug yang memengaruhi seluruh jaringan, multiproviders menggunakan berbagai skema implementasi TEE untuk meningkatkan keamanan dan ketahanan. Dengan menjalankan langkah-langkah komputasi yang sama di berbagai platform TEE, verifikasi ganda dapat memastikan bahwa kerentanan dalam satu implementasi TEE tidak akan membahayakan seluruh aplikasi. Meskipun pendekatan ini mensyaratkan bahwa proses komputasi bersifat deterministik, atau mendefinisikan konsensus di antara skema implementasi TEE yang berbeda dalam situasi yang tidak deterministik, namun hal ini juga memberikan keuntungan signifikan seperti isolasi kesalahan, redundansi, dan verifikasi lintas, menjadikannya pilihan yang baik untuk aplikasi yang membutuhkan jaminan keandalan.
TEE jelas telah menjadi area yang sangat menarik. Seperti disebutkan sebelumnya, di mana-mana AI dan akses konstan ke data sensitif pengguna berarti bahwa perusahaan teknologi besar seperti Apple dan NVIDIA menggunakan TEE dalam produk mereka dan menawarkan TEE sebagai bagian dari penawaran mereka.
Di sisi lain, komunitas kripto selalu sangat memperhatikan keamanan. Saat pengembang mencoba untuk memperluas aplikasi dan kasus penggunaan on-chain, kita telah melihat TEE menjadi solusi yang populer dalam memberikan keseimbangan yang tepat antara fungsionalitas dan asumsi kepercayaan. Meskipun TEE tidak seperti solusi ZK lengkap yang meminimalkan kepercayaan, kami memperkirakan TEE akan menjadi cara bagi perusahaan Web3 dan produk perusahaan teknologi besar untuk perlahan-lahan bergabung.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Panduan Pengembangan untuk TEE
Penulis: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Dikompilasi oleh: Shew, GodRealmX
Sejak Apple mengumumkan peluncuran awan pribadi dan NVIDIA menyediakan komputasi rahasia dalam GPU, lingkungan eksekusi tepercaya (TEE) telah menjadi semakin populer. Jaminan kerahasiaan mereka membantu melindungi data pengguna (termasuk kunci pribadi), sementara isolasi memastikan bahwa eksekusi program yang ditempatkan di atasnya tidak dapat dimanipulasi - baik oleh manusia, program lain, atau sistem operasi. Oleh karena itu, tidak mengherankan bahwa banyak produk di bidang Crypto x AI menggunakan TEE untuk membangun produk.
Seperti halnya dengan setiap teknologi baru, TEE sedang mengalami periode eksperimen yang optimis. Artikel ini bertujuan untuk menyediakan panduan konsep dasar bagi pengembang dan pembaca umum, sehingga mereka dapat memahami apa itu TEE, model keamanan TEE, kerentanan umum, dan praktik terbaik penggunaan TEE dengan aman. (Catatan: Untuk memudahkan pemahaman teks, kami dengan sengaja menggunakan istilah yang lebih sederhana untuk menggantikan istilah TEE).
Apa itu TEE
TEE adalah lingkungan isolasi di prosesor atau pusat data di mana program dapat berjalan tanpa intervensi dari bagian lain dari sistem. Untuk mencegah intervensi dari bagian lain terhadap TEE, kita memerlukan serangkaian desain, terutama termasuk kontrol akses yang ketat, yaitu mengontrol akses bagian lain dari sistem terhadap program dan data dalam TEE. Saat ini, TEE hadir di mana-mana, mulai dari ponsel, server, PC, hingga lingkungan cloud, sehingga sangat mudah diakses dan terjangkau.
Konten di atas mungkin terdengar kabur dan abstrak, sebenarnya cara TEE diimplementasikan oleh server dan penyedia cloud yang berbeda berbeda, tetapi tujuan pokoknya adalah untuk mencegah TEE diinterferensi oleh program lain.
Sebagian besar pembaca mungkin akan menggunakan informasi biometrik untuk masuk ke perangkat, misalnya membuka kunci ponsel dengan sidik jari. Tetapi bagaimana kita memastikan aplikasi jahat, situs web, atau sistem operasi jailbreak tidak dapat mengakses dan mencuri informasi biometrik ini? Faktanya, selain mengenkripsi data, sirkuit dalam perangkat TEE sama sekali tidak mengizinkan program apa pun mengakses area memori dan pemrosesan yang digunakan oleh data sensitif.
Dompet keras adalah contoh lain dari skenario aplikasi TEE. Dompet keras terhubung ke komputer dan berkomunikasi dengan sandbox-nya, tetapi komputer tidak dapat mengakses frase kunci yang disimpan di dalam dompet keras secara langsung. Dalam kedua kasus di atas, pengguna percaya bahwa produsen perangkat dapat merancang chip dengan benar dan memberikan pembaruan firmware yang sesuai untuk mencegah data rahasia di dalam TEE diekspor atau dilihat.
Model Keamanan
Sayangnya, ada begitu banyak jenis implementasi TEE, dan setiap implementasi yang berbeda (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) memerlukan pemodelan analisis keamanan yang independen. Di bagian sisa dari artikel ini, kita akan membahas terutama IntelSGX, TDX, dan AWSNitro, karena sistem TEE ini memiliki lebih banyak pengguna dan juga memiliki alat pengembangan yang lengkap. Sistem-sistem di atas juga merupakan sistem TEE yang paling umum digunakan di dalam Web3.
Secara umum, alur kerja aplikasi yang diterapkan di TEE adalah sebagai berikut:
Jelas, ada tiga risiko potensial di dalamnya:
Beruntungnya, TEE sekarang memiliki solusi untuk menghilangkan risiko di atas, yaitu Reproducible Builds( dan Remote Atteststations) yang dapat dibangun ulang(.
Jadi apa yang dimaksud dengan konstruksi yang dapat diulang? Pengembangan perangkat lunak modern seringkali memerlukan impor dependensi yang besar, seperti alat, pustaka, atau kerangka eksternal, dan file dependensi ini juga mungkin memiliki masalah tersembunyi. Sekarang solusi seperti npm menggunakan hash kode yang sesuai dengan file dependensi sebagai identifier unik. Ketika npm menemukan bahwa file dependensi tidak sesuai dengan nilai hash yang tercatat, itu bisa menganggap bahwa file dependensi telah dimodifikasi.
![])https://img.gateio.im/social/moments-9cd2aa236f682970fe58733c85a6884f(
Dapat dibangun ulang yang dapat dianggap sebagai seperangkat standar, yang bertujuan agar ketika kode apa pun berjalan di perangkat apa pun, asalkan dibangun sesuai prosedur yang telah ditentukan sebelumnya, maka akhirnya akan menghasilkan nilai hash yang konsisten. Tentu saja, di dalam praktek kita juga dapat menggunakan produk lain selain hash sebagai identifier, di sini kita sebut sebagai pengukuran kode)code measurement(.
Nix adalah alat umum untuk build berulang. Ketika kode sumber program terbuka, siapa pun dapat memeriksa kode untuk memastikan bahwa pengembang tidak memasukkan sesuatu yang tidak biasa, dan siapa pun dapat membangun kode menggunakan Nix untuk memeriksa apakah produk yang dibangun memiliki metrik / hash kode yang sama dengan produk yang digunakan oleh tim proyek dalam produksi. Tetapi bagaimana kita mengetahui metrik kode untuk suatu program di TEE? Ini membawa kita ke konsep yang disebut "bukti jarak jauh". **
![])https://img.gateio.im/social/moments-de22e99c8194fa04f29ee5416aebcd03(
Bukti Jarak Jauh adalah pesan tanda tangan yang berasal dari platform TEE (Pihak Terpercaya), yang mencakup nilai pengukuran kode program, versi platform TEE, dll. Bukti jarak jauh memungkinkan pengamat eksternal mengetahui bahwa suatu program sedang dijalankan di lokasi aman yang tidak dapat diakses oleh siapa pun (TEE asli versi xx).
![])https://img.gateio.im/social/moments-e4900d340dd1c812355c38739632d2a6(
Dapat dibangun ulang dan bukti jarak jauh memungkinkan pengguna mana pun untuk mengetahui kode aktual yang berjalan di dalam TEE dan informasi versi platform TEE, sehingga mencegah pengembang atau server melakukan hal yang jahat.
Namun, dalam kasus TEE, selalu perlu mempercayai pemasoknya. Jika pemasok TEE berbuat jahat, mereka dapat dengan langsung memalsukan bukti jarak jauh. Oleh karena itu, jika memandang pemasok sebagai media serangan yang mungkin, sebaiknya menghindari ketergantungan hanya pada TEE, lebih baik menggabungkannya dengan ZK atau protokol konsensus.
Keindahan TEE
Menurut pandangan kami, fitur-fitur yang sangat populer di TEE, terutama dalam hal kemudahan implementasi untuk AI Agent, terutama terdiri dari beberapa poin berikut:
Baik atau buruk, pada saat ini sulit menemukan alternatif untuk banyak kasus penggunaan TEE. Kami percaya bahwa pengenalan TEE akan memperluas ruang pengembangan aplikasi di atas rantai, yang mungkin mendorong terciptanya skenario aplikasi baru.
TEE bukan peluru perak
Program yang berjalan di TEE masih rentan terhadap serangkaian serangan dan kesalahan. Seperti kontrak pintar, mereka rentan terhadap sejumlah masalah. Untuk kemudahan, kami akan mengklasifikasikan kerentanan yang mungkin seperti berikut:
pengembang ceroboh
Baik disengaja maupun tidak, pengembang dapat melemahkan jaminan keamanan program dalam TEE melalui kode yang disengaja atau tidak disengaja. Ini termasuk:
Kerentanan Waktu Eksekusi
Pengembang bahkan yang paling berhati-hati pun bisa menjadi korban kerentanan saat runtime. Pengembang harus mempertimbangkan dengan hati-hati apakah salah satu dari berikut ini akan mempengaruhi jaminan keamanan proyek mereka:
Misalnya, dalam TEE, mesin pencocokan yang dapat memproses transaksi enkripsi tidak dapat memberikan jaminan urutan yang adil (anti-MEV), karena router/gateway/host masih dapat menjatuhkan, menunda, atau memprioritaskan berdasarkan alamat IP sumber paket data.
Kekurangan Arsitektur
Teknologi yang digunakan dalam aplikasi TEE harus diperlakukan dengan hati-hati. Beberapa masalah yang mungkin muncul saat membangun aplikasi TEE adalah:
Masalah Operasional
Titik terakhir namun tidak paling tidak penting adalah, ada beberapa hal praktis tentang bagaimana menjalankan server yang menjalankan program TEE secara nyata:
Membangun Program TEE yang Aman
Kami membagi saran kami menjadi beberapa poin berikut:
Membuat aplikasi yang sangat aman mungkin melibatkan penghapusan dependensi eksternal seperti input eksternal, API, atau layanan, untuk mengurangi serangan yang mungkin terjadi. Pendekatan ini dapat memastikan bahwa aplikasi berjalan secara independen tanpa interaksi eksternal yang dapat mengancam integritas atau keamanannya. Meskipun strategi ini dapat membatasi keanekaragaman fitur aplikasi, namun dapat memberikan tingkat keamanan yang sangat tinggi.
Jika model berjalan secara lokal, tingkat keamanan ini dapat dicapai untuk sebagian besar kasus penggunaan CryptoxAI.
2. Tindakan Pencegahan yang Diperlukan
Tidak peduli apakah aplikasi memiliki dependensi eksternal atau tidak, konten berikut diperlukan!
Menganggap aplikasi TEE sebagai kontrak pintar, bukan aplikasi backend; tetapkan frekuensi pembaruan yang rendah, dan lakukan pengujian secara ketat.
Pembangunan program TEE harus sama ketatnya dengan menulis, menguji, dan memperbarui kontrak pintar. Seperti kontrak pintar, TEE beroperasi di lingkungan yang sangat sensitif dan tidak dapat diubah, di mana kesalahan atau perilaku yang tidak terduga dapat memiliki konsekuensi serius, termasuk kehilangan dana sepenuhnya. Audit menyeluruh, pengujian yang luas, dan pembaruan minimal yang telah diaudit dengan cermat sangat penting untuk memastikan integritas dan keandalan aplikasi berbasis TEE.
Memeriksa kode audit dan memeriksa pipa bangunan
Keamanan aplikasi tidak hanya bergantung pada kode itu sendiri, tetapi juga bergantung pada alat-alat yang digunakan dalam proses pembangunan. Pipa pembangunan yang aman sangat penting untuk mencegah kerentanan. TEE hanya menjamin bahwa kode yang disediakan akan berjalan sesuai dengan proses yang diharapkan, tetapi tidak dapat memperbaiki cacat yang diperkenalkan dalam proses pembangunan.
Untuk mengurangi risiko, kode harus diuji dan diaudit dengan ketat untuk menghilangkan kesalahan dan mencegah kebocoran informasi yang tidak perlu. Selain itu, pembangunan yang dapat diulang berperan sangat penting, terutama ketika kode dikembangkan oleh satu pihak dan digunakan oleh pihak lain. Pembangunan yang dapat diulang memungkinkan siapa pun memverifikasi apakah program yang dieksekusi di dalam TEE sesuai dengan kode sumber asli, untuk memastikan transparansi dan kepercayaan. Tanpa pembangunan yang dapat diulang, sangat sulit untuk menentukan konten yang tepat dari program yang dieksekusi di dalam TEE, yang dapat mengancam keamanan aplikasi.
Misalnya, kode sumber DeepWorm (proyek pemodelan otak cacing yang dijalankan di TEE) sepenuhnya terbuka. Program yang dieksekusi di dalam TEE dibangun secara dapat direproduksi menggunakan saluran Nix.
Menggunakan perpustakaan yang telah diaudit atau diverifikasi
Ketika memproses data sensitif dalam program TEE, hanya gunakan perpustakaan yang telah diaudit untuk manajemen kunci dan pemrosesan data pribadi. Perpustakaan yang belum diaudit dapat mengungkapkan kunci dan mengancam keamanan aplikasi. Utamakan dependensi yang telah diperiksa secara menyeluruh dan berfokus pada keamanan untuk menjaga kerahasiaan dan integritas data.
Selalu verifikasi bukti dari TEE
Pengguna yang berinteraksi dengan TEE harus memverifikasi bukti jarak jauh atau mekanisme verifikasi yang dihasilkan oleh TEE untuk memastikan interaksi yang aman dan dapat dipercaya. Tanpa pemeriksaan ini, server dapat memanipulasi respons, sehingga sulit untuk membedakan antara output TEE yang sebenarnya dan data yang telah dimanipulasi. Bukti jarak jauh menyediakan bukti kunci untuk kode dan konfigurasi yang berjalan di dalam TEE, dan kita dapat menggunakan bukti jarak jauh ini untuk menentukan apakah program yang dieksekusi di dalam TEE sesuai dengan yang diharapkan.
Bukti konkret dapat diverifikasi di rantai (IntelSGX, AWSNitro), menggunakan bukti ZK (IntelSGX, AWSNitro) untuk verifikasi di luar rantai, atau dapat diverifikasi oleh pengguna sendiri atau layanan host (seperti t16z atau MarlinHub).
3. Saran Berdasarkan Kasus Penggunaan
Berdasarkan kasus penggunaan dan struktur aplikasi, petunjuk berikut mungkin membantu membuat aplikasi Anda lebih aman.
Pastikan selalu melakukan interaksi pengguna dengan TEE melalui saluran yang aman
Server yang di dalam TEE pada dasarnya tidak dapat dipercaya. Server dapat mengintersep dan mengubah komunikasi. Dalam beberapa kasus, membaca data tanpa mengubahnya mungkin dapat diterima, tetapi dalam kasus lain, bahkan membaca data saja mungkin tidak diinginkan. Untuk mengurangi risiko ini, sangat penting untuk membangun saluran enkripsi end-to-end yang aman antara pengguna dan TEE. Setidaknya, pastikan pesan mencakup tanda tangan untuk memverifikasi keasliannya dan sumbernya. Selain itu, pengguna perlu selalu memeriksa bukti jarak jauh yang diberikan oleh TEE untuk memastikan bahwa mereka berkomunikasi dengan TEE yang benar. Ini memastikan integritas dan kerahasiaan komunikasi.
Misalnya, Oyster dapat mendukung penerbitan TLS yang aman dengan menggunakan catatan CAA dan RFC8657. Selain itu, itu juga menyediakan protokol TLS asli bernama Scallop, yang tidak bergantung pada WebPKI.
Mengetahui bahwa TEE memori adalah transient
Memori TEE adalah transient, yang berarti saat TEE dimatikan, isinya (termasuk kunci enkripsi) akan hilang. Jika tidak ada mekanisme keamanan yang dapat menyimpan informasi ini, data penting mungkin tidak dapat diakses secara permanen, yang dapat mengakibatkan kesulitan dalam akses keuangan atau operasional.
Jaringan Komputasi Multipihak (MPC) dengan sistem penyimpanan terdesentralisasi seperti IPFS dapat digunakan sebagai solusi untuk masalah ini. Jaringan MPC membagi kunci ke beberapa node untuk memastikan tidak ada satu pun node yang memiliki kunci lengkap, sambil memungkinkan jaringan untuk membangun kembali kunci saat diperlukan. Data yang dienkripsi dengan kunci ini dapat disimpan dengan aman di IPFS.
Jika diperlukan, jaringan MPC dapat memberikan kunci ke server TEE baru yang menjalankan gambar yang sama, dengan syarat-syarat tertentu dipenuhi. Metode ini dapat memastikan elastisitas dan keamanan yang kuat, sehingga data tetap dapat diakses dan dirahasiakan bahkan di lingkungan yang tidak terpercaya.
![])https://img.gateio.im/social/moments-429ced8c56f3dff6c933327cf8963516(
Ada solusi lain, yaitu TEE membagi transaksi terkait ke server MPC yang berbeda, setelah itu server MPC menandatangani dan menggabungkan transaksi tersebut sebelum akhirnya ditambahkan ke blockchain. Metode ini jauh kurang fleksibel, tidak dapat digunakan untuk menyimpan kunci API, password, atau data apa pun (tanpa layanan penyimpanan pihak ketiga yang terpercaya).
![])https://img.gateio.im/social/moments-37203038abc830a2f70f702c7eeb0e7b(
Mengurangi Area Serangan
Untuk kasus penggunaan yang sangat aman, layak untuk mencoba mengurangi ketergantungan periferal sebanyak mungkin dengan mengorbankan pengalaman pengembang. Misalnya, Dstack dilengkapi dengan kernel minimal berbasis Yocto yang hanya berisi modul yang diperlukan untuk fungsi Dstack. Bahkan layak untuk menggunakan teknologi lama seperti SGX (lebih dari TDX) karena teknologi tersebut tidak memerlukan bootloader atau sistem operasi menjadi bagian dari TEE.
Isolasi Fisik
Dengan mengisolasi fisik TEE dari intervensi manusia yang mungkin, keamanan TEE dapat ditingkatkan lebih lanjut. Meskipun kita dapat mempercayai pusat data untuk menyediakan keamanan fisik dengan mendukung server TEE di pusat data dan penyedia cloud, proyek seperti Spacecoin sedang mengeksplorasi alternatif yang cukup menarik - luar angkasa. Makalah SpaceTEE bergantung pada langkah-langkah keamanan seperti pengukuran momen inersia setelah peluncuran untuk memverifikasi apakah satelit mengalami deviasi yang diharapkan saat memasuki orbit.
Multiple Verifiers
Sama seperti Ethereum mengandalkan implementasi klien ganda untuk mengurangi risiko bug yang memengaruhi seluruh jaringan, multiproviders menggunakan berbagai skema implementasi TEE untuk meningkatkan keamanan dan ketahanan. Dengan menjalankan langkah-langkah komputasi yang sama di berbagai platform TEE, verifikasi ganda dapat memastikan bahwa kerentanan dalam satu implementasi TEE tidak akan membahayakan seluruh aplikasi. Meskipun pendekatan ini mensyaratkan bahwa proses komputasi bersifat deterministik, atau mendefinisikan konsensus di antara skema implementasi TEE yang berbeda dalam situasi yang tidak deterministik, namun hal ini juga memberikan keuntungan signifikan seperti isolasi kesalahan, redundansi, dan verifikasi lintas, menjadikannya pilihan yang baik untuk aplikasi yang membutuhkan jaminan keandalan.
![])https://img.gateio.im/social/moments-da3100eaa6119891428bb2346de3f57e(
Melihat ke Depan
TEE jelas telah menjadi area yang sangat menarik. Seperti disebutkan sebelumnya, di mana-mana AI dan akses konstan ke data sensitif pengguna berarti bahwa perusahaan teknologi besar seperti Apple dan NVIDIA menggunakan TEE dalam produk mereka dan menawarkan TEE sebagai bagian dari penawaran mereka.
Di sisi lain, komunitas kripto selalu sangat memperhatikan keamanan. Saat pengembang mencoba untuk memperluas aplikasi dan kasus penggunaan on-chain, kita telah melihat TEE menjadi solusi yang populer dalam memberikan keseimbangan yang tepat antara fungsionalitas dan asumsi kepercayaan. Meskipun TEE tidak seperti solusi ZK lengkap yang meminimalkan kepercayaan, kami memperkirakan TEE akan menjadi cara bagi perusahaan Web3 dan produk perusahaan teknologi besar untuk perlahan-lahan bergabung.