Panduan Pengembang untuk TEE

Apa itu TEE? Model keamanan TEE? Panduan praktik keamanan kerentanan TEE yang umum dan model keamanan TEE?

Judul Asli: “Mengamankan Aplikasi TEE: Panduan Pengembang”

Menulis: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)

Kompilasi: Shew, GodRealmX Tanah Suci

Sejak Apple mengumumkan peluncuran cloud pribadi dan NVIDIA menyediakan komputasi rahasia dalam GPU, Trusted Execution Environment (TEE) semakin populer. Jaminan kerahasiaan mereka membantu melindungi data pengguna (termasuk kunci pribadi), sementara isolasi memastikan bahwa eksekusi program yang dideploy di atasnya tidak akan dimanipulasi - baik oleh manusia, program lain, atau sistem operasi. Oleh karena itu, tidak mengherankan banyak produk di bidang Crypto x AI menggunakan TEE untuk membangunnya.

Seperti halnya dengan setiap teknologi baru, TEE sedang mengalami periode eksperimen yang optimis. Artikel ini bertujuan untuk memberikan panduan konsep dasar bagi pengembang dan pembaca umum, sehingga mereka dapat memahami apa itu TEE, model keamanan TEE, kerentanan umum, dan praktik terbaik untuk menggunakan TEE dengan aman. (Catatan: Untuk memudahkan pemahaman teks, kami dengan sengaja menggunakan istilah yang lebih sederhana sebagai pengganti istilah TEE).

Apa itu TEE

TEE adalah lingkungan isolasi di prosesor atau pusat data di mana program dapat berjalan tanpa gangguan dari bagian lain dari sistem. Untuk menghindari gangguan dari bagian lain, kita memerlukan serangkaian desain, termasuk kontrol akses yang ketat, yaitu mengendalikan akses bagian lain sistem ke program dan data di dalam TEE. Saat ini, TEE tersebar luas di ponsel, server, PC, dan lingkungan cloud, sehingga sangat mudah diakses dan terjangkau.

Konten di atas mungkin terdengar samar dan abstrak, namun cara implementasi TEE oleh server dan penyedia awan yang berbeda berbeda, tetapi tujuannya mendasar adalah untuk menghindari TEE terganggu oleh program lain.

Sebagian besar pembaca mungkin akan menggunakan informasi biometrik untuk login ke perangkat, seperti membuka kunci sidik jari di ponsel. Tetapi bagaimana kita memastikan bahwa 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 memperbolehkan program apa pun mengakses area memori dan pemroses yang digunakan oleh data sensitif.

Dompet keras adalah contoh lain dari skenario aplikasi TEE. Dompet keras terhubung ke komputer dan berkomunikasi dengannya dalam mode sandbox, tetapi komputer tidak dapat mengakses kata-kata pemulihan yang disimpan di dalam memori dompet keras secara langsung. Dalam kedua kasus tersebut, pengguna mempercayai produsen perangkat dapat merancang chip dengan benar dan menyediakan pembaruan firmware yang sesuai untuk mencegah data rahasia di dalam TEE diekspor atau dilihat.

Model Keamanan

Sayangnya, ada banyak jenis implementasi TEE, dan implementasi-implementasi yang berbeda (Intel SGX, Intel TDX, AMD SEV, AWS Nitro Enclaves, ARM TrustZone) ini memerlukan pemodelan dan analisis model keamanan yang independen. Di bagian selanjutnya dalam artikel ini, kita akan membahas terutama Intel SGX, TDX, dan AWS Nitro, karena sistem-sistem TEE ini memiliki lebih banyak pengguna dan juga memiliki alat pengembangan yang lengkap dan tersedia. Sistem-sistem tersebut juga merupakan sistem-sistem TEE yang paling umum digunakan dalam Web3.

Secara umum, alur kerja aplikasi yang dideploy di TEE adalah sebagai berikut:

