2025-11-18T12:28:13.304767

Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Rezabek, Mahhouk, Miller et al.
Confidential Virtual Machines (CVMs) protect data in use by running workloads inside hardware-isolated environments. In doing so, they also inherit the limitations of the underlying hardware. Trusted Execution Environments (TEEs), which enforce this isolation, explicitly exclude adversaries with physical access from their threat model. Commercial TEEs, e.g., Intel TDX, thus assume infrastructure providers do not physically exploit hardware and serve as safeguards instead. This creates a tension: tenants must trust provider integrity at the hardware layer, yet existing remote attestation offers no way to verify that CVMs actually run on physically trusted platforms, leaving today's CVM deployments unable to demonstrate that their guarantees align with the TEE vendor's threat model. We bridge this confidence gap with Data Center Execution Assurance (DCEA), a design generating "Proofs of Cloud". DCEA binds a CVM to its underlying platform using vTPM-anchored measurements, ensuring CVM launch evidence and TPM quotes refer to the same physical chassis. This takes advantage of the fact that data centers are often identifiable via TPMs. Our approach applies to CVMs accessing vTPMs and running on top of software stacks fully controlled by the cloud provider, as well as single-tenant bare-metal deployments with discrete TPMs. We trust providers for integrity (certificate issuance), but not for the confidentiality of CVM-visible state. DCEA enables remote verification of a CVM's platform origin and integrity, mitigating attacks like replay and attestation proxying. We include a candidate implementation on Google Cloud and Intel TDX that leverages Intel TXT for trusted launch. Our design refines CVMs' threat model and provides a practical path for deploying high-assurance, confidential workloads in minimally trusted environments.
academic

Доказательство облака: гарантия выполнения в центре обработки данных для конфиденциальных виртуальных машин

Основная информация

  • ID статьи: 2510.12469
  • Название: Proof of Cloud: Data Center Execution Assurance for Confidential VMs
  • Авторы: Filip Rezabek, Moe Mahhouk, Andrew Miller, Stefan Genchev, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach
  • Классификация: cs.CR (криптография и безопасность), cs.DC (распределённые, параллельные и кластерные вычисления)
  • Дата публикации: 14 октября 2024 г. (препринт arXiv)
  • Ссылка на статью: https://arxiv.org/abs/2510.12469

Аннотация

Конфиденциальные виртуальные машины (КВМ) защищают данные в процессе обработки путём выполнения рабочих нагрузок в аппаратно-изолированной среде. Однако они также наследуют ограничения базового оборудования. Доверенные среды выполнения (ДСВ) обеспечивают такую изоляцию, но их модель угроз явно исключает злоумышленников с физическим доступом. Коммерческие ДСВ (такие как Intel TDX) предполагают, что поставщики инфраструктуры не будут использовать оборудование на физическом уровне. Это создаёт противоречие: арендаторы должны доверять целостности поставщика на уровне оборудования, но существующие удалённые аттестации не могут проверить, действительно ли КВМ работает на физически надёжной платформе. В данной статье предлагается конструкция гарантии выполнения в центре обработки данных (ГВЦОД), которая генерирует «облачное доказательство», привязывая КВМ к её базовой платформе через измерения, закреплённые в виртуальном TPM, обеспечивая соответствие свидетельства загрузки КВМ и ссылки TPM одному и тому же физическому корпусу.

Исследовательский контекст и мотивация

Определение проблемы

Современные конфиденциальные виртуальные машины (КВМ) сталкиваются с критическим недостатком безопасности: хотя ДСВ может доказать «какой код выполняется», она не может доказать «где выполняется код». Эта «локационная слепота» позволяет злоумышленникам потенциально запускать якобы надёжные рабочие нагрузки на контролируемом ими оборудовании, одновременно генерируя действительные доказательства.

Значимость проблемы

  1. Недостатки модели угроз: модель угроз коммерческих ДСВ (Intel TDX, AMD SEV-SNP) предполагает, что злоумышленники не имеют физического доступа к серверам, но невозможно проверить это предположение
  2. Реальные примеры атак: недавние атаки использовали физический доступ для извлечения ключей аттестации Intel SGX
  3. Высокорисковые приложения: чувствительные области, такие как децентрализованные финансы (DeFi), всё больше полагаются на защиту ДСВ ценных активов, но участники не доверяют друг другу

