認証済みTLSの脆弱性、セキュアなクラウドデータを危険にさらす

クラウド信頼の幻想

セキュアなクラウドコンピューティングにおける信頼は、本来、送信されたデータの真の受信者を検証することから始まります。しかし今回、新たな形式検証によって、Attested TLSプロトコルが正確な保証を提供できないケースがあることが明らかになりました。

Attested TLSは、セキュアなTLS接続とリモートアテステーションをシームレスに統合し、サーバーが本物の改ざんされていない信頼実行環境（TEE）内で動作していることをクライアントに暗号学的に証明することを義務付けています。ドレスデン工科大学、IBM、ナミュール大学の研究者たちは、この証明を現在の接続に紐付けるために設計された7つの異なる手法を精査した結果、そのいずれもトラフィックリレー攻撃を防げないことを突き止めました。

トラフィックリレー攻撃の仕組み

この特定の攻撃手法では、クライアントは信頼できるサーバーやAIエージェントから完全に有効な確認応答を受け取りながらも、その後、機密データを全く別の悪意ある第三者に向けて暗号化してしまいます。プロトコルはソフトウェア環境の完全性を厳密に検証するものの、その検証結果を特定のサーバーインスタンスや、ハンドシェイク後にユーザーデータを保護する固有の暗号鍵に安全に紐付けることができていません。

影響を受けるソフトウェア実装

著者らは理論モデルと4つの実運用実装の両方を厳密に評価しました。その結果、WhatsAppのPrivate Processing、Contrast、Cocos AI、そしてConfidential Computing Consortiumが設計したデモプロジェクトにおいて、この構造的な脆弱性が存在することを明らかにしました。Cocos AIについてはバージョン0.4.0から0.8.2までが脆弱な状態にありますが、情報源によれば本番環境での悪用は確認されていないとのことです。

深刻度スコアとセキュリティ上の欠陥

このセキュリティ上の欠陥はCVE-2026-33697として採番されており、CVSS 3.1のフレームワークにおいて10点満点中7.5点という高い深刻度スコアを受けています。著者らが提案する防御策は、接続の初期段階でのみ正しいサーバーの身元を確認するものであり、その後のデータストリームが同一のシステムへ流れ続けることまでは保証していません。そのため、現時点では包括的な保護は存在しない状態です。

推奨される修正手順

セキュリティ専門家は、開発者に対し、初期接続のセットアップ段階でのアテステーションを取りやめるよう強く推奨しています。代わりに、ハンドシェイクが完了しデータ送信用の鍵が完全に確立された後に実行される検証プロトコルへ移行すべきだとしています。この暗号技術上の欠陥に関するより深い学術的分析については、Attested TLS CVE-2026-33697 high-severity vulnerabilityに掲載された論文が、正確な構造上の欠陥を詳しく解説しています。