1. ‘Pengembang’ telah menulis beberapa kode, kode ini mungkin sudah open source atau mungkin tidak
2. Kemudian, pengembang akan mengemas kode ke dalam file gambar Enclave (EIF), yang dapat dijalankan di TEE.
3. EIF di-host di server yang dilengkapi dengan sistem TEE. Dalam beberapa kasus, pengembang dapat langsung menggunakan komputer pribadi yang dilengkapi dengan TEE untuk meng-host EIF dan menyediakan layanan ke luar.
4. Pengguna dapat berinteraksi dengan aplikasi melalui antarmuka yang telah ditentukan sebelumnya.

Tampaknya ada 3 risiko potensial di sini:

• Pengembang: Apa fungsi dari kode yang digunakan untuk mempersiapkan EIF? Kode EIF mungkin tidak sesuai dengan logika bisnis yang diumumkan oleh pihak proyek, dan mungkin dapat mencuri data privasi pengguna.
• Server: Apakah file EIF pada TEE server berjalan sesuai yang diharapkan? Atau apakah EIF benar-benar dieksekusi di dalam TEE? Server juga mungkin menjalankan program lain di dalam TEE
• Pemasok: Apakah desain TEE dari TEE aman? Apakah ada pintu belakang yang akan membocorkan semua data TEE kepada pemasok?

Beruntungnya, TEE sekarang memiliki solusi untuk menghilangkan risiko di atas, yaitu konstruksi ulang yang dapat diulang (Reproducible Builds) dan sertifikasi jarak jauh (Remote Atteststations).

Jadi apa itu pembangunan ulang yang dapat diulang? Pengembangan perangkat lunak modern sering kali melibatkan impor dependensi yang besar, seperti alat, pustaka, atau kerangka kerja eksternal, dll. File dependensi ini juga dapat memiliki risiko. Sekarang, solusi seperti npm menggunakan hash kode dari file dependensi sebagai identitas unik. Ketika npm menemukan file dependensi yang tidak cocok dengan nilai hash yang tercatat, maka dapat diasumsikan bahwa file dependensi tersebut telah diubah.

Sementara konstruksi yang dapat diulang dapat dianggap sebagai seperangkat standar, tujuannya adalah ketika kode apa pun berjalan pada setiap perangkat, selama dibangun sesuai dengan prosedur yang telah ditentukan sebelumnya, akhirnya akan menghasilkan nilai hash yang konsisten. Tentu saja, dalam praktiknya, kita juga dapat menggunakan produk di luar hash sebagai pengidentifikasi, di sini kita sebut sebagai pengukuran kode (pengukuran kode).

Nix adalah alat umum untuk build berulang. Ketika kode sumber program tersedia untuk umum, siapa pun dapat memeriksa kode untuk memastikan pengembang tidak memasukkan sesuatu yang luar biasa, dan siapa pun dapat membangun kode menggunakan Nix untuk memeriksa apakah produk yang dibangun memiliki metrik kode yang sama dengan produk yang digunakan oleh tim proyek dalam produksi / hash. 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 yang Dipercayai), yang berisi nilai pengukuran kode program, versi platform TEE, dan lain sebagainya. Bukti jarak jauh memungkinkan pengamat eksternal mengetahui bahwa suatu program sedang dieksekusi di lokasi yang aman dan tidak dapat diakses oleh siapa pun (TEE versi xx yang sebenarnya).

!

Dengan konstruksi yang dapat diulangi dan bukti jarak jauh, pengguna mana pun dapat mengetahui kode sebenarnya yang berjalan di dalam TEE dan informasi versi platform TEE, sehingga mencegah pengembang atau server yang jahat.

Namun, dalam kasus TEE, selalu harus mempercayai pemasoknya. Jika pemasok TEE berbuat jahat, mereka dapat dengan langsung memalsukan bukti jarak jauh. Oleh karena itu, jika mempertimbangkan pemasok sebagai potensi media serangan, sebaiknya menghindari ketergantungan hanya pada TEE, lebih baik menggabungkannya dengan ZK atau protokol konsensus.