Ограничения существующих подходов

  • Стандартная аттестация ДСВ проверяет только модель процессора, микрокод и состояние загрузки, не включая свидетельства о месте установки процессора
  • Невозможно обнаружить перемещение рабочей нагрузки злоумышленником в неконтролируемую среду
  • Отсутствуют криптографические механизмы для проверки местоположения ДСВ

Основные вклады

  1. Определение модели угроз ГВЦОД: охватывает сценарии КВМ и голого железа с различными возможностями злоумышленников
  2. Разработка практической архитектуры ГВЦОД: привязка доказательства TD к измерениям уровня платформы через виртуальный TPM
  3. Оценка осуществимости и безопасности метода: включая детальную реализацию протокола и меры по смягчению атак
  4. Предоставление эталонной реализации: кандидатская реализация на Google Cloud и Intel TDX с использованием Intel TXT для надёжной загрузки

Описание методики

Определение задачи

ГВЦОД предназначена для предоставления удалённому верификатору криптографического свидетельства того, что конфиденциальная рабочая нагрузка не только работает в проверенном состоянии программного и аппаратного обеспечения, но и работает в известной инфраструктурной среде.

Проектирование основной архитектуры

Двойной корень доверия

ГВЦОД устанавливает два параллельных корня доверия:

  1. Корень доверия ДСВ: от производителей ДСВ, таких как Intel
  2. Корень доверия инфраструктуры: от поставщика облака, реализуемый через TPM/виртуальный TPM

Два сценария развёртывания

Сценарий 1 (S1): управляемая КВМ

  • КВМ работает на управляемом поставщиком гипервизоре с виртуальным TPM
  • Поставщик облака управляет хост-ОС и инфраструктурой виртуального TPM
  • Привязка реализуется через проверку согласованности ссылок виртуального TPM и TD

Сценарий 2 (S2): развёртывание на голом железе

  • Однотенантный сервер на голом железе с прямым доступом к дискретному TPM
  • Стек хост-программного обеспечения ненадёжен, полагается только на гарантии оборудования
  • Использует Intel TXT для установления цепи доверия от TPM к КВМ

Детали технической реализации

Четырёхэтапный протокол ГВЦОД

  1. Установление надёжной загрузки и корня платформы: использование Intel TXT для безопасной загрузки, измерение ранних элементов загрузки в PCR 17-18
  2. Конфигурация и запечатывание ключей аттестации: TPM генерирует ключ аттестации (AK) и запечатывает материал приватного ключа в соответствии с политикой PCR 17-18
  3. Привязка свидетельства гостевой машины: TD встраивает хеш открытого ключа виртуального TPM в свой отчёт аттестации
  4. Рабочий процесс составного свидетельства верификатора: верификатор инициирует вызов на основе nonce, получает отчёт TD и ссылку TPM

Ключевые технические инновации

  • Перекрёстная проверка PCR-RTMR: обнаружение несоответствий путём сравнения значений PCR TPM и RTMR TD
  • Механизм запечатывания ключей: запечатывание открытого ключа виртуального TPM в определённые значения PCR для предотвращения использования в несовместимой среде
  • Транзитивная привязка: создание транзитивной привязки от доказательства TD к измерениям стека хост-программного обеспечения через хеш AK

Анализ безопасности

Модель угроз

  • Возможности злоумышленника: контроль хост-ОС, гипервизора и виртуализационного стека; перехват, задержка, повтор или внедрение сообщений
  • Ограничения злоумышленника: невозможность физического вмешательства; производители CPU и TPM заслуживают доверия; инфраструктура поставщика облака заслуживает доверия

Векторы атак и меры смягчения

Тип атакиОписание атакиМеханизм смягчения
A1: подделка ссылок/измеренийПодделка ссылки виртуального TPM или внедрение поддельных значений PCR/RTMRПодписанный QE TD + запечатанная ссылка AK
A2: атака трансляции/проксиТрансляция запроса ссылки на удалённую честную машинуNonce + хеш AK, встроенный в TD + запечатанный AK
A3: несоответствие измеренийЗначения PCR не совпадают с TD-RTMRВерификатор проверяет TD RTMR против PCR 17-18
A4: перехват/подделка каналаАтака «человек посередине» на пути TD к виртуальному TPMПривязка конечной точки через AK + проверка подписи
A5: подмена идентичности и ключейПодделка сертификата TPM-EK или замена ожидаемого AKAK, закреплённый в EK + ожидаемый AKpub, встроенный в TD
A6: компрометация привилегированных компонентовЗапуск изменённого вредоносного двоичного файла виртуального TPMИзмерение виртуального TPM/хоста в PCR 18

