В облачных сервисах тысячи задач реализуются совместно — и это всегда риск утечек. Чтобы изолировать данные, вендоры придумали доверенные среды выполнения (TEE): они шифруют память на уровне железа и не дают хост-системе заглянуть внутрь. Все бы хорошо, но есть проблемы. 

Исследователи показали: защиту можно обойти без взлома кода — достаточно физического доступа. Требуется поместить между модулем памяти и платой перехватчик шины (интерпосер), как оказалось, это не так сложно. В итоге получаем поддельную удаленную аттестацию и  вытаскиваем ключи за считанные минуты. Для облаков и ИИ-сервисов это тревожный звоночек: аппаратная защита не панацея, если не учитывать физический уровень.Об этом сегодня и поговорим. 

Как работают TEE и что пошло не так

Защищенные зоны появились, когда стало нужно выполнять приватные вычисления на одном чипе для разных пользователей. Intel первой предложила такую технологию в 2015 году — SGX. Она позволяла запускать приложения в изолированных «анклавах», где память шифруется прямо на уровне процессора. 

Позже для серверов компания создала TDX — ту же идею, но с более надежной защитой виртуальных машин и проверкой целостности данных. AMD пошла тем же путем: в 2020 году выкатили SEV-SNP для процессоров EPYC. Там особое внимание уделено защите памяти от подмены и аттестации через собственный сервис ключей. Nvidia подключилась позже — в 2023-м запустила Confidential Compute для видеокарт вроде H100. Это дало возможность обучать и запускать модели ИИ в защищенном режиме, не раскрывая данные и веса нейросетей.

Все эти системы строятся на детерминированном шифровании: один блок данных с фиксированным ключом всегда дает одинаковый результат, что упрощает обработку больших объемов оперативки в серверах. Такой подход экономит ресурсы, но открывает лазейку — если перехватить трафик, можно скопировать зашифрованный фрагмент и «воспроизвести» его позже, заставив систему принять подделку за оригинал. 

Исследователь Дэниел Генкин и его команда показали это на практике: сначала — Battering RAM и Wiretap для DDR4, затем — TEE.fail для DDR5. Они использовали перехватчик шины памяти, который устанавливается между модулем ОЗУ и платой. Это устройство собирается из готовых компонентов и стоит менее тысячи долларов. Подключив его к тестовой машине и получив первоначальный доступ через скомпрометированное ядро, исследователи за  несколько минут извлекли секреты — например, приватные ключи ECDSA. На практике это означает, что если в дата-центре у злоумышленника есть физический доступ (при замене модуля памяти), он может подменить данные, и TEE этого не заметит.

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

Как именно действуют атаки 

Каждый вендор пытался закрыть дыры по-своему, но универсальность физического подхода делает защиту хрупкой. Возьмем Intel: в TDX анклавы генерируют ключи аттестации, подписанные самой компанией, чтобы клиент мог убедиться в целостности среды. TEE.fail обходит это, перехватывая Attestation Key во время обмена с Intel Attestation Service — злоумышленник копирует зашифрованный блок, воспроизводит его и подделывает сертификат даже на чужой машине. В блокчейне, где Ethereum-билдеры вроде BuilderNet полагаются на такие проверки для честных аукционов, это позволяет внедрить вредоносный код и выдать его за легитимный. Аналогично с SGX: старые анклавы страдают от replay-атак, где подмененная память раскрывает секреты вроде приватных ключей в смарт-контрактах.

AMD с SEV-SNP пошла еще дальше — после атаки Cipherleaks добавили «скрытие шифротекста», чтобы запутать анализ трафика, и усилили SME для constant-time операций. Но на Zen 5-архитектуре EPYC исследователи повторно открыли боковой канал: интерпосер модифицирует пакеты в реальном времени, крадя credentials OpenSSL или ключи для дешифровки сетевого трафика. Это бьет по облачным VM, где SNP используется для изоляции workloads — злоумышленник может перехватить сессию и извлечь данные, не трогая хост-ОС. В сценариях вроде Azure Confidential VMs, интегрированных с Kubernetes, такая подмена значит, что аттестация лжет, а клиент платит за «защищенный» сервис, который на деле открыт.

Nvidia продвигает Confidential Compute для своих серверных GPU, вроде H100 и B200, но в защите есть уязвимость: отчет об аттестации не привязан к конкретной видеокарте или виртуальной машине. Это позволяет злоумышленнику «одолжить» валидный отчет с контролируемого сервера и выдать его за защищенную среду на другом. В результате данные — например, веса ИИ-моделей или пользовательские запросы — могут утечь, даже если система считает, что они исполняются в надежной среде. Дополнительную сложность добавляет CUDA: программы, написанные под защищенный режим, продолжают работать, даже если защита уже подменена. Пока Nvidia только обещает патчи, но практические атаки, вроде тех, что были продемонстрированы на Secret Network и dstack, показывают: без исправлений в самом механизме шифрования это не решится.

Последствия для инфраструктур и что с этим делать дальше

Такие атаки затрагивают не только производителей, но и весь рынок. В облаке, если подделать аттестацию, Amazon или Google не смогут отличить безопасный сервер от скомпрометированного. Поэтому некоторые блокчейн-платформы, например Secret Network, уже начали вводить «белые списки» узлов и ограничивать подключение новых — чтобы не пустить злоумышленников. В сфере ИИ риски еще выше: утечка пользовательских запросов или весов моделей на GPU Nvidia может стоить компаниям миллионов. Под угрозой и сервисы вроде Signal или Cloudflare, если злоумышленник получит физический доступ к серверу. В итоге становится ясно: TEE защищают от атак через софт, но слабы против атак на уровень «железа», особенно там, где оборудование может находиться вне полного контроля — например, в удаленных дата-центрах или у подрядчиков.

Хорошая новость в том, что все это не катастрофа, а сигнал к развитию. Сейчас в отрасли уже появляются гибридные подходы: например, сочетание доверенных сред (TEE) с принципами нулевого доверия или использование специальных чипов, как в AWS Nitro, где проверка привязана к конкретному серверу. Что можно сделать на практике? Во-первых, включайте физические атаки в модель угроз и оценивайте, кто реально имеет доступ к вашему железу. Во-вторых, используйте шифрование с добавлением случайности, чтобы атаки с повтором данных перестали работать. В-третьих, тестируйте оборудование заранее: готовые инструменты для проверки уже есть в открытом доступе. В облаке помогает простой подход — разрешайте только известные и проверенные узлы, а для ИИ-задач полезно накладывать поверх TEE дополнительные уровни защиты, например дифференциальную приватность. 

Ну и производители чипов тоже не стоят на месте: Intel модернизирует TDX, AMD усиливает защиту в новых EPYC, Nvidia обещает обновления для GPU. Так что защита не стоит на месте, и информационная безопасность продолжает развиваться.