С тех пор, как Apple объявила о запуске частного облака, а NVIDIA предоставляет конфиденциальные вычисления в графическом процессоре (GPU), доверенная среда выполнения (TEE) стала все более популярной. Их гарантированная конфиденциальность помогает защитить данные пользователей (включая приватные ключи), а изоляция обеспечивает, что выполнение программ, размещенных на них, не будет подвергаться вмешательству - независимо от того, являются ли это люди, другие программы или операционные системы. Поэтому неудивительно, что в области Crypto x AI широко используется TEE для создания продуктов.
Как и любая новая технология, TEE проходит оптимистический экспериментальный период. В этой статье мы хотели бы предоставить основное понятийное руководство для разработчиков и обычных читателей, чтобы они понимали, что такое TEE, его модель безопасности, распространенные уязвимости и лучшие практики безопасного использования TEE. * (Примечание: чтобы текст был понятен, мы сознательно заменили термины TEE на более простые эквиваленты).
Что такое TEE
TEE - это изолированная среда в процессоре или центре обработки данных, в которой программы могут работать, не подвергаясь вмешательству остальной части системы. Для предотвращения вмешательства других частей системы в TEE нам нужен ряд мер, в основном строгий контроль доступа, то есть контроль доступа остальных частей системы к программам и данным внутри TEE. В настоящее время TEE повсюду, в телефонах, серверах, ПК и облачных средах, поэтому они очень доступны и имеют разумную цену.
Вышеупомянутое содержание может звучать неясно и абстрактно, на самом деле различные серверы и облачные поставщики реализуют TEE по-разному, но их основная цель - предотвратить вмешательство других программ в TEE.
!
Большинство пользователей, возможно, будут использовать биометрическую информацию для входа в устройства, например, разблокировки телефона по отпечатку пальца. Но как мы можем гарантировать, что вредоносные приложения, веб-сайты или операционные системы с джейлбрейком не смогут получить доступ к этой биометрической информации и украсть ее? Фактически, помимо шифрования данных, схемы в TEE устройстве абсолютно не позволяют программам обращаться к областям памяти и процессора, занятым чувствительными данными.
Железный кошелек - еще один пример сценария применения TEE. Железный кошелек подключается к компьютеру и взаимодействует с ним в песочнице, но компьютер не может напрямую получить доступ к мнемоническим словам, хранящимся в железном кошельке. В обоих вышеупомянутых случаях пользователи доверяют производителям устройств, способным правильно разрабатывать микросхемы и предоставлять соответствующие обновления прошивки, чтобы предотвратить экспорт или просмотр конфиденциальных данных в TEE.
Модель безопасности
К сожалению, существует множество различных реализаций TEE, и для каждой из них (Intel SGX, Intel TDX, AMD SEV, AWS Nitro Enclaves, ARM TrustZone) требуется отдельное моделирование и анализ безопасности. В остальной части этой статьи мы сосредоточимся на Intel SGX, TDX и AWS Nitro, поскольку эти системы TEE имеют больше пользователей и полноценные инструменты разработки. Эти системы также являются наиболее распространенными внутри Web3 системами TEE.
В общем, рабочий процесс развертывания приложений в TEE выглядит следующим образом:
"Разработчики" написали некоторый код, который может быть открытым или нет
Затем разработчик упаковывает код в образ Enclave (EIF), который может выполняться в TEE.
EIF размещается на сервере с TEE в некоторых случаях разработчик может использовать персональный компьютер с TEE для хостинга EIF и предоставления услуг.
Пользователь может взаимодействовать с приложением через предопределенный интерфейс.
!
Очевидно, здесь есть 3 потенциальных риска:
Разработчики: Для чего вообще нужен код EIF? Код EIF может не соответствовать бизнес-логике, о которой проект заявляет наружу, и может быть использован для кражи пользовательских конфиденциальных данных.
Сервер: Выполняется ли TEE сервер с ожидаемым файлом EIF? Или EIF действительно выполняется в TEE? Сервер также может выполнять другие программы в TEE
Поставщик: Безопасен ли дизайн TEE? Есть ли задние двери, через которые все данные TEE могут утекать поставщику?
К счастью, сейчас у TEE есть решение для устранения вышеупомянутых рисков, а именно воспроизводимые сборки(Reproducible Builds) и удаленные аттестации(Remote Atteststations).
Что такое повторное построение? Современная разработка программного обеспечения часто требует импорта большого количества зависимостей, таких как внешние инструменты, библиотеки или фреймворки и т. д. Эти файлы зависимостей также могут иметь скрытые уязвимости. Сейчас npm и другие схемы используют хеш кода, соответствующего файлу зависимости, в качестве уникального идентификатора. Когда npm обнаруживает, что файл зависимости не соответствует сохраненному хешу, можно считать, что этот файл зависимости был изменен.
!
А повторно создаваемый код может быть рассмотрен как набор стандартов, целью которых является обеспечение того, что при запуске любого кода на любом устройстве, при условии соблюдения заранее определенных процедур построения, мы получим одинаковые хэш-значения. Конечно, в процессе реализации мы также можем использовать производные, отличные от хэшей, в качестве идентификаторов, и здесь мы называем это измерением кода (code measurement).
Nix - это распространенный инструмент для повторяемой сборки. После публикации исходного кода программы любой может проверить код, чтобы убедиться, что разработчики не вставили нежелательный контент, и любой может использовать Nix для сборки кода и проверить, соответствует ли созданный продукт кодом, развернутым проектом в производственной среде, имеющим одинаковые хеш-коды. Но как мы можем узнать значение хеш-кода программы в TEE? Здесь вступает в игру концепция, известная как «удаленное доказательство».
!
Дистанционное подтверждение - это подписанное сообщение от платформы TEE (доверенной стороны), в котором содержатся значения измерения кода программы, версия платформы TEE и т. д. Дистанционное подтверждение позволяет внешним наблюдателям знать, что программа выполняется в безопасном месте, к которому никто не имеет доступ (реальный TEE версии xx).
!
Возможность повторного построения и удаленное подтверждение позволяют любому пользователю знать фактический код, выполняемый в TEE, и информацию о версии платформы TEE, тем самым предотвращая злоумышленничество разработчиков или серверов.
Однако, в случае с TEE необходимо всегда доверять поставщику. Если поставщик TEE злоупотребляет своим положением, он может подделать удаленное доказательство. Поэтому, если поставщик рассматривается как возможный канал атаки, следует избегать полного полагания на TEE и лучше сочетать их с протоколом ZK или консенсусом.
Привлекательность TEE
По нашему мнению, TEE особенно популярен благодаря следующим особенностям, особенно в отношении дружественности развертывания для AI Agent:
Производительность: TEE может работать с моделью LLM, его производительность и стоимость сопоставимы с обычным сервером. В то время как zkML требует большого количества вычислительных ресурсов для генерации zk-доказательств LLM.
Поддержка GPU: NVIDIA предоставляет поддержку вычислений внутри защищенной среды (TEE) в своих последних сериях графических процессоров (Hopper, Blackwell и т. д.)
Правильность: LLM недетерминированы; Ввод одного и того же приглашения несколько раз приведет к разным результатам. В результате, несколько узлов, включая наблюдателей, пытающихся создать доказательства мошенничества, могут никогда не прийти к консенсусу по результатам работы LLM. В этом сценарии мы можем быть уверены в том, что LLM, работающий в TEE, не может быть изменен злоумышленниками, и что программы в TEE всегда работают так, как написано, что делает TEE более подходящим, чем opML или консенсус, для обеспечения надежности результатов вывода LLM**
Конфиденциальность: Данные в TEE невидимы для внешних программ. Поэтому ключи, созданные или принятые в TEE, всегда остаются безопасными. Эта особенность может использоваться для обеспечения пользователя тем, что любое сообщение, подписанное этим ключом, происходит из внутренней программы TEE. Пользователи могут быть уверены в передаче ключа TEE и установлении некоторых условий подписи, а также подтверждении подписи от TEE согласно заранее установленным условиям подписи
Соединение с Интернетом: С помощью некоторых инструментов программы, работающие в TEE, могут безопасно получать доступ к Интернету (необходимо предоставить правильные данные для поиска третьим сторонам, без раскрытия запросов или ответов серверам, работающим в TEE). Это очень полезно для извлечения информации из сторонних API и может использоваться для передачи вычислений доверенным, но закрытым поставщикам моделей.
Права на запись: В отличие от схемы zk, код, выполняемый в TEE, может создавать сообщения (независимо от того, являются ли они сообщениями в социальных сетях или транзакциями) и отправлять их через сеть API и RPC.
Разработчик-дружественный: фреймворки и SDK, связанные с TEE, позволяют писать код на любом языке и легко развертывать программы в TEE, как в облачном сервере
Независимо от того, хорошо это или плохо, в настоящее время трудно найти альтернативу для многих случаев использования TEE. Мы считаем, что введение TEE дальше расширяет пространство разработки приложений на цепочке, что может способствовать появлению новых сценариев применения.
TEE не является серебряной пулей
Программы, работающие в TEE, по-прежнему легко подвергаются воздействию ряда атак и ошибок. Как и умные контракты, они легко сталкиваются с рядом проблем. Для упрощения мы классифицируем возможные уязвимости следующим образом:
Разработчик неосторожен
Уязвимость времени выполнения
Архитектурный дефект дизайна
Проблемы с управлением
Недосмотр разработчиков
Независимо от того, намеренно это или нет, разработчики могут ослабить гарантии безопасности программ в TEE через намеренный или ненамеренный код. Это включает в себя:
Непрозрачный код: Модель безопасности TEE зависит от внешней верификации. Прозрачность кода критически важна для внешней проверки третьими сторонами.
Проблемы с измерением кода: Даже если код является открытым, если нет третьей стороны, которая перестроит код и проверит значения измерения кода в удаленном доказательстве, а затем проверит их на основе предоставленных в удаленном доказательстве значений измерения кода. Это аналогично получению zk-доказательства, но не его проверке.
Небезопасный код: Даже если вы тщательно генерируете и управляете ключами в TEE, логика, содержащаяся в коде, может утечь из TEE во время вызова извне. Кроме того, в коде могут быть встроены задние двери или уязвимости. В отличие от традиционной разработки бэкэнда, это требует высоких стандартов в процессе разработки и аудита программного обеспечения, аналогичных разработке смарт-контрактов.
Атаки на цепочку поставок: Современная разработка программного обеспечения использует большое количество стороннего кода. Атаки на цепочку поставок представляют серьезную угрозу целостности TEE.
Рантайм-уязвимость
Даже самые осторожные разработчики могут стать жертвами уязвимостей времени выполнения. Разработчикам необходимо тщательно рассмотреть, может ли одно из следующих условий повлиять на безопасность их проекта:
Динамический код: Не всегда возможно обеспечить полную прозрачность для всего кода. Иногда сам сценарий требует динамического выполнения непрозрачного кода, загруженного в TEE во время выполнения. Такой код может легко утечь конфиденциальную информацию или нарушить инвариантность, поэтому необходимо очень осторожно предотвращать такие ситуации.
Динамические данные: Большинство приложений используют внешние API и другие источники данных во время выполнения. Модель безопасности расширяется на эти источники данных, которые имеют тот же статус, что и оракулы в DeFi, и неправильные или устаревшие данные могут привести к катастрофе. Например, в случае использования AI Agent слишком сильная зависимость от LLM-сервисов, таких как Claude.
Небезопасная и нестабильная связь: TEE должен работать внутри сервера, содержащего компонент TEE. С точки зрения безопасности работающий на сервере TEE фактически является идеальным посредником (MitM) между TEE и внешним взаимодействием. Сервер не только способен подсматривать за внешними соединениями TEE и просматривать отправляемое содержимое, но также может проверять определенные IP-адреса, ограничивать соединения и внедрять пакеты данных в соединение, чтобы обмануть одну из сторон, заставив ее думать, что соединение происходит от xx.
Например, в TEE может быть запущен сопоставительный движок, который обрабатывает зашифрованные транзакции, но этот двигатель не может гарантировать справедливое сортирование (противодействие MEV), потому что маршрутизатор / шлюз / хост все еще может отбрасывать, задерживать или обрабатывать приоритетно на основе IP-адреса источника пакета данных.
архитектурный дефект
Стек технологий, используемый в приложении TEE, должен быть выбран осторожно. При разработке приложения TEE могут возникнуть следующие проблемы:
Приложения с большей атакой: Атака приложений относится к количеству модулей кода, которые нужно обеспечить полной безопасностью. Код с большей атакой очень сложно аудировать и может скрывать ошибки или уязвимости.** Это часто противоречит опыту разработчиков. Например, программы TEE, зависящие от Docker, имеют гораздо большую атаку по сравнению с программами TEE, которые не зависят от Docker. Инклейвы, зависящие от зрелых операционных систем, имеют большую атаку по сравнению с TEE, использующими самую легкую операционную систему.
** Переносимость и активность: ** В Web3 приложения должны быть устойчивы к цензуре. Любой может запустить TEE и взять под контроль неактивных участников системы, а также сделать приложения внутри TEE переносимыми. ** Самая большая проблема здесь - это переносимость ключей. В некоторых системах TEE существуют механизмы производства ключей, но как только используется механизм производства ключей внутри TEE, другие серверы не могут генерировать ключи внутри внешних программ TEE локально, ** что обычно ограничивает программы TEE только для одной машины, что недостаточно для обеспечения переносимости.
Небезопасный корень доверия : Например, как проверить, принадлежит ли данный адрес к AI Agent, работающему в TEE? Неправильное проектирование здесь может привести к тому, что истинный корень доверия может быть внешним сторонним или платформой управления ключами, а не самим TEE.
Проблемы с операцией
Наконец, но не менее важный момент состоит в том, что есть некоторые практические аспекты относительно того, как на самом деле работает сервер, выполняющий программу TEE.
Небезопасная версия платформы: TEE-платформа время от времени получает обновления безопасности, которые отображаются в виде версии платформы в удаленном доказательстве. Если ваш TEE не работает на безопасной версии платформы, хакеры могут использовать известные атаки, чтобы украсть ключи из TEE. Что еще хуже, сегодня ваш TEE может работать на безопасной версии платформы, а завтра может стать небезопасным.
Отсутствие физической безопасности: Несмотря на все усилия, TEE может быть подвержено атакам по боковым каналам, что обычно требует физического доступа и контроля к серверу, на котором находится TEE. Поэтому физическая безопасность является важным слоем глубокой защиты. Связанное понятие - облачное подтверждение, с помощью которого можно доказать, что TEE работает в облачном центре данных, при этом облачная платформа обеспечивает физическую безопасность.
Создание безопасной программы TEE
Мы разделили наши предложения на несколько пунктов:
Самое безопасное решение
Принятые необходимые меры предосторожности
Рекомендации, основанные на сценариях использования
1. Самое безопасное решение: без внешних зависимостей
Создание высоко-безопасных приложений может потребовать устранения внешних зависимостей, таких как внешний ввод, API или сервисы, что уменьшит поверхность атаки. Этот подход гарантирует независимую работу приложения без внешних взаимодействий, которые могут нанести ущерб его целостности или безопасности. Хотя такая стратегия может ограничить функциональное разнообразие программы, она может обеспечить высокий уровень безопасности.
Если модель работает локально, то для большинства случаев использования CryptoxAI можно достичь такого уровня безопасности.
2. Принятые необходимые меры предосторожности
Независимо от того, есть ли у приложения внешние зависимости, следующее содержимое обязательно!
Рассматривайте приложения TEE как смарт-контракты, а не как приложения бэк-энда; поддерживайте низкую частоту обновлений и строгие тесты.
Построение программ TEE должно быть таким же строгим, как написание, тестирование и обновление смарт-контрактов. Как и смарт-контракты, TEE работает в чрезвычайно чувствительной и невоспринимаемой среде, где ошибка или непредвиденное поведение может привести к серьезным последствиям, включая полную потерю средств. Тщательная проверка, обширное тестирование и минимальные, тщательно проверенные обновления являются крайне важными для обеспечения целостности и надежности приложений, основанных на TEE.
Проверьте код аудита и проверьте конвейер сборки
Безопасность приложения зависит не только от самого кода, но и от инструментов, используемых в процессе построения. Безопасный процесс сборки критичен для предотвращения уязвимостей. TEE только гарантирует, что предоставленный код будет работать в соответствии с ожидаемым процессом, но не может исправить дефекты, внесенные в процесс сборки.
Для снижения рисков необходимо строго тестировать и аудировать код для устранения ошибок и предотвращения ненужного утечки информации. Кроме того, повторяемая сборка играет важную роль, особенно когда код разрабатывается одной стороной и используется другой стороной. Повторяемая сборка позволяет любому проверить, соответствует ли программа, выполняемая в TEE, исходному исходному коду, что обеспечивает прозрачность и доверие. ** Без повторяемой сборки практически невозможно определить точное содержимое программы, выполняемой внутри TEE, что создает угрозу безопасности приложения. **
Например, исходный код проекта DeepWorm (модель моделирующего мозга червя, выполняемая в TEE) полностью открыт. Исполняемая программа в TEE построена с использованием конвейера Nix воспроизводимым образом.
Использование аудитированных или проверенных хранилищ
При обработке чувствительных данных в TEE-программах используйте только аудитированные библиотеки для управления ключами и обработки частных данных. Неаудитированные библиотеки могут раскрывать ключи и угрожать безопасности приложений. Приоритет отдается тщательно просмотренным, ориентированным на безопасность зависимостям для поддержания конфиденциальности и целостности данных.
Всегда проверяйте доказательства от TEE
Пользователи, взаимодействующие с TEE, должны проверять удаленное доказательство или механизм проверки, созданные TEE, чтобы обеспечить безопасное и надежное взаимодействие. Без этих проверок сервер может манипулировать ответами, и невозможно отличить настоящий вывод TEE от подделанных данных. Удаленное доказательство предоставляет ключевые доказательства для кодовой базы и конфигурации, выполняемых в TEE, и на его основе можно судить, соответствует ли программа, выполняемая внутри TEE, ожидаемым результатам.
Конкретная проверка может быть произведена на блокчейне (Intel SGX, AWS Nitro), а также проверена вне блокчейна с использованием доказательства ZK (Intel SGX, AWS Nitro), или может быть проверена пользователем самостоятельно или с помощью управляемой службы (например, t16z или MarlinHub).
3. Зависит от рекомендаций по использованию случаев
Следуя целям использования приложения и его структуре, следующие советы могут помочь сделать ваше приложение более безопасным.
Гарантия выполнения взаимодействия пользователя с TEE всегда через безопасный канал
Сервер, на котором находится TEE, по своей сути недостоверен. Сервер может перехватывать и изменять связь. В некоторых случаях чтение данных сервером без их изменения может быть приемлемым, а в других случаях даже чтение данных может быть нежелательным. Для снижения этих рисков критически важно установить безопасный конечный шифрованный канал между пользователем и TEE. По крайней мере, убедитесь, что сообщение содержит подпись для проверки подлинности и источника. Кроме того, пользователю необходимо всегда проверять удаленное подтверждение от TEE, чтобы убедиться, что он взаимодействует с правильным TEE. Это обеспечивает целостность и конфиденциальность связи.
Например, Oyster может поддерживать безопасную выдачу TLS с помощью записей CAA и RFC8657. Кроме того, он предоставляет нативный протокол TEE TLS под названием Scallop, который не зависит от WebPKI.
Знайте, что память TEE является мгновенной
Память TEE является эфемерной, что означает, что ее содержимое (включая ключи шифрования) будет потеряно при закрытии TEE. Без безопасного механизма для сохранения этой информации, критические данные могут остаться недоступными навсегда, что может привести к финансовым или операционным проблемам.
Сеть множественных вычислений (MPC) с децентрализованной системой хранения, такой как IPFS, может использоваться в качестве решения для этой проблемы. Сеть MPC разбивает ключи на несколько узлов, обеспечивая отсутствие у любого отдельного узла полного ключа, а также позволяя сети восстанавливать ключи по мере необходимости. Данные, зашифрованные этим ключом, могут быть безопасно храниться на IPFS.
Если необходимо, сеть MPC может предоставить ключи новому серверу TEE, работающему с тем же образом, при условии выполнения определенных условий. Этот подход обеспечивает гибкость и надежную безопасность, обеспечивая доступность и конфиденциальность данных даже в недоверенной среде.
!
Есть и другое решение, ** а именно, TEE передает соответствующие транзакции разным серверам MPC, после чего серверы MPC подписывают их и агрегируют подписи, и, наконец, транзакции попадают в блокчейн. Этот метод намного менее гибок и не может использоваться для сохранения ключей API, паролей или произвольных данных (без доверенного стороннего хранилища данных).**
!
Уменьшить поверхность атаки
Для критически важных случаев использования стоит попытаться минимизировать внешние зависимости за счет жертвы опыта разработчика. Например, Dstack поставляется с минимальным ядром, основанным на Yocto, в котором содержатся только модули, необходимые для работы Dstack. Даже старые технологии, такие как SGX (превышающие TDX), могут быть полезны, поскольку для их работы не требуется загрузчик или операционная система, становящиеся частью TEE.
физическая изоляция
Путем физической изоляции TEE от возможного вмешательства человека можно дополнительно повысить безопасность TEE. Хотя мы можем доверять центрам обработки данных в обеспечении физической безопасности, размещая TEE-сервера в центрах обработки данных и у облачных провайдеров, проекты, такие как Spacecoin, исследуют довольно интересную альтернативу - космос. В статье о SpaceTEE описываются меры безопасности, такие как измерение инерционного момента после запуска, чтобы проверить, соответствует ли спутник ожидаемому траекторному движению при входе на орбиту.
Мульти-производитель
Как и Ethereum, который полагается на реализацию нескольких клиентов для снижения риска ошибок, multiprovers использует различные реализации TEE для повышения безопасности и гибкости. ** Запуск одной и той же вычислительной процедуры на различных платформах TEE позволяет множественную проверку и гарантирует, что уязвимость в одной реализации TEE не поставит под угрозу всё приложение **. Хотя для этого метода требуется определенность процесса вычисления или согласование разных реализаций TEE в случае недетерминированности, он также предоставляет значительные преимущества, такие как изоляция сбоев, резервирование и кросс-проверка, что делает его хорошим выбором для приложений, требующих надежности.
!
Взгляд в будущее
TEE явно стал очень захватывающей областью. Как уже упоминалось ранее, повсеместность и постоянный доступ AI к конфиденциальным данным пользователей означает, что крупные технологические компании, такие как Apple и NVIDIA, используют TEE в своих продуктах и предлагают его как часть своих продуктов.
С другой стороны, сообщество криптографии всегда уделяло большое внимание безопасности. По мере того, как разработчики пытаются расширить приложения и случаи использования на цепочке, мы видим, что TEE становится популярным решением, обеспечивающим правильный баланс между функциональностью и предполагаемым доверием. Хотя TEE не обеспечивает минимального уровня доверия, как полные решения ZK, мы ожидаем, что TEE станет путем постепенного слияния продуктов Web3-компаний и крупных технологических компаний.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Руководство разработчика для TEE
Авторы: Prateek, Roshan, Siddhartha & Linguine (Marlin), Krane (Asula) Составитель: Shew, GodRealmX
С тех пор, как Apple объявила о запуске частного облака, а NVIDIA предоставляет конфиденциальные вычисления в графическом процессоре (GPU), доверенная среда выполнения (TEE) стала все более популярной. Их гарантированная конфиденциальность помогает защитить данные пользователей (включая приватные ключи), а изоляция обеспечивает, что выполнение программ, размещенных на них, не будет подвергаться вмешательству - независимо от того, являются ли это люди, другие программы или операционные системы. Поэтому неудивительно, что в области Crypto x AI широко используется TEE для создания продуктов.
Как и любая новая технология, TEE проходит оптимистический экспериментальный период. В этой статье мы хотели бы предоставить основное понятийное руководство для разработчиков и обычных читателей, чтобы они понимали, что такое TEE, его модель безопасности, распространенные уязвимости и лучшие практики безопасного использования TEE. * (Примечание: чтобы текст был понятен, мы сознательно заменили термины TEE на более простые эквиваленты).
Что такое TEE
TEE - это изолированная среда в процессоре или центре обработки данных, в которой программы могут работать, не подвергаясь вмешательству остальной части системы. Для предотвращения вмешательства других частей системы в TEE нам нужен ряд мер, в основном строгий контроль доступа, то есть контроль доступа остальных частей системы к программам и данным внутри TEE. В настоящее время TEE повсюду, в телефонах, серверах, ПК и облачных средах, поэтому они очень доступны и имеют разумную цену.
Вышеупомянутое содержание может звучать неясно и абстрактно, на самом деле различные серверы и облачные поставщики реализуют TEE по-разному, но их основная цель - предотвратить вмешательство других программ в TEE.
!
Большинство пользователей, возможно, будут использовать биометрическую информацию для входа в устройства, например, разблокировки телефона по отпечатку пальца. Но как мы можем гарантировать, что вредоносные приложения, веб-сайты или операционные системы с джейлбрейком не смогут получить доступ к этой биометрической информации и украсть ее? Фактически, помимо шифрования данных, схемы в TEE устройстве абсолютно не позволяют программам обращаться к областям памяти и процессора, занятым чувствительными данными.
Железный кошелек - еще один пример сценария применения TEE. Железный кошелек подключается к компьютеру и взаимодействует с ним в песочнице, но компьютер не может напрямую получить доступ к мнемоническим словам, хранящимся в железном кошельке. В обоих вышеупомянутых случаях пользователи доверяют производителям устройств, способным правильно разрабатывать микросхемы и предоставлять соответствующие обновления прошивки, чтобы предотвратить экспорт или просмотр конфиденциальных данных в TEE.
Модель безопасности
К сожалению, существует множество различных реализаций TEE, и для каждой из них (Intel SGX, Intel TDX, AMD SEV, AWS Nitro Enclaves, ARM TrustZone) требуется отдельное моделирование и анализ безопасности. В остальной части этой статьи мы сосредоточимся на Intel SGX, TDX и AWS Nitro, поскольку эти системы TEE имеют больше пользователей и полноценные инструменты разработки. Эти системы также являются наиболее распространенными внутри Web3 системами TEE.
В общем, рабочий процесс развертывания приложений в TEE выглядит следующим образом:
!
Очевидно, здесь есть 3 потенциальных риска:
К счастью, сейчас у TEE есть решение для устранения вышеупомянутых рисков, а именно воспроизводимые сборки(Reproducible Builds) и удаленные аттестации(Remote Atteststations).
Что такое повторное построение? Современная разработка программного обеспечения часто требует импорта большого количества зависимостей, таких как внешние инструменты, библиотеки или фреймворки и т. д. Эти файлы зависимостей также могут иметь скрытые уязвимости. Сейчас npm и другие схемы используют хеш кода, соответствующего файлу зависимости, в качестве уникального идентификатора. Когда npm обнаруживает, что файл зависимости не соответствует сохраненному хешу, можно считать, что этот файл зависимости был изменен.
!
А повторно создаваемый код может быть рассмотрен как набор стандартов, целью которых является обеспечение того, что при запуске любого кода на любом устройстве, при условии соблюдения заранее определенных процедур построения, мы получим одинаковые хэш-значения. Конечно, в процессе реализации мы также можем использовать производные, отличные от хэшей, в качестве идентификаторов, и здесь мы называем это измерением кода (code measurement).
Nix - это распространенный инструмент для повторяемой сборки. После публикации исходного кода программы любой может проверить код, чтобы убедиться, что разработчики не вставили нежелательный контент, и любой может использовать Nix для сборки кода и проверить, соответствует ли созданный продукт кодом, развернутым проектом в производственной среде, имеющим одинаковые хеш-коды. Но как мы можем узнать значение хеш-кода программы в TEE? Здесь вступает в игру концепция, известная как «удаленное доказательство».
!
Дистанционное подтверждение - это подписанное сообщение от платформы TEE (доверенной стороны), в котором содержатся значения измерения кода программы, версия платформы TEE и т. д. Дистанционное подтверждение позволяет внешним наблюдателям знать, что программа выполняется в безопасном месте, к которому никто не имеет доступ (реальный TEE версии xx).
!
Возможность повторного построения и удаленное подтверждение позволяют любому пользователю знать фактический код, выполняемый в TEE, и информацию о версии платформы TEE, тем самым предотвращая злоумышленничество разработчиков или серверов.
Однако, в случае с TEE необходимо всегда доверять поставщику. Если поставщик TEE злоупотребляет своим положением, он может подделать удаленное доказательство. Поэтому, если поставщик рассматривается как возможный канал атаки, следует избегать полного полагания на TEE и лучше сочетать их с протоколом ZK или консенсусом.
Привлекательность TEE
По нашему мнению, TEE особенно популярен благодаря следующим особенностям, особенно в отношении дружественности развертывания для AI Agent:
Независимо от того, хорошо это или плохо, в настоящее время трудно найти альтернативу для многих случаев использования TEE. Мы считаем, что введение TEE дальше расширяет пространство разработки приложений на цепочке, что может способствовать появлению новых сценариев применения.
TEE не является серебряной пулей
Программы, работающие в TEE, по-прежнему легко подвергаются воздействию ряда атак и ошибок. Как и умные контракты, они легко сталкиваются с рядом проблем. Для упрощения мы классифицируем возможные уязвимости следующим образом:
Недосмотр разработчиков
Независимо от того, намеренно это или нет, разработчики могут ослабить гарантии безопасности программ в TEE через намеренный или ненамеренный код. Это включает в себя:
Рантайм-уязвимость
Даже самые осторожные разработчики могут стать жертвами уязвимостей времени выполнения. Разработчикам необходимо тщательно рассмотреть, может ли одно из следующих условий повлиять на безопасность их проекта:
Например, в TEE может быть запущен сопоставительный движок, который обрабатывает зашифрованные транзакции, но этот двигатель не может гарантировать справедливое сортирование (противодействие MEV), потому что маршрутизатор / шлюз / хост все еще может отбрасывать, задерживать или обрабатывать приоритетно на основе IP-адреса источника пакета данных.
архитектурный дефект
Стек технологий, используемый в приложении TEE, должен быть выбран осторожно. При разработке приложения TEE могут возникнуть следующие проблемы:
Проблемы с операцией
Наконец, но не менее важный момент состоит в том, что есть некоторые практические аспекты относительно того, как на самом деле работает сервер, выполняющий программу TEE.
Создание безопасной программы TEE
Мы разделили наши предложения на несколько пунктов:
1. Самое безопасное решение: без внешних зависимостей
Создание высоко-безопасных приложений может потребовать устранения внешних зависимостей, таких как внешний ввод, API или сервисы, что уменьшит поверхность атаки. Этот подход гарантирует независимую работу приложения без внешних взаимодействий, которые могут нанести ущерб его целостности или безопасности. Хотя такая стратегия может ограничить функциональное разнообразие программы, она может обеспечить высокий уровень безопасности.
Если модель работает локально, то для большинства случаев использования CryptoxAI можно достичь такого уровня безопасности.
2. Принятые необходимые меры предосторожности
Независимо от того, есть ли у приложения внешние зависимости, следующее содержимое обязательно!
Рассматривайте приложения TEE как смарт-контракты, а не как приложения бэк-энда; поддерживайте низкую частоту обновлений и строгие тесты.
Построение программ TEE должно быть таким же строгим, как написание, тестирование и обновление смарт-контрактов. Как и смарт-контракты, TEE работает в чрезвычайно чувствительной и невоспринимаемой среде, где ошибка или непредвиденное поведение может привести к серьезным последствиям, включая полную потерю средств. Тщательная проверка, обширное тестирование и минимальные, тщательно проверенные обновления являются крайне важными для обеспечения целостности и надежности приложений, основанных на TEE.
Проверьте код аудита и проверьте конвейер сборки
Безопасность приложения зависит не только от самого кода, но и от инструментов, используемых в процессе построения. Безопасный процесс сборки критичен для предотвращения уязвимостей. TEE только гарантирует, что предоставленный код будет работать в соответствии с ожидаемым процессом, но не может исправить дефекты, внесенные в процесс сборки.
Для снижения рисков необходимо строго тестировать и аудировать код для устранения ошибок и предотвращения ненужного утечки информации. Кроме того, повторяемая сборка играет важную роль, особенно когда код разрабатывается одной стороной и используется другой стороной. Повторяемая сборка позволяет любому проверить, соответствует ли программа, выполняемая в TEE, исходному исходному коду, что обеспечивает прозрачность и доверие. ** Без повторяемой сборки практически невозможно определить точное содержимое программы, выполняемой внутри TEE, что создает угрозу безопасности приложения. **
Например, исходный код проекта DeepWorm (модель моделирующего мозга червя, выполняемая в TEE) полностью открыт. Исполняемая программа в TEE построена с использованием конвейера Nix воспроизводимым образом.
Использование аудитированных или проверенных хранилищ
При обработке чувствительных данных в TEE-программах используйте только аудитированные библиотеки для управления ключами и обработки частных данных. Неаудитированные библиотеки могут раскрывать ключи и угрожать безопасности приложений. Приоритет отдается тщательно просмотренным, ориентированным на безопасность зависимостям для поддержания конфиденциальности и целостности данных.
Всегда проверяйте доказательства от TEE
Пользователи, взаимодействующие с TEE, должны проверять удаленное доказательство или механизм проверки, созданные TEE, чтобы обеспечить безопасное и надежное взаимодействие. Без этих проверок сервер может манипулировать ответами, и невозможно отличить настоящий вывод TEE от подделанных данных. Удаленное доказательство предоставляет ключевые доказательства для кодовой базы и конфигурации, выполняемых в TEE, и на его основе можно судить, соответствует ли программа, выполняемая внутри TEE, ожидаемым результатам.
Конкретная проверка может быть произведена на блокчейне (Intel SGX, AWS Nitro), а также проверена вне блокчейна с использованием доказательства ZK (Intel SGX, AWS Nitro), или может быть проверена пользователем самостоятельно или с помощью управляемой службы (например, t16z или MarlinHub).
3. Зависит от рекомендаций по использованию случаев
Следуя целям использования приложения и его структуре, следующие советы могут помочь сделать ваше приложение более безопасным.
Гарантия выполнения взаимодействия пользователя с TEE всегда через безопасный канал
Сервер, на котором находится TEE, по своей сути недостоверен. Сервер может перехватывать и изменять связь. В некоторых случаях чтение данных сервером без их изменения может быть приемлемым, а в других случаях даже чтение данных может быть нежелательным. Для снижения этих рисков критически важно установить безопасный конечный шифрованный канал между пользователем и TEE. По крайней мере, убедитесь, что сообщение содержит подпись для проверки подлинности и источника. Кроме того, пользователю необходимо всегда проверять удаленное подтверждение от TEE, чтобы убедиться, что он взаимодействует с правильным TEE. Это обеспечивает целостность и конфиденциальность связи.
Например, Oyster может поддерживать безопасную выдачу TLS с помощью записей CAA и RFC8657. Кроме того, он предоставляет нативный протокол TEE TLS под названием Scallop, который не зависит от WebPKI.
Знайте, что память TEE является мгновенной
Память TEE является эфемерной, что означает, что ее содержимое (включая ключи шифрования) будет потеряно при закрытии TEE. Без безопасного механизма для сохранения этой информации, критические данные могут остаться недоступными навсегда, что может привести к финансовым или операционным проблемам.
Сеть множественных вычислений (MPC) с децентрализованной системой хранения, такой как IPFS, может использоваться в качестве решения для этой проблемы. Сеть MPC разбивает ключи на несколько узлов, обеспечивая отсутствие у любого отдельного узла полного ключа, а также позволяя сети восстанавливать ключи по мере необходимости. Данные, зашифрованные этим ключом, могут быть безопасно храниться на IPFS.
Если необходимо, сеть MPC может предоставить ключи новому серверу TEE, работающему с тем же образом, при условии выполнения определенных условий. Этот подход обеспечивает гибкость и надежную безопасность, обеспечивая доступность и конфиденциальность данных даже в недоверенной среде.
!
Есть и другое решение, ** а именно, TEE передает соответствующие транзакции разным серверам MPC, после чего серверы MPC подписывают их и агрегируют подписи, и, наконец, транзакции попадают в блокчейн. Этот метод намного менее гибок и не может использоваться для сохранения ключей API, паролей или произвольных данных (без доверенного стороннего хранилища данных).**
!
Уменьшить поверхность атаки
Для критически важных случаев использования стоит попытаться минимизировать внешние зависимости за счет жертвы опыта разработчика. Например, Dstack поставляется с минимальным ядром, основанным на Yocto, в котором содержатся только модули, необходимые для работы Dstack. Даже старые технологии, такие как SGX (превышающие TDX), могут быть полезны, поскольку для их работы не требуется загрузчик или операционная система, становящиеся частью TEE.
физическая изоляция
Путем физической изоляции TEE от возможного вмешательства человека можно дополнительно повысить безопасность TEE. Хотя мы можем доверять центрам обработки данных в обеспечении физической безопасности, размещая TEE-сервера в центрах обработки данных и у облачных провайдеров, проекты, такие как Spacecoin, исследуют довольно интересную альтернативу - космос. В статье о SpaceTEE описываются меры безопасности, такие как измерение инерционного момента после запуска, чтобы проверить, соответствует ли спутник ожидаемому траекторному движению при входе на орбиту.
Мульти-производитель
Как и Ethereum, который полагается на реализацию нескольких клиентов для снижения риска ошибок, multiprovers использует различные реализации TEE для повышения безопасности и гибкости. ** Запуск одной и той же вычислительной процедуры на различных платформах TEE позволяет множественную проверку и гарантирует, что уязвимость в одной реализации TEE не поставит под угрозу всё приложение **. Хотя для этого метода требуется определенность процесса вычисления или согласование разных реализаций TEE в случае недетерминированности, он также предоставляет значительные преимущества, такие как изоляция сбоев, резервирование и кросс-проверка, что делает его хорошим выбором для приложений, требующих надежности.
!
Взгляд в будущее
TEE явно стал очень захватывающей областью. Как уже упоминалось ранее, повсеместность и постоянный доступ AI к конфиденциальным данным пользователей означает, что крупные технологические компании, такие как Apple и NVIDIA, используют TEE в своих продуктах и предлагают его как часть своих продуктов.
С другой стороны, сообщество криптографии всегда уделяло большое внимание безопасности. По мере того, как разработчики пытаются расширить приложения и случаи использования на цепочке, мы видим, что TEE становится популярным решением, обеспечивающим правильный баланс между функциональностью и предполагаемым доверием. Хотя TEE не обеспечивает минимального уровня доверия, как полные решения ZK, мы ожидаем, что TEE станет путем постепенного слияния продуктов Web3-компаний и крупных технологических компаний.