TEE: изоляция, которой нужна точная модель противника

TEE — семейство архитектур

TEE обозначает доверенную среду исполнения, но конкретная граница зависит от реализации. У OP-TEE есть normal world, secure world и переход через monitor; взаимодействие включает вызовы и shared memory. У enclave и confidential VM иные единицы изоляции и наборы доверенных компонентов. Поэтому фраза «секрет в TEE» без названия платформы и противника недостаточна для оценки. S06

Нужно отдельно назвать актив: ключ, входные данные, промежуточное состояние, результат или сам алгоритм. Затем — субъект, от которого требуется защита: приложение-сосед, ядро normal world, администратор гипервизора, физический оператор. Одна архитектура может решать часть этих задач и не обещать остальные.

Граница вокруг вычисления не проверяет смысл запроса

Рассмотрим проектируемый сервис подписи внутри изолированной среды. Он может надёжно хранить ключ и всё же подписывать сообщения, которые бизнес-политика не разрешает. Причина — в интерфейсе принятия решения, а не обязательно в утечке ключа. Поэтому аудит TEE должен прослеживать авторизацию операции отдельно от конфиденциальности памяти.

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

Red: исследовательская гипотеза должна указывать нарушаемое свойство. Подмена входа, утечка секрета, rollback состояния и отказ в обслуживании — разные результаты, даже если наблюдаются через один API.

Blue: ведите перечень доверенных входов как контракт. Длина, тип и формат сообщения ещё не устанавливают его право на выполнение защищённой операции.

OP-TEE: normal world остаётся участником протокола

Документация OP-TEE описывает world switches, trusted threads и возвраты к normal world для обслуживания запросов. Планирование клиентского Linux-потока влияет на продолжение соответствующей работы. Следовательно, изоляцию исполнения нельзя автоматически приравнивать к независимой гарантии доступности сервиса. S06

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

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

Хранилище: шифрование, целостность и свежесть

OP-TEE документирует REE filesystem storage и RPMB-вариант. Для обычного REE-хранилища данные защищаются криптографически, но защита от rollback зависит от конфигурации; документация прямо связывает более сильное свойство с RPMB. Поэтому наличие зашифрованного файла само по себе не доказывает невозможность вернуть его старую допустимую версию. S07

Аналитический пример — счётчик разрешённых операций. Если проверяются только корректность тега и ключ устройства, старое корректное состояние может иметь ту же криптографическую подлинность, что и новое. Для запрета возврата нужна ещё связь с монотонным состоянием или иной протокол свежести. Это различие относится не только к TEE, но в TEE его особенно легко пропустить из-за сильного обещания защищённого хранения.

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

CLKSCREW и Plundervolt: доверие распространяется на управление железом

CLKSCREW исследовала, как механизмы управления энергопотреблением могут затрагивать изолированное исполнение на изученной ARM-платформе. Работа показывает необходимость включать подобные управляющие интерфейсы в модель доверия. Она не доказывает одинаковую уязвимость всех реализаций TrustZone. S09

Plundervolt показала программно управляемое нарушение целостности вычислений SGX через привилегированный интерфейс напряжения на затронутых Intel-процессорах. Авторы отделяют эту модель от чисто физических атак и обсуждают исправления через microcode/BIOS и отражение состояния в аттестации. S08

Общий вывод этих работ — аппаратная изоляция должна учитывать не только чтение и запись памяти, но и управление условиями вычисления. В ревью полезно спросить, какие привилегированные компоненты могут менять параметры платформы и входят ли они в доверенную базу. Это аналитическое обобщение, а не универсальная инструкция по воспроизведению конкретной атаки.

Confidential VM: гипервизор может быть противником

Intel TDX описывает изоляцию trust domain от VMM и другого внешнего программного обеспечения. AMD SEV-SNP добавляет к семейству SEV механизмы целостности и учёта владения памятью. Эти архитектуры меняют договор между гостем и инфраструктурой; они не превращают каждую виртуальную машину в одинаковую TEE. S18 S20

При этом виртуальные устройства и интерфейсы обмена остаются важны. Intel отдельно публикует руководство по защите гостевого кода в модели недоверенного VMM. Изоляция приватной памяти не делает произвольный ответ виртуального устройства правдивым. S19

Для оценки конкретного проекта нужно разделить приватные и разделяемые данные. Если приложение само публикует секрет через согласованный канал, аппаратная граница не может переопределить смысл этой публикации. Сюда же относятся журналы, crash reports и отладочные интерфейсы: они являются частью дизайна приложения.

Матрица вопросов к любой TEE

Эта матрица — предложение для аудита. Она не объявляет наличие уязвимости в любой TEE, а задаёт воспроизводимые вопросы, на которые архитектура должна отвечать независимо от маркетингового названия.

Связь с rootkit-исследованием

Rootkit в обычном ядре и код внутри TEE могут находиться по разные стороны границы. Тогда компрометация ОС не обязательно даёт чтение защищённого секрета, но может менять входы, задерживать ответы или подменять пользовательский интерфейс. Для защищённой операции важно не только где находится ключ, но и как пользователь подтверждает смысл действия.

Именно поэтому доверенный интерфейс, изоляция и аттестация нельзя заменять друг другом. У каждого своя задача. Хорошая спецификация TEE формулирует ограниченное обещание настолько точно, что по нему можно построить отрицательный тест и понять, какой компонент отвечает за его результат.