Экспериментальная установка и результаты

Платформа реализации

  • Целевая платформа: Intel TDX на Google Cloud Platform
  • Технический стек: Intel TXT, TPM 2.0, гипервизор QEMU
  • Тестовая среда: GCP в канадском регионе и хосты OVH

Оценка производительности

Тестирование производительности 500 последовательных операций с TPM и виртуальным TPM:

Тип операцииАппаратный TPMВиртуальный TPM
Генерация ссылки~0,55 сек~0,30 сек
Операция подписи~0,40 сек~0,15 сек

Ключевые выводы:

  • Аппаратный TPM медленнее программного виртуального TPM примерно на порядок величины
  • Производительность виртуального TPM более стабильна, аппаратный TPM показывает большую волатильность
  • Для одноразовых операций аттестации накладные расходы приемлемы

Поддержка облачных платформ

ПлатформаПоддержка КВМПоддержка виртуального TPMПоддержка голого железаАппаратный TPM
GCP✓✓✓✓
Azure✓✓××
AWS×✓××

Связанные работы

Доказательства привязки к местоположению

Существующие решения обычно полагаются на проверку на основе задержки или внешние сигналы геолокации, такие как GPS, но страдают от шума сетевого пути или отсутствия точности.

Защита от атак прокси

Предложенная в статье атака «Франкенштейн-прокси» расширяет существующие концепции атак подключения, где злоумышленник владеет несколькими аппаратными устройствами, а не одной платформой.

Механизмы защиты приватности

Связанные работы подчёркивают опасения по поводу утечки конфиденциальной информации в журналах прозрачности сертификатов; в данной статье предлагается использование доказательств с нулевым разглашением для смягчения рисков отслеживаемости.

Заключение и обсуждение

Основные выводы

  1. ГВЦОД успешно устраняет разрыв между моделью угроз ДСВ и требованиями практического развёртывания
  2. Благодаря двойному корню доверия и перекрёстной проверке PCR-RTMR эффективно защищает от шести основных программных атак
  3. Реализация на существующих аппаратных платформах доказывает осуществимость подхода

Ограничения

  1. Зависимость от процесса измерения PCR: измерения PCR могут различаться между платформами или стеками виртуализации
  2. Проблемы многотенантной среды: повторное использование компонентов виртуального TPM может ослабить гарантии уникальности доказательства
  3. Соображения приватности: цепь сертификатов виртуального TPM может раскрыть детали развёртывания

Направления будущих исследований

  1. Расширение на платформы AMD: требуется функциональность, аналогичная RTMR, от AMD SEV-SNP
  2. Глобальный реестр ключей: установление проверки уникальности AK на основе блокчейна или прозрачности сертификатов
  3. Интеграция доказательств с нулевым разглашением: реализация проверки платформы с защитой приватности

Глубокая оценка

Преимущества

  1. Значимость проблемы: решает критический пробел безопасности при развёртывании КВМ
  2. Инновационность метода: первый систематический подход к доказательствам привязки к местоположению
  3. Высокая практичность: развёртывается на существующих коммерческих платформах
  4. Комплексный анализ безопасности: выявляет и смягчает множество векторов атак
  5. Полная реализация: предоставляет детальную реализацию протокола и оценку производительности

Недостатки

  1. Зависимость от платформы: в настоящее время в основном ограничена Intel TDX, поддержка AMD ограничена
  2. Предположения о доверии: по-прежнему требуется доверие к физической безопасности поставщика облака и выдаче сертификатов
  3. Накладные расходы производительности: операции аппаратного TPM относительно медленны
  4. Сложность: реализация протокола сложна, что затрудняет развёртывание

Влияние

  1. Академический вклад: предоставляет новое измерение гарантий безопасности в области конфиденциальных вычислений
  2. Практическая ценность: имеет важное значение для высокорисковых приложений, таких как DeFi
  3. Потенциал стандартизации: может повлиять на развитие будущих стандартов ДСВ

Применимые сценарии

  • Приложения децентрализованных финансов (DeFi)
  • Сценарии многостороннего вычисления
  • Облачные рабочие нагрузки с высокими требованиями безопасности
  • Приложения конфиденциальных вычислений, требующие проверки местоположения

Библиография

Статья цитирует 55 связанных работ, охватывающих технологию ДСВ, спецификации TPM, безопасность облачных вычислений, криптографические протоколы и другие области, обеспечивая прочную теоретическую основу для исследования.