Pesona TEE

Menurut pandangan kami, fitur TEE yang sangat populer, terutama dalam hal kemudahan implementasi pada AI Agent, terutama karena beberapa alasan berikut:

• Performa: TEE dapat menjalankan model LLM dengan performa dan biaya yang mirip dengan server biasa. Sedangkan zkML membutuhkan daya komputasi yang besar untuk menghasilkan bukti zk dari LLM.
• Dukungan GPU: NVIDIA menyediakan dukungan komputasi TEE dalam serinya GPU terbaru (Hopper, Blackwell, dll)
• Keakuratan : LLMs bersifat non-deterministik; input berulang 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 TEE tidak dapat dimanipulasi oleh penjahat, program di dalam TEE selalu berjalan sesuai dengan cara yang ditulis, ini membuat TEE lebih cocok untuk menjamin kehandalan hasil penalaran LLM daripada opML atau konsensus
• Kerahasiaan: Data di TEE tidak terlihat oleh program eksternal. Oleh karena itu, kunci privat yang dihasilkan atau diterima di TEE selalu aman. Fitur ini dapat digunakan untuk memastikan kepada pengguna bahwa pesan yang ditandatangani oleh kunci tersebut berasal dari program internal TEE. Pengguna dapat dengan yakin menitipkan kunci privat ke TEE dan mengatur beberapa kondisi tanda tangan, serta memastikan bahwa tanda tangan dari TEE sesuai dengan kondisi tanda tangan yang telah ditetapkan sebelumnya.
• Koneksi Jaringan: Program yang berjalan di TEE dapat dengan aman mengakses internet melalui beberapa alat (tanpa mengungkapkan kueri atau respons kepada server yang tidak berjalan pada TEE, sambil tetap memberikan jaminan pengambilan data yang benar untuk pihak ketiga). Ini sangat berguna untuk mengambil informasi dari API pihak ketiga dan dapat digunakan untuk outsourcing komputasi ke penyedia model yang tepercaya tetapi eksklusif.
• Hak Tulis: Berlawanan dengan skema zk, kode yang berjalan di TEE dapat membangun pesan (baik itu tweet atau transaksi) dan mengirimkannya melalui API dan jaringan RPC.
• Pengembang Ramah: Kerangka dan SDK terkait TEE memungkinkan orang menulis kode dalam bahasa apa pun dan dengan mudah mendeploy program ke TEE seperti di server cloud

Baik atau buruk, saat ini sangat sulit menemukan solusi pengganti untuk banyak kasus penggunaan TEE. Kami percaya bahwa pengenalan TEE telah memperluas ruang pengembangan aplikasi berantai, yang mungkin mendorong munculnya skenario aplikasi baru.

TEE bukanlah perak ajaib

**Program yang berjalan di TEE masih rentan terhadap berbagai serangan dan bug. Sama seperti kontrak pintar, mereka rentan terhadap berbagai masalah. Demi kesederhanaan, kami telah mengkategorikan kemungkinan kerentanan sebagai berikut:

• Kesalahan pengembang
• Kerentanan waktu jalan
• Kekurangan Desain Arsitektur
• Masalah Operasional

Kesalahan Pengembang

Baik disengaja maupun tidak disengaja, pengembang dapat melemahkan jaminan keamanan program dalam TEE melalui kode yang disengaja maupun tidak disengaja. Ini termasuk:

