Автор: Доктор Шунфан (Шелвен) Чжоу, ведущий исследователь Phala Network и один из авторов технического описания Phala, занимается исследованиями в области безопасности более 7 лет. Он является ведущим автором книги «Постоянно развивающаяся игра: оценка атак и защиты в реальном мире в экосистеме Ethereum», симпозиума по безопасности USENIX 2020 и других документов по анализу программ.

Абстрактный

30 ноября эксперт по безопасности Эндрю Миллер отметил, что уязвимости Intel SGX создали большие риски безопасности для таких проектов, как Secret Network, что вызвало широкие дискуссии в сообществе. Intel SGX, наиболее широко распространенная реализация TEE, также используется внесетевыми работниками Phala, однако Phala использует новый дизайн системы, который уменьшает поверхность атаки и смягчает последствия потенциальных атак. Наша команда разработчиков считает влияние таких уязвимостей на Phala контролируемым.

Эта статья объяснит читателям:

• Почему уязвимости ÆPIC Leak и MMIO подорвали безопасность Secret Network
• Причины, по которым Phala использует Secure Enclave (TEE)
• Как Phala гарантирует, что он не будет скомпрометирован уязвимостями SGX
• Будущие механизмы безопасности

1. Что вызвало уязвимость в Secret Network?

• Аппаратному обеспечению с неисправленными уязвимостями ( утечка ÆPIC и уязвимости MMIO , анонсированные Intel 9 августа 2022 г.) было разрешено присоединиться к секретной сети и управлять узлами. Команда Secret заморозила регистрацию после того, как белая шляпа сообщила об этой проблеме;
• Один и тот же главный ключ дешифрования в секретной сети используется всеми узлами.

2. Чего могли добиться злоумышленники?

Как я цитируюhttps://sgx.fail: «Эти уязвимости могут быть использованы для извлечения начального числа консенсуса, главного ключа дешифрования для частных транзакций в Секретной сети. Разоблачение начального значения консенсуса позволит полностью задним числом раскрыть все частные транзакции Secret-4 с момента создания цепочки».

3. Подвержены ли Phala Network тем же уязвимостям?

Нет. Phala принимает управление доступом к регистрации узлов (называемых « рабочими» в Phala) и управление иерархией ключей, о чем я расскажу позже.

Ресурсы :

• https://scrt.network/blog/notice-successful-resolution-of-xapic-vulnerability
• https://sgx.fail/

Зачем Phala нужен Secure Enclave (TEE)

Phala — это вычислительное облако без разрешений, которое позволяет любым компьютерам присоединяться в качестве рабочих, поэтому наша модель угроз заключается в том, что по умолчанию ни один рабочий не является доверенным. Злоумышленники, действующие как работники, могут попытаться:

• просматривать данные пользователей;
• предоставлять ложные результаты выполнения или вообще не выполнять никаких вычислений;
• предоставлять некачественные услуги, такие как снижение производительности процессора или блокировка доступа к сети.

Secure Enclave обеспечивает важные аппаратные средства безопасности, в том числе:

• Конфиденциальность : все значения памяти зашифрованы;
• Целостность выполнения : никто не может нарушить правильность выполнения, даже если он контролирует операционную систему и физический компьютер;
• Удаленная аттестация : пользователи могут удаленно проверять аппаратное и программное обеспечение, работающее в Secure Enclave.

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

Может ли Phala использовать доказательство с нулевым разглашением, многосторонние вычисления или полностью гомоморфное шифрование в качестве своих рабочих?

Ответ — нет, да и да, поскольку эти решения работают по-разному.

• В случае ZKP пользователь выполняет свое собственное выполнение и предоставляет только доказательство в цепочке, что он действительно выполнил работу. Это не случай облачных вычислений, когда вы делегируете свои вычисления другим;
• MPC делит задания на разные части, поэтому ни один из исполнителей не может знать исходный ввод или конечный результат;
• FHE позволяет исполнителям выполнять вычисления непосредственно с зашифрованным текстом, поэтому они не могут знать данные пользователей.

Контроль доступа при регистрации работников

Чтобы присоединиться к Phala в качестве работника, необходимо выполнить два предварительных условия:

• Работники должны предоставить оборудование с поддержкой Secure Enclave. В настоящее время мы поддерживаем только Intel SGX, но наше исследование AMD-SEV показало, что он также совместим с нашей текущей системой;
• Воркеры запускают немодифицированные программы, созданные Phala, включая узел Phala и автономную pRuntime (сокращение от Phala Runtime) .

• Информация об оборудовании
• Запускается ли pRuntime внутри SGX;
• Известные уязвимости с учетом текущей версии оборудования и прошивки. На основании этого блокчейн Phala отклонит аппаратное обеспечение с уязвимостями из черного списка и присвоит каждому работнику уровень доверия .
• Информация о программном обеспечении
• Хэш бинарного файла программы, который помогает гарантировать неизменность pRuntime;
• Начальная структура памяти программы, поэтому определяется ее начальное состояние.

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

Управление ключевой иерархией

Первая в мире иерархия ключей для гибридной системы блокчейн-TEE была предложена в документе Ekiden в 2019 году и служит основой для проекта Oasis. Являясь вычислительным облаком, Phala улучшает этот дизайн, чтобы сделать его жизнеспособным для сети примерно из 100 000 узлов. Мы также представляем новый механизм, такой как ротация ключей, для дальнейшего повышения надежности облака.

Прежде чем мы действительно углубимся в детали нашего управления ключами контракта, читатели должны знать, что каждый объект в нашей системе имеет свой собственный идентификационный ключ. Каждый пользователь имеет свою учетную запись, а каждый рабочий процесс и привратник (которые избираются рабочими процессами) имеют свою собственную пару WorkerKey sr25519 , которая генерируется внутри pRuntime (а также в SGX), а закрытый ключ никогда не покидает SGX. Идентификационный ключ используется для:

• Идентифицировать сообщение объекта с помощью подписи;
• Установите зашифрованный канал связи между пользователями, работниками и привратниками с соглашением о ключах ECDH . По умолчанию любое общение между любыми сущностями шифруется в Phala.

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

Наконец, когда контракт развертывается в кластере, он развертывается для всех рабочих процессов в этом кластере. Эти рабочие процессы будут следовать детерминированному процессу и выводить ClusterKey, чтобы получить тот же ContractKey. ContractKeys уникальны для разных контрактов.

Каковы уязвимости в случае утечки определенных ключей?

• В случае утечки WorkerKey злоумышленники могут расшифровать все отправленные ему сообщения, такие как ClusterKey его кластера, который можно использовать для доступа к ContractKeys этого кластера. Злоумышленники могут даже выдать себя за работника, чтобы предоставить пользователям ложные результаты. Такая злонамеренная активность может быть обнаружена путем сравнения результатов нескольких рабочих процессов, после чего цепочка отключит скомпрометированный рабочий процесс и конфискует PHA этого рабочего;
• В случае утечки ContractKey злоумышленники могут расшифровать состояния и все исторические входные данные этого контракта;
• В случае утечки ClusterKey злоумышленники могут узнать указанную выше информацию обо всех контрактах в этом кластере;
• В случае утечки MasterKey происходит утечка всех исторических данных.

• В Phala реализована ротация ключей для привратников, что означает, что с разрешения Совета привратники могут обновлять MasterKey, а затем, соответственно, ClusterKeys и ContractKeys.
• Поэтому, когда произойдет худший случай, мы сначала зарегистрируем новые привратники с новейшим оборудованием, отменим регистрацию всех старых (поскольку они, вероятно, будут уязвимы) и переключимся на новый мастер-ключ.

1. Используйте многосторонние вычисления для управления MasterKey

2. Включить обновление котировок RA

Поскольку Phat Contract в настоящее время не поддерживается в основной сети, работникам нужно отправить котировки RA только один раз во время регистрации. Когда Phat Contract будет выпущен, мы включим регулярное обновление RA Quotes, чтобы уязвимые рабочие были сокращены, как только сообщалось о новых уязвимостях, а рабочие не применяли исправления.

Наконец, я хотел бы поблагодарить Эндрю Миллера и группу исследователей безопасности, включая Кристину Гарман, Даниэля Генкина, Стефана ван Шайка и других, за их вклад в область безопасности. Как сказал Эндрю, цель его команды — помочь улучшить безопасность и снизить количество инцидентов, связанных с безопасностью. Я искренне надеюсь на более подробные обсуждения с исследователями безопасности, чтобы консолидировать ненадежную инфраструктуру для мира Web3.