Средняя
Конфиденциальные вычисления (confidential computing) последние несколько лет позиционируются как технологический фундамент цифрового суверенитета Европы. Крупнейшие вендоры — Intel, Google, AMD — обещают защиту данных не только на диске и в сети, но и в процессе обработки. «Аттестация», «аппаратный корень доверия», «изолированные среды выполнения» — эти термины звучат как гарантия того, что никто, даже облачный провайдер, не сможет получить доступ к вашим данным.
Но что, если главный механизм, который должен это доказывать, архитектурно несостоятелен?
Новое исследование, представленное на ведущих конференциях по компьютерной безопасности AsiaCCS 2026 и ESORICS 2026, выявило фундаментальные уязвимости в протоколе attested TLS (aTLS), который должен подтверждать, что клиент общается именно с тем защищённым сервером, которому он доверяет. Результат неутешительный: протокол обещает больше, чем может доказать, а предложенные исправления устраняют лишь часть проблем.
В этой статье мы разберём, что пошло не так, почему производители пропустили уязвимости, несмотря на дорогостоящие аудиты, и что это значит для европейских CIO, закупщиков облачных услуг и всех, кто всерьёз относится к кибербезопасности.
Содержание
- Часть 1. Что такое конфиденциальные вычисления и почему они нужны?
- Часть 2. Проблема: attested TLS не работает так, как обещано
- Часть 3. Реальные системы, реальные уязвимости
- Часть 4. Реакция индустрии: четыре разных ответа
- Часть 5. BSI подтверждает: конфиденциальные вычисления — не панацея
- Часть 6. Что это значит для кибербезопасности и мониторинга сети?
- Часть 7. Что дальше? Рекомендации и выводы
- Заключение
Часть 1. Что такое конфиденциальные вычисления и почему они нужны?
Проблема, которую решают конфиденциальные вычисления
Традиционные модели безопасности защищают данные в двух состояниях: в покое (на диске) и при передаче (по сети). Но есть третье состояние — данные в использовании (in use) — когда процессор обрабатывает информацию в оперативной памяти. Именно здесь данные наиболее уязвимы: операционная система, гипервизор, другие приложения и даже администратор облачной инфраструктуры теоретически могут получить доступ к памяти работающего приложения.
Конфиденциальные вычисления решают эту проблему с помощью аппаратных доверенных сред выполнения (Trusted Execution Environment, TEE). Это изолированные области внутри процессора, где код и данные защищены даже от привилегированного доступа со стороны ОС или гипервизора.
Технологии: Intel TDX, AMD SEV-SNP и другие
На рынке доминируют несколько реализаций:
- Intel Trust Domain Extensions (TDX) — создаёт изолированные доверенные домены внутри виртуальных машин, использует аппаратные расширения для управления и шифрования памяти. На страницах продуктов Intel обещают, что TDX «добавит гарантии суверенитета данных и управления».
- AMD SEV-SNP — аналогичная технология от прямого конкурента, также позволяющая создавать зашифрованные виртуальные машины.
- Google Cloud Confidential Computing — облачная реализация, которая, по заявлениям Google, предлагает «полный, аудируемый контроль над доступом к данным клиентов».
- Европейские рамочные программы цифрового суверенитета, такие как французский SecNumCloud и немецкий BSI C5, рассматривают конфиденциальные вычисления как важный компонент защищённой облачной инфраструктуры.
Удалённая аттестация — главный механизм доверия
Вся конструкция конфиденциальных вычислений держится на удалённой аттестации (remote attestation). Это механизм, с помощью которого сервер криптографически доказывает клиенту, что он работает внутри подлинной, неизменённой доверенной среды выполнения, прежде чем между ними начнётся обмен чувствительными данными.
Проще говоря: клиент должен быть уверен, что сервер — это не подделка, не скомпрометированная машина и не злоумышленник, притворяющийся легитимным сервером. Аттестация даёт это обещание.
Но как именно это обещание выполняется на практике? Через протокол, который называется attested TLS (aTLS) — расширение стандартного TLS, добавляющее в рукопожатие аттестационные данные.
Часть 2. Проблема: attested TLS не работает так, как обещано
Что не так с протоколом?
Мухаммад Усама Сардар, исследователь из Технического университета Дрездена, потратил два года на формальную верификацию протокола attested TLS. Используя инструмент ProVerif для символического анализа безопасности протоколов, он и его соавторы обнаружили: протокол в значительной степени не делает того, что заявляет.
В их работе Identity Crisis in Confidential Computing, представленной на AsiaCCS 2026, описаны атаки перенаправления (diversion attacks) против двух современных реализаций attested TLS. Соединение, предназначенное для одного сервера, может быть бесшумно перенаправлено на другую, скомпрометированную машину с идентичным программным обеспечением — в любой точке мира. Клиент никогда не узнает об этом.
Подчёркнём важный нюанс: целевой сервер не сделал ничего плохого. Он легитимен, правильно настроен и выполняет все требования безопасности. Проблема в том, что протокол проверяет целостность программного обеспечения, но не проверяет местоположение сервера.
Три уровня связывания — и ни один не работает полностью
Исследователи формализовали проблему в виде трёх уровней криптографического связывания между аттестационными данными и TLS-соединением, которое эти данные должны подтверждать:
- Уровень 1 (самый слабый) — привязка только к самому первому обмену ключами в рукопожатии (этап Diffie-Hellman), когда клиент и сервер договариваются об общем секрете до того, как любая из сторон подтвердила свою личность.
- Уровень 2 — привязка к ключу трафика рукопожатия клиента, охватывающая всё вплоть до подтверждения идентичности сервера.
- Уровень 3 (самый сильный и практически важный) — привязка к ключу прикладного трафика — тому самому ключу, который используется для шифрования чувствительных данных, отправляемых клиентом после установления соединения.
Из семи исследованных механизмов связывания только три достигают уровня 1. Остальные проваливаются даже на этом базовом уровне.
Собственное предложенное исследователями исправление — криптографический связыватель, построенный из секрета рукопожатия TLS в комбинации с публичным ключом сервера — формально достигает уровня 2. Но уровень 3 может быть недостижим в рамках внутрирукопожатийной аттестации (intra-handshake attestation) в её текущей архитектуре без нарушения свойств TLS 1.3, которые протокол никогда не был спроектирован отдавать.
На простом языке: лучшее из доступных сегодня исправлений доказывает, что клиент общается с правильной машиной в начале рукопожатия. Оно не может доказать, что данные, отправленные через несколько минут, всё ещё поступают на ту же самую машину.
Проблема с таймингом
Почему уровень 3 так трудно достижим? Всё упирается в тайминг.
Уровень 3 требует привязать аттестационные данные к ключу, который шифрует фактические прикладные данные. Но к тому моменту, когда этот ключ существует, аттестационные данные уже отправлены — если только сам протокол TLS не будет существенно изменён.
Пост-рукопожатийная аттестация (post-handshake attestation) ждёт до этого момента, когда ключ уже существует, чтобы привязаться к нему. Поэтому исследователи рекомендуют полностью отказаться от внутрирукопожатийной аттестации в пользу пост-рукопожатийной.
Часть 3. Реальные системы, реальные уязвимости
Продакшен, а не лабораторные концепты
Это не абстрактная академическая проблема. Исследователи формально проанализировали четыре реальные реализации внутри рукопожатийной аттестации:
- Meta Private Processing — система конфиденциальной обработки для WhatsApp.
- Edgeless Systems Contrast — коммерческая платформа конфиденциальных вычислений.
- Cocos AI — открытая платформа для конфиденциального ИИ.
- Реализация CCC Attestation Special Interest Group.
Первые три работают в продакшене сегодня. Атаки применимы ко всем версиям Cocos AI с 0.4.0 по 0.8.2.
CVE-2026–33697: высокий рейтинг серьёзности
Уязвимость получила идентификатор CVE-2026–33697 с рейтингом 7.5 из 10 по шкале CVSS — высокий уровень серьёзности.
Для сравнения: BadRAM — атака на AMD SEV-SNP 2024 года, вызвавшая широкий резонанс — получила 5.3. В репозитории CCC Attestation SIG этот CVE значится как самая высокооценённая уязвимость среди недавних проблем конфиденциальных вычислений, опережая Fabricked (5.9), BreakFAST (5.9) и Staleus (4.0).
Meta заказала аудит — и пропустила уязвимость
Особенно показательно то, что Meta заказала обширный аудит безопасности своей WhatsApp-реализации у известной фирмы Trail of Bits до того, как команда Сардара исследовала систему. Аудит не обнаружил атаку перенаправления.
Почему? Не потому, что аудиторы некомпетентны. Разница в методологии:
- Ручной аудит — даже очень тщательный — это выборочная проверка. Аудитор смотрит на код, ищет известные паттерны уязвимостей, проверяет логику. Но он не может перебрать все возможные сценарии.
- Формальная верификация инструментами вроде ProVerif — это исчерпывающая проверка протокола против всех сценариев, допускаемых определённой моделью угроз. Тонкая ошибка в том, как аттестационные данные привязаны к соединению, может проскользнуть мимо выборочной проверки и при этом быть формально доказанно сломанной при исчерпывающем анализе.
Часть 4. Реакция индустрии: четыре разных ответа
Исследование Сардара вызвало четыре различных институциональных ответа.
IETF SEAT — правильная реакция
IETF Secure Evidence and Attestation Transport (SEAT) рабочая группа, сформированная после того, как группа, включающая Сардара, успешно обосновала её необходимость на сессии Birds of a Feather на IETF 123 в Мадриде в июле 2025 года, написала свойства корреляции Сардара непосредственно в свой устав как явное, обязательное требование для любой новой спецификации. Это стандартизирующий орган, делающий именно то, что должен: встраивать формальную верификацию в процесс, а не прикручивать её постфактум.
IETF TLS — признание без обязательств
IETF TLS рабочая группа формально признала те же атаки, но не приняла обязательного требования.
CCC Attestation SIG — десятидневное молчание
CCC Attestation Special Interest Group — группа, состоящая из представителей производителей оборудования и облачных вендоров, чьи продукты оказались уязвимыми, — не создала запрошенный репозиторий для публикации доказательств уязвимости в течение десяти дней и после трёх письменных напоминаний.
Сардар запросил новый публичный репозиторий GitHub 14 июня. 17 июня напомнил. 18 июня — второй раз. 24 июня — уже без дипломатических формулировок. Репозиторий так и не был создан.
Поскольку репозиторий не был создан до сдачи финальной версии статьи, Сардар опубликовал артефакты внутри существующего репозитория CCC. Его комментарий был краток: «Поскольку монополия [рабочих групп, доминируемых вендорами, над этой инфраструктурой] продолжается, мы выпустили артефакты, чтобы проинформировать сообщество и дать исследователям возможность анализировать их независимо».
Производители — маркетинг против реальности
Intel в ответ на вопрос об аттестационной инфраструктуре TDX заявила, что не считает свою аттестационную инфраструктуру ограничением для гарантий суверенитета, поскольку любая зависимость от кремния Intel и корневого сертификата «ограничена». Intel не находится на пути данных клиента, не получает открытый текст клиента через аттестацию, и решение об операционном доверии может быть делегировано независимому верификатору или оставлено клиенту.
Это технически обоснованный, осторожно сформулированный ответ. Он объясняет архитектуру, но не закон. На вопрос, представляет ли аттестационная инфраструктура Intel риск суверенитета в соответствии с RISAA — законом США 2024 года, который может обязать производителей оборудования сотрудничать с секретными ордерами разведки, — Intel не ответила.
Google не ответил на запрос о комментариях.
Часть 5. BSI подтверждает: конфиденциальные вычисления — не панацея
Независимо от исследований Сардара, Федеральное ведомство по информационной безопасности Германии (BSI) пришло к близкому выводу через свой собственный канал.
Карина Хильт, заместитель пресс-секретаря BSI, заявила, что конфиденциальные вычисления функционируют как «компонент защиты в глубину», усиливающий изоляцию арендаторов и защищающий конфиденциальность и целостность, но не доступность. Критически важное дополнение: «Зависимости от других сервисов, таких как управление идентификацией и ключами и т.д., также не смягчаются с помощью CC».
Это институциональное эхо именно того разрыва, который вскрывает анализ протокола Сардара: гарантии конфиденциальных вычислений останавливаются далеко перед тем, чтобы гарантировать, кто на самом деле контролирует ключи и инфраструктуру идентификации, от которых зависит развёртывание.
На вопрос о маркетинговых заявлениях вендоров BSI не смягчило позицию: «Позиционирование вендоров в отношении CC может придавать слишком большой вес его техническим возможностям. CC в одиночку не может удовлетворить требования к цифровому суверенитету».
Часть 6. Что это значит для кибербезопасности и мониторинга сети?
Для специалистов по сетевой безопасности
Атаки перенаправления работают на уровне протокола прикладного уровня — они не обнаруживаются стандартными средствами мониторинга сети. Ваши системы обнаружения вторжений (IDS), анализаторы трафика и SIEM-решения не увидят ничего подозрительного, потому что:
- TLS-рукопожатие проходит успешно
- Сертификаты валидны
- Трафик зашифрован
- Нет никаких явных признаков перенаправления
Это делает атаку идеально скрытной с точки зрения традиционного мониторинга сети и управления рисками.
Для управления рисками
Уязвимость CVE-2026-33697 с рейтингом 7.5 требует пересмотра моделей угроз для любых систем, использующих конфиденциальные вычисления:
Риск №1: Аутентификация сервера не гарантирует, что данные остаются на том же сервере после установления соединения.
Риск №2: Зависимость от аттестационной инфраструктуры производителя (Intel, AMD) создаёт дополнительный вектор атаки, который не покрывается стандартными средствами мониторинга сети.
Риск №3: Юридические риски — RISAA и аналогичные законы могут потребовать от производителей раскрытия информации, что ставит под сомнение «суверенность» даже технически корректных реализаций.
Для европейских CIO и закупщиков
Вопрос выходит за рамки привычного: «Какой вендор владеет облаком?» и «Какое правительство может обязать какого производителя оборудования?». Теперь он звучит так:
Можно ли вообще доверять криптографическому рукопожатию, которое должно доказывать, что рабочая нагрузка работает там, где она утверждает, что работает?
Часть 7. Что дальше? Рекомендации и выводы
Немедленные действия
Обновите модели угроз для всех систем, использующих конфиденциальные вычисления. Учитывайте возможность атак перенаправления.
Пересмотрите средства мониторинга сети. Традиционные подходы не обнаружат этот класс атак. Рассмотрите внедрение средств мониторинга на уровне приложений и формальной верификации протоколов.
Проверьте версии Cocos AI — все версии с 0.4.0 по 0.8.2 уязвимы.
Требуйте от вендоров результатов формальной верификации, а не только ручных аудитов. Пример с Trail of Bits и Meta показывает, что ручные аудиты могут пропускать критические уязвимости.
Стратегические рекомендации
- Откажитесь от внутрирукопожатийной аттестации в пользу пост-рукопожатийной. Исследователи прямо рекомендуют это IETF TLS рабочей группе.
- Не полагайтесь на конфиденциальные вычисления как на единственный механизм безопасности. BSI прямо указывает, что CC — это «компонент защиты в глубину», а не панацея.
- Включайте формальную верификацию в процессы закупок. Если вендор не может предоставить формальные доказательства безопасности своих протоколов — это красный флаг.
- Мониторинг сети и управление рисками должны учитывать не только технические, но и юридические аспекты — зависимость от производителей оборудования, которые могут быть подвержены национальным законам типа RISAA.
Научный взгляд: проблема может не иметь решения
Самый тревожный вывод исследования: уровень 3 связывания (прикладной трафик) может быть недостижим в рамках текущей архитектуры TLS 1.3 без нарушения фундаментальных свойств протокола.
Это означает, что фундаментальный механизм доверия конфиденциальных вычислений архитектурно сломан, и исправление может потребовать пересмотра самого TLS — протокола, который является основой безопасности всего интернета.
Заключение
Конфиденциальные вычисления — это мощная технология. Они решают реальную проблему защиты данных в использовании. Но они не являются серебряной пулей для цифрового суверенитета, и их главный механизм доверия — удалённая аттестация через attested TLS — оказался архитектурно несостоятельным.
Исследование Сардара и его коллег — это не просто академическая работа. Это предупреждение для всей индустрии: нельзя строить системы безопасности на обещаниях, которые не могут быть формально подтверждены. Нельзя заменять исчерпывающую верификацию ручными аудитами, какими бы дорогими они ни были. И нельзя игнорировать юридические риски, связанные с зависимостью от производителей оборудования.
Для специалистов по кибербезопасности, сетевой безопасности и мониторингу сети вывод однозначен: существующие средства мониторинга не обнаруживают этот класс атак. Требуются новые подходы — на уровне формальной верификации протоколов, на уровне приложений и на уровне юридического анализа.
Для европейских CIO и закупщиков облачных услуг вопрос теперь стоит иначе: не «кому доверять», а «можно ли доверять вообще».
Ответ на этот вопрос пока остаётся открытым. Но одно ясно точно: доверие, которое нельзя проверить формально, — это не доверие, а надежда. А надежда — плохая стратегия в кибербезопасности.
Статья подготовлена на основе исследований, представленных на AsiaCCS 2026 и ESORICS 2026, а также материалов The Register, BSI и открытых источников. CVE-2026–33697 присвоен рейтинг 7.5 (высокий) по шкале CVSS.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
