Механизм доверия в конфиденциальных вычислениях сломан. Исправления может не быть

Механизм доверия в конфиденциальных вычислениях сломан. Исправления может не быть

Конфиденциальные вычисления позиционируют как основу европейской цифровой суверенности. Венчуры и государства опираются на механизм remote attestation, протокол, при котором сервер криптографически доказывает клиенту, что работает внутри подлинной, неизменённой среды доверия (Trusted Execution Environment, TEE) перед передачей чувствительных данных.

Исследователь Muhammad Usama Sardar из TU Dresden провел две года формальной верификации протокола attested TLS. С соавторами Mariam Moustafa и Tuomas Aura (AsiaCCS 2026) и позже Viacheslav Dubeyko и Jean-Marie Jacquet (ESORICS 2026) он обнаружил, что протокол делает не то, что обещает.

Основная проблема, relay-атаки. Клиент верифицирует, что общается с правильным сервером в начале рукопожатия TLS, но данные, отправленные минуты спустя, могут быть перенаправлены на совершенно другую, вредоносную машину, работающую с идентичным ПО. Клиент не узнает о подмене. Исследователи протестировали семь разных способов криптографической привязки данных аттестации к соединению TLS; ни один не защищает от relay-атак.

Диагностировали уязвимости в четырёх реальных системах: Meta Private Processing (WhatsApp), Edgeless Systems Contrast, Cocos AI и proof-of-concept Consortium for Confidential Computing. Первые три работают в production. Cocos AI уязвима в версиях 0.4.0, 0.8.2. Уязвимость получила CVE-2026-33697 с оценкой 7.5 (high severity), выше, чем BadRAM (5.3) от 2024 года.

Особенно примечательно: Meta заказала обширный security review этой же реализации у авторитетной фирмы Trail of Bits, они атаку не поймали. Причина не в компетенции, а в методе. Формальная верификация (ProVerif) проверяет протокол против всех сценариев угрозовой модели; ручной аудит лишь семплирует. Тонкий дефект в привязке может пройти сквозь выборочный аудит, но провалиться под исчерпывающей формальной проверкой.

Немецкое Федеральное бюро информационной безопасности (BSI) независимо пришло к похожему выводу. Confidential computing, лишь «компонент защиты в глубину», но не решает зависимости от инфраструктуры управления идентичностью и ключами. Вендоры переоценивают возможности технологии для суверенности.

Женев согласился публиковать артефакты исследования в CCC-репозитории лишь после того, как рабочая группа Attestation SIG (состоящая из представителей вендоров, чьи реализации сломаны) не создала нужный репозиторий за неделю и три письменных напоминания.

Ключевые факты

  • Remote attestation протокол attested TLS в confidential computing уязвим к relay-атакам: клиент может быть перенаправлен на вредоносный сервер без оповещения, несмотря на верификацию в начале соединения
  • Формальная верификация выявила уязвимости в четырех production-системах (Meta WhatsApp, Edgeless Systems Contrast, Cocos AI), которые прошли ручные security-аудиты авторитетных фирм
  • CVE-2026-33697 получил оценку 7.5 (high severity), выше памятного BadRAM 2024 года; три из четырех уязвимых систем уже работают в боевых условиях
  • Немецкое бюро информационной безопасности (BSI) вывело, что confidential computing не решает ключевые зависимости от инфраструктуры управления идентичностью, вендоры переоценивают технологию для цифровой суверенности
  • Рабочая группа вендоров (CCC Attestation SIG) неделю игнорировала запрос на создание репозитория для публикации доказательств уязвимостей

Почему это важно

Confidential computing позиционируют как техническую основу европейской цифровой суверенности: Intel TDX обещает «защиту суверенности данных», Google Cloud говорит о «полном аудируемом контроле над доступом». Но основной механизм доверия, remote attestation, имеет фундаментальный дефект. Клиент не может быть уверен, что данные, отправленные после верификации соединения, достигнут нужного сервера, а не перехватчика. В контексте европейских суверенных облаков (SecNumCloud) это подрывает центральное обещание: гарантию контроля над данными.

Кому это важно

Облачные провайдеры (Meta, Google, Amazon), которые строят инфраструктуру confidential computing; государства ЕС, опирающиеся на эту технологию для суверенности; компании, размещающие критичные данные в таких системах; регуляторы (BSI, IETF, CCC), стандартизирующие протоколы; исследователи формальной верификации; организации, требующие гарантий end-to-end при передаче данных.

Как это применить

Если вы развёртываете или выбираете confidential computing: не опирайтесь только на позиционирование вендора о суверенности и control. Требуйте формальной верификации протоколов, не только ручных аудитов. Проверьте, какой уровень криптографической привязки используется (уровень 1, слабый, уровень 3, невозможен в текущей архитектуре). Рассмотрите альтернативные гарантии: физическая безопасность, инспекции, юрисдикционные договоры. Для пилотов в production этих систем добавьте мониторинг сетевых потоков и верификацию целевых адресов на уровне приложения.

Можно ли доверять

Исследование прошло через peer-review в ведущих конференциях (AsiaCCS, ESORICS), использовало формальные методы (ProVerif) и тестировало реальные production-системы. Выводы подтверждены независимо, BSI пришла к похожему заключению собственным путём. Авторы ответственно раскрыли уязвимости: CVE опубликован, вендоры уведомлены. Единственный минус, рабочая группа вендоров медлила с публикацией доказательств, но это не меняет математику. Результаты воспроизводимы.

Риски и подводные камни

Вендоры могут переинтерпретировать выводы: мол, это лишь архитектурное ограничение, которое принимается заранее. На самом деле, риск реален и эксплуатируется при правильных условиях (контролируемая сеть, возможность перехватывать трафик). Уровень 2 (текущее смягчение) оставляет окно: доказывает только, что соединение началось правильно. Заявления вендоров о суверенности, маркетинг, опередивший техническую зрелость. RISAA (US закон, обязывающий вендоров сотрудничать с разведкой) не упоминается в ответах Intel, хотя это ключевая зависимость для суверенности.

«В конфиденциальных вычислениях вы всё равно должны доверять производителю оборудования. Нет вообще никакого способа избежать этого. Протокольный слой должен был обеспечить всё остальное. Исследование показывает, что он обеспечивает гораздо менее того, что предполагается.»

— Muhammad Usama Sardar, исследователь TU Dresden