Apple, özel bulutunu duyurduğu ve NVIDIA'nın GPU'da gizli hesaplama sağladığından beri Güvenli Yürütme Ortamı (TEE) giderek popüler hale geliyor. Onların gizlilik garantisi, kullanıcı verilerinin (özel anahtarlar dahil olabilir) korunmasına yardımcı olurken, izolasyon, üzerinde çalışan programların insanlar, diğer programlar veya işletim sistemleri tarafından değiştirilmesini önler. Bu nedenle, Crypto x AI alanında TEE'yi kullanarak ürünler inşa etmek şaşırtıcı değildir.
Herhangi bir yeni teknoloji gibi, TEE umut verici bir deneyim sürecinden geçiyor. Bu makale, geliştiriciler ve genel okuyucular için temel kavram rehberi sağlayarak, TEE'nin ne olduğunu, TEE'nin güvenlik modelini, yaygın hataları ve TEE'yi güvenli bir şekilde kullanmanın en iyi uygulama yöntemlerini anlamalarını sağlamayı ummaktadır. （Not：Metni anlaşılır kılmak için TEE terimlerinin daha basit eş anlamlılarıyla bilinçli olarak değiştirilmiştir).
TEE Nedir
TEE, işlemci veya veri merkezindeki izole bir ortamdır, burada programlar herhangi bir sistem müdahalesi olmadan çalışabilir. TEE'nin diğer kısımlar tarafından müdahale edilmemesi için sıkı bir erişim kontrolü dizisi gereklidir, yani sistem diğer kısımlarının TEE içindeki programlara ve verilere erişimini kontrol etmelidir. Şu anda TEE, cep telefonları, sunucular, PC'ler ve bulut ortamlarında yaygın olarak bulunmaktadır, bu nedenle oldukça erişilebilir ve uygun fiyatlıdır.
Yukarıdaki içerik muhtemelen belirsiz ve soyut gelebilir, aslında farklı sunucuların ve bulut sağlayıcıların TEE'yi uygulama şekilleri farklı olabilir, ancak temel amaçları TEE'nin diğer programlar tarafından engellenmesini önlemektir.
Çoğu okuyucu, parmak iziyle telefonu kilitlemek gibi biyometrik bilgileri kullanarak cihaza giriş yapabilir. Ancak kötü niyetli uygulamaların, web sitelerinin veya jailbreak işletim sistemlerinin bu biyometrik bilgilere erişmesini ve çalmasını nasıl önleyebiliriz? Aslında, verileri şifrelemenin yanı sıra, TEE cihazındaki devre, hassas verilerin kullandığı bellek ve işlemci alanına herhangi bir programın erişmesine izin vermez.
Donanım cüzdanı, TEE uygulama senaryosunun başka bir örneğidir. Donanım cüzdanı bilgisayara bağlanır ve onunla sandbox olarak iletişim kurar, ancak bilgisayar doğrudan donanım cüzdanında depolanan hatırlatıcı kelimelere erişemez. Yukarıdaki iki durumda da kullanıcılar, cihaz üreticisinin çipin doğru bir şekilde tasarlandığına ve TEE içindeki gizli verilerin ihraç edilmesini veya görüntülenmesini önlemek için uygun firmware güncellemelerini sağlayabileceğine inanır.
Güvenlik modeli
Maalesef, TEE'nin birçok farklı uygulama şekli vardır ve bu farklı uygulamaların (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) bağımsız güvenlik modelleme analizine ihtiyacı vardır. Bu makalenin geri kalanında, IntelSGX, TDX ve AWSNitro'yu ele alacağız çünkü bu TEE sistemleri daha fazla kullanıcıya sahip ve tam kullanılabilirlik sağlayan geliştirme araçlarına sahiptir. Yukarıdaki sistemler aynı zamanda Web3 içinde en yaygın olarak kullanılan TEE sistemleridir.
Genellikle, TEE'de dağıtılan uygulamanın iş akışı aşağıdaki gibi olur:
“Geliştiriciler” bazı kodlar yazdı, bu kodlar açık kaynak olabilir veya olmayabilir
Geliştirici daha sonra kodu Enclave görüntü dosyasına (EIF) paketler, bu dosya TEE'de çalıştırılabilir.
EIF, belirli durumlarda, geliştiricilerin hizmet sunmak için doğrudan TEE'ye sahip kişisel bilgisayarlarında EIF'i barındırabileceği bir TEE sistemi olan bir sunucuda barındırılır.
Kullanıcı önceden tanımlanmış arayüzler aracılığıyla uygulamayla etkileşimde bulunabilir.
Açıkça, burada 3 potansiyel risk var:
Geliştiriciler: EIF için hazırlanan kodun ne işe yaradığı? EIF kodu, proje sahibinin dışa dönük iş mantığına uygun olmayabilir ve kullanıcıların gizli verilerini çalabilir.
Sunucu: TEE sunucusu, beklenen EIF dosyasıyla uyumlu olarak çalışıyor mu? Veya EIF gerçekten TEE içinde mi yürütülüyor? Sunucu ayrıca TEE içinde başka programlar da çalıştırabilir.
Tedarikçi: TEE'nin tasarımı güvenli mi? TEE içindeki tüm verileri tedarikçiye sızdıran bir arka kapı var mı?
Neyse ki, şu anda TEE'nin yukarıdaki riskleri ortadan kaldırmak için bir çözümü var, yani ** tekrarlanabilir yapılar(Reproducible Builds) ve uzaktan belgelendirme(Remote Atteststations)**.
Peki, tekrarlanabilir inşa nedir? Modern yazılım geliştirme genellikle dış araçlar, kütüphaneler veya çerçeveler gibi birçok bağımlılığı içermektedir ve bu bağımlılık dosyalarında potansiyel güvenlik sorunları olabilir. Şu anda npm gibi çözümler, bağımlılık dosyalarına karşılık gelen kod özetini benzersiz bir tanımlayıcı olarak kullanmaktadır. npm, bir bağımlılık dosyasının kaydedilen özet değeriyle eşleşmediğini tespit ettiğinde, bu bağımlılık dosyasının değiştirildiğini düşünebilir.
Ve tekrarlanabilir yapılandırma, bir dizi standart olarak kabul edilebilir ve amacı, herhangi bir kodun herhangi bir cihazda çalıştığı zaman, önceden belirlenmiş bir sürece göre yapılandırıldığında sonunda tutarlı bir karma değeri elde edilebilir. Tabii ki, uygulamada, karmadan farklı ürünleri de bir tanımlayıcı olarak kullanabiliriz, bu durumda bunu kod ölçüsü olarak adlandırıyoruz(.
Nix, tekrarlanabilir şekilde oluşturulabilen yaygın bir araçtır. Bir programın kaynak kodu açıklandıktan sonra, herkes kodu kontrol edebilir ve geliştiricilerin anormal içerik ekleyip eklemediğini doğrulayabilir, herkes Nix'i kullanarak kod oluşturabilir ve oluşturulan ürünlerin, proje tarafından üretim ortamında dağıtılan ürünlerle aynı kod ölçütü/hash'e sahip olup olmadığını kontrol edebilir. Ancak TEE'de programın kod ölçüsünü nasıl bileceğiz? Bu noktada "uzaktan kanıt" olarak adlandırılan kavram devreye giriyor.
Uzak Doğrulama, programın kod ölçüleri, TEE platformunun sürümü vb. içeren, TEE platformundan (güvenilir taraf) gelen imzalı bir mesajdır. Uzak doğrulama, dış gözlemcilerin bir programın herhangi bir kişinin erişemeyeceği güvenli bir konumda (gerçek TEE'nin xx sürümü) yürütüldüğünü bilmesini sağlar.
Tekrarlanabilir yapısı ve uzaktan kanıtlama, herhangi bir kullanıcının TEE içinde çalışan gerçek kod ve TEE platformu sürüm bilgisini bilmesini sağlar, böylece geliştiricilerin veya sunucuların kötü niyetli davranışını engeller.
Ancak, TEE durumunda, tedarikçisine her zaman güvenmek gerekir. Eğer TEE tedarikçisi kötü niyetli hareket ederse, uzaktan kanıtı doğrudan sahtekarlık yapabilir. Bu nedenle, tedarikçiyi potansiyel bir saldırı aracı olarak görürseniz, yalnızca TEE'ye güvenmekten kaçının, onları en iyi şekilde ZK veya uzlaşma protokolü ile birleştirin.
TEE'nin Cazibesi
Bizim bakış açımıza göre, TEE'nin özellikle AI Agent'ın dağıtımı için uygunluğu, özellikle aşağıdaki noktalarda belirgin bir şekilde karşımıza çıkıyor:
**Performans: **TEE, LLM modelini çalıştırabilir ve performansı ve maliyet açısından normal sunucularla benzerdir. zkML ise LLM'nin zk kanıtını oluşturmak için büyük miktarda hesaplama gücü tüketir.
GPU desteği: NVIDIA'nın en yeni GPU serisinde (Hopper, Blackwell vb.) TEE hesaplama desteği sunmaktadır
Doğruluk：LLM'ler belirsizdir; aynı ipucunu defalarca girdiğinizde farklı sonuçlar elde edersiniz. Bu nedenle, birden fazla düğüm (sahtekarlık kanıtları oluşturmaya çalışan gözlemciler dahil) asla LLM'nin çalışma sonuçlarında uzlaşmaya varamayabilir. Bu senaryoda, TEE'de çalışan LLM'nin kötü niyetli kişiler tarafından manipüle edilemeyeceğine güvenebiliriz, TEE içindeki program her zaman yazıldığı şekilde çalışır, bu da TEE'nin opML'den veya uzlaşıdan daha uygun olmasını sağlar LLM çıkarım sonuçlarının güvenilirliğini sağlamak için
Gizlilik: TEE'deki veriler dış programlar tarafından görünmez. Bu nedenle, TEE'de oluşturulan veya alınan özel anahtarlar her zaman güvendedir. Bu özellik, kullanıcılara, bu anahtarın imzaladığı herhangi bir mesajın TEE'nin iç programlarından geldiğini garanti etmek için kullanılabilir.Kullanıcılar özel anahtarlarını TEE'ye emanet edip bazı imza koşulları belirleyebilir ve TEE'den gelen imzanın önceden belirlenmiş imza koşullarına uygun olup olmadığını doğrulayabilirler
Bağlantı: TEE'de çalışan bir programın, internete güvenli bir şekilde erişmesini sağlayan araçlar kullanarak (TEE'de çalışan sunucuya sorgu veya yanıt verilmeden, üçüncü taraflara doğru veri alınmasını sağlarken) üçüncü taraf API'lerden bilgi almak için oldukça faydalıdır. Bu, güvenilir ancak özel bir model sağlayıcısına hesaplamayı dış kaynak olarak vermekte kullanılabilir.
Yazma izni: Zk şemasının aksine, TEE'de çalışan kodlar mesajlar oluşturabilir (hem tweetler hem de işlemler) ve bunları API ve RPC ağına gönderebilir.
Geliştirici dostu: TEE ile ilgili çerçeve ve SDK'lar, insanların herhangi bir dilde kod yazmalarına izin verir ve programları TEE'ye kolayca dağıtmalarını sağlar, sanki bulutta sunucuda çalışıyormuş gibi
İyi ya da kötü, şu anda TEE'nin kullanım alanlarının çoğu için alternatif bulmak oldukça zor. TEE'nin tanıtılmasının, şu anda blok zinciri uygulamalarının geliştirme alanını daha da genişlettiğine inanıyoruz, bu da yeni uygulama senaryolarının ortaya çıkmasını tetikleyebilir.
TEE bir gümüş mermi değildir
TEE'de çalışan programlar hala bir dizi saldırıya ve hataya maruz kalma riskine sahiptir. Akıllı sözleşmeler gibi, onlar da çeşitli sorunlarla karşılaşabilirler. Basitlik açısından, olası güvenlik açıklıklarını aşağıdaki gibi sınıflandıracağız:
Geliştirici dikkatsizlik
Çalışma zamanı açığı
Mimarlık tasarım kusuru
Operasyon sorunu
Geliştiricinin dikkatsizliği
Geliştiriciler, kasıtlı veya kasıtsız olarak, TEE'deki programların güvenlik güvencelerini kasıtlı veya kasıtsız olarak zayıflatabilirler. Bu şunları içerir:
Opaque Code: The security model of the TEE depends on external verifiability. The transparency of the code is crucial for external third-party verification.
Kod ölçümünde bir sorun var: Kod açık olsa bile, kod ölçümleri tekrar yapılmadan ve uzaktan kanıtlardaki kod ölçüm değerlerini kontrol etmeden ve uzaktan kanıtlarda sağlanan kod ölçümlerine dayanarak kontrol edilmez. Bu, zk kanıtını almak ancak doğrulamamak gibi bir şeye benzer.
Güvensiz kodlar: TEE içindeki anahtarları doğru bir şekilde oluşturup yönetseniz bile, kod içindeki mantık, dışarıdan çağrıldığında TEE içindeki anahtarları sızdırabilir. Ayrıca, kodda arka kapılar veya açıklar olabilir. Geleneksel arka uç geliştirme ile karşılaştırıldığında, yazılım geliştirme ve denetleme sürecinin yüksek standartlara sahip olması gerekmektedir, akıllı sözleşme geliştirme ile benzerlik gösterir.
Tedârik Zinciri Saldırısı: Modern yazılım geliştirme süreci büyük ölçüde üçüncü taraf kodlar kullanır. Tedârik zinciri saldırıları, TEE'nin bütünlüğüne büyük bir tehdit oluşturur.
Çalışma Zamanı Zafiyeti
Geliştiriciler, ne kadar dikkatli olursa olsun, çalışma zamanı açıklarının kurbanı olabilirler. Geliştiriciler, projelerinin güvenliğini etkileyip etkilemeyeceğini dikkatlice düşünmek zorundadır:
Dinamik Kod: Tüm kodların her zaman şeffaf olması mümkün olmayabilir. Bazen, kullanım durumu kendisi, TEE'ye yüklenen şeffaf olmayan kodun çalışma zamanında dinamik olarak yürütülmesini gerektirir. Bu tür kodlar kolayca gizli bilgileri sızdırabilir veya değişmezliği bozabilir, bu durumu önlemek için çok dikkatli olunmalıdır.
Dinamik Veriler: Çoğu uygulama, yürütme sırasında harici API'ları ve diğer veri kaynaklarını kullanır. Güvenlik modeli, bu veri kaynaklarını da içerecek şekilde genişletilir; bu veri kaynakları, DeFi'deki oraklar gibi aynı seviyededir ve yanlış veya eski veriler felakete yol açabilir. Örneğin, AI Ajanı kullanım durumunda, Claude gibi LLM hizmetlerine aşırı bağımlılık.
Güvensiz ve istikrarsız iletişim: TEE, TEE bileşenlerini içeren sunucuda çalışmak zorundadır. Güvenlik açısından, TEE'nin çalıştığı sunucu aslında TEE ve dış dünya arasında mükemmel bir aracıdır (MitM). Sunucu, TEE'nin dış bağlantılarını gözlemleyebilir ve gönderilen içeriği inceleyebilir, belirli IP'leri denetleyebilir, bağlantıları kısıtlayabilir ve bağlantılara veri paketi enjekte edebilir, böylece bir tarafın onun xx'den geldiğini düşünmesini sağlamak için tasarlanmıştır.
Örneğin, şifreli işlemleri işleyebilen bir eşdeğer işletim ortamında (TEE), bu işletim ortamı, yönlendirici/gateway/sunucu tarafından hala paket kaynağı IP adresine göre paketleri atma, geciktirme veya önceliklendirme gibi adil sıralama garantisi (MEV direnci) sağlayamaz.
Mimari Kusur
TEE uygulamaları tarafından kullanılan teknoloji yığını konusunda dikkatli olunmalıdır. Bir TEE uygulaması oluştururken aşağıdaki sorunlar ortaya çıkabilir:
**Büyük saldırı yüzeyine sahip uygulamalar: Uygulamanın saldırı yüzeyi, tamamen güvenli olması gereken kod modülü sayısını belirtir. Büyük saldırı yüzeyine sahip kodlar çok zor denetlenebilir, hata veya kullanılabilir açıkları gizleyebilir. Bu genellikle geliştiricilerin deneyimi ile çelişir. Örneğin, Docker'a bağımlı TEE programlarına göre Docker'a bağımlı TEE programlarının saldırı yüzeyi çok daha büyüktür. En hafif işletim sistemlerine dayalı TEE programlarına göre, olgunlaşmış işletim sistemlerine dayalı Enclaves'lerin daha büyük bir saldırı yüzeyi vardır.
Taşınabilirlik ve Canlılık: Web3'te, uygulamalar sansür direncine sahip olmalıdır. Herkes TEE'yi başlatabilir ve etkin olmayan sistem katılımcılarını devralabilir ve TEE içindeki uygulamaların taşınabilir olmasını sağlayabilir. Buradaki en büyük zorluk, anahtarın taşınabilirliğidir. Bazı TEE sistemlerinde anahtar türetilme mekanizmaları bulunmaktadır, ancak bir kez TEE içindeki anahtar türetilme mekanizması kullanıldığında, diğer sunucular yerel olarak dış TEE programları içindeki anahtarları oluşturamazlar. Bu durum TEE programlarının genellikle sadece aynı makinede sınırlı kalmasına neden olur, bu da taşınabilirliği sağlamak için yetersizdir
Güvensiz Güven Kökü: Örneğin, bir TEE'de çalışan bir AI Ajanı için, belirli bir adresin bu Ajan'a ait olup olmadığını nasıl doğrulayabiliriz? Burada dikkatli bir şekilde tasarlanmazsa, gerçek güven kökü, TEE'nin kendisi yerine harici bir üçüncü taraf veya anahtar depolama platformu olabilir.
Operasyon Sorunu
Son ancak en az önemli olmayan bir nokta, TEE programını gerçekten çalıştırmak için sunucu hakkında bazı pratik dikkat edilmesi gereken noktalar vardır:
Güvensiz Platform Sürümü: TEE platformu ara sıra güvenlik güncellemeleri alır ve bu güncellemeler uzaktan kanıtlamada platform sürümü olarak yansır. Eğer TEE güvenli platform sürümünde çalışmıyorsa, hacker'lar bilinen saldırı vektörlerini kullanarak TEE'den anahtarları çalabilirler. Daha da kötüsü, TEE'niz bugün güvenli bir platform sürümünde çalışıyor olabilir, yarın ise güvensiz olabilir.
Fiziksel Güvenlik Yok: TEE'nin yan kanal saldırılarına karşı korunması gerekmektedir ve genellikle TEE'nin bulunduğu sunucuya fiziksel erişim ve kontrol gerektirir. Bu nedenle, fiziksel güvenlik önemli bir derin savunma katmanıdır. İlgili bir kavram, TEE'nin bulut veri merkezinde çalıştığını kanıtlayabileceğiniz bir bulut kanıtıdır ve bulut platformunun fiziksel güvenliği sağlar.
Güvenli TEE programı oluşturma
Önerilerimizi aşağıdaki noktalara ayırıyoruz:
En güvenli çözüm
Alınan gerekli önlemler
Kullanım durumuna bağlı öneriler
1. En güvenli çözüm: Harici bağımlılıkları yok
Yüksek güvenlikli bir uygulama oluşturmak, dış bağımlılıkları, yani harici girişleri, API'leri veya hizmetleri ortadan kaldırmak suretiyle saldırı yüzeyini azaltmayı gerektirebilir. Bu yöntem, uygulamanın bağımsız bir şekilde çalışmasını ve bütünlüğünü veya güvenliğini tehlikeye atabilecek harici etkileşimleri olmadan çalışmasını sağlar. Bu strateji, programın işlevselliğini sınırlayabileceği gibi, son derece yüksek bir güvenlik sağlayabilir.
Eğer model yerel olarak çalışıyorsa, çoğu CryptoxAI senaryosu için bu düzeyde güvenlik sağlanabilir.
2. Alınması Gereken Önlemler
Uygulamanın dış bağımlılıkları olsa da, aşağıdaki içerik gereklidir!
TEE uygulamasını bir akıllı sözleşme olarak değerlendirin, bir arka uç uygulaması değil; düşük güncelleme sıklığını ve sıkı testi koruyun.
TEE programları oluşturmak, akıllı sözleşmelerin yazılması, test edilmesi ve güncellenmesi kadar titiz olmalıdır. Akıllı sözleşmelerde olduğu gibi, TEE, yüksek hassasiyetli ve değiştirilemez bir ortamda çalışır, burada hata veya beklenmeyen davranış ciddi sonuçlara yol açabilir, bunlar arasında fonların tamamen kaybı da bulunmaktadır. TEE tabanlı uygulamaların bütünlüğünü ve güvenilirliğini sağlamak için kapsamlı bir denetim, geniş kapsamlı test ve dikkatlice denetlenmiş en az düzeyde güncelleme son derece önemlidir.
Denetim kodlarını kontrol et ve yapılandırma boru hattını kontrol et
Uygulamanın güvenliği, yalnızca kodun kendisine değil, aynı zamanda inşa sürecinde kullanılan araçlara da bağlıdır. Güvenli bir inşa boru hattı, güvenlik açıklarını önlemek için hayati önem taşır. TEE, yalnızca sağlanan kodun beklenen süreçte çalışacağını garanti eder, ancak inşa sürecinde tanıtılan hataları düzeltemez.
Riski azaltmak için, kodların sıkı bir şekilde test edilmesi ve denetlenmesi gerekmektedir, böylece hatalar ortadan kaldırılır ve gereksiz bilgi sızıntısı önlenir. Ayrıca, tekrarlanabilir yapı, özellikle kodun bir tarafça geliştirilip başka bir tarafça kullanıldığı durumlarda hayati bir rol oynamaktadır. Tekrarlanabilir yapı, TEE içinde yürütülen programların orijinal kaynak koduyla eşleşip eşleşmediğini herhangi bir kişinin doğrulamasına olanak sağlar, böylece şeffaflık ve güven sağlanır. Tekrarlanabilir yapı olmadan, TEE içinde yürütülen programın tam içeriğini belirlemek neredeyse imkansızdır ve uygulamanın güvenliğini tehlikeye atar.
Örneğin, DeepWorm (TEE'de çalışan solucan beyin simülasyon modeli projesi) 'nin kaynak kodu tamamen açıktır. TEE içindeki yürütülebilir program, yeniden üretilebilir bir şekilde Nix boru hattı kullanılarak inşa edilmiştir.
Denetlenmiş veya doğrulanmış kitaplıkları kullanın
Duyarlı verilerin TEE programında işlenmesi gerektiğinde, yalnızca denetlenmiş kütüphaneler kullanılarak anahtar yönetimi ve özel veri işleme yapılmalıdır. Denetlenmemiş kütüphaneler anahtarları açığa çıkarabilir ve uygulamanın güvenliğini tehlikeye atabilir. Verilerin gizliliğini ve bütünlüğünü korumak için güvenlik odaklı, detaylı olarak incelenmiş bağımlılıkları öncelikli olarak düşünün.
TEE'den doğrulama her zaman sağlanır
TEE ile etkileşimde bulunan kullanıcılar, güvenli ve güvenilir etkileşimi sağlamak için TEE tarafından üretilen uzaktan kanıtları veya doğrulama mekanizmalarını doğrulamalıdır. Bu kontroller olmadan sunucu yanıtlarını manipüle edebilir ve gerçek TEE çıktısını ve değiştirilmiş verileri ayırt edemez. Uzaktan kanıtlar, TEE'de çalışan kod kitaplıkları ve yapılandırmalar için kritik kanıtlar sağlar ve TEE içinde yürütülen programların beklendiği gibi olup olmadığını uzaktan kanıtlara dayanarak belirleyebiliriz.
Belgeleme, zincir dışında ZK kanıtlama (IntelSGX, AWSNitro) veya zincir üzerinde (IntelSGX, AWSNitro) gerçekleştirilebilir ve kullanıcılar tarafından veya barındırılan hizmetler (örneğin t16z veya MarlinHub) tarafından doğrulanabilir.
3. Kullanım Durumuna Bağlı Öneriler
Uygulama senaryosuna ve yapısına bağlı olarak, aşağıdaki ipuçları uygulamanızı daha güvenli hale getirmenize yardımcı olabilir.
Kullanıcıların TEE ile etkileşimde her zaman güvenli bir kanalda çalışmasını sağlayın
TEE'nin bulunduğu sunucu temelde güvenilir değildir. Sunucu iletişimi engelleyebilir ve değiştirebilir. Bazı durumlarda, sunucu verileri okuyabilir ancak değiştirmemek kabul edilebilirken, diğer durumlarda verileri okumak bile istenmeyebilir. Bu riskleri azaltmak için kullanıcılar ve TEE arasında güvenli uçtan uca şifreli bir kanalın oluşturulması son derece önemlidir. En azından, iletilerin doğruluğunu ve kaynağını doğrulamak için bir imza içerdiğinden emin olun. Ayrıca, Kullanıcıların, doğru TEE ile iletişim kurduklarını doğrulamak için TEE'nin uzaktan kanıtını kontrol etmeleri gerekir. Bu iletişimin bütünlüğünü ve gizliliğini sağlar.
Örneğin, Oyster, güvenli TLS çıkarımını desteklemek için CAA kayıtlarını ve RFC8657'yi kullanabilir. Ayrıca, WebPKI'ye bağlı olmayan Scallop adlı bir TEE yerel TLS protokolü sağlar.
Biliyorsunuz TEE belleğinin geçici olduğunu
TEE belleği geçicidir, bu da TEE kapandığında (şifreleme anahtarları dahil) içeriğin kaybolacağı anlamına gelir. Bu bilgileri saklamak için güvenli bir mekanizma olmadığında, kritik verilere erişim kalıcı olarak engellenebilir, bu da fonların veya işletmenin sıkıntıya girmesine neden olabilir.
IPFS gibi merkezi olmayan depolama sistemlerine sahip çok taraflı hesaplama (MPC) ağı, bu sorunun bir çözümü olarak kullanılabilir. MPC ağı, anahtarları birden fazla düğüme böler, tek bir düğümün tam anahtarı tutmadığından emin olurken ağın anahtarı gerektiğinde yeniden oluşturmasına izin verir. Bu anahtarla şifrelenmiş veriler güvenli bir şekilde IPFS üzerinde depolanabilir.
Gerekli olduğunda, MPC ağı, belirli koşullar sağlandığında aynı görüntüyü çalıştıran yeni bir TEE sunucusuna anahtar sağlayabilir. Bu yöntem, verilerin erişilebilirliğini ve gizliliğini güvence altına alırken, güvenilmeyen bir ortamda bile esneklik ve güçlü güvenlik sağlar.
Başka bir çözüm de şudur: TEE ilgili işlemleri farklı MPC sunucularına ayırır, MPC sunucuları imzaladıktan sonra işlemleri topluca imzalar ve işlemleri nihai olarak zincire yükler. Bu yöntemin esnekliği çok daha düşüktür, API anahtarları, şifreler veya herhangi bir veri (güvenilir üçüncü taraf depolama hizmeti olmadan) saklamak için kullanılamaz.
Güvenlik açısından kritik kullanım örnekleri için, geliştirici deneyimi pahasına çevre bağımlılıklarını mümkün olduğunca azaltmaya çalışmaktır. Örneğin, Dstack, yalnızca Dstack'in çalışması gereken modülleri içeren minimal Yocto tabanlı bir çekirdekle birlikte gelir. TEE'nin bir parçası olmak için bir önyükleyici veya işletim sistemi gerektirmediğinden, SGX (TDX üzerinden) gibi daha eski bir teknolojiyi kullanmaya bile değer olabilir.
Fiziksel izolasyon
TEE'nin fiziksel olarak müdahale edilmesini önleyerek güvenliğini daha da artırabiliriz. TEE sunucularını veri merkezlerinde veya bulut sağlayıcılarında barındırarak fiziksel güvenliği sağlayabiliriz ancak Spacecoin gibi projeler oldukça ilginç bir alternatif keşfediyor - uzay. SpaceTEE makalesi, uyduların yörüngeye giriş sürecinde sapma olup olmadığını doğrulamak için atalet momentlerinin ölçümü gibi güvenlik önlemlerine dayanıyor.
Çoklu Kanıtlayıcı
Ethereum, gibi, birçok istemci uygulamasına dayanarak, ağın tümünü etkileyebilecek hata riskini azaltmak için multiprover'ler, güvenliği ve esnekliği artırmak için farklı TEE uygulama planları kullanır. Aynı hesaplama adımlarını farklı TEE platformları üzerinde çalıştırarak, çoklu doğrulama, bir TEE uygulamasındaki bir açığın tüm uygulamayı tehlikeye atmasını önler. Bu yöntem, hesaplama sürecinin belirli olmasını veya belirsiz durumlarda farklı TEE uygulama planları arasında bir uzlaşma sağlanmasını gerektirirken, aynı zamanda hata izolasyonu, yedekleme ve çapraz doğrulama gibi önemli avantajlar sunar ve güvenilirlik garantisi gerektiren uygulamalar için iyi bir seçenek haline gelir.
TEE açıkça heyecan verici bir alan haline gelmiştir. Daha önce belirtildiği gibi, yapay zekanın evrensel olarak kullanılması ve kullanıcı hassas verilerine sürekli erişimi, Apple ve NVIDIA gibi büyük teknoloji şirketlerinin ürünlerinde TEE kullanmasını ve TEE'yi ürünlerinin bir parçası olarak sunmasını sağlamaktadır.
Öte yandan, kripto topluluğu her zaman güvenliğe büyük önem vermiştir. Geliştiricilerin zincir tabanlı uygulamaları ve kullanım durumlarını genişletmeye çalıştıkları bir dönemde, TEE'nin, işlevsellik ve güvenilirlik arasında doğru bir denge sağlamak için popüler hale geldiğini gördük. TEE, tam ZK çözümü kadar güvenilir değil olmasına rağmen, ilk kez Web3 şirketleri ve büyük teknoloji şirketlerinin ürünlerini yavaşça birleştirmesi beklenmektedir.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
TEE geliştiricileri rehberi
Yazar: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Derleme: Shew, GodRealmX
Apple, özel bulutunu duyurduğu ve NVIDIA'nın GPU'da gizli hesaplama sağladığından beri Güvenli Yürütme Ortamı (TEE) giderek popüler hale geliyor. Onların gizlilik garantisi, kullanıcı verilerinin (özel anahtarlar dahil olabilir) korunmasına yardımcı olurken, izolasyon, üzerinde çalışan programların insanlar, diğer programlar veya işletim sistemleri tarafından değiştirilmesini önler. Bu nedenle, Crypto x AI alanında TEE'yi kullanarak ürünler inşa etmek şaşırtıcı değildir.
Herhangi bir yeni teknoloji gibi, TEE umut verici bir deneyim sürecinden geçiyor. Bu makale, geliştiriciler ve genel okuyucular için temel kavram rehberi sağlayarak, TEE'nin ne olduğunu, TEE'nin güvenlik modelini, yaygın hataları ve TEE'yi güvenli bir şekilde kullanmanın en iyi uygulama yöntemlerini anlamalarını sağlamayı ummaktadır. （Not：Metni anlaşılır kılmak için TEE terimlerinin daha basit eş anlamlılarıyla bilinçli olarak değiştirilmiştir).
TEE Nedir
TEE, işlemci veya veri merkezindeki izole bir ortamdır, burada programlar herhangi bir sistem müdahalesi olmadan çalışabilir. TEE'nin diğer kısımlar tarafından müdahale edilmemesi için sıkı bir erişim kontrolü dizisi gereklidir, yani sistem diğer kısımlarının TEE içindeki programlara ve verilere erişimini kontrol etmelidir. Şu anda TEE, cep telefonları, sunucular, PC'ler ve bulut ortamlarında yaygın olarak bulunmaktadır, bu nedenle oldukça erişilebilir ve uygun fiyatlıdır.
Yukarıdaki içerik muhtemelen belirsiz ve soyut gelebilir, aslında farklı sunucuların ve bulut sağlayıcıların TEE'yi uygulama şekilleri farklı olabilir, ancak temel amaçları TEE'nin diğer programlar tarafından engellenmesini önlemektir.
Çoğu okuyucu, parmak iziyle telefonu kilitlemek gibi biyometrik bilgileri kullanarak cihaza giriş yapabilir. Ancak kötü niyetli uygulamaların, web sitelerinin veya jailbreak işletim sistemlerinin bu biyometrik bilgilere erişmesini ve çalmasını nasıl önleyebiliriz? Aslında, verileri şifrelemenin yanı sıra, TEE cihazındaki devre, hassas verilerin kullandığı bellek ve işlemci alanına herhangi bir programın erişmesine izin vermez.
Donanım cüzdanı, TEE uygulama senaryosunun başka bir örneğidir. Donanım cüzdanı bilgisayara bağlanır ve onunla sandbox olarak iletişim kurar, ancak bilgisayar doğrudan donanım cüzdanında depolanan hatırlatıcı kelimelere erişemez. Yukarıdaki iki durumda da kullanıcılar, cihaz üreticisinin çipin doğru bir şekilde tasarlandığına ve TEE içindeki gizli verilerin ihraç edilmesini veya görüntülenmesini önlemek için uygun firmware güncellemelerini sağlayabileceğine inanır.
Güvenlik modeli
Maalesef, TEE'nin birçok farklı uygulama şekli vardır ve bu farklı uygulamaların (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) bağımsız güvenlik modelleme analizine ihtiyacı vardır. Bu makalenin geri kalanında, IntelSGX, TDX ve AWSNitro'yu ele alacağız çünkü bu TEE sistemleri daha fazla kullanıcıya sahip ve tam kullanılabilirlik sağlayan geliştirme araçlarına sahiptir. Yukarıdaki sistemler aynı zamanda Web3 içinde en yaygın olarak kullanılan TEE sistemleridir.
Genellikle, TEE'de dağıtılan uygulamanın iş akışı aşağıdaki gibi olur:
Açıkça, burada 3 potansiyel risk var:
Neyse ki, şu anda TEE'nin yukarıdaki riskleri ortadan kaldırmak için bir çözümü var, yani ** tekrarlanabilir yapılar(Reproducible Builds) ve uzaktan belgelendirme(Remote Atteststations)**.
Peki, tekrarlanabilir inşa nedir? Modern yazılım geliştirme genellikle dış araçlar, kütüphaneler veya çerçeveler gibi birçok bağımlılığı içermektedir ve bu bağımlılık dosyalarında potansiyel güvenlik sorunları olabilir. Şu anda npm gibi çözümler, bağımlılık dosyalarına karşılık gelen kod özetini benzersiz bir tanımlayıcı olarak kullanmaktadır. npm, bir bağımlılık dosyasının kaydedilen özet değeriyle eşleşmediğini tespit ettiğinde, bu bağımlılık dosyasının değiştirildiğini düşünebilir.
Ve tekrarlanabilir yapılandırma, bir dizi standart olarak kabul edilebilir ve amacı, herhangi bir kodun herhangi bir cihazda çalıştığı zaman, önceden belirlenmiş bir sürece göre yapılandırıldığında sonunda tutarlı bir karma değeri elde edilebilir. Tabii ki, uygulamada, karmadan farklı ürünleri de bir tanımlayıcı olarak kullanabiliriz, bu durumda bunu kod ölçüsü olarak adlandırıyoruz(.
Nix, tekrarlanabilir şekilde oluşturulabilen yaygın bir araçtır. Bir programın kaynak kodu açıklandıktan sonra, herkes kodu kontrol edebilir ve geliştiricilerin anormal içerik ekleyip eklemediğini doğrulayabilir, herkes Nix'i kullanarak kod oluşturabilir ve oluşturulan ürünlerin, proje tarafından üretim ortamında dağıtılan ürünlerle aynı kod ölçütü/hash'e sahip olup olmadığını kontrol edebilir. Ancak TEE'de programın kod ölçüsünü nasıl bileceğiz? Bu noktada "uzaktan kanıt" olarak adlandırılan kavram devreye giriyor.
![])https://img.gateio.im/social/moments-de22e99c8194fa04f29ee5416aebcd03(
Uzak Doğrulama, programın kod ölçüleri, TEE platformunun sürümü vb. içeren, TEE platformundan (güvenilir taraf) gelen imzalı bir mesajdır. Uzak doğrulama, dış gözlemcilerin bir programın herhangi bir kişinin erişemeyeceği güvenli bir konumda (gerçek TEE'nin xx sürümü) yürütüldüğünü bilmesini sağlar.
![])https://img.gateio.im/social/moments-e4900d340dd1c812355c38739632d2a6(
Tekrarlanabilir yapısı ve uzaktan kanıtlama, herhangi bir kullanıcının TEE içinde çalışan gerçek kod ve TEE platformu sürüm bilgisini bilmesini sağlar, böylece geliştiricilerin veya sunucuların kötü niyetli davranışını engeller.
Ancak, TEE durumunda, tedarikçisine her zaman güvenmek gerekir. Eğer TEE tedarikçisi kötü niyetli hareket ederse, uzaktan kanıtı doğrudan sahtekarlık yapabilir. Bu nedenle, tedarikçiyi potansiyel bir saldırı aracı olarak görürseniz, yalnızca TEE'ye güvenmekten kaçının, onları en iyi şekilde ZK veya uzlaşma protokolü ile birleştirin.
TEE'nin Cazibesi
Bizim bakış açımıza göre, TEE'nin özellikle AI Agent'ın dağıtımı için uygunluğu, özellikle aşağıdaki noktalarda belirgin bir şekilde karşımıza çıkıyor:
İyi ya da kötü, şu anda TEE'nin kullanım alanlarının çoğu için alternatif bulmak oldukça zor. TEE'nin tanıtılmasının, şu anda blok zinciri uygulamalarının geliştirme alanını daha da genişlettiğine inanıyoruz, bu da yeni uygulama senaryolarının ortaya çıkmasını tetikleyebilir.
TEE bir gümüş mermi değildir
TEE'de çalışan programlar hala bir dizi saldırıya ve hataya maruz kalma riskine sahiptir. Akıllı sözleşmeler gibi, onlar da çeşitli sorunlarla karşılaşabilirler. Basitlik açısından, olası güvenlik açıklıklarını aşağıdaki gibi sınıflandıracağız:
Geliştiricinin dikkatsizliği
Geliştiriciler, kasıtlı veya kasıtsız olarak, TEE'deki programların güvenlik güvencelerini kasıtlı veya kasıtsız olarak zayıflatabilirler. Bu şunları içerir:
Çalışma Zamanı Zafiyeti
Geliştiriciler, ne kadar dikkatli olursa olsun, çalışma zamanı açıklarının kurbanı olabilirler. Geliştiriciler, projelerinin güvenliğini etkileyip etkilemeyeceğini dikkatlice düşünmek zorundadır:
Örneğin, şifreli işlemleri işleyebilen bir eşdeğer işletim ortamında (TEE), bu işletim ortamı, yönlendirici/gateway/sunucu tarafından hala paket kaynağı IP adresine göre paketleri atma, geciktirme veya önceliklendirme gibi adil sıralama garantisi (MEV direnci) sağlayamaz.
Mimari Kusur
TEE uygulamaları tarafından kullanılan teknoloji yığını konusunda dikkatli olunmalıdır. Bir TEE uygulaması oluştururken aşağıdaki sorunlar ortaya çıkabilir:
Operasyon Sorunu
Son ancak en az önemli olmayan bir nokta, TEE programını gerçekten çalıştırmak için sunucu hakkında bazı pratik dikkat edilmesi gereken noktalar vardır:
Güvenli TEE programı oluşturma
Önerilerimizi aşağıdaki noktalara ayırıyoruz:
1. En güvenli çözüm: Harici bağımlılıkları yok
Yüksek güvenlikli bir uygulama oluşturmak, dış bağımlılıkları, yani harici girişleri, API'leri veya hizmetleri ortadan kaldırmak suretiyle saldırı yüzeyini azaltmayı gerektirebilir. Bu yöntem, uygulamanın bağımsız bir şekilde çalışmasını ve bütünlüğünü veya güvenliğini tehlikeye atabilecek harici etkileşimleri olmadan çalışmasını sağlar. Bu strateji, programın işlevselliğini sınırlayabileceği gibi, son derece yüksek bir güvenlik sağlayabilir.
Eğer model yerel olarak çalışıyorsa, çoğu CryptoxAI senaryosu için bu düzeyde güvenlik sağlanabilir.
2. Alınması Gereken Önlemler
Uygulamanın dış bağımlılıkları olsa da, aşağıdaki içerik gereklidir!
TEE uygulamasını bir akıllı sözleşme olarak değerlendirin, bir arka uç uygulaması değil; düşük güncelleme sıklığını ve sıkı testi koruyun.
TEE programları oluşturmak, akıllı sözleşmelerin yazılması, test edilmesi ve güncellenmesi kadar titiz olmalıdır. Akıllı sözleşmelerde olduğu gibi, TEE, yüksek hassasiyetli ve değiştirilemez bir ortamda çalışır, burada hata veya beklenmeyen davranış ciddi sonuçlara yol açabilir, bunlar arasında fonların tamamen kaybı da bulunmaktadır. TEE tabanlı uygulamaların bütünlüğünü ve güvenilirliğini sağlamak için kapsamlı bir denetim, geniş kapsamlı test ve dikkatlice denetlenmiş en az düzeyde güncelleme son derece önemlidir.
Denetim kodlarını kontrol et ve yapılandırma boru hattını kontrol et
Uygulamanın güvenliği, yalnızca kodun kendisine değil, aynı zamanda inşa sürecinde kullanılan araçlara da bağlıdır. Güvenli bir inşa boru hattı, güvenlik açıklarını önlemek için hayati önem taşır. TEE, yalnızca sağlanan kodun beklenen süreçte çalışacağını garanti eder, ancak inşa sürecinde tanıtılan hataları düzeltemez.
Riski azaltmak için, kodların sıkı bir şekilde test edilmesi ve denetlenmesi gerekmektedir, böylece hatalar ortadan kaldırılır ve gereksiz bilgi sızıntısı önlenir. Ayrıca, tekrarlanabilir yapı, özellikle kodun bir tarafça geliştirilip başka bir tarafça kullanıldığı durumlarda hayati bir rol oynamaktadır. Tekrarlanabilir yapı, TEE içinde yürütülen programların orijinal kaynak koduyla eşleşip eşleşmediğini herhangi bir kişinin doğrulamasına olanak sağlar, böylece şeffaflık ve güven sağlanır. Tekrarlanabilir yapı olmadan, TEE içinde yürütülen programın tam içeriğini belirlemek neredeyse imkansızdır ve uygulamanın güvenliğini tehlikeye atar.
Örneğin, DeepWorm (TEE'de çalışan solucan beyin simülasyon modeli projesi) 'nin kaynak kodu tamamen açıktır. TEE içindeki yürütülebilir program, yeniden üretilebilir bir şekilde Nix boru hattı kullanılarak inşa edilmiştir.
Denetlenmiş veya doğrulanmış kitaplıkları kullanın
Duyarlı verilerin TEE programında işlenmesi gerektiğinde, yalnızca denetlenmiş kütüphaneler kullanılarak anahtar yönetimi ve özel veri işleme yapılmalıdır. Denetlenmemiş kütüphaneler anahtarları açığa çıkarabilir ve uygulamanın güvenliğini tehlikeye atabilir. Verilerin gizliliğini ve bütünlüğünü korumak için güvenlik odaklı, detaylı olarak incelenmiş bağımlılıkları öncelikli olarak düşünün.
TEE'den doğrulama her zaman sağlanır
TEE ile etkileşimde bulunan kullanıcılar, güvenli ve güvenilir etkileşimi sağlamak için TEE tarafından üretilen uzaktan kanıtları veya doğrulama mekanizmalarını doğrulamalıdır. Bu kontroller olmadan sunucu yanıtlarını manipüle edebilir ve gerçek TEE çıktısını ve değiştirilmiş verileri ayırt edemez. Uzaktan kanıtlar, TEE'de çalışan kod kitaplıkları ve yapılandırmalar için kritik kanıtlar sağlar ve TEE içinde yürütülen programların beklendiği gibi olup olmadığını uzaktan kanıtlara dayanarak belirleyebiliriz.
Belgeleme, zincir dışında ZK kanıtlama (IntelSGX, AWSNitro) veya zincir üzerinde (IntelSGX, AWSNitro) gerçekleştirilebilir ve kullanıcılar tarafından veya barındırılan hizmetler (örneğin t16z veya MarlinHub) tarafından doğrulanabilir.
3. Kullanım Durumuna Bağlı Öneriler
Uygulama senaryosuna ve yapısına bağlı olarak, aşağıdaki ipuçları uygulamanızı daha güvenli hale getirmenize yardımcı olabilir.
Kullanıcıların TEE ile etkileşimde her zaman güvenli bir kanalda çalışmasını sağlayın
TEE'nin bulunduğu sunucu temelde güvenilir değildir. Sunucu iletişimi engelleyebilir ve değiştirebilir. Bazı durumlarda, sunucu verileri okuyabilir ancak değiştirmemek kabul edilebilirken, diğer durumlarda verileri okumak bile istenmeyebilir. Bu riskleri azaltmak için kullanıcılar ve TEE arasında güvenli uçtan uca şifreli bir kanalın oluşturulması son derece önemlidir. En azından, iletilerin doğruluğunu ve kaynağını doğrulamak için bir imza içerdiğinden emin olun. Ayrıca, Kullanıcıların, doğru TEE ile iletişim kurduklarını doğrulamak için TEE'nin uzaktan kanıtını kontrol etmeleri gerekir. Bu iletişimin bütünlüğünü ve gizliliğini sağlar.
Örneğin, Oyster, güvenli TLS çıkarımını desteklemek için CAA kayıtlarını ve RFC8657'yi kullanabilir. Ayrıca, WebPKI'ye bağlı olmayan Scallop adlı bir TEE yerel TLS protokolü sağlar.
Biliyorsunuz TEE belleğinin geçici olduğunu
TEE belleği geçicidir, bu da TEE kapandığında (şifreleme anahtarları dahil) içeriğin kaybolacağı anlamına gelir. Bu bilgileri saklamak için güvenli bir mekanizma olmadığında, kritik verilere erişim kalıcı olarak engellenebilir, bu da fonların veya işletmenin sıkıntıya girmesine neden olabilir.
IPFS gibi merkezi olmayan depolama sistemlerine sahip çok taraflı hesaplama (MPC) ağı, bu sorunun bir çözümü olarak kullanılabilir. MPC ağı, anahtarları birden fazla düğüme böler, tek bir düğümün tam anahtarı tutmadığından emin olurken ağın anahtarı gerektiğinde yeniden oluşturmasına izin verir. Bu anahtarla şifrelenmiş veriler güvenli bir şekilde IPFS üzerinde depolanabilir.
Gerekli olduğunda, MPC ağı, belirli koşullar sağlandığında aynı görüntüyü çalıştıran yeni bir TEE sunucusuna anahtar sağlayabilir. Bu yöntem, verilerin erişilebilirliğini ve gizliliğini güvence altına alırken, güvenilmeyen bir ortamda bile esneklik ve güçlü güvenlik sağlar.
![])https://img.gateio.im/social/moments-429ced8c56f3dff6c933327cf8963516(
Başka bir çözüm de şudur: TEE ilgili işlemleri farklı MPC sunucularına ayırır, MPC sunucuları imzaladıktan sonra işlemleri topluca imzalar ve işlemleri nihai olarak zincire yükler. Bu yöntemin esnekliği çok daha düşüktür, API anahtarları, şifreler veya herhangi bir veri (güvenilir üçüncü taraf depolama hizmeti olmadan) saklamak için kullanılamaz.
![])https://img.gateio.im/social/moments-37203038abc830a2f70f702c7eeb0e7b(
Azaltılmış saldırı yüzeyi
Güvenlik açısından kritik kullanım örnekleri için, geliştirici deneyimi pahasına çevre bağımlılıklarını mümkün olduğunca azaltmaya çalışmaktır. Örneğin, Dstack, yalnızca Dstack'in çalışması gereken modülleri içeren minimal Yocto tabanlı bir çekirdekle birlikte gelir. TEE'nin bir parçası olmak için bir önyükleyici veya işletim sistemi gerektirmediğinden, SGX (TDX üzerinden) gibi daha eski bir teknolojiyi kullanmaya bile değer olabilir.
Fiziksel izolasyon
TEE'nin fiziksel olarak müdahale edilmesini önleyerek güvenliğini daha da artırabiliriz. TEE sunucularını veri merkezlerinde veya bulut sağlayıcılarında barındırarak fiziksel güvenliği sağlayabiliriz ancak Spacecoin gibi projeler oldukça ilginç bir alternatif keşfediyor - uzay. SpaceTEE makalesi, uyduların yörüngeye giriş sürecinde sapma olup olmadığını doğrulamak için atalet momentlerinin ölçümü gibi güvenlik önlemlerine dayanıyor.
Çoklu Kanıtlayıcı
Ethereum, gibi, birçok istemci uygulamasına dayanarak, ağın tümünü etkileyebilecek hata riskini azaltmak için multiprover'ler, güvenliği ve esnekliği artırmak için farklı TEE uygulama planları kullanır. Aynı hesaplama adımlarını farklı TEE platformları üzerinde çalıştırarak, çoklu doğrulama, bir TEE uygulamasındaki bir açığın tüm uygulamayı tehlikeye atmasını önler. Bu yöntem, hesaplama sürecinin belirli olmasını veya belirsiz durumlarda farklı TEE uygulama planları arasında bir uzlaşma sağlanmasını gerektirirken, aynı zamanda hata izolasyonu, yedekleme ve çapraz doğrulama gibi önemli avantajlar sunar ve güvenilirlik garantisi gerektiren uygulamalar için iyi bir seçenek haline gelir.
![])https://img.gateio.im/social/moments-da3100eaa6119891428bb2346de3f57e(
Geleceğe Bakış
TEE açıkça heyecan verici bir alan haline gelmiştir. Daha önce belirtildiği gibi, yapay zekanın evrensel olarak kullanılması ve kullanıcı hassas verilerine sürekli erişimi, Apple ve NVIDIA gibi büyük teknoloji şirketlerinin ürünlerinde TEE kullanmasını ve TEE'yi ürünlerinin bir parçası olarak sunmasını sağlamaktadır.
Öte yandan, kripto topluluğu her zaman güvenliğe büyük önem vermiştir. Geliştiricilerin zincir tabanlı uygulamaları ve kullanım durumlarını genişletmeye çalıştıkları bir dönemde, TEE'nin, işlevsellik ve güvenilirlik arasında doğru bir denge sağlamak için popüler hale geldiğini gördük. TEE, tam ZK çözümü kadar güvenilir değil olmasına rağmen, ilk kez Web3 şirketleri ve büyük teknoloji şirketlerinin ürünlerini yavaşça birleştirmesi beklenmektedir.