Confidential computing son dönemde özellikle Avrupa’nın “egemen bulut” yaklaşımında teknik bir dayanak olarak öne çıkarılıyor. Bu modelde temel fikir, hassas veriler paylaşılmadan önce sunucunun gerçekten değişmemiş bir Trusted Execution Environment içinde çalıştığını kriptografik olarak kanıtlaması. Bu kanıt süreci remote attestation ile sağlanıyor ve TLS ile birleştirilen “attested TLS” yaklaşımı da istemcinin doğru ve güvenilir makineye bağlandığını göstermeyi hedefliyor. Ancak yeni akademik çalışmalar, bu varsayımın pratikte iddia edildiği kadar güçlü olmadığını ortaya koyuyor.
TU Dresden araştırmacısı Muhammad Usama Sardar’ın son iki yılda yürüttüğü biçimsel doğrulama çalışmaları, attested TLS protokollerinin önemli bir bölümünün beklenen güvenlik özelliklerini sağlamadığını gösterdi. ProVerif adlı sembolik protokol analiz aracıyla yapılan incelemelerde, bir istemcinin bağlantısının fark edilmeden farklı ve ele geçirilmiş bir makineye yönlendirilebildiği bulundu. Buradaki temel sorun, protokolün çalıştırılan yazılımın bütünlüğünü doğrulasa da bu yazılımın hangi fiziksel ya da mantıksal konumda çalıştığını güvenilir şekilde bağlayamaması. Sonuç olarak istemci, doğru sunucuya bağlandığını sanarken aslında dünyanın herhangi bir yerindeki başka bir sisteme trafik gönderebiliyor.
Bu bulgular iki ayrı çalışmada detaylandırıldı. Identity Crisis in Confidential Computing başlıklı çalışma, güncel iki attested TLS protokolünde diversion saldırıları bulunduğunu gösteriyor. Daha yeni olan Intra-handshake.fail ise attestation kanıtının doğrudan TLS handshake sürecinde üretildiği “intra-handshake attestation” yaklaşımını inceliyor. Araştırmacılar burada yedi farklı kriptografik bağlama yöntemini değerlendirdi ve hiçbirinin relay saldırılarını engelleyemediğini raporladı. Yani istemci, güvenilir bir AI agent ya da sunucudan geldiğini düşündüğü attestation kanıtını doğrulasa bile, son aşamada trafiğini bambaşka ve kötü niyetli bir sisteme şifreleyebiliyor.
Çalışmaların çıkış noktası, donanım üreticisine zaten güvenmek zorunda olunduğu kabulü. Confidential computing ekosisteminde root of trust donanım katmanına dayanıyor. Buna rağmen araştırma, protokol katmanının beklenenden daha az güvence sunduğunu savunuyor. Sorun doğrudan donanımın kırılması değil; donanımın güvenli olduğunu varsaysanız bile, istemci ile gerçek hedef sistem arasındaki bağın TLS içinde yeterince güçlü kurulamadığı ifade ediliyor.
Araştırmacılar problemi üç seviyeli bir bağlama modeliyle tanımlıyor. En zayıf olan birinci seviye, attestation kanıtını yalnızca handshake’in ilk anahtar değişimi adımına, yani Diffie-Hellman sürecine bağlıyor. İkinci seviye, bunu istemcinin handshake traffic key bilgisine kadar genişletiyor ve sunucunun kimlik doğrulamasına kadarki kısmı kapsıyor. En güçlü ve pratikte en önemli kabul edilen üçüncü seviye ise attestation kanıtını doğrudan application traffic key’e, yani kullanıcı verisini gerçekten şifreleyen anahtara bağlıyor. Sorun şu ki mevcut intra-handshake mimarisinde üçüncü seviyeye ulaşmak neredeyse mümkün görünmüyor.
ProVerif tabanlı analiz, incelenen yedi bağlama mekanizmasından yalnızca üçünün birinci seviyeyi sağlayabildiğini gösterdi. Kalan mekanizmalar bu temel eşiği bile karşılayamıyor. Araştırma ekibinin önerdiği karşı önlem, TLS handshake secret ile sunucunun public key bilgisini birleştiren kriptografik bir binder kullanıyor ve biçimsel olarak ikinci seviyeye ulaşıyor. Ancak makaleye göre üçüncü seviye, TLS 1.3’ün mevcut özelliklerinden ödün vermeden intra-handshake attestation içinde elde edilemeyebilir. Daha sade bir ifadeyle, bugün eldeki en iyi çözüm bağlantının başlangıcında doğru makineyle konuşulduğunu gösterebiliyor; fakat dakikalar sonra gönderilen uygulama verisinin hâlâ aynı makineye gittiğini kesin biçimde kanıtlayamıyor.
Bu açık yalnızca teorik ya da laboratuvar ortamındaki prototiplerle sınırlı değil. Araştırma ekibi dört gerçek dünya uygulamasını da biçimsel olarak analiz etti: Meta’nın WhatsApp için kullandığı Private Processing sistemi, Edgeless Systems’in Contrast çözümü, açık kaynaklı Cocos AI platformu ve Confidential Computing Consortium’un Attestation Special Interest Group bünyesindeki proof-of-concept çalışma. Bunlardan ilk üçü üretimde kullanılıyor. Ayrıca saldırıların Cocos AI’ın 0.4.0 ile 0.8.2 arasındaki tüm sürümlerini etkilediği belirtiliyor. Araştırmacılara göre bu hata sınıfı tamamen yeni değil, fakat oldukça ince olduğu için yıllarca fark edilmeden kalabilmiş.
Sorumlu açıklama sürecinin ardından CVE-2026-33697 tanımlandı ve açık için CVSS 7.5 puan verildi; bu da “high severity” kategorisine denk geliyor. Araştırmada dikkat çekilen kıyaslamalardan biri, 2024’te ses getiren AMD SEV-SNP odaklı BadRAM saldırısının 5.3 puan almış olması. CCC Attestation SIG deposundaki kayıtlar da CVE-2026-33697’yi yakın dönemdeki confidential computing açıkları arasında en yüksek puanlı sorun olarak listeliyor. Fabricked 5.9, BreakFAST 5.9 ve Staleus ise 4.0 puanla bunun gerisinde yer alıyor.
Konuyu daha dikkat çekici kılan noktalardan biri, bu açığın daha önce yapılan klasik güvenlik incelemelerinde yakalanmamış olması. Meta’nın WhatsApp tarafındaki uygulaması, Sardar’ın ekibi incelemeden önce kapsamlı bir güvenlik denetiminden geçmişti. Ancak relay saldırısı burada tespit edilmedi. Araştırmaya göre bunun nedeni doğrudan yetersizlik değil, kullanılan yöntemin sınırları. Biçimsel doğrulama araçları tanımlanan tehdit modeli içindeki tüm senaryoları sistematik biçimde test ederken, manuel denetimler ne kadar ayrıntılı olursa olsun örnekleme yaklaşımına dayanıyor. Kanıtın bağlantıya nasıl bağlandığına dair ince bir hata, manuel gözden kaçabilirken biçimsel analiz altında açıkça ortaya çıkabiliyor.
Standartlaşma ve endüstri tarafında da konu resmen kabul edilmiş durumda. IETF’nin TLS çalışma grubu relay saldırılarını tanımış bulunuyor. Secure Evidence and Attestation Transport yani SEAT çalışma grubu ise bu tür korelasyon özelliklerini yeni spesifikasyonlar için açık ve zorunlu bir gereklilik olarak süreçlerine ekledi. Buna karşılık satış ve pazarlama söyleminde aynı temkin görülmüyor. Confidential computing hâlâ egemenlik, doğrulanabilirlik ve güçlü veri koruması söylemleriyle tanıtılıyor; ancak bu araştırmalar, attestation zincirinin düşündürücü zayıflıkları olduğunu gösteriyor.
Almanya Federal Office for Information Security yani BSI da benzer yönde bir değerlendirme yaptı. Kurum, confidential computing’i savunma katmanlarından biri olarak konumlandırıyor; tenant isolation ile gizlilik ve bütünlüğü güçlendirdiğini, ancak erişilebilirliği garanti etmediğini belirtiyor. Daha kritik olan nokta ise, kimlik ve anahtar yönetimi gibi bağımlılıkların confidential computing ile ortadan kalkmadığının açıkça vurgulanması. Bu yaklaşım, protokol analizinin gösterdiği boşlukla örtüşüyor: sistemin güvenlik garantileri, dağıtımın dayandığı kimlik ve anahtar altyapısını kimin kontrol ettiğini tek başına çözemiyor.
Intel tarafı, TDX attestation altyapısının egemenlik açısından bir sınırlama oluşturmadığını savunuyor. Şirkete göre Intel iş yükünün veri yolunda yer almıyor, attestation üzerinden müşteri düz metnine erişmiyor ve güven kararı bağımsız bir doğrulayıcıya devredilebiliyor ya da müşteride tutulabiliyor. Bu açıklama mimari açıdan savunulabilir olsa da, hukuki egemenlik tartışmasını tamamen kapatmıyor. Özellikle donanım üreticilerinin belirli yasal yükümlülüklere tabi olması konusu, teknik tasarımın ötesine geçen bir başlık olarak önemini koruyor.
Araştırmanın en net teknik sonucu, intra-handshake attestation yaklaşımının sınırlarına işaret etmesi. Üçüncü seviye bağlama, yani attestation kanıtını gerçek uygulama verisini şifreleyen anahtara bağlama hedefi, zamanlama nedeniyle mevcut mimaride karşılanamıyor. Çünkü o anahtar oluştuğunda kanıt çoktan gönderilmiş oluyor. Bu nedenle araştırmacılar post-handshake attestation yaklaşımının üçüncü seviyeyi sağlama konusunda daha umut verici olduğunu düşünüyor. Buna göre attestation, handshake sonrasında ve gerekli anahtar zaten oluşmuşken yapılırsa daha güçlü bir bağ kurulabilir.
Sonuç olarak çalışma, confidential computing’in tüm değerini ortadan kaldırmıyor; fakat pazarlama söylemi ile gerçek güvenlik garantileri arasındaki farkı belirginleştiriyor. Özellikle Avrupa’da dijital egemenlik, veri yerelliği ve doğrulanabilir bulut altyapısı arayan kurumlar için soru artık yalnızca hangi bulut sağlayıcısının seçileceği değil. Asıl mesele, iş yükünün iddia edildiği yerde çalıştığını kanıtlaması gereken kriptografik handshake mekanizmasının kendisine ne ölçüde güvenilebileceği. Mevcut bulgular, bu soruya bugün için rahatlatıcı bir yanıt vermiyor.