• Kode Tidak Transparan: Model keamanan TEE bergantung pada verifikasi eksternal. Transparansi kode sangat penting untuk verifikasi pihak ketiga eksternal. Ada masalah dengan metrik kode: Meskipun kode bersifat publik, jika tidak ada pihak ketiga yang membangun kembali kode dan memeriksa metrik kode dalam pengesahan jarak jauh, lalu periksa terhadap metrik kode yang disediakan dalam pengesahan jarak jauh. Ini mirip dengan menerima pengesahan zk tetapi tidak memverifikasinya.
• Kode yang tidak aman: Meskipun Anda dengan hati-hati menghasilkan dan mengelola kunci dengan benar di TEE, logika yang terkandung dalam kode dapat bocor ke dalam kunci dalam TEE selama pemanggilan eksternal. Selain itu, kode juga dapat mengandung pintu belakang atau kerentanan. Dibandingkan dengan pengembangan backend tradisional, ini membutuhkan standar tinggi dalam proses pengembangan dan audit perangkat lunak, mirip dengan pengembangan kontrak pintar. Serangan rantai pasokan: Pengembangan perangkat lunak modern menggunakan banyak kode pihak ketiga. **Serangan rantai pasokan menimbulkan ancaman signifikan terhadap integritas TEE. **

Kerentanan Waktu Eksekusi

Pengembang, meskipun hati-hati, masih dapat menjadi korban kerentanan saat runtime. Pengembang harus mempertimbangkan dengan cermat apakah salah satu dari hal berikut ini akan memengaruhi jaminan keamanan proyek mereka:

• Kode Dinamis: Tidak selalu mungkin menjaga semua kode tetap transparan. Kadang-kadang, kasus pengguna itu sendiri memerlukan eksekusi dinamis saat runtime dari kode opak yang dimuat ke dalam TEE. Jenis kode seperti ini rentan terhadap kebocoran informasi rahasia atau pelanggaran invarian, sehingga harus dijaga dengan sangat hati-hati untuk mencegah situasi semacam itu.
• Data Dinamis: Sebagian besar aplikasi menggunakan API eksternal dan sumber data lainnya saat berjalan. Model keamanan diperluas untuk mencakup sumber data ini, yang berada pada posisi yang sama dengan orakel dalam DeFi, di mana data yang tidak akurat atau usang dapat menyebabkan bencana. Misalnya, dalam kasus penggunaan AI Agent, terlalu bergantung pada layanan LLM seperti Claude.
• Komunikasi yang tidak aman dan tidak stabil: TEE perlu dijalankan di dalam server yang berisi komponen TEE. Dari sudut pandang keamanan, menjalankan server TEE sebenarnya adalah perantara sempurna (MitM) antara TEE dan interaksi eksternal. Server tidak hanya dapat mengintip koneksi eksternal TEE dan melihat konten yang sedang dikirim, tetapi juga dapat memeriksa IP tertentu, membatasi koneksi, dan menyuntikkan paket data ke 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 membuang, menunda, atau mengutamakan berdasarkan alamat IP sumber paket data.

kelemahan arsitektur

Teknologi yang digunakan dalam stack aplikasi TEE harus diperhatikan dengan hati-hati. Berikut adalah masalah yang mungkin muncul saat membangun aplikasi TEE:

• Aplikasi dengan Luas Serangan yang Lebih Besar: Luas serangan aplikasi merujuk pada jumlah modul kode yang harus dijamin keamanannya. Kode dengan luas serangan yang lebih besar sangat sulit untuk diaudit dan mungkin menyembunyikan bug atau kerentanan yang dapat dieksploitasi. Hal ini sering kali bertentangan dengan pengalaman pengembang. Misalnya, program TEE yang bergantung pada Docker memiliki luas serangan yang jauh lebih besar dibandingkan dengan program TEE yang tidak bergantung pada Docker. Enklaf yang bergantung pada sistem operasi yang matang memiliki luas serangan yang lebih besar dibandingkan dengan program TEE yang menggunakan sistem operasi yang sangat ringan.
• Portabilitas dan Aktivitas: Dalam Web3, aplikasi harus tahan terhadap sensor. Siapa pun dapat memulai TEE dan mengambil alih peserta sistem yang tidak aktif, dan membuat aplikasi dalam TEE dapat dipindahkan. Tantangan terbesar di sini adalah portabilitas kunci. Beberapa sistem TEE memiliki mekanisme derivasi kunci, tetapi begitu menggunakan mekanisme derivasi kunci dalam TEE, maka server lain tidak dapat menghasilkan kunci internal program TEE secara lokal, ini membuat program TEE biasanya terbatas hanya pada satu mesin, 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 merupakan milik Agent tersebut? Jika hal ini tidak dirancang dengan baik, maka akar kepercayaan yang sebenarnya mungkin berasal dari pihak ketiga eksternal atau platform penyimpanan kunci, bukan TEE itu sendiri.

Masalah Operasional

Terakhir tetapi tidak paling tidak penting adalah beberapa hal yang perlu diperhatikan tentang bagaimana menjalankan server yang benar-benar menjalankan program TEE:

• Versi platform yang tidak aman: Platform TEE kadang-kadang menerima pembaruan keamanan, yang akan tercermin dalam versi platform pada bukti jarak jauh. Jika TEE Anda tidak berjalan di atas versi platform yang aman, penyerang dapat menggunakan media serangan yang diketahui untuk mencuri kunci dari TEE. Yang lebih buruk lagi, TEE Anda mungkin berjalan di atas versi platform yang aman hari ini, tapi besok bisa menjadi tidak aman.
• Tidak Ada Keamanan Fisik: Meskipun Anda telah berusaha sebaik mungkin, TEE mungkin rentan terhadap serangan sisi, yang biasanya memerlukan akses fisik dan kontrol ke server di mana TEE berada. Oleh karena itu, keamanan fisik merupakan lapisan pertahanan kedalaman yang penting. Konsep terkait adalah bukti awan, di mana Anda dapat membuktikan bahwa TEE berjalan di pusat data awan, sementara platform awan tersebut menawarkan jaminan keamanan fisik.

Membangun program TEE yang aman

Kami akan membagi saran kami menjadi beberapa poin berikut ini:

• Solusi yang paling aman
• Langkah pencegahan yang diperlukan
• Saran yang tergantung pada kasus penggunaan

1. Skenario paling aman: Tidak ada dependensi eksternal

Membuat aplikasi yang sangat aman mungkin melibatkan penghapusan dependensi eksternal, seperti input eksternal, API, atau layanan, sehingga mengurangi serangan. Pendekatan ini dapat memastikan aplikasi berjalan secara mandiri tanpa interaksi eksternal yang dapat merusak integritas atau keamanannya. Meskipun strategi ini mungkin membatasi keragaman fungsionalitas program, namun dapat memberikan tingkat keamanan yang sangat tinggi.

Jika model dijalankan secara lokal, maka untuk sebagian besar kasus penggunaan CryptoxAI, tingkat keamanan ini dapat dicapai.

2. Tindakan pencegahan yang diperlukan

Tidak peduli apakah aplikasi memiliki dependensi eksternal atau tidak, konten berikut diperlukan!

Memperlakukan aplikasi TEE sebagai kontrak pintar, bukan aplikasi backend; menjaga frekuensi pembaruan yang rendah, dan melakukan pengujian yang ketat.

Membangun program TEE harus sama ketatnya dengan menulis, menguji, dan memperbarui kontrak pintar. Seperti kontrak pintar, TEE berjalan di lingkungan yang sangat sensitif dan tidak dapat diubah, di mana kesalahan atau perilaku yang tidak diinginkan dapat menyebabkan konsekuensi serius, termasuk kehilangan dana secara menyeluruh. Audit menyeluruh, pengujian yang luas, dan pembaruan yang minimal dan hati-hati yang telah diaudit dengan baik sangat penting untuk memastikan integritas dan keandalan aplikasi berbasis TEE.

Memeriksa kode audit dan memeriksa pipa konstruksi

Keamanan aplikasi tidak hanya bergantung pada kode itu sendiri, tetapi juga bergantung pada alat yang digunakan selama 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 selama proses pembangunan.

Untuk mengurangi risiko, kode harus diuji dan diaudit secara ketat untuk menghilangkan kesalahan dan mencegah kebocoran informasi yang tidak perlu. Selain itu, pembangunan ulang yang dapat diulang memainkan peran penting, terutama ketika kode dikembangkan oleh satu pihak dan digunakan oleh pihak lain. Pembangunan ulang yang dapat diulang memungkinkan siapa pun memverifikasi apakah program yang dijalankan di dalam TEE cocok dengan kode sumber asli, sehingga memastikan transparansi dan kepercayaan. Jika tidak ada pembangunan ulang yang dapat diulang, hampir tidak mungkin untuk menentukan konten program yang dijalankan di dalam TEE dengan tepat, yang dapat membahayakan keamanan aplikasi.

Misalnya, kode sumber untuk DeepWorm (proyek yang menjalankan model simulasi otak cacing dalam TEE) sepenuhnya open source. Pelaksana dalam TEE dibangun secara reproduktif menggunakan pipa Nix.

Menggunakan perpustakaan yang telah diaudit atau diverifikasi

Saat menangani data sensitif dalam program TEE, gunakan hanya pustaka yang diaudit untuk manajemen kunci dan pemrosesan data pribadi. Library yang tidak diaudit dapat mengekspos kunci dan membahayakan keamanan aplikasi. Prioritaskan dependensi yang diperiksa dengan baik dan berfokus pada keamanan untuk menjaga kerahasiaan dan integritas data Anda.

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 tidak dapat membedakan output TEE yang sebenarnya dan data yang telah dimanipulasi. Bukti jarak jauh menyediakan bukti penting untuk kode-kode yang berjalan di TEE dan konfigurasi, kita dapat menilai konsistensi dari program yang dijalankan di dalam TEE berdasarkan bukti jarak jauh tersebut.

Bukti konkret dapat diverifikasi di rantai (IntelSGX, AWSNitro), diverifikasi di luar rantai dengan menggunakan bukti ZK (IntelSGX, AWSNitro), atau diverifikasi oleh pengguna sendiri atau layanan hosting (seperti t16z atau MarlinHub).

3. Rekomendasi yang Bergantung pada Kasus Penggunaan

Berikut adalah beberapa tips yang mungkin membantu membuat aplikasi Anda lebih aman berdasarkan kasus penggunaan dan strukturnya.

Pastikan selalu melakukan interaksi pengguna dengan TEE melalui saluran aman

Server tempat TEE berada secara inheren tidak tepercaya. Server dapat mencegat dan memodifikasi komunikasi. Dalam beberapa kasus, mungkin dapat diterima bagi server untuk membaca data tanpa mengubahnya, sementara di tempat lain, mungkin tidak disarankan untuk membaca data bahkan jika itu tidak diinginkan. Untuk mengurangi risiko ini, sangat penting untuk memiliki saluran terenkripsi end-to-end yang aman antara pengguna dan TEE. Paling tidak, pastikan bahwa pesan tersebut berisi tanda tangan untuk memverifikasi keaslian dan asalnya. Selain itu, pengguna harus selalu memeriksa bahwa TEE memberikan pengesahan jarak jauh untuk memverifikasi 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, ia juga menyediakan protokol TLS TEE asli bernama Scallop yang tidak bergantung pada WebPKI.

Mengetahui bahwa memori TEE adalah transient

Memori TEE bersifat transien, yang berarti ketika TEE ditutup, kontennya (termasuk kunci enkripsi) akan hilang. Jika tidak ada mekanisme keamanan yang dapat digunakan untuk menyimpan informasi ini, data penting dapat menjadi tidak dapat diakses secara permanen, yang dapat mengakibatkan kesulitan dalam akses dana atau operasional.

Jaringan Komputasi Multi-Pihak (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 memegang kunci lengkap, sambil memungkinkan jaringan untuk membangun kembali kunci saat diperlukan. Data yang dienkripsi dengan kunci ini dapat disimpan secara aman di IPFS.

Jika diperlukan, jaringan MPC dapat memberikan kunci ke server TEE baru yang menjalankan gambar yang sama, asalkan kondisi tertentu terpenuhi. Pendekatan ini memastikan ketahanan dan keamanan yang kuat, menjaga data dapat diakses dan rahasia bahkan di lingkungan yang tidak tepercaya.

Masih ada solusi lain, yaitu TEE memberikan transaksi terkait ke server MPC yang berbeda secara terpisah, server MPC menandatangani transaksi tersebut secara terpisah dan kemudian melakukan agregat tanda tangan sebelum transaksi akhirnya diunggah ke rantai. Metode ini jauh lebih tidak fleksibel dan tidak dapat digunakan untuk menyimpan kunci API, kata sandi, atau data apa pun (tanpa layanan penyimpanan pihak ketiga yang terpercaya).

Mengurangi area serangan

Untuk kasus penggunaan yang kritis untuk keamanan, layak untuk mencoba mengurangi ketergantungan perangkat keras 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 ini tidak memerlukan bootloader atau sistem operasi untuk menjadi bagian dari TEE.

Isolasi Fisik

**Keamanan TEE dapat lebih ditingkatkan dengan mengisolasi mereka secara fisik dari kemungkinan intervensi manusia. **Meskipun kami dapat mempercayai bahwa pusat data dapat memberikan keamanan fisik dengan menghosting server TEE di pusat data dan penyedia cloud. Tetapi proyek-proyek seperti Spacecoin sedang mengeksplorasi alternatif yang agak menarik – ruang angkasa. Makalah SpaceTEE mengandalkan langkah-langkah keamanan, seperti mengukur momen inersia setelah peluncuran, untuk memverifikasi bahwa satelit menyimpang dari harapan selama masuk ke orbit.

Pemegang bukti ganda

Seperti Ethereum yang mengandalkan implementasi klien yang berbeda untuk mengurangi risiko bug yang mempengaruhi seluruh jaringan, multiprovers menggunakan berbagai skema implementasi TEE yang berbeda untuk meningkatkan keamanan dan keuletan. Dengan menjalankan langkah-langkah komputasi yang sama di berbagai platform TEE, verifikasi multipel memastikan bahwa kerentanan dalam salah satu implementasi TEE tidak akan membahayakan seluruh aplikasi. Meskipun metode ini membutuhkan alur komputasi yang deterministik, atau kesepakatan antara berbagai skema implementasi TEE dalam kasus ketidakdeterministik, metode ini juga menawarkan keuntungan signifikan seperti isolasi kesalahan, redundant, dan verifikasi silang, menjadikannya pilihan yang baik untuk aplikasi yang membutuhkan jaminan keandalan.

Melihat ke Depan

TEE jelas telah menjadi bidang yang sangat menarik. Seperti yang sudah disebutkan sebelumnya, kehadiran AI dan akses berkelanjutan ke data sensitif pengguna berarti perusahaan teknologi besar seperti Apple dan NVIDIA menggunakan TEE dalam produk mereka dan menyediakannya sebagai bagian dari produk mereka.

Di sisi lain, komunitas kripto selalu sangat memperhatikan keamanan. Saat pengembang mencoba untuk memperluas aplikasi dan kasus penggunaan di atas rantai, kita telah melihat TEE menjadi populer sebagai solusi yang menawarkan keseimbangan yang tepat antara fungsi dan asumsi kepercayaan. Meskipun TEE tidak meminimalkan kepercayaan seperti solusi ZK yang lengkap, kami memperkirakan TEE akan menjadi cara pertama yang perlahan mencampurkan produk perusahaan Web3 dan perusahaan teknologi